- dns-wg - mailman.ripe.net

Name servers problems
by Jaap Akkerhuis 28 Feb '06

28 Feb '06

For those not on NANOG, on that list is quite some discussion going on about using (recursive) name servers for amplicication attacks. The discussion starts at http://www.merit.edu/mail.archives/nanog/threads.html#16000.o There is a special mailing list devoted on this problem by the isc: http://lists.oarci.net/mailman/listinfo/dns-operations, and this list is open to anyone. There is an US cert warning about this: http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf. The upshot is: Close your open recursive nameservers. Other info: http://dns.measurement-factory.com/surveys/sum1.html and a plug for a secure template by the cymru guys: http://www.cymru.com/Documents/secure-bind-template.html Maybe all this is worth a slot at the coming dns-wg (or eof) meeting? jaap Acknowledgement: Information compiled from messages from Harvey Allen, Lucy Lynch, Rob Thomas and others.

3 2

DNS Misbehavior Doc
by David Malone 21 Feb '06

21 Feb '06

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.

4 5

RIPE52 agenda item solicitation
by Peter Koch 20 Feb '06

20 Feb '06

Dear DNS WG, at the upcoming RIPE meeting, we will have two slots on Thursday, April 27th (1100-1230 and 1600-1700). There will be the usual administrivia, reports from other groups (IETF, ICANN, ...) and action item reviews. Please send us <dns-wg-chair(a)ripe.net> requests for agenda time including subject, presenter and estimated duration. So, if you have an interesting talk or know of someone else who has or if you have a DNS issue that fits into the wg's charter and that you'd like to discuss, please let us know. For topics of broader interest it's also possible to get a slot in the EOF/Plenary during the week. -Peter

1 0

new DNS Operations mailing list
by brett watson 18 Feb '06

18 Feb '06

(Apologies in advance for cross-postings) We've created a new mailing list (based on a proposal approved by OARC members), that is nanog-like yet professional, and bugtraq-like, to deal specifically with DNS security issues such as: Attacks Security vulnerabilities Secure configuration The list concerns all these from the sense of operational problems rather than system administrators tech support. DNS is arguably as important as routing protocols, and yet we rarely hear details of the attacks going on. The folks dealing with attacks may be network admins, system admins, or security folks; they deal with the problems themselves and move on. Establishing an open yet professional group can be essential to: 1. Form a community of operators. 2. Locate serious people. 3. Find out about problems. 4. Share information. 5. Alert of issues. 6. Move on to more secure environments and meat-space operations. If interested in subscribing to this open list, the links below will get you there. http://lists.oarci.net/mailman/listinfo/ -b

1 0

DNSSEC breaks qmail
by Lutz Donnerhacke 17 Feb '06

17 Feb '06

Qmail can't deliver to DNSSEC protected domains. (Repost from edri.org-ML) Reason: - qmail send an "ANY IN edri.org" query in order to deliver mail. * Due to DNSSEC, there are a some signatures catched by ANY so the response packet size is 605 bytes. - qmail does not support EDNS extensions for larger UDP packets. * The response is truncated to 512 bytes and marked "truncated". - qmail does not support the very old TCP fallback requirement for DNS. - qmail refuses to deliver the mail and logs "CNAME_lookup_failed_temporarily." Overview of packet sizes question | answer size -----------------------|-------------- ANY edri.org | 605 byte MX edri.org | 237 byte A edri.org | 213 byte -----------------------|-------------- ANY edri.org +dnssec | 1331 byte MX edri.org +dnssec | 923 byte A edri.org +dnssec | 731 byte

7 16

Just another lookaside zone
by Lutz Donnerhacke 14 Feb '06

14 Feb '06

-----BEGIN PGP SIGNED MESSAGE----- In order to extend the deployment of security technology, we switch to DNSSEC for us and our customers. Usually the collection of SEP keys on each resolver host is hard to maintain. This is the reason why, we set up an other DLV zone. The zone is automatically rechecked for new keys and subentries on each zone. Please allow AXFR (auth by DNSSEC key) to provide all necessary data. The bind lookaside mechanism is limited to small steps, so a many DLV entries as possible are needed. I copy also the data from dlv.verisignlabs.com, so you may even trust them. ;-) Necessary configuration in /etc/named.conf: options { ...; dnssec-enable yes; dnssec-lookaside "." trust-anchor "dnssec.iks-jena.de"; }; trusted-keys { "iks-jena.de." 257 3 5 "AQPRteOmx973cbeIMigT7nciz3dcbt8ssZPG OK2vtPQlEaZO2fKgnm1Fo6FPWcGqKv6O1Zpj Ew2upKVDnzwMCRHpGe0Qh2TawStviww/jxUt joZom9Hy6uIkTvo7TxqnWg55LoHlcsl1kxsF 1PsM2Z88F1XhXSrUtkiQnViXbfzR0joDE8xG J9zRNuzr9Jik+bcv4S4KFOE/Ocn4F5vF7+eo jz9m3/u0gvQdvgFsb7OHr9cYA5GeG++cJWGG 6xFF+yWEDdWuu2A7IJM3EQFWLr0kGDS6oWo/ 5Bz4PlrURjU5wahM1iwLnbKXhQQempzPYnSE s1CW+KH73WjMa76Dna9B"; }; It's recommended to set up a secondary for "dnssec.iks-jena.de". We send out notifies, too. I did not manage to install a web form right now. If you like to get listed, please send me an email. I'm looking for a *stable* ipv6 and dnssec able secondary server for our zones. If you like to exchange secondary DNS service in different AS, please contact me via OpenPGP mail. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQCiAwUBQ+JD3pFeTizbCJMJAQH3+QRmNxR+RIQYqlrEv2IbFBsAheZINPbSbUnw GkBCUvnTJIHmE9s2em0hxkUR+QQOpaih4szklG2B96aZ04eds5CH9ujovdfTMp0P rb1ri6SIdvHPez50Yp9EbG51Dsdde/8eQgU3P7HHU8ZXUY9x8d0EkMu9fHrsLgkv 66NNL6ezk9S25aoTknE51FlxknX1 =PyvH -----END PGP SIGNATURE-----

