I've dusted off the Misbehavior of DNS document, cleaned it up a bit, added comments based on what was said on the mailing list when I last posted it (including some of the related issues mentioned). Do people think this is worth perusing as a RIPE document? Is the related issues section useful? Are the comments on testing useful? David. Misbehavior of DNS when faced with IPv6 or other New Query Types David Malone February 2005 Abstract This document is a short description of problems with certain DNS systems that have come to light with the deployment of IPv6 enabled software. 1. Introduction 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 with only new types, such as AAAA, and others have problems with any query not of type A. The end result of these issues is that connecting to a site using a problematic name server may be impossible, intermittent or significantly delayed. The technical details of these problems are explained in [RFC4074]. 2. Problem Extent 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. This corresponds to about 1.8% or URLS that are impacted by the problem. For more details of this survey see [IPJMISBEHAVE]. In terms of DNS server software, DNS load balancers seem to be commonly affected. This means that high-volume sites, such as ad servers, are often victims of this problem. Due to the embedding of ad-server images in web pages, the extent of the problem may be experienced by users of other web sites displaying these ads. 3. Testing New DNS Systems 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 [RFC1035], [RFC3597] and [RFC4074] 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. Simple testing can be conducted by making a query for a AAAA record using a tool such as dig. Supposing that the server has IP 192.0.2.1 and is to serve the domain example.com, queries such as the following should be made: dig AAAA exists.example.com @192.0.2.1 dig AAAA does-not-exist.example.com @192.0.2.1 dig AAAA www.subdomain.example.com @192.0.2.1 In each case the server should return the correct number of AAAA records (0 if there are none) and a status of NOERROR. Even if the server is only responsible for reverse zones, where queries for AAAA records are uncommon, such tests are still useful as reverse zones may still receive queries for other new record types. A simple web-based tool for testing is available at http://www.cnri.dit.ie/cgi-bin/check_aaaa.pl This tool can detect some of the most common problems given a domain name. 4. Addressing the Existing Problem 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! The action required to restore normal service may just require a simple software upgrade if the DNS Server vendor has already addressed these issues. A DNS server vendor should be able to address the issues using the RFCs referenced in this document. 5. Related Issues There are a number of other IPv6 related DNS issues that warrant mention. 5.1 A6 Records Initially, IPv6 addresses were to be determined in the DNS using A6 records, rather than AAAA records. Name servers that respond incorrectly to AAAA requests are also likely to respond incorrectly to A6 records. A6 queires are now considered experimental. 5.2 ip6.int vs. ip6.arpa Originally, two schemes were proposed for IPv6 reverse lookups. One used the ip6.int domain and the "nibble" format. The other used the ip6.arpa domain and the "bitstring" format. The system that has now been settled on uses the ip6.arpa domain and the nibble format. While some use of the ip6.int domain continues, it has been deprecated by [RFC4159]. 5.3 Resolver Issues There can also be issues with DNS resolvers. Some resolvers may not react as expected when asked to act on unusual addresses (such as IPv6 mapped addresses). Other resolvers have had problems if a host both IPv4 and IPv6 addresses. Still others have had problems if hosts have only IPv6 addresses. Some of these issues can be worked around by the application developer, however many vendors now have software updates to address these issues. 6. Acknowledgments This work is a product of the RIPE DNS Working Group. 7. References [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 [RCF3597] A. Gustafsson, "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC4074] Y. Morishita and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005. [RFC4159] G. Huston, "Deprecation of "ip6.int"", RFC 4159, August 2005. [IPJMISBEHAVE] D. Malone, 'Misbehaving Name Servers and What They're Missing', The Internet Protocol Journal - Volume 8, Number 1, March 2005.
On Feb 6, 2006, at 10:14 PM, David Malone wrote:
o 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 [RFC1035], [RFC3597] and [RFC4074] mentioned above).
Hmmm... I'd say this recommendation is a little to "narrow". For IPv6 misbehavior these 3 RFCs are probably sufficient but there are also other DNS extensions that new implementations should be able to deal with. Most particular the middleboxes like load balancers should know about protocol extensions such as EDNS0 and DNSSEC. I understand that this document is IPv6 specific but maybe being a little more generic here might help implementors to realize they have to do more. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/
For IPv6 misbehavior these 3 RFCs are probably sufficient but there are also other DNS extensions that new implementations should be able to deal with. Most particular the middleboxes like load balancers should know about protocol extensions such as EDNS0 and DNSSEC.
Sure - do you know of any writeup of EDNS0 experience? I guess experience of DNSSEC niggles is just comming on line now, so it isn't written up yet. David.
On Feb 21, 2006, at 13:32, David Malone wrote:
Sure - do you know of any writeup of EDNS0 experience? I guess experience of DNSSEC niggles is just comming on line now, so it isn't written up yet.
There's a little info on NIC-SE's web site. Though the last time I looked this was largely a list of broken firewalls that barf on EDNS0 packets. draft-ietf-enum-experiences-03.txt is also working its way through the IETF. This has a few passing references to problems when EDNS0 is not supported.
On Tue, Feb 21, 2006 at 01:18:50PM +0100, Olaf M. Kolkman wrote:
to deal with. Most particular the middleboxes like load balancers should know about protocol extensions such as EDNS0 and DNSSEC.
I understand that this document is IPv6 specific but maybe being a little more generic here might help implementors to realize they have to do more.
I'm a bit afraid of losing focus here. This started as a survey of systems not properly serving AAAA RRs, then additional v6 considerations were added and now EDNS0 is on the table. While all these are serious operational issues, we might want to address them separately or point to and combine efforts which already deal with them. For example, there's work underway dealing with EDNS0 in the IETF and everyone here will be invited to contribute. For David's work there's the IPJ article including the reference to RFC 4074. What else is needed? It might help to continue these surveys, but we'd need to see what we're going to measure. o There are some old or problematic implementations out there and it might be the vendors (for fixes) or the operators (for upgrades) or both that need to become aware. Do we want to identify these implementations (-> fingerprinting) or their distribution? Who's going to do that? o Who's our target? End users/site administrators running name servers? ISPs? Registrars? Registries? {a possible recommendation _could_ be to include in DNS checks the correct server behaviour against AAAA queries} o There's also the middlebox issue (both vendors and operators), which already bites us with EDNS0. Again, who is the target? -Peter
On Mon, Feb 06, 2006 at 09:14:46PM +0000, David Malone wrote:
Do people think this is worth perusing as a RIPE document? Is the related issues section useful? Are the comments on testing useful?
Thanks, David, for posting this summary. Together with the IPJ article this gives a good overview of the problem and its development over time.
Simple testing can be conducted by making a query for a AAAA record using a tool such as dig. Supposing that the server has IP 192.0.2.1 and is to serve the domain example.com, queries such as the following should be made:
dig AAAA exists.example.com @192.0.2.1 dig AAAA does-not-exist.example.com @192.0.2.1 dig AAAA www.subdomain.example.com @192.0.2.1
Might want to add "+norec" to the options list.
In each case the server should return the correct number of AAAA records (0 if there are none) and a status of NOERROR. Even if the
Would the "speaking names" above indicate that just the AAAA does not exist, but the name does?
This tool can detect some of the most common problems given a domain name.
You might want to inspect the additional section. There's one implementation that puts an A RR into the additional section whenever you ask for AAAA or A6, another one rewrites A6 queries to ANY queries. Would it be possible to publish the script?
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!
Agreed, we might want to drop this option.
5. Related Issues
5.1 A6 Records 5.2 ip6.int vs. ip6.arpa 5.3 Resolver Issues
Personally I'd not touch these here or at most by reference. The ip6.int vs. ip6.arpa will appear on our agenda in the near future anyway. -Peter
participants (4)
-
David Malone -
Jim Reid -
Olaf M. Kolkman -
Peter Koch