From lutz at iks-jena.de Thu Feb 2 18:40:07 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 2 Feb 2006 17:40:07 +0000 (UTC) Subject: [dns-wg] Just another lookaside zone Message-ID: -----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----- From dwmalone at maths.tcd.ie Mon Feb 6 22:14:46 2006 From: dwmalone at maths.tcd.ie (David Malone) Date: Mon, 06 Feb 2006 21:14:46 +0000 Subject: [dns-wg] DNS Misbehavior Doc Message-ID: <200602062114.aa30573@salmon.maths.tcd.ie> 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. From training at ripe.net Tue Feb 7 13:39:46 2006 From: training at ripe.net (RIPE NCC Training Services) Date: Tue, 07 Feb 2006 13:39:46 +0100 Subject: [dns-wg] Announcement DNS Training Course Message-ID: <20060207123946.ED2E42F598@herring.ripe.net> 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 . 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 From lutz at iks-jena.de Tue Feb 7 18:13:56 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 7 Feb 2006 17:13:56 +0000 (UTC) Subject: [dns-wg] Just another lookaside zone References: Message-ID: * Lutz Donnerhacke wrote: > I did not manage to install a web form right now. If you like to > get listed, please send me an email. Webform including some statistics is online: https://www.iks-jena.de/leistungen/dnssec.php If you are not listed, you might add yourself. > 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. Problem solved. Half a day after this message, Cable & Wireless announced, that the switched there DNS infrastructure (at least for secondaries) to DNSSEC. Great! From gall at switch.ch Wed Feb 8 12:05:45 2006 From: gall at switch.ch (Alexander Gall) Date: Wed, 8 Feb 2006 12:05:45 +0100 Subject: [dns-wg] Just another lookaside zone In-Reply-To: References: Message-ID: <17385.53385.420390.123170@hadron.switch.ch> On Tue, 7 Feb 2006 17:13:56 +0000 (UTC), Lutz Donnerhacke said: > * Lutz Donnerhacke wrote: >> I did not manage to install a web form right now. If you like to >> get listed, please send me an email. > Webform including some statistics is online: > https://www.iks-jena.de/leistungen/dnssec.php I have several questions: Why do you include DLV Records for Zones that are below a secure entry point (those you call "chained")? They will never be used unless the parent zones become insecure. What exactly does "DNSKEY unchecked, DSSET given" mean? I suppose that you have received the DSSET by the maintainer of the zone through an authenticated channel (if not, you shouldn't add the DLV record at all). Why doesn't that make it a secure entry point and why should you "check" the DNSKEY? Why do you include DLV records for zones that you know are broken? Obviously, this classification has no meaning for a resolver that does lookaside validation. All DLV Records in this zone must have been authenticated by you (and we all trust you, of course :-), or the scheme is useless. Or am I missing the point and this zone should be used as a repository for secure entry points from which one creates local trusted keys rather than use it as a true lookaside zone? Personally, I have come to the conclusion that I don't like it at all that my cache considers the entire DNS bogus when the DLV zone becomes unreachable or corrupted. I'll stick to my locally configured trusted keys and wait for the root to be signed. BTW, there are some nasty bugs in the DLV implementation in BIND up to 9.3.2 (e.g. see what happens when you corrupt the trusted key of your DLV zone, but don't do it on your production server :-) I've been told that it has been improved a lot for 9.4 and these changes will be backported to 9.3.3. >> 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. > Problem solved. Half a day after this message, Cable & Wireless announced, > that the switched there DNS infrastructure (at least for secondaries) to > DNSSEC. Great! Cool. In case you still need secondaries, I can offer two in Switzerland with excellent IPv6 connectivity :-) -- Alex From lutz at iks-jena.de Wed Feb 8 13:01:30 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 8 Feb 2006 12:01:30 +0000 (UTC) Subject: [dns-wg] Just another lookaside zone References: <17385.53385.420390.123170@hadron.switch.ch> Message-ID: * Alexander Gall wrote: > Why do you include DLV Records for Zones that are below a secure entry > point (those you call "chained")? They will never be used unless the > parent zones become insecure. My tests show, that some resolvers only go one step back to the origin to check the lookaside data. So if you query for host.sub.do.main, these resolvers do only query for host.sub.do.main.trust.an.chor and sub.do.main.trust.an.chor. I have to dig this problem much deeper, to see iff this is a configuration or software issue. In order to keep the lookaside zone useful, I included the subzones. OTOH it's possible, that the parent zone becomes unsigned. In this case the sub zones become new SEPs. If would be the only reason, I'll move the DLV entries to TXT entries in order to keep them as a backup. Furthermore, I regulary check the validity of the DNSKEYs with the DS parent entries to detect errors in chaining (i.e. after rollover errors). > What exactly does "DNSKEY unchecked, DSSET given" mean? I suppose > that you have received the DSSET by the maintainer of the zone through > an authenticated channel (if not, you shouldn't add the DLV record at > all). Why doesn't that make it a secure entry point and why should > you "check" the DNSKEY? This entry means: Somebody added a zone. This process generates the DS entry from the queried DNSKEY. If possible the DNSKEY is queried using DNSSEC authenication, so you can't add a sub zone of a signed parent zone without correct chaining. I should add the validation step for the person, who adds this zone, of course. Thanks for this suggestion. The daily maintainance check "drops" all entries an requeries them using the old lookaside zone. Only authenicated responses are used to rebuild the zone. In this step the parent chaining is checked, too. And sub zones are added, if possible using AXFR or (on dlv.verisignlabs.com) by NSEC traversing. For new SEPs there exists currently no trustly off-band validation. Because everybody can set up a signed zone, any attacker can sign any zone unter his control and provide any typical validation. I only check, that the real zone is really signed. I do not trust other name servers than the ICANN root (and myself). Of course it is possible to attack to my infrastructure in order to fool my name servers. > Why do you include DLV records for zones that you know are broken? The check is done from my point of view. I do not assume permanent access to every zone in the internet. Some broken zones might be truly operational in other networks. I assume that ct.nl and fnl.nl are operational on nlnetlabs. I also assume that demo.netsec.tislabs.com is operational on tislabs. It might be helpful for operators to have an outside view to this zone. There might be an TCP/53 block between AS15725 and the authorized name servers. The name servers might be offline or the zone is expired on the secondaries. There even might be an routing loop like this one: traceroute to dnssec1.jprs.co.jp (2001:200:132::2) from 2001:4bd8:0:666:280:adff:fe1e:79ba ...huge IPv6 delay on C&W backbone in USA... 12 pc8.otemachi.wide.ad.jp (2001:200:0:4401::11) 299.067 ms 13 otemachi.dnslab.jp (2001:200:132:4::2) 299.889 ms 14 fuundo.dnslab.jp (2001:200:132:5::1) 301.206 ms 15 otemachi.dnslab.jp (2001:200:132:4::2) 301.584 ms > Obviously, this classification has no meaning for a resolver that does > lookaside validation. All DLV Records in this zone must have been > authenticated by you (and we all trust you, of course :-), or the > scheme is useless. Exactly. At the moment there is a large gap between trusting the unknown and stay unusable because there are no entries at all. My way might be to risky for you. That's ok. Any suggestion is welcome. > Or am I missing the point and this zone should be used as a repository > for secure entry points from which one creates local trusted keys > rather than use it as a true lookaside zone? It serves both issues, but the main subject it to generate trust. > Personally, I have come to the conclusion that I don't like it at all > that my cache considers the entire DNS bogus when the DLV zone becomes > unreachable or corrupted. You are free to set up a secondary. You will get notifies automatically. Of course invalid signatures are really bad. Because I switched almost all name server I admin to this zone, such a mistake will be noticed very quickly ;-) > I'll stick to my locally configured trusted > keys and wait for the root to be signed. Of course. Do you configure the trusted keys to every of your name servers? How do to keep them in sync? You you really believe to see a signed root this life? > BTW, there are some nasty bugs in the DLV implementation in BIND up to > 9.3.2 (e.g. see what happens when you corrupt the trusted key of your > DLV zone, but don't do it on your production server :-) I've been > told that it has been improved a lot for 9.4 and these changes will be > backported to 9.3.3. Thanx. The problems with the Windows DNS server software are much harder to solve. Is there any rewrite out there? Or do we have to write one yourself? > In case you still need secondaries, I can offer two in > Switzerland with excellent IPv6 connectivity :-) Thank you. Currently I prefer to complain using your service contracts. From gall at switch.ch Wed Feb 8 16:30:20 2006 From: gall at switch.ch (Alexander Gall) Date: Wed, 8 Feb 2006 16:30:20 +0100 Subject: [dns-wg] Just another lookaside zone In-Reply-To: References: <17385.53385.420390.123170@hadron.switch.ch> Message-ID: <17386.3724.266780.278261@hadron.switch.ch> On Wed, 8 Feb 2006 12:01:30 +0000 (UTC), Lutz Donnerhacke said: > * Alexander Gall wrote: >> Why do you include DLV Records for Zones that are below a secure entry >> point (those you call "chained")? They will never be used unless the >> parent zones become insecure. > My tests show, that some resolvers only go one step back to the origin to > check the lookaside data. So if you query for host.sub.do.main, these > resolvers do only query for host.sub.do.main.trust.an.chor and > sub.do.main.trust.an.chor. But DLV is only applied to the apex of a secure subtree. Let's take 0.176.195.in-addr.arpa as an example. This involves two secure delegations. The resolver walks up the tree using regular DNSSEC until it finds that 195.in-addr.arpa is insecure. No DLV is involved up to this point. Only then does it try to see if it can authenticate the DNSKEY of 195.in-addr.arpa with DLV. The sub-zones are never considered for DLV. I think that doing anything else is just plain broken. But then again, there is no spec how DLV is supposed to work, so who can say what's right ;-) > I have to dig this problem much deeper, to see iff this is a configuration > or software issue. > In order to keep the lookaside zone useful, I included the subzones. > OTOH it's possible, that the parent zone becomes unsigned. In this case the > sub zones become new SEPs. If would be the only reason, I'll move the DLV > entries to TXT entries in order to keep them as a backup. > Furthermore, I regulary check the validity of the DNSKEYs with the DS parent > entries to detect errors in chaining (i.e. after rollover errors). Interesting. And what do you do when the DS doesn't match the DNSKEY? For a rollover, if both keys (old and new) are in the DNSKEY RRset and the RRset is signed by the old key, you can safely roll the DS as well. In all other cases, you *must* keep the broken chain. This will render the zone bogus, but this is precisely what should happen. >> What exactly does "DNSKEY unchecked, DSSET given" mean? I suppose >> that you have received the DSSET by the maintainer of the zone through >> an authenticated channel (if not, you shouldn't add the DLV record at >> all). Why doesn't that make it a secure entry point and why should >> you "check" the DNSKEY? > This entry means: Somebody added a zone. This process generates the DS entry > from the queried DNSKEY. If possible the DNSKEY is queried using DNSSEC > authenication, so you can't add a sub zone of a signed parent zone without > correct chaining. I should add the validation step for the person, who adds > this zone, of course. Thanks for this suggestion. But you don't need DLV if the parent zone is signed! This is covered by plain DNSSEC. > The daily maintainance check "drops" all entries an requeries them using the > old lookaside zone. Only authenicated responses are used to rebuild the zone. I'm not sure I understand the use of this. Can you give an example of what new information you can discover this way (apart from catching roll-overs in progress)? > In this step the parent chaining is checked, too. And sub zones are added, if > possible using AXFR or (on dlv.verisignlabs.com) by NSEC traversing. > For new SEPs there exists currently no trustly off-band validation. Because > everybody can set up a signed zone, any attacker can sign any zone unter his > control and provide any typical validation. I only check, that the real zone > is really signed. I do not trust other name servers than the ICANN root (and > myself). Many of the current islands of security publish their SEPs over https. This looks all right to me if you check the certificates carefully. I think you should not accept unauthenticated SEPs at all. > Of course it is possible to attack to my infrastructure in order to fool my > name servers. >> Why do you include DLV records for zones that you know are broken? > The check is done from my point of view. I do not assume permanent access to > every zone in the internet. Some broken zones might be truly operational in > other networks. I assume that ct.nl and fnl.nl are operational on nlnetlabs. > I also assume that demo.netsec.tislabs.com is operational on tislabs. Then you can probably also assume that they configure their resolvers with their own trusted keys and don't use your DLV zone :-) > It might be helpful for operators to have an outside view to this zone. > There might be an TCP/53 block between AS15725 and the authorized name > servers. > The name servers might be offline or the zone is expired on the secondaries. > There even might be an routing loop like this one: > traceroute to dnssec1.jprs.co.jp (2001:200:132::2) > from 2001:4bd8:0:666:280:adff:fe1e:79ba > ...huge IPv6 delay on C&W backbone in USA... > 12 pc8.otemachi.wide.ad.jp (2001:200:0:4401::11) 299.067 ms > 13 otemachi.dnslab.jp (2001:200:132:4::2) 299.889 ms > 14 fuundo.dnslab.jp (2001:200:132:5::1) 301.206 ms > 15 otemachi.dnslab.jp (2001:200:132:4::2) 301.584 ms >> Obviously, this classification has no meaning for a resolver that does >> lookaside validation. All DLV Records in this zone must have been >> authenticated by you (and we all trust you, of course :-), or the >> scheme is useless. > Exactly. At the moment there is a large gap between trusting the unknown > and stay unusable because there are no entries at all. My way might be to > risky for you. That's ok. Any suggestion is welcome. My suggestion is to establish real trust. Yes, that's hard. But I can't see how you can do without. >> Or am I missing the point and this zone should be used as a repository >> for secure entry points from which one creates local trusted keys >> rather than use it as a true lookaside zone? > It serves both issues, but the main subject it to generate trust. Right, but this is precisely what's missing right now, isn't? >> Personally, I have come to the conclusion that I don't like it at all >> that my cache considers the entire DNS bogus when the DLV zone becomes >> unreachable or corrupted. > You are free to set up a secondary. You will get notifies automatically. Of > course invalid signatures are really bad. Because I switched almost all name > server I admin to this zone, such a mistake will be noticed very quickly ;-) Yes. But this may have severe consequences. Suppose admin X uses your DLV zone. An attacker DoSes all the server for this zone. X can't resolve any queries any more and decides to disable DNSSEC. Now all zones that were previously protected by DNSSEC are spoofable. You may say that this is also possible with plain DNSSEC. True, but then the damage is restricted to the subtree of the zone that's being DoSed, where as the entire DNS is considered to be a child of the DLV zone. DoSing the root zone is considerably harder than DoSing your hadful of name servers. The problem is that DLV acts a lot like the true root zone when it brakes, but only protects very few zones when it works (the absence of a key in the DLV zone has no real meaning, I think, compared to a "provably insecure" zone in plain DNSSEC). >> I'll stick to my locally configured trusted >> keys and wait for the root to be signed. > Of course. Do you configure the trusted keys to every of your name servers? > How do to keep them in sync? > You you really believe to see a signed root this life? I don't know. But I believe that DNSSEC will fail if it doesn't happen. -- Alex From lutz at iks-jena.de Wed Feb 8 18:35:44 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 8 Feb 2006 17:35:44 +0000 (UTC) Subject: [dns-wg] Just another lookaside zone References: <17386.3724.266780.278261@hadron.switch.ch> Message-ID: * Alexander Gall wrote: > But DLV is only applied to the apex of a secure subtree. Let's take > 0.176.195.in-addr.arpa as an example. This involves two secure > delegations. The resolver walks up the tree using regular DNSSEC > until it finds that 195.in-addr.arpa is insecure. No DLV is involved > up to this point. Only then does it try to see if it can authenticate > the DNSKEY of 195.in-addr.arpa with DLV. The sub-zones are never > considered for DLV. I think that doing anything else is just plain > broken. But then again, there is no spec how DLV is supposed to work, > so who can say what's right ;-) Of course, I'll remove the DLV entries for chained zones. These resolvers need to be fixed, not the zone. Give me a day. > On Wed, 8 Feb 2006 12:01:30 +0000 (UTC), Lutz Donnerhacke said: >> Furthermore, I regulary check the validity of the DNSKEYs with the DS parent >> entries to detect errors in chaining (i.e. after rollover errors). > > Interesting. And what do you do when the DS doesn't match the DNSKEY? After the change tomorrow, the DLV entry will be inserted to keep in touch with the changed zone. It will dismiss, if the parent reflects the change. Such behavior will only happen, if the new key is signed with a valid old one. It's not required, that the new key is used for signing in this very moment. Might only be happen if the rollover period is too short or if the client do not notify the parent at all. Oh, the parent might also simply drop the DS record. In this case the formerly verified DNSKEYs are used to generate DLV entries. I'd should display an error indicator due to broken chaining. > For a rollover, if both keys (old and new) are in the DNSKEY RRset and > the RRset is signed by the old key, you can safely roll the DS as well. On usual rollover, all keys are valid as long as there exists a valid chain to each of them. Valid keys are retained for chain breaks. So normal rollover does not harm. > In all other cases, you *must* keep the broken chain. This will render > the zone bogus, but this is precisely what should happen. IBTD. From the operational point of view the error in chaining is much more likely to be an mistake, than a thought decision. The new DNSKEYs has to be signed to be accepted, so there must exists a operational action to break this chain while staying in the DLV. I prefer to keep the network running. DNSKEY changes without a trust chain from already trusted entries are not accepted, so classical attacks will not cause the DLV to show up the attackers key as valid. >> This entry means: Somebody added a zone. This process generates the DS >> entry from the queried DNSKEY. If possible the DNSKEY is queried using >> DNSSEC authenication, so you can't add a sub zone of a signed parent >> zone without correct chaining. I should add the validation step for the >> person, who adds this zone, of course. Thanks for this suggestion. > > But you don't need DLV if the parent zone is signed! This is covered > by plain DNSSEC. This case will change tomorrow to only notice the existance of the signed sub zone. Usually new entries are added as islands. >> The daily maintainance check "drops" all entries an requeries them using the >> old lookaside zone. Only authenicated responses are used to rebuild the zone. > > I'm not sure I understand the use of this. Can you give an example > of what new information you can discover this way (apart from catching > roll-overs in progress)? Apart rollovers? I try to detect legitimate rollovers. But there are other kinds of key changes, which are detected in this way. As long as they match the rollover procedure, I try to keep in touch. OTOH it's a simple "reachable" check from outside. >> For new SEPs there exists currently no trustly off-band validation. Because >> everybody can set up a signed zone, any attacker can sign any zone unter his >> control and provide any typical validation. I only check, that the real zone >> is really signed. I do not trust other name servers than the ICANN root (and >> myself). > > Many of the current islands of security publish their SEPs over https. > This looks all right to me if you check the certificates carefully. Please let me smile. First: There is no canonical way to get the DNSKEY information automatically. Second: If the zone is under attackers control, each validation can be forged. You might refer to SSL certificates, but I do not trust most of those CAs. We are in the CA bussiness since about nine years. I lost all my illusions. > I think you should not accept unauthenticated SEPs at all. If I do not accept it, the zone can only be used unsigned. What a security improvement! >> The check is done from my point of view. I do not assume permanent >> access to every zone in the internet. Some broken zones might be truly >> operational in other networks. I assume that ct.nl and fnl.nl are >> operational on nlnetlabs. I also assume that demo.netsec.tislabs.com is >> operational on tislabs. > > Then you can probably also assume that they configure their resolvers > with their own trusted keys and don't use your DLV zone :-) I do not claim my assumptions as true. If you can reach those zones, the DLV entry might be useful. If you can't reach those zones, they do not harm you. >> Exactly. At the moment there is a large gap between trusting the unknown >> and stay unusable because there are no entries at all. My way might be to >> risky for you. That's ok. Any suggestion is welcome. > > My suggestion is to establish real trust. Yes, that's hard. > But I can't see how you can do without. It's very possible to be too paranoid. Unrelated and uncheckable information can be considered true without any damage. That's why I include it. >> You are free to set up a secondary. You will get notifies >> automatically. Of course invalid signatures are really bad. Because I >> switched almost all name server I admin to this zone, such a mistake >> will be noticed very quickly ;-) > > Yes. But this may have severe consequences. Suppose admin X uses > your DLV zone. An attacker DoSes all the server for this zone. If X set up a secondary (as recommened), the DoS does not harm unless the zone times out. In this case X get's a notice from its own name server and can use the secondary data as primary, if necessary. But if X has a minimal interest in his infrastructure, he will notice such a DoS of a "partner" much earlier. If the zone times out due to such an attack, it's very likely that my company does not exists anymore. So X has to contact an other source anyway. > X can't resolve any queries any more and decides to disable DNSSEC. > Now all zones that were previously protected by DNSSEC are spoofable. X has a long transition period to change. X is not required to disable DNSSEC at all, because backup data is available. > You may say that this is also possible with plain DNSSEC. True, but > then the damage is restricted to the subtree of the zone that's being > DoSed, where as the entire DNS is considered to be a child of the DLV > zone. DoSing the root zone is considerably harder than DoSing your > hadful of name servers. Ack. > The problem is that DLV acts a lot like the true root zone when it > brakes, but only protects very few zones when it works (the absence of a > key in the DLV zone has no real meaning, I think, compared to a "provably > insecure" zone in plain DNSSEC). Nack. Provably insecure is not caused by unreachablity of a name server. It is caused by reaching the server and get a signed answer. >>> I'll stick to my locally configured trusted >>> keys and wait for the root to be signed. > >> Of course. Do you configure the trusted keys to every of your name servers? >> How do to keep them in sync? I'm really interested in an answer to this question, because this was the basic reason to set up the lookaside zone. >> You you really believe to see a signed root this life? > > I don't know. But I believe that DNSSEC will fail if it doesn't happen. Global requirements are the main reason to fail projects. It would be nice to have, but it's unlikely. So we have to deal with. BTW: Congratulations to your signings. Your zones does appear last night in my monitoring and I'm very happy to see that deployment increases. From gall at switch.ch Thu Feb 9 16:47:54 2006 From: gall at switch.ch (Alexander Gall) Date: Thu, 9 Feb 2006 16:47:54 +0100 Subject: [dns-wg] Just another lookaside zone In-Reply-To: References: <17386.3724.266780.278261@hadron.switch.ch> Message-ID: <17387.25642.675340.242134@hadron.switch.ch> On Wed, 8 Feb 2006 17:35:44 +0000 (UTC), Lutz Donnerhacke said: > * Alexander Gall wrote: >> On Wed, 8 Feb 2006 12:01:30 +0000 (UTC), Lutz Donnerhacke said: >>> Furthermore, I regulary check the validity of the DNSKEYs with the DS parent >>> entries to detect errors in chaining (i.e. after rollover errors). >> >> Interesting. And what do you do when the DS doesn't match the DNSKEY? > After the change tomorrow, the DLV entry will be inserted to keep in touch > with the changed zone. It will dismiss, if the parent reflects the change. > Such behavior will only happen, if the new key is signed with a valid old > one. It's not required, that the new key is used for signing in this very > moment. Might only be happen if the rollover period is too short or if the > client do not notify the parent at all. > Oh, the parent might also simply drop the DS record. In this case the > formerly verified DNSKEYs are used to generate DLV entries. > I'd should display an error indicator due to broken chaining. >> For a rollover, if both keys (old and new) are in the DNSKEY RRset and >> the RRset is signed by the old key, you can safely roll the DS as well. > On usual rollover, all keys are valid as long as there exists a valid chain > to each of them. Valid keys are retained for chain breaks. So normal > rollover does not harm. Yes, that's what I meant. >> In all other cases, you *must* keep the broken chain. This will render >> the zone bogus, but this is precisely what should happen. > IBTD. From the operational point of view the error in chaining is much more > likely to be an mistake, than a thought decision. The new DNSKEYs has to be > signed to be accepted, so there must exists a operational action to break > this chain while staying in the DLV. I prefer to keep the network running. Surely you don't mean to say that you remove a DLV RR when it no longer authenticates the DNSKEY RRset. Or are you? I might misunderstand what you mean by "keep the network running", so I'll try to rephrase what I wanted to say. DNSSEC doesn't tolerate mistakes that break the chain of trust because it can't be distinguished from an attack. Now, it would be perfectly fine for an end user to decide for himself whether he wants to accept the bogus information or not, but, of course, that's impossible without an API or DNSSEC support in the stub resolver which allows for a local policy. In any case, DNSSEC must provide this information (i.e. that the delegation is broken). > DNSKEY changes without a trust chain from already trusted entries are not > accepted, so classical attacks will not cause the DLV to show up the > attackers key as valid. That would be really bad. I tried to argue that removing the DLV must not be done either. >>> The daily maintainance check "drops" all entries an requeries them using the >>> old lookaside zone. Only authenicated responses are used to rebuild the zone. >> >> I'm not sure I understand the use of this. Can you give an example >> of what new information you can discover this way (apart from catching >> roll-overs in progress)? > Apart rollovers? I try to detect legitimate rollovers. But there are other > kinds of key changes, which are detected in this way. As long as they match > the rollover procedure, I try to keep in touch. OTOH it's a simple > "reachable" check from outside. Sorry, I didn't realize that the main purpose of your daily job was checking for rollovers. We are in violent agreement here. >>> For new SEPs there exists currently no trustly off-band validation. Because >>> everybody can set up a signed zone, any attacker can sign any zone unter his >>> control and provide any typical validation. I only check, that the real zone >>> is really signed. I do not trust other name servers than the ICANN root (and >>> myself). >> >> Many of the current islands of security publish their SEPs over https. >> This looks all right to me if you check the certificates carefully. > Please let me smile. First: There is no canonical way to get the DNSKEY > information automatically. Second: If the zone is under attackers control, > each validation can be forged. I'm talking about OOB methods, of course (like ). > You might refer to SSL certificates, but I do not trust most of those CAs. > We are in the CA bussiness since about nine years. I lost all my illusions. I know that PKIs are not what they were promised to be, but they are not completely worthless either. I try to maintain a level of trust that I feel comfortable with. >> I think you should not accept unauthenticated SEPs at all. > If I do not accept it, the zone can only be used unsigned. > What a security improvement! Um, I prefer an unsigned zone over one whose signatures I cannot trust. What is the improvement there? [...] >>> Exactly. At the moment there is a large gap between trusting the unknown >>> and stay unusable because there are no entries at all. My way might be to >>> risky for you. That's ok. Any suggestion is welcome. >> >> My suggestion is to establish real trust. Yes, that's hard. >> But I can't see how you can do without. > It's very possible to be too paranoid. Unrelated and uncheckable information > can be considered true without any damage. That's why I include it. As I said, it should be up to the user to decide whether he want's to use the information or not (just like he can chose to accept a bogus SSL certificate, which can be perfectly harmless, too). That's not the point, though. Signatures are completely useless without trust. It's even worse because they can give the casual user a false sense of security. I'm sure you know that better than me. Without trust, this whole excercise is essentially a test of DNSSEC implementations. That's fine, too, but it needs to be stated clearly. >>> You are free to set up a secondary. You will get notifies >>> automatically. Of course invalid signatures are really bad. Because I >>> switched almost all name server I admin to this zone, such a mistake >>> will be noticed very quickly ;-) >> >> Yes. But this may have severe consequences. Suppose admin X uses >> your DLV zone. An attacker DoSes all the server for this zone. > If X set up a secondary (as recommened), the DoS does not harm unless the Having all users of the DLV zone become a secondary doesn't scale (because of the size of the NS RRset and possibly the load on the master). > zone times out. In this case X get's a notice from its own name server and > can use the secondary data as primary, if necessary. But if X has a minimal > interest in his infrastructure, he will notice such a DoS of a "partner" > much earlier. If the zone times out due to such an attack, it's very likely > that my company does not exists anymore. So X has to contact an other source > anyway. >> X can't resolve any queries any more and decides to disable DNSSEC. >> Now all zones that were previously protected by DNSSEC are spoofable. > X has a long transition period to change. > X is not required to disable DNSSEC at all, because backup data is available. I think this would be equivalent to the following. Let people download a signed file with the keys and install them as trusted keys in their servers (the key that signs the file would have to be authenticated just like the one for the zone dnssec.iks-jena.de). If all the information is local anyway, DLV would then just be a complicated way to check a local trust anchor. Using an established mechanism (AXFR) to distribute the zone is nice, but it's not a necessity (oops, I'm starting to sound like Dan Bernstein ;-) [...] >> The problem is that DLV acts a lot like the true root zone when it >> brakes, but only protects very few zones when it works (the absence of a >> key in the DLV zone has no real meaning, I think, compared to a "provably >> insecure" zone in plain DNSSEC). > Nack. Provably insecure is not caused by unreachablity of a name server. > It is caused by reaching the server and get a signed answer. I'm not talking about unreachable servers but about getting a prove that a particular name does not exist in the DLV zone. What does it mean? It's the same as not having a local trust anchor configured for the zone, but it does not constitute a prove that the zone is unsigned. So, you have less information about the zone than when you get prove from the parent zone that no DS RRset exists. Essentially, you don't learn anything about zones that are not in the DLV zone, and yet, all of these zones are considered compromised when the DLV zone is broken. This trade-off is what bothers me the most. >>>> I'll stick to my locally configured trusted >>>> keys and wait for the root to be signed. >> >>> Of course. Do you configure the trusted keys to every of your name servers? >>> How do to keep them in sync? > I'm really interested in an answer to this question, > because this was the basic reason to set up the lookaside zone. This is easy. I centrally maintain a BIND configuration snippet for the "trusetd-key" clause and push it to my caching servers with scp (I also do some failsafe checking that the config is OK before doing a "rndc reconfig"). It's simple and reliable. The situation is a bit like with the now deprecated A6 RR. Renumbering your own DNS zones is easy. All you need is a bit of discipline and a perl script. You don't need A6 for that. The true value of A6 would have been renumbering across administative boundaries. Similarly, DLV is only needed if you use a "regular" DLV zone. If everybody keeps a local copy of the zone as you suggest, DLV is just overhead, as I tried to explain above. >>> You you really believe to see a signed root this life? >> >> I don't know. But I believe that DNSSEC will fail if it doesn't happen. > Global requirements are the main reason to fail projects. It would be nice > to have, but it's unlikely. So we have to deal with. DNS just happens to be a global infrastructure :-) Idon't think it would have worked if it had started as a heap of disconnected pieces patched together by a mechanism that doesn't scale. If it were just a technological issue, I'd be all for it and use any hack to get it going (I should know, because I'm a long-term IPv6 and multicast user ;-) Unfortunatley, I don't think this will do much good if security is the main objective. > BTW: Congratulations to your signings. Your zones does appear last night in > my monitoring and I'm very happy to see that deployment increases. Yeah, I hadn't realized that RIPE NCC had signed 6.0.1.0.0.2.ip6.arpa until I spotted the entry on your site. Our zone 195.176.in-addr.arpa has been securely delegated since November. -- Alex From lutz at iks-jena.de Thu Feb 9 18:58:10 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 9 Feb 2006 17:58:10 +0000 (UTC) Subject: [dns-wg] Just another lookaside zone References: <17387.25642.675340.242134@hadron.switch.ch> Message-ID: * Alexander Gall wrote: >> IBTD. From the operational point of view the error in chaining is much more >> likely to be an mistake, than a thought decision. The new DNSKEYs has to be >> signed to be accepted, so there must exists a operational action to break >> this chain while staying in the DLV. I prefer to keep the network running. > > Surely you don't mean to say that you remove a DLV RR when it no > longer authenticates the DNSKEY RRset. Or are you? No, I cleaned up the verification step so that DLVs are updated using the following parameters: Keys : valid, signed DNSKEYs DSs : valid, signed DS parent entries Old : DS entries from the active DLV zone If Keys and DSs exists, no DLV is generated. If Keys exists, DLVs are generated. If DSs exists, DLVs are generated for 30 days. If Old exists, DLVs are generated for 7 days. > DNSSEC doesn't tolerate mistakes that break the chain of trust because > it can't be distinguished from an attack. On rollover it's very likly to do not get the parent updated or the parent restores an old entry by accident. In this case, I generate DLVs based on validated information. I can't see what's wrong with it. > Now, it would be perfectly fine for an end user to decide for himself > whether he wants to accept the bogus information or not, but, of > course, that's impossible without an API or DNSSEC support in the stub > resolver which allows for a local policy. In any case, DNSSEC must > provide this information (i.e. that the delegation is broken). Please explain why and how a delegation can break. This will clarify why I prefer to keep former validated data active. > Sorry, I didn't realize that the main purpose of your daily job was > checking for rollovers. We are in violent agreement here. The main purpose of providing a DLV zone is to keep this zone in sync with reality. I do not expect all DNSSEC opertators to update there keys on my website. So I have to do it myself. >> Please let me smile. First: There is no canonical way to get the DNSKEY >> information automatically. Second: If the zone is under attackers control, >> each validation can be forged. > > I'm talking about OOB methods, of course (like > ). This page is used. On most other cases there is no way to be sure. >> You might refer to SSL certificates, but I do not trust most of those CAs. >> We are in the CA bussiness since about nine years. I lost all my illusions. > > I know that PKIs are not what they were promised to be, but they are > not completely worthless either. I try to maintain a level of trust > that I feel comfortable with. Please explain how a PKI can be used, if the common ones are not trustworthy and most DNSSEC operators does offer there keys on various unstandardized ways. I can't see any automatic check usable. There are 418 island of trust in the DLV zone at the moment. Please try and check some of the unknown yourself. >>> I think you should not accept unauthenticated SEPs at all. > >> If I do not accept it, the zone can only be used unsigned. >> What a security improvement! > > Um, I prefer an unsigned zone over one whose signatures I cannot > trust. What is the improvement there? If the keys are correct, you gain a valid signed zone. If the keys are wrong, you can be fooled about the zone content. If the keys are missing, you can be fooled about the zone content. The attacker has to modify the zone in order to get it listed in my list. If the attacker had modified the zone, the unsigned information are ... >> It's very possible to be too paranoid. Unrelated and uncheckable >> information can be considered true without any damage. That's why I >> include it. > > As I said, it should be up to the user to decide whether he want's to > use the information or not So you need a checklist with about 500 entries now customizable for each user. Not my task. Sorry. > Signatures are completely useless without trust. No signatures are better? > It's even worse because they can give the casual user a false sense of > security. I'm sure you know that better than me. Without trust, this > whole excercise is essentially a test of DNSSEC implementations. > That's fine, too, but it needs to be stated clearly. DNSSEC does not provide security in the common sense. It protects DNS to intermedeate changes. This can be achived. >> If X set up a secondary (as recommened), the DoS does not harm unless the > > Having all users of the DLV zone become a secondary doesn't scale > (because of the size of the NS RRset and possibly the load on the > master). I do not include them into the zone. They get notifies. That's all. >> X has a long transition period to change. X is not required to disable >> DNSSEC at all, because backup data is available. > > I think this would be equivalent to the following. Let people > download a signed file with the keys and install them as trusted keys > in their servers (the key that signs the file would have to be > authenticated just like the one for the zone dnssec.iks-jena.de). If > all the information is local anyway, DLV would then just be a > complicated way to check a local trust anchor. Using an established > mechanism (AXFR) to distribute the zone is nice, but it's not a > necessity (oops, I'm starting to sound like Dan Bernstein ;-) Of course. This is the distribution step I mentioned. It's easier to maintain using a DLV zone, than synching a lot of keys. Do rollover detection on those keys automatically and you end up in methods I use. If you do not maintain the key list, it's useless. >> Nack. Provably insecure is not caused by unreachablity of a name server. >> It is caused by reaching the server and get a signed answer. > > I'm not talking about unreachable servers but about getting a prove > that a particular name does not exist in the DLV zone. What does it > mean? Nothing. The zone can't be checked even if it is signed. > but it does not constitute a prove that the zone is unsigned. DLVs does not prove the signedness of a zone. > So, you have less information about the zone than when you > get prove from the parent zone that no DS RRset exists. If the parent has DS records, the zone is not in the DLV. The parent is. > Essentially, you don't learn anything about zones that are not in the DLV > zone, and yet, all of these zones are considered compromised when the DLV > zone is broken. This trade-off is what bothers me the most. DLVs are a distribution medium. If the distribution of your key files breaks, you get an equivalent disaster. >>>> Of course. Do you configure the trusted keys to every of your name servers? >>>> How do to keep them in sync? > >> I'm really interested in an answer to this question, >> because this was the basic reason to set up the lookaside zone. > > This is easy. I centrally maintain a BIND configuration snippet for > the "trusetd-key" clause and push it to my caching servers with scp (I > also do some failsafe checking that the config is OK before doing a > "rndc reconfig"). It's simple and reliable. I do not like to maintain a list of servers to push configuration to. Often I even can not do this because those machines are not mine or not reachable for typical distribution mechanisms. How many entries do you maintain in your trust key file? Are they still valid? > boundaries. Similarly, DLV is only needed if you use a "regular" DLV > zone. If everybody keeps a local copy of the zone as you suggest, DLV > is just overhead, as I tried to explain above. Setting up an hidden secondary is not an overhead. >> Global requirements are the main reason to fail projects. It would be nice >> to have, but it's unlikely. So we have to deal with. > > DNS just happens to be a global infrastructure :-) IPv6 either. Do we have it all over the world? > Idon't think it would have worked if it had started as a heap of > disconnected pieces patched together by a mechanism that doesn't scale. I assume it scales. YMMV. > If it were just a technological issue, I'd be all for it and use any > hack to get it going (I should know, because I'm a long-term IPv6 and > multicast user ;-) Unfortunatley, I don't think this will do much good > if security is the main objective. I do think of DNSSEC deployment as a technological issue. Did you notice, that dnssec-deployment.org is not signed ;-? >> BTW: Congratulations to your signings. Your zones does appear last night in >> my monitoring and I'm very happy to see that deployment increases. > > Yeah, I hadn't realized that RIPE NCC had signed 6.0.1.0.0.2.ip6.arpa > until I spotted the entry on your site. Our zone 195.176.in-addr.arpa > has been securely delegated since November. Great. An now you will notice, that some entries are going dead ... From lutz at iks-jena.de Tue Feb 14 12:16:57 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 14 Feb 2006 11:16:57 +0000 (UTC) Subject: [dns-wg] Just another lookaside zone References: Message-ID: * Lutz Donnerhacke wrote: > In order to extend the deployment of security technology, we switch to > DNSSEC for us and our customers. [...] This is the reason why, we set > up an other DLV zone. Please do *not* try to use this zone with any public available bind version. There is a bug in long time behaivor of the caching algorithms. Invalidating of cache entries occurs unrelated to DNSSEC. This causes invalidating of any signed entries over the time. The race condition caused by cache invalitation is large enough to hit the lookaside zone itself after some hours on a busy server. Normal usage hits the problem after some days. Due to the bind architecture, even authorized servers can be unable to deliver there own data. Look for "empty name resolving" entries in the logfiles. Unfortunly there is no working DNSSECable DNS server software out at all. From Roy.Arends at nominet.org.uk Tue Feb 14 15:04:50 2006 From: Roy.Arends at nominet.org.uk (Roy.Arends at nominet.org.uk) Date: Tue, 14 Feb 2006 15:04:50 +0100 Subject: [dns-wg] Just another lookaside zone In-Reply-To: Message-ID: dns-wg-admin at ripe.net wrote on 14-02-2006 12:16:57: > * Lutz Donnerhacke wrote: > > In order to extend the deployment of security technology, we switch to > > DNSSEC for us and our customers. [...] This is the reason why, we set > > up an other DLV zone. > > Please do *not* try to use this zone with any public available bind version. > There is a bug in long time behaivor of the caching algorithms. Invalidating > of cache entries occurs unrelated to DNSSEC. This causes invalidating of any > signed entries over the time. The race condition caused by cache > invalitation is large enough to hit the lookaside zone itself after some > hours on a busy server. Normal usage hits the problem after some days. Due > to the bind architecture, even authorized servers can be unable to deliver > there own data. > > Look for "empty name resolving" entries in the logfiles. > > Unfortunly there is no working DNSSECable DNS server software out at all. Try unbound as a validating DNSSEC resolver. http://www.rfc.se/unbound Roy From lutz at iks-jena.de Fri Feb 17 12:11:00 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 17 Feb 2006 11:11:00 +0000 (UTC) Subject: [dns-wg] DNSSEC breaks qmail Message-ID: 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 From jim at rfc1035.com Fri Feb 17 12:40:20 2006 From: jim at rfc1035.com (Jim Reid) Date: Fri, 17 Feb 2006 11:40:20 +0000 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: References: Message-ID: <5DAFCBFE-E4E3-4699-A04B-775FD970A9DB@rfc1035.com> On Feb 17, 2006, at 11:11, Lutz Donnerhacke wrote: > 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." Hmmm. Even though DJB's enthusiasm for DNSSEC is well known, I'm not sure it's fair to be blaming qmail. Well this time at least... This looks to be a local name server misconfiguration. Or perhaps a bug. qmail won't be asking for DNSSEC RR types. That's for sure. And it won't be setting the DO bit either because DJB is no fan of EDNS0. So qmail's lookups should not be getting RRSIGs and suchlike, which would hopefully mean it won't get truncated responses. RFC3225 says don't send DNSSEC RRtypes unless the client has set the DO bit to indicate they understand DNSSEC. So your local name server shouldn't be handing out these RRtypes to qmail's ANY QTYPE queries unless qmail set the D0 bit. Or have I missed something? From roy at nominet.org.uk Fri Feb 17 12:46:13 2006 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 17 Feb 2006 12:46:13 +0100 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: Message-ID: > 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." I can think of non-dnssec responses that are larger than 512 octets, so the subject of this message does not cover its content. I am not sure what CNAME has to do with this. I have seen patches for qmail that make it handle larger udp packet sizes. Which service marks a DNS message 'truncated' in your example ? Roy From pk at DENIC.DE Fri Feb 17 12:48:19 2006 From: pk at DENIC.DE (Peter Koch) Date: Fri, 17 Feb 2006 12:48:19 +0100 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: References: Message-ID: <20060217114819.GC1980@unknown.office.denic.de> On Fri, Feb 17, 2006 at 11:11:00AM +0000, Lutz Donnerhacke wrote: > - qmail send an "ANY IN edri.org" query in order to deliver mail. MX has been around for quite a while. > * Due to DNSSEC, there are a some signatures catched by ANY so the > response packet size is 605 bytes. Qmail has already had problems in the past with domain names where an ANY response exceeds 512 octets. It happens with large NS RRsets, RFC1101 PTRs or large TXT RR(Set)s which seem not so uncommon these days (although that's a mistake). There was a patch at , but i have no idea whether that can be applied today. > - qmail does not support EDNS extensions for larger UDP packets. That's probably not the application's problem, but the resolver's. > * The response is truncated to 512 bytes and marked "truncated". > - qmail does not support the very old TCP fallback requirement for DNS. If that's the case, see above. > MX edri.org | 237 byte > A edri.org | 213 byte These are fine. > ANY edri.org +dnssec | 1331 byte > MX edri.org +dnssec | 923 byte > A edri.org +dnssec | 731 byte These are also fine, since per RFC 3226 the resolver asking for DNSSEC must support at least 1220 octets payload. The interesting question here is whether there are other applications that issue ANY queries (most likely for the zone apex) and their resolvers _do_ fall back to TCP. -Peter From lutz at iks-jena.de Fri Feb 17 13:02:35 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 17 Feb 2006 12:02:35 +0000 (UTC) Subject: [dns-wg] DNSSEC breaks qmail References: Message-ID: * Roy Arends wrote: > I can think of non-dnssec responses that are larger than 512 octets, so > the subject of this message does not cover its content. Of course. The ANY request for "bofh." does exceed 512 bytes, too. In this case it's caused by the large number of NS records. DNSSEC "guarantees" exceeding this limit. > I am not sure what CNAME has to do with this. djb might notify this only the case of CNAMEs, because the additional section becomes be quite long. > I have seen patches for qmail that make it handle larger udp packet > sizes. You have to install them in order to send mail to DNSSEC domains. > Which service marks a DNS message 'truncated' in your example ? The questioned nameserver. Setting the TC bit is a requirement from RfC 1035. From lutz at iks-jena.de Fri Feb 17 13:07:53 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 17 Feb 2006 12:07:53 +0000 (UTC) Subject: [dns-wg] DNSSEC breaks qmail References: <20060217114819.GC1980@unknown.office.denic.de> Message-ID: * Peter Koch wrote: > The interesting question here is whether there are other applications that > issue ANY queries (most likely for the zone apex) and their resolvers > _do_ fall back to TCP. We notify a similar problem with sendmail. The interal resolver for DNS-mapping rules does not fall back to TCP. It does not cause any trouble here, because it supports EDNS and our zones are small enough. We notice the problem only, because some spammers resolve their temporary domains to an MX with 254 A records (a whole /24). From lutz at iks-jena.de Fri Feb 17 13:11:39 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 17 Feb 2006 12:11:39 +0000 (UTC) Subject: [dns-wg] DNSSEC breaks qmail References: <5DAFCBFE-E4E3-4699-A04B-775FD970A9DB@rfc1035.com> Message-ID: * Jim Reid wrote: > qmail won't be asking for DNSSEC RR types. That's for sure. And it > won't be setting the DO bit either because DJB is no fan of EDNS0. Qmail asks for "ANY" and this includes "NSEC" and "RRSIG", too. Qmail does not support EDNS and therefore get an truncated response as RfC 1035 requires. Qmail does not support the TCP fallback requirement and got struck. > So qmail's lookups should not be getting RRSIGs If qmail would ask for "MX" and "A", there would be no problem at all. But qmail ask for "ANY". > So your local name server shouldn't be handing out these RRtypes to > qmail's ANY QTYPE queries unless qmail set the D0 bit. "NSEC" and "RRSIG" are covered by "ANY". From lutz at iks-jena.de Fri Feb 17 13:24:29 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 17 Feb 2006 12:24:29 +0000 (UTC) Subject: [dns-wg] DNSSEC breaks qmail References: <5DAFCBFE-E4E3-4699-A04B-775FD970A9DB@rfc1035.com> Message-ID: * Lutz Donnerhacke wrote: > Qmail does not support EDNS and therefore get an truncated response > as RfC 1035 requires. It's even worse. qmail uses the libc resolver. If it's a bind resolver, qmail provides 512 bytes buffer, so bind can only fill in truncated data. If it's djbdns, the buffer will contain no data at all. Both resolvers provide approbiate return codes which qmail ignores. From jim at rfc1035.com Fri Feb 17 13:30:43 2006 From: jim at rfc1035.com (Jim Reid) Date: Fri, 17 Feb 2006 12:30:43 +0000 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: References: <5DAFCBFE-E4E3-4699-A04B-775FD970A9DB@rfc1035.com> Message-ID: <4BF73A31-E6C7-40E6-82DF-FB76222F7E6D@rfc1035.com> On Feb 17, 2006, at 12:11, Lutz Donnerhacke wrote: >> So your local name server shouldn't be handing out these RRtypes to >> qmail's ANY QTYPE queries unless qmail set the D0 bit. > > "NSEC" and "RRSIG" are covered by "ANY". Indeed they are. My apologies for forgetting that bit of RFC3225. From roy at nominet.org.uk Fri Feb 17 14:39:02 2006 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 17 Feb 2006 14:39:02 +0100 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: Message-ID: > * Roy Arends wrote: > > I can think of non-dnssec responses that are larger than 512 octets, so > > the subject of this message does not cover its content. > > Of course. The ANY request for "bofh." does exceed 512 bytes, too. In this > case it's caused by the large number of NS records. DNSSEC "guarantees" > exceeding this limit. Does it ? I can think of dnssec responses that are smaller than 512 octets. > > Which service marks a DNS message 'truncated' in your example ? > > The questioned nameserver. Setting the TC bit is a requirement from RfC 1035. The questioned nameserver has the luxury of constructing a response so that it _at_least_ satisfies the request. There is for instance no need for authority and additional section information to be send to the stub. I have no idea why an rfc4035 compliant resolver would send RRSIGs NSECs or DNSKEYs to a stub if the DO bit was not set. ANY only covers those if DO=1. I suspect that the questioned nameserver is broken. Roy From list-ripe-dns-wg at vicious.dropbear.id.au Fri Feb 17 14:48:36 2006 From: list-ripe-dns-wg at vicious.dropbear.id.au (Bruce Campbell) Date: Fri, 17 Feb 2006 14:48:36 +0100 (CET) Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: <20060217114819.GC1980@unknown.office.denic.de> References: <20060217114819.GC1980@unknown.office.denic.de> Message-ID: On Fri, 17 Feb 2006, Roy Arends wrote: >> Qmail can't deliver to DNSSEC protected domains. (Repost from > edri.org-ML) >> >> Reason: >> - qmail does not support the very old TCP fallback requirement for > DNS. >> - qmail refuses to deliver the mail >> and logs "CNAME_lookup_failed_temporarily." > > I can think of non-dnssec responses that are larger than 512 octets, so > the subject of this message does not cover its content. > I am not sure what CNAME has to do with this. The logic leading to that log message is 'I did not receive a valid A or MX record result, so I must have been looking up a CNAME and the remote DNS server failed to give a response'. Qmail should (according to qmail FAQ 2.5) retry the message later, however it will most probably get the same result as the remote zone will not have changed. On Fri, 17 Feb 2006, Peter Koch wrote: > Qmail has already had problems in the past with domain names where an ANY > response exceeds 512 octets. It happens with large NS RRsets, RFC1101 PTRs > or large TXT RR(Set)s which seem not so uncommon these days (although that's > a mistake). There was a patch at , > but i have no idea whether that can be applied today. No new releases of qmail by the author have been made since that patch was created; it should still apply. >> - qmail does not support EDNS extensions for larger UDP packets. > > That's probably not the application's problem, but the resolver's. Qmail runs its own resolver, which is where the problem arises. -- Bruce Campbell From pk at DENIC.DE Fri Feb 17 14:49:16 2006 From: pk at DENIC.DE (Peter Koch) Date: Fri, 17 Feb 2006 14:49:16 +0100 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: References: Message-ID: <20060217134916.GB2485@unknown.office.denic.de> On Fri, Feb 17, 2006 at 02:39:02PM +0100, Roy Arends wrote: > for authority and additional section information to be send to the stub. I > have no idea why an rfc4035 compliant resolver would send RRSIGs NSECs or > DNSKEYs to a stub if the DO bit was not set. ANY only covers those if > DO=1. [...] section 3 of RFC 4035 (top of page 9) says: A security-aware name server that receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and MUST NOT perform any of the additional processing described below. "treat ... as it would any other RRset" would support ANY covering those, which is consistent with RFC 3225. -Peter From roy at nominet.org.uk Fri Feb 17 15:09:05 2006 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 17 Feb 2006 15:09:05 +0100 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: <20060217134916.GB2485@unknown.office.denic.de> Message-ID: dns-wg-admin at ripe.net wrote on 17-02-2006 14:49:16: > On Fri, Feb 17, 2006 at 02:39:02PM +0100, Roy Arends wrote: > > > for authority and additional section information to be send to the stub. I > > have no idea why an rfc4035 compliant resolver would send RRSIGs NSECs or > > DNSKEYs to a stub if the DO bit was not set. ANY only covers those if > > DO=1. [...] > > section 3 of RFC 4035 (top of page 9) says: > > A security-aware name server that receives a DNS query that does not > include the EDNS OPT pseudo-RR or that has the DO bit clear MUST > treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and > MUST NOT perform any of the additional processing described below. > > "treat ... as it would any other RRset" would support ANY covering those, > which is consistent with RFC 3225. > > -Peter Maybe this helps: 3.2. Recursive Name Servers 3.2.1. The DO Bit The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the state of the DO bit in the initiating request received by the name server side. If the DO bit in an initiating query is not set, the name server side MUST strip any authenticating DNSSEC RRs from the response but MUST NOT strip any DNSSEC RR types that the initiating query explicitly requested. The important part is the last full sentence. Roy From Roy.Arends at nominet.org.uk Fri Feb 17 12:31:23 2006 From: Roy.Arends at nominet.org.uk (Roy.Arends at nominet.org.uk) Date: Fri, 17 Feb 2006 12:31:23 +0100 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: Message-ID: dns-wg-admin at ripe.net wrote on 17-02-2006 12:11:00: > 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." I can think of non-dnssec responses that are larger than 512 octets, so the subject of this message does not cover its content. I am not sure what CNAME has to do with this. I have seen patches for qmail that make it handle larger udp packet sizes. Which service marks a DNS message 'truncated' in your example ? Roy From hb at bsws.de Fri Feb 17 12:59:00 2006 From: hb at bsws.de (Henning Brauer) Date: Fri, 17 Feb 2006 12:59:00 +0100 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: <20060217114819.GC1980@unknown.office.denic.de> References: <20060217114819.GC1980@unknown.office.denic.de> Message-ID: <20060217115900.GV14506@nudo.bsws.de> * Peter Koch [2006-02-17 12:49]: > > - qmail does not support EDNS extensions for larger UDP packets. > That's probably not the application's problem, but the resolver's. no, since qmail reimplements the resolver parts (don't make me comment on that) > > * The response is truncated to 512 bytes and marked "truncated". > > - qmail does not support the very old TCP fallback requirement for DNS. > If that's the case, see above. see above - it IS qmail's fault. there's plenty of patches around to make it at leats re-query over TCP for those whi want to work around that bug. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services, http://bsws.de OpenBSD-based Webhosting, Mail Services, Managed Servers, ... From Roy.Arends at nominet.org.uk Fri Feb 17 14:31:52 2006 From: Roy.Arends at nominet.org.uk (Roy.Arends at nominet.org.uk) Date: Fri, 17 Feb 2006 14:31:52 +0100 Subject: [dns-wg] DNSSEC breaks qmail In-Reply-To: Message-ID: > * Roy Arends wrote: > > I can think of non-dnssec responses that are larger than 512 octets, so > > the subject of this message does not cover its content. > > Of course. The ANY request for "bofh." does exceed 512 bytes, too. In this > case it's caused by the large number of NS records. DNSSEC "guarantees" > exceeding this limit. Does it ? I can think of dnssec responses that are smaller than 512 octets. > > Which service marks a DNS message 'truncated' in your example ? > > The questioned nameserver. Setting the TC bit is a requirement from RfC 1035. The questioned nameserver has the luxury of constructing a response so that it _at_least_ satisfies the request. There is for instance no need for authority and additional section information to be send to the stub. I have no idea why an rfc4035 compliant resolver would send RRSIGs NSECs or DNSKEYs to a stub if the DO bit was not set. ANY only covers those if DO=1. I suspect that the questioned nameserver is broken. Roy From lutz at iks-jena.de Fri Feb 17 22:40:36 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 17 Feb 2006 21:40:36 +0000 (UTC) Subject: [dns-wg] DNSSEC breaks qmail References: <20060217115900.GV14506@nudo.bsws.de> Message-ID: * Henning Brauer wrote: > no, since qmail reimplements the resolver parts (don't make me comment > on that) Even worse. The native qmail does use the resolver vom the libc, but only provides a buffer of 512 bytes. After the request qmail ignores the API result code and parses the buffer. If qmail runs in a bind enviroment, it finds some usable records and continues. If qmail runs with djbdns, the resolver does not fills the buffer at all (correct, too). Qmail does not find any record in the response and concludes, that it must be a temporary cname problem. You refer to a version with an applied patch: Partial reimplemenation od tinydns into qmail. There seems to be another patch out there, which allows TCP for DNS. From bwatson at oarc.isc.org Sat Feb 18 21:03:14 2006 From: bwatson at oarc.isc.org (brett watson) Date: Sat, 18 Feb 2006 13:03:14 -0700 Subject: [dns-wg] new DNS Operations mailing list Message-ID: <8092745F-556F-4418-BFBE-222AD20FD751@oarc.isc.org> (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 From pk at DENIC.DE Mon Feb 20 13:28:21 2006 From: pk at DENIC.DE (Peter Koch) Date: Mon, 20 Feb 2006 13:28:21 +0100 Subject: [dns-wg] RIPE52 agenda item solicitation Message-ID: <20060220122821.GH648@unknown.office.denic.de> 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 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 From olaf at NLnetLabs.nl Tue Feb 21 13:18:50 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Tue, 21 Feb 2006 13:18:50 +0100 Subject: [dns-wg] DNS Misbehavior Doc In-Reply-To: <200602062114.aa30573@salmon.maths.tcd.ie> References: <200602062114.aa30573@salmon.maths.tcd.ie> Message-ID: <476B25E9-96D0-429A-94AF-91EAF39C39D9@NLnetLabs.nl> 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 227 bytes Desc: This is a digitally signed message part URL: From dwmalone at maths.tcd.ie Tue Feb 21 14:32:15 2006 From: dwmalone at maths.tcd.ie (David Malone) Date: Tue, 21 Feb 2006 13:32:15 +0000 Subject: [dns-wg] DNS Misbehavior Doc In-Reply-To: Your message of "Tue, 21 Feb 2006 13:18:50 +0100." <476B25E9-96D0-429A-94AF-91EAF39C39D9@NLnetLabs.nl> Message-ID: <200602211332.aa17706@salmon.maths.tcd.ie> > 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. From jim at rfc1035.com Tue Feb 21 15:15:07 2006 From: jim at rfc1035.com (Jim Reid) Date: Tue, 21 Feb 2006 14:15:07 +0000 Subject: [dns-wg] DNS Misbehavior Doc In-Reply-To: <200602211332.aa17706@salmon.maths.tcd.ie> References: <200602211332.aa17706@salmon.maths.tcd.ie> Message-ID: <37B3A1BE-B6D5-4498-9EB9-F9796436AEBC@rfc1035.com> 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. From pk at DENIC.DE Tue Feb 21 19:23:36 2006 From: pk at DENIC.DE (Peter Koch) Date: Tue, 21 Feb 2006 19:23:36 +0100 Subject: [dns-wg] DNS Misbehavior Doc In-Reply-To: <476B25E9-96D0-429A-94AF-91EAF39C39D9@NLnetLabs.nl> References: <200602062114.aa30573@salmon.maths.tcd.ie> <476B25E9-96D0-429A-94AF-91EAF39C39D9@NLnetLabs.nl> Message-ID: <20060221182336.GE1575@unknown.office.denic.de> 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 From pk at DENIC.DE Tue Feb 21 19:39:34 2006 From: pk at DENIC.DE (Peter Koch) Date: Tue, 21 Feb 2006 19:39:34 +0100 Subject: [dns-wg] DNS Misbehavior Doc In-Reply-To: <200602062114.aa30573@salmon.maths.tcd.ie> References: <200602062114.aa30573@salmon.maths.tcd.ie> Message-ID: <20060221183934.GF1575@unknown.office.denic.de> 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 From president at ukraine.su Fri Feb 24 14:57:27 2006 From: president at ukraine.su (Max Tulyev) Date: Fri, 24 Feb 2006 16:57:27 +0300 Subject: [dns-wg] DNSSEC: Signed zones list Message-ID: <200602241657.27394.president@ukraine.su> Hi! Where can I find the list of signed domains and their open keys to set up my DNS resolver? Which zones are signed now (exept RIPE's ones)? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From lutz at iks-jena.de Fri Feb 24 15:11:23 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 24 Feb 2006 14:11:23 +0000 (UTC) Subject: [dns-wg] DNSSEC: Signed zones list References: <200602241657.27394.president@ukraine.su> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- * Max Tulyev wrote: > Where can I find the list of signed domains and their open keys to set up my > DNS resolver? Which zones are signed now (exept RIPE's ones)? $ host -t axfr dnssec.iks-jena.de. iks-jena.de has DNSKEY record 257 3 5 AQPRteOmx973cbeIMigT7nciz3dcbt8ssZPGOK2vtPQlEaZO2fKgnm1F o6FPWcGqKv6O1ZpjEw2upKVDnzwMCRHpGe0Qh2TawStviww/jxUtjoZo m9Hy6uIkTvo7TxqnWg55LoHlcsl1kxsF1PsM2Z88F1XhXSrUtkiQnViX bfzR0joDE8xGJ9zRNuzr9Jik+bcv4S4KFOE/Ocn4F5vF7+eojz9m3/u0 gvQdvgFsb7OHr9cYA5GeG++cJWGG6xFF+yWEDdWuu2A7IJM3EQFWLr0k GDS6oWo/5Bz4PlrURjU5wahM1iwLnbKXhQQempzPYnSEs1CW+KH73WjM a76Dna9B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iQCiAwUBQ/8T6pFeTizbCJMJAQGjbQRmPXIbHz++I1m8/amFHRjGTbpMzkob21ej SVBJC3ZB7MNDyt4f4ehF1LjCSbczl0ceThfw/o8CNDFXiWgZqNYFGZAOobuGZy/Q UlKW9f/g4+RZsrbxi9nQmEspRyxoSFh/6wq8SAWU29Y2itSIBmsW2h9cmFyyTA0y 2PgrbozRoLGQc7UlkE7bOcjjzbht =5mra -----END PGP SIGNATURE----- From olaf at NLnetLabs.nl Fri Feb 24 15:30:33 2006 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Fri, 24 Feb 2006 15:30:33 +0100 Subject: [dns-wg] DNSSEC: Signed zones list In-Reply-To: <200602241657.27394.president@ukraine.su> References: <200602241657.27394.president@ukraine.su> Message-ID: On Feb 24, 2006, at 2:57 PM, Max Tulyev wrote: > Hi! > > Where can I find the list of signed domains and their open keys to > set up my > DNS resolver? Which zones are signed now (exept RIPE's ones)? Hello Max, There are not many of such lists. In fact I know of only one: http://www-x.antd.nist.gov/dnssec/ --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 227 bytes Desc: This is a digitally signed message part URL: From pawal at blipp.com Fri Feb 24 15:46:36 2006 From: pawal at blipp.com (Patrik Wallstrom) Date: Fri, 24 Feb 2006 15:46:36 +0100 Subject: [dns-wg] DNSSEC: Signed zones list In-Reply-To: <200602241657.27394.president@ukraine.su> References: <200602241657.27394.president@ukraine.su> Message-ID: <20060224144636.GB14840@vic20.blipp.com> On Fri, 24 Feb 2006, Max Tulyev wrote: > Hi! > > Where can I find the list of signed domains and their open keys to set up my > DNS resolver? Which zones are signed now (exept RIPE's ones)? .SE is signed as well, http://dnssec.nic.se/key.html -- patrik_wallstrom->foodfight->pawal at blipp.com->+46-733173956 From president at ukraine.su Sun Feb 26 10:13:21 2006 From: president at ukraine.su (Max Tulyev) Date: Sun, 26 Feb 2006 12:13:21 +0300 Subject: [dns-wg] DNSSEC: Signed zones list In-Reply-To: References: <200602241657.27394.president@ukraine.su> Message-ID: <200602261213.21137.president@ukraine.su> Hello Olaf! Thank you! So as I can understand, to fully inplement DNSSEC on my named's I have to get ALL keys for ALL signed zones and premanently trace all of them if it is not expired, isn't it? > On Feb 24, 2006, at 2:57 PM, Max Tulyev wrote: > > Hi! > > > > Where can I find the list of signed domains and their open keys to > > set up my > > DNS resolver? Which zones are signed now (exept RIPE's ones)? > > Hello Max, > > There are not many of such lists. In fact I know of only one: > http://www-x.antd.nist.gov/dnssec/ > > > --Olaf > > > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Sun Feb 26 18:59:27 2006 From: president at ukraine.su (Max Tulyev) Date: Sun, 26 Feb 2006 20:59:27 +0300 Subject: [dns-wg] DNSSEC: Signed zones list In-Reply-To: References: <200602241657.27394.president@ukraine.su> Message-ID: <200602262059.27944.president@ukraine.su> Hello Olaf! > http://www-x.antd.nist.gov/dnssec/ In fact, I can't find exactly the list. And there is nothing working here... DNSSEC Guide: not avaliable yet. All files to download: (example) The requested resource (/dnssec/download/anon_zones.tar.gz) is not available. and so on... -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jaap at NLnetLabs.nl Mon Feb 27 11:11:32 2006 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Mon, 27 Feb 2006 11:11:32 +0100 Subject: [dns-wg] Name servers problems Message-ID: <200602271011.k1RABW1x090209@bartok.nlnetlabs.nl> 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. From lutz at iks-jena.de Mon Feb 27 11:13:28 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 27 Feb 2006 10:13:28 +0000 (UTC) Subject: [dns-wg] DNSSEC: Signed zones list References: <200602261213.21137.president@ukraine.su> Message-ID: * Max Tulyev wrote: > So as I can understand, to fully inplement DNSSEC on my named's I have to > get ALL keys for ALL signed zones and premanently trace all of them if it > is not expired, isn't it? Your are mostly right. You do not need (and should not care about) the key of chained zones, i.e. zone, that have a DS record in the signed parent zone. In those cases you only need the key of the topmost signed zone. In order to keep the maintaining effort as small as possible, several TLD offer a seperate DNS-server which hosts signed subzones. Such servers are available for *.fr, *.net and *.com. The *.se zone is signed using the standard DNS servers. Another trick to delegate the maintaining work is to use a lookaside zone. There are two zones out there: dlv.verisignlab.com and dnssec.iks-jena.de. A lookaside zone is used by your DNS server to determine a "DS" record for an unknown zone. Consequently the lookaside zone does not contain records for chained zones. It's up to you. Good luck. From jorgen at hovland.cx Mon Feb 27 11:39:32 2006 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 27 Feb 2006 11:39:32 +0100 Subject: [dns-wg] Name servers problems References: <200602271011.k1RABW1x090209@bartok.nlnetlabs.nl> Message-ID: <009e01c63b8a$18071200$4a27b3d5@tungemaskin> ----- Original Message ----- From: "Jaap Akkerhuis" > 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. > > It might be worth mentioning that DNS is not the only service being abused for this kind of attack. Strictly speaking, any service replying to spoofed packets with more data than what they received are affected. That includes the tcp protocol and also authorative namservers (tip: dig -t a b.n @a.nic.fr) that respond to queries. But recursive nameservers are obviously an easier target.. for now. j (which finds it interesting that people are discussing this issue now and not in around year 2000 which was, at least for me, the first time I noticed this problem.) From president at ukraine.su Mon Feb 27 12:30:21 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 27 Feb 2006 14:30:21 +0300 Subject: [dns-wg] DNSSEC: Signed zones list In-Reply-To: References: <200602261213.21137.president@ukraine.su> Message-ID: <200602271430.21740.president@ukraine.su> > Another trick to delegate the maintaining work is to use a lookaside zone. > There are two zones out there: dlv.verisignlab.com and dnssec.iks-jena.de. > A lookaside zone is used by your DNS server to determine a "DS" record for > an unknown zone. Consequently the lookaside zone does not contain records > for chained zones. It's like black magic :( localhost bind # ping dlv.verisignlab.com ping: unknown host dlv.verisignlab.com localhost bind # ping dnssec.iks-jena.de ping: unknown host dnssec.iks-jena.de -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jeroen at unfix.org Mon Feb 27 13:07:36 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 27 Feb 2006 13:07:36 +0100 Subject: [dns-wg] DNSSEC: Signed zones list In-Reply-To: <200602271430.21740.president@ukraine.su> References: <200602261213.21137.president@ukraine.su> <200602271430.21740.president@ukraine.su> Message-ID: <1141042056.6905.2.camel@firenze.zurich.ibm.com> On Mon, 2006-02-27 at 14:30 +0300, Max Tulyev wrote: > > Another trick to delegate the maintaining work is to use a lookaside zone. > > There are two zones out there: dlv.verisignlab.com and dnssec.iks-jena.de. > > A lookaside zone is used by your DNS server to determine a "DS" record for > > an unknown zone. Consequently the lookaside zone does not contain records > > for chained zones. > > It's like black magic :( > > localhost bind # ping dlv.verisignlab.com > ping: unknown host dlv.verisignlab.com try adding an 's'. The above is a very nice example of a domainsquatter (also something where neither dnssec or tls can't help as anyone can register any domain) $ dig -t any dlv.verisignlabs.com ;; Truncated, retrying in TCP mode. [..] dlv.verisignlabs.com. 86400 IN NS ns1.dlv.verisignlabs.com. dlv.verisignlabs.com. 3600 IN DNSKEY 256 3 5 AQOlH7LDa3Sy/rK +WyqydkS94p1hWWhEyTdZhxwuz/1zPGqh8pc8lXNj tOqcVXNSQX1XCSJPhW8XylXlq8gLlyRiVUs+TBoKrGYs7VARuLqZZDW4 Utu +VuDsTCjxjtAgxH15KfJbmnpMP3ffQvDHzyj8F2Dw6aaLHAwot3eI YWOy7w== [..] > localhost bind # ping dnssec.iks-jena.de > ping: unknown host dnssec.iks-jena.de Doesn't have an A record, but does have a large number of others. Use the 'dig'. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From president at ukraine.su Mon Feb 27 18:51:57 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 27 Feb 2006 20:51:57 +0300 Subject: [dns-wg] DNSSEC: Signed zones list In-Reply-To: References: <200602261213.21137.president@ukraine.su> Message-ID: <200602272051.57984.president@ukraine.su> > In order to keep the maintaining effort as small as possible, several TLD > offer a seperate DNS-server which hosts signed subzones. Such servers are > available for *.fr, *.net and *.com. The *.se zone is signed using the > standard DNS servers. So where I can get the keys? ;) I googled, but found nothing :( > Another trick to delegate the maintaining work is to use a lookaside zone. > There are two zones out there: dlv.verisignlab.com and dnssec.iks-jena.de. > A lookaside zone is used by your DNS server to determine a "DS" record for > an unknown zone. Consequently the lookaside zone does not contain records > for chained zones. Understood, nice idea, thank you! -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From Ed.Lewis at neustar.biz Tue Feb 28 07:46:01 2006 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 28 Feb 2006 14:46:01 +0800 Subject: [dns-wg] Name servers problems In-Reply-To: <200602271011.k1RABW1x090209@bartok.nlnetlabs.nl> References: <200602271011.k1RABW1x090209@bartok.nlnetlabs.nl> Message-ID: At 11:11 +0100 2/27/06, Jaap Akkerhuis wrote: >For those not on NANOG, on that list is quite some discussion going >on about using (recursive) name servers for amplicication attacks. ... > >Maybe all this is worth a slot at the coming dns-wg (or eof) meeting? Yes, it is worth some time. Some folks remain unconvinced that open recursive servers are a problem. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... From lutz at iks-jena.de Tue Feb 28 09:11:25 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 28 Feb 2006 08:11:25 +0000 (UTC) Subject: [dns-wg] DNSSEC: Signed zones list References: <200602272051.57984.president@ukraine.su> Message-ID: * Max Tulyev wrote: >> In order to keep the maintaining effort as small as possible, several TLD >> offer a seperate DNS-server which hosts signed subzones. Such servers are >> available for *.fr, *.net and *.com. The *.se zone is signed using the >> standard DNS servers. > > So where I can get the keys? ;) I googled, but found nothing :( Start at the obvious point: http://www.dnssec.net/projects Strange enough, neither dnssec.net nor dnssec-deployment.org are signed. From s.steffann at computel.nl Mon Feb 27 13:11:34 2006 From: s.steffann at computel.nl (Sander Steffann) Date: Mon, 27 Feb 2006 13:11:34 +0100 Subject: [dns-wg] DNSSEC: Signed zones list In-Reply-To: <200602271430.21740.president@ukraine.su> Message-ID: <2B1A983EDCEC3447B22632B64F72646014E8BA@bill.office.computel.nl> Hi, > It's like black magic :( > > localhost bind # ping dlv.verisignlab.com > ping: unknown host dlv.verisignlab.com I can't find any DNS records for that zone either. > localhost bind # ping dnssec.iks-jena.de > ping: unknown host dnssec.iks-jena.de But: you are looking only for A and/or AAAA records here. Those are not relevant for what you want to do with DNSSEC. Try "dig dnssec.iks-jena.de any" You will get something like: ; <<>> DiG 9.2.4 <<>> dnssec.iks-jena.de any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10861 ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;dnssec.iks-jena.de. IN ANY ;; ANSWER SECTION: dnssec.iks-jena.de. 57512 IN TYPE48 \# 134 0100030501039E1F9DA1882F5054559A92916DACF8483B4F1A8B53D0 6C55FFD75C2DE4A008FB2C08D0B19BC89FA279DB7FFEA8ABF44C21AA 295DFCE9D8CD7829B544C216CF6530E2D43AE0EF5E9D80B2CB87669F 3455DC9C14952788CDF9AA6BD38805E99B0B8729E9F5E47D38E5874A 644499E68AAB0113EB59B1C10C5AD4693A25BC554841 dnssec.iks-jena.de. 57512 IN TYPE48 \# 262 010103050103B8161FFE486EC0A2F6DE05AA20FF6F6FE29C96E58889 34BEC1AB2840BEA12A8655222EB1A2A72E54B3EC1B5C9D1CE0637CBE 549CCB4015078CFEE2F0BFCFFB396652783CF737F07D5B5E21CF0691 717CE6A85421DA4B044924E7843DC3BC75F6AFA1E39CBDB5A95B3B9A 62ADC5D5DC514F9226FA2D58E62586C1D3D54F523106F0DEF2CB9EEB 14730DC5E28483CCBEE3A4AD07AA3B88F692F1FF1A48D0AB8DB14ACC 65FF427D8B6BC5AA559E43DEA3AD77259EB176C283B649ACA5EC677F 0646F4792BDD35B042589A5E30F05FEA2FD0D39A45E20A7589B226B6 F723447EE10CADE2A80CC94D86EBAD0F99D98206E42ED4F6C5937EBB 572C4635F40449982131 dnssec.iks-jena.de. 3512 IN TYPE47 \# 63 01320132013001320134013601330133013601360139013404653136 34046172706106646E7373656308696B732D6A656E61026465000007 22000000000380 dnssec.iks-jena.de. 3512 IN TYPE46 \# 294 003005030000E10045E84FA843D8F7A8A22D06646E7373656308696B 732D6A656E6102646500835A26CD1BD23C709CC56529F92E2F54193F 2A3EA60D4C85B3DD62A556BFD26B16C9068F60140004E5B1EFD41395 A63447DAAEE0CF52931E944E63B429F52788CE485467B78FE8AC7E27 8CFAE4F17C6F2F913FFA4A186CDAE70293D4BFAA8A292E9BA14163FA 409D4A1C594297981CDFB15E999EF94DFDE55DB22A200E87B1D6B3E8 F3FD83842CEF289F467FEC46F3E180AE36F4D2722BABBEE23E7578CD 11E3FDDF22528CDC830FDBF38D5B7CD45364B75C72ACFF76EB3FB887 8725853B5EA14809BA5E8CF9A30F805AC91D346FBD6679E615ABB417 7AE8256A6D0FC07E0E33BF2A88C84CA950C64B1A0BB6152DFC0D714B 95C07DE7262B73715CEF2BC3D3A7 dnssec.iks-jena.de. 3512 IN TYPE46 \# 166 000205030000E100441F2B7143F79E71037A06646E7373656308696B 732D6A656E610264650032EFE01FFBAE07CAC4B0E7F6E6E243705DF4 FC5BA0280090B06D3A92C3AA6D29FA2FEC3496E013CD61FA86FE6A11 B6020646C848023BEFD748E89B7D30E80C141B15800E922B7F0ADF0C 6FE4D6B8C027CF003293719F291FDC9616C4FD0CE229BC56D4BB2300 7CA3E8C9301051E91D51D1EDBC3D6CAD593516EBAE290E187335 dnssec.iks-jena.de. 3512 IN TYPE46 \# 166 000605030000E1004429BED7440231D7037A06646E7373656308696B 732D6A656E61026465009154AE475E2A83424BB38FDA4A5DF05D8177 7FBF7A2DFE165962E1A10335E3037262AE5963D6B4F3D4601552DAFF 47BA8979FB4958F62107CBBCDF46691C7C8F82E6BEA2046B22FE359E C417299C695D2A2837B040713BFBD6524F4E6841C3574375F7A0866E 1CEAFB4C27BF8968F87959D520EB9DD787611931495894744655 dnssec.iks-jena.de. 3512 IN TYPE46 \# 166 002F050300000E1044254CBC43FDBFBC037A06646E7373656308696B 732D6A656E61026465006015226113998270879DA328B98726891973 88D5347D6D29EB0B0CC51306BBDC2FD39F7385B17170AC6CA9B282C3 5E5380642CFD73CEDAE836B96F77322D878080D30F8F0E81C7C298B8 587118734C568778A3FA964A5ACDD6CC6EB920644A16E815A8FF7FE9 5F6635FB19E45EE5E6597DAAAD5A46B2C604335213A46B19E96C dnssec.iks-jena.de. 3512 IN TYPE46 \# 166 003005030000E100441F2B7143F79E71037A06646E7373656308696B 732D6A656E610264650058453B4AF3C6CC1CBA508C688C31DF5F759E BBA587A64A09F0F6B3A0232A72E737EFCB554C77DAA9532EBA3F43F6 F92AC3D8F23393E79AC3E90B806718B6B2F52C71DD5F2EB5BF67E618 8B89D1FAA7842D7762834F9AA507E140A173BA2E631FA8B496F76F5E 5B89606CCF735345B3CD282E83351C3F7E95A74ED71277345EAB dnssec.iks-jena.de. 57512 IN SOA avalon.iks-jena.de. hostmaster.iks-jena.de. 2006022702 10800 3600 3600000 3600 dnssec.iks-jena.de. 57512 IN NS avalon.iks-jena.de. ;; AUTHORITY SECTION: dnssec.iks-jena.de. 57512 IN NS avalon.iks-jena.de. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Feb 27 13:09:35 2006 ;; MSG SIZE rcvd: 1631 - Sander From president at ukraine.su Tue Feb 28 10:41:36 2006 From: president at ukraine.su (Max Tulyev) Date: Tue, 28 Feb 2006 12:41:36 +0300 Subject: [dns-wg] DNSSEC: Signed zones list In-Reply-To: <2B1A983EDCEC3447B22632B64F72646014E8BA@bill.office.computel.nl> References: <2B1A983EDCEC3447B22632B64F72646014E8BA@bill.office.computel.nl> Message-ID: <200602281241.36236.president@ukraine.su> Hi! So what exactly I should do with this? > But: you are looking only for A and/or AAAA records here. Those are not > relevant for what you want to do with DNSSEC. Try "dig dnssec.iks-jena.de > any" -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From lutz at iks-jena.de Tue Feb 28 13:27:16 2006 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 28 Feb 2006 12:27:16 +0000 (UTC) Subject: [dns-wg] DNSSEC: Signed zones list References: <200602281241.36236.president@ukraine.su> Message-ID: * Max Tulyev wrote: > So what exactly I should do with this? In your named.conf: options { ... dnssec-enable yes; dnssec-lookaside "." trust-anchor "dnssec.iks-jena.de"; }; trusted-keys { "iks-jena.de." 257 3 5 "AQPRteOmx973cbeIMigT7nciz3dcbt8ssZPGOK2vtPQl EaZO2fKgnm1Fo6FPWcGqKv6O1ZpjEw2upKVDnzwMCRHp Ge0Qh2TawStviww/jxUtjoZom9Hy6uIkTvo7TxqnWg55 LoHlcsl1kxsF1PsM2Z88F1XhXSrUtkiQnViXbfzR0joD E8xGJ9zRNuzr9Jik+bcv4S4KFOE/Ocn4F5vF7+eojz9m 3/u0gvQdvgFsb7OHr9cYA5GeG++cJWGG6xFF+yWEDdWu u2A7IJM3EQFWLr0kGDS6oWo/5Bz4PlrURjU5wahM1iwL nbKXhQQempzPYnSEs1CW+KH73WjMa76Dna9B"; }; What happens now? Image you query the A record for coruscant.dyn.niconet.se. coruscant.dyn.niconet.se. 38 IN A 213.114.39.13 coruscant.dyn.niconet.se. 38 IN RRSIG A 5 4 60 20070120160745 ( 20060119150745 651 dyn.niconet.se. F5vLlZAn5k/Mtaw6PSzkxTaTtHS8myV95eEOugY5lepf PJIiFbV5HiHZSDpoNXjAhzWzHY96+R0Wd7Qu2UUr3gDn Z/YXoHzLqC3lzRS9HSVx9HzzPixjt0/8ChhEK0QMUuhh lN8Xq90ayiUdtkK6jDM5CG27VjMbtr/de4475TSmBOut m+Jd/B+E8s+OzHTNXphAM0LgGjhS1IZcpMoQyfPbosbD K6VqD79nJdjzPZlmE2f0cFesELkJEHC1bcRA32W3BwI6 k+UB1T+yqf4TJj25BoTwfWVP/AEe4BHe1at44K6LDA2f bQc9ibWFGup/O8S8IkcNi76AiA2XVibcjA== ) coruscant.dyn.niconet.se. 38 IN RRSIG A 5 4 60 20070120160745 ( 20060119150745 65120 dyn.niconet.se. T+4KN4Ol3e6cPLy7ue4wSd9VwnCWYLxvOSljCtWnQxKp oCvrNjkkAV0j1AHHqI5nMK63mbyb+tUudq/3jFX5WhCl hCaSWFNH+LIB5982VixgodqCUKJrUTfB2bB33ZD320PO msa1H3bJ532Vf2BudACn40bNdjc87mW4sGwv9g7FzEJ0 yuEkem+fm0AAP2qKBXRkiTSJwo6I3LiwIWODJenAP8XZ odhk+PWipFQSNhnPRd3tYIKUYHIOOUMaEFECTdtyTsaM K8fIgE1AD6b6XjiQx9eDolIvDmSELc/K12L4qCWJbh84 burp6AXMm5TpzTCJMbXuc/xPZJIW7D2T/g== ) As you can see, it's signed! Let's check the signatures. First we need the key. From the RRSIG entries both keys resides in the the zone dyn.niconet.se. and has the key id 651 and 65120. So let's retrieve those DNSKEYs. dyn.niconet.se. 300 IN DNSKEY 256 3 5 ( AQOfq5czkMFmGPBCa8lXbM+yyNPfBQvn9Uomj3to07kz NegN4gqPdfXy2lIhYJ9JF1wQ7bvG2J3fo1Ysu9E2AIn3 hdesGyiAEGXO1PJqMYmts/1tXtE2HQ8LNa+omo90Ph2O 5cJN5YKDXdYJ1fZzfJrpza6VHmSeXrVQMsQYx8nO69ns rCtmMhopXp9I+Vvv9e7eG8/c4ji60AgigNGYro7GbUQQ 4YicoRL7USZiXEVWstzXXk+XQ+5IOny6+Q7rij7fdipM CZ41vvJ2N0ETMfzZuYR3AcaWVauOxITVnobVZaFfZ5Us 5Id2FSyW8A1AvDPLMJNZWM23VBhNmmESCnrn ) ; key id = 65120 dyn.niconet.se. 300 IN DNSKEY 257 3 5 ( AQPCeNlj/rDZis8yPN8GI2WXJpnoIF1iIiS4xCc8gAJM 77pmuVEalUqhGhjykMA0uSrWrQu0nBl0FvFCp0vL4T+4 ZLT7Ug7KOTJauiiEuxj7IGNhHh7az6Q0KXf8Y8i1pvvA PPWENZJqUgK1YMTJ6t/GTTGld4elhwz5a3vu2aAc2GpZ MAqa9idTC8o8x1A8w9e3B7fr2cMwiMnyk3Mk+2SLZAxU dk45S8gBuV0UEEUoU5viSkNOgxeaAprO7ORR/AJB/20V EiJ9FAsfnjTcqR57GS5NMeh/cIVm46xBwjEdighCTimn yBXmtwdj52hW843DK//9hO6gdEVn1Z84ezud ) ; key id = 651 dyn.niconet.se. 300 IN RRSIG DNSKEY 5 3 300 20061118080551 ( 20051118080551 651 dyn.niconet.se. cNbr1mwi0tCzPSGBdzQfWs7OjvgDIoKJNupf6Arnm4zX 5EpYDJO8v4XzM4QIrPTGHHEBBmjHYaCeRxbzh0sBf3MD ZnD3feNMAXdTFRY+J3fLsZFtfpH8duBNmU3YM13y7B9j ZT8mhLTkSPKTeecdNcSZpTy8UzRo/wYNpHnFzGafenwf HUNls0qE+m9eR4+l5m006NBuLymgmVnVBcvMXRmcI0gZ 0wSNeIGtC3WOggE0Aknf47JWH09nt9PogdJ+0Eh2sg7p Uf+wxfjLzbEiNjo3z+TdulUp6X774WnY+O0gaIMmxZmV POybUM49UJsCgVXPGs1vn2MosPXa/8Mj2A== ) dyn.niconet.se. 300 IN RRSIG DNSKEY 5 3 300 20061118080551 ( 20051118080551 65120 dyn.niconet.se. PXQs5HGRmC3N3NSQVxxKEMy7IyJKqkzBmGnfQB7CDOEq 9BYzxlrU5o4yWktSgaDVy0yDhJYFPW0DU0WHV29TUmCm aqV5oMvuj328vSb4MGPIQFR58J2R8aRgj3FyeBcOQYfR 6UfFyN4o/ZHy8PvcUOFWrPlnereTkfrArIq97o5NrojE RndF8v3h0kcdECJ/BgAvCFF4x4TnSHoIooMokfS86vmS hUuI5W7afCI9qjkrB+RWtCpuKaeUqstdM188BTxqNAqP acGhYICgpo2hmRfdhwAYmdlFjAaDD13hHn26pu/JLa0O 2bBUPEy4JKjKievm9MZz2eg9z5ClEtuSxA== ) There are two DNSKEYs and both are signed by each other. We can now check the signature but are still unable to verify the trustworthy of the used keys. So let's ask for chaining information from parent. dyn.niconet.se. 300 IN DS 651 5 1 ( 5AA71DA50AD09FA2857E4E695F4979056683F2BF ) dyn.niconet.se. 300 IN RRSIG DS 5 3 300 20070204110034 ( 20060204110034 32669 niconet.se. W0Dv73cO2I2DLMaDeUr0ROw1VuQ0/3ejrbH1PUDEVYzq nAy93TQY8hlOoz3vPEDXupsOq/H+bvi/94G4ovCHGfD8 FlkNJwKE6KTu+8QcLJ+8K/08FVJbz30zcCZliA74 ) This is a signed fingerprint for key 651. The signing key has id 32669 in zone niconet.se. Let's skip the dnskey query for niconet.se and ask the parent directly. niconet.se. 86094 IN DS 48132 5 1 ( 14C1848A3B17143389613853CF06EEA76BEBD43F ) niconet.se. 86094 IN RRSIG DS 5 2 86400 20060305195120 ( 20060227200552 17585 se. RoDfJvvofrW5JJVYaZFEzFD3AUcAiPeNNgxBeVDJkiVG J72SSIrDXI6wEwEiBE2JDiuyR6moduTB96O8CUlXflT8 8Llzdn1xAVM8p19lSwyJfxMIwDyXxeyi3XuSoRLdAhSV gDqAUn1CIFfZkOI9TvnLqmurvAhryQDabQ2SgCo= ) The signing key is 17585 in zone se. There is no signed fingerprint for the zone se on the root servers. So we have a secure entry point for with we have to check the trustworthyness. There are two possibilities: a) Find a different way to obtain the key directly from the se-maintainers. Install this key as "trusted-keys". b) Use a lookaside zone by querying for DLV from se.dnssec.iks-jena.de. se.dnssec.iks-jena.de. 57600 IN DLV 17686 5 1 ( 9E5E81A0B71A9B6B251077F700AA730E18D712EF ) se.dnssec.iks-jena.de. 57600 IN RRSIG DLV 5 4 57600 20060324223850 ( 20060222223850 890 dnssec.iks-jena.de. JShT4Nd3TS+nVLEWhm9pwpIiBncDXj3USKrwo8jLCfhD nHhyYEntZcg4UkSKLanhPVW83cVRGAnT/bYuT2qXct1B +k8DNPbaff0CNX0coSAim6CzJlf0ICOVM3GZELT2NtNw 9pd0lZ+289eUIhsvW8xEZ1oZLB0e6clde28BKqI= ) This is a signed fingerprint (same format as DS) for the key 17686 from se. It is signed by key 890 from dnssec.iks-jena.de. In turn this key is signed by 41517 from dnssec.iks-jena.de. which has a fingerprint signed by 52706 from iks-jena.de. In turn this key is signed by 30258 from iks-jena.de. And finally this very last key is marked as trustworthy by your local configuration. Have fun!