<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.network.dns.operations">
    <title>gmane.network.dns.operations</title>
    <link>http://blog.gmane.org/gmane.network.dns.operations</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2171"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2159"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2154"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2150"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2144"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2142"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2134"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2122"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2118"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2106"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2105"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2104"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2103"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2101"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2096"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2076"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2054"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2049"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2047"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.network.dns.operations/2045"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2171">
    <title>Querying version.bind illegal?</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2171</link>
    <description>&lt;pre&gt;Hi,

I've developed a DNS checking tool (http://www.dnsinspect.com/).
After 5 years of running it without any issues, I've received today a
compliant through my ISP from a big company in a foreign country.

They pretend that my VPS is attacking their infrastructure while
querying their DNS server's version and this request can be regarded
as cyber-terror attack (my tool tries only to warn users exposing the
DNS software version).

I've blacklisted their DNS servers from being queried in the future,
but I would like to know if querying version.bind is illegal (in
some countries)?

Regards,
Vitalie
&lt;/pre&gt;</description>
    <dc:creator>Vitalie Cherpec</dc:creator>
    <dc:date>2013-05-23T13:39:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2159">
    <title>DNS Performance Test Over TCP</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2159</link>
    <description>&lt;pre&gt;Hi,

I'm trying to run a DNS TCP performance test to a DNS server in a
lab environment. I'm doing the test from another server connected
directly with a 1 Gb link. Both servers are running CentOS 6.4. I use
dnsperf to run my DNS performance test on UDP, and it's giving me what I
want on both IPv4 and IPv6, but I can't find a proper tool to do it with
TCP.

I tried querytcp, but it won't let me limit the maximum queries per
second. Also, couldn't get queryperf++ to install on my boxes because it
has some dependencies that it needs to run.

Does anybody know a good tool to do DNS performance tests over TCP?

Regards,
Kareem.

&lt;/pre&gt;</description>
    <dc:creator>Kareem Ali</dc:creator>
    <dc:date>2013-05-22T14:06:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2154">
    <title>http://www.intodns.com/ no go for tlds</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2154</link>
    <description>&lt;pre&gt;http://www.intodns.com/ does not seem to work for cctlds

randy
&lt;/pre&gt;</description>
    <dc:creator>Randy Bush</dc:creator>
    <dc:date>2013-05-21T14:01:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2150">
    <title>Missing nameservers reported by parent</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2150</link>
    <description>&lt;pre&gt;Hello,

from: http://www.intodns.com/dns-oarc.net

FAIL: The following nameservers are listed at your nameservers as 
nameservers for your domain, but are not listed at the parent 
nameservers (see RFC2181 5.4.1). You need to make sure that these 
nameservers are working.If they are not working ok, you may have problems!
ns2.dns-oarc.net

How about this warning?

Regards.
&lt;/pre&gt;</description>
    <dc:creator>fenghe</dc:creator>
    <dc:date>2013-05-21T03:16:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2144">
    <title>Multi-master setups</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2144</link>
    <description>&lt;pre&gt;Syncing between the two servers would seem to only help in the case where
the masters could only reach the first server, but your slaves could only
reach the second server, which seems unlikely, unless the second
distribution server is closer (network-wise) to the slaves.

I would continue to push for 100% allow-transfer, and set up automated cron
jobs to test and send email for those that are not working.

I plan to use a similar setup, but fortunately I only have about a dozen
masters to contact, so it will be much easier for me.

The only 'clever' alternative I can think of is to change the IP of the
second distribution server to take over the IP of the first server if the
first one fails.  It helps if each server has a second IP that is separate.

&lt;/pre&gt;</description>
    <dc:creator>Bob Harold</dc:creator>
    <dc:date>2013-05-20T16:34:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2142">
    <title>Multi-master setups</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2142</link>
    <description>&lt;pre&gt;Dear DNS folk,

I'm thinking about multi-master setups to add some resiliency to our DNS
infrastructure.

In our specific case we have a distribution server which slaves several
zones from various different parties. They also send notify messages to
this server. Once it transfers a zone, it sends notify messages to our
public-facing DNS cluster, and they all transfer the zone from it.

