From dwmalone at maths.tcd.ie Thu Jul 1 16:54:43 2004 From: dwmalone at maths.tcd.ie (David Malone) Date: Thu, 01 Jul 2004 15:54:43 +0100 Subject: [dns-wg] AAAA lookup misbehaviour Message-ID: <200407011554.aa39587@salmon.maths.tcd.ie> At the last RIPE meeting I was given an action item: Write up a draft RIPE document summarizing the observations made regarding AAAA resolution problems. Circulate to the list, initiate discussion what to, i.e. whom to approach with the list of errors/problems seen. I checked with Peter, and he says the documents are pretty freeform, so I've written a few paragraphs, included below. David This document is a short description of problems with certain DNS systems that have come to light with the deployment of IPv6 enabled software. --- One of the services that DNS provides is a facility for mapping host names to IPv4 addresses. This is probably the most common used service that DNS provides, and is achieved requesting a record of type "A" for the host name. Records of type A can only store an IPv4 address, and so with the introduction of IPv6, a new record type, AAAA has been introduced. It is becoming increasingly common for software to first issue a request of type AAAA, and if no record of that type is found then to issue a request for a record of type A. A request for a record of type AAAA causes no problems for most DNS servers, however some DNS servers have been found that have problems answering queries not of type A. The technical details of these problems are explained in the IETF draft document draft-ietf-dnsop-misbehavior-against-aaaa-01.txt. In 2004, about 0.5--1% of name servers seem to have to have a problem of this nature. The end result of these issues is that connecting to a site using a problematic name server may be impossible, intermittent or significantly delayed. To prevent introducing more DNS servers with such issues, testing of new DNS equipment should include checking that the response for records is in accordance with the RFCs. As DNS load balancing software has often fallen foul of these problems, particular care should be taken in testing and validating such systems. The fact that problematic nameservers exist is in itself a problem. Where these issues cause direct inconvenience, the maintainers of the server and the maintainers of the DNS data should be notified to allow a normal service to be restored. However, often it is difficult for end users to identify the source of these problems, (for example, where an image embedded in a web page being served from a host with a problem hostname). It is also possible to automatically produce lists of names and nameservers that exhibit these problems. Clearly it is possible to automatically mail hostmaters or to publish "hall of shame" lists based on such data. It is unclear if such actions would achieve any useful effect, as service maintainers are usually primarily concerned about complaints directly from paying users! From alvaro.vives at consulintel.es Fri Jul 2 13:42:55 2004 From: alvaro.vives at consulintel.es (Alvaro Vives) Date: Fri, 2 Jul 2004 13:42:55 +0200 Subject: [dns-wg] AAAA lookup misbehaviour References: <200407011554.aa39587@salmon.maths.tcd.ie> Message-ID: <016701c46029$b8b45c50$ce00000a@consulintel.es> Hi David, Only problems with DNS servers will be covered? I mean, won't you include something related with resolvers. I can send some info regarding a bug in the resolver library of Windows XP+SP1 and Windows 2003, which causes a failure when a domain name has A and AAAA records. Best regards, Alvaro Vives Consulintel ----- Original Message ----- From: "David Malone" To: Cc: "Peter Koch" ; Sent: Thursday, July 01, 2004 4:54 PM Subject: [dns-wg] AAAA lookup misbehaviour > At the last RIPE meeting I was given an action item: > > Write up a draft RIPE document summarizing the observations made > regarding AAAA resolution problems. Circulate to the list, > initiate discussion what to, i.e. whom to approach with the list > of errors/problems seen. > > I checked with Peter, and he says the documents are pretty freeform, > so I've written a few paragraphs, included below. > > David > > > > This document is a short description of problems with certain DNS > systems that have come to light with the deployment of IPv6 enabled > software. > > --- > > One of the services that DNS provides is a facility for mapping > host names to IPv4 addresses. This is probably the most common used > service that DNS provides, and is achieved requesting a record of > type "A" for the host name. Records of type A can only store an > IPv4 address, and so with the introduction of IPv6, a new record > type, AAAA has been introduced. It is becoming increasingly common > for software to first issue a request of type AAAA, and if no record > of that type is found then to issue a request for a record of type > A. > > A request for a record of type AAAA causes no problems for most DNS > servers, however some DNS servers have been found that have problems > answering queries not of type A. The technical details of these > problems are explained in the IETF draft document > draft-ietf-dnsop-misbehavior-against-aaaa-01.txt. In 2004, about > 0.5--1% of name servers seem to have to have a problem of this > nature. The end result of these issues is that connecting to a > site using a problematic name server may be impossible, intermittent > or significantly delayed. > > To prevent introducing more DNS servers with such issues, testing > of new DNS equipment should include checking that the response for > records is in accordance with the RFCs. As DNS load balancing > software has often fallen foul of these problems, particular care > should be taken in testing and validating such systems. > > The fact that problematic nameservers exist is in itself a problem. > Where these issues cause direct inconvenience, the maintainers of > the server and the maintainers of the DNS data should be notified > to allow a normal service to be restored. However, often it is > difficult for end users to identify the source of these problems, > (for example, where an image embedded in a web page being served > from a host with a problem hostname). > > It is also possible to automatically produce lists of names and > nameservers that exhibit these problems. Clearly it is possible to > automatically mail hostmaters or to publish "hall of shame" lists > based on such data. It is unclear if such actions would achieve > any useful effect, as service maintainers are usually primarily > concerned about complaints directly from paying users! > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From colm at stdlib.net Sat Jul 3 00:13:43 2004 From: colm at stdlib.net (Colm MacCarthaigh) Date: Fri, 2 Jul 2004 23:13:43 +0100 Subject: [dns-wg] AAAA lookup misbehaviour In-Reply-To: <016701c46029$b8b45c50$ce00000a@consulintel.es> References: <200407011554.aa39587@salmon.maths.tcd.ie> <016701c46029$b8b45c50$ce00000a@consulintel.es> Message-ID: <20040702221342.GA20499@castlerea.stdlib.net.> On Fri, Jul 02, 2004 at 01:42:55PM +0200, Alvaro Vives wrote: > Hi David, > > Only problems with DNS servers will be covered? I mean, won't you > include something related with resolvers. > > I can send some info regarding a bug in the resolver library of > Windows XP+SP1 and Windows 2003, which causes a failure when a domain > name has A and AAAA records. There's also the really-annoying "getnaneinfo() can't handle IPv4-mapped-IPv6 addresses" problem that creeped into some BSD code (most notably OS X resolver library) and lately glibc through some ancient ISC code people blindly-copied I think. This seems to be the most common problem on *nix platforms anyway, luckily enough it's easily work-aroundable, for an example work-around see: http://cvs.apache.org/viewcvs.cgi/apr/network_io/unix/sockaddr.c?view=markup Workaround description: Test the address against IN6_IS_ADDR_V4MAPPED, and setup a (IPv4) sockaddr_in structure based on the last 32-bits of the mapped address, and resolve it instead. That's about the only big problem I've seen in any wide deployment with APR which has been used with Apache 2 for over 2 years now. -- Colm MacC?rthaigh Public Key: colm+pgp at stdlib.net From pk at TechFak.Uni-Bielefeld.DE Sun Jul 4 22:31:53 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Sun, 04 Jul 2004 22:31:53 +0200 Subject: [dns-wg] draft minutes from RIPE 48 DNS WG sessions Message-ID: <200407042031.i64KVro15089@grimsvotn.TechFak.Uni-Bielefeld.DE> Dear all, please find below the draft minutes for our RIPE 48 sessions. Thanks to Timur Bakeyev and Alessandro Bassi from the RIPE NCC for being the scribes. Please read these minutes and send in any necessary corrections either to the list or, if minor, to the chairs at dns-wg-chair at ripe.net. We plan to have the minutes taken to the wg's files by July, 25th. There's also an action items list at http://www.ripe.net/ripe/wg/dns/action-list.html -Peter ======================================================== RIPE Meeting: 48 Working Group: DNS Working Group Status: 2nd Draft Revision Number: 3 * content to the Chair of the working group. * format to webmaster at ripe.net. ======================================================== DNS Working Group, Session 1 (DRAFT) RIPE 48 Amsterdam Date: Tuesday, 4 May 2004 Time: 16:00 - 17:30 Location: Grand Ballroom Chair: Jim Reid Scribe: Timur Bakeyev, RIPE NCC - Administrivia. Introduction Session is going to be Web casted as well as reflected in Jabber. Request to participants to hold their question till the end of presentation. Thanks to Nominet, who sponsored the chair of this group. Swap of the presentations: Instead of "DNSSEC forum" by Suzanne Woolf -> "DNS an MCI, another type of large DNS server" by Andre Koopal. - "Proposed new charter", Peter Koch http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-charter.pdf The DNS Working Group discusses current DNS related issues in technology and operations. The WG encourages deployment of DNS and DNS-related protocol components by collecting experience and documenting current practice and recommendations. It therefore provides a mechanism for exchanging practical and operational experience with organizations like CENTR and the IETF. The WG discusses DNS software implementations, especially security and scalability aspects as well as performance and interoperability considerations. DNS quality and other factors that may affect the stability of the DNS system are also discussed by the WG. The DNS WG provides a forum for the Registry and Registrar community. It discusses the technical and operational issues arising from registration policies with a specific focus on the deployment of new and emerging features. Charter was approved by the meeting. - "CENTR news", Kim Davies; CENTR http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-centr.pdf - "Implementation of the BACK ORDER service", Andrzej Bartosiewicz; NASK http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-backorder.pdf This will be launched on 1st June, 2004. System of options - similar to stock exchange options. - "EPP implementation", Patrycja Wegrzynowicz; NASK http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-backorder.pdf XML based Extensive Provision Protocol Q: Can you explain the slide: Registrar buys option for the Registrant. What are the terms used? A: Registrar is the agent of Registrant. Q: (Jim) What is the reaction of the customers on the new schema and how Registrars like it? A: As for Registrants, they hardly even notice the change. It's more attractive to the Registrars. They are quite happy :) - "Deploying IDNs in the .no domain", Jarle Greipsland; NorID. http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-idns-no.pdf Q: (Jaap) What do you exactly register in your forms - UNICODE, Punycode or just US encoding? A: When register you have to fill out both in the forms. On update you can supply any of them. Q: And what is your Whois server accepts? A: It is either US-ASCII, ISO-Latin1 or UTF8. Q: And the input for the request? A: US-ASCII or Latin1 by default, but you can supply switch to use UTF8. Q: (Carsten) Speaking about legal terms - what is registration contract about? Is it about IDN in UTF8 or in Punycode? A: Both versions are on contract. Q: So, the contract actually is about bundle of two names? A: Yes, both names are defined there(Get two for the price of one:) - "IDN deployment in Germany", Marcos Sanz; DENIC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-idn-de.pdf Q: (Peter) That binary queries, you talked about - did you take a look onto second level labels or all the labels? A: All the labels(of course in .de) Q: And for those queries your DNS server received - did you try to cross check whether that binary, UTF, Latin1 names, what ever you found there - were that names actually registered within .de? A: I didn't do it systematically, but yes, most of them there registered? Q: Question remains, what names where queried before they have chance to be registered? A: Random words, general terms... In the last week we saw, that people mostly tried to reach that MAY exist on their opinion. - ".info support for German script", Desiree Miloshevic; Afilias http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-idn-launch.pdf Q: There have been reports, that there is a project to make IDN available without software upgrade? A: That was misinterpretation of our announces in the press. C: (Jaap) Charset names, used for IDNs should be standardized, possibly through the IANA or other Internet official bodies... - "DNS at MCI", Andre Koopal; MCI http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-mci.pdf Q: (Peter) You are acting as a secondary for customers. What happens when primary(at your customer) disappears? That should lead to the lame delegations and query storms... A: We do remove them from the configs after certain amount of time. No special actions are taken against query storms, though. C: (Jaap) You've said, that you don't use Bind 9 for NL TLD, because it's too picky about the standards. But that's the goal - to enforce standards for those lame delegations! Q: (Olaf) Are you sure that Bind 9 doesn't accept '/' in the domain names? A: Not really, maybe some other quite popular symbol, but the problem exists.. Q: (Jim) Are you making efforts to move to Bind 9? A: Not right now, at least. C: (Peter) there is clearly problem with disappearing customers for DNS integrity. Registrars refuse to remove them on ISPs requests. What can be done in such situation? What is the common practice? Would it be OK to make it an action point for WG? R: (Jim) That's a good idea! Peter, you've just volunteered to bring in to the DNS WG :) [ACTION 48.1] on Peter Koch: Collect experience with lameness problems, initiate BCP style document and wishlist for support by TLD registries. ======================================================== DNS Working Group, Session 2 (DRAFT) RIPE 48 Amsterdam Date: Thursday, 6 May 2004 Time: 9:00 - 12:30, Location: St. Johns II Chair: Peter Koch (09:00 - 10:30), Jim Reid (11:00 - 12:30) Scribe: Alessandro Bassi, RIPE NCC - "IETF Reports", Sam Weiler; TIS Labs http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-ietf.pdf Last IETF was held in Seoul, apparently was quite "boring". Next meeting in August, in San Diego. DNS discovery for IPv6: a summary comparing the alternatives must be done before august, otherwise the item will be removed. DNSOP: business as usual, several drafts in progress, several ones stopped or in stand by. DNSEXT: 9 open drafts DNSSEC: No recent problems. It has to be noted that there are no major protocol issues in the last year DNSEXT: most milestones are advanced to draft standards. There is an RFC 3597 interoprability testing coordinated by Jakob Schlyter Mailing list: https://www.rfc.se/mailman/listinfo/interop3597 or interop3597-request at rfc.se - "K-Root operations update", Dave Knight; RIPE NCC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-kroot-update.pdf Status: Global instances are in London and A'dam. Recently two more secondary have been installed in Frankfurt and Athens. Web site has been renewed completely, and a stats page has been added. More stats will come in the near future. The current query load is 7000 queries/second. Of these, the great majority is directed to London and Amsterdam. Future plans: - to have 4 more instances of primary servers, two in the US and two in Asia. - to deploy IPv6. Q: (Jim) Has any traffic analysis been done? Are the Greeks using the Athens server? A: Those kind of stats will be available in a couple of months. - "Reverse DNS status report", Olaf Kolkman; RIPE NCC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-rdns-update.pdf New reverse DNS, for more fine-grain control, multiple interfaces, and simplification of policies. Today, because of the current policies, there might be inconsistencies and confusion. Policies will change drastically. Status: the cleanup (prerequisite) was made the first week of April. April 26, the new interface and new policy were put live. Marvin will die the 1st of July. the DNSSEC implementation has been deferred. In the new policy, there is no need for assignment (as before), and anybody authorized can do the Rev DNS. Another change is mnt-by, which becomes mandatory. When submitting the request, points will be added for warnings and errors; over a certain limit, the request will be rejected. Q: (Jim) Any plans to introduce TSIG ... A: No plans Q: Do people care about it? Why not? A: (Peter): Zone transfer restrictions are useless anyway for most zones. Restrictions can be IP based. [ACTION 48.2] An action item was created on Mans Nilsson to write up a proposal for the use of TSIG for zone transfers, when ns.ripe.net acts as a secondary. [ACTION 48.3] Olaf Kolkman was kindly asked to send to the list a pointer to the predelegation checks currently applied and to initiate review of those checks and, if necessary, propose changes. - "DNS-MODA", Jim Reid http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-moda.pdf There is a growing frustration with the IETF process, something different is needed. Something similar to what W3C is, so a W3C for DNS, no profit, impartial. MODA will not be a standards-making body, or introduce proprietary solutions, but will work with IETF to improve the current procedures. Q: (Geoff Huston) This is alien to what IETF does. IETF also hates Intellectual Rights problems, and being considered like a rubber stamp to somebody else's solution, especially if it's half-baked ideas. IETF must discuss things. A: The idea is to speed things up, not to have IETF as rubber stamp body. The work that comes out of MODA will be well-thought out and shouldn't be half-baked. Q: (Geoff Huston) IETF has a bad record in working with industry. IETF task is to work on new things; the risk is exacerbating problems and making alliances outside. Q: (Patrik) W3C is not a good example. For instance, let's take HTTP (IETF) and XML (W3C), there were lots of problems not to make the same thing twice and work on the same issues. Also, what is the decision making process of MODA? It is not clear at the moment. A: True enough: those processes will be determined by the membership. Q: (Rob Blokzijl) I agree in what Patrick just said, In IETF there's an open, unconditional participation. MODA is more like a closed Club. MODA is needed, but it's a bad idea to throw out the free participation. some re-thinking is needed. Q: (Patrik Faltstrom) If there is a need for MODA, then IETF does not work. You have to say it clearly. A: we are trying to to be collaborative and cooperative, not seeking confrontation. . Q: (Rob Blokzijl) There is no logo yet? And, what is the IETF reaction to this idea? A: The important thing was to announce MODA at this meeting and so start the efforts to recruit members. The web site and logo will come later. Discussions have been held with the IETF about MODA for some time. While there's been no formal response yet, the signs are good. Though both parties will need to see how things work out in practice. - "DNS AAAA measurements: How many sites have problems with IPv6",David Malone; CNRI http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-malone.pdf Q: (Jim) Delegation -> capture the info and document it. Write a document about how to avoid config problems. [ACTION 48.4]: David agreed to write a document about this for the WG to consider. - "6over4 reverse Delegation",Geoff Huston; ICANN http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-sixxto4.pdf Individual draft submitted. Keith Moore submitted also some work in the past, with ideas ranging from reasonable to bizarre. Q: (Bernard Tuy) which kind of draft did you submit? A: Individual submission. Not against all the work that has already been done, but there has been a request to the reverse delegation community to do some more work on it. - "Reverse delegation in ip6.int", Andrei Robachevsky; RIPE NCCC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-reverse-ipv6.pdf Q: (Peter) You suggested to remove ip6.int delegation. What is the current load? A: around 3 queries per minute. == BREAK == - "ISC News", Joao Damas; ISC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-isc.pdf Advancement on Bind 9.3 Q: (Bernard Tuy) What does OARC mean? A: Operation Analysis Research Centre. Q: (Jim) What is the timescale for the release of 9.3? Does it depend on IETF work on DNSSEC? A: No, it does not. It will probably be next week. NLNet update - "DNSSEC forum",Suzanne Woolf; ISC http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-dnssec-roadmap.pdf DNSSEC specs are done, but deployment is less formal and less well documented. There are problems in deployment. Privacy issues also still have to be tackled. Q: (Peter Koch) You mentioned a discussion of zone walking, which may be considered a deployment obstacle. Any solutions? A: Not yet. We are identifying issues but we don't know how serious they are and what needs to be done. A: (Olaf Kolkman) A protocol change at this point would mean that we'll be back to the drawing board. Changing the protocol would mean a delay of one year. There is no obvious solution in sight. - "Query load variation on ccTLD servers during delegation phases", Mans Nilsson; KTH http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-f2f.pdf Problems, delay introduced because of IANA. Q: (Doug Barton) First, some good news, we are working on v6; the board meeting in May will discuss it. About the delay, when was the request submitted? A: Well, not yet submitted Q: Then I accept your apologies for not blaming IANA to be late when no request have been submitted. Normally it takes 2 days. - "DNS Survey",Peter Koch; Universitaet Bielefeld http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-dns-survey.pdf Looking into the .de; Bind 8 by number has only 30%, but 60% by delegation, and 72% by weighted delegation. Q: (Jim) Why lots of people are still running Bind 8? A: Not really lots. Some of them are very large providers. There is a concern about load. Also, Bind until version 9.2 has a protocol problem, fixed with 9.3; so maybe, in the near future figures will change. - AOB Patrik Faltstrom is standing down as DNS WG co-chair. He will probably have some role in the ENUM WG that is expected to be formed. Jim thanked Patrik for his efforts in the DNS WG. He said that since this created a vacancy for a co-chair, he invited anyone who was interested in becoming a co-chair to get in touch. ======================================================== From olaf at ripe.net Mon Jul 5 11:39:58 2004 From: olaf at ripe.net (Olaf M. Kolkman) Date: Mon, 5 Jul 2004 11:39:58 +0200 Subject: [dns-wg] Deprecation of Message-ID: <20040705113958.0bcca94c.olaf@ripe.net> Dear Colleagues, (Apologies for duplicate messages) Further to our message sent on April 26[1] we would like to inform you that we will discontinue use of the e-mail interface for reverse delegation requests as of July 14, 2004. Starting from this date, any mail sent to will receive an appropriate redirection message. Reverse delegation requests can only be submitted to the RIPE Whois Database by using the e-mail interface or by using one of the other update mechanisms such as web-updates[2]. For more information about the authentication mechanism, please see http://www.ripe.net/reverse -- Olaf Kolkman New Projects, RIPE NCC [1] Announcement: New Policy and Procedures for Reverse DNS Requests http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00024.html [2] Webupdates interface to the RIPE Whois Database. http://www.ripe.net/perl/webupdates.pl If you are reading this or related posts from the archive all occurrences of ripe.net in e-mail addresses have been replaced by localhost. From dwmalone at maths.tcd.ie Tue Jul 6 16:34:03 2004 From: dwmalone at maths.tcd.ie (David Malone) Date: Tue, 06 Jul 2004 15:34:03 +0100 Subject: [dns-wg] AAAA lookup misbehaviour Message-ID: <200407061534.aa63193@salmon.maths.tcd.ie> I hadn't planned on covering the sort of client side issues mentioned by Alvaro and Colm, but maybe I should consider it? I think I understand the issue mentioned by Colm, and would be interested in the details of Alvaro's problem. If people think it is a good idea to cover these problems, then I'll write some text. The only feedback that I've got so far is from Peter, and I've made the changes that he suggested. The last paragraph mentions trying to automatically nag someone regarding problem servers - I'm not sure if we should be advocating this or if we should be saying it is a bad idea. David. This document is a short description of problems with certain DNS systems that have come to light with the deployment of IPv6 enabled software. --- One of the services that DNS provides is a facility for mapping host names to IPv4 addresses. This is probably the most common used service that DNS provides, and is achieved requesting a record of type "A" for the host name. Records of type A can only store an IPv4 address, and so with the introduction of IPv6, a new record type, AAAA has been introduced. It is becoming increasingly common for software to first issue a request of type AAAA, and if no record of that type is found then to issue a request for a record of type A. A request for a record of type AAAA causes no problems for most DNS servers, however some DNS servers implementations have been found that have problems answering other queries. Some DNS implementations have problems will only new types, such as AAAA, and others have problems with any query not of type A. The technical details of these problems are explained in the IETF draft document draft-ietf-dnsop-misbehavior-against-aaaa-01.txt. In Q1 2004, a survey of nameservers for 24000 hostnames mentioned in web proxy logs found about 0.5--1% of name servers seem to have to have a problem of this nature. The end result of these issues is that connecting to a site using a problematic name server may be impossible, intermittent or significantly delayed. To prevent introducing more DNS servers with such issues, testing of new DNS equipment should include checking that the response for records is in accordance with the RFCs (in particular RFC 1035, RFC 3597 and the draft mentioned above). As DNS load balancing software has often fallen foul of these problems, particular care should be taken in testing and validating such systems. The fact that problematic nameservers exist is in itself a problem. Where these issues cause direct inconvenience, the maintainers of the server and the maintainers of the DNS data should be notified to allow a normal service to be restored. However, often it is difficult for end users to identify the source of these problems, (for example, where an image embedded in a web page being served from a host with a problem hostname). It is also possible to automatically produce lists of names and nameservers that exhibit these problems. Clearly it is possible to automatically mail hostmaters or to publish "hall of shame" lists based on such data. It is unclear if such actions would achieve any useful effect, as service maintainers are usually primarily concerned about complaints directly from paying users! From jim at rfc1035.com Wed Jul 7 09:36:22 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 07 Jul 2004 08:36:22 +0100 Subject: [dns-wg] AAAA lookup misbehaviour In-Reply-To: Your message of "Tue, 06 Jul 2004 15:34:03 BST." <200407061534.aa63193@salmon.maths.tcd.ie> Message-ID: <5248.1089185782@gromit.rfc1035.com> >>>>> "David" == David Malone writes: David> The only feedback that I've got so far is from Peter, and David> I've made the changes that he suggested. The last paragraph David> mentions trying to automatically nag someone regarding David> problem servers - I'm not sure if we should be advocating David> this or if we should be saying it is a bad idea. Well if we don't get a consensus on this here, let's put the subject on the agenda for the next WG. We can always ask the meeting for a decision. Personally speaking, I'd support some sort of reminder though not a public naming and shaming. However this opens up a couple of other issues. What happens when there's no response to the email nagging (or whatever)? This is often how lame delegation reports get treated. It might also be sensible to include your AAAA recommendations in RIPE's delegation checks, especially for the new reverse delegation procedure that's being introduced. Perhaps the WG could make a decision about that too. From pk at TechFak.Uni-Bielefeld.DE Wed Jul 7 14:43:31 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 07 Jul 2004 14:43:31 +0200 Subject: [dns-wg] AAAA lookup misbehaviour In-Reply-To: Your message of "Wed, 07 Jul 2004 08:36:22 BST." <5248.1089185782@gromit.rfc1035.com> Message-ID: <200407071243.i67ChVS23917@grimsvotn.TechFak.Uni-Bielefeld.DE> > Personally speaking, I'd support some sort of reminder though not a > public naming and shaming. However this opens up a couple of other > issues. What happens when there's no response to the email nagging > (or whatever)? This is often how lame delegation reports get treated. The "hall of shame" wasn't serious, I guess. While similar methods exist (although not with that tone), it's not going to be helpful. In most cases it's the software that's broken/outdated/in violation of what we now see as the protocol. So, the operator would have to upgrade or, in extreme cases, change the software. Some of them may not even think of IPv6, still they're affected when their servers e.g. respond NXDOMAIN where they shouldn't. A more detailed picture would be helpful, including kind of fingerprinting of the affected systems, so the vendors could be approached directly. After that (or in parallel) the operators could be informed using the normal paths (SOA-RNAME, tech-c, ...) and asked for cooperation. This would need a group of volunteers (well, nowadays "to volunteer" is a transitive verb, you see) and a fixed timeframe (e.g. after RIPE 49 until end 2004). The wg could back this by, amongst other things, documenting the project as an official wg effort, just in case someone wonders why they're approached and asked to disclose what kind of SW they run. In addition, the DNS registries might want to support this to encourage IPv6 deployment and to ease migration. First, of course, the wg needs to decide whether the problem size justifies the effort. -Peter From dwmalone at maths.tcd.ie Wed Jul 7 15:20:15 2004 From: dwmalone at maths.tcd.ie (David Malone) Date: Wed, 07 Jul 2004 14:20:15 +0100 Subject: [dns-wg] AAAA lookup misbehaviour In-Reply-To: Your message of "Wed, 07 Jul 2004 14:43:31 +0200." <200407071243.i67ChVS23917@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <200407071420.aa39091@salmon.maths.tcd.ie> > A more detailed picture would be helpful, including kind of fingerprinting > of the affected systems, so the vendors could be approached directly. I do have some fingerprinting results, but they were a very simple-minded application of fpdns. I'm sure the fpdns authors could do a much better job (in fact, asking for unknown or rare types is probably a useful fingerprinting technqiue). The WG cooperating with the vendors/operators would also be good, as they can then be a part of RIPE efforts to encourage/smooth IPv6 deployment. I'd certainly be interested to see a case study from a (certain) big operator describing the deployment of a fix. OTOH, it may be sufficient to document the problem so it can be more easily diagnosed and fixed by vendors and operators who trip over it. (I presume DNSSEC may run into similar problems with weird responses for unknown types, but I am rather ignorant of the details of DNSSEC.) David. From Niall.oReilly at ucd.ie Wed Jul 7 18:29:06 2004 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 7 Jul 2004 17:29:06 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME Message-ID: Hello, I wouldn't cross-post, but there seems to be nobody home over on the enum-wg list, and it is related to DNS ... /Niall Begin forwarded message: > From: Niall O'Reilly > Date: 7 July 2004 10:48:56 IST > To: enum-wg at ripe.net > Cc: Niall O'Reilly > Subject: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME > > Hello ENUMmers, > > I'm about to become responsible for a Tier-2 ENUM registry, part of > the Irish ENUM > Trial. I expect to use BIND as the name server platform for this > purpose. I have > supposed (perhaps na?vely) that the conventional delegation mechanism, > using NS > records in the parent zone, would be appropriate. This involves > creating a new > zone as each new telephone number is registered, and configuring the > zone specifically > on each of Tier-2 name servers. > > I'm not sure I really want to buy in to this level of per-number > provisioning > activity, and see apparently significant advantages in using the > technique of RFC2317 > (Classless IN-ADDR.ARPA delegation) to make life simpler. > > The advantages I see are the following. > > The Tier-1 zone file becomes smaller, with just one CNAME (or DNAME) > record per > delegation, rather than two or more NS records. > > At Tier 2, the named configuration file needs only per-server, rather > than per-number- > per-server provisioning activity, and propagation of newly-registered > numbers is driven > by NOTIFY rather than by reloading the updated configuration file on > each server. > > This looks like the way to go, but perhaps I'm missing something ? > > Best regards, > > Niall O'Reilly > UCD Computing Services From maillistparticipant at elgaard.net Thu Jul 8 18:40:55 2004 From: maillistparticipant at elgaard.net (=?ISO-8859-1?Q?J=F8rgen_Elgaard_Larsen?=) Date: Thu, 08 Jul 2004 18:40:55 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? Message-ID: <40ED7917.20104@elgaard.net> Hi there, I would like to share some thoughts on reverse DNS with you. In my experience, reverse DNS often works well with larger organisations that have been assigned a /24 IPv4 range or greater. On the other hand, it almost never works with smaller organisations using smaller ranges, e.g. on ADSL lines. As I see it, there is a general trend that more and more small and mid-size businesses uses ADSL lines for connectivity. Since IPv4 addresses are scarce, these businesses are often assigned IPv4 ranges smaller than /24 - many only get a /30 range. Nevertheless, they still operates servers for various purposes. The problem is that ISPs typically are very hesitant to administer reverse DNS for these addresses. Either these addresses have no reverse DNS at all, or they resolve to a semi-random host name (e.g. address aaa.bbb.ccc.ddd resolves to aaa.bbb.ccc.ddd.adsl.isp-name.com). If the ISP (or whoever administers reverse DNS for the /24 range) do not wish to help out, there is really nothing the end user can do. Apart from being _really_ annoying to the end user, it also undermines reverse DNS as such: It is already difficult to convince everybody to set up reverse DNS, but even if an end user wants to do it, it may not be possible for him. I am aware that it would take some work for RIPE NCC to force every ISP to properly administer reverse DNS, but there are several costless methods that would help a lot. Please consider these suggestions: a) Make it mandatory for ISPs to offer classless reverse delegation to end users with RIPE-assigned IP ranges (i.e. for PA IP ranges that has a inetnum object with an end user as admin-c). Even if this would not be actively enforced, it would be a great help to end users if they could point to an official RIPE policy on this. Even a web page saying that LIRs _should_ do so would be a help. b) Make it mandatory for ISPs to offer either classless delegation or reverse DNS at IP-level for all its assigned addresses. Again, if there are no ressources to enforce it, it would still help to make it official RIPE NCC policy. c) Extend the new reverse delegation system to include classless delegation of PA addresses. For this to work, it would probably be necessary to move master DNS for all split ranges to RIPE NCC, which of course would increase the load on RIPE NCC. Administration, on the other hand, could be fully automatised. There are probably many other ways, too. Anyhow, I would really like a solution to this. Sincerely, J?rgen E. Larsen CTO Elgaard Data jel(at)elgaard.net From jim at rfc1035.com Thu Jul 8 21:41:15 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 08 Jul 2004 20:41:15 +0100 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: Message from =?ISO-8859-1?Q?J=F8rgen_Elgaard_Larsen?= of "Thu, 08 Jul 2004 18:40:55 +0200." <40ED7917.20104@elgaard.net> Message-ID: <7872.1089315675@gromit.rfc1035.com> J?rgen, you raise an interesting question. This subject is certainly something for the WG to consider. How about presenting something at the next RIPE meeting? My personal opinion is that a mandatory policy is likely to be too cumbersome. It could also be painful for ISPs and the NCC: creating inetnum objects for every /29 or whatever an ISP gives to its DSL customers. That might also open the door to other complications. If some DSL user is in the NCC database because of an inetnum object for reverse delegation, maybe that user should be paying NCC fees? And does that user become responsible for maintaining that inetnum and related objects in the database? I've also got a gut feel that reverse delegation is really an issue between an ISP and its customer. If some ISP won't do reverse delegation properly (or at all), the customer is free to pick another ISP that does. Economic Darwinism should sort this out, just like it eliminates the clueless ISPs with lousy service. A document advising about reverse delegations which customers can put in front of their ISP would be no bad thing though. That said, I would welcome a discussion about the subject and encourage the WG, especially those at DSL providers, to speak up. I would also be pleased for the WG to produce some document on reverse delegation and strongly recommends this gets done properly. Making reverse delegation mandatory for all customer IP addresses may be a step too far IMO, but let the WG decide this. Perhaps you could start the ball rolling by preparing an initial draft with a view to starting a work item? I'm a great believer in delegation (excuse the pun), so over to you.... and the WG. From brad.knowles at skynet.be Thu Jul 8 22:04:41 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu, 8 Jul 2004 22:04:41 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <7872.1089315675@gromit.rfc1035.com> References: <7872.1089315675@gromit.rfc1035.com> Message-ID: At 8:41 PM +0100 2004-07-08, Jim Reid wrote: > I've also got a gut feel that reverse delegation is really an issue > between an ISP and its customer. If some ISP won't do reverse > delegation properly (or at all), the customer is free to pick another > ISP that does. Economic Darwinism should sort this out, just like it > eliminates the clueless ISPs with lousy service. I disagree. In many cases, there is one and only one DSL provider for a given address -- the old telephone monopoly continues to have a stranglehold here. In cases where multiple DSL providers are available (or where cablemodem is an option), the monopoly provider is usually more flexible for that customer, whereas they tend to take a much more cavalier attitude towards those who have no other option. I think that it is wishful thinking to assume that Economic Darwinism will sort out this problem. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From pk at TechFak.Uni-Bielefeld.DE Thu Jul 8 23:19:01 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 08 Jul 2004 23:19:01 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: Your message of "Thu, 08 Jul 2004 20:41:15 BST." <7872.1089315675@gromit.rfc1035.com> Message-ID: <200407082119.i68LJ2N00214@grimsvotn.TechFak.Uni-Bielefeld.DE> > My personal opinion is that a mandatory policy is likely to be too Mandating these things usually needs a hat the wg doesn't wear. See also draft-ietf-dnsop-inaddr-required-05.txt. > cumbersome. It could also be painful for ISPs and the NCC: creating > inetnum objects for every /29 or whatever an ISP gives to its DSL > customers. That might also open the door to other complications. If Yes, like privacy issues. > some DSL user is in the NCC database because of an inetnum object for > reverse delegation, maybe that user should be paying NCC fees? And does Well, does the recipient of assigned address space now (directly) pay an NCC fee? > about reverse delegations which customers can put in front of their > ISP would be no bad thing though. What I've read between the lines is that in the case of DSL the classless delegation method may not be sufficient, even if the ISP is able and willing. Due to dynamic nature of address assignments they'd need something similar to dyndns (and friends) for the reverse mapping. So, is anyone doing this already? -Peter From jim at rfc1035.com Thu Jul 8 23:55:05 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 08 Jul 2004 22:55:05 +0100 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: Message from Peter Koch of "Thu, 08 Jul 2004 23:19:01 +0200." <200407082119.i68LJ2N00214@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <8029.1089323705@gromit.rfc1035.com> >>>>> "Peter" == Peter Koch writes: Peter> Well, does the recipient of assigned address space now Peter> (directly) pay an NCC fee? Well I'm not even though my ISP gave me a /28. I suppose some percentage of my DSL bill goes towards my ISP's contributions to the NCC. >> about reverse delegations which customers can put in front of >> their ISP would be no bad thing though. Peter> What I've read between the lines is that in the case of DSL Peter> the classless delegation method may not be sufficient, even Peter> if the ISP is able and willing. Due to dynamic nature of Peter> address assignments they'd need something similar to dyndns Peter> (and friends) for the reverse mapping. So, is anyone doing Peter> this already? No idea. Anyone? From jim at rfc1035.com Fri Jul 9 00:03:46 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 08 Jul 2004 23:03:46 +0100 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: Message from Brad Knowles of "Thu, 08 Jul 2004 22:04:41 +0200." Message-ID: <8050.1089324226@gromit.rfc1035.com> >>>>> "Brad" == Brad Knowles writes: >> I've also got a gut feel that reverse delegation is really an >> issue between an ISP and its customer. If some ISP won't do >> reverse delegation properly (or at all), the customer is free >> to pick another ISP that does. Economic Darwinism should sort >> this out, just like it eliminates the clueless ISPs with lousy >> service. Brad> I disagree. In many cases, there is one and only one Brad> DSL provider for a given address -- the old telephone Brad> monopoly continues to have a stranglehold here. Brad, please re-read what I said. I spoke about ISPs, not DSL providers. If working reverse DNS is a very important consideration for some customer, they can always find an ISP who can accommodate that. This might of course mean choosing some other way of shifting bits from what any monopoly DSL provider has to offer. So the customer makes their choice and pays their money. This probably is a much more effective way of getting results than writing up a BCP. Please note that I'm not saying monopoly DSL (or whatever) providers should be encouraged to ignore reverse DNS for their customers. From brad.knowles at skynet.be Fri Jul 9 02:25:54 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri, 9 Jul 2004 02:25:54 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <8050.1089324226@gromit.rfc1035.com> References: <8050.1089324226@gromit.rfc1035.com> Message-ID: At 11:03 PM +0100 2004-07-08, Jim Reid wrote: > Brad, please re-read what I said. I spoke about ISPs, not DSL > providers. At least in some countries, the DSL provider owns the reverse DNS, not the ISP. > If working reverse DNS is a very important consideration > for some customer, they can always find an ISP who can accommodate > that. Not all ISPs provide their own access. In Belgium, I believe that Belgacom is the only DSL access provider that is allowed by law. Everyone else has to resell DSL access from Belgacom, and Belgacom owns the reverse DNS. For some countries, access is the only thing that is provided, and if you want anything beyond access, you have to go to some other provider outside of the country. I have been told that this is the case throughout Poland. > This might of course mean choosing some other way of shifting > bits from what any monopoly DSL provider has to offer. To cablemodem, which is not available in all locales. The only other high speed option is satellite, which also isn't universally available. > So the customer > makes their choice and pays their money. This probably is a much more > effective way of getting results than writing up a BCP. Sometimes there aren't any viable choices. Whatever the WG does (or does not do), I think this fundamental problem has to be acknowledged. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From jim at rfc1035.com Fri Jul 9 03:06:21 2004 From: jim at rfc1035.com (Jim Reid) Date: Fri, 09 Jul 2004 02:06:21 +0100 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: Message from Brad Knowles of "Fri, 09 Jul 2004 02:25:54 +0200." Message-ID: <8872.1089335181@gromit.rfc1035.com> >>>>> "Brad" == Brad Knowles writes: >> Brad, please re-read what I said. I spoke about ISPs, not DSL >> providers. Brad> At least in some countries, the DSL provider owns the Brad> reverse DNS, not the ISP. To repeat myself: please re-read what I said. If bit-shifter A won't do reverse DNS to a customer's liking, the customer can go to bit-shifter B who does. How A and B shift bits is irrelevant: DSL, avian carriers, cable modems, whatever. It all comes down to a trade-off between cost, QoS, bandwidth and reverse DNS. If reverse DNS is the over-riding concern for someone, they can always find an ISP who will do this. Though it may be from an ISP that doesn't do DSL. >> If working reverse DNS is a very important consideration for >> some customer, they can always find an ISP who can accommodate >> that. Brad> Not all ISPs provide their own access. In Belgium, I Brad> believe that Belgacom is the only DSL access provider that Brad> is allowed by law. Everyone else has to resell DSL access Brad> from Belgacom, and Belgacom owns the reverse DNS. So what? If they won't do reverse DNS to your liking, try a cable company. Or get Level3 (say) to run fibre into your basement. Or do dialup over your GSM. There's always a solution. But it might not be as cheap or convenient as DSL from the incumbent. That's why I said people can always vote with their wallets. In the case of a monopoly provider, a "Correct Reverse DNS Is A Very Good Thing" document from the WG might be helpful if their policies are not addressing their customer's needs and those customers have nowhere else to go. From brad.knowles at skynet.be Fri Jul 9 03:38:10 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri, 9 Jul 2004 03:38:10 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <8872.1089335181@gromit.rfc1035.com> References: <8872.1089335181@gromit.rfc1035.com> Message-ID: At 2:06 AM +0100 2004-07-09, Jim Reid wrote: > If bit-shifter A won't do reverse DNS to a customer's liking, the > customer can go to bit-shifter B who does. How A and B shift bits > is irrelevant: DSL, avian carriers, cable modems, whatever. It all > comes down to a trade-off between cost, QoS, bandwidth and reverse > DNS. If reverse DNS is the over-riding concern for someone, they can > always find an ISP who will do this. Though it may be from an ISP that > doesn't do DSL. Let's go back to the original message on this subject from J?rgen Elgaard Larsen: | In my experience, reverse DNS often works well with larger | organisations that have been assigned a /24 IPv4 range or | greater. On the other hand, it almost never works with smaller | organisations using smaller ranges, e.g. on ADSL lines. | | As I see it, there is a general trend that more and more small | and mid-size businesses uses ADSL lines for connectivity. Since | IPv4 addresses are scarce, these businesses are often assigned | IPv4 ranges smaller than /24 - many only get a /30 range. | Nevertheless, they still operates servers for various purposes. Now, Jim -- you're talking about the general solution. Yes, with enough money, you should always be able to find an alternative provider who is willing to do whatever you want. You just have them run an OC-192 line to your basement, get RIPE to issue you a /8, and you're golden. Anything down to an E-1 and a /24 and you shouldn't have any problems. But we're not talking about the general solution. We're talking about issues with DSL providers. > In the case of a monopoly provider, a "Correct Reverse DNS Is A Very > Good Thing" document from the WG might be helpful if their policies > are not addressing their customer's needs and those customers have > nowhere else to go. Now that is a statement which I will agree with. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From jim at rfc1035.com Fri Jul 9 10:09:19 2004 From: jim at rfc1035.com (Jim Reid) Date: Fri, 09 Jul 2004 09:09:19 +0100 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: Message from Brad Knowles of "Fri, 09 Jul 2004 03:38:10 +0200." Message-ID: <9183.1089360559@gromit.rfc1035.com> >>>>> "Brad" == Brad Knowles writes: Brad> But we're not talking about the general solution. Brad> We're talking about issues with DSL providers. So incorrect reverse delegation for customer IP addresses only happens with DSL providers, does it? From brad.knowles at skynet.be Fri Jul 9 11:14:55 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri, 9 Jul 2004 11:14:55 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <9183.1089360559@gromit.rfc1035.com> References: <9183.1089360559@gromit.rfc1035.com> Message-ID: At 9:09 AM +0100 2004-07-09, Jim Reid wrote: > So incorrect reverse delegation for customer IP addresses only happens > with DSL providers, does it? No, but for the purposes of this thread, it is not useful to discuss any solution which is appropriate for the general problem but not applicable to the DSL provider situation. We haven't yet gotten to the part where we talk about going the other way. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From Niall.oReilly at ucd.ie Fri Jul 9 14:05:05 2004 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 9 Jul 2004 13:05:05 +0100 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: References: <9183.1089360559@gromit.rfc1035.com> Message-ID: <36CA310E-D1A0-11D8-835A-000393D8D77E@ucd.ie> On 9 Jul 2004, at 10:14, Brad Knowles wrote: > At 9:09 AM +0100 2004-07-09, Jim Reid wrote: > >> So incorrect reverse delegation for customer IP addresses only >> happens >> with DSL providers, does it? > > No, but for the purposes of this thread, it is not useful to discuss > any solution which is appropriate for the general problem but not > applicable to the DSL provider situation. > > We haven't yet gotten to the part where we talk about going the other > way. Now that all that's been (energetically) clarified, I'm looking forward to seeing and commenting on J?rgen's draft. Where I live, wireless is economically more attractive than DSL, and suffers from the same problem. Best regards, Niall O'Reilly UCD Computing Services From maillistparticipant at elgaard.net Fri Jul 9 21:08:16 2004 From: maillistparticipant at elgaard.net (=?windows-1252?Q?J=F8rgen_Elgaard_Larsen?=) Date: Fri, 09 Jul 2004 21:08:16 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <7872.1089315675@gromit.rfc1035.com> References: <7872.1089315675@gromit.rfc1035.com> Message-ID: <40EEED20.2050003@elgaard.net> I am delighted to see such an interest in this subject. I would love to write a draft on it, and perhaps even presenting it at a RIPE meeting. Instead of spamming you all with answers to each posts, I will collect my comments in a single mail. Of course, this messes up threading, but so be it :-) From the various comments I realise that although I originally related this problem to DSL customers it is also an issue to other end users, regardless of technology. It seems to be a general pattern for all end users with small IP range allocations. Jim Reid argued that these customers could just switch to another ISP, which of course is true. But even if it theoretically possible, it may not be economically viable. A small company may have to choose between paying, say, ?10 a month for a DSL connection or thousands of euros for having some serious provider pulling in a fibre or something. How many small businesses will be able and willing to pay orders of magnitude extra just to get the "luxury" of reverse DNS? Jim Reid also wrote: > It could also be painful for ISPs and the NCC: creating > inetnum objects for every /29 or whatever an ISP gives to its DSL > customers. Certainly. I did not mean to suggest making new inetnum objects. My idea was that end users that already have inetnum objects might be given the choice of reverse delegation. For end users without inetnum objects, the holder of the inetnum object for the encompassing range (typically the ISP) should handle reverse DNS. As I see it, it would be enough to make reverse delegation of PA addresses analogous to reverse delegation of PI addresses. The question here would be whether the RIPE NCC DNS servers can carry the load. Does anyone have an idea of how many inetnum objects there are in the whois database for IPv4 ranges lower than /24 - compared to the total number of inetnum objects? Peter Koch wrote: > See also draft-ietf-dnsop-inaddr-required-05.txt. A very interesting draft. If this becomes standard, RIPE should consider this question anyway. Does anyone know the status of this draft? Interestingly, the draft mentions RIPE as appearing "to have the strongest policy in this area [ripe-185] indicating Local Internet Registries are required to perform IN-ADDR services, and delegate those as appropriate when address blocks are delegated". ripe-185 is now deprecated, and the new policy does not mention this requirement at all. The former reverse DNS FAQ said "Each Local Internet Registry (LIR) is obliged to handle administration involved with the reverse delegation for the IP addresses it assigns" - but again, the new reverse delegation pages does not mention it at all. Prior to mailing this list, I asked ripe-dbm at ripe.net about this. They answered: > [...] there is no policy that obliges [the ISPs] to provide this > service to their customers, it is their own option. > > Although the text in our previous F.A.Q. was different, this statement > was what was always meant. So until recently, although unintentional, RIPE already demanded for ISPs to provide reverse DNS :-) Peter Koch also wrote: > Yes, like privacy issues. Actually, draft-ietf-dnsop-inaddr-required-05.txt mentions that privacy issues are irrelevant for this, since the information is already partially accessible through whois. > What I've read between the lines is that in the case of DSL the classless > delegation method may not be sufficient, even if the ISP is able and willing. > Due to dynamic nature of address assignments they'd need something similar > to dyndns (and friends) for the reverse mapping. So, is anyone doing this > already? It is true that some DSL customers have dynamic addresses, but many have static ones. If someone were to make reverse DNS for dynamic addresses, it would have to be the ISP (or whoever controls the /24 zone). I feel it would be counter-productive to make that mandatory - dynamic addresses and DNS cache do not mix (sufficiently low TTLs would just make too much traffic). Thank you for all your comments, J?rgen E. Larsen CTO Elgaard Data jel(at)elgaard.net From jon at lawrence.org.uk Fri Jul 9 21:26:08 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Fri, 9 Jul 2004 20:26:08 +0100 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <40EEED20.2050003@elgaard.net> References: <7872.1089315675@gromit.rfc1035.com> <40EEED20.2050003@elgaard.net> Message-ID: <200407092026.08931.jon@lawrence.org.uk> On Friday 09 July 2004 20:08, J?rgen Elgaard Larsen wrote: > So until recently, although unintentional, RIPE already demanded for > ISPs to provide reverse DNS :-) ISP's/LIR's should be required to provide reverse DNS. Even if it's just a generic reverse such as adsl-xx-xx.isp.com > > Peter Koch also wrote: > > Yes, like privacy issues. > > Actually, draft-ietf-dnsop-inaddr-required-05.txt mentions that privacy > issues are irrelevant for this, since the information is already partially > accessible through whois. No privacy issues aren't irrelevant. When I got my IP range at home, I wasn't informed that my details could potentially appear in a public registry - they didn't in the end, although there is an inetnum for my range it's fully admin'd by my ISP and doesn't contain any of my details. Privacy issues must be addressed, and there is actually no reason why the end user's details need to be associated with the inetnum. Jon From maillistparticipant at elgaard.net Fri Jul 9 22:14:38 2004 From: maillistparticipant at elgaard.net (=?windows-1252?Q?J=F8rgen_Elgaard_Larsen?=) Date: Fri, 09 Jul 2004 22:14:38 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <200407092026.08931.jon@lawrence.org.uk> References: <7872.1089315675@gromit.rfc1035.com> <40EEED20.2050003@elgaard.net> <200407092026.08931.jon@lawrence.org.uk> Message-ID: <40EEFCAE.1070707@elgaard.net> Jon Lawrence wrote: > ISP's/LIR's should be required to provide reverse DNS. Even if it's just a > generic reverse such as adsl-xx-xx.isp.com Although generic reverses does help in some ways, it could also be argued that they do not provide much real information. In my opinion it will only make sense to make reverse DNS mandatory, if the end user can decide that the information should be useful, i.e. that addresses resolve to corresponding canonical hostnames. > No privacy issues aren't irrelevant. > When I got my IP range at home, I wasn't informed that my details could > potentially appear in a public registry - they didn't in the end, although > there is an inetnum for my range it's fully admin'd by my ISP and doesn't > contain any of my details. > Privacy issues must be addressed, and there is actually no reason why the end > user's details need to be associated with the inetnum. Sorry, I did not mean that privacy issues are irrelevant. What I (and the draft) ment was that there are no privacy issues with reverse DNS as long as you can find the end user for an IP address through whois. Whether the whois database should allow anonymised inetnum objects is another discussion. But of course there will be privacy issues if otherwise anonymous IP addresses are forced to have reverse DNS pointing to something personal. Thanks for pointing that out - I had not thought of that, since I started the other way around, wanting to ensure that end users could have relevant reverse DNS if they wanted. In practice, however, this is should not be a problem. Even if you can be identified though domain X, there is usally no practical way for the ISP to know that you have made a hostname in that domain point to one of your IP addresses. Unless you instruct your ISP to make reverse DNS point for your addresses to something specific, they usually will have no choice but to let it point to a generic reverse. Best regards, J?rgen E. Larsen CTO Elgaard Data jel(at)elgaard.net From jon at lawrence.org.uk Fri Jul 9 22:52:55 2004 From: jon at lawrence.org.uk (Jon Lawrence) Date: Fri, 9 Jul 2004 21:52:55 +0100 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <40EEFCAE.1070707@elgaard.net> References: <7872.1089315675@gromit.rfc1035.com> <200407092026.08931.jon@lawrence.org.uk> <40EEFCAE.1070707@elgaard.net> Message-ID: <200407092152.55361.jon@lawrence.org.uk> On Friday 09 July 2004 21:14, J?rgen Elgaard Larsen wrote: > Jon Lawrence wrote: > > ISP's/LIR's should be required to provide reverse DNS. Even if it's just > > a generic reverse such as adsl-xx-xx.isp.com > > Although generic reverses does help in some ways, it could also be > argued that they do not provide much real information. In my opinion it > will only make sense to make reverse DNS mandatory, if the end user can > decide that the information should be useful, i.e. that addresses > resolve to corresponding canonical hostnames. yes and no :) It make sense to make reverse dns mandatory even if it's only a *generic* reverse. For one thing, I see plenty of emails coming through are servers (and some of them are genuine) which come from addresses with absolutely no reverse. I'd rather the reverse was relevant, but a *generic* is better than nothing. > > > No privacy issues aren't irrelevant. > > When I got my IP range at home, I wasn't informed that my details could > > potentially appear in a public registry - they didn't in the end, > > although there is an inetnum for my range it's fully admin'd by my ISP > > and doesn't contain any of my details. > > Privacy issues must be addressed, and there is actually no reason why the > > end user's details need to be associated with the inetnum. > > Sorry, I did not mean that privacy issues are irrelevant. > > What I (and the draft) ment was that there are no privacy issues with > reverse DNS as long as you can find the end user for an IP address > through whois. You don't necessarily need to be able to find the end user directly from the whois, so long as the whois points you in the right direction - ie the ISP. Ultimately, the whois always points you in the right direction, even if that means you end up complaining to the LIR directly :) > Whether the whois database should allow anonymised inetnum objects is > another discussion. Indeed it is another discussion but I for one see nothing intriniscally wrong with it - depending upon the degree on anonimity. I think the inetnum for my home range (81.168.4.64/29) is a good example of how to put in place an anonymous (as far as the end user is concerned) inetnum. > Thanks for pointing that out - I had not thought of that, since I > started the other way around, wanting to ensure that end users could > have relevant reverse DNS if they wanted. We also do the same. If someone wants to have a relevant reverse DNS then they get it - we may request proof that they own the domain name that they want it pointing to ;) but the customer gets what they want. Even if they don't want it, they may get it - All be it, it might just be their initials prefixed to our domain - it makes associating entries in log files to users a lot easier. So what if it's a bit more work for me to setup, in the long run I believe it saves me headaches. Jon From pk at TechFak.Uni-Bielefeld.DE Fri Jul 9 23:00:27 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Fri, 09 Jul 2004 23:00:27 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: Your message of "Fri, 09 Jul 2004 21:08:16 +0200." <40EEED20.2050003@elgaard.net> Message-ID: <200407092100.i69L0S403764@grimsvotn.TechFak.Uni-Bielefeld.DE> J?rgen E. Larsen wrote: > A very interesting draft. If this becomes standard, RIPE should consider > this question anyway. Does anyone know the status of this draft? it is currently a wg item in the IETF DNSOP wg and will be discussed at the San Diego IETF. There hasn't been any discussion on the list for quite a while. > Peter Koch also wrote: > > Yes, like privacy issues. > > Actually, draft-ietf-dnsop-inaddr-required-05.txt mentions that privacy > issues are irrelevant for this, since the information is already partially > accessible through whois. Just to clarify: I wasn't suggesting that the reverse mapping induced privacy problems. This sentence was in response to Jim, who, to my reading, suggested small allocations be added to the RIPE db. > It is true that some DSL customers have dynamic addresses, but many have > static ones. If someone were to make reverse DNS for dynamic addresses, > it would have to be the ISP (or whoever controls the /24 zone). I feel > it would be counter-productive to make that mandatory - dynamic > addresses and DNS cache do not mix (sufficiently low TTLs would just > make too much traffic). So, do you feel this is DSL specific or could be described as "reverse mapping for small address ranges"? Brad seemed to distinguish between the ISP and the DSL provider {BTW, speaking of categories, you might want to have a look at draft-klensin-ip-service-terms-03.txt - but let's not discuss that one here}. My perception is that we have a similar situation with one of our larger T-elco. On the other hand, the very same company does (and has been doing for years) provide RFC 2317 delegations. Let's first agree what the problem domain is. Then, we could do some measurement/counting, e.g. find how much address space < /24 is actually served in RFC 2317/BCP 20 style. The NCC did regular IN-ADDR.ARPA surveys and some of this data may be either readily available or not too difficult to find. -Peter From bruce.campbell at ripe.net Mon Jul 12 13:28:38 2004 From: bruce.campbell at ripe.net (Bruce Campbell) Date: Mon, 12 Jul 2004 13:28:38 +0200 (CEST) Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <40EEED20.2050003@elgaard.net> References: <7872.1089315675@gromit.rfc1035.com> <40EEED20.2050003@elgaard.net> Message-ID: On Fri, 9 Jul 2004, [windows-1252] J?rgen Elgaard Larsen wrote: > Does anyone have an idea of how many inetnum objects there are > in the whois database for IPv4 ranges lower than /24 - compared to the > total number of inetnum objects? There are 959000 The question here would be whether the RIPE NCC DNS servers can carry > the load. We have ccTLD zones secondaried on the same servers with more than a million DNS records. > It is true that some DSL customers have dynamic addresses, but many have > static ones. If someone were to make reverse DNS for dynamic addresses, > it would have to be the ISP (or whoever controls the /24 zone). I feel Agreed. ( DNS updates by the NCC for dynamic addresses has LIR customers directly contacting the NCC written all over it, to say nothing of how we handle this in the database ) Regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security "Text processing has made it possible to right-justify any idea, even one which cannot be justified on any other grounds." -- J. Finnegan, USC. From jel at elgaard.net Fri Jul 9 22:11:07 2004 From: jel at elgaard.net (=?windows-1252?Q?J=F8rgen_Elgaard_Larsen?=) Date: Fri, 09 Jul 2004 22:11:07 +0200 Subject: [dns-wg] Policy for Reverse DNS for End-User PA Addresses? In-Reply-To: <200407092026.08931.jon@lawrence.org.uk> References: <7872.1089315675@gromit.rfc1035.com> <40EEED20.2050003@elgaard.net> <200407092026.08931.jon@lawrence.org.uk> Message-ID: <40EEFBDB.10705@elgaard.net> Jon Lawrence wrote: > ISP's/LIR's should be required to provide reverse DNS. Even if it's just a > generic reverse such as adsl-xx-xx.isp.com Although generic reverses does help in some ways, it could also be argued that they do not provide much real information. In my opinion it will only make sense to make reverse DNS mandatory, if the end user can decide that the information should be useful, i.e. that addresses resolve to corresponding canonical hostnames. > No privacy issues aren't irrelevant. > When I got my IP range at home, I wasn't informed that my details could > potentially appear in a public registry - they didn't in the end, although > there is an inetnum for my range it's fully admin'd by my ISP and doesn't > contain any of my details. > Privacy issues must be addressed, and there is actually no reason why the end > user's details need to be associated with the inetnum. Sorry, I did not mean that privacy issues are irrelevant. What I (and the draft) ment was that there are no privacy issues with reverse DNS as long as you can find the end user for an IP address through whois. Whether the whois database should allow anonymised inetnum objects is another discussion. But of course there will be privacy issues if otherwise anonymous IP addresses are forced to have reverse DNS pointing to something personal. Thanks for pointing that out - I had not thought of that, since I started the other way around, wanting to ensure that end users could have relevant reverse DNS if they wanted. In practice, however, this is should not be a problem. Even if you can be identified though domain X, there is usally no practical way for the ISP to know that you have made a hostname in that domain point to one of your IP addresses. Unless you instruct your ISP to make reverse DNS point for your addresses to something specific, they usually will have no choice but to let it point to a generic reverse. Best regards, J?rgen E. Larsen CTO Elgaard Data jel(at)elgaard.net From andrei at ripe.net Tue Jul 13 09:49:57 2004 From: andrei at ripe.net (Andrei Robachevsky) Date: Tue, 13 Jul 2004 09:49:57 +0200 Subject: [dns-wg] FYI: IANA delegation procedure for the root zone and ipv6 glue Message-ID: <40F39425.2080006@ripe.net> Colleagues, The final version of the new IANA delegation data procedure is now on-line at http://www.iana.org/procedures/delegation-data.html. Regards, Andrei Robachevsky RIPE NCC From pk at TechFak.Uni-Bielefeld.DE Tue Jul 13 16:11:24 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 13 Jul 2004 16:11:24 +0200 Subject: [dns-wg] FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: Your message of "Tue, 13 Jul 2004 09:49:57 +0200." <40F39425.2080006@ripe.net> Message-ID: <200407131411.i6DEBP717249@grimsvotn.TechFak.Uni-Bielefeld.DE> Andrei, > on-line at http://www.iana.org/procedures/delegation-data.html. thanks for the pointer! Now, what are "reasonable queries"? -Peter From bortzmeyer at nic.fr Tue Jul 13 16:18:22 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 13 Jul 2004 16:18:22 +0200 Subject: [dns-wg] Re: FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: <200407131411.i6DEBP717249@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <40F39425.2080006@ripe.net> <200407131411.i6DEBP717249@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040713141822.GA1625@nic.fr> On Tue, Jul 13, 2004 at 04:11:24PM +0200, Peter Koch wrote a message of 8 lines which said: > Now, what are "reasonable queries"? www.ripe.net karrenberg.ripe.net very-very-long-name-unreasonable-but-only-intended-to-break-the-512-bytes-limit-of-DNS-without-EDNS0.ripe.net From jeroen.valcke at belnet.be Tue Jul 13 10:51:55 2004 From: jeroen.valcke at belnet.be (Jeroen Valcke) Date: Tue, 13 Jul 2004 10:51:55 +0200 Subject: [dns-wg] FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: <40F39425.2080006@ripe.net> References: <40F39425.2080006@ripe.net> Message-ID: <20040713085155.GA997@jeroen.fw.belnet.be> Hello, On Tue, Jul 13, 2004 at 09:49:57AM +0200, Andrei Robachevsky wrote: > The final version of the new IANA delegation data procedure is now > on-line at http://www.iana.org/procedures/delegation-data.html. the document states that, "The procedures described apply equally to all NS, glue (A/AAAA), or other records published in the root zone" Now, I was wondering whether IPv6 glue records have already been added in the root zone. To my knowledge not, is that correct? Are there TLDs who already submitted IPv6 glue records? Best regards, -Jeroen- -- Jeroen Valcke From bortzmeyer at nic.fr Tue Jul 13 16:27:54 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 13 Jul 2004 16:27:54 +0200 Subject: [dns-wg] Re: FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: <20040713085155.GA997@jeroen.fw.belnet.be> References: <40F39425.2080006@ripe.net> <20040713085155.GA997@jeroen.fw.belnet.be> Message-ID: <20040713142754.GA2484@nic.fr> On Tue, Jul 13, 2004 at 10:51:55AM +0200, Jeroen Valcke wrote a message of 18 lines which said: > Now, I was wondering whether IPv6 glue records have already been > added in the root zone. To my knowledge not, is that correct? Correct. ftp://rs.internic.net/domain/root.zone.gz > Are there TLDs who already submitted IPv6 glue records? We did, on 17th February 2003. From geoff at nominet.org.uk Tue Jul 13 16:36:54 2004 From: geoff at nominet.org.uk (Geoffrey Sisson) Date: Tue, 13 Jul 2004 15:36:54 +0100 (BST) Subject: [dns-wg] Re: FYI: IANA delegation procedure for the root zone and ipv6 glue Message-ID: <20040713143654.F35A3E7E65@mx1.nominet.org.uk> Stephane Bortzmeyer writes: > On Tue, Jul 13, 2004 at 10:51:55AM +0200, > Jeroen Valcke wrote > a message of 18 lines which said: > > > Now, I was wondering whether IPv6 glue records have already been > > added in the root zone. To my knowledge not, is that correct? > > Correct. ftp://rs.internic.net/domain/root.zone.gz > > > Are there TLDs who already submitted IPv6 glue records? > > We did, on 17th February 2003. At the CENTR GA Meeting last month, Doug Barton announced that AAAA RRs would be introduced into the root zone by the end of June, but this has not yet happened. Regards Geoff From bortzmeyer at nic.fr Tue Jul 13 17:02:41 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 13 Jul 2004 17:02:41 +0200 Subject: [dns-wg] Re: Re: FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: <010e01c468e9$3ced9b90$6e11a9c3@mobile666> References: <40F39425.2080006@ripe.net> <200407131411.i6DEBP717249@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040713141822.GA1625@nic.fr> <010e01c468e9$3ced9b90$6e11a9c3@mobile666> Message-ID: <20040713150241.GA4458@nic.fr> On Tue, Jul 13, 2004 at 04:54:02PM +0200, Roy Arends wrote a message of 40 lines which said: > Your wild guess is wrong, there are no queries possible that exceeds > > 512 udp size. I never said so, I showed a query that could make a break of the 512-bytes limit, *when echoed in the reply*. And, BTW, my query was illegal but for another reason, left as an exercice. From Mohsen.Souissi at nic.fr Tue Jul 13 17:27:08 2004 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Tue, 13 Jul 2004 17:27:08 +0200 Subject: [dns-wg] FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: <200407131411.i6DEBP717249@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <40F39425.2080006@ripe.net> <200407131411.i6DEBP717249@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040713152708.GH26835@kerkenna.nic.fr> Hi Peter & all, On 13 Jul, Peter Koch wrote: | Andrei, | | > on-line at http://www.iana.org/procedures/delegation-data.html. | | thanks for the pointer! | Now, what are "reasonable queries"? ==> If my understanding is correct, "reasonable queries" are queries that don't trigger DNS responses whose length exceeds 512 octets. You may find more details on average and worst case queries in Kato-Vixie draft which expired but which is archived here : http://www.ietf.org/proceedings/03jul/I-D/draft-ietf-dnsop-respsize-00.txt You may also find more theoritical computation related to DNS response size and name compression at the following URL : http://w6.nic.fr/dnsv6/resp-size.html Mohsen. From pk at TechFak.Uni-Bielefeld.DE Tue Jul 13 19:11:51 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 13 Jul 2004 19:11:51 +0200 Subject: [dns-wg] Re: FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: Your message of "Tue, 13 Jul 2004 16:18:22 +0200." <20040713141822.GA1625@nic.fr> Message-ID: <200407131711.i6DHBpk17677@grimsvotn.TechFak.Uni-Bielefeld.DE> Stephane Bortzmeyer wrote: > I was serious. > > very-very-long-name-unreasonable-but-only-intended-to-break-the-512-bytes-lim >it-of-DNS-without-EDNS0.ripe.net > Now, what about _ldap._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs.office.TechFak.Uni-Bielefeld.DE? The name is "long" but not "only-intended-to-break-the-512-bytes-limit". -Peter From olaf at ripe.net Wed Jul 14 16:45:43 2004 From: olaf at ripe.net (Olaf M. Kolkman) Date: Wed, 14 Jul 2004 16:45:43 +0200 Subject: [dns-wg] Last Warning: Termination of Message-ID: <20040714164543.6a9e77aa.olaf@ripe.net> Dear Colleagues, [Apologies for the duplicate messages] As announced previously (e.g. [1]), we will discontinue the use of the e-mail interface for reverse delegation requests as of tomorrow (July 15, 2004). From tomorrow, all mails sent to this address will be returned to sender. Reverse delegation requests can only be submitted to the RIPE Whois Database by using the e-mail interface or by using one of the other update mechanisms such as web-updates[2]. For more information about the authentication mechanism, please see http://www.ripe.net/reverse -- Olaf Kolkman New Projects, RIPE NCC [1] http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00042.html [2] Webupdates interface to the RIPE Whois Database. http://www.ripe.net/perl/webupdates.pl If you are reading this or related posts from the archive all occurrences of ripe.net in e-mail addresses have been replaced by localhost -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC From jim at rfc1035.com Wed Jul 14 18:18:34 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 14 Jul 2004 17:18:34 +0100 Subject: [dns-wg] Last Warning: Termination of In-Reply-To: Message from "Olaf M. Kolkman" of "Wed, 14 Jul 2004 16:45:43 +0200." <20040714164543.6a9e77aa.olaf@ripe.net> Message-ID: <17626.1089821914@gromit.rfc1035.com> >>>>> "Olaf" == Olaf M Kolkman writes: Olaf> As announced previously (e.g. [1]), we will discontinue the Olaf> use of the e-mail interface for Olaf> reverse delegation requests as of tomorrow (July 15, 2004). Olaf> From tomorrow, all mails sent to this address will be Olaf> returned to sender. I hope the bounce message tells the sender what email address they should have used or points them at a web page that gives this info. From bortzmeyer at nic.fr Wed Jul 14 23:14:06 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 14 Jul 2004 23:14:06 +0200 Subject: [dns-wg] Re: Re: FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: <200407131711.i6DHBpk17677@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <20040713141822.GA1625@nic.fr> <200407131711.i6DHBpk17677@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040714211406.GB6662@nic.fr> On Tue, Jul 13, 2004 at 07:11:51PM +0200, Peter Koch wrote a message of 17 lines which said: > Now, what about > _ldap._tcp.Standardname-des-ersten-Standorts._sites.dc._msdcs.office.TechFak.Uni-Bielefeld.DE? > > The name is "long" but not "only-intended-to-break-the-512-bytes-limit". You're right, SRV records, IDN, DNSSEC, domain names in german, and of course IPv6 have all the potential to "innocently" break the 512-bytes limit. That's why all DNS software should support EDNS0, IMHO. From jim at rfc1035.com Thu Jul 15 12:07:15 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 15 Jul 2004 11:07:15 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: Message from "Niall O'Reilly" of "Wed, 07 Jul 2004 17:29:06 BST." Message-ID: <20051.1089886035@gromit.rfc1035.com> >>>>> "Niall" == Niall O'Reilly writes: >> I'm about to become responsible for a Tier-2 ENUM registry, >> part of the Irish ENUM Trial. I expect to use BIND as the name >> server platform for this purpose. I have supposed (perhaps >> na?vely) that the conventional delegation mechanism, using NS >> records in the parent zone, would be appropriate. This >> involves creating a new zone as each new telephone number is >> registered, and configuring the zone specifically on each of >> Tier-2 name servers. >> >> I'm not sure I really want to buy in to this level of >> per-number provisioning activity, and see apparently >> significant advantages in using the technique of RFC2317 >> (Classless IN-ADDR.ARPA delegation) to make life simpler. Actually I think it will make life harder. 2317-style delegation is trickier to set up and maintain than conventional delegation. >> The advantages I see are the following. >> >> The Tier-1 zone file becomes smaller, with just one CNAME (or >> DNAME) record per delegation, rather than two or more NS >> records. So what? Is disk space and RAM expensive? The T1 registry is going to be storing so much data about its registrations -- tech & admin contact details, billing info, authentication/validation tokens, whois tags, registrar data, etc, etc -- that shaving off a couple of resource records would be lost in the noise. For the T1, adding CNAMEs instead of conventional delegations might well be an unwanted complication: ie it requires changes and on-going support to the registry database and back-end scripts and tools. IIUC some registry systems only handle the RRs needed for conventional delegation: NS records and related glue. >> At Tier 2, the named configuration file needs only per-server, >> rather than per-number- per-server provisioning activity, and >> propagation of newly-registered numbers is driven by NOTIFY >> rather than by reloading the updated configuration file on each >> server. You lose the granularity of control and the flexibility to let customers manage their delegations. I'm presuming you plan to have all your numbers CNAME'd into a single zone file rather than discrete zone files for each zone. This might also get you into trouble with the competition authorities because the people using these CNAME'd numbers are locked in to your way of doing things. For something like a DDI block for an organisation, this shouldn't be an issue. But if it was for all numbers in the Dublin area code (say), there would be a problem. Registrants won't have the freedom to choose and switch DNS providers. Or decouple DNS hosting from the ISP/registrar they use to get their ENUM delegation. Using some sort of CNAME/DNAME trickery may limit your options for the future. ie It imposes a certain way of working or mindset that seems reasonable today. But it may not be the case in a year or so. And then all sorts of silliness happens as the original CNAME/DNAME model gets perverted to support the then prevailing orthodoxy. How often have we met bizarre DNS setups that have been inherited from an earlier DNS administrator who kludged a configuration and then kept tweaking it instead of doing the job properly? >> This looks like the way to go, but perhaps I'm missing >> something ? Using CNAME trickery for ENUM is unwise. It opens the door to all sorts of evils, like the accommodation of alternate trees. And it will make DNSSEC deployment (hah!) much harder because the parent can't secure any delegations with DS records because there are no proper delegations. DNAME is even worse because there are plenty of name servers and resolvers out there that don't understand this RR. It's not impossible that some applications will get upset if they get CNAME-like referrals to their lookups when they only expected to get NAPTR RRs or conventional referrals. For instance think of someone who writes a minimal ENUM-aware resolver as a Java applet for their mobile phone. Another problem -- which won't apply to someone clueful like you -- is that the introduction of CNAMEs increases the likelihood of looping or very long CNAME chains. Or dangling CNAMEs that point at nothing. Even without these administrative errors, the introduction of CNAMEs will complicate ENUM lookups and could mean they take too long. This would be somewhat annoying when someone picks up their ENUM-aware phone, dials a number and then waits for an eternity while the resolver chases down umpteen CNAME chains before making a phone ring. IMO it's best not to give people access to that much rope to hang themselves. From Niall.oReilly at ucd.ie Thu Jul 15 13:02:47 2004 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 15 Jul 2004 12:02:47 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: <20051.1089886035@gromit.rfc1035.com> References: <20051.1089886035@gromit.rfc1035.com> Message-ID: <817E3A5A-D64E-11D8-8F56-000393D8D77E@ucd.ie> Jim, Thanks for the comprehensive comments. I'ld like to reply to one chunk at a time. [dns-wg-ers, sorry for the cross-posting; I'ld use enum-wg if it were populated.] On 15 Jul 2004, at 11:07, Jim Reid wrote: > So what? Is disk space and RAM expensive? No. T1 zone-file size is indeed no big deal, mentioned for completeness only. > The T1 registry is going to > be storing so much data about its registrations -- tech & admin > contact details, billing info, authentication/validation tokens, whois > tags, registrar data, etc, etc -- that shaving off a couple of > resource records would be lost in the noise. Only if your (unstated) assumptions about the role of the T1 Registry match the particular instance. My concept of the T1 Registry is much lighter, with delegation only at T1, payload (NAPTR of course, possibly others) at T2, and validation with the registRARs. This distributes customer-related overhead to the front-office, where it can be related directly to each registrar's business. > For the T1, adding CNAMEs > instead of conventional delegations might well be an unwanted > complication: ie it requires changes and on-going support to the > registry database and back-end scripts and tools. IIUC some registry > systems only handle the RRs needed for conventional delegation: NS > records and related glue. IMHO such registry systems are not suited to the ENUM business, and a T1 which takes this approach is unlikely to be winning many tenders for national infrastructure. Of course, that depends on the clue-level available to the local awarding agency. I'm happy to say that, here in +353-land, our trial T1 is taking a more helpful approach. Best regards, Niall O'Reilly UCD Computing Services From roy at dnss.ec Tue Jul 13 16:54:02 2004 From: roy at dnss.ec (Roy Arends) Date: Tue, 13 Jul 2004 16:54:02 +0200 Subject: [dns-wg] Re: FYI: IANA delegation procedure for the root zone and ipv6 glue References: <40F39425.2080006@ripe.net> <200407131411.i6DEBP717249@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040713141822.GA1625@nic.fr> Message-ID: <010e01c468e9$3ced9b90$6e11a9c3@mobile666> Your wild guess is wrong, there are no queries possible that exceeds > 512 udp size. A QNAME has a maximum length of 255. The wording used "reasonable queries" originates in Ronald van der Pol's paper on 'Adding IPv6 glue to the root zone'. My wild guess is that Ronald might shed some light on this. Gut feeling is that reasonable in the context of Ronalds paper means queries that conform to all DNS specification. Roy ----- Original Message ----- From: "Stephane Bortzmeyer" To: "Peter Koch" Cc: Sent: Tuesday, July 13, 2004 4:18 PM Subject: [dns-wg] Re: FYI: IANA delegation procedure for the root zone and ipv6 glue > On Tue, Jul 13, 2004 at 04:11:24PM +0200, > Peter Koch wrote > a message of 8 lines which said: > > > Now, what are "reasonable queries"? > > > > www.ripe.net > > > karrenberg.ripe.net > > > very-very-long-name-unreasonable-but-only-intended-to-break-the-512-bytes-li mit-of-DNS-without-EDNS0.ripe.net > > > > From Niall.oReilly at ucd.ie Thu Jul 15 13:38:14 2004 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 15 Jul 2004 12:38:14 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: <20051.1089886035@gromit.rfc1035.com> References: <20051.1089886035@gromit.rfc1035.com> Message-ID: <751F9306-D653-11D8-8F56-000393D8D77E@ucd.ie> On 15 Jul 2004, at 11:07, Jim Reid wrote: > You lose the granularity of control and the flexibility to let > customers manage their delegations. I'm presuming you plan to have all > your numbers CNAME'd into a single zone file rather than discrete zone > files for each zone. I see it quite the other way around: you _gain_ flexibility. The customer has a single point of administration for announcing the delegation and changes thereto. Once the CNAME has aged out from resolver caches, there is no trace left of obsolete data in the 'golden tree'. If the T2 provider which the customer has just deserted delays (or neglects) removing the relevant RRsets, so what ? With NS, on the other hand, you have to make sure that all the obsolete data on still authoritative servers is eliminated. > This might also get you into trouble with the > competition authorities because the people using these CNAME'd numbers > are locked in to your way of doing things. Are you saying that the opportunity for restrictive practices is significantly different according to which method you choose for implementing delegation ? I really don't see this. > For something like a DDI > block for an organisation, this shouldn't be an issue. But if it was > for all numbers in the Dublin area code (say), there would be a > problem. How is this different between the NS and CNAME implementations ? > Registrants won't have the freedom to choose and switch DNS > providers. Or decouple DNS hosting from the ISP/registrar they use to > get their ENUM delegation. See above. Best regards, Niall O'Reilly UCD Computing Services From Niall.oReilly at ucd.ie Thu Jul 15 13:48:11 2004 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 15 Jul 2004 12:48:11 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: <20051.1089886035@gromit.rfc1035.com> References: <20051.1089886035@gromit.rfc1035.com> Message-ID: On 15 Jul 2004, at 11:07, Jim Reid wrote: > Another problem -- which won't apply to someone clueful like you -- is > that the introduction of CNAMEs increases the likelihood of looping or > very long CNAME chains. Or dangling CNAMEs that point at nothing. Even > without these administrative errors, the introduction of CNAMEs will > complicate ENUM lookups and could mean they take too long. This would > be somewhat annoying when someone picks up their ENUM-aware phone, > dials a number and then waits for an eternity while the resolver > chases down umpteen CNAME chains before making a phone ring. IMO it's > best not to give people access to that much rope to hang themselves. OTOH, there's a balance to be struck between allowing people to be responsible for their own mistakes and engaging in the diminishing-returns game of protecting them from everything. If registrars or T2 registries can't do their job, how long will they stay in business ? Best regards, Niall O'Reilly UCD Computing Services From Niall.oReilly at ucd.ie Thu Jul 15 13:54:38 2004 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 15 Jul 2004 12:54:38 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: <20051.1089886035@gromit.rfc1035.com> References: <20051.1089886035@gromit.rfc1035.com> Message-ID: On 15 Jul 2004, at 11:07, Jim Reid wrote: > And it will > make DNSSEC deployment (hah!) much harder because the parent can't > secure any delegations with DS records because there are no proper > delegations. So, we'd better make sure our trial doesn't take longer than six months ? 8-) Seriously, though, this is something I need to avoid losing sight of. Thanks. > DNAME is even worse because there are plenty of name > servers and resolvers out there that don't understand this RR. This also. thanks again. > It's > not impossible that some applications will get upset if they get > CNAME-like referrals to their lookups when they only expected to get > NAPTR RRs or conventional referrals. For instance think of someone who > writes a minimal ENUM-aware resolver as a Java applet for their mobile > phone. Nobody with significant market share would be involved in inflicting such a broken application on the unsuspecting customers, would they ? 8-) Best regards, Niall O'Reilly UCD Computing Services From jim at rfc1035.com Thu Jul 15 14:47:01 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 15 Jul 2004 13:47:01 +0100 Subject: [dns-wg] Re: FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: Message from "Roy Arends" of "Tue, 13 Jul 2004 16:54:02 +0200." <010e01c468e9$3ced9b90$6e11a9c3@mobile666> Message-ID: <20563.1089895621@gromit.rfc1035.com> >>>>> "Roy" == Roy Arends writes: Roy> Your wild guess is wrong, there are no queries possible that Roy> exceeds > 512 udp size. A QNAME has a maximum length of 255. IIUC, there is nothing in the DNS protocol which limits the Question Section to one QNAME/QTYPE/CLASS tuple. QDCOUNT can be > 1. Though I suppose some could argue that a request which contained > 1 query was unreasonable. [ISTR BIND will reject these with a FORMERR.] And if we consider DDNS requests to be queries -- which in some sense they are -- these can easily be bigger than 512 bytes. Just throw in a few prerequisites and a handful of additions and deletions in the one DDNS transaction. Besides I think the original context of "unreasonable queries" was really about queries which were unreasonable because of the responses they'd provoke, not the size of the queries themselves. ie In the absence of EDNS0 the server is forced to send truncated replies, causing TCP retries. Come to think of it, a discussion of query size is somewhat academic. If a query is going to be more than 512 bytes, the client will have to either use TCP or EDNS0 to send it to the server. From brad.knowles at skynet.be Thu Jul 15 14:46:16 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu, 15 Jul 2004 14:46:16 +0200 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: References: <20051.1089886035@gromit.rfc1035.com> Message-ID: At 12:48 PM +0100 2004-07-15, Niall O'Reilly wrote: > If registrars or T2 registries can't do their job, how long will they stay > in business ? If the current amount of policing we're getting from ICANN is any example, then the answer is "surprisingly long". Just ask Network Solutions. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From jim at rfc1035.com Thu Jul 15 15:25:27 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 15 Jul 2004 14:25:27 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: Message from "Niall O'Reilly" of "Thu, 15 Jul 2004 12:38:14 BST." <751F9306-D653-11D8-8F56-000393D8D77E@ucd.ie> Message-ID: <20599.1089897927@gromit.rfc1035.com> >>>>> "Niall" == Niall O'Reilly writes: >> You lose the granularity of control and the flexibility to let >> customers manage their delegations. I'm presuming you plan to >> have all your numbers CNAME'd into a single zone file rather >> than discrete zone files for each zone. Niall> I see it quite the other way around: you _gain_ Niall> flexibility. Is the glass half-empty or half-full? It depends on where you look from. Niall> The customer has a single point of administration for Niall> announcing the delegation and changes thereto. Once the Niall> CNAME has aged out from resolver caches, there is no trace Niall> left of obsolete data in the 'golden tree'. If the T2 Niall> provider which the customer has just deserted delays (or Niall> neglects) removing the relevant RRsets, so what ? With NS, Niall> on the other hand, you have to make sure that all the Niall> obsolete data on still authoritative servers is eliminated. Niall, I don't understand what you're saying. Perhaps you could explain your envisaged scheme with some examples: ie what's in zone files. You're now talking about T2 provider. From your earlier posting I'm confused if this is a registry, DNS provider, registrar (or some combination of these) and what RR/zone data they may hold and manipulate. So please, draw me an idiot-proof picture. The roles and interfaces you're outlining seem rather fuzzy. Niall> Are you saying that the opportunity for restrictive Niall> practices is significantly different according to which Niall> method you choose for implementing delegation ? YES! It's not just about how delegation gets implemented. The roles and responsibilities in that process matter too. This is why the UK ENUM Group factored out the DNS Provider as a distinct role in its overall ENUM architecture. [Read its 2002 report.] That meant DNS content and service wasn't necessarily under the control of a registrar, ISP or application service provider. This is a very important distinction IMO. We also envisaged a market for different levels of DNS service. Some might be happy with a no-guarantees free service, while others want something super-robust with 24x7 support, anycasting, DNSSEC and so on. Your CNAME scheme could make it harder to establish that market. Suppose my number is delegated from the T1 registry with a CNAME to some zone of yours. You have the trust relationship with the T1. I have a trust relationship with you. In this scenario, the T1 doesn't know or care about me. So they won't change the CNAME if I asked them to do this. That won't happen unless you tell them. And if we've had a falling out, you're not likely to make that hassle-free. Now suppose you're a telco and I'm a customer wanting to switch to another telco. Or I want to shift my mail URIs from the telco's mail server to say hotmail. Does this help clarify the context now? >> For something like a DDI block for an organisation, this >> shouldn't be an issue. But if it was for all numbers in the >> Dublin area code (say), there would be a problem. Niall> How is this different between the NS and CNAME Niall> implementations ? It's not about that. It's about what can be put in the zone and how that's done. If all the numbers in one block are "delegated" -- for some loose definition of that term -- to a single zone file, there will be less flexibility and granularity of control over the zone's contents. I have to use whatever tools you've provided and onlyaccess ENUM services you'll let me add to the zone for that number. This is tolerable for a number block under one authority where common rules and policy can be enforced -- say the DDI block for an employer. But for the general case, this isn't acceptable. The entity holding that zone file shouldn't be allowed to restrict what NAPTR records exist for my number. Or my neighbour's. For maximum flexibility and fine-grained granularity of control (plus making sure delegations carefully follow the national numbering plan), the T1 registry should delegate individual numbers to discrete zone files that are notionally controlled by the owner of that number. Introducing CNAMEs will add a layer of indirection. [A needless one IMO.] That could mean boundaries of responsibility get blurred and/or more complicated. Which could give an unscrupulous provider enough wiggle room for unsavoury practices. From jim at rfc1035.com Thu Jul 15 15:32:45 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 15 Jul 2004 14:32:45 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: Message from "Niall O'Reilly" of "Thu, 15 Jul 2004 12:48:11 BST." Message-ID: <20619.1089898365@gromit.rfc1035.com> >>>>> "Niall" == Niall O'Reilly writes: Niall> OTOH, there's a balance to be struck between allowing Niall> people to be responsible for their own mistakes and Niall> engaging in the diminishing-returns game of protecting them Niall> from everything. Indeed. And in this case, sharp instruments need to be kept well away from the children. That means avoiding some of the obvious rat-holes when it comes to DNS administration. Note too Niall that lots of ISPs can't get RFC2317-style delegation right and these are the guys who should have DNS skills as a core competency. Niall> If registrars or T2 registries can't do their job, how long Niall> will they stay in business ? Long enough to kill off ENUM by making it seem less robust and dependable than it could be? Consumer confidence is going to be critical for ENUM to become widely used. Cheap calls over VoIP may get everyone's attention. But if DNS lookups fail and phones don't ring reliably, nobody's going to use it. From jim at rfc1035.com Thu Jul 15 15:40:57 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 15 Jul 2004 14:40:57 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: Message from "Niall O'Reilly" of "Thu, 15 Jul 2004 12:02:47 BST." <817E3A5A-D64E-11D8-8F56-000393D8D77E@ucd.ie> Message-ID: <20639.1089898857@gromit.rfc1035.com> >>>>> "Niall" == Niall O'Reilly writes: Niall> IMHO such registry systems are not suited to the ENUM Niall> business, and a T1 which takes this approach is unlikely to Niall> be winning many tenders for national infrastructure. Of Niall> course, that depends on the clue-level available to the Niall> local awarding agency. Niall> I'm happy to say that, here in +353-land, our trial T1 is Niall> taking a more helpful approach. Good. The key thing here is you have a trial. So you can try different delegation approaches and see what works and what doesn't. And aside from the DNS mechanics, you can consider things like the impact of a particular approach on interfaces, roles & responsibilities as well as stuff like competition policy and the public interest. IMO it's far more important to learn about these things than focus on which name server(s) some zone sits on. From Niall.oReilly at ucd.ie Thu Jul 15 16:31:39 2004 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 15 Jul 2004 15:31:39 +0100 Subject: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME In-Reply-To: <20639.1089898857@gromit.rfc1035.com> References: <20639.1089898857@gromit.rfc1035.com> Message-ID: On 15 Jul 2004, at 14:40, Jim Reid wrote: > So you can try different > delegation approaches and see what works and what doesn't. And aside > from the DNS mechanics, you can consider things like the impact of a > particular approach on interfaces, roles & responsibilities as well as > stuff like competition policy and the public interest. IMO it's far > more important to learn about these things than focus on which name > server(s) some zone sits on. No dispute there! Best regards, Niall O'Reilly UCD Computing Services From berni at birkenwald.de Fri Jul 16 18:59:28 2004 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri, 16 Jul 2004 18:59:28 +0200 Subject: [dns-wg] Stale restricted IPv6 information at Verisign/IANA Message-ID: <40F80970.1080805@birkenwald.de> Good evening, perhaps slightly off-topic, but nethertheless... I've been trying to readd an AAAA glue record to one of my nameservers in .net after the server moved from M"net space (2001:a60::/32) to TNIB (2001:1b18::/32). It worked before, after the move the registrar (dd24.net if anyone is curious) could not add the appropriate record: | [COMMAND] | command=ModifyNameserver | delipaddress0=212.90.120.82 | addipaddress0=81.92.162.8 | delipaddress1=2001:a60:9000:1000::1:11 | addipaddress1=2001:1B18:202:FFFF::53:1:1 | nameserver=auth01.dns.mucip.net | EOF | [RESPONSE] | code = 535 | description = Restricted IP address a quick query of the registrar at Verisign GRS resulted in Verisign claiming | The IPv6 you were trying to add is currently in a restricted range by | IANA. | | The IP 2001:1B18:202:FFFF::53:1:1 falls into the below restricted | range. | | 2001:1A00:: 2001:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF Well, 1b18 is slightly older than a60, so I decided to give Verisign a small hint that their list is out of date. Verisign although claims | WE are currently following the restricted v6 IP list which is mandated | by IANA and is current. | | We recommend that you contact IANA directly in regards to your matter. I tried to contact/blame IANA but I haven't received any reply so far. Anyone having an idea who the culprit is in this game? Bernhard From oppermann at pipeline.ch Fri Jul 16 15:32:43 2004 From: oppermann at pipeline.ch (Andre Oppermann) Date: Fri, 16 Jul 2004 15:32:43 +0200 Subject: [dns-wg] Reverse checker out-of-sync with RIPE-203 Message-ID: <40F7D8FB.4C86DD4@pipeline.ch> The reverse delegation checker on www.ripe.net seems to be out-of-sync with the recommended values in RIPE-203 (or vice-versa). For example RIPE-203 recommends 3600000 seconds (1000 hours = 5 weeks and something) for the SOA expire value. However if I actually put this into my zone file the checker at http://www.ripe.net/cgi-bin/nph-dc.cgi complains that this is too high and suggests a value between 2-4 weeks. Which is is right? One of these should be changed/corrected to resolve this discrepancy. PS: What are the current actual officially recommended SOA values for revese zones? -- Andre From pk at TechFak.Uni-Bielefeld.DE Mon Jul 19 09:47:37 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Mon, 19 Jul 2004 09:47:37 +0200 Subject: [dns-wg] Reverse checker out-of-sync with RIPE-203 In-Reply-To: Your message of "Fri, 16 Jul 2004 15:32:43 +0200." <40F7D8FB.4C86DD4@pipeline.ch> Message-ID: <200407190747.i6J7lbq06863@grimsvotn.TechFak.Uni-Bielefeld.DE> Andre Oppermann wrote: > For example RIPE-203 recommends 3600000 seconds (1000 hours = 5 weeks and > something) for the SOA expire value. However if I actually put this into > my zone file the checker at http://www.ripe.net/cgi-bin/nph-dc.cgi complains > that this is too high and suggests a value between 2-4 weeks. as far as I can see that is reported as a warning only. However, the reference to RFC 1912 is a bit outdated. There's a wg action item 48.3 (see action list at http://www.ripe.net/ripe/wg/dns/action-list.html) already to document, evaluate and replace as necessary the currently applied tests. Your suggestions are welcome. > Which is is right? One of these should be changed/corrected to resolve this > discrepancy. RIPE 203 aims at "small and stable" zones. Not all IN-ADDR.ARPA zones do fall into this category. The values suggested there may still be applicable to many IN-ADDR.ARPA zones, but that depends. -Peter From pk at TechFak.Uni-Bielefeld.DE Wed Jul 21 09:07:20 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 21 Jul 2004 09:07:20 +0200 Subject: [dns-wg] IPv6 glue AAAA RRs in the root zone Message-ID: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> Haven't seen an announcement right here, so FYI: as of SOA# 2004072000 the following AAAA RRs (aka "IPv6 glue") are available from within the root zone: A.DNS.JP. AAAA 2001:DC4:0:0:0:0:0:1 D.DNS.JP. AAAA 2001:240:0:0:0:0:0:53 E.DNS.JP. AAAA 2001:200:0:1:0:0:0:4 F.DNS.JP. AAAA 2001:2F8:0:100:0:0:0:153 G.DNS.KR. AAAA 2001:DC5:A:0:0:0:0:1 -Peter From bortzmeyer at nic.fr Wed Jul 21 09:16:46 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 21 Jul 2004 09:16:46 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040721071646.GA28704@nic.fr> On Wed, Jul 21, 2004 at 09:07:20AM +0200, Peter Koch wrote a message of 13 lines which said: > Haven't seen an announcement right here, so FYI: I do not know if this counts as an announcement: http://www.reuters.com/newsArticle.jhtml?type=internetNews&storyID=5717373 Do note that the IPv6 server of ".fr", requested in February 2003, is still not announced. From yasuhiro at jprs.co.jp Wed Jul 21 09:19:33 2004 From: yasuhiro at jprs.co.jp (Yasuhiro Orange Morishita / =?iso-2022-jp?B?GyRCPzkyPEJZOSgbKEI=?=) Date: Wed, 21 Jul 2004 16:19:33 +0900 (JST) Subject: [dns-wg] IPv6 glue AAAA RRs in the root zone In-Reply-To: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040721.161933.60854573.yasuhiro@jprs.co.jp> Yes, we are happy to announce about this: http://jprs.jp/en/press/20040721-e.html -- Yasuhiro 'Orange' Morishita DNS Technical Engineer Research and Development department, Japan Registry Service Co.,Ltd. (JPRS) E-Mail: yasuhiro at jprs.co.jp / orange at jprs.co.jp > Haven't seen an announcement right here, so FYI: > > as of SOA# 2004072000 the following AAAA RRs (aka "IPv6 glue") are available > from within the root zone: > > A.DNS.JP. AAAA 2001:DC4:0:0:0:0:0:1 > D.DNS.JP. AAAA 2001:240:0:0:0:0:0:53 > E.DNS.JP. AAAA 2001:200:0:1:0:0:0:4 > F.DNS.JP. AAAA 2001:2F8:0:100:0:0:0:153 > > G.DNS.KR. AAAA 2001:DC5:A:0:0:0:0:1 > > -Peter > From jeroen at unfix.org Wed Jul 21 09:29:40 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Jul 2004 09:29:40 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040721071646.GA28704@nic.fr> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> Message-ID: <1090394980.4858.101.camel@segesta.zurich.ibm.com> On Wed, 2004-07-21 at 09:16, Stephane Bortzmeyer wrote: > On Wed, Jul 21, 2004 at 09:07:20AM +0200, > Peter Koch wrote > a message of 13 lines which said: > > > Haven't seen an announcement right here, so FYI: > > I do not know if this counts as an announcement: > > http://www.reuters.com/newsArticle.jhtml?type=internetNews&storyID=5717373 > > Do note that the IPv6 server of ".fr", requested in February 2003, is > still not announced. Unless I completely mis-understood, but isn't that article talking about *root* servers and not GTLD servers, which Peter showed... Then again reuters is of course journalist blurb they can't tell the difference. Even though now .jp + .kr have a nameserver as glue as long as the roots are not available using IPv6 then it doesn't make a real difference as you can't reach them anyway over only IPv6... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From geoff at nominet.org.uk Wed Jul 21 09:37:11 2004 From: geoff at nominet.org.uk (Geoffrey Sisson) Date: Wed, 21 Jul 2004 08:37:11 +0100 (BST) Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone Message-ID: <20040721073711.01711E7EBA@mx1.nominet.org.uk> Stephane Bortzmeyer writes: > Do note that the IPv6 server of ".fr", requested in February 2003, is > still not announced. Maybe only coincidence: JPNIC = ccNSO member KRNIC = ccNSO member AFNIC = ccNSO non-member Regards Geoff From bortzmeyer at nic.fr Wed Jul 21 09:47:47 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 21 Jul 2004 09:47:47 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <1090394980.4858.101.camel@segesta.zurich.ibm.com> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> Message-ID: <20040721074747.GA30273@nic.fr> On Wed, Jul 21, 2004 at 09:29:40AM +0200, Jeroen Massar wrote a message of 48 lines which said: > Unless I completely mis-understood, but isn't that article talking > about *root* servers and not GTLD servers, which Peter showed... No, Peter was talking about root name servers, nothing changed for the ICANN gTLDs. > Even though now .jp + .kr have a nameserver as glue as long as the > roots are not available using IPv6 then it doesn't make a real > difference as you can't reach them anyway over only IPv6... Wrong, several root name servers (of course, not ICANN's one) are reachable over IPv6: read http://www.root-servers.org/ and edit your db.root. From bortzmeyer at nic.fr Wed Jul 21 09:57:59 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 21 Jul 2004 09:57:59 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040721071646.GA28704@nic.fr> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> Message-ID: <20040721075759.GA31267@nic.fr> On Wed, Jul 21, 2004 at 09:16:46AM +0200, Stephane Bortzmeyer wrote a message of 12 lines which said: > > Haven't seen an announcement right here, so FYI: > > I do not know if this counts as an announcement: > > http://www.reuters.com/newsArticle.jhtml?type=internetNews&storyID=5717373 The official one, better technically :-) http://www.icann.org/announcements/announcement-20jul04.htm From jeroen at unfix.org Wed Jul 21 10:33:54 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Jul 2004 10:33:54 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040721074747.GA30273@nic.fr> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> <20040721074747.GA30273@nic.fr> Message-ID: <1090398833.4858.119.camel@segesta.zurich.ibm.com> On Wed, 2004-07-21 at 09:47, Stephane Bortzmeyer wrote: > On Wed, Jul 21, 2004 at 09:29:40AM +0200, > Jeroen Massar wrote > a message of 48 lines which said: > > > Unless I completely mis-understood, but isn't that article talking > > about *root* servers and not GTLD servers, which Peter showed... > > No, Peter was talking about root name servers, nothing changed for the > ICANN gTLDs. > > > Even though now .jp + .kr have a nameserver as glue as long as the > > roots are not available using IPv6 then it doesn't make a real > > difference as you can't reach them anyway over only IPv6... > > Wrong, several root name servers (of course, not ICANN's one) are > reachable over IPv6: read http://www.root-servers.org/ and edit your > db.root. I know those addresses and I also know that all of those boxes have a latency over at least 200ms and very odd routability and those are far far far from to be called production. One really doesn't want to use those, just to be able to say that one can use IPv6.... BTW that list is missing i.root-servers.org which is located in Sweden, but that is a testing address and routes over the US instead of staying inside Europe... Greets, Jeroen -- Just to make my point, traces from noc.sixxs.net: B.root-servers.org: traceroute to 2001:478:65::53 (2001:478:65::53) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.612 ms 0.357 ms 0.409 ms 2 at-0-0-1.schiphol-rijk.ipv6.concepts-ict.net (2001:838:0:12::1) 3.943 ms 3.955 ms 3.908 ms 3 ge-1-0-0.nikhef.ipv6.concepts-ict.net (2001:838:0:11::1) 4.572 ms 4.554 ms 4.515 ms 4 eth10-0-0.xr1.ams1.gblx.net (2001:7f8:1::a500:3549:1) 4.722 ms 5.136 ms 4.718 ms 5 2001:450:1:1::22 (2001:450:1:1::22) 160.68 ms * 160.748 ms 6 3ffe:80a::10 (3ffe:80a::10) 156.026 ms 155.655 ms 155.943 ms 7 * * * 8 * F.root-servers.org: traceroute to 2001:500::1035 (2001:500::1035) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.385 ms 0.35 ms 0.341 ms 2 at-0-0-1.schiphol-rijk.ipv6.concepts-ict.net (2001:838:0:12::1) 3.929 ms 3.909 ms 3.904 ms 3 ge-1-0-0.nikhef.ipv6.concepts-ict.net (2001:838:0:11::1) 4.56 ms 4.525 ms 4.513 ms 4 ge-0.ams-ix.amstnl02.nl.bb.verio.net (2001:7f8:1::a500:2914:1) 4.722 ms 4.734 ms 4.869 ms 5 p16-1-0-0.r80.asbnva01.us.bb.verio.net (2001:418:0:2000::2b5) 86.17 ms 86.037 ms 85.92 ms 6 p16-1-2-0.r21.asbnva01.us.bb.verio.net (2001:418:0:2000::89) 86.039 ms 88.355 ms 85.984 ms 7 p16-0-1-2.r20.plalca01.us.bb.verio.net (2001:418:0:2000::101) 146.398 ms 146.33 ms 146.32 ms 8 ge-6-1.a01.snfcca05.us.ra.verio.net (2001:418:0:702b::4) 147.015 ms 146.816 ms 146.932 ms 9 fa-4-6.a01.snfcca05.us.ce.verio.net (2001:418:1c00:5000::2) 147.053 ms 146.995 ms 147.068 ms 10 2001:500::1035 (2001:500::1035) 147.002 ms 147.054 ms 146.961 ms H.root-servers.org: traceroute to 2001:500:1::803f:235 (2001:500:1::803f:235) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.386 ms !H 0.347 ms !H 0.349 ms !H Which gets announced as a /48 thus doesn't come through the filters... M.root-servers.org: traceroute to 2001:dc3::35 (2001:dc3::35) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.376 ms 0.356 ms 0.333 ms 2 at-0-0-1.schiphol-rijk.ipv6.concepts-ict.net (2001:838:0:12::1) 3.918 ms 3.907 ms 3.895 ms 3 ge-1-0-0.nikhef.ipv6.concepts-ict.net (2001:838:0:11::1) 4.629 ms 4.533 ms 4.52 ms 4 eth10-0-0.xr1.ams1.gblx.net (2001:7f8:1::a500:3549:1) 7.297 ms 5.652 ms 4.703 ms 5 2001:450:1:1::22 (2001:450:1:1::22) 160.476 ms * 160.764 ms 6 3ffe:80a::10 (3ffe:80a::10) 155.729 ms 155.724 ms 155.655 ms 7 3ffe:80a::2 (3ffe:80a::2) 154.208 ms 153.992 ms 153.945 ms 8 otm6-bb1.IIJ.Net (2001:240:100:ffff::ff) 285.941 ms otm6-bb0.IIJ.Net (2001:240:100:fffe::ff) 286.119 ms 286.328 ms 9 tky001ix06.IIJ.Net (2001:240:100:2::30) 286.458 ms tky001ix06.IIJ.Net (2001:240:100:1::30) 286.441 ms otm6-gate0.IIJ.Net (2001:240:100::204) 286.345 ms 10 2001:200:0:1800::1d4c:3 (2001:200:0:1800::1d4c:3) 287.073 ms 287.17 ms 287.266 ms 11 2001:dc3::35 (2001:dc3::35) 287.178 ms 287.018 ms 287.981 ms -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From jim at rfc1035.com Wed Jul 21 10:52:28 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 21 Jul 2004 09:52:28 +0100 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: Message from Stephane Bortzmeyer of "Wed, 21 Jul 2004 09:47:47 +0200." <20040721074747.GA30273@nic.fr> Message-ID: <800.1090399948@gromit.rfc1035.com> >>>>> "Stephane" == Stephane Bortzmeyer writes: >> Unless I completely mis-understood, but isn't that article >> talking about *root* servers and not GTLD servers, which Peter >> showed... Stephane> No, Peter was talking about root name servers I thought he was talking about the name servers for .jp. Which happen to be in the root zone that's served by the root servers.... no? From pk at TechFak.Uni-Bielefeld.DE Wed Jul 21 11:06:38 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 21 Jul 2004 11:06:38 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: Your message of "Wed, 21 Jul 2004 09:47:47 +0200." <20040721074747.GA30273@nic.fr> Message-ID: <200407210906.i6L96cX13211@grimsvotn.TechFak.Uni-Bielefeld.DE> > No, Peter was talking about root name servers, nothing changed for the At least this Peter wasn't. I talked about the root *zone*. The press article was "interesting", but thanks for the pointer to the ICANN website. Missed that while looking at IANA's where the new policy document was referenced, which (i.e. our discussion of that document) was the reason to point to its implementation. -Peter From jim at rfc1035.com Wed Jul 21 11:11:07 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 21 Jul 2004 10:11:07 +0100 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: Message from Jeroen Massar of "Wed, 21 Jul 2004 10:33:54 +0200." <1090398833.4858.119.camel@segesta.zurich.ibm.com> Message-ID: <830.1090401067@gromit.rfc1035.com> >>>>> "Jeroen" == Jeroen Massar writes: >> Wrong, several root name servers (of course, not ICANN's one) >> are reachable over IPv6: read http://www.root-servers.org/ >> and edit your db.root. Jeroen> I know those addresses and I also know that all of those Jeroen> boxes have a latency over at least 200ms and very odd Jeroen> routability and those are far far far from to be called Jeroen> production. This could be a good topic for presenting to the WG. Want to volunteer to write up a document and/or presentation on the state of IPv6 deployment in the root and TLD name servers, routing anomalies, etc, etc? It would be good to hear someone's first-hand experiences with this stuff: what went wrong, how it was worked around or solved, what could be done better, future directions. Personally, I don't see why you care about the RTT to a root server. A well-behaved name server will make 4-5 queries to a root server once a week or so. Why optimise that? Please note I'm not suggesting that it's OK for root servers to have lousy RTTs. My name server is in regular, frequent contact with other name servers that have RTTs longer than 200ms. Jeroen> One really doesn't want to use those, just to be able to Jeroen> say that one can use IPv6.... Well, what other choice is there? :-) And anyway, since the overwhelming bulk of the world's name servers are IPv4-only, resolution over IPv6 doesn't seem to be a particularly productive exercise. Jeroen> BTW that list is missing i.root-servers.org which is Jeroen> located in Sweden, but that is a testing address and Jeroen> routes over the US instead of staying inside Europe... Why does it matter where a root name server is physically located? Sorry, I should rephrase that: why does it matter where a route for a root name server gets announced? IMO a 200ms RTT over IPv6 has to be better than an infinite RTT. From kurtis at kurtis.pp.se Wed Jul 21 11:42:20 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 21 Jul 2004 11:42:20 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <1090398833.4858.119.camel@segesta.zurich.ibm.com> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> <20040721074747.GA30273@nic.fr> <1090398833.4858.119.camel@segesta.zurich.ibm.com> Message-ID: <42B1879C-DAFA-11D8-9444-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-07-21, at 10.33, Jeroen Massar wrote: > BTW that list is missing i.root-servers.org which is located in Sweden, > but that is a testing address and routes over the US instead of staying > inside Europe... > Yes, you can try out 2001:7fe::53 for i.root-servers.net. We have this week ben busy working on the Ipv6 network and we are trying to get stable connectivity to i.root. As of today you should see a somewhat shorter path to i.root. We are also bringing up more peerings that will hopefully help to cut down latency. Feel free to use the address above, but please note that it's not listed publicly for a reason (although we appreciate any outage reports to dns-noc at netnod.se). - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQP46gaarNKXTPFCVEQJATQCfWu8xg2AtkkDm83Et5Bzto387A4sAmgJK 9Fw6EXLK2/U//xR5AVFUHkhI =UMXv -----END PGP SIGNATURE----- From jeroen at unfix.org Wed Jul 21 11:42:40 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Jul 2004 11:42:40 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <830.1090401067@gromit.rfc1035.com> References: <830.1090401067@gromit.rfc1035.com> Message-ID: <1090402959.4858.148.camel@segesta.zurich.ibm.com> [Added CC to ipv6-wg at ripe.net, where IMHO this belongs ;) ] On Wed, 2004-07-21 at 11:11, Jim Reid wrote: > >>>>> "Jeroen" == Jeroen Massar writes: > > >> Wrong, several root name servers (of course, not ICANN's one) > >> are reachable over IPv6: read http://www.root-servers.org/ > >> and edit your db.root. > > Jeroen> I know those addresses and I also know that all of those > Jeroen> boxes have a latency over at least 200ms and very odd > Jeroen> routability and those are far far far from to be called > Jeroen> production. > > This could be a good topic for presenting to the WG. Want to volunteer > to write up a document and/or presentation on the state of IPv6 > deployment in the root and TLD name servers, routing anomalies, etc, > etc? It would be good to hear someone's first-hand experiences with > this stuff: what went wrong, how it was worked around or solved, what > could be done better, future directions. Check http://www.sixxs.net/misc/latency/ and select the "IPv6 between POPs and well known destinations" option to reveal some ugglyness. I've been monitoring most of them for quite some time already and I also did some testing with the IPv6 only test root's (see http://www.rs.net) The POPs mentioned btw are the located all over Europe at various independent ISP's add .sixxs.net to find out exactly where or see the POP page on the site. Average latency to b.root-servers.net at least 294ms. H.root-servers.net was gone for sunday to monday and so on.... Not even minding the packetloss. E and I are also there btw, though that is not on the root-servers.org site. > Personally, I don't see why you care about the RTT to a root server. A > well-behaved name server will make 4-5 queries to a root server once a > week or so. That is indeed true, but it is rather odd when a machine is physically close and good connectivity between for instance Amsterdam and Sweden exists and then one still has traffic going over the US... But this is more a problem of the state of the IPv6 routing tables and the fact that only I is in europe and is only even testing IPv6 connectivity. Thus a presentation or better a debate about how the IPv6 routing can be improved in general would be a better subject and prolly the place for that is the ipv6-wg. But as people know who go there Gert Doering has been doing those updates for quite some time already and last time at least there was some discussion about the MIPP draft. Even as it has improved considerably in the last couple of years we are not there yet.. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From kurtis at kurtis.pp.se Wed Jul 21 11:45:39 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 21 Jul 2004 11:45:39 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <830.1090401067@gromit.rfc1035.com> References: <830.1090401067@gromit.rfc1035.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-07-21, at 11.11, Jim Reid wrote: > > Jeroen> BTW that list is missing i.root-servers.org which is > Jeroen> located in Sweden, but that is a testing address and > Jeroen> routes over the US instead of staying inside Europe... > > Why does it matter where a root name server is physically located? > Sorry, I should rephrase that: why does it matter where a route for a > root name server gets announced? > > IMO a 200ms RTT over IPv6 has to be better than an infinite RTT. Although I agree in principle from a DNS perspective - the high RTT in most occasions indicates tunneling. And although tunneling per-se is not that bad, it is much more vulnerable to problems in the underlaying routing and most of all, much harder to diagnose from the "outside". - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQP47R6arNKXTPFCVEQIVIACfT2aoJQviSEoGlOhI1/gFn7ZuXpkAoIsP NclE/WfB/ZG6tAHIQvofpi/X =1IjQ -----END PGP SIGNATURE----- From jeroen at unfix.org Wed Jul 21 11:49:03 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Jul 2004 11:49:03 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <42B1879C-DAFA-11D8-9444-000A95928574@kurtis.pp.se> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> <20040721074747.GA30273@nic.fr> <1090398833.4858.119.camel@segesta.zurich.ibm.com> <42B1879C-DAFA-11D8-9444-000A95928574@kurtis.pp.se> Message-ID: <1090403342.4858.155.camel@segesta.zurich.ibm.com> On Wed, 2004-07-21 at 11:42, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2004-07-21, at 10.33, Jeroen Massar wrote: > > > BTW that list is missing i.root-servers.org which is located in Sweden, > > but that is a testing address and routes over the US instead of staying > > inside Europe... > > > > Yes, you can try out 2001:7fe::53 for i.root-servers.net. We have this > week ben busy working on the Ipv6 network and we are trying to get > stable connectivity to i.root. As of today you should see a somewhat > shorter path to i.root. We are also bringing up more peerings that will > hopefully help to cut down latency. > > Feel free to use the address above, but please note that it's not > listed publicly for a reason (although we appreciate any outage reports > to dns-noc at netnod.se). Indeed, I know see various paths coming in over AORTA (Chello) etc. That is starting to become better. The roundtrip-paths are async over the US still though :( I've passed the above on to some other IPv6 routing fora maybe that should get some attention. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From jordi.palet at consulintel.es Wed Jul 21 11:51:36 2004 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 21 Jul 2004 11:51:36 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone References: <830.1090401067@gromit.rfc1035.com> Message-ID: <0dff01c46f08$52cdb150$8700000a@consulintel.es> Probably this is relevant for this thread even when the test not done in root servers ... http://www.ist-ipv6.org/modules.php?op=modload&name=News&file=article&sid=613 ----- Original Message ----- From: "Kurt Erik Lindqvist" To: "Jim Reid" Cc: "Peter Koch" ; "Stephane Bortzmeyer" ; "Jeroen Massar" ; Sent: Wednesday, July 21, 2004 11:45 AM Subject: Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2004-07-21, at 11.11, Jim Reid wrote: > > > > > Jeroen> BTW that list is missing i.root-servers.org which is > > Jeroen> located in Sweden, but that is a testing address and > > Jeroen> routes over the US instead of staying inside Europe... > > > > Why does it matter where a root name server is physically located? > > Sorry, I should rephrase that: why does it matter where a route for a > > root name server gets announced? > > > > IMO a 200ms RTT over IPv6 has to be better than an infinite RTT. > > Although I agree in principle from a DNS perspective - the high RTT in > most occasions indicates tunneling. And although tunneling per-se is > not that bad, it is much more vulnerable to problems in the underlaying > routing and most of all, much harder to diagnose from the "outside". > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQP47R6arNKXTPFCVEQIVIACfT2aoJQviSEoGlOhI1/gFn7ZuXpkAoIsP > NclE/WfB/ZG6tAHIQvofpi/X > =1IjQ > -----END PGP SIGNATURE----- > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From brad.knowles at skynet.be Wed Jul 21 11:50:55 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 21 Jul 2004 11:50:55 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <830.1090401067@gromit.rfc1035.com> References: <830.1090401067@gromit.rfc1035.com> Message-ID: At 10:11 AM +0100 2004-07-21, Jim Reid wrote: > Personally, I don't see why you care about the RTT to a root server. A > well-behaved name server will make 4-5 queries to a root server once a > week or so. Why optimise that? Please note I'm not suggesting that > it's OK for root servers to have lousy RTTs. My name server is in > regular, frequent contact with other name servers that have RTTs > longer than 200ms. Well, I'm not an IPv6 expert by any stretch of the imagination, but the impression I got was that if you were IPv6-only, and all the root nameservers you can reach via IPv6 are routed via highly undesirable paths, then you would be in a pretty bad situation. It's fine for some of those IPv6 addresses to be non-production or very sub-optimally routed, but I think the problem comes from when that happens to all of them. At least, that was my take. > Well, what other choice is there? :-) And anyway, since the overwhelming > bulk of the world's name servers are IPv4-only, resolution over IPv6 > doesn't seem to be a particularly productive exercise. True enough. Thinking about it some more, I can't imagine anyone in the real world today who might be forced to be in an IPv6-only environment. However, I can imagine a lot of groups that would want significant testing to be done in IPv6-only environments, to try and simulate as best as possible what the real world would look like in the near future, when some people might start to be put in this boat. They would be unable to expand those tests to other groups, until the IPv6-only access is improved. This would also force them to roll back the initial implementation period for real users. And they'd be in a world of pain if they had already committed to IPv6-only service for certain groups, and then be unable to deliver to them. It seems to me that the folks in Asia would be most likely to be hurt by this, as well as anyone who is working on the "ubiquitous computing" environments where anything with a battery, power cord, or display would be given it's own IP address. > Why does it matter where a root name server is physically located? > Sorry, I should rephrase that: why does it matter where a route for a > root name server gets announced? > > IMO a 200ms RTT over IPv6 has to be better than an infinite RTT. But if they're all 200ms for IPv6-only, that may effectively prohibit the deployment of IPv6-only networks (or even IPv6-first networks), until such time as the RTT is improved to a more adequate level. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From kurtis at kurtis.pp.se Wed Jul 21 13:12:52 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Wed, 21 Jul 2004 13:12:52 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <1090403342.4858.155.camel@segesta.zurich.ibm.com> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> <20040721074747.GA30273@nic.fr> <1090398833.4858.119.camel@segesta.zurich.ibm.com> <42B1879C-DAFA-11D8-9444-000A95928574@kurtis.pp.se> <1090403342.4858.155.camel@segesta.zurich.ibm.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> BTW that list is missing i.root-servers.org which is located in >>> Sweden, >>> but that is a testing address and routes over the US instead of >>> staying >>> inside Europe... >>> >> >> Yes, you can try out 2001:7fe::53 for i.root-servers.net. We have this >> week ben busy working on the Ipv6 network and we are trying to get >> stable connectivity to i.root. As of today you should see a somewhat >> shorter path to i.root. We are also bringing up more peerings that >> will >> hopefully help to cut down latency. >> >> Feel free to use the address above, but please note that it's not >> listed publicly for a reason (although we appreciate any outage >> reports >> to dns-noc at netnod.se). > > Indeed, I know see various paths coming in over AORTA (Chello) etc. > That is starting to become better. The roundtrip-paths are async over > the US still though :( > > I've passed the above on to some other IPv6 routing fora maybe that > should get some attention. (this is getting seriously off-topic) What I did notice today, while doing some work on the routing, is that BGP changes seems to take forever to propagate through the IPv6 routing table. A change that to our direct peers lasted less than 5 minutes, lead to down-time of around 20 minutes for a host in the US. Wired. As for the paths, we should have more peers up by the end of the week. If you are an ISP, and your are present at Netnod, and you would like to investigate IPv6 peering with the root-server, send a mail to peering at netnod.se. I was almost going to offer tunnels with BGP over them to anyone, but I realized I would never be able to migrate away from that swap so I won't :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQP5Pt6arNKXTPFCVEQIN5gCg1ls4DWw+OzoNhuTk755oeAURqo8An2VX Tix22ttp2f8UTyVCkRy8CIRs =Z51y -----END PGP SIGNATURE----- From jabley at isc.org Wed Jul 21 14:57:40 2004 From: jabley at isc.org (Joe Abley) Date: Wed, 21 Jul 2004 19:57:40 +0700 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040721074747.GA30273@nic.fr> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> <20040721074747.GA30273@nic.fr> Message-ID: <8C91DDFD-DB15-11D8-9800-000A95E7E6B4@isc.org> On 21 Jul 2004, at 14:47, Stephane Bortzmeyer wrote: > Wrong, several root name servers (of course, not ICANN's one) are > reachable over IPv6: read http://www.root-servers.org/ and edit your > db.root. With BIND, the hints file is used to bootstrap a nameserver such that it can find answers to the question "dig . NS", with attendant glue. Once such an answer has been received, the hints file is not used any more. So editing the hints file to include AAAA records might cause the first query a recursive nameserver makes after boot to be carried over IPv6, but until there are AAAA records in the root zone, all subsequent queries to the root will be sent over IPv4. It would be interesting to know what a recursive nameserver with AAAA records added to its hints file and no IPv4 transit would do, after it got an answer with no IPv6 glue from a root nameserver, though. I haven't tried it. Joe From jabley at isc.org Wed Jul 21 15:02:19 2004 From: jabley at isc.org (Joe Abley) Date: Wed, 21 Jul 2004 20:02:19 +0700 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <1090398833.4858.119.camel@segesta.zurich.ibm.com> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> <20040721074747.GA30273@nic.fr> <1090398833.4858.119.camel@segesta.zurich.ibm.com> Message-ID: <32E712DE-DB16-11D8-9800-000A95E7E6B4@isc.org> On 21 Jul 2004, at 15:33, Jeroen Massar wrote: > F.root-servers.org: > > traceroute to 2001:500::1035 (2001:500::1035) from > 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets > 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.385 ms > 0.35 ms 0.341 ms [etc] We are trying hard to make F available from our anycast nodes on its IPv6 address. Finding exchange points which (a) will give you v6 addresses and (b) have peers which will peer with you over IPv6 is not trivial, however. > H.root-servers.org: > > traceroute to 2001:500:1::803f:235 (2001:500:1::803f:235) from > 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets > 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.386 ms !H > 0.347 ms !H 0.349 ms !H > > Which gets announced as a /48 thus doesn't come through the filters... If that doesn't make it through your filters, then your filters are broken. 2001:500:1::/48 is an ARIN micro-allocation, and it is perfectly legitimate to advertise it with no covering /32 supernet. Incidentally, F is also announced as a /48, and is also an ARIN micro allocation (the first one they made, in fact). 2001:500::/48 seems to get through your filters ok. Joe From jeroen at unfix.org Wed Jul 21 18:03:11 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 21 Jul 2004 18:03:11 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <8C91DDFD-DB15-11D8-9800-000A95E7E6B4@isc.org> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> <20040721074747.GA30273@nic.fr> <8C91DDFD-DB15-11D8-9800-000A95E7E6B4@isc.org> Message-ID: <1090425790.16467.297.camel@segesta.zurich.ibm.com> [ note: aggregated mails ;) ] On Wed, 2004-07-21 at 14:57, Joe Abley wrote: > On 21 Jul 2004, at 14:47, Stephane Bortzmeyer wrote: > > > Wrong, several root name servers (of course, not ICANN's one) are > > reachable over IPv6: read http://www.root-servers.org/ and edit your > > db.root. > > With BIND, the hints file is used to bootstrap a nameserver such that > it can find answers to the question "dig . NS", with attendant glue. > Once such an answer has been received, the hints file is not used any > more. Remove the hints and 'load' your roots as a master, that is the trick I employ when I want to use alternate roots. Bind will complain but won't dig ;) Dirty trick and indeed as you mentioned the AAAA's should be in the root (.) otherwise everybody will have to do this dirtywork. > It would be interesting to know what a recursive nameserver with AAAA > records added to its hints file and no IPv4 transit would do, after it > got an answer with no IPv6 glue from a root nameserver, though. I > haven't tried it. It throws away your hints information thus basically it is left dead on the street... On Wed, 2004-07-21 at 15:02, Joe Abley wrote: > On 21 Jul 2004, at 15:33, Jeroen Massar wrote: > > > F.root-servers.org: > > > > traceroute to 2001:500::1035 (2001:500::1035) from > > 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets > > 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.385 ms > > 0.35 ms 0.341 ms > > [etc] > > We are trying hard to make F available from our anycast nodes on its > IPv6 address. Finding exchange points which (a) will give you v6 > addresses and (b) have peers which will peer with you over IPv6 is not > trivial, however. Then I should advise you to come to the AMS-IX, there is no F there and it should not be hard to get IPv6 from the IX nor transit nor peers. Just give them a shout and I am sure people are willing to help out. > > H.root-servers.org: > > > > traceroute to 2001:500:1::803f:235 (2001:500:1::803f:235) from > > 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets > > 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.386 ms !H > > 0.347 ms !H 0.349 ms !H > > > > Which gets announced as a /48 thus doesn't come through the filters... > > If that doesn't make it through your filters, then your filters are > broken. 2001:500:1::/48 is an ARIN micro-allocation, and it is > perfectly legitimate to advertise it with no covering /32 supernet. > > Incidentally, F is also announced as a /48, and is also an ARIN micro > allocation (the first one they made, in fact). 2001:500::/48 seems to > get through your filters ok. This is indeed something odd, as can be seen in GRH* most ISP's get it and indeed the 2001:500:1::/48 doesn't get trough, I've taken it up with AS12871 who provide the connectivity for that machine and they control the filters not me ;) * = http://www.sixxs.net/tools/grh/lg/?find=2001:500::/32 Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From daniel.karrenberg at ripe.net Wed Jul 21 23:10:36 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 21 Jul 2004 23:10:36 +0200 Subject: [dns-wg] FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: <200407131411.i6DEBP717249@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <40F39425.2080006@ripe.net> <200407131411.i6DEBP717249@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040721211036.GA5422@reifa.local> On 13.07 16:11, Peter Koch wrote: > Andrei, > thanks for the pointer! > Now, what are "reasonable queries"? [sorry, huge mail backlog] This wording indeed has its origin in section 1 of http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf which explains why *any* query would be a stupid wording. Hence this wording was the most reasonable (sic ;-). Daniel From daniel.karrenberg at ripe.net Wed Jul 21 23:30:46 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 21 Jul 2004 23:30:46 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040721075759.GA31267@nic.fr> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <20040721075759.GA31267@nic.fr> Message-ID: <20040721213045.GB5422@reifa.local> On 21.07 09:57, Stephane Bortzmeyer wrote: > > The official one, better technically :-) > > http://www.icann.org/announcements/announcement-20jul04.htm Isn't that lovely? So this was really and wholly an ICANN achievement? I hate announcmenets by bureaucrats about "their" achievements when their main contribution really is to introduce unnecessary friction, entropy and delay. Don't get me wrong: changes to root zone management require process. I am arguing *for* giving the IANA more discretion in timely operational matters, like part of the new procedure does. I just wish that both IANA and ICANN will increase the effectiveness of their processes and be *much* more humble about their role and contributions. Anyway: I am happy this has finally happened! Daniel From bortzmeyer at nic.fr Thu Jul 22 09:38:52 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 22 Jul 2004 09:38:52 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040721071646.GA28704@nic.fr> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> Message-ID: <20040722073852.GA27063@nic.fr> On Wed, Jul 21, 2004 at 09:16:46AM +0200, Stephane Bortzmeyer wrote a message of 12 lines which said: > Do note that the IPv6 server of ".fr", requested in February 2003, is > still not announced. Done this night. ~ % dig @k.root-servers.net NS fr. ; <<>> DiG 9.2.4rc5 <<>> @k.root-servers.net NS fr. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10236 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9 ;; QUESTION SECTION: ;fr. IN NS ;; AUTHORITY SECTION: fr. 172800 IN NS dns.cs.wisc.edu. fr. 172800 IN NS ns1.nic.fr. fr. 172800 IN NS dns.inria.fr. fr. 172800 IN NS ns2.nic.fr. fr. 172800 IN NS dns.princeton.edu. fr. 172800 IN NS ns-ext.vix.com. fr. 172800 IN NS ns3.domain-registry.nl. fr. 172800 IN NS c.nic.fr. ;; ADDITIONAL SECTION: dns.cs.wisc.edu. 172800 IN A 128.105.2.10 ns1.nic.fr. 172800 IN A 192.93.0.1 dns.inria.fr. 172800 IN A 193.51.208.13 ns2.nic.fr. 172800 IN A 192.93.0.4 dns.princeton.edu. 172800 IN A 128.112.129.15 ns-ext.vix.com. 172800 IN A 204.152.184.64 ns3.domain-registry.nl. 172800 IN A 193.176.144.6 c.nic.fr. 172800 IN A 192.134.0.49 c.nic.fr. 172800 IN AAAA 2001:660:3006:1::1:1 ;; Query time: 16 msec ;; SERVER: 193.0.14.129#53(k.root-servers.net) ;; WHEN: Thu Jul 22 09:38:44 2004 ;; MSG SIZE rcvd: 377 From jeroen at unfix.org Thu Jul 22 09:47:04 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 22 Jul 2004 09:47:04 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040722073852.GA27063@nic.fr> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <20040722073852.GA27063@nic.fr> Message-ID: <1090482424.16467.323.camel@segesta.zurich.ibm.com> On Thu, 2004-07-22 at 09:38, Stephane Bortzmeyer wrote: > On Wed, Jul 21, 2004 at 09:16:46AM +0200, > Stephane Bortzmeyer wrote > a message of 12 lines which said: > > > Do note that the IPv6 server of ".fr", requested in February 2003, is > > still not announced. > > Done this night. Congratulations! Your hard fighting finally worked out ;) Now pray for .de Btw, is there a list of TLD's which support IPv6, transport and NS glue. Of course with a pointer where to request it ;) I hope to see it soon for .com/net/org and .ch + .nl too... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From bortzmeyer at nic.fr Thu Jul 22 09:57:50 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 22 Jul 2004 09:57:50 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <1090482424.16467.323.camel@segesta.zurich.ibm.com> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <20040722073852.GA27063@nic.fr> <1090482424.16467.323.camel@segesta.zurich.ibm.com> Message-ID: <20040722075750.GA28862@nic.fr> On Thu, Jul 22, 2004 at 09:47:04AM +0200, Jeroen Massar wrote a message of 42 lines which said: > Now pray for .de They made a formal request? When? Ours took 17 months to proceed. From daniel.karrenberg at ripe.net Thu Jul 22 10:13:01 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 22 Jul 2004 10:13:01 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040722075750.GA28862@nic.fr> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <20040722073852.GA27063@nic.fr> <1090482424.16467.323.camel@segesta.zurich.ibm.com> <20040722075750.GA28862@nic.fr> Message-ID: <20040722081301.GD5422@reifa.local> On 22.07 09:57, Stephane Bortzmeyer wrote: > They made a formal request? When? Ours took 17 months to proceed. Now that IANA *finally* have the rpocedure in place this should be much quicker. Daniel From Mohsen.Souissi at nic.fr Thu Jul 22 11:20:12 2004 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Thu, 22 Jul 2004 11:20:12 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040721073711.01711E7EBA@mx1.nominet.org.uk> References: <20040721073711.01711E7EBA@mx1.nominet.org.uk> Message-ID: <20040722092012.GR76622@kerkenna.nic.fr> Hi Geoffrey & all, On 21 Jul, Geoffrey Sisson wrote: | Stephane Bortzmeyer writes: | | > Do note that the IPv6 server of ".fr", requested in February 2003, is | > still not announced. | | Maybe only coincidence: | | JPNIC = ccNSO member | KRNIC = ccNSO member | AFNIC = ccNSO non-member | ==> There's definitely no connection. I won't dwell on politics issues. Please let me give you some technical explanations for the delay (since .fr glue was published a few hours later than .jp and .kr). The .fr glue ought to be published at the same time as .jp and .kr glue. The delay is only due to the change of ns3.nic.fr name into c.nic.fr (with th same A and AAAA RRs) in the NS list for .fr. The main reason is that ns3.nic.fr already hosts about 19 other TLDs and publishing the AAAA RR for .fr implies publishing it also for the other TLDs for consistency reasons. So, AFNIC had two choices : 1) to ask all the admin & tech contacts of all those TLDs for their agreement for AAAA publication 2) to perform that change ns3.nic.fr --> c.nic.fr on July 20th ==> The 1st choice would have taken several days (or weeks) The second choice took us less than 12 hours (including a.root-servers.net reload delay). This choice is a preparation for fr NS compression to be done soon as specified at section 6 of http://w6.nic.fr/dnsv6/resp-size.html (note that document was yet another technical one to persuade ICANN/IANA to go forward with IPv6 AAAA glue). Regards, Mohsen. From bortzmeyer at nic.fr Thu Jul 22 11:23:16 2004 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 22 Jul 2004 11:23:16 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <1090482424.16467.323.camel@segesta.zurich.ibm.com> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <20040722073852.GA27063@nic.fr> <1090482424.16467.323.camel@segesta.zurich.ibm.com> Message-ID: <20040722092316.GA21177@nic.fr> On Thu, Jul 22, 2004 at 09:47:04AM +0200, Jeroen Massar wrote a message of 42 lines which said: > Btw, is there a list of TLD's which support IPv6, transport and NS > glue. Using only nameservers whose name is in the TLD (otherwise ns.ripe.net would give the impression of wide IPv6 adoption), twelve TLDs, all of them ccTLDs: CH: domreg.nic.CH. (2001:620:0:3:a00:20ff:fe85:9276) merapi.switch.CH. (2001:620::5) merapi.switch.CH. (2001:620:0:1:a00:20ff:fe88:a3f8) DE: a.nic.DE. (2001:608:6::5) EE: dns.estpak.EE. (2001:7d0:0:e010::1) FR: c.nic.FR. (2001:660:3006:1::1:1) IR: ns.nic.IR. (2001:960:618:70::89) persia.nic.IR. (2001:960:618:70::84) IT: dns.nic.IT. (2001:760:600:1::5) JP: d.dns.JP. (2001:240::53) e.dns.JP. (2001:200:0:1::4) a.dns.JP. (2001:dc4::1) f.dns.JP. (2001:2f8:0:100::153) KR: g.dns.KR. (2001:dc5:a::1) PT: ns2.dns.PT. (2001:690:a80:4001::100) SE: g.ns.SE. (2001:6b0:8:1::53) f.ns.SE. (2001:6b0:7::53) TN: ns.ati.TN. (2001:970:1:1::10) TW: a.dns.TW. (2001:cd8:800::8) c.dns.TW. (2001:238:800:1::1) d.dns.TW. (2001:c50:ffff:1::230) > Of course with a pointer where to request it ;) Attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: find-tld.sh Type: application/x-sh Size: 789 bytes Desc: not available URL: From pk at TechFak.Uni-Bielefeld.DE Thu Jul 22 11:30:58 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 22 Jul 2004 11:30:58 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: Your message of "Thu, 22 Jul 2004 11:20:12 +0200." <20040722092012.GR76622@kerkenna.nic.fr> Message-ID: <200407220930.i6M9UwL19567@grimsvotn.TechFak.Uni-Bielefeld.DE> Mohsen Souissi wrote: > The second choice took us less than 12 hours (including now, could you see an increase in the number of queries sent to this server via IPv6? It wasn't zero before I suppose since the AAAA RR was already present, although not as glue. -Peter From pk at TechFak.Uni-Bielefeld.DE Thu Jul 22 11:52:27 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 22 Jul 2004 11:52:27 +0200 Subject: [dns-wg] FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: Your message of "Wed, 21 Jul 2004 23:10:36 +0200." <20040721211036.GA5422@reifa.local> Message-ID: <200407220952.i6M9qSd19664@grimsvotn.TechFak.Uni-Bielefeld.DE> Daniel Karrenberg wrote: > This wording indeed has its origin in section 1 of > http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf I had already read that paper. The term "reasonable queries" appears exactly once and even then it is not defined but states that "response sizes for reasonable queries do not exceed the 512 octet limit". That's where we started. > which explains why *any* query would be a stupid wording. The rest of your paper suggests that "reasonable" may mean a query pattern that is found in real life at a (subset of the) root nameserver(s). At least that would sound not unreasonable to me. But we're talking about a policy document here - why does that use/have to use such fuzzy wording? -Peter From Mohsen.Souissi at nic.fr Thu Jul 22 11:55:25 2004 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Thu, 22 Jul 2004 11:55:25 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <200407220930.i6M9UwL19567@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <20040722092012.GR76622@kerkenna.nic.fr> <200407220930.i6M9UwL19567@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040722095525.GT76622@kerkenna.nic.fr> On 22 Jul, Peter Koch wrote: | Mohsen Souissi wrote: | | > The second choice took us less than 12 hours (including | | now, could you see an increase in the number of queries sent to this server | via IPv6? It wasn't zero before I suppose since the AAAA RR was already | present, although not as glue. ==> This is indeed a very interesting question. We have been gatehring statistics for DNS queries sent to ns3.nic.fr via IPv6 transport for about two years. There have been about 70 queries per minute on average during the last year. It's hard to tell now the difference because AAAA glue has just been published (for instance, we cannot see a big difference between the 20th and the 21st of July). . We will keep watching DNS traffic via IPv6 transport and give you more accurate figures if you want later. Regards, Mohsen. From kurtis at kurtis.pp.se Thu Jul 22 12:01:14 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 22 Jul 2004 12:01:14 +0200 Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040722092012.GR76622@kerkenna.nic.fr> References: <20040721073711.01711E7EBA@mx1.nominet.org.uk> <20040722092012.GR76622@kerkenna.nic.fr> Message-ID: <1162741B-DBC6-11D8-B026-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-07-22, at 11.20, Mohsen Souissi wrote: > The second choice took us less than 12 hours (including > a.root-servers.net reload delay). Why would you have to wait for a.root-servers.net to reload? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQP+QbqarNKXTPFCVEQL3MQCg/vvoA0zJJsus3NFXtbCPoz6FYvwAn2OK dhcFHDUtXkMRmXb0bnt6R3VL =HJk1 -----END PGP SIGNATURE----- From brad.knowles at skynet.be Thu Jul 22 12:00:15 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Thu, 22 Jul 2004 12:00:15 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: References: <830.1090401067@gromit.rfc1035.com> Message-ID: At 11:46 AM +0200 2004-07-22, Joao Damas wrote: >>> Well, what other choice is there? :-) And anyway, since the overwhelming >>> bulk of the world's name servers are IPv4-only, resolution over IPv6 >>> doesn't seem to be a particularly productive exercise. >> >> True enough. > > True enough for what subset of users? For that subset of users which are not using IPv6-only systems. > If the a user is interested in only a few and those provide the service > that user needs and uses, what does he/she care about a million servers > out there? IMO, the real problem is knowing, a priori, precisely which set of servers you'd need to talk to via IPv6-only methods. If you knew that, you wouldn't have to worry about whether or not there is any glue at the root. Of course, we might be able to try to answer these sorts of questions for small-scale testing environments, but in the general case it is impossible to know this. Therefore, we have to try to build the systems such that we do provide the necessary links from the root. The real question is what to do in the transition period, and how do you decide where you are in the transition period? -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From Joao_Damas at isc.org Thu Jul 22 12:09:10 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 22 Jul 2004 12:09:10 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: References: <830.1090401067@gromit.rfc1035.com> Message-ID: <2CBEB80F-DBC7-11D8-BC9E-000A959B2120@isc.org> On 22 Jul, 2004, at 12:00, Brad Knowles wrote: > Therefore, we have to try to build the systems such that we do > provide the necessary links from the root. > Precisely Joao From jim at rfc1035.com Thu Jul 22 12:12:54 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 22 Jul 2004 11:12:54 +0100 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: Message from Joao Damas of "Thu, 22 Jul 2004 11:46:16 +0200." Message-ID: <2606.1090491174@gromit.rfc1035.com> >>>>> "Joao" == Joao Damas writes: BN: cc list has been trimmed as everyone there is already on dns-wg at ripe.net >>> Well, what other choice is there? :-) And anyway, since the >>> overwhelming bulk of the world's name servers are IPv4-only, >>> resolution over IPv6 doesn't seem to be a particularly >>> productive exercise. >> True enough. Joao> True enough for what subset of users? If the a user is Joao> interested in only a few and those provide the service that Joao> user needs and uses, what does he/she care about a million Joao> servers out there? It's not that simple Joao. If only it could be that simple... Have you forgotten the IPv6 migration issues that Johan Ihren and others have mentioned at previous WG meetings? Some IPv6 users will drop DNS over IPv4 as soon as they see AAAAs for TLD name servers. Or, worse, for the root servers. They may not realise or understand that this will cut them off from most of the internet. Which you seem to be saying is fine. If all they're interested in is the IPv6 internet, let them just get access to that. I'd agree with that sentiment if we knew for sure we were talking about informed, knowledgeable users. But I'm not convinced that's the case. Even so this approach brings more problems. Firstly, it highlights the lack of a migration strategy for introducing DNS over IPv6. We still don't know what's going to break, how those failures will manifest themselves and what the consequences of that will be. Both for applications/resolvers and for name servers. For instance, what will my IPv6 web browser do when lookups over IPv6 for www.google.com return only A records? Or SERVFAIL? Second of all, a piecemeal introduction of AAAA glue could be destablising for the DNS and the internet. We just don't know either way, so we should proceed carefully with a good understanding of the consequences of these changes. Thirdly, this could also put pressure on other TLDs to add AAAA glue -- "because others are doing this" -- before they're ready to do so. Finally, by encouraging the IPv6-only people to go off into their own little world, we fragment the internet and its name space. At the very least, it will mean some IPv6-ers are likely to develop a mindset that DNS migration to IPv6 is done and there's nothing more for them to do as far as IPv6 and the DNS is concerned. From jeroen at unfix.org Thu Jul 22 12:48:24 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 22 Jul 2004 12:48:24 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <2606.1090491174@gromit.rfc1035.com> References: <2606.1090491174@gromit.rfc1035.com> Message-ID: <1090493304.16467.489.camel@segesta.zurich.ibm.com> On Thu, 2004-07-22 at 11:36, Joao Damas wrote: > On 21 Jul, 2004, at 18:03, Jeroen Massar wrote: > >> We are trying hard to make F available from our anycast nodes on its > >> IPv6 address. Finding exchange points which (a) will give you v6 > >> addresses and (b) have peers which will peer with you over IPv6 is not > >> trivial, however. > > > > Then I should advise you to come to the AMS-IX, there is no F there and > > it should not be hard to get IPv6 from the IX nor transit nor peers. > > Just give them a shout and I am sure people are willing to help out. > > F has v6 enabled for peerings at several exchanges, for instance at the > SFINX in Paris, the GigaPIX in Lisbon and the Namex in Rome. We will > turn it on in any other anycast location where the exchange supports > IPv6 traffic directly and there are peers to peer with. As can be seen under f.root-servers.net at the following url (use "IPv6 well known destinations"): http://www.sixxs.net/misc/latency/latency/ F is at about 100ms in IPv6 for most destinations, ~3ms from ptlis01 though. Then again if I look at f.root-servers.net over IPv4 in that same graph the average is ~150ms... hmmm IPv6 is better as IPv4? :) On Thu, 2004-07-22 at 12:12, Jim Reid wrote: > Have you forgotten the IPv6 migration issues that Johan Ihren and > others have mentioned at previous WG meetings? Some IPv6 users will > drop DNS over IPv4 as soon as they see AAAAs for TLD name servers. Then those users doing that are basically stupid. You can't do anything about that and they simply hurt themselves. IPv4 will exist for at least the coming 50 years in one form or another and it will not evaporate. People thinking that they can live without some kind of IPv4 access, well let them live in their small world. > I'd agree with that sentiment if we knew > for sure we were talking about informed, knowledgeable users. But I'm > not convinced that's the case. Do 'normal' users know what IPv6 is, or even IPv4 or even IP? They want to type names and generally don't configure their nameservers, DHCP does that. And the few that will break it will hurt themselves and get laughed at. Non issue ;) > Even so this approach brings more problems. Firstly, it highlights the > lack of a migration strategy for introducing DNS over IPv6. DNS over IPv6 gives an extra transport possibility, we cannot currently do without IPv4. If you want a IPv6 only DNS system make sure that you at least have a caching IPv4/IPv6 capable box in front of it. The same goes for proxies, shutdown your IPv4, just keep your proxybox doing both IPv4 and IPv6 and you will be fine. > We still don't know what's going to break, how those failures will manifest > themselves and what the consequences of that will be. Both for > applications/resolvers and for name servers. For instance, what will > my IPv6 web browser do when lookups over IPv6 for www.google.com > return only A records? Or SERVFAIL? The transport (IPv4 or IPv6) doesn't matter, what matter is the answer which you get and the speed of it. DNS fortunatly falls back to another transport or nameserver to retrieve the answer from another when SERVFAIL comes back. When you have an IPv6 only webclient then of course you can't use A records and you will fail there, solution: Transition Mechanism's. eg try: http://www.google.com.sixxs.org Or any other proxy as I described above. > Second of all, a piecemeal > introduction of AAAA glue could be destablising for the DNS and the > internet. We just don't know either way, so we should proceed > carefully with a good understanding of the consequences of these > changes. How can it destabilize 'the internet'? The only problem that could occur is when there is too many glue in so that you require EDNS0, in that case you need to update your machine anyway as you are a hot target for virii, DNS is then the least of your concerns ;) (Oh and yes I like legacy machines, don't worry) > Thirdly, this could also put pressure on other TLDs to add > AAAA glue -- "because others are doing this" -- before they're ready > to do so. If they are not ready now then they are simply late. That is the same with deploying your IPv6 network now or in 10 years when there is customer demand. Either you do it now and slowly and with a possible small customer base who don't mind that you are breaking it or you do it rapidly in a couple of years and break a lot of things. > Finally, by encouraging the IPv6-only people to go off into > their own little world, we fragment the internet and its name > space. At the very least, it will mean some IPv6-ers are likely to > develop a mindset that DNS migration to IPv6 is done and there's > nothing more for them to do as far as IPv6 and the DNS is concerned. People using IPv6 (next to IPv4) can already reach a number of sites and especially content which the IPv4 people can't. Probably the best example since long: www.kame.net When using IPv4 you can't see the Dancing Kame(tm). Too bad for them.... computers is progress, if you don't progress then stay behind. The 'normal public' you are talking about will follow, it will take some time but it will happen, not now, not tomorrow, not directly, not with a flag day, but very slowly and gradually. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From Joao_Damas at isc.org Thu Jul 22 12:51:39 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 22 Jul 2004 12:51:39 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <2606.1090491174@gromit.rfc1035.com> References: <2606.1090491174@gromit.rfc1035.com> Message-ID: <1BE6EEC4-DBCD-11D8-BC9E-000A959B2120@isc.org> On 22 Jul, 2004, at 12:12, Jim Reid wrote: >>>>>> "Joao" == Joao Damas writes: > > BN: cc list has been trimmed as everyone there is already on > dns-wg at ripe.net > >>>> Well, what other choice is there? :-) And anyway, since the >>>> overwhelming bulk of the world's name servers are IPv4-only, >>>> resolution over IPv6 doesn't seem to be a particularly >>>> productive exercise. >>> True enough. > > Joao> True enough for what subset of users? If the a user is > Joao> interested in only a few and those provide the service that > Joao> user needs and uses, what does he/she care about a million > Joao> servers out there? > > It's not that simple Joao. If only it could be that simple... > > Have you forgotten the IPv6 migration issues that Johan Ihren and > others have mentioned at previous WG meetings? No, I have discussed them with Johan on occasion. Does that mean we are to seat down and do nothing? The problems are known and there are proposed solutions. At the same time the RSSAC was working on producing the recommendation for the IANA to accept AAAA in the root zone, it also discussed how to start this transition for the root-servers.net zone and the respective glue. > Some IPv6 users will > drop DNS over IPv4 as soon as they see AAAAs for TLD name servers. Or, > worse, for the root servers. They may not realise or understand that > this will cut them off from most of the internet. Which you seem to be > saying is fine. If all they're interested in is the IPv6 internet, let > them just get access to that. I'd agree with that sentiment if we knew > for sure we were talking about informed, knowledgeable users. But I'm > not convinced that's the case. Did not know about your baby-sitting activities. You can't protect users from every possible mistake. You should analyse problems and recommend sensible defaults, while avoiding troublesome choices but this should not prevent progress. You can;t just sit around saying "oh, but there are all these unknowns and a choice is so hard..." > > Even so this approach brings more problems. Firstly, it highlights the > lack of a migration strategy for introducing DNS over IPv6. We still > don't know what's going to break, how those failures will manifest > themselves and what the consequences of that will be. Both for > applications/resolvers and for name servers. A lot of this has been done or is being done. > For instance, what will > my IPv6 web browser do when lookups over IPv6 for www.google.com > return only A records? What do you mean "your IPv6 web browser"? > Or SERVFAIL? Second of all, a piecemeal > introduction of AAAA glue could be destablising for the DNS and the > internet. We just don't know either way, so we should proceed > carefully with a good understanding of the consequences of these > changes. Thirdly, this could also put pressure on other TLDs to add > AAAA glue -- "because others are doing this" -- before they're ready > to do so. Some people put non-conformant javascript and HTML in their web pages, they count on error handling, or lack thereof, of particular web browsers to put out web pages that can only be seen by those web browsers... Of course changes need to be done in a responsible way and I am taking personal offence if you would suggest that I would not follow that path. > Finally, by encouraging the IPv6-only people to go off into > their own little world, we fragment the internet and its name > space. No, you just are not getting it. I am talking about enabling, you are talking about limiting. > At the very least, it will mean some IPv6-ers are likely to > develop a mindset that DNS migration to IPv6 is done and there's > nothing more for them to do as far as IPv6 and the DNS is concerned. Since when has that been possible for any protocol that is used on the Internet? DNS, the protocol, keeps changing and adding new possibilities, just like most other Internet protocols. The bottom line: it is time to get going. Joao From jeroen at unfix.org Thu Jul 22 12:57:48 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 22 Jul 2004 12:57:48 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <8EC47BF0-DBC2-11D8-BC9E-000A959B2120@isc.org> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> <20040721074747.GA30273@nic.fr> <8C91DDFD-DB15-11D8-9800-000A95E7E6B4@isc.org> <1090425790.16467.297.camel@segesta.zurich.ibm.com> <8EC47BF0-DBC2-11D8-BC9E-000A959B2120@isc.org> Message-ID: <1090493868.16467.508.camel@segesta.zurich.ibm.com> On Thu, 2004-07-22 at 11:36, Joao Damas wrote: > On 21 Jul, 2004, at 18:03, Jeroen Massar wrote: > >> We are trying hard to make F available from our anycast nodes on its > >> IPv6 address. Finding exchange points which (a) will give you v6 > >> addresses and (b) have peers which will peer with you over IPv6 is not > >> trivial, however. > > > > Then I should advise you to come to the AMS-IX, there is no F there and > > it should not be hard to get IPv6 from the IX nor transit nor peers. > > Just give them a shout and I am sure people are willing to help out. > > F has v6 enabled for peerings at several exchanges, for instance at the > SFINX in Paris, the GigaPIX in Lisbon and the Namex in Rome. We will > turn it on in any other anycast location where the exchange supports > IPv6 traffic directly and there are peers to peer with. As can be seen under f.root-servers.net at the following url (use "IPv6 well known destinations"): http://www.sixxs.net/misc/latency/latency/ F is at about 100ms in IPv6 for most destinations, ~3ms from ptlis01 though. Then again if I look at f.root-servers.net over IPv4 in that same graph the average is ~150ms... hmmm IPv6 is better as IPv4? :) > We would love to be at the AMSIX but would need some sort of local > sponsor for that, perhaps the AMSIX itself. I shall ask them. See the off-list message for an offer from someone. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From geoff at nominet.org.uk Thu Jul 22 13:39:00 2004 From: geoff at nominet.org.uk (Geoffrey Sisson) Date: Thu, 22 Jul 2004 12:39:00 +0100 (BST) Subject: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <20040722092012.GR76622@kerkenna.nic.fr> Message-ID: <20040722113900.436E8E7EAA@mx1.nominet.org.uk> Mohsen Souissi writes: > On 21 Jul, Geoffrey Sisson wrote: > | Stephane Bortzmeyer writes: > | > | > Do note that the IPv6 server of ".fr", requested in February 2003, is > | > still not announced. > | > | Maybe only coincidence: > | > | JPNIC = ccNSO member > | KRNIC = ccNSO member > | AFNIC = ccNSO non-member > > ==> There's definitely no connection. Agreed; events have demonstrated no connection. Regards Geoff From Joao_Damas at isc.org Thu Jul 22 11:36:07 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 22 Jul 2004 11:36:07 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <1090425790.16467.297.camel@segesta.zurich.ibm.com> References: <200407210707.i6L77KO12981@grimsvotn.TechFak.Uni-Bielefeld.DE> <20040721071646.GA28704@nic.fr> <1090394980.4858.101.camel@segesta.zurich.ibm.com> <20040721074747.GA30273@nic.fr> <8C91DDFD-DB15-11D8-9800-000A95E7E6B4@isc.org> <1090425790.16467.297.camel@segesta.zurich.ibm.com> Message-ID: <8EC47BF0-DBC2-11D8-BC9E-000A959B2120@isc.org> On 21 Jul, 2004, at 18:03, Jeroen Massar wrote: >> We are trying hard to make F available from our anycast nodes on its >> IPv6 address. Finding exchange points which (a) will give you v6 >> addresses and (b) have peers which will peer with you over IPv6 is not >> trivial, however. > > Then I should advise you to come to the AMS-IX, there is no F there and > it should not be hard to get IPv6 from the IX nor transit nor peers. > Just give them a shout and I am sure people are willing to help out. F has v6 enabled for peerings at several exchanges, for instance at the SFINX in Paris, the GigaPIX in Lisbon and the Namex in Rome. We will turn it on in any other anycast location where the exchange supports IPv6 traffic directly and there are peers to peer with. We would love to be at the AMSIX but would need some sort of local sponsor for that, perhaps the AMSIX itself. I shall ask them. Of course, F's global nodes also announce the IPv6 prefix to their IPv6 peers. Joao From Joao_Damas at isc.org Thu Jul 22 11:46:16 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 22 Jul 2004 11:46:16 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: References: <830.1090401067@gromit.rfc1035.com> Message-ID: On 21 Jul, 2004, at 11:50, Brad Knowles wrote: > At 10:11 AM +0100 2004-07-21, Jim Reid wrote: > >> Personally, I don't see why you care about the RTT to a root server. >> A >> well-behaved name server will make 4-5 queries to a root server once >> a >> week or so. Why optimise that? Please note I'm not suggesting that >> it's OK for root servers to have lousy RTTs. My name server is in >> regular, frequent contact with other name servers that have RTTs >> longer than 200ms. > > Well, I'm not an IPv6 expert by any stretch of the imagination, but > the impression I got was that if you were IPv6-only, and all the root > nameservers you can reach via IPv6 are routed via highly undesirable > paths, then you would be in a pretty bad situation. It's fine for > some of those IPv6 addresses to be non-production or very > sub-optimally routed, but I think the problem comes from when that > happens to all of them. > > At least, that was my take. > >> Well, what other choice is there? :-) And anyway, since the >> overwhelming >> bulk of the world's name servers are IPv4-only, resolution over IPv6 >> doesn't seem to be a particularly productive exercise. > > True enough. True enough for what subset of users? If the a user is interested in only a few and those provide the service that user needs and uses, what does he/she care about a million servers out there? The problem here is that this initial missing link does not enable a user that could be IPv6 only and live without a NAT, to do so. It is this lack of enabling that is the problem from my point of view. Joao From daniel.karrenberg at ripe.net Thu Jul 22 13:48:28 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 22 Jul 2004 13:48:28 +0200 Subject: [dns-wg] FYI: IANA delegation procedure for the root zone and ipv6 glue In-Reply-To: <200407220952.i6M9qSd19664@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <20040721211036.GA5422@reifa.local> <200407220952.i6M9qSd19664@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040722114828.GA10511@reifa-wave.karrenberg.net> On 22.07 11:52, Peter Koch wrote: > ... > But we're talking about a policy document > here - why does that use/have to use such fuzzy wording? Because non-fuzzy wording that serves the purpose does not exist. The IANA has to make a judgement call here and it is better to make that explicit in the policy than to keep it obscure. People should take notice and indeed you and others have noticed it correctly. If necessary the IANA may indeed use real life queries at the time to make that call. I doubt whether it will ever be necesaary in practise but it might be. Daniel PS: If your question is whether we trust the IANA with this judgement call, that is something different. I am afraid that we do not have much choice in this particular matter. Someone has to make that call. I hope that IANA will make the right calls and (re-)gain our confidence. From jim at rfc1035.com Thu Jul 22 14:41:34 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 22 Jul 2004 13:41:34 +0100 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: Message from Joao Damas of "Thu, 22 Jul 2004 12:51:39 +0200." <1BE6EEC4-DBCD-11D8-BC9E-000A959B2120@isc.org> Message-ID: <2872.1090500094@gromit.rfc1035.com> >>>>> "Joao" == Joao Damas writes: >> Have you forgotten the IPv6 migration issues that Johan Ihren >> and others have mentioned at previous WG meetings? Joao> No, I have discussed them with Johan on occasion. Does that Joao> mean we are to seat down and do nothing? No, of course not. Doing nothing is not an option. >> For instance, what will my IPv6 web browser do when lookups >> over IPv6 for www.google.com return only A records? Joao> What do you mean "your IPv6 web browser"? I would have thought this was obvious from the context: a browser running on some IPv6-only device or only had DNS transport over IPv6. Joao> Of course changes need to be done in a responsible way and I Joao> am taking personal offence if you would suggest that I would Joao> not follow that path. I made no such suggestion. [I said some TLDs might be pressured into doing IPv6 things before they were ready to do that. They may well be acting responsibly based on the limited resources and info they have available to them.] And anyway, how can you take personal offence? AFAIK, you're not personally responsible for any TLD AAAA glue or the contents of the root zone. Please note too that I'm not impugning those who do have that responsibility either. What I am saying is that making well-intentioned changes to critical DNS infrastructure may have unexpected consequences if the impact of those changes isn't fully understood. This applies to other horrors like DNSSEC deployment, not just these IPv6 issues. BTW, the IANA document which sparked this discussion talks about changing TLD delegations when there are "serious operational problems". Presumably these arise after the TLD and IANA have acted responsibly by applying some carefully considered (but not fully thought out?) change to the delegation. >> Finally, by encouraging the IPv6-only people to go off into >> their own little world, we fragment the internet and its name >> space. Joao> No, you just are not getting it. I am talking about Joao> enabling, you are talking about limiting. I'm doing no such thing. Though I may well not be "getting it". What we seem to be disagreeing about is tactics and strategy, not policy. ie We agree IPv6 has to be deployed in the DNS. Where we differ is in how to achieve that. You seem to be saying "just do it". I'm saying "let's first try to understand what we're getting ourselves into". IMO the internet today is too big and too important for the "just do it" approach that was possible 10 or more years ago. >> At the very least, it will mean some IPv6-ers are likely to >> develop a mindset that DNS migration to IPv6 is done and >> there's nothing more for them to do as far as IPv6 and the DNS >> is concerned. Joao> Since when has that been possible for any protocol that is Joao> used on the Internet? DNS, the protocol, keeps changing and Joao> adding new possibilities, just like most other Internet Joao> protocols. DNS protocol development has been stalled for years. But that's beside the point. Whenever something new comes along, care needs to be taken that it doesn't introduce interoperability problems or operational issues. [eg Sending resolvers into an infinite tight loop beating up root or TLD servers for the same non-existent names.] I'm sure we agree on this. What we're disagreeing about appears to be the extent that these potential problems have been analysed and documented. Perhaps an IPv6-only island on the internet would bring DNS problems for the rest of the net that the people in this island never see? Or care to fix? In a sense, this can be compared to the DSL users who have Windows boxes that get hijacked by spammers. The end user might not be aware of that, so can't/won't plug the holes that give rise to the operational problems. It's a bad analogy because someone will eventually blackhole the spammer and give an incentive for the end user to fix the problem. That sort of corrective mechanism might not be possible in an IPv6 only island that's pounding the life out of the world's name servers. From Joao_Damas at isc.org Thu Jul 22 15:39:56 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 22 Jul 2004 15:39:56 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <2872.1090500094@gromit.rfc1035.com> References: <2872.1090500094@gromit.rfc1035.com> Message-ID: <9E53718E-DBE4-11D8-BC9E-000A959B2120@isc.org> On 22 Jul, 2004, at 14:41, Jim Reid wrote: > > BTW, the IANA document which sparked this discussion talks about > changing TLD delegations when there are "serious operational > problems". Presumably these arise after the TLD and IANA have acted > responsibly by applying some carefully considered (but not fully > thought out?) change to the delegation. It is extremely difficult to prove you have addressed all possible situations when dealing with a system such as the Internet. That is why there is the hook there enabling the IANA to take action if there are operational problems. No one anticipates operational problems arising from this change if the proper checks outlined in the document are done, but it is nice to have a safety mechanism. Imagine there was indeed an operational problem and that the IANA had to initiate a formal discussion, that had to come to a consensus, on what to do about it. A bloody nightmare if you ask me. So I think the document and procedure has been as thought out as it could have been and as dfk says, it then becomes a matter of confidence on the organisation currently tasked with providing the service. > >>> Finally, by encouraging the IPv6-only people to go off into >>> their own little world, we fragment the internet and its name >>> space. > > Joao> No, you just are not getting it. I am talking about > Joao> enabling, you are talking about limiting. > > I'm doing no such thing. Though I may well not be "getting it". What > we seem to be disagreeing about is tactics and strategy, not policy. > ie We agree IPv6 has to be deployed in the DNS. Where we differ is in > how to achieve that. You seem to be saying "just do it". No just do it, just get on with doing it. > I'm saying > "let's first try to understand what we're getting ourselves into". > IMO the internet today is too big and too important for the "just do > it" approach that was possible 10 or more years ago. > 10 years ago people also acted mostly in a responsible way. When you contemplate all cases, there will be some under which some people will be able to cut themselves off the Internet, intentionally or not (remember the MS name server debacle a couple of years ago?) That sort of situation can't stop progress. Joao From pk at TechFak.Uni-Bielefeld.DE Thu Jul 22 15:58:27 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Thu, 22 Jul 2004 15:58:27 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: Your message of "Thu, 22 Jul 2004 15:39:56 +0200." <9E53718E-DBE4-11D8-BC9E-000A959B2120@isc.org> Message-ID: <200407221358.i6MDwRS20762@grimsvotn.TechFak.Uni-Bielefeld.DE> Joao Damas wrote: > operational problems. No one anticipates operational problems arising > from this change if the proper checks outlined in the document are > done, but it is nice to have a safety mechanism. Agreed, fully. > Imagine there was indeed an operational problem and that the IANA had > to initiate a formal discussion, that had to come to a consensus, on > what to do about it. A bloody nightmare if you ask me. Sure, but the 'safety belt' in the policy document is stated much broader than necessary for the risk posed by AAAA glue RRs. It can be applied to problems totally unrelated to IPv6. While that may even be technically useful certain certain circumstances, this en passant introduction would not have been necessary. -Peter From daniel.karrenberg at ripe.net Thu Jul 22 17:30:53 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 22 Jul 2004 17:30:53 +0200 Subject: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone In-Reply-To: <200407221358.i6MDwRS20762@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <9E53718E-DBE4-11D8-BC9E-000A959B2120@isc.org> <200407221358.i6MDwRS20762@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <20040722153052.GA12816@reifa-wave.karrenberg.net> Gents, it boils down to the question whether we trust IANA or not. In the not-too-recent past this was no question at all. I hope that in the not-too-distant future it will again be no question. Daniel