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!
"David" == David Malone <dwmalone@maths.tcd.ie> 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.
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
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.
As the next RIPE meeting is rolling up, I just thought I'd raise the AAAA lookup misbehaviour thread again. To briefly remind you of where we'd got to: 1) I'd written up a short describing the problem with authoritative servers and recommending that new name servers should be tested before deployment. 2) Alvaro and Colm had highlighted some problems with client resolver libraries, but it wasn't clear if a description of these problems should live in the same document. 3) We were trying to figure out what action could be taken to encourage people to fix existing problem name servers. So, other than the hall of shame, what options do we have to encourage people to fix their software? Working with vendors of DNS solutions is certainly a good idea, and the dns-wg's name could be useful when convincing vendors to take action. Another possibility would be to recommend that when problem DNS servers are found, then they should be considered lame and so dropped from the advertised list of NSs for a zone. Any other ideas? David.
On Wed, 2004-09-08 at 13:05, David Malone wrote:
As the next RIPE meeting is rolling up, I just thought I'd raise the AAAA lookup misbehaviour thread again. To briefly remind you of where we'd got to:
1) I'd written up a short describing the problem with authoritative servers and recommending that new name servers should be tested before deployment. 2) Alvaro and Colm had highlighted some problems with client resolver libraries, but it wasn't clear if a description of these problems should live in the same document. 3) We were trying to figure out what action could be taken to encourage people to fix existing problem name servers.
So, other than the hall of shame, what options do we have to encourage people to fix their software? Working with vendors of DNS solutions is certainly a good idea, and the dns-wg's name could be useful when convincing vendors to take action.
Another possibility would be to recommend that when problem DNS servers are found, then they should be considered lame and so dropped from the advertised list of NSs for a zone.
Any other ideas?
Notez bien that some software is also doing A6 lookups, even bind9 does this upto 9.3.x afaik. Add a small item about ip6.int and ip6.arpa and maybe even discussing (again as the previous time nicely got killed) about the quick removal of ip6.int in total. Greets, Jeroen
On 8 Sep, 2004, at 13:59, Jeroen Massar wrote:
On Wed, 2004-09-08 at 13:05, David Malone wrote:
As the next RIPE meeting is rolling up, I just thought I'd raise the AAAA lookup misbehaviour thread again. To briefly remind you of where we'd got to:
1) I'd written up a short describing the problem with authoritative servers and recommending that new name servers should be tested before deployment. 2) Alvaro and Colm had highlighted some problems with client resolver libraries, but it wasn't clear if a description of these problems should live in the same document. 3) We were trying to figure out what action could be taken to encourage people to fix existing problem name servers.
So, other than the hall of shame, what options do we have to encourage people to fix their software? Working with vendors of DNS solutions is certainly a good idea, and the dns-wg's name could be useful when convincing vendors to take action.
Another possibility would be to recommend that when problem DNS servers are found, then they should be considered lame and so dropped from the advertised list of NSs for a zone.
Any other ideas?
Notez bien that some software is also doing A6 lookups, even bind9 does this upto 9.3.x afaik.
9.3.x has no code left to deal with A6 records. Joao
So, other than the hall of shame, what options do we have to encourage people to fix their software? Call the Internet Police :-). Effectively, there are not a lot of options other than make the problem know, Working with vendors of DNS solutions is certainly a good idea, and the dns-wg's name could be useful when convincing vendors to take action. Publishing a Ripe document identifying the problem and the solutions there to might help to convince the RIPE members to take action; have this in the RIPE course material where appropriate (LIR course ?); bring it under attention of the IPv6 working group and other IPv6 groups. Another possibility would be to recommend that when problem DNS servers are found, then they should be considered lame and so dropped from the advertised list of NSs for a zone. Recommend to who? To the parent is I guess your answer. We are dabbling into policy space here if you don't watch it (expecially when the parent is "." :-). Any other ideas? Call the local papers :-). No, honestly, publisch it. You might ask Ole whether he thinks it is useful for the Protocol Journal. jaap
On 8 Sep, 2004, at 13:05, David Malone wrote:
As the next RIPE meeting is rolling up, I just thought I'd raise the AAAA lookup misbehaviour thread again. To briefly remind you of where we'd got to:
1) I'd written up a short describing the problem with authoritative servers and recommending that new name servers should be tested before deployment. 2) Alvaro and Colm had highlighted some problems with client resolver libraries, but it wasn't clear if a description of these problems should live in the same document. 3) We were trying to figure out what action could be taken to encourage people to fix existing problem name servers.
So, other than the hall of shame, what options do we have to encourage people to fix their software?
Writing a RIPE document. People use them as reference material when they are well written, both within and outside the RIPE region
Working with vendors of DNS solutions is certainly a good idea, and the dns-wg's name could be useful when convincing vendors to take action.
Sure, buy me a beer. I am easy to convince :-) Now seriously, we try to do the right thing, we may have bugs some times. For instance there was some time ago a bug that went like this: 1679. [bug] When there was a single nameserver with multiple addresses for a zone not all addresses were tried. [RT #11706] e.g. If the server had one AAAA and one A, then A would not be tried. They will mark all addresses bad if they get a bad response from one of the addresses (bad response != no response). Although you could argue this goes in your favour as IPv6 promoter.
Another possibility would be to recommend that when problem DNS servers are found, then they should be considered lame and so dropped from the advertised list of NSs for a zone.
Well, that would depend on the nature of the misbehaviour. I am looking forward to your DNS-wg contribution. Joao
participants (6)
-
David Malone -
Jaap Akkerhuis -
Jeroen Massar -
Jim Reid -
Joao Damas -
Peter Koch