July 2004 - dns-wg - mailman.ripe.net

Re: [dns-wg] AAAA lookup misbehaviour
by David Malone 08 Sep '04

08 Sep '04

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!

6 8

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 22 Jul '04

22 Jul '04

>>>>> "Joao" == Joao Damas <Joao_Damas(a)isc.org> 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.

4 3

FYI: IANA delegation procedure for the root zone and ipv6 glue
by Andrei Robachevsky 22 Jul '04

22 Jul '04

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

7 12

Re: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone
by geoff＠nominet.org.uk 22 Jul '04

22 Jul '04

Stephane Bortzmeyer <bortzmeyer(a)nic.fr> 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

4 5

IPv6 glue AAAA RRs in the root zone
by Peter Koch 22 Jul '04

22 Jul '04

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

8 21

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 22 Jul '04

22 Jul '04

>>>>> "Joao" == Joao Damas <Joao_Damas(a)isc.org> writes: BN: cc list has been trimmed as everyone there is already on dns-wg(a)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.

3 2

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 22 Jul '04

22 Jul '04

>>>>> "Jeroen" == Jeroen Massar <jeroen(a)unfix.org> 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.

6 7

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 21 Jul '04

21 Jul '04

>>>>> "Stephane" == Stephane Bortzmeyer <bortzmeyer(a)nic.fr> 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?

1 0

Reverse checker out-of-sync with RIPE-203
by Andre Oppermann 19 Jul '04

19 Jul '04

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

2 1

Stale restricted IPv6 information at Verisign/IANA
by Bernhard Schmidt 16 Jul '04

16 Jul '04

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

1 0