Obviously, this single distribution server is a single point of failure,
and I'd like to get rid of it.

The simplest solution is to add a second server to our infrastructure,
with an identical zone configuration, so that it is also a slave for all
the same zones. It would also transfer zones directly from the masters,
and provide AXFR/IXFR to our cluster.

Adding a second distribution server has management overhead though. We
have several hundred masters, and even after contacting all of them, we
will never have a 100% clean setup where the master allows zone
transfers for both our distribution servers. So if I want to ensure that
both our distribution servers hold identical copies of zones, then I
would ideally want them to notify each other, and pull zones off each
other as well. Do any of you do this?

Aside from this idea, are there any other clever ideas people have
implemented?

Regards,

Anand Buddhdev


&lt;/pre&gt;</description>
    <dc:creator>Anand Buddhdev</dc:creator>
    <dc:date>2013-05-17T14:53:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2134">
    <title>DNS amplification attacks indraft-ietf-savi-threat-scope-08</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2134</link>
    <description>&lt;pre&gt;IETF document
&amp;lt;http://www.rfc-editor.org/internet-drafts/draft-ietf-savi-threat-scope-08.txt&amp;gt; 
(approved by IESG and currently in the RFC Editor Queue) contains:


Two things puzzle me: I'm not sure of what attack they are referring
to since there is no reference in the RFC. Is it the one discussed in
tge "DNS deluge for x.p.ctrc.c" thread on the NANOG mailing list in
february 2006?

And the second is the mentioned amplification factor. All the DNS
servers I know limit the size of the UDP answer to 4 096 bytes, 4 144
with the IPv4 and UDP headers. A factor of 76:1 needs requests smaller
or equal to 54 bytes, which leaves only SIX bytes for the DNS
message... How did they reach this number?
_______________________________________________
dns-operations mailing list
dns-operations&amp;lt; at &amp;gt;lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs&lt;/pre&gt;</description>
    <dc:creator>Stephane Bortzmeyer</dc:creator>
    <dc:date>2013-05-16T07:44:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2122">
    <title>bind-9.9.3rc2 ANY+TCP patch</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2122</link>
    <description>&lt;pre&gt;I thought I'd share this to anyone that wants to just force all TYPE=ANY queries over TCP to prevent those from coming from spoofed locations.

This is a crude but effective hack.  It doesn't stop the system from recursing to find the response.

http://puck.nether.net/~jared/bind-9.9.3rc2-tcp-any.patch

- Jared
&lt;/pre&gt;</description>
    <dc:creator>Jared Mauch</dc:creator>
    <dc:date>2013-05-15T19:16:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2118">
    <title>security with a firewall</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2118</link>
    <description>&lt;pre&gt;Hi,

Does a hardware firewall help to defend the DNS attack?
If so what's the suggested policy/rules?

Thanks.
&lt;/pre&gt;</description>
    <dc:creator>fenghe</dc:creator>
    <dc:date>2013-05-15T08:13:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2106">
    <title>DSCng 0.1.0</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2106</link>
    <description>&lt;pre&gt;Hi everybody,

I am happy to announce, that we published the first numbered release of 
DSCng - 0.1.0.

The project is still in development and there will certainly be some 
bugs and rough edges. On the other hand, it is no problem to run DSCng 
alongside your production version of DSC and we feel confident that the 
code is stable enough for broader testing. We also promise to include 
migration scripts for any future updates, should the database structure 
change.

More information about the project, as well as download links and 
installation documentation, is available at http://www.dscng.cz/

Best regards

Beda

&lt;/pre&gt;</description>
    <dc:creator>Bedrich Kosata</dc:creator>
    <dc:date>2013-05-14T07:21:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2105">
    <title>Call for Participation -- ICANN DNSSEC Workshop 17July 2013</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2105</link>
    <description>&lt;pre&gt;Call for Participation -- ICANN DNSSEC Workshop 17 July 2013

The DNSSEC Deployment Initiative, in cooperation with the ICANN Security
and Stability Advisory Committee (SSAC), is planning a DNSSEC Workshop at
the ICANN meeting in Durban, South Africa on 17 July 2013.  The DNSSEC
Workshop has been a part of ICANN meetings for several years and has
provided a forum for both experienced and new people to meet, present and
discuss current and future DNSSEC deployments.  For reference, the most
recent session was held at the ICANN meeting in Beijing, China on 10 April
2013. The presentations and transcripts are available
athttp://beijing46.icann.org/node/37125.

We are seeking presentations on the following topics:

1.  DNSSEC Activities in Africa
For this panel we are seeking participation from those who have been
involved in DNSSEC deployment in Africa as well as those who have a keen
interest in the challenges and benefits of deployment.  Key questions are
to consider include: What would help to promote DNSSEC deployment?  What
are the challenges you have faced when you deployed DNSSEC?

2. The Operational Realities of Running DNSSEC
Now that DNSSEC has become an operational norm for many registries,
registrars, and ISPs, what have we learned about how we manage DNSSEC?
What's best practice around key rollovers? How often do you review your
disaster recovery procedures? Is there operational familiarity within your
customer support teams? Has DNSSEC made DNS more 'brittle' or is it just a
run-of-the-mill operational practice? What operational statistics have we
gathered about DNSSEC? Is it changing DNS patterns? How are our
nameservers handling DNSSEC traffic? Is the volume as expected? Have we
seen anything unusual?  Are there experiences being documented in the form
of best practices, or something similar, for transfer of signed zones?

3.  DNSSEC and Enterprise Activities
DNSSEC has always been seen as a huge benefit to organizations looking to
protect their identity and security on the Web. Large enterprises are an
obvious target for DNS hackers and DNSSEC provides an ideal solution to
this challenge. This session aims to look at the benefits and challenges
of deploying DNSSEC for major enterprises. Topics for discussion:

* What is the current status of DNSSEC deployment among enterprises?
* What plans do the major enterprises have for their DNSSEC roadmaps?
* What are the challenges to deployment for these organizations?  Do they
foresee raising awareness of DNSSEC with their customers?

4. When Unexpected DNSSEC Events Occur
What have we learned from some of the operational outages that we have
seen over the past 18 months? Are there lessons that we can pass on to
those just about to implement DNSSEC? How do you manage dissemination of
information about the outage? What have you learned about communications
planning? Do you have a route to ISPs and registrars? How do you liaise
with your CERT community?

5.  Preparing for Root Key Rollover
For this topic we are seeking input on issues relating to root key
rollover.  In particular, we are seeking comments from vendors, ISPs, and
the community that will be affected by distribution of new root keys.

6.  DNSSEC: Regulative, Legislative and Persuasive Approaches to
Encouraging Deployment
There are many models in discussion for encouraging the take-up of DNSSEC
amongst TLDs. In some jurisdictions we have seen governmental edicts
insisting that DNSSEC is deployed across a Top Level Domain. In others, we
have seen reports produced for governments highlighting the lack of take
up and the need for tighter control amongst operators. Recently, we have
witnessed the consideration  of mandated DNSSEC signing of zones by some
TLDs in order to gain access to newer premium domains.  Have any of these
approaches worked in encouraging take up of DNSSEC? What role does a
national government have in assisting deployment of DNSSEC? How are some
of these measures perceived by registrars, DNS operators, ISPs and
registrants?

7. DANE and Other DNSSEC Applications
Using DNSSEC as a means of authentication for http transactions is an
exciting development of DNSSEC. What is the progress of the DNS-Based
Authentication of Named Entities (DANE) initiative? (See
http://datatracker.ietf.org/wg/dane/. &amp;lt;http://datatracker.ietf.org/wg/dane/&amp;gt;
) How soon could DANE become a
deployable reality and what will be the impact of such a deployment, e.g.
impact on traditional certification authorities (CAs)?

8.  Use of DNSSEC in the Reverse Space
This topic includes signed reverse zones, security products using reverse
DNS lookup for DNSSEC validation?

9.  The Great DNSSEC Panel Quiz
Ever fancied pitting your wits against your colleagues?  Demonstrate your
knowledge and expertise in DNSSEC in our Great DNSSEC Panel Quiz.

In addition, we welcome suggestions for additional topics.

If you are interested in participating, please send a brief (1-2 sentence)
description of your proposed presentation to dnssec-durban-XMYgHUjnkMVWk0Htik3J/w&amp;lt; at &amp;gt;public.gmane.org by
**Monday 27 May 2013.**

We hope that you can join us.

Thank you,

Julie Hedlund

On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Simon McCalla, Nominet UK
Russ Mundy, Sparta/Parsons
Ondřej Surý, CZ.NIC
Lance Wolak, .ORG, The Public Interest Registry
Yoshiro Yoneya, JPRS
Dan York, Internet Society


&lt;/pre&gt;</description>
    <dc:creator>Julie Hedlund</dc:creator>
    <dc:date>2013-05-13T14:49:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2104">
    <title>Measuring DNSSEC Performance.</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2104</link>
    <description>&lt;pre&gt;
from &amp;lt;http://www.potaroo.net/ispcol/2013-05/dnssec-performance.html&amp;gt;:

-----

So the overall result is that if you DNSSEC sign a domain today then some 70% of the received A queries will request DNSSEC additional information, and the traffic level in responses will rise by a factor of 4.5 over traffic levels for an unsigned domain. If every client used DNSSEC validating resolvers then the total traffic levels would increase by a factor of up to 13 over levels associated with an unsigned domain. Obviously, once more, caching of the DNSSEC zone values would have some impact on this number, and a more accurate working projection is that traffic volumes would increase by a factor of between 6 and 13, depending on the zone’s key lifetime and query activity.

For the invalidly-signed domain name the traffic levels in the responses have increased by a factor of 5.5. When the DNSSEC-signatures cannot be validated the client will repeat the query on any alternate DNS resolvers that have been configured. One way to look at this is to compare it to the validly signed domain. DNSSEC-invalidity is observed to increase the total response traffic volume by 20%. But this condition is being encountered by at most 4% of clients. If every client was using resolvers that performed DNSSEC validation then the consequence of key expiration, or any other event that caused the signature information be become invalid, would increase the traffic levels by 500%. In other words, the total traffic volume would be 6 times greater than that of a validly signed domain, or some 96 times higher than that of a validly signed domain, when using a single name server in the case where none of the responses are cached in DNS resolvers.

-----

-----------------------------------------------------------------------
Roland Dobbins &amp;lt;rdobbins-rd7evPjynkNeoWH0uzbU5w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; // &amp;lt;http://www.arbornetworks.com&amp;gt;

  Luck is the residue of opportunity and design.

       -- John Milton

&lt;/pre&gt;</description>
    <dc:creator>Dobbins, Roland</dc:creator>
    <dc:date>2013-05-12T05:06:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2103">
    <title>DNS-OARC Spring Workshop Final Information</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2103</link>
    <description>&lt;pre&gt;Our Dublin workshop is proving to be packed, from both a content and
attendance point of view.

Our main themed session for the workshop is on the ever-topical subject
of open resolver-based attacks, with 4 speakers, chaired by Merike Kaeo
on Sunday afternoon. Much of Monday morning is devoted to talks and
operational experience and measurement of DNSSEC. We have a number of
talks on various approaches to DNS monitoring, and several research talks.

My new colleague William Sotomayor will be reporting on his progress
rejuvenating OARC's infrastructure, and I will be speaking about the
recent member survey, board retreat, and ensuing OARC development plan.
Note that although these talks in the second half of Monday morning are
targetted at and mostly of interest to OARC Members, we are not having a
formally closed members-only session this time.

Please note that the meeting venue is now *full*, and we can't accept
and further registrations or walk-ins. If you registered, please ensure
you pick up your badge when you arrive so you have access to lunch and
the evening social event.

If you didn't register, you can still attend remotely - you can find the
speakers' slides via the agenda at:

  https://indico.dns-oarc.net/indico/conferenceTimeTable.py?confId=0

and we will be webcasting proceedings with help from ICANN at:

  http://icann.adobeconnect.com/dns-oarc/

with jabber remote participation at:

  xmpp:dns-operations-8PHf0o9tX6fUpgmpJlUroZ4u3ZODToM5G8YN2Ja/eVQ&amp;lt; at &amp;gt;public.gmane.org

For on-site connectivity, we'll be using the RIPE meeting wireless
network, look for SSID "ripemtg".

During the Sunday lunch break, Sebastian Castro will be running a PGP
signing session, please check the  with him for keyring details.

At the end of the Sunday (18:30) we have a social event, we're grateful
to OARC members APNIC, NZRS and RIPE External Relations for sponsoring
this, and also INEX and DB Events for helping organise it.

Finally, a big thank you to IEDR for sponsoring and helping with the
meeting, Nominet for sponsoring our coffee breaks, and the RIPE NCC
meeting and Ops teams for providing connectivity.

Look forward to seeing you all in Dublin !

Keith

&lt;/pre&gt;</description>
    <dc:creator>Keith Mitchell</dc:creator>
    <dc:date>2013-05-11T19:35:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2101">
    <title>DNS 9.9.2 open socket error</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2101</link>
    <description>&lt;pre&gt;Hi all,

We have a DNS server bind 9.9.2 on Solaris Generic_147441-24 running on VM. We got errors from DNS server that cannot resolve some domain names. When we checked the logs, the error like this

