August 2006 - dns-wg - mailman.ripe.net

DNS Lameness Checking Proposal
by Brett Carr 22 Sep '06

22 Sep '06

As per the dns-wg Action point 52.3 from RIPE 52 "post questions and proposal to wg mailing list on how to deal with lame delegations when either the NCC is responsible for maintaining the parent or for running a (secondary) server for the child that is or is about to become delegated lame due to an unavailable *xfr source." Please find attached "dnslamecheckAug2006.txt" a proposal on how the RIPE NCC should test for lameness and what the resulting actions could be. Your feedback and discussion on this proposal is welcomed. Brett Carr. -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8

3 4

Announcement DNS for LIRs Training Courses
by RIPE NCC Training Services 29 Aug '06

29 Aug '06

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: Date: Tuesday 5 September 2006 Time: 0900-1700 Location: Reykjavik, Iceland Hosted by: TM-Software http://www.t.is/ And Date: Friday 29 September 2006 Time: 0900-1700 Location: Amsterdam, Netherlands And Date: Friday 27 October 2006 Time: 0900-1700 Location: London, United Kingdom And Date: Tuesday 28 November 2006 Time: 0900-1700 Location: Rome, Italy Hosted by: CASPUR http://www.caspur.it/ Hosted by: NAMEX http://www.namex.it/ And Date: Friday 15 December 2006 Time: 0900-1700 Location: Moscow, Russian Federation The main objective of the DNS for LIRs Training Course is to provide LIRs with information about the different DNS related services the RIPE NCC has available for them. It covers reverse DNS procedures and checks, as well as giving information about DNS Monitoring (DNSMON), K-Root and anycasting. The course also covers DNSSEC and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zones. Please note that the DNS for LIRs course focuses on DNS services and procedures related to being an LIR. The course does: - NOT teach the basics of DNS - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe fully how to operate a Local Internet Registry (LIR) The course is intended for technical staff of LIRs. It is assumed that all attendees are familiar with common DNS terminology and have a practical knowledge of operating DNS servers. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/dns REGISTRATION: ============ To register for this course, please use the LIR Portal or complete the registration via our website on: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

Review of IANA Root Zone Technical Checks
by Brett Carr 21 Aug '06

21 Aug '06

This may be of interest to some of the folks on here. Brett -- Brett Carr RIPE Network Coordination Centre Systems Engineer -- Operations Group Amsterdam, Netherlands GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 > -----Original Message----- > From: owner-dnsop(a)lists.uoregon.edu [mailto:owner- > dnsop(a)lists.uoregon.edu] On Behalf Of Kim Davies > Sent: Saturday, August 19, 2006 6:39 PM > To: dnsop(a)lists.uoregon.edu > Subject: [dnsop] Review of IANA Root Zone Technical Checks > > Dear Colleagues: > > Yesterday we started a review of IANA's procedures relating to > validating NS records and glue supplied by TLD operators for insertion > into the root zone. > > The discussion paper, as well as a public forum for comments, is at: > > http://www.icann.org/announcements/announcement-18aug06.htm > > We'll run this comment period until 30 September, after which we will > use the guidance provided to draft an operational procedure on the > topic. > > Kindest Regards, > > Kim Davies > Internet Assigned Numbers Authority > > > > . > dnsop resources:_____________________________________________________ > web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html > mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

1 0

AAAA problem document
by David Malone 13 Aug '06

13 Aug '06

It seems that the AAAA problem draft is still on the agenda. I've included the current version of the document below, which includes some minor updates, clarifications and edits from the last version. There weren't too many substantial comments last time and the issue isn't changing rapidly. I'd suggest that we either go with something close to this version of the document, or close the item and point at the Internet Protocol Journal article. David. Misbehavior of DNS when faced with IPv6 or other New Query Types David Malone August 2006 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 by 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 ("quad A"), has been introduced. It is becoming increasingly common for software to first issue a request for a record 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 server 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 nameserver may be impossible, intermittent or significantly delayed. The technical details of these problems are explained in [RFC4074]. Note that these problems are not limited to hosts connected to the IPv6 Internet. Any host may look up an IPv6 address even if it does not wish to make an IPv6 connection. This might include hosts processing e-mail headers of a mail that has passed through an IPv6-capable system or a host processing log files from an IPv6-capable system. 2. Problem Extent In Q1 2004, a survey of nameservers for 24000 hostnames mentioned in web proxy logs found about 0.5-1% of nameservers 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 response. In the first case, the correct response is a number of AAAA records (0 if there are none) and a status of NOERROR; in the second case, the returned status should be NXDOMAIN; in the third case the server should return a referral to the servers for the subdomain. 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 to your user-base, the maintainers of the offending 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 is 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 hostmasters or to publish lists based on such data. However, as service maintainers are usually primarily concerned about complaints from paying users, the most effective way to tackle this problem may be for these users to users to notify service maintainers. 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 these issues rapidly 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. Nameservers that respond incorrectly to AAAA requests are also likely to respond incorrectly to A6 records. A6 queries 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. Most use of the ip6.int domain has ceased and it has been deprecated formally [RFC4159]. However, some older IPv6 clients may still issue queries in this domain. 5.3 Resolver Issues There can also be issues with DNS resolver libraries. 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 has both IPv4 and IPv6 addresses. Still others have had problems if hosts have only IPv6 addresses. Problems have also been reported with some caching recursive resolvers included in 'home router' products, which behave incorrectly when dealing AAAA or non-A record queries. Some of these issues can be worked around by 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.

1 0

Agenda Items for RIPE53
by Jim Reid 11 Aug '06

11 Aug '06

Although we're in the middle of the summer holidays, it's time to start planning RIPE53. If you have any suggestions for agenda items for the WG -- presentations, discussion topics, etc -- please let dns- wg-chair(a)ripe.net know. It is easier to allocate slots in the agenda when suggestions are made early, so your co-chairs would appreciate it if your input arrived sooner rather than later. Thanks.

1 0

The RIPE Database and DNS management system has been updated
by Katie Petrusha 08 Aug '06

08 Aug '06

Dear Colleagues, We have updated the RIPE Database and DNS management system to implement several new features. The change in the RIPE Database: - There is a new syntax for the "nserver:" attribute in the DOMAIN object to support IPv4 and IPv6 glue name servers. The changes in the DNS management system: - The management of DNS delegation in the e164.arpa (ENUM) zone has been brought under the same provisioning system as reverse DNS management. - The Delegation Checker has been updated to support glue name servers for IPv4 and IPv6 - The Web Zone Delegation Checker has also been updated You can find more details about the proposal for implementation at: http://www.ripe.net/ripe/maillists/archives/dns-wg/2006/msg00128.html -- Katie Petrusha RIPE NCC

1 0