From training at ripe.net Mon Feb 12 18:11:15 2007 From: training at ripe.net (RIPE NCC Training Services) Date: Mon, 12 Feb 2007 18:11:15 +0100 Subject: [dns-wg] Announcement DNS for LIRs Training Courses Message-ID: <20070212171115.5DDB52F583@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: Friday 30 March 2007 Time: 09:00-17:00 Location: Lisbon, Portugal And Date: Friday 20 April 2007 Time: 09:00-17:00 Location: Frankfurt, Germany Hosted by: DE.CIX: http://www.decix.de/ And Date: Friday 27 April 2007 Time: 09:00-17:00 Location: Budapest, Hungary And Date: Friday 18 May 2007 Time: 09:00-17:00 Location: Amsterdam, Netherlands And Date: Friday 8 June 2007 Time: 09:00-17:00 Location: London, United Kingdom And Date: Thursday 21 June 2007 Time: 09:00-17:00 Location: Tehran, Iran 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 From Anne-Marie.Eklund-Lowinder at iis.se Mon Feb 12 16:45:58 2007 From: Anne-Marie.Eklund-Lowinder at iis.se (=?iso-8859-1?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Mon, 12 Feb 2007 16:45:58 +0100 Subject: [dns-wg] Swedish ISP TCD Song Adopts DNSSEC Message-ID: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ** Swedish ISP TDC Song Adopts DNSSEC Swedish Internet Service Provider TDC Song announced in a press release on Friday that it will run DNSSEC on its name servers and thus be able to offer safer broadband services to its customers. TDC Song will be using .SE-DNSSEC, a service offered by .SE (The Internet Infrastructure Foundation) responsible for the Swedish top-level domain .se. For the full press release (in Swedish), see: http://wpy.observer.se/wpyfs/00/00/00/00/00/09/35/D0/release.html ** Anne-Marie Eklund L?winder Quality & Security Manager .SE (The Internet Infrastructure Foundation) P O Box 7399 103 91 Stockholm Sweden Tel: +46 8 452 35 00, direct: +46 8 452 35 17, mobile: +46 734 315 310 E-mail: anne-marie.eklund-lowinder at iis.se Web: www.iis.se -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRdCLtaXc8AFCsc+UEQIB8QCg4aRoRyiK+TzRgYOSCb8eBMSyUCsAn2v9 8PdylTKBWZcOnYC2sUed8jLy =ABy6 -----END PGP SIGNATURE----- From lutz at iks-jena.de Tue Feb 13 15:45:58 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 13 Feb 2007 14:45:58 +0000 (UTC) Subject: [dns-wg] Swedish ISP TCD Song Adopts DNSSEC References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> Message-ID: * Anne-Marie Eklund-L?winder wrote: > Swedish Internet Service Provider TDC Song announced in a press > release on Friday that it will run DNSSEC on its name servers and > thus be able to offer safer broadband services to its customers. What is so great about this message? From paf at cisco.com Tue Feb 13 16:18:37 2007 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 13 Feb 2007 16:18:37 +0100 Subject: [dns-wg] Swedish ISP TCD Song Adopts DNSSEC In-Reply-To: References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> Message-ID: <533CF084-D43B-4B68-8CFE-38AD472E199C@cisco.com> On 13 feb 2007, at 15.45, Lutz Donnerhacke wrote: > * Anne-Marie Eklund-L?winder wrote: >> Swedish Internet Service Provider TDC Song announced in a press >> release on Friday that it will run DNSSEC on its name servers and >> thus be able to offer safer broadband services to its customers. > > What is so great about this message? That a large ISP turn on verification of DNSSEC signatures in their resolvers with the key of a TLD as anchor. That has not happened before as far as I know. If I am wrong, I would like to know. Patrik From jim at rfc1035.com Tue Feb 13 16:55:56 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 13 Feb 2007 15:55:56 +0000 Subject: [dns-wg] Swedish ISP TCD Song Adopts DNSSEC In-Reply-To: References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> Message-ID: On Feb 13, 2007, at 14:45, Lutz Donnerhacke wrote: > * Anne-Marie Eklund-L?winder wrote: >> Swedish Internet Service Provider TDC Song announced in a press >> release on Friday that it will run DNSSEC on its name servers and >> thus be able to offer safer broadband services to its customers. > > What is so great about this message? Surely the decision to deploy DNSSEC in anger by any ISP is something this WG would heartily celebrate. Even if TDC Song has just switched on DNSSEC validation for the signed bits of .se, it's a start. DNSSEC deployment has to start somewhere. By that I mean deployment in the context of validation outside the usual "research" environments and for stuff beyond zone signing. From lutz at iks-jena.de Tue Feb 13 17:05:43 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 13 Feb 2007 17:05:43 +0100 Subject: [dns-wg] Re: Swedish ISP TCD Song Adopts DNSSEC In-Reply-To: <533CF084-D43B-4B68-8CFE-38AD472E199C@cisco.com> References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <533CF084-D43B-4B68-8CFE-38AD472E199C@cisco.com> Message-ID: <20070213160543.GA9689@belenus.iks-jena.de> On Tue, Feb 13, 2007 at 04:18:37PM +0100, Patrik F?ltstr?m wrote: > On 13 feb 2007, at 15.45, Lutz Donnerhacke wrote: > >What is so great about this message? > > That a large ISP turn on verification of DNSSEC signatures in their > resolvers with the key of a TLD as anchor. That has not happened > before as far as I know. If I am wrong, I would like to know. I thought Cable and Wireless did this in December 2005. From president at ukraine.su Tue Feb 13 18:00:51 2007 From: president at ukraine.su (Max Tulyev) Date: Tue, 13 Feb 2007 19:00:51 +0200 Subject: [dns-wg] Re: Swedish ISP TCD Song Adopts DNSSEC In-Reply-To: <20070213160543.GA9689@belenus.iks-jena.de> References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <533CF084-D43B-4B68-8CFE-38AD472E199C@cisco.com> <20070213160543.GA9689@belenus.iks-jena.de> Message-ID: <45D1EEC3.7030902@ukraine.su> We (NetAssist, Kiev, Ukraine) did it a year ago (RIPE backresolve, .se, .ru, .net, .com as well as ISC's DLV checking). In general, I don't believe in practical usage of this implementation, because of you can do a DNS attack on the client's resolver directly. But I see significant decrease of spam after DNSSEC implementation. I believe it can happens because of wise spammers can't cheat backresolve and blacklists checks anymore. Lutz Donnerhacke wrote: > On Tue, Feb 13, 2007 at 04:18:37PM +0100, Patrik F?ltstr?m wrote: >> On 13 feb 2007, at 15.45, Lutz Donnerhacke wrote: >>> What is so great about this message? >> That a large ISP turn on verification of DNSSEC signatures in their >> resolvers with the key of a TLD as anchor. That has not happened >> before as far as I know. If I am wrong, I would like to know. > > I thought Cable and Wireless did this in December 2005. > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From randy at psg.com Tue Feb 13 18:04:45 2007 From: randy at psg.com (Randy Bush) Date: Tue, 13 Feb 2007 07:04:45 -1000 Subject: [dns-wg] Swedish ISP TCD Song Adopts DNSSEC References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> Message-ID: <17873.61357.786210.307904@roam.psg.com> > DNSSEC deployment has to start somewhere. the root or it will not scale and there will be significant breakage of END USERS' access randy From jim at rfc1035.com Tue Feb 13 18:27:12 2007 From: jim at rfc1035.com (Jim Reid) Date: Tue, 13 Feb 2007 17:27:12 +0000 Subject: [dns-wg] Swedish ISP TCD Song Adopts DNSSEC In-Reply-To: <17873.61357.786210.307904@roam.psg.com> References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <17873.61357.786210.307904@roam.psg.com> Message-ID: On Feb 13, 2007, at 17:04, Randy Bush wrote: >> DNSSEC deployment has to start somewhere. > > the root or it will not scale True. But what should the DNS engineers do while the layer-9 issues about the root key rumble on and on? I very much doubt anyone's going to take responsibility for signing the root unless they know that, yes DNSSEC really does work and won't break the internet. The only way of establishing that IMO is "real world" experience outside the research environment where DNSSEC deployment has been done to date. From randy at psg.com Tue Feb 13 18:58:21 2007 From: randy at psg.com (Randy Bush) Date: Tue, 13 Feb 2007 07:58:21 -1000 Subject: [dns-wg] Swedish ISP TCD Song Adopts DNSSEC In-Reply-To: References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <17873.61357.786210.307904@roam.psg.com> Message-ID: <45D1FC3D.3050309@psg.com> >>> DNSSEC deployment has to start somewhere. >> the root or it will not scale > True. But what should the DNS engineers do while the layer-9 issues > about the root key rumble on and on? dunno 'bout everyone else, but i have too much work to do already. > I very much doubt anyone's going to take responsibility for signing > the root unless they know that, yes DNSSEC really does work and won't > break the internet. bs. that is not the problem at the root. it's all layer nine. randy From dougb at dougbarton.us Tue Feb 13 19:48:31 2007 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 13 Feb 2007 10:48:31 -0800 Subject: [dns-wg] Re: Swedish ISP TCD Song Adopts DNSSEC In-Reply-To: <45D1EEC3.7030902@ukraine.su> References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <533CF084-D43B-4B68-8CFE-38AD472E199C@cisco.com> <20070213160543.GA9689@belenus.iks-jena.de> <45D1EEC3.7030902@ukraine.su> Message-ID: <45D207FF.5070308@dougbarton.us> Max Tulyev wrote: > We (NetAssist, Kiev, Ukraine) did it a year ago (RIPE backresolve, .se, > .ru, .net, .com as well as ISC's DLV checking). I think this is a great move. Have you had any feedback from your users? > In general, I don't believe in practical usage of this implementation, > because of you can do a DNS attack on the client's resolver directly. > > But I see significant decrease of spam after DNSSEC implementation. I > believe it can happens because of wise spammers can't cheat backresolve > and blacklists checks anymore. How is the information about whether the RRsets are signed and/or validated, or not, getting back to the clients? IOW, if I'm a piece of anti-spam software, how do I know that the answer I received is signed and validated? I ask because IMO this is actually the more difficult part of DNSSEC deployment. We have the stuff to sign the zones, but figuring out how to use the signature data (or lack thereof) is a whole new kettle of fish. Doug -- If you're never wrong, you're not trying hard enough From lutz at iks-jena.de Wed Feb 14 10:33:12 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 14 Feb 2007 09:33:12 +0000 (UTC) Subject: [dns-wg] Swedish ISP TCD Song Adopts DNSSEC References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <17873.61357.786210.307904@roam.psg.com> Message-ID: * Randy Bush wrote: >> DNSSEC deployment has to start somewhere. > > the root or it will not scale and there will be significant > breakage of END USERS' access DLV does exist and works. From jim at rfc1035.com Wed Feb 14 11:55:05 2007 From: jim at rfc1035.com (Jim Reid) Date: Wed, 14 Feb 2007 10:55:05 +0000 Subject: [dns-wg] getting DNSSEC deployed In-Reply-To: <45D1FC3D.3050309@psg.com> References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <17873.61357.786210.307904@roam.psg.com> <45D1FC3D.3050309@psg.com> Message-ID: On Feb 13, 2007, at 17:58, Randy Bush wrote: >> I very much doubt anyone's going to take responsibility for signing >> the root unless they know that, yes DNSSEC really does work and won't >> break the internet. > > bs. that is not the problem at the root. it's all layer nine. Nobody said this was an issue at the root Randy. And whether that's a layer-9 issue or not is irrelevant too: this genuine problem -- you'd presumably call it a non-problem -- has to be resolved somehow. Getting real-world experience of what happens when DNSSEC is switched on is part of that process. So the recent moves in Sweden are to be commended as a step towards getting that experience. I'm disappointed if you don't share that view. From randy at psg.com Wed Feb 14 18:08:51 2007 From: randy at psg.com (Randy Bush) Date: Wed, 14 Feb 2007 07:08:51 -1000 Subject: [dns-wg] getting DNSSEC deployed References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <17873.61357.786210.307904@roam.psg.com> <45D1FC3D.3050309@psg.com> Message-ID: <17875.16931.132332.880242@roam.psg.com> >>> I very much doubt anyone's going to take responsibility for >>> signing the root unless they know that, yes DNSSEC really does >>> work and won't break the internet. >> bs. that is not the problem at the root. it's all layer nine. > Nobody said this was an issue at the root Randy. false. i did. if the root is not signed, dnssec is an unstabele and unscalable mess, with disasters for the end users waiting to happen. > And whether that's a layer-9 issue or not is irrelevant too not when you seem to be trying to fix it at layers 3-7. > this genuine problem -- you'd presumably call it a non-problem -- > has to be resolved somehow. i consider it a major problem. and the only solution is getting iana to sign the root zone. whether we like it or not, that is the way dnssec was designed. > Getting real-world experience of what happens when DNSSEC is > switched on is part of that process. So the recent moves in > Sweden are to be commended as a step towards getting that > experience. I'm disappointed if you don't share that view. you should be used to me dissapointing you. after all, i am the guy publicly blamed for delaying dnssec for years. isolated deployments of dnssec will have interesting results. i eagerly await the results from sweden rolling their key in an emergency. and no, lutz, dlv has an unspecified trust model. and the answers to the trust model promised in san jose nanog many moons ago have yet to be given. randy From lutz at iks-jena.de Wed Feb 14 18:37:56 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 14 Feb 2007 17:37:56 +0000 (UTC) Subject: [dns-wg] getting DNSSEC deployed References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <17873.61357.786210.307904@roam.psg.com> <45D1FC3D.3050309@psg.com> <17875.16931.132332.880242@roam.psg.com> Message-ID: * Randy Bush wrote: > and no, lutz, dlv has an unspecified trust model. and the answers > to the trust model promised in san jose nanog many moons ago have > yet to be given. I do trust my DLV data. I offer it to others. From Niall.oReilly at ucd.ie Wed Feb 14 18:25:37 2007 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 14 Feb 2007 17:25:37 +0000 Subject: [dns-wg] getting DNSSEC deployed In-Reply-To: <17875.16931.132332.880242@roam.psg.com> References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <17873.61357.786210.307904@roam.psg.com> <45D1FC3D.3050309@psg.com> <17875.16931.132332.880242@roam.psg.com> Message-ID: On 14 Feb 2007, at 17:08, Randy Bush wrote: > you should be used to me dissapointing you. after all, i am the > guy publicly blamed for delaying dnssec for years. Six months at a time ... ? 8-) /Niall From david.conrad at icann.org Wed Feb 14 19:48:13 2007 From: david.conrad at icann.org (David Conrad) Date: Wed, 14 Feb 2007 10:48:13 -0800 Subject: [dns-wg] getting DNSSEC deployed In-Reply-To: References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <17873.61357.786210.307904@roam.psg.com> <45D1FC3D.3050309@psg.com> <17875.16931.132332.880242@roam.psg.com> Message-ID: On Feb 14, 2007, at 9:37 AM, Lutz Donnerhacke wrote: > * Randy Bush wrote: >> and no, lutz, dlv has an unspecified trust model. and the answers >> to the trust model promised in san jose nanog many moons ago have >> yet to be given. > I do trust my DLV data. I offer it to others. And how do I trust the DLV registry you use? Rgds, -drc From lutz at iks-jena.de Wed Feb 14 21:11:44 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 14 Feb 2007 20:11:44 +0000 (UTC) Subject: [dns-wg] getting DNSSEC deployed References: Message-ID: * David Conrad wrote: > On Feb 14, 2007, at 9:37 AM, Lutz Donnerhacke wrote: >> I do trust my DLV data. I offer it to others. > > And how do I trust the DLV registry you use? You can't without knowing me. From david.conrad at icann.org Wed Feb 14 22:31:06 2007 From: david.conrad at icann.org (David Conrad) Date: Wed, 14 Feb 2007 13:31:06 -0800 Subject: [dns-wg] getting DNSSEC deployed In-Reply-To: References: Message-ID: <6D3433CF-6A47-4035-BF7D-9DB8F9027AC4@icann.org> On Feb 14, 2007, at 12:11 PM, Lutz Donnerhacke wrote: >> And how do I trust the DLV registry you use? > You can't without knowing me. I think this points to part of the "unscalable mess" Randy was talking about. Rgds, -drc From olaf at NLnetLabs.nl Wed Feb 14 22:38:14 2007 From: olaf at NLnetLabs.nl (Olaf M. Kolkman) Date: Wed, 14 Feb 2007 22:38:14 +0100 Subject: [dns-wg] getting DNSSEC deployed In-Reply-To: References: Message-ID: <5E6ACCB7-4DAF-483E-9874-E669F97DD985@NLnetLabs.nl> On 14Feb 2007, at 9:11 PM, Lutz Donnerhacke wrote: > * David Conrad wrote: >> On Feb 14, 2007, at 9:37 AM, Lutz Donnerhacke wrote: >>> I do trust my DLV data. I offer it to others. >> >> And how do I trust the DLV registry you use? > > You can't without knowing me. So, there you go.. remember what Randy just said: > if the root is not signed, dnssec is an unstabele > and unscalable mess, I am not a firm believer in DLV but I think it will allow the early deployers to familiarize themselves with the DNSSEC operational space. But, life for the masses, as opposed to early deployers, will only be good once: - The root is signed - Automated trust anchor rollover works (work on that finished in DNSEXT and is now at IESG level) - A fair amount of TLDs is signed Until then we will have to live with kludges like DLV. Now I appreciate Lutz' offer but I think that the more DLV registries will pop up the more confusion and troubleshooting hell will be created simply because users of different DLVs will have a different view on the namespace. Note however that now, for folk who configure their nameservers to use a DLV registry things will not be radically different operationally than in the case of a signed root; they configure one trust anchor, and off they fly. So as long as the root is not signed I hope that people will converge to using[*] one DLV registry and I also hope that the layer 9 stuff surrounding a signed root is being dealt in an appropriate time window. (Neill just suggested one :-) ) . --Olaf [*] where using in this case means: take a leap of faith and put your trust in a particular DLV registry. PS I appreciate the announcement about a validating recursive nameserver being turned on in some big IESP but I hope that will not become a trend ;-) ----------------------------------------------------------- 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 randy at psg.com Wed Feb 14 23:04:31 2007 From: randy at psg.com (Randy Bush) Date: Wed, 14 Feb 2007 12:04:31 -1000 Subject: [dns-wg] getting DNSSEC deployed References: <5E6ACCB7-4DAF-483E-9874-E669F97DD985@NLnetLabs.nl> Message-ID: <17875.34671.192569.666463@roam.psg.com> > So as long as the root is not signed I hope that people will converge > to using[*] one DLV registry and I also hope that the layer 9 stuff > surrounding a signed root is being dealt in an appropriate time > window. (Neill just suggested one :-) ) . show me a dlv with published trust policies as was asked for last (northern) summer. until then, hell no. randy From roy at nominet.org.uk Wed Feb 14 23:08:34 2007 From: roy at nominet.org.uk (Roy Arends) Date: Wed, 14 Feb 2007 23:08:34 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed Message-ID: Kudo's to TDC Song, C&W and others. Real nice they're validating data. So what about joe end user. Are there initiatives to offer tsig/sig0/dtls between user and isp ? Are there initiatives to deploy code at the OS level, similar as to what the NLNetLabs and Sparta folk are building for the application level ? Are formentioned providers deploying either of these two sets of solutions to their end users ? Or is it all just security theater ? Bring dns validation to where dns requests are initiated and where it is consumed; at the end user. That part is still vulnerable to spoofing while we're trying to secure the invisible infrastructure. Note that with end user validation, and well established methods to update the end users' certificate store, we might be well on our way. See also: http://dnss.ec/blog/?p=10 Sure, signing the root is crucial, and I'm not convinced dlv is a viable alternative, but thats all meaningless if layer 6/7 don't get some fondling. Roy From brettcarr at ripe.net Thu Feb 15 13:49:12 2007 From: brettcarr at ripe.net (Brett Carr) Date: Thu, 15 Feb 2007 13:49:12 +0100 Subject: [dns-wg] Maintenance on ns-pri.ripe.net Message-ID: [Apologies for duplicates] Dear Colleagues, On 21 February 2007, authoritative Reverse DNS Services on ns-pri.ripe.net will be unavailable between 18:00 and 21:00 UTC. During this time we need to carry out maintenance work. We apologise in advance for any inconvenience. If you have any questions or concerns about this, send an e-mail to Regards -- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam From lutz at iks-jena.de Fri Feb 16 09:24:33 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 08:24:33 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: Message-ID: * Roy Arends wrote: > Note that with end user validation, and well established methods to update > the end users' certificate store, we might be well on our way. > > See also: http://dnss.ec/blog/?p=10 IBTD. You can run a caching validating on your own system. If you do not want this, you have to use a stub resolver. A stub resolver means, that you have a established link to an authenitcated resolver. This resolver has to do the DNSSEC validation. If your application want's to validate DNSSEC itself, ther exists a request format to get the responses unvalidated. Following this proposal in the blog, DNSSEC is dead. From roy at nominet.org.uk Fri Feb 16 09:52:35 2007 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 16 Feb 2007 09:52:35 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: Message-ID: Lutz Donnerhacke wrote on 02/16/2007 09:24:33 AM: > * Roy Arends wrote: > > Note that with end user validation, and well established methods to update > > the end users' certificate store, we might be well on our way. > > > > See also: http://dnss.ec/blog/?p=10 > > IBTD. Please don't beg. > You can run a caching validating on your own system. Isn't that what I was saying ? I just don't want to do all the recursion. My ISP's resolver can do that. > If you do not > want this, you have to use a stub resolver. A stub resolver means, that you > have a established link to an authenitcated resolver. This resolver has to > do the DNSSEC validation. not really. I can also validate on a stub resolver. > If your application want's to validate DNSSEC itself, ther exists a request > format to get the responses unvalidated. Yeah, I think I've read that in some internet draft somewhere. > Following this proposal in the blog, DNSSEC is dead. Tell me Lutz, how does joe end user run a full featured validating resolver daemon, when he barely understand the concept of DNS. If he shouldn't run this, how does he setup "a established link to an authenticated resolver". You're not really referring to just an bunch of addresses in some resolv.conf or equivalent, since thats hardly an established link. The ISP's resolver hardly knows who's talking to it. Now, lets assume for a sec we don't run into scaling issues, since the "authenticated resolver" needs to do some crypto for the "established link", while doing some crypto to validate messages. Why should I trust data, validated by my ISP ? Them ISPs route me to a search page, while I should've received an NXDOMAIN. but, no fear, the 'ad' bit is set, and I can just blindly trust my ISP, while they're cashing (no typo) in on my unfortunate misspellings. Roy From lutz at iks-jena.de Fri Feb 16 10:20:09 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 09:20:09 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: Message-ID: * Roy Arends wrote: > Lutz Donnerhacke wrote on 02/16/2007 09:24:33 AM: >> You can run a caching validating on your own system. > > Isn't that what I was saying ? I just don't want to do all the recursion. > My ISP's resolver can do that. So use it for this. > not really. I can also validate on a stub resolver. I wouldn't call this "stub". A stub resolver is a protocol translator: It offers an well known API to well known protocol. It does nothing more of the protocol itself. >> Following this proposal in the blog, DNSSEC is dead. > > Tell me Lutz, how does joe end user run a full featured validating > resolver daemon, when he barely understand the concept of DNS. The end user has a stub resolver pointing to a trustwothy validating one. It's this plain simple. If you want to break this behavior, DNSSEC is dead. > If he shouldn't run this, how does he setup "a established link to an > authenticated resolver". You're not really referring to just an bunch of > addresses in some resolv.conf or equivalent, since thats hardly an > established link. The ISP's resolver hardly knows who's talking to it. I'm responsible for DNS at an ISP: The ISP's resolver know who queries it. > Now, lets assume for a sec we don't run into scaling issues, since the > "authenticated resolver" needs to do some crypto for the "established > link", while doing some crypto to validate messages. DNSSEC validating on a larger resolver does scale well, because - that's the important observation I made - a lot of queries can be answered from cached NSEC records without querying further. The whole bunch of NXDOMAIN dropped by about 70% here. Crypto is cheap compared to networking. > Why should I trust data, validated by my ISP? Because you choose him to do so. > Them ISPs route me to a search page, while I should've received an > NXDOMAIN. but, no fear, the 'ad' bit is set, and I can just blindly trust > my ISP, while they're cashing (no typo) in on my unfortunate > misspellings. If you do not trust your ISP, you need an other one or you won validating protocols i.e. VPN to a trustwothy point. DNSSEC for end users is not a security issue, it's a deployment issue. From jim at rfc1035.com Fri Feb 16 10:59:20 2007 From: jim at rfc1035.com (Jim Reid) Date: Fri, 16 Feb 2007 09:59:20 +0000 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: Message-ID: On Feb 16, 2007, at 09:20, Lutz Donnerhacke wrote: > DNSSEC validating on a larger resolver does scale well, because - > that's the > important observation I made - a lot of queries can be answered > from cached > NSEC records without querying further. The whole bunch of NXDOMAIN > dropped by > about 70% here. It would be good to get some real numbers here. And to find out what happens to the already-crypto-validated-and-cached RRSIGs when their TTLs and "best before" dates change. Dropping the NXDOMAINs by 70% seems very strange. If the same number of queries are being made as before, what answers are they getting back instead of NXDOMAIN? Aha! It must be SERVFAIL because DNSSEC validation failed. :-) > Crypto is cheap compared to networking. Please explain how you arrive at this conclusion. Crypto is never cheap, especially the cost of the human factors in things like key management. Example: adding a host to some network is much less work than configuring SSH on that host and distributing its host key(s). I would like to know how running a cryptosystem is cheaper than moving bits around, all other things being equal. From pk at DENIC.DE Fri Feb 16 11:07:29 2007 From: pk at DENIC.DE (Peter Koch) Date: Fri, 16 Feb 2007 11:07:29 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: Message-ID: <20070216100729.GB22720@denics7.denic.de> On Fri, Feb 16, 2007 at 09:20:09AM +0000, Lutz Donnerhacke wrote: > DNSSEC validating on a larger resolver does scale well, because - that's the > important observation I made - a lot of queries can be answered from cached > NSEC records without querying further. The whole bunch of NXDOMAIN dropped by > about 70% here. Crypto is cheap compared to networking. Are you suggesting that a) since most of the queries are repeated ones leading to NXDOMAIN you can take advantage of the response being cached and not in need of re-validation, or b) you have and use an implementation, that -- in violation of the DNSSEC specification -- applies "aggressive negative caching"? In case of (a) I'd not understand the drop rate, for (b) I'd like to read a name. -Peter From roy at nominet.org.uk Fri Feb 16 11:13:15 2007 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 16 Feb 2007 11:13:15 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: Message-ID: Lutz Donnerhacke wrote on 02/16/2007 10:20:09 AM: > * Roy Arends wrote: > > Lutz Donnerhacke wrote on 02/16/2007 09:24:33 AM: > >> You can run a caching validating on your own system. > > > > Isn't that what I was saying ? I just don't want to do all the recursion. > > My ISP's resolver can do that. > > So use it for this. I just explained why I don't want to do that. > > not really. I can also validate on a stub resolver. > > I wouldn't call this "stub". A stub resolver is a protocol translator: It > offers an well known API to well known protocol. It does nothing more of the > protocol itself. I'd call this a "security aware stub resolver" (rfc 4033, section 2). > >> Following this proposal in the blog, DNSSEC is dead. > > > > Tell me Lutz, how does joe end user run a full featured validating > > resolver daemon, when he barely understand the concept of DNS. > > The end user has a stub resolver pointing to a trustwothy validating one. > It's this plain simple. If you want to break this behavior, DNSSEC is dead. explain to me how DNSSEC is dead by doing validation on a stub resolver. > > If he shouldn't run this, how does he setup "a established link to an > > authenticated resolver". You're not really referring to just an bunch of > > addresses in some resolv.conf or equivalent, since thats hardly an > > established link. The ISP's resolver hardly knows who's talking to it. > > I'm responsible for DNS at an ISP: The ISP's resolver know who queries it. So, what do you offer to your clients? SIG(0), TSIG, DTLS, some VPN method ? How many clients have configured that ? And with 'who queries it', you probably mean that you have some list in place somewhere that discriminates on ip. Note that I can simply passive query your resolver box. You wouldn't even know it is me. > > Now, lets assume for a sec we don't run into scaling issues, since the > > "authenticated resolver" needs to do some crypto for the "established > > link", while doing some crypto to validate messages. > > DNSSEC validating on a larger resolver does scale well, because - that's the > important observation I made - a lot of queries can be answered from cached > NSEC records without querying further. The whole bunch of NXDOMAIN dropped by > about 70% here. Crypto is cheap compared to networking. I find those last two statements highly unlikely, but for argument sake, multiply this by cost(crypto(lastmile))*count(users). > > Why should I trust data, validated by my ISP? > > Because you choose him to do so. Eh ? No, I rely on it to bring me the data. I'll validate it myself, thank you very much. > > Them ISPs route me to a search page, while I should've received an > > NXDOMAIN. but, no fear, the 'ad' bit is set, and I can just blindly trust > > my ISP, while they're cashing (no typo) in on my unfortunate > > misspellings. > > If you do not trust your ISP, you need an other one or you won validating > protocols i.e. VPN to a trustwothy point. "trust" is not a binary concept. You need to relate trust to a service, and then still, it comes in degrees. I trust my bank to process payments. I trust my ISP to keep my link alive and to have proper peering in place. I _could_ trust my ISP to serve me the right data, but that would only be the right data in their perspective, wouldn't it, and that might not match mine. > DNSSEC for end users is not a security issue, it's a deployment issue. Eh ? DNSSEC is security backfitted on a widely deployed protocol. This has deployment issues in general. Roy From lutz at iks-jena.de Fri Feb 16 11:20:58 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 10:20:58 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: Message-ID: * Jim Reid wrote: > It would be good to get some real numbers here. Yep. > Dropping the NXDOMAINs by 70% seems very strange. If the same number of > queries are being made as before, what answers are they getting back > instead of NXDOMAIN? *g* The good answers are usually cached on customer side. Only the bad queries are resend after a short negative caching period. The validating resolver does not itself requery those questions but respond (from a cached and valid NSEC) NXDOMAIN. >> Crypto is cheap compared to networking. > > Please explain how you arrive at this conclusion. RRSIG validation does occur on every freshly received record. Then the result of the validation is cached. OTOH resolving a query recursively requires at least one packet exchange with a remote system. This takes time. I compare timing and conclude that time_validating = time_queryDNSSEC + time_validation + n*time_lookup and time_recursing = n*time_query must not be in a strict order for every n. Speaking for the locally hosted signed zones (~500) I observe a big win. The win will be much better if the root where signed (because the resolver knows which TLD does not exists from cache), so that stetting up a signed root for outself is a probable project in the near future. From lutz at iks-jena.de Fri Feb 16 11:29:41 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 10:29:41 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: <20070216100729.GB22720@denics7.denic.de> Message-ID: * Peter Koch wrote: > b) you have and use an implementation, that -- in violation of the DNSSEC > specification -- applies "aggressive negative caching"? Of course, it's a slightly modified bind. What's wrong with using the NSEC data for negative caching? Example: Q: avalon.iks-jena.de. AAAA [query the authoritive] A: avalon NSEC awstats.iks-jena.de. A MX TXT LOC SSHFP RRSIG NSEC Q: avalon.iks-jena.de. HINFO A: avalon NSEC awstats.iks-jena.de. A MX TXT LOC SSHFP RRSIG NSEC Q: avatar.iks-jena.de. A A: avalon NSEC awstats.iks-jena.de. A MX TXT LOC SSHFP RRSIG NSEC I do _not_ extent the lifetime of the NSEC over the TTL based on the RRSIG end date. From lutz at iks-jena.de Fri Feb 16 11:40:14 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 10:40:14 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: Message-ID: * Roy Arends wrote: > explain to me how DNSSEC is dead by doing validation on a stub resolver. You can't update the installed base quick enought to gain the benefits of DNSSEC. If the recursing resolvers do not validate, the whole DNSSEC effect is going to zero. You will find about 100000 validating resolvers at end user sites and nobody will sign a zone for this group of geeks. >> I'm responsible for DNS at an ISP: The ISP's resolver know who queries >> it. > > So, what do you offer to your clients? SIG(0), TSIG, DTLS, some VPN method? Internet Access over our own infrastructure. If you are coming from extern, you have to use TSIG. > How many clients have configured that? The larger customers. It's about 20000 end users. We do not sell internet access to private users. > And with 'who queries it', you probably mean that you have some list in > place somewhere that discriminates on ip. Note that I can simply passive > query your resolver box. You wouldn't even know it is me. I can't see your point here. > I find those last two statements highly unlikely, but for argument sake, > multiply this by cost(crypto(lastmile))*count(users). I do not see the need for crypto on the last mile. >> > Why should I trust data, validated by my ISP? >> >> Because you choose him to do so. > > Eh? No, I rely on it to bring me the data. I'll validate it myself, thank > you very much. You are a geek. But you spoke about end users. And they trust their ISP for the data they received from him. You are still free to do the validation yourself. >> If you do not trust your ISP, you need an other one or you won >> validating protocols i.e. VPN to a trustwothy point. > > "trust" is not a binary concept. You need to relate trust to a service, > and then still, it comes in degrees. IBTD, but this is a useless discussion. > I trust my ISP to keep my link alive and to have proper peering in place. > I _could_ trust my ISP to serve me the right data, but that would only be > the right data in their perspective, wouldn't it, and that might not match > mine. For the joe end user, there is no difference. >> DNSSEC for end users is not a security issue, it's a deployment issue. > > Eh? Exactly. Turn on validation on the recursing servers and you are done. > DNSSEC is security backfitted on a widely deployed protocol. This has > deployment issues in general. Pushing deployment (incl. key management) to the end users is the wrong way. From bortzmeyer at nic.fr Fri Feb 16 12:05:29 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 16 Feb 2007 12:05:29 +0100 Subject: [dns-wg] Re: What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: <20070216100729.GB22720@denics7.denic.de> Message-ID: <20070216110529.GA1576@nic.fr> On Fri, Feb 16, 2007 at 10:29:41AM +0000, Lutz Donnerhacke wrote a message of 20 lines which said: > Of course, it's a slightly modified bind. What's wrong with using > the NSEC data for negative caching? RFC 4035, "4.5. Response Caching" In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace. From roy at nominet.org.uk Fri Feb 16 12:24:26 2007 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 16 Feb 2007 12:24:26 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: Message-ID: Lutz Donnerhacke wrote on 02/16/2007 11:40:14 AM: > * Roy Arends wrote: > > explain to me how DNSSEC is dead by doing validation on a stub resolver. > > You can't update the installed base quick enought to gain the benefits of > DNSSEC. If the recursing resolvers do not validate, the whole DNSSEC effect > is going to zero. You will find about 100000 validating resolvers at end > user sites and nobody will sign a zone for this group of geeks. Ah, you're assuming that folk will en-masse sign their zones for the handfull of validating resolvers ? Meanwhile, my OS/X and windows boxes are configured (by default) to update itself regularly. Some of my applications do that as well. My browsers have validation intergrated. Joe end user would not even see the difference.... but he's better off than before. I don't really expect any demand from end-users in general. I have difficulty believing that there will be any effort from big ISP's to do this. It takes a few support calls to have validation switched off at the ISPs site, or the ISP will already see their very thin margin evaporate (sure sure, you're the exception). That leaves us with pushing code to the end user, in applications and OS, which implies coorperation from and education to software developers. Since you don't sell access to private end users, I assume you sell bulk access, which implies that corps/folks you send access to, have their own resolvers in place. They loose. > > And with 'who queries it', you probably mean that you have some list in > > place somewhere that discriminates on ip. Note that I can simply passive > > query your resolver box. You wouldn't even know it is me. > > I can't see your point here. acl's, firewalls, etc, that decide on source ip address if it can query your resolver. I can circumvent that. > > I find those last two statements highly unlikely, but for argument sake, > > multiply this by cost(crypto(lastmile))*count(users). > > I do not see the need for crypto on the last mile. That is okay. > >> > Why should I trust data, validated by my ISP? > >> > >> Because you choose him to do so. > > > > Eh? No, I rely on it to bring me the data. I'll validate it myself, thank > > you very much. > > You are a geek. But you spoke about end users. And they trust their ISP for > the data they received from him. I'd advice joe end user to validate locally. Just as I'd advice them validate certificates (which browsers do automagically). Are you saying that end users should blindly trust their http connection, just because it come via their ISP, or the ISP's proxy? > You are still free to do the validation yourself. Good. I was concerned for a second. I see no point in discussing this further. You may call me a geek, thats fine, I see it as 'early adaptor'. Roy From demch at chello.nl Fri Feb 16 12:07:45 2007 From: demch at chello.nl (Yuri Demchenko) Date: Fri, 16 Feb 2007 12:07:45 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: Message-ID: <45D59081.8030201@chello.nl> I think this will not be too much off-topic. What does DNSSEC and Techsec-WG people think about recently revealed pharming attack technique that is based on the end user DNS altering? NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS Millions of high-speed Internet users across the globe are threatened by a new attack technique called drive-by pharming, Symantec and Indiana University researchers warned Thursday. http://go.techtarget.com/r/1004039/1401570 On the practical note, I need to say something definite to my students what DNS experts think? Thanks. Yuri Roy Arends wrote: > Lutz Donnerhacke wrote on 02/16/2007 10:20:09 AM: > >> * Roy Arends wrote: >>> Lutz Donnerhacke wrote on 02/16/2007 09:24:33 AM: >>>> You can run a caching validating on your own system. >>> Isn't that what I was saying ? I just don't want to do all the > recursion. >>> My ISP's resolver can do that. >> So use it for this. > > I just explained why I don't want to do that. > >>> not really. I can also validate on a stub resolver. >> I wouldn't call this "stub". A stub resolver is a protocol translator: > It >> offers an well known API to well known protocol. It does nothing more of > the >> protocol itself. > > I'd call this a "security aware stub resolver" (rfc 4033, section 2). > >>>> Following this proposal in the blog, DNSSEC is dead. >>> Tell me Lutz, how does joe end user run a full featured validating >>> resolver daemon, when he barely understand the concept of DNS. >> The end user has a stub resolver pointing to a trustwothy validating > one. >> It's this plain simple. If you want to break this behavior, DNSSEC is > dead. > > explain to me how DNSSEC is dead by doing validation on a stub resolver. > >>> If he shouldn't run this, how does he setup "a established link to an >>> authenticated resolver". You're not really referring to just an bunch > of >>> addresses in some resolv.conf or equivalent, since thats hardly an >>> established link. The ISP's resolver hardly knows who's talking to it. >> I'm responsible for DNS at an ISP: The ISP's resolver know who queries > it. > > So, what do you offer to your clients? SIG(0), TSIG, DTLS, some VPN method > ? How many clients have configured that ? > And with 'who queries it', you probably mean that you have some list in > place somewhere that discriminates on ip. Note that I can simply passive > query your resolver box. You wouldn't even know it is me. > >>> Now, lets assume for a sec we don't run into scaling issues, since the >>> "authenticated resolver" needs to do some crypto for the "established >>> link", while doing some crypto to validate messages. >> DNSSEC validating on a larger resolver does scale well, because - that's > the >> important observation I made - a lot of queries can be answered from > cached >> NSEC records without querying further. The whole bunch of NXDOMAIN > dropped by >> about 70% here. Crypto is cheap compared to networking. > > I find those last two statements highly unlikely, but for argument sake, > multiply this by cost(crypto(lastmile))*count(users). > >>> Why should I trust data, validated by my ISP? >> Because you choose him to do so. > > Eh ? No, I rely on it to bring me the data. I'll validate it myself, thank > you very much. > >>> Them ISPs route me to a search page, while I should've received an >>> NXDOMAIN. but, no fear, the 'ad' bit is set, and I can just blindly > trust >>> my ISP, while they're cashing (no typo) in on my unfortunate >>> misspellings. >> If you do not trust your ISP, you need an other one or you won > validating >> protocols i.e. VPN to a trustwothy point. > > "trust" is not a binary concept. You need to relate trust to a service, > and then still, it comes in degrees. I trust my bank to process payments. > I trust my ISP to keep my link alive and to have proper peering in place. > I _could_ trust my ISP to serve me the right data, but that would only be > the right data in their perspective, wouldn't it, and that might not match > mine. > >> DNSSEC for end users is not a security issue, it's a deployment issue. > > Eh ? > > DNSSEC is security backfitted on a widely deployed protocol. This has > deployment issues in general. > > Roy > > From lutz at iks-jena.de Fri Feb 16 13:13:40 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 12:13:40 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: Message-ID: * Roy Arends wrote: > Lutz Donnerhacke wrote on 02/16/2007 11:40:14 AM: >> You can't update the installed base quick enought to gain the benefits >> of DNSSEC. If the recursing resolvers do not validate, the whole DNSSEC >> effect is going to zero. You will find about 100000 validating >> resolvers at end user sites and nobody will sign a zone for this group >> of geeks. > > Ah, you're assuming that folk will en-masse sign their zones for the > handfull of validating resolvers ? Yes. See the reactions to the last announcement of a Swedish ISP. > Meanwhile, my OS/X and windows boxes are configured (by default) to update > itself regularly. Some of my applications do that as well. My browsers > have validation intergrated. Joe end user would not even see the > difference.... but he's better off than before. He will see a difference, if some spoofing attacks does not longer work. > I don't really expect any demand from end-users in general. I see a strong demand from commercial banking institutes (not really). Let's assume some major DSL-ISPs does switch on validating. This results in a trusted DNS for about 60% of there customers (may be more). Now consider the phishing buzzword. No, it does not help against clicking on every link and attachment in Outlook. > I have difficulty believing that there will be any effort from big ISP's > to do this. It takes a few support calls to have validation switched off > at the ISPs site, or the ISP will already see their very thin margin > evaporate. Most DSL markets are death due to dumping. If you really want to keep customers, you have to provide more features. Security is a very valuable feature this days. Adding DNSSEC validating causes a major step-up at least in press release shootouts. > That leaves us with pushing code to the end user, in applications and OS, > which implies coorperation from and education to software developers. Taking this road means: Redo from start. Never get a reasonable deployment. Root will not be signed, because there are not enough installations. More installations will not come up, because the root is not signed and key maintainence is a mess. Catch-22. I prefer the other way. > Since you don't sell access to private end users, I assume you sell bulk > access, which implies that corps/folks you send access to, have their own > resolvers in place. They loose. What do they loose? >> I can't see your point here. > > acl's, firewalls, etc, that decide on source ip address if it can query > your resolver. I can circumvent that. How do you want to do this? Please respond by email directly, it's off-topic. >> You are a geek. But you spoke about end users. And they trust their ISP >> for the data they received from him. > > I'd advice joe end user to validate locally. They are free to do so. They are free to use any nameserver they want. But if they use the ISP's recursive resolver, this will be a validating one. > Just as I'd advice them validate certificates (which browsers do > automagically). Are you saying that end users should blindly trust their > http connection, just because it come via their ISP, or the ISP's proxy? No, you confuse the source of the data. The ISP can validate the integrity of DNSSEC-signed zones, and it is good to do so. The ISP can't validate the integrety of HTTPS certificates, because the protocols does not show them to him without serveral crude hacks. > You may call me a geek, thats fine, I see it as 'early adaptor'. We are all 'early adaptors', because we need the blood from the edge. From lutz at iks-jena.de Fri Feb 16 13:14:26 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 12:14:26 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: <45D59081.8030201@chello.nl> Message-ID: * Yuri Demchenko wrote: > What does DNSSEC and Techsec-WG people think about recently revealed > pharming attack technique that is based on the end user DNS altering? If you use a validating resolver on your end side, DNSSEC detects and prevents this attack. From lutz at iks-jena.de Fri Feb 16 13:27:13 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 12:27:13 +0000 (UTC) Subject: [dns-wg] Re: What about the last mile, was: getting DNSSEC deployed References: <20070216110529.GA1576@nic.fr> Message-ID: * Stephane Bortzmeyer wrote: > On Fri, Feb 16, 2007 at 10:29:41AM +0000, > Lutz Donnerhacke wrote >> Of course, it's a slightly modified bind. What's wrong with using >> the NSEC data for negative caching? > > RFC 4035, "4.5. Response Caching" > > In theory, a resolver could use wildcards or NSEC RRs to generate > positive and negative responses (respectively) until the TTL or > signatures on the records in question expire. However, it seems > prudent for resolvers to avoid blocking new authoritative data or > synthesizing new data on their own. Resolvers that follow this > recommendation will have a more consistent view of the namespace. I do not block new authoritative data, because I listen to NOTIFY on 232. and ff35:8000:. If authoritive server sends a NOTIFY to this group and the zone data is pruned on the listening resolver. Originally the multicast hack was done to update (hidden) secondaries behind firewalls. Using multicast there is no need for peeling holes into the firewall. From bortzmeyer at nic.fr Fri Feb 16 13:54:07 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 16 Feb 2007 13:54:07 +0100 Subject: [dns-wg] Re: What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: <45D59081.8030201@chello.nl> Message-ID: <20070216125407.GA22183@nic.fr> On Fri, Feb 16, 2007 at 12:14:26PM +0000, Lutz Donnerhacke wrote a message of 6 lines which said: > If you use a validating resolver on your end side, You forget "AND if the zone you query is signed". From bortzmeyer at nic.fr Fri Feb 16 13:57:18 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 16 Feb 2007 13:57:18 +0100 Subject: [dns-wg] Re: What about the last mile, was: getting DNSSEC deployed In-Reply-To: <45D59081.8030201@chello.nl> References: <45D59081.8030201@chello.nl> Message-ID: <20070216125718.GB22183@nic.fr> On Fri, Feb 16, 2007 at 12:07:45PM +0100, Yuri Demchenko wrote a message of 110 lines which said: > What does DNSSEC and Techsec-WG people think about recently revealed > pharming attack technique that is based on the end user DNS > altering? I really wonder why do all newspapers present it as a DNS attack. It is an attack against a server (the home router). Once you control it, you can do many things besides changing the DNS configuration (such as setting up a tunnel and diverting all IP data through it, so DNSSEC would be screwed, anyway). > On the practical note, I need to say something definite to my > students what DNS experts think? As I said, the DNS is not involved at all in this attack. From jim at rfc1035.com Fri Feb 16 14:00:19 2007 From: jim at rfc1035.com (Jim Reid) Date: Fri, 16 Feb 2007 13:00:19 +0000 Subject: [dns-wg] Re: What about the last mile, was: getting DNSSEC deployed In-Reply-To: <20070216125407.GA22183@nic.fr> References: <45D59081.8030201@chello.nl> <20070216125407.GA22183@nic.fr> Message-ID: <6FBA63C8-C571-42E0-9E19-80267CC9A245@rfc1035.com> On Feb 16, 2007, at 12:54, Stephane Bortzmeyer wrote: >> If you use a validating resolver on your end side, > > You forget "AND if the zone you query is signed". and you forget "AND you have a valid, properly configured trust anchor for the key that ultimately signs that zone". :-) Cue the Monty Python joke about our children's children's children... :-) From jaap at NLnetLabs.nl Fri Feb 16 13:46:38 2007 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Fri, 16 Feb 2007 13:46:38 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: Your message of Fri, 16 Feb 2007 12:07:45 +0100. <45D59081.8030201@chello.nl> Message-ID: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS Millions of high-speed Internet users across the globe are threatened by a new attack technique called drive-by pharming, Symantec and Indiana University researchers warned Thursday. http://go.techtarget.com/r/1004039/1401570 This method is variation on the team to users equipment as a coprocessor. In this case, a java applet tries to guess the passwd of the users adsl router and then reconfigures the dns server in the box. Most users have not chnged the original passwd (if an) or use an easy tp gues one. More details got dicussed on nanog. On the practical note, I need to say something definite to my students what DNS experts think? Tell then to switch of java etc. :-). As noted, dnssec can protect against spoofed dns info. jaap From pk at DENIC.DE Fri Feb 16 14:26:10 2007 From: pk at DENIC.DE (Peter Koch) Date: Fri, 16 Feb 2007 14:26:10 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: Message-ID: <20070216132610.GA1934@denics7.denic.de> On Fri, Feb 16, 2007 at 10:20:58AM +0000, Lutz Donnerhacke wrote: > The win will be much better if the root where signed (because the resolver > knows which TLD does not exists from cache), so that stetting up a signed > root for outself is a probable project in the near future. If lowering response times for QNAMEs falling into non-existent TLDs (or reducing garbage sent to the root servers) is your goal, why wait for DNSSEC? Just make your recursive server authoritative for the root zone (all caveats apply) and be done. I'm neither questioning nor recommending this approach, but I'm a bit concerned to see side effects (real or perceived) sold as benefits for DNSSEC, where these benefits don't exist. -Peter From lutz at iks-jena.de Fri Feb 16 14:49:32 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 13:49:32 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: <20070216132610.GA1934@denics7.denic.de> Message-ID: * Peter Koch wrote: > I'm a bit concerned to see side effects (real or perceived) sold as > benefits for DNSSEC, where these benefits don't exist. Of course, but the side effects are the cool things which make the pig fly. Examples: SSHFP is great for admins. CERT are great for those guys wanting VeriSign to disappear. Agressive negative caches are great for DNS admins. Zone enumerations are great for 'some' people. Larger responses are great for qmail haters. Security buzzwords are great for finanical instituts suffering phishing. Signing the root is great for fundemantalists. DLVs are great for always alternative geeks. Do I miss something? From roy at nominet.org.uk Fri Feb 16 15:35:15 2007 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 16 Feb 2007 15:35:15 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: Message-ID: So I lied. It wasn't my last response on the subject. Lutz Donnerhacke wrote on 02/16/2007 01:13:40 PM: > * Roy Arends wrote: > > Lutz Donnerhacke wrote on 02/16/2007 11:40:14 AM: > >> You can't update the installed base quick enought to gain the benefits > >> of DNSSEC. If the recursing resolvers do not validate, the whole DNSSEC > >> effect is going to zero. You will find about 100000 validating > >> resolvers at end user sites and nobody will sign a zone for this group > >> of geeks. > > > > Ah, you're assuming that folk will en-masse sign their zones for the > > handfull of validating resolvers ? > > Yes. See the reactions to the last announcement of a Swedish ISP. So folks with domains under '.se' are signing their zone en-masse ? Haven't seen those reactions. > > Meanwhile, my OS/X and windows boxes are configured (by default) to update > > itself regularly. Some of my applications do that as well. My browsers > > have validation intergrated. Joe end user would not even see the > > difference.... but he's better off than before. > > He will see a difference, if some spoofing attacks does not longer work. Stub resolvers can be spoofed trivially. resolver code in dsl routers/cable modems can be spoofed trivially. So, unless the end-user has dnssec deployed locally, spoofing attacks work. > > I don't really expect any demand from end-users in general. > > I see a strong demand from commercial banking institutes (not really). > Let's assume some major DSL-ISPs does switch on validating. This results in > a trusted DNS for about 60% of there customers (may be more). Now consider > the phishing buzzword. security theater. Nothing really changes for the end user. Those who tried to spoof resolvers will now change their focus towards the end-users stub. Arms race. > > That leaves us with pushing code to the end user, in applications and OS, > > which implies coorperation from and education to software developers. > > Taking this road means: Redo from start. It _is_ done from the start. We've put in the current standards. Applications can already use. My jabber server uses it. Validation on a stub. > Never get a reasonable deployment. > Root will not be signed, because there are not enough installations. More > installations will not come up, because the root is not signed and key > maintainence is a mess. Catch-22. That is the _current_ status quo. not enough installations have 'switched on' dnssec, so why bother signing. why bother switching on dnssec if not enough domains are signed. > >> I can't see your point here. > > > > acl's, firewalls, etc, that decide on source ip address if it can query > > your resolver. I can circumvent that. > > How do you want to do this? I scan a range, a few boxes will do a reverse lookup. I control the specific reverse address space, hence your resolver is talking to me: window of opportunity. Another way is spraying spam around, antispam code resolve whatever I tell it to resolve. This reminds to finish my article about intrusion detection detection (sic) methods, and develop some anti intrusion detection dection (sic) methods. > Please respond by email directly, it's off-topic. Well. Others might be interested in this as well, so, there. > >> You are a geek. But you spoke about end users. And they trust their ISP > >> for the data they received from him. > > > > I'd advice joe end user to validate locally. > > They are free to do so. They are free to use any nameserver they want. > But if they use the ISP's recursive resolver, this will be a validating one. What is the use of seeing a bit set in the response that claims that the response is validated, when I can't trust the link !!!!!!! > > Just as I'd advice them validate certificates (which browsers do > > automagically). Are you saying that end users should blindly trust their > > http connection, just because it come via their ISP, or the ISP's proxy? > > No, you confuse the source of the data. eh ? > The ISP can validate the integrity of DNSSEC-signed zones, and it is good to do so. The ISP can validate the integrity, sure. To me that would be another middlebox fondling with the data. > The ISP can't validate the > integrety of HTTPS certificates, because the protocols does not show them to > him without serveral crude hacks. So, basically, if the https protocol would allow it, ISP's like to validate the integrity of certificates as well.... so end users don't have to ? Roy From bortzmeyer at nic.fr Fri Feb 16 16:11:44 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 16 Feb 2007 16:11:44 +0100 Subject: [dns-wg] Re: World's first commercial service for DNSSEC launched in Sweden In-Reply-To: <023E9DDFC555E3479AEBF917CE60A0B4CC59B6@EXCHANGE.office.nic.se> References: <023E9DDFC555E3479AEBF917CE60A0B4CC59B6@EXCHANGE.office.nic.se> Message-ID: <20070216151144.GA28749@nic.fr> On Fri, Feb 16, 2007 at 04:02:53PM +0100, Anne-Marie Eklund-L?winder wrote a message of 46 lines which said: > -----BEGIN PGP SIGNED MESSAGE----- Great, next time be sure you sign properly :-) gpg: Signature made Fri Feb 16 16:02:53 2007 CET using DSA key ID 42B1CF94 gpg: BAD signature from "Anne-Marie Eklund-Lowinder " From bortzmeyer at nic.fr Fri Feb 16 16:29:00 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 16 Feb 2007 16:29:00 +0100 Subject: [dns-wg] Re: World's first commercial service for DNSSEC launched in Sweden In-Reply-To: <023E9DDFC555E3479AEBF917CE60A0B4CC59C9@EXCHANGE.office.nic.se> References: <023E9DDFC555E3479AEBF917CE60A0B4CC59B6@EXCHANGE.office.nic.se> <20070216151144.GA28749@nic.fr> <023E9DDFC555E3479AEBF917CE60A0B4CC59C9@EXCHANGE.office.nic.se> Message-ID: <20070216152900.GA25347@nic.fr> On Fri, Feb 16, 2007 at 04:25:09PM +0100, Anne-Marie Eklund-L?winder wrote a message of 43 lines which said: > Well, that's quite another story. That's probably happens because I > am using plain-text signatures together with Swedish diacritics, and > on top of that, Outlook. :-) This one worked, probably because it was sent directly to me, which seems to indicate that the MLM, not your MUA, was the culprit. In any case, it is a good indication of the type of problems we'll have when DNSSEC will be deployed :-) From lutz at iks-jena.de Fri Feb 16 17:03:19 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 16:03:19 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: Message-ID: * Roy Arends wrote: > So folks with domains under '.se' are signing their zone en-masse ? No, because it was free. Now you can _buy_ security from SE-DNSSEC and the run starts. :-/ > Stub resolvers can be spoofed trivially. resolver code in dsl > routers/cable modems can be spoofed trivially. It's hard to spoof in our own infrastructure, but YMMV. > security theater. Nothing really changes for the end user. Those who tried > to spoof resolvers will now change their focus towards the end-users stub. > Arms race. End user stubs arn't reachable from outside, due to firewalls etc. pp.. But YMMV. >> Taking this road means: Redo from start. > > It _is_ done from the start. We've put in the current standards. > Applications can already use. My jabber server uses it. Validation on a > stub. Fine! I'm happy with it. But I'm not happy with urging such installation on every end user host by prohibiting verifying recursive resolvers. >> Never get a reasonable deployment. Root will not be signed, because >> there are not enough installations. More installations will not come >> up, because the root is not signed and key maintainence is a mess. >> Catch-22. > > That is the _current_ status quo. not enough installations have 'switched > on' dnssec, so why bother signing. why bother switching on dnssec if not > enough domains are signed. Therefore every validating recursive resolver is a big win. Urging to shut validation down on those resolvers ist the wrong road. But YMMV. >>> acl's, firewalls, etc, that decide on source ip address if it can >>> query your resolver. I can circumvent that. >> >> How do you want to do this? > > I scan a range, a few boxes will do a reverse lookup. I control the > specific reverse address space, hence your resolver is talking to me: > window of opportunity. Another way is spraying spam around, antispam code > resolve whatever I tell it to resolve. So you do not query my resolver, but my resolver queries you. Let keep such discussions off the list. >> They are free to do so. They are free to use any nameserver they want. >> But if they use the ISP's recursive resolver, this will be a validating >> one. > > What is the use of seeing a bit set in the response that claims that the > response is validated, when I can't trust the link !!!!!!! Oh my godness. Paranoia is offtopic either. You have much more problems than DNS if the link between your system and your ISPs resolver is not trustworthy. >> The ISP can validate the integrity of DNSSEC-signed zones, and it is >> good to do so. > > The ISP can validate the integrity, sure. To me that would be another > middlebox fondling with the data. Paranoia again. So do not use the resolver of your ISP! > So, basically, if the https protocol would allow it, ISP's like to > validate the integrity of certificates as well.... so end users don't > have to? Of course. There are proxies which break the end-to-end-security of https in order to achive this. But I consider this as a hack. BTW: ISPs do validate a lot more of internet data while flying through. You do not see a lot of crap out there. And you are happy with it. From roy at nominet.org.uk Fri Feb 16 17:29:26 2007 From: roy at nominet.org.uk (Roy Arends) Date: Fri, 16 Feb 2007 17:29:26 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: Message-ID: Lutz, lets recap. I'm urging folk to not forget about the last mile. I'm fine with caching resolvers validating dns data. Roy From david.conrad at icann.org Fri Feb 16 17:51:13 2007 From: david.conrad at icann.org (David Conrad) Date: Fri, 16 Feb 2007 08:51:13 -0800 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> Message-ID: <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> > NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS ... > As noted, dnssec can protect against spoofed dns info. Except DNSSEC wouldn't really be applicable. The attack (as I understand it) provides a new IP address (that of an attacker-owned caching resolver) to clients on a LAN attached to the broadband router, with the attacker-owned caching resolver returning answers to stub resolver queries. Since validation is done at the caching resolver, DNSSEC wouldn't apply. Rgds, -drc From david.conrad at icann.org Fri Feb 16 17:57:13 2007 From: david.conrad at icann.org (David Conrad) Date: Fri, 16 Feb 2007 08:57:13 -0800 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: Message-ID: On Feb 16, 2007, at 12:52 AM, Roy Arends wrote: > Tell me Lutz, how does joe end user run a full featured validating > resolver daemon, when he barely understand the concept of DNS. End users run stuff significantly more complicated than a caching resolver without understanding the concepts. Running a caching resolver daemon should not require any end-user configuration. Rgds, -drc From lutz at iks-jena.de Fri Feb 16 18:00:21 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 17:00:21 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: Message-ID: * David Conrad wrote: > Running a caching resolver daemon should not require any end-user > configuration. Keymanagment is not free in the first step. From david.conrad at icann.org Fri Feb 16 18:19:57 2007 From: david.conrad at icann.org (David Conrad) Date: Fri, 16 Feb 2007 09:19:57 -0800 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: Message-ID: On Feb 16, 2007, at 9:00 AM, Lutz Donnerhacke wrote: > * David Conrad wrote: >> Running a caching resolver daemon should not require any end-user >> configuration. > Keymanagment is not free in the first step. Right. You have to run software update and click OK when new trust anchors need to be installed. End-users don't run caching servers for historical reasons having to do with CPU cycles and available RAM (and perhaps poor choices regarding configuration files in particular DNS software implementations). Those reasons don't apply anymore. Trusting the infrastructure between you and your ISP is merely creating a new target for attack. Or perhaps highlighting an existing target for attack. It also means you trust your ISP. As more and more ISPs see "sitefinder"-like functionality as a way of making more money faster, that trust is less and less tenable. Rgds, -drc From lutz at iks-jena.de Fri Feb 16 21:03:09 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Fri, 16 Feb 2007 20:03:09 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: Message-ID: * David Conrad wrote: > Trusting the infrastructure between you and your ISP is merely > creating a new target for attack. Or perhaps highlighting an > existing target for attack. It also means you trust your ISP. Because I am an ISP, my view is slightly biased. From dougb at dougbarton.us Fri Feb 16 21:50:07 2007 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 16 Feb 2007 12:50:07 -0800 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> Message-ID: <45D618FF.2050904@dougbarton.us> David Conrad wrote: >> NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS > ... >> As noted, dnssec can protect against spoofed dns info. > > Except DNSSEC wouldn't really be applicable. > > The attack (as I understand it) provides a new IP address (that of an > attacker-owned caching resolver) to clients on a LAN attached to the > broadband router, with the attacker-owned caching resolver returning > answers to stub resolver queries. Since validation is done at the > caching resolver, DNSSEC wouldn't apply. It would apply in the (theoretical) subset of applications that are configured to rely on signed and validated responses, like hopefully windows/osx/mozilla/other software updaters could be configured to do. It could also apply to an even more theoretical future browser feature that uses a mechanism similar to the shiny gold SSL padlock icon to indicate a signed and validated response, but the value of that would be limited to the subset of users who wouldn't just click "go to the site anyway" like they do with SSL warnings now. Doug -- If you're never wrong, you're not trying hard enough From david.conrad at icann.org Fri Feb 16 22:10:45 2007 From: david.conrad at icann.org (David Conrad) Date: Fri, 16 Feb 2007 13:10:45 -0800 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <45D618FF.2050904@dougbarton.us> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> <45D618FF.2050904@dougbarton.us> Message-ID: <7FA2BFC1-5947-46D7-82FE-85AF266A0E54@icann.org> On Feb 16, 2007, at 12:50 PM, Doug Barton wrote: > David Conrad wrote: >>> NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS >> ... >>> As noted, dnssec can protect against spoofed dns info. >> Except DNSSEC wouldn't really be applicable. > It would apply in the (theoretical) subset of applications that are > configured to rely on signed and validated responses, like hopefully > windows/osx/mozilla/other software updaters could be configured to do. The question is how do they get the information that the data has been signed and the signatures validated. Since with this attack they'd be going through a compromised server, they lose. The only way out of that hole is if you run a local validating caching server and have appropriate (out-of-band validated) trust anchors configured and if you're running a local caching server, you're already not susceptible to the attack. Rgds, -drc From demch at chello.nl Fri Feb 16 23:37:39 2007 From: demch at chello.nl (Yuri Demchenko) Date: Fri, 16 Feb 2007 23:37:39 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <7FA2BFC1-5947-46D7-82FE-85AF266A0E54@icann.org> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> <45D618FF.2050904@dougbarton.us> <7FA2BFC1-5947-46D7-82FE-85AF266A0E54@icann.org> Message-ID: <45D63233.7020708@chello.nl> David Conrad wrote: > On Feb 16, 2007, at 12:50 PM, Doug Barton wrote: >> David Conrad wrote: >>>> NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS >>> ... >>>> As noted, dnssec can protect against spoofed dns info. >>> Except DNSSEC wouldn't really be applicable. >> It would apply in the (theoretical) subset of applications that are >> configured to rely on signed and validated responses, like hopefully >> windows/osx/mozilla/other software updaters could be configured to do. > > The question is how do they get the information that the data has been > signed and the signatures validated. Since with this attack they'd be > going through a compromised server, they lose. The only way out of that > hole is if you run a local validating caching server and have > appropriate (out-of-band validated) trust anchors configured and if > you're running a local caching server, you're already not susceptible to > the attack. > I was thinking similar like home routers could have default configuration to use DNSSEC responses, and maybe in the future only DNSSEC. As about trust anchors, in other security applications we looking now closely at the TPM (Trusted Platform Module)/TCG technology that provides hardware bound and hardware protected trust anchors. Yuri From david.conrad at icann.org Sat Feb 17 00:00:30 2007 From: david.conrad at icann.org (David Conrad) Date: Fri, 16 Feb 2007 15:00:30 -0800 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <45D63233.7020708@chello.nl> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> <45D618FF.2050904@dougbarton.us> <7FA2BFC1-5947-46D7-82FE-85AF266A0E54@icann.org> <45D63233.7020708@chello.nl> Message-ID: <3ED97A86-0053-425A-8FA6-590C8064B662@icann.org> Yuri, On Feb 16, 2007, at 2:37 PM, Yuri Demchenko wrote: >> The question is how do they get the information that the data has >> been signed and the signatures validated. Since with this attack >> they'd be going through a compromised server, they lose. The only >> way out of that hole is if you run a local validating caching >> server and have appropriate (out-of-band validated) trust anchors >> configured and if you're running a local caching server, you're >> already not susceptible to the attack. > I was thinking similar like home routers could have default > configuration to use DNSSEC responses, and maybe in the future only > DNSSEC. Wouldn't this mean the nasty javascript merely updates the trust anchors to point to the bad guy's DNS server? That is, if the home user doesn't configure the password and the trust anchors are configurable on the router, the bad guys win. As was mentioned previously, this really isn't a DNS attack. It is a "exploitation of a default password" attack, so DNSSEC doesn't help. > As about trust anchors, in other security applications we looking > now closely at the TPM (Trusted Platform Module)/TCG technology > that provides hardware bound and hardware protected trust anchors. This might work if it requires no end user interaction. Rgds, -drc From president at ukraine.su Mon Feb 19 00:27:44 2007 From: president at ukraine.su (Max Tulyev) Date: Sun, 18 Feb 2007 23:27:44 +0000 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: Message-ID: <45D8E0F0.3010907@ukraine.su> Lutz Donnerhacke wrote: >> I find those last two statements highly unlikely, but for argument sake, >> multiply this by cost(crypto(lastmile))*count(users). > > I do not see the need for crypto on the last mile. And what to do with spoofed answers? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Mon Feb 19 00:37:44 2007 From: president at ukraine.su (Max Tulyev) Date: Sun, 18 Feb 2007 23:37:44 +0000 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: Message-ID: <45D8E348.1040402@ukraine.su> Lutz Donnerhacke wrote: > Most DSL markets are death due to dumping. If you really want to keep > customers, you have to provide more features. Security is a very valuable > feature this days. Adding DNSSEC validating causes a major step-up at least > in press release shootouts. Yes! Certainly ;) It is cheap for implement (just activate some options), but loud to shout ;) From president at ukraine.su Mon Feb 19 00:38:51 2007 From: president at ukraine.su (Max Tulyev) Date: Sun, 18 Feb 2007 23:38:51 +0000 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: <45D59081.8030201@chello.nl> Message-ID: <45D8E38B.8090706@ukraine.su> Lutz Donnerhacke wrote: > * Yuri Demchenko wrote: >> What does DNSSEC and Techsec-WG people think about recently revealed >> pharming attack technique that is based on the end user DNS altering? > > If you use a validating resolver on your end side, DNSSEC detects and > prevents this attack. > How? As I understood, the idea of the attack is to change DNS, not to poison it. From jorgen at hovland.cx Sun Feb 18 22:36:20 2007 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Sun, 18 Feb 2007 22:36:20 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: <45D8E0F0.3010907@ukraine.su> Message-ID: <001701c753a4$d5928600$c102955b@l> ----- Original Message ----- From: "Max Tulyev" > Lutz Donnerhacke wrote: > >>> I find those last two statements highly unlikely, but for argument sake, >>> multiply this by cost(crypto(lastmile))*count(users). >> >> I do not see the need for crypto on the last mile. > > And what to do with spoofed answers? 256bit nonce/id field instead of 16. From Anne-Marie.Eklund-Lowinder at iis.se Fri Feb 16 16:02:53 2007 From: Anne-Marie.Eklund-Lowinder at iis.se (=?iso-8859-1?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Fri, 16 Feb 2007 16:02:53 +0100 Subject: [dns-wg] World's first commercial service for DNSSEC launched in Sweden Message-ID: <023E9DDFC555E3479AEBF917CE60A0B4CC59B6@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [2007-02-16] .SE (The Internet Infrastructure Foundation) responsible for the Swedish top-level domain on the Internet, today launched .SE-DNSSEC, the world's first commercial service with DNS Security Extensions (DNSSEC) for cryptographically signed name resolving in the domain name system (DNS), in the presence of Dr. Steve Crocker, major Swedish ISP:s, Registrars, Government Agencys, Swedish DNS experts and Swedish banks. http://www.iis.se/english/nyheter/news/2007-02-16?lang=en The first customer registered just minutes after the launch. Anne-Marie Eklund L?winder Quality & Security Manager .SE (The Internet Infrastructure Foundation) P O Box 7399 103 91 Stockholm Sweden Tel: +46 8 452 35 00, direct: +46 8 452 35 17, mobile: +46 734 315 310 E-mail: anne-marie.eklund-lowinder at iis.se Web: www.iis.se -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRdXHnaXc8AFCsc+UEQKyQgCgroFV70K5SvVYPKeIzma0+ma2vDIAn2j/ snytxj/Xamt6T8mEL3kqNoRc =oNcW -----END PGP SIGNATURE----- From Anne-Marie.Eklund-Lowinder at iis.se Fri Feb 16 16:25:09 2007 From: Anne-Marie.Eklund-Lowinder at iis.se (=?iso-8859-1?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Fri, 16 Feb 2007 16:25:09 +0100 Subject: [dns-wg] SV: World's first commercial service for DNSSEC launched in Sweden In-Reply-To: <20070216151144.GA28749@nic.fr> References: <023E9DDFC555E3479AEBF917CE60A0B4CC59B6@EXCHANGE.office.nic.se> <20070216151144.GA28749@nic.fr> Message-ID: <023E9DDFC555E3479AEBF917CE60A0B4CC59C9@EXCHANGE.office.nic.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, that's quite another story. That's probably happens because I am using plain-text signatures together with Swedish diacritics, and on top of that, Outlook. :-) All the best, Anne-Marie > -----Ursprungligt meddelande----- > Fr?n: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] > Skickat: den 16 februari 2007 16:12 > Till: Anne-Marie Eklund-L?winder > Kopia: dns-operations at mail.oarc.isc.org; dns-wg at ripe.net; > dns-app at lists.cafax.se; sec-heads at romab.com > ?mne: Re: World's first commercial service for DNSSEC > launched in Sweden > > On Fri, Feb 16, 2007 at 04:02:53PM +0100, Anne-Marie > Eklund-L?winder wrote a > message of 46 lines which said: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Great, next time be sure you sign properly :-) > > gpg: Signature made Fri Feb 16 16:02:53 2007 CET using DSA > key ID 42B1CF94 > gpg: BAD signature from "Anne-Marie Eklund-Lowinder > " -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRdXM1aXc8AFCsc+UEQKa3gCeMw33Fwvj4+rdusxtyh6AnEYtcCcAnR0b O9L44mp9WrVitq+T7bt9pdR4 =baQI -----END PGP SIGNATURE----- From simon at josefsson.org Fri Feb 16 17:00:29 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 16 Feb 2007 17:00:29 +0100 Subject: [dns-wg] Re: World's first commercial service for DNSSEC launched in Sweden In-Reply-To: <20070216152900.GA25347@nic.fr> (Stephane Bortzmeyer's message of "Fri\, 16 Feb 2007 16\:29\:00 +0100") References: <023E9DDFC555E3479AEBF917CE60A0B4CC59B6@EXCHANGE.office.nic.se> <20070216151144.GA28749@nic.fr> <023E9DDFC555E3479AEBF917CE60A0B4CC59C9@EXCHANGE.office.nic.se> <20070216152900.GA25347@nic.fr> Message-ID: <87tzxm8542.fsf@latte.josefsson.org> Stephane Bortzmeyer writes: > On Fri, Feb 16, 2007 at 04:25:09PM +0100, > Anne-Marie Eklund-L?winder wrote > a message of 43 lines which said: > >> Well, that's quite another story. That's probably happens because I >> am using plain-text signatures together with Swedish diacritics, and >> on top of that, Outlook. :-) > > This one worked, probably because it was sent directly to me, which > seems to indicate that the MLM, not your MUA, was the culprit. > > In any case, it is a good indication of the type of problems we'll > have when DNSSEC will be deployed :-) Actually that analogy doesn't hold fully. The PGP signature that were used by Anne-Marie doesn't conform to the IETF-standardized PGP-in-mail format, i.e. RFC 2015/3156. If RFC 3156 were used, the signature should have worked fine, even for non-ASCII characters such as '?'. This does not mean that DNSSEC as standardized by the IETF will work, though... ;-) /Simon Btw, the second signature were good here too. It was ASCII only. Let's see if this non-ASCII properly signed e-mail goes through.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From lutz at iks-jena.de Mon Feb 19 10:27:11 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 19 Feb 2007 09:27:11 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: <45D8E0F0.3010907@ukraine.su> Message-ID: * Max Tulyev wrote: > Lutz Donnerhacke wrote: >> I do not see the need for crypto on the last mile. > > And what to do with spoofed answers? Spoofing the ISPs resolver on the last mile is not possible due to ingress filtering. From lutz at iks-jena.de Mon Feb 19 10:28:19 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 19 Feb 2007 09:28:19 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: <45D8E38B.8090706@ukraine.su> Message-ID: * Max Tulyev wrote: > Lutz Donnerhacke wrote: >> If you use a validating resolver on your end side, DNSSEC detects and >> prevents this attack. > > How? As I understood, the idea of the attack is to change DNS, not to > poison it. If you always get the right answer, this attack does not harm. From ncc at ripe.net Mon Feb 19 11:16:15 2007 From: ncc at ripe.net (RIPE NCC) Date: Mon, 19 Feb 2007 11:16:15 +0100 Subject: [dns-wg] RIPE NCC Planned Maintenance, February/March 2007 Message-ID: <20070219102058.9BA5C60082@x34.ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC will perform maintenance work that will affect a number of servers. The maintenance work will take place on: Tuesday, 20 February 2007 between 18:00 and 20:00 UTC Thursday, 22 February 2007 between 18:00 and 20:00 UTC Tuesday, 27 February 2007 between 18:00 and 20:00 UTC During this maintenance, individual servers may experience short outages. We apologise for any inconvenience that this may cause. If you have any questions about this, please send an e-mail to ops at ripe.net. Regards, James -- James Aldridge, Senior Systems & Network Engineer, RIPE NCC From president at ukraine.su Mon Feb 19 11:42:23 2007 From: president at ukraine.su (Max Tulyev) Date: Mon, 19 Feb 2007 12:42:23 +0200 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: <45D8E0F0.3010907@ukraine.su> Message-ID: <45D97F0F.7050205@ukraine.su> Lutz Donnerhacke wrote: > * Max Tulyev wrote: >> Lutz Donnerhacke wrote: >>> I do not see the need for crypto on the last mile. >> And what to do with spoofed answers? > > Spoofing the ISPs resolver on the last mile is not possible due to ingress > filtering. > ...if it is switched on, if it is at all routers, if the spoofer not in the same ethernet (or other L2 broadcast) segment, if..., if..., if... :) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From lutz at iks-jena.de Mon Feb 19 12:10:03 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 19 Feb 2007 11:10:03 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: <45D97F0F.7050205@ukraine.su> Message-ID: * Max Tulyev wrote: > Lutz Donnerhacke wrote: >> * Max Tulyev wrote: >>> Lutz Donnerhacke wrote: >>>> I do not see the need for crypto on the last mile. > > ...if it is switched on, if it is at all routers, if the spoofer not in > the same ethernet (or other L2 broadcast) segment, if..., if..., if... :) I'm the ISP. From president at ukraine.su Mon Feb 19 12:26:06 2007 From: president at ukraine.su (Max Tulyev) Date: Mon, 19 Feb 2007 13:26:06 +0200 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: <45D97F0F.7050205@ukraine.su> Message-ID: <45D9894E.9080202@ukraine.su> Lutz Donnerhacke wrote: > * Max Tulyev wrote: >> Lutz Donnerhacke wrote: >>> * Max Tulyev wrote: >>>> Lutz Donnerhacke wrote: >>>>> I do not see the need for crypto on the last mile. >> ...if it is switched on, if it is at all routers, if the spoofer not in >> the same ethernet (or other L2 broadcast) segment, if..., if..., if... :) > > I'm the ISP. > Me too. But what is the difference? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From lutz at iks-jena.de Mon Feb 19 13:05:20 2007 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 19 Feb 2007 12:05:20 +0000 (UTC) Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed References: <45D9894E.9080202@ukraine.su> Message-ID: * Max Tulyev wrote: > Lutz Donnerhacke wrote: >> I'm the ISP. > > Me too. > But what is the difference? You can't spoof my nameserver in my network. YNMV. From jorgen at hovland.cx Mon Feb 19 13:17:59 2007 From: jorgen at hovland.cx (=?utf-8?Q?J=C3=B8rgen_Hovland?=) Date: Mon, 19 Feb 2007 13:17:59 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: <45D9894E.9080202@ukraine.su> Message-ID: <008001c7541f$ff29d740$5c0b000a@tungemaskin> -----Original Message----- From: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] On Behalf Of Lutz Donnerhacke >* Max Tulyev wrote: >> Lutz Donnerhacke wrote: >>> I'm the ISP. >> >> Me too. >> But what is the difference? > >You can't spoof my nameserver in my network. YNMV. It is not a requirement to be in your network in order to spoof it. From president at ukraine.su Mon Feb 19 13:41:23 2007 From: president at ukraine.su (Max Tulyev) Date: Mon, 19 Feb 2007 14:41:23 +0200 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: References: <45D9894E.9080202@ukraine.su> Message-ID: <45D99AF3.5090803@ukraine.su> Lutz Donnerhacke wrote: > * Max Tulyev wrote: >> Lutz Donnerhacke wrote: >>> I'm the ISP. >> Me too. >> But what is the difference? > > You can't spoof my nameserver in my network. YNMV. > Even beeing in same L2 broadcast segment with you? (assuming your workstation don't have running DNS resolver with enabled DNSSEC) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From Woeber at CC.UniVie.ac.at Mon Feb 19 11:05:59 2007 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 19 Feb 2007 10:05:59 +0000 Subject: [techsec-wg] Re: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> References: <200702161246.l1GCkcJG089857@bartok.nlnetlabs.nl> <9E465AD0-2235-42DD-AFD0-B5DC155F653F@icann.org> Message-ID: <45D97687.9070407@CC.UniVie.ac.at> David Conrad wrote: >> NEW ATTACK TECHNIQUE THREATENS BROADBAND USERS > > ... > >> As noted, dnssec can protect against spoofed dns info. > > > Except DNSSEC wouldn't really be applicable. I know, it would be sloppy use of terms, but when I read the thread I "included" TSIG under the DNSSEC item. That could help, unless the shared secret gets easily compromised, too, and it probably would, assuming that java* or active* is enabled ;-) > The attack (as I understand it) provides a new IP address (that of an > attacker-owned caching resolver) to clients on a LAN attached to the > broadband router, with the attacker-owned caching resolver returning > answers to stub resolver queries. Since validation is done at the > caching resolver, DNSSEC wouldn't apply. > > Rgds, > -drc Wilfried. From brettcarr at ripe.net Thu Feb 22 15:41:34 2007 From: brettcarr at ripe.net (Brett Carr) Date: Thu, 22 Feb 2007 15:41:34 +0100 Subject: [dns-wg] Maintenance on ns.ripe.net Message-ID: [Apologies for duplicates] Dear Colleagues, On 28 February 2007, authoritative Reverse DNS Services on ns.ripe.net will be unavailable between 18:00 and 21:00 UTC. During this time we need to carry out maintenance work. We apologise in advance for any inconvenience. If you have any questions or concerns about this, send an e-mail to dns-help at ripe.net Regards -- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam From fw at deneb.enyo.de Sat Feb 24 16:18:43 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 24 Feb 2007 16:18:43 +0100 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: (Roy Arends's message of "Wed, 14 Feb 2007 23:08:34 +0100") References: Message-ID: <87d53zwpm4.fsf@mid.deneb.enyo.de> * Roy Arends: > So what about joe end user. Are there initiatives to offer tsig/sig0/dtls > between user and isp ? Are there initiatives to deploy code at the OS > level, similar as to what the NLNetLabs and Sparta folk are building for > the application level ? Are formentioned providers deploying either of > these two sets of solutions to their end users ? Or is it all just > security theater ? I've been thinking about this recently (for a fairly tech-savvy user base, but also including end users). My hope was some design that would enable us to add a simple "enable DNSSEC with DLV" switch to the operating system. The basic idea is like this: - Install a local BIND 9 resolver in forward-only mode. Enable DLV (using ISC's zone if allowed). - Modify software which updates /etc/resolv.conf to tweak the BIND configuration instead. In this configuration, /etc/resolv.conf will always point to localhost. - Perhaps modify the libc stub resolver to return better error codes, and update some interactive applications to make use of them. - If necessary, tweak BIND so that it exposes a DNSSEC-less view to applications, and does not request validation from the forwarders. (For instance, we must not exceed the 512 byte size limit on the application interface when the original configuration doesn't.) - Get some banks or other high-profile sites to participate in the DLV project, so that all this actually makes sense. However, I fear that many users are located on networks which do not offer a transparent DNS transport: the forwarders they use are not capable of handling requests for DNSSEC-related RRs for some reason. Perhaps they discard resource records they deem strange, or they have got problems with large responses. A typical setup might look like this: +--------------+ | ISP resolver | +--------------+ similar configuration | at a different ISP | : /---------------\ : | Access Router | : \---------------/ : | : | : /-----\ : | CPE |.................: \-----/ (actually, the CPE is a cheap NAT device) | +------+ | Host | (running a DNSSEC-aware resolver locally) +------+ The CPE typically runs some kind of DNS forwarder (can be a simple destination NAT, but might be an application proxy), and advertises itself as caching resolver to the host via DHCP. The access router might inspect DNS traffic and transparently proxy it. It's not too uncommon that the "ISP" the end user subscribes to switches their subcontractor, so that you can get hooked to a completely different infrastructure over night. The subcontractor might use anycast or load-balancing across different implementations to provide the caching service. If the host is a real mobile device, the picture is much more complicated. There are a couple of things that can go wrong here: ISP resolver, access router (if proxying) and the CPE must be transparent for DNSSEC traffic. It's not sufficient to check this at installation time. It's hard to cache this information, too (thanks to load-balancing). Perhaps these fears are unwarranted; fairly distributed testing would provide us with some assurance that this might actually work. Unfortunately, the real showstopper I see is that you cannot tell an attack from an infrastructure change that happened to break DNSSEC. But we need to provide some kind of fallback in case DNSSEC breaks because we absolutely must ensure that we match plain DNS in terms of availability. (And I don't think yet another security indicator visible to the end user is the answer.) Running name resolution over 443/TCP to some central resolver infrastructure suddenly seems much more attractive, doesn't it? However, I don't like the way this facilitates large-scale interception of DNS traffic (with end user addresses intact, so that you won't call me a hypocrite 8-). From rstory at sparta.com Mon Feb 26 15:51:18 2007 From: rstory at sparta.com (Robert Story) Date: Mon, 26 Feb 2007 09:51:18 -0500 Subject: [dns-wg] What about the last mile, was: getting DNSSEC deployed In-Reply-To: <87d53zwpm4.fsf@mid.deneb.enyo.de> References: <87d53zwpm4.fsf@mid.deneb.enyo.de> Message-ID: <20070226095118.479512b5@spx.vb.futz.org> On Sat, 24 Feb 2007 16:18:43 +0100 Florian wrote: FW> Unfortunately, the real showstopper I see is that you cannot tell an FW> attack from an infrastructure change that happened to break DNSSEC. FW> But we need to provide some kind of fallback in case DNSSEC breaks FW> because we absolutely must ensure that we match plain DNS in terms of FW> availability. (And I don't think yet another security indicator FW> visible to the end user is the answer.) Well, you've got yourself painted into a corner here. I don't think you can have a fallback, or you haven't added any security. The only way to get an ISP to sit up and take notice will be the flood of support calls when they do something that breaks DNS, just as it it now. (Of course, this is also probably one of the reasons they are wary of deploying DNSSEC in the first place). FW> Running name resolution over 443/TCP to some central resolver FW> infrastructure suddenly seems much more attractive, doesn't it? Not particularly. Either way, you've got to get the ISPs to buy into a new way of thinking about DNS. Besides, I haven't seen any real detail on how this 443/tcp idea would work. I'm sure that if it got as much scrutiny as DNSSEC has had, it would turn out to not be as simple as it's proponents might think it is. -- Robert Story SPARTA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From president at ukraine.su Tue Feb 27 11:50:59 2007 From: president at ukraine.su (Max Tulyev) Date: Tue, 27 Feb 2007 12:50:59 +0200 Subject: [dns-wg] Re: Swedish ISP TCD Song Adopts DNSSEC In-Reply-To: <45D207FF.5070308@dougbarton.us> References: <023E9DDFC555E3479AEBF917CE60A0B4CC54BB@EXCHANGE.office.nic.se> <533CF084-D43B-4B68-8CFE-38AD472E199C@cisco.com> <20070213160543.GA9689@belenus.iks-jena.de> <45D1EEC3.7030902@ukraine.su> <45D207FF.5070308@dougbarton.us> Message-ID: <45E40D13.1060109@ukraine.su> Doug Barton wrote: > Max Tulyev wrote: >> We (NetAssist, Kiev, Ukraine) did it a year ago (RIPE backresolve, .se, >> .ru, .net, .com as well as ISC's DLV checking). > > I think this is a great move. Have you had any feedback from your users? Common users didn't notify any differences. But some of experienced ones notified slightly increased time of resolve. I notified significant decrease of spam. > How is the information about whether the RRsets are signed and/or > validated, or not, getting back to the clients? IOW, if I'm a piece of > anti-spam software, how do I know that the answer I received is signed > and validated? If you are just resolver client and someone trying to cheat backresolve tests - you'll get this IP is just not resolved. And of course, you can use libraries such as http://www.net-dns.org/ For me, failed DNSSEC validation of DNS resolve (including DNS BL tests) is the enough argument to drop that mail as the spam or fraud. By the way, is there any tools and/or log analyzers to gather and analyze some statistics about DNSSEC working on my servers? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO)