- dns-wg - mailman.ripe.net

DNS hardware
by Bobby Ölander 12 Aug '05

12 Aug '05

Hello! I'm working at a company called Com Hem AB in Sweden, we are at the moment the biggest cabelnetwork company in Sweden. I have a question that concerns the hardware in the server that should be a primary DNS (even the hardware on the secondary DNS could be nice to know about). What I wonder most about is, should the primary DNS be build with a RAID-system? Or is that not importent of the fact there is a secondary DNS? Respectfully, Bobby Ölander NOC Com Hem AB

5 6

To post to this list
by contact＠internetprogress.org 11 Aug '05

11 Aug '05

To post to this list, my emailadress : contact(a)internetprogress.org Sincerely, Guy Lombart

1 0

[pim@bit.nl: Re: [dns-wg] DNS hardware]
by Pim van Pelt 11 Aug '05

11 Aug '05

Hi, Sorry for duplicates, I group-replied and the reply seems to have went to dns-wg-chair. Here's my original response to Bobby's question: | I have a question that concerns the hardware in the server that should | be a primary DNS (even the hardware on the secondary DNS could be nice | to know about). | What I wonder most about is, should the primary DNS be build with a | RAID-system? Or is that not importent of the fact there is a secondary | DNS? It depends on the software you will be running and the amount of queries per second you plan on answering. In the case of bind(9), disk access is low because the server loads zonedata into memory. Other software products (tinydns, nsd) use mmap()ed files, so they access disk but I don't think it'll be that much, because those pages are mapped into memory if you have enough of it. For the ISP I work for [medium sized ISP in the Netherlands], we have two diskless P4 boxes and they each answer some 100qps. They are not loaded or busy at all, and happen to also serve as DNScache [using djbdns stuff at 500qps] and an SNTP service. nsauth1 up 139+08:53, load 0.17, 0.22, 0.23 FreeBSD/i386 (4.10-RELEASE-p5) nsauth2 up 139+09:09, load 0.03, 0.02, 0.02 FreeBSD/i386 (4.10-RELEASE-p5) nsauth3 up 246+14:55, load 0.05, 0.08, 0.07 FreeBSD/i386 (4.10-RELEASE-p5) The difference in load is because most of our customers use nsauth1 as caching nameserver and nsauth2/nsauth3 hardly ever gets hit. groet, Pim -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

1 0

Delegation checker
by John Payne 29 Jul '05

29 Jul '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have had a long running issue with the delegation checker. I appreciate that I may be unique, but having to get the database manager to help out with (infrequent, admittedly) exception handling is irritating to say the least. The problem is with the PROBLEM_WRONG_REVERSE_MAPPING check. Background. I work for a company that has a very large "non-network". We have lots of islands of infrastructure mainly not on "our" IP space, but provider PA space where we don't control the rDNS (I'm not saying we couldn't, but we only run into issues with RIPE - so the pay off doesn't seem to be worth the effort). The PROBLEM_WRONG_REVERSE_MAPPING is assigning 4 points for each nameserver missing "correct" rDNS. With 8 nameservers, that's 12 points more than failure. Now, I could work around this by only submitting 4 nameservers, but that seems contrary to the goal of having a stable in-addr.arpa delegation. The description for PROBLEM_WRONG_REVERSE_MAPPING refers to RFC1912, section 2.1 which says "should", not "must", so such a high penalty for no technical problem does not seem valid. I can't think of a truely operational problem caused by missing rDNS on an auth nameserver. I would like to propose either changing this to a 0 point Information, or a 1 point Warning. Thanks for listening John (BTW, PROBLEM_MAILCHECK_CONNECTION_FAILED also doesn't seem to be doing an MX lookup before attempting a connection. The A record for $company.com does not point to a mailserver which is why RIPE gets connection refused... but the MX records are correctly set up). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFC6lRr3TsPuH6oTJ8RAiXnAKDbgkGdV6+OIQ2FP/wvKsZWcSNF8gCghScv Ry07wV96ZJT7Ty/DGa10pjk= =IRKq -----END PGP SIGNATURE-----

2 2

Policy development process for deployment of Secure DNS
by Jim Reid 08 Jul '05

08 Jul '05

<wg chair hat on> This announcement is required as part of the policy development process described in: http://www.ripe.net/ripe/draft-documents/pdp.html Olaf Kolkman sent a policy proposal to the DNS-WG list on Tuesday, July 5th. On behalf of the DNS WG co-chairs, I would like to invite your comments on this proposal. This invitation formally opens the policy discussion phase that is to end no sooner than 4 weeks from today: ie August 5th, 2005. The policy proposal is posted at: http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html. Discussion takes place on the dns-wg(a)ripe.net list. I would also like to use this policy proposal to get the WG to formally endorse the NCC's efforts on DNSSEC deployment. To the best of my knowledge the WG has never requested that the NCC undertake any DNSSEC activities. [Of course the DISI project has been voted on in the annual Activity Plan for a couple of years now.] So I suppose as we go forward, this is as good a time as any for the WG to formalise this work. <\wg chair hat on>

1 0

DNSSEC deployment on the reverse tree.
by Olaf M. Kolkman 07 Jul '05

07 Jul '05

[Apologies for duplicates] Dear Colleagues The RIPE NCC has been involved with the development of the DNSSEC protocol. Now that the protocol has become available, we plan to implement DNSSEC on our domains in the reverse DNS tree. The deployment of DNSSEC is the second and last phase of the Reverse DNS restructuring project. You can find more information about this project at: http://www.ripe.net/rs/reverse/dnssec/index.html To implement DNSSEC, we propose extending the policy for Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region. You can find the proposed policy at: http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html. We welcome your feedback on this poposal before 1 August 2005. Please send your comments to the DNS Working Group Mailing List. We are also introducing two new procedures: "DNSSEC Key Maintenance Procedure" http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html and "Procedure for Requesting DNSSEC Delegations" http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html Your feedback on these drafts is also welcome, again please send this to the DNS Working Group Mailing List. As part of the "Procedure for Requesting DNSSEC Delegations" we plan to add a "ds-rdata:" attribute to DOMAIN objects. Regards Olaf M Kolkman New Projects, RIPE NCC.

3 6

Re: [dns-wg] Followup to IANA TLD delegation problem
by Marcel Schneider 23 Jun '05

23 Jun '05

On Friday, 10 Jun 2005, Doug Barton writes: Dear Doug Thanks for responding to Jim's questions. Reading your mail I still have difficulties understanding two issues: a) You state in [1] that after editing the root zone, VerSign experienced an "unexpected result". What exactly was the result what caused it ? Whould also appreciate if you could elaborate on how VerSign was able to fix this "unexpected result". b) When this "unexpected result" was regarded by IANA staff as temporary and as having minimal operational impact, why was AFNIC then sent this response to their application: "IANA is no longer adding additional examples of host names in delegation records where multiple host names point to the same IP address". The "no longer" suggests a policy change. Why did IANA not just say: "Folks we have a problem here, wait a moment until we've fixed it" ? Marcel > Thanks again for the opportunity to discuss these issues. I hope that the > group finds these answers satisfactory. We are of course happy to discuss > this in further detail if desired. > [1] What was the nature of the technical problem that prevented > multiple names in for an IP address and how was it resolved? > In November of 2004 AFNIC asked to have several hostnames added to the root > zone that resolved to the same IPv4 addresses as hostnames that already > existed. When VeriSign edited the root zone to include these new names, an > unexpected result occurred. In some of the TLDs that had the pre-existing > hostnames for these servers, the new hostnames appeared in the delegations > inappropriately. This problem was identified within several hours of the > zone going live by VeriSign staff, as well as at least one member of the > ccTLD community. The VeriSign and IANA staffs communicated immediately about > this issue, and the specific problem related to this request was fixed > manually by VeriSign in the next zone revision after it was identified. > Because in any pair of hostnames affected by this result the IPv4 address > was the same, the operational impact of this problem was minimal, if it was > identifiable at all. > [2] Why was there no announcement that this problem existed? > The specific problem applied only to new instances of duplicate names, it > did not affect existing duplicate names for which no change was in process. > The total number of these duplicate hostnames is very small relative to the > rest of the zone (less than 3%), and requests to modify domains which have > these hostnames in their delegations are rare. There were no instances of > such a request from November of 2004 through March of 2005, when AFNIC > submitted the request for the RE ccTLD. > Because the issue affected only a small number of TLDs and name server > operators, IANA staff chose to address the issue with those individuals > directly. Often TLD managers appreciate such specific cases being dealt with > on a personal level. > [3] Are safeguards now in place to prevent this sort of problem recurring? > Yes. VeriSign has informed us that the general problem which produced the > original unexpected result has now been corrected. Additionally, IANA staff > have enhanced efforts to monitor the "live" root zone from several different > servers, and use that data to proactively monitor the results of change > requests. > [4] What procedures does IANA (or ICANN?) have to make sure that changes > to the TLD delegation process or problems with that process are properly > communicated to its stakeholders? > The procedure that IANA uses to communicate changes in the TLD delegation > process follows the typical ICANN formula of involving key stakeholders at > early stages, opening proposals up for public comment, incorporating > appropriate comments into the final version, and posting the procedure for > its stakeholders. A relevant example of this process is the "Delegation Data > Procedure," which is posted at > http://www.iana.org/procedures/delegation-data.html. > Specific problems in the root management process are evaluated on a case by > case basis. When necessary, there is a mailing list composed of the contact > addresses for each of the TLD managers that can be utilized for any issue of > wide interest to the TLD manager community. As noted above, cases which > affect one, or a few TLDs are often dealt with on a one-to-one basis, with > the appreciation of the relevant TLD manager(s). > [5] Were those procedures followed for this incident? If not, why not? > The procedure for communicating changes to the TLD delegation process was > not followed in this specific case because there was no formal change of > process. > The specific problem which produced the delay in processing AFNIC's request > for RE was always understood to be temporary. As discussed above, rather > than widely disseminate the information about this issue to the TLD manager > community, IANA staff chose to communicate directly with those affected by > the issue. > ICANN's goal, as always, is to cooperate with the TLD managers in > implementing the changes they feel are appropriate for their TLDs, while > also maintaining the stability of the DNS. We regret if our cautious > handling of this particular request, or the timing of our responses to the > group's reasonable questions, has caused any undue confusion in the DNS > community about ICANN's dedication to that goal. We welcome comment and > discussion on these topics. > I am enclosing below some information about the current (at this writing, > 2005061000) root zone that may be relevant to this discussion. The first > part is the complete list of IPv4 addresses that have multiple hostnames > associated. There are no IPv6 addresses with multiple hostnames. The second > part is a compilation of statistics about the current zone. > Regards, > Doug > 128.112.129.15: dns.princeton.edu c.ext.nic.fr > 192.134.0.49: c.nic.fr ns3.nic.fr > 192.36.144.116: slave.sth.netnod.se slave1.sth.netnod.se > 192.93.0.1: a.nic.fr ns1.nic.fr > 192.93.0.4: b.nic.fr ns2.nic.fr > 193.176.144.6: e.ext.nic.fr ns3.domain-registry.nl > 193.51.208.13: dns.inria.fr a.ext.nic.fr > 204.152.184.64: ns-ext.vix.com ns-ext.isc.org > 204.74.112.1: tld1.basicfusion.net tld1.ultradns.net ud1.ns.net.ua > 204.74.113.1: tld2.basicfusion.net tld2.ultradns.net > Statistics > ========== > Number of gTLDs: 15 > Number of ccTLDs: 245 > Total number of TLDs: 260 > Number of IPv4 hosts: 798 > Number of IPv4 addresses: 798 > Number of IPv6 hosts: 40 > Number of IPv6 addresses: 41 > TLDs with IPv6 glue: 50 > Total TLD name server hosts: 797 > -- > Doug Barton > General Manager, The Internet Assigned Numbers Authority

5 5

Re: [dns-wg] Followup to IANA TLD delegation problem
by Doug Barton 15 Jun '05

15 Jun '05

Jim, Thanks again for the opportunity to discuss these issues. I hope that the group finds these answers satisfactory. We are of course happy to discuss this in further detail if desired. [1] What was the nature of the technical problem that prevented multiple names in for an IP address and how was it resolved? In November of 2004 AFNIC asked to have several hostnames added to the root zone that resolved to the same IPv4 addresses as hostnames that already existed. When VeriSign edited the root zone to include these new names, an unexpected result occurred. In some of the TLDs that had the pre-existing hostnames for these servers, the new hostnames appeared in the delegations inappropriately. This problem was identified within several hours of the zone going live by VeriSign staff, as well as at least one member of the ccTLD community. The VeriSign and IANA staffs communicated immediately about this issue, and the specific problem related to this request was fixed manually by VeriSign in the next zone revision after it was identified. Because in any pair of hostnames affected by this result the IPv4 address was the same, the operational impact of this problem was minimal, if it was identifiable at all. [2] Why was there no announcement that this problem existed? The specific problem applied only to new instances of duplicate names, it did not affect existing duplicate names for which no change was in process. The total number of these duplicate hostnames is very small relative to the rest of the zone (less than 3%), and requests to modify domains which have these hostnames in their delegations are rare. There were no instances of such a request from November of 2004 through March of 2005, when AFNIC submitted the request for the RE ccTLD. Because the issue affected only a small number of TLDs and name server operators, IANA staff chose to address the issue with those individuals directly. Often TLD managers appreciate such specific cases being dealt with on a personal level. [3] Are safeguards now in place to prevent this sort of problem recurring? Yes. VeriSign has informed us that the general problem which produced the original unexpected result has now been corrected. Additionally, IANA staff have enhanced efforts to monitor the "live" root zone from several different servers, and use that data to proactively monitor the results of change requests. [4] What procedures does IANA (or ICANN?) have to make sure that changes to the TLD delegation process or problems with that process are properly communicated to its stakeholders? The procedure that IANA uses to communicate changes in the TLD delegation process follows the typical ICANN formula of involving key stakeholders at early stages, opening proposals up for public comment, incorporating appropriate comments into the final version, and posting the procedure for its stakeholders. A relevant example of this process is the "Delegation Data Procedure," which is posted at http://www.iana.org/procedures/delegation-data.html. Specific problems in the root management process are evaluated on a case by case basis. When necessary, there is a mailing list composed of the contact addresses for each of the TLD managers that can be utilized for any issue of wide interest to the TLD manager community. As noted above, cases which affect one, or a few TLDs are often dealt with on a one-to-one basis, with the appreciation of the relevant TLD manager(s). [5] Were those procedures followed for this incident? If not, why not? The procedure for communicating changes to the TLD delegation process was not followed in this specific case because there was no formal change of process. The specific problem which produced the delay in processing AFNIC's request for RE was always understood to be temporary. As discussed above, rather than widely disseminate the information about this issue to the TLD manager community, IANA staff chose to communicate directly with those affected by the issue. ICANN's goal, as always, is to cooperate with the TLD managers in implementing the changes they feel are appropriate for their TLDs, while also maintaining the stability of the DNS. We regret if our cautious handling of this particular request, or the timing of our responses to the group's reasonable questions, has caused any undue confusion in the DNS community about ICANN's dedication to that goal. We welcome comment and discussion on these topics. I am enclosing below some information about the current (at this writing, 2005061000) root zone that may be relevant to this discussion. The first part is the complete list of IPv4 addresses that have multiple hostnames associated. There are no IPv6 addresses with multiple hostnames. The second part is a compilation of statistics about the current zone. Regards, Doug 128.112.129.15: dns.princeton.edu c.ext.nic.fr 192.134.0.49: c.nic.fr ns3.nic.fr 192.36.144.116: slave.sth.netnod.se slave1.sth.netnod.se 192.93.0.1: a.nic.fr ns1.nic.fr 192.93.0.4: b.nic.fr ns2.nic.fr 193.176.144.6: e.ext.nic.fr ns3.domain-registry.nl 193.51.208.13: dns.inria.fr a.ext.nic.fr 204.152.184.64: ns-ext.vix.com ns-ext.isc.org 204.74.112.1: tld1.basicfusion.net tld1.ultradns.net ud1.ns.net.ua 204.74.113.1: tld2.basicfusion.net tld2.ultradns.net Statistics ========== Number of gTLDs: 15 Number of ccTLDs: 245 Total number of TLDs: 260 Number of IPv4 hosts: 798 Number of IPv4 addresses: 798 Number of IPv6 hosts: 40 Number of IPv6 addresses: 41 TLDs with IPv6 glue: 50 Total TLD name server hosts: 797 -- Doug Barton General Manager, The Internet Assigned Numbers Authority

4 3

[Fwd: [centr-fm] Re: IANA TLD delegation issue]
by Kim Davies 13 Jun '05

13 Jun '05

Dear all, Olivier Guillard of AFNIC has described in the attached document the details of their attempts to redelegate their domains. It is a useful summary of the issue as they experienced it. kim -- Kim Davies, Council of European National Top Level Domain Registries Avenue Louise 327, B-1050 Brussels; Tel. +32 2 627 5550

10 31

Re: [dns-wg] Followup to IANA TLD delegation problem
by Jim Reid 07 Jun '05

07 Jun '05

>>>>> "Doug" == Doug Barton <doug.barton(a)icann.org> writes: Doug> Jim, We're happy to provide answers to these Doug> questions. Given that Monday is a holiday in the US, may I Doug> suggest that we will provide answers to the questions listed Doug> on Tuesday 31 May unless you or the WG indicate that more Doug> time is needed for you to formulate the list? Hi Doug. You'll have seen that there's been no detailed discussion in the last week or so on the mailing list about this issue. Most of the comments have seemed to echo the questions that were in my earlier mail. Assuming that you're back from paternity leave, I think it would now be helpful for these questions to be answered. This would allow us to finally resolve this issue and hopefully prevent it flaring up again in some other forum. Here are those questions once again: [1] What was the nature of the technical problem that prevented multiple names in for an IP address and how was it resolved? [2] Why was there no announcement that this problem existed? [3] Are safeguards now in place to prevent this sort of problem recurring? [4] What procedures does IANA (or ICANN?) have to make sure that changes to the TLD delegation process or problems with that process are properly communicated to its stakeholders? [5] Were those procedures followed for this incident? If not, why not?

2 1