3 9

Announcement DNS Training Course
by RIPE NCC Training Services 07 Feb '06

07 Feb '06

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: Date: Monday 10 April 2006 Time: 09:00 17:00 Location: London, United Kingdom And Date: Thursday 11 May 2006 Time: 09:00 17:00 Location: Amsterdam, Netherlands And Date: Tuesday 13 June 2006 Time: 09:00 17:00 Location: Riyadh, Saudi Arabia Hosted by:ZAJIL International Telecommunications Co. W.L.L. And Date: Thursday 22 June 2006 Time: 09:00 17:00 Location: Munich, Germany 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 __________ RIPE NCC Online Learning...at your own pace in your own space https://e-learning.ripe.net

1 0

DNSSEC rollout announcement
by Brett Carr 10 Jan '06

10 Jan '06

[Apologies for duplicates.] Dear Colleague, The RIPE NCC has been moving ahead with the signing of DNSSEC reverse zones. We are pleased to announce that we have reached the stage where all IPv4 reverse zones are signed. You can find details of the zones and relevant public keys at: https://www.ripe.net/projects/disi/keys/ We are now also accepting signed delegations (DS Records) for all IPv4 zones. Details on how to request a secure delegation can be found at: https://www.ripe.net/rs/reverse/dnssec/registry-procedure.html During the month of January, we will phase in the signing of IPv6 reverse zones. Further notification of this will be sent when the process is complete. 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

1 0

Announcement DNS Training Course
by RIPE NCC Training Services 13 Dec '05

13 Dec '05

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: Date: Friday, 27 January 2006 Time: 09:00 17:00 Location: Limassol, Cyprus And Date: Wednesday, 15 February 2006 Time: 09:00 17:00 Location: Manama, Bahrain Hosted by: 2Connect: http://www.2connectbahrain.com/ 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

unsubscribe jkuijer@dds.nl
by jkuijer＠dds.nl 30 Nov '05

30 Nov '05