06-May-2013 13:45:25.566 dispatch: warning: dispatch dd91e50: open_socket(0.0.0.0#2049) -&amp;gt; permission denied: continuing
06-May-2013 13:51:41.421 dispatch: warning: dispatch 1efc7e90: open_socket(0.0.0.0#4045) -&amp;gt; permission denied: continuing

Is this error cause our resolving problem? 

Thank you

Ayca.


&lt;/pre&gt;</description>
    <dc:creator>Ayca Taskin (Garanti Teknoloji</dc:creator>
    <dc:date>2013-05-06T11:25:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2096">
    <title>Multiple A/AAAA RRs associated with an NS RR</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2096</link>
    <description>&lt;pre&gt;Most authoritative servers, and presumably most operators, associate a
single A, AAAA or pair of those two to a single NS RR, but I have seen
cases where this is not true.

For instance, representative of the more common configuration,
example.org has an NS RR of b.iana-servers.net and that name in turn has
one A and one AAAA associated with it.

However, imagine b.iana-servers.net actually maps to multiple A RRs.

I've seen cases where PTRs can get out of whack.

I could imagine server selection or round robin algorithms giving
somewhat unpredictable and potentially suboptimal results.

Perhaps even some issues with an suboptimal set of additional records
being returned.

On the other hand... if the NS names are in different zones, perhaps
this adds some reliability.

I'm curious if anyone is aware of, or can envision, any actual problems
or real benefits with this A/AAAA overloading, for a lack of a better
term since I'm not sure what to call it.

Thanks to my friend Ed Lewis who entertained a version of this question
some time back off-list and began his response in his characteristically
delightful way with "Problems get solved more easily when it's a genius
and an idiot working together".

John
&lt;/pre&gt;</description>
    <dc:creator>John Kristoff</dc:creator>
    <dc:date>2013-05-03T22:15:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2076">
    <title>DNSSEC problem at one.com</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2076</link>
    <description>&lt;pre&gt;Anyone has more technical and factual information about this problem?
Error in .SE, in one.com or in Telia?

http://www.one.com/en/info/profile

Update - April 27, 2013 12:52 PM CET

Telenor have solved the issues, but unfortunately some customers using Telia and Bredbandsbolaget as internet provider can still have difficulties accessing domains where DNSSEC are enabled. We are in a dialog with Telia and Bredbandsbolaget, and we have requested them to look into this problem.

Please read more information below, regarding how to work around the issue, by using Google's DNS service.

We apologize for the inconvenience this is causing, and hope for your understanding.

DNSSEC - .se domains - April 26, 2013 11:09 AM CET

Some customers having .se domains are experience problems with access to their domain.

.SE, the company responsible for the .se domain, has made an initiative to increase the security for the Swedish top-level domain, and have therefore implemented DNSSEC and asked us (One.com) to rollout DNSSEC on .se domain hosted by us.

This was done successfully on a group of .se domains during the last 24 hours, and should not have any impact on our customer’s access to their domain other than increasing the DNS (domain name server) security.

Unfortunately we have found out that some customers using Bredbandsbolaget and Telenor as internet provider can have difficult with accessing domains where DNSSEC are enabled, where we have requested them to look into this problem.

To limit the impact, then we are also in talk with .SE and are working on a temporary solution to disable DNSSEC.

We would also recommend customers who have this problem to change DNS server to 8.8.8.8. which is a name servers powered by Google which is fully compatible with DNSSEC.

Guides to change DNS:

Mac: http://www.computerhope.com/issues/ch001161.htm

Windows: http://www.computerhope.com/issues/ch001161.htm#1

For information about DNSSEC:

http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

We apologize for any inconvenience and hope for your understanding.
_______________________________________________
dns-operations mailing list
dns-operations&amp;lt; at &amp;gt;lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs&lt;/pre&gt;</description>
    <dc:creator>Stephane Bortzmeyer</dc:creator>
    <dc:date>2013-04-27T14:32:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2054">
    <title>DNS Issue</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2054</link>
    <description>&lt;pre&gt;Dears

I wonder if someone can guide me in the direction for troubleshooting my DNS issues.


I work in the regional ISP, we have to DNS servers where it works fine for most of the Domain names but it cannot resolve some others, like dyn.com.


When I try to do dig + trace , below is the output, the txt in red shows that for that specific domain the DNS server cannot resolve it, please guide me to the proper procedure for troubleshooting such problem.




dig dyn.com +trace

; &amp;lt;&amp;lt;&amp;gt;&amp;gt; DiG 9.3.4-P1 &amp;lt;&amp;lt;&amp;gt;&amp;gt; dyn.com +trace
;; global options:  printcmd
.                       518394  IN      NS      j.root-servers.net.
.                       518394  IN      NS      k.root-servers.net.
.                       518394  IN      NS      l.root-servers.net.
.                       518394  IN      NS      m.root-servers.net.
.                       518394  IN      NS      a.root-servers.net.
.                       518394  IN      NS      b.root-servers.net.
.                       518394  IN      NS      c.root-servers.net.
.                       518394  IN      NS      d.root-servers.net.
.                       518394  IN      NS      e.root-servers.net.
.                       518394  IN      NS      f.root-servers.net.
.                       518394  IN      NS      g.root-servers.net.
.                       518394  IN      NS      h.root-servers.net.
.                       518394  IN      NS      i.root-servers.net.
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms

com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
;; Received 497 bytes from 192.58.128.30#53(j.root-servers.net) in 112 ms

dyn.com.                172800  IN      NS      ns1.p01.dynect.net.
dyn.com.                172800  IN      NS      ns3.p01.dynect.net.
dyn.com.                172800  IN      NS      ns2.p01.dynect.net.
dyn.com.                172800  IN      NS      ns4.p01.dynect.net.
;; Received 175 bytes from 192.54.112.30#53(h.gtld-servers.net) in 167 ms



dig: couldn't get address for 'ns1.p01.dynect.net': failure




Thank you

Best Regards
Samir Abid Ali
Core Network Manager
Gorannet ISP
Mobile:07703-587-625
Office:053 5111 000 ext. 1032

&lt;/pre&gt;</description>
    <dc:creator>Samir Abidali</dc:creator>
    <dc:date>2013-04-24T13:06:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2049">
    <title>Signatures expired in 54.in-addr.arpa</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2049</link>
    <description>&lt;pre&gt;The RRSIG records in 54.in-addr.arpa have expired, at 2013-04-19 00:00:30 UTC.

http://dnssec-debugger.verisignlabs.com/54.in-addr.arpa confirms this.

dns-ops-VVaJSnPt7Kc&amp;lt; at &amp;gt;public.gmane.org (SOA.rname for the zone) cc'd.

This particular zone seems to have a jinx on it - it was the one for
which the DS and DNSKEY records got out of step in December 2011.

&lt;/pre&gt;</description>
    <dc:creator>Chris Thompson</dc:creator>
    <dc:date>2013-04-20T19:04:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2047">
    <title>Biggest Fake Conference in Computer Science</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2047</link>
    <description>&lt;pre&gt;We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the 
same paper with a modified title) to WORLDCOMP 2012. This paper 
had numerous fundamental mistakes. Sample statements from 
that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies 
have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. 
See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See 
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. If WORLDCOMP is not fake then why did DBLP suddenly stopped 
listing the proceedings after? 


The status of your WORLDCOMP papers can be changed from “scientific” 
to “other” (i.e., junk or non-technical) at any time. See the comments 
http://www.mail-archive.com/tccc&amp;lt; at &amp;gt;lists.cs.columbia.edu/msg05168.html   
of a respected researcher on this. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and 
try to threaten the critiques of WORLDCOMP. That is, the puppet does all 
his best to get a maximum number of papers published at WORLDCOMP to 
get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP until 2012) has refused to 
provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. WORLDCOMP’13 
will be held at a different resort.


WORLDCOMP will not be held after 2013. 


The paper submission deadline for WORLDCOMP’13 was March 18 and it was 
extended to April 6 and now it is extended to April 20 (it may be extended 
again) but still there are no committee members, no reviewers, and there is no 
conference Chairman. The only contact details available on WORLDCOMP’s 
website is just an email address! Prof. Hamid Arabnia expends the deadline 
to get more papers (means, more registration fee into his pocket!).


Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. 
Reveal the names and affiliations of all the reviewers (for each year) 
and how many papers each reviewer had reviewed on average. We also request 
him to look at the Open Challenge at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

_______________________________________________
dns-operations mailing list
dns-operations&amp;lt; at &amp;gt;lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs&lt;/pre&gt;</description>
    <dc:creator>jimsimpson2-revL73yDgGBWk0Htik3J/w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-04-20T14:25:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2045">
    <title>NANOG 58</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2045</link>
    <description>&lt;pre&gt;::sorry for duplicates::

Greetings folks

Once again we will have DNS Track in NANOG.

There has been lots of recent DNS related discussions going on in many e-mail lists and I am quite sure there will be many great DNS talks in NANOG 58 just like in previous NANOGs.

DNS Track's goal is to bring together the audience who doesn't necessarily want to know all the details of a topic but would like to spend 90 mins listening quick updates from various DNS related subjects and get some crucial information and updates.

If you are interested in talking/presenting in the DNS Track and/or want to help me organize this Track in any way, please contact me off-list. Hopefully we can inform those who do NOT spend much time dealing with DNS about some topics they were not aware.

Once I know the details of the agenda such as time and date of the track, topics that will be covered, i will share this with you.

Mehmet


&lt;/pre&gt;</description>
    <dc:creator>Mehmet Akcin</dc:creator>
    <dc:date>2013-04-18T19:20:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.network.dns.operations/2039">
    <title>[Off-topic] DNS dataset for academic research</title>
    <link>http://comments.gmane.org/gmane.network.dns.operations/2039</link>
    <description>&lt;pre&gt;Hi,

I am looking for a DNS dataset for academic research. I have been
studying .BR DNS dataset (DITL 2008 on DNS-OARC servers), however, I
would like to investigate more recent traffic.

I am a PhD candidate at Federal University of Amazonas (Brazilian
state), and my research concerns how DNS traffic can be used to
identify Botnets.

PS: Sorry if this topic had been answered before
--
Kaio Rafael,
&lt;/pre&gt;</description>
    <dc:creator>Kaio Rafael</dc:creator>
    <dc:date>2013-04-18T15:23:35</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.network.dns.operations">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.network.dns.operations</link>
  </textinput>
</rdf:RDF>