Citeren dns-wg-request(a)ripe.net: > Send dns-wg mailing list submissions to > dns-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/dns-wg > or, via email, send a message with subject or body 'help' to > dns-wg-request(a)ripe.net > > You can reach the person managing the list at > dns-wg-admin(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dns-wg digest..." > > > Today's Topics: > > 1. unsubscribe jkuijer(a)dds.nl (jkuijer(a)dds.nl) > 2. RE: RIPE NCC DNSSEC on the reverse tree update. (Brett Carr) > 3. RE: RIPE NCC DNSSEC on the reverse tree update. (Alexander Gall) > > --__--__-- > > Message: 1 > Date: Tue, 29 Nov 2005 12:24:05 +0100 > From: jkuijer(a)dds.nl > To: dns-wg(a)ripe.net > Subject: [dns-wg] unsubscribe jkuijer(a)dds.nl > > Citeren dns-wg-request(a)ripe.net: > > > Send dns-wg mailing list submissions to > > dns-wg(a)ripe.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.ripe.net/mailman/listinfo/dns-wg > > or, via email, send a message with subject or body 'help' to > > dns-wg-request(a)ripe.net > > > > You can reach the person managing the list at > > dns-wg-admin(a)ripe.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of dns-wg digest..." > > > > > > Today's Topics: > > > > 1. RE: RIPE NCC DNSSEC on the reverse tree update. (Alexander Gall) > > 2. RE: RIPE NCC DNSSEC on the reverse tree update. (Randy Bush) > > > > -- __--__-- > > > > Message: 1 > > From: Alexander Gall <gall(a)switch.ch> > > Date: Mon, 28 Nov 2005 12:02:49 +0100 > > To: "Brett Carr" <brettcarr(a)ripe.net> > > Cc: <dns-wg(a)ripe.net> > > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > On Mon, 28 Nov 2005 11:24:45 +0100, "Brett Carr" <brettcarr(a)ripe.net> said: > > > > >> -----Original Message----- > > >> From: Alexander Gall [mailto:gall@switch.ch] > > >> Sent: 28 November 2005 08:47 > > >> To: Brett Carr > > >> Cc: dns-wg(a)ripe.net > > >> Subject: Re: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > >> > > >> Brett, > > >> > > >> What's going on with 195.in-addr.arpa? All DNSSEC records > > >> are gone, e.g. > > >> > > > > > We saw some zone file corruption during the early hours of the morning, > > this > > > caused a failsafe operation to takeover and hence the zones were > published > > > without signatures. I've investigated and fixed the corruption and so now > > > everything is back to normal. > > > > Thanks. Having such a failsafe procedure is probably a good idea. > > However, it caused my sub-zone to be marked as bogus, which is bad > > (i.e. my cache with only the key for 195.in-addr.arpa configured as > > trusted key returned SERVFAIL for all queries within > > 176.195.in-addr.arpa). I think that you must not leave the DS records > > in the zone when all other DNSSEC RRsets are removed (and the DS > > record for my zone was definitely there). Otherwise, a verifier will > > find a DS record but is unable to check its authenticity and has to > > declare the zone as bogus. > > > > -- > > Alex > > > > > > > > -- __--__-- > > > > Message: 2 > > From: Randy Bush <randy(a)psg.com> > > Date: Mon, 28 Nov 2005 06:01:50 -1000 > > To: "Brett Carr" <brettcarr(a)ripe.net> > > Cc: dns-wg(a)ripe.net > > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > > We saw some zone file corruption during the early hours of the > > > morning, this caused a failsafe operation to takeover and hence > > > the zones were published without signatures. > > > > considering the obvious attack paths this opens, one assumes that > > this 'failsafe' would not be part of the operation of a secure > > zone in normal, as opposed to trial, operation. > > > > randy > > > > > > > > > > End of dns-wg Digest > > > > > > > --__--__-- > > Message: 2 > From: "Brett Carr" <brettcarr(a)ripe.net> > To: "'Alexander Gall'" <gall(a)switch.ch> > Cc: <dns-wg(a)ripe.net> > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > Date: Tue, 29 Nov 2005 16:38:58 +0100 > > > > > -----Original Message----- > > From: Alexander Gall [mailto:gall@switch.ch] > > Sent: 25 November 2005 15:22 > > To: Brett Carr > > Cc: dns-wg(a)ripe.net > > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > Brett, > > > > On Fri, 25 Nov 2005 14:41:34 +0100, "Brett Carr" > > <brettcarr(a)ripe.net> said: > > > > >> -----Original Message----- > > >> From: Alexander Gall [mailto:gall@switch.ch] > > >> Sent: 25 November 2005 11:48 > > >> To: Brett Carr > > >> Cc: dns-wg(a)ripe.net > > >> Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > > > [...] > > > > >> > > >> However, I think there is a problem with ns.ripe.net. It doesn't > > >> return DNSSEC RRsets when the DO flag is set in the query: > > >> > > > > [...] > > > > > I found a small config typo, which I have fixed, it should > > be ok now though. > > > > Thanks, it looks good now. > > > > Did you have a chance to look (or have somebody else have a > > look :-) at > > <https://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi> for the > > zone 176.195.in-addr.arpa? I can see two problems: > > > > - For some reason, the tool doesn't get replies to queries for NS and > > DNSKEY records at our name servers {merapi,scsnms}.switch.ch with > > the DO flag set. The tool then (erroneously) concludes that these > > RRsets are inconsistent among the servers for the zone. > > > > I see the queries coming in on our servers from 193.0.0.214. Could > > it be that the replies are filtered somwhere in your network (having > > strange flags and all that)? > > > We have now fixed this after finding some strange (udp fragment) filtering > behaviour on our Juniper router, We will be carrying out more (lab based) > tests on this and will report the results to Juniper. > > Regards > > 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 > > > > > --__--__-- > > Message: 3 > From: Alexander Gall <gall(a)switch.ch> > Date: Wed, 30 Nov 2005 08:59:37 +0100 > To: "Brett Carr" <brettcarr(a)ripe.net> > Cc: <dns-wg(a)ripe.net> > Subject: RE: [dns-wg] RIPE NCC DNSSEC on the reverse tree update. > > On Tue, 29 Nov 2005 16:38:58 +0100, "Brett Carr" <brettcarr(a)ripe.net> said: > > >> Did you have a chance to look (or have somebody else have a > >> look :-) at > >> <https://www.ripe.net/cgi-bin/delcheck/delcheck2.cgi> for the > >> zone 176.195.in-addr.arpa? I can see two problems: > >> > >> - For some reason, the tool doesn't get replies to queries for NS and > >> DNSKEY records at our name servers {merapi,scsnms}.switch.ch with > >> the DO flag set. The tool then (erroneously) concludes that these > >> RRsets are inconsistent among the servers for the zone. > >> > >> I see the queries coming in on our servers from 193.0.0.214. Could > >> it be that the replies are filtered somwhere in your network (having > >> strange flags and all that)? > > > > We have now fixed this after finding some strange (udp fragment) filtering > > behaviour on our Juniper router, We will be carrying out more (lab based) > > tests on this and will report the results to Juniper. > > Thanks! > > -- > Alex > > > > > End of dns-wg Digest >

1 0