From shane@isc.org Thu Mar 1 03:10:01 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAE021F86C7 for ; Thu, 1 Mar 2012 03:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFQL53Oz22Il for ; Thu, 1 Mar 2012 03:10:00 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id F08DA21F8664 for ; Thu, 1 Mar 2012 03:09:59 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id D8D8EC9428; Thu, 1 Mar 2012 11:09:44 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-desktop (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AC46E216C31; Thu, 1 Mar 2012 11:09:42 +0000 (UTC) (envelope-from shane@isc.org) Date: Thu, 1 Mar 2012 12:09:24 +0100 From: Shane Kerr To: "John Levine" Message-ID: <20120301120924.4e8f3d6e@shane-desktop> In-Reply-To: <20120229164716.36600.qmail@joyce.lan> References: <20120229102255.74fa4291@shane-desktop> <20120229164716.36600.qmail@joyce.lan> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:10:01 -0000 John, On Wednesday, 2012-02-29 16:47:16 -0000, "John Levine" wrote: > >The main (only?) advantage of doing it with EDNS is that you can work > >with existing name servers. It means adding more logic to our already > >fabulously complicated resolvers to get full benefit, but nobody ever > >said DNS was easy. > > If you're adding logic to servers and clients, why couldn't some of > that logic listen on a different port? Of course it could, but we would like old and new services to live together happily. What we don't want is for new servers to send a packet and have to go through a timeout if old servers do not support the service. In principle we could signal somehow that new servers are available without sending a packet. The obvious way to do this - a new RR type - is suboptimal, because if the new RR type does not live above the zone cut then old style packets will still have to be used to figure out the status of the servers. Perhaps we could use a hack like the DNSCurve folks do, and encode in the name of the delegation that it is a new-style server: waycool.example.com NS w--waycool-new-ns-1.waycool.example.com NS w--waycool-new-ns-2.waycool.example.com NS old-school-ns-1.waycool.example.com NS old-school-ns-2.waycool.example.com If a hack like this makes sense, then a new port also makes sense. > But honestly, I don't see what problem is being solved here. The > original motivation was to ask for SPF and TXT records at the same > time, rather than sending two queries. You don't need a new version > of DNS to handle that, all you need is a kludge in your server that > knows that when it gets a query for one, it can return the other in > the additional section. MX queries already have their kludge, > returning A and AAAA records. I'm pretty sure MX queries do NOT have a kludge. I don't believe that the additional section is actually used by any servers these days, so MX queries (and their grown-up cousins, the SRV queries) are a great example of where putting multiple queries in a single packet would be helpful. While multiple queries in a single packet would not eliminate all extra traffic, at least it would mean you could do all A/AAAA queries in one follow-up packet: what is MX for xxx.example.com? -> <- a.example.com and b.example.com what are the A and AAAA for a.example.com and b.example.com? <- 192.0.2.1, 192.0.2.2 So we save 3 queries, although to be honest mail is the least interesting since it all happens in the background and the traffic for DNS is minimal compared to the traffic for the actual mail. :) My personal goal is to improve resolution times for A/AAAA lookups by collecting them into a single query. Perhaps it makes more sense to simply add Yet Another DNS Hack and add a special QTYPE like ANY meaning "any address", that is actually well-defined and usable. There are possibly (probably?) other use cases, which is why I asked what the use cases are. :) > The meta-reason for doing two queries is that it's still so hard to > provision new RR types that people fake them with TXT. If we're going > to hack on our DNS software, I'd rather work on that. It will always be easier to simply use a TXT record. I can do pretty much anything with a TXT record and my own software today... I just start coding and a couple hours later there it is. Even if the process is as simple as going to a web page on IANA and filling in a 3-field form and waiting for the automatically-generated confirmation e-mail, it will *still* be easier just to hack my own stuff and not worry about it. Having said that, it can't be extremely hard to get a new RR type. There are tons of RR types that have been issued and never even had a complete specification proposed. (You can see Ed's draft-lewis-dns-undocumented-types for a list of these.) So I think the meta-reason for doing multiple queries is because sometimes you have related lookups and it would be handy to, you know, do them at the same time. Cheers, -- Shane From johnl@taugh.com Thu Mar 1 06:08:57 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02B721E81B5 for ; Thu, 1 Mar 2012 06:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWHNE6bENjgH for ; Thu, 1 Mar 2012 06:08:57 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 13EC721E814C for ; Thu, 1 Mar 2012 06:08:56 -0800 (PST) Received: (qmail 73235 invoked from network); 1 Mar 2012 14:08:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=11e0f.4f4f82f7.k1203; bh=smyXhs+CNf/sFBrfhIG23kBMeRWrfmCKq7PIVmWJt5s=; b=uTvHj46qyXNJoZ2Aya7ZMGXluqGIeszXRGNB4lqfAh5brZeCY5av9uM8B5E0m5LI2X6CXgiI2nu08plQEseDSybG09CJERNvpjbxI+H+s3DzIdPxJVPmLIWqq1IZHZsjCKbDNKS0Ccnee5Kqq/BWxr9tCUhyQ3ES8sllHYx8hA8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=11e0f.4f4f82f7.k1203; bh=smyXhs+CNf/sFBrfhIG23kBMeRWrfmCKq7PIVmWJt5s=; b=RvKIVY0AlJx726sqldyqNxNZzT4uW9m0lMZ00pvDM3j3DsWXTjeKWNUl7Q7gRpXfclk+5BGoAoz+7D0XQtUwda80BuMqhC/ij0wf0tFlxO8R4e2dO8X/GpOYCX+letAcUg9/VC8HYF9tmNWkFsAZ032QJtX5VQ0OKj6qCSTyZlA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Mar 2012 14:08:33 -0000 Date: 1 Mar 2012 09:08:55 -0500 Message-ID: From: "John R Levine" To: "Shane Kerr" In-Reply-To: <20120301120924.4e8f3d6e@shane-desktop> References: <20120229102255.74fa4291@shane-desktop> <20120229164716.36600.qmail@joyce.lan> <20120301120924.4e8f3d6e@shane-desktop> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:08:57 -0000 >> the additional section. MX queries already have their kludge, >> returning A and AAAA records. > > I'm pretty sure MX queries do NOT have a kludge. I don't believe that > the additional section is actually used by any servers these days, Really? Caches throw away additional sections even when they're authoritative? I find that rather surprising. Why would it be a productive use of time to add all this new mechanism, rather than fix caches to use the exact same data that they're already getting? I know about cache poisoning, but the logic to deal with it is exactly the same logic you'd have to use to decide which of multiple answers to accept. > My personal goal is to improve resolution times for A/AAAA lookups by > collecting them into a single query. Perhaps it makes more sense to > simply add Yet Another DNS Hack and add a special QTYPE like ANY > meaning "any address", that is actually well-defined and usable. Add a new RR called AORAAAA that returns both with a field that has flag bits to say which is valid. And, of course, the A and AAAA records in the additional section. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From nweaver@icsi.berkeley.edu Thu Mar 1 06:43:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B873721E82F0 for ; Thu, 1 Mar 2012 06:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm6MwWJKnS2z for ; Thu, 1 Mar 2012 06:43:08 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5A921E82E9 for ; Thu, 1 Mar 2012 06:43:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 1864B2C4046; Thu, 1 Mar 2012 06:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3Gxs7OK7lcFO; Thu, 1 Mar 2012 06:43:07 -0800 (PST) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id BB9D82C400E; Thu, 1 Mar 2012 06:43:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 1 Mar 2012 06:43:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <453CF72C-6CB5-4015-B35B-EE00E668BD2D@icsi.berkeley.edu> References: <20120229102255.74fa4291@shane-desktop> <20120229164716.36600.qmail@joyce.lan> <20120301120924.4e8f3d6e@shane-desktop> To: "John R Levine" X-Mailer: Apple Mail (2.1257) Cc: dnsop@ietf.org, Shane Kerr , Nicholas Weaver Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:43:08 -0000 On Mar 1, 2012, at 6:08 AM, John R Levine wrote: >>> the additional section. MX queries already have their kludge, >>> returning A and AAAA records. >>=20 >> I'm pretty sure MX queries do NOT have a kludge. I don't believe that >> the additional section is actually used by any servers these days, >=20 > Really? Caches throw away additional sections even when they're = authoritative? I find that rather surprising. >=20 > Why would it be a productive use of time to add all this new = mechanism, rather than fix caches to use the exact same data that = they're already getting? >=20 > I know about cache poisoning, but the logic to deal with it is exactly = the same logic you'd have to use to decide which of multiple answers to = accept. =20 Yes, the logic should be "NEVER cache anything you didn't directly ask = for, absent DNSSEC validation". =20 Which means you (IMO) MUST throw away non-authoritative information in = the additional section, and most resolvers will only even attempt to = cache additional records when they are the records associated with the = authority section. It is the caching of non-asked-for data, be it Auth, Additional, CNAME = chains, etc, which enables race-until-win attacks like the Kaminski = attack. Thus a resolver MUST NEVER cache data that wasn't specifically asked for = if it can't DNSSEC validate this information. It can use the additional = data received to indicate that it SHOULD ask for the information, but it = shouldn't ever cache it in a general context. Or, if it does cache it, it should validate that the entry would be = valid by performing an independent lookup, a'la Unbound and replace the = information with the new version. >> My personal goal is to improve resolution times for A/AAAA lookups by >> collecting them into a single query. Perhaps it makes more sense to >> simply add Yet Another DNS Hack and add a special QTYPE like ANY >> meaning "any address", that is actually well-defined and usable. >=20 > Add a new RR called AORAAAA that returns both with a field that has = flag bits to say which is valid. And, of course, the A and AAAA records = in the additional section. Or don't bother. As I mentioned earlier, this is a clear = parallelization case, so the only thing you are saving in this = optimization is ~100B of traffic, and the latency involved in = transmitting an additional 100B through the network. From fanf2@hermes.cam.ac.uk Thu Mar 1 06:51:45 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E924F21E833B for ; Thu, 1 Mar 2012 06:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.701 X-Spam-Level: X-Spam-Status: No, score=-5.701 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tje5faQa1Kuk for ; Thu, 1 Mar 2012 06:51:45 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id BA06E21E8337 for ; Thu, 1 Mar 2012 06:51:44 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57137) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1S37M3-0004ya-SV (Exim 4.72) (return-path ); Thu, 01 Mar 2012 14:51:39 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S37M3-0003Uz-Oz (Exim 4.67) (return-path ); Thu, 01 Mar 2012 14:51:39 +0000 Date: Thu, 1 Mar 2012 14:51:39 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John R Levine In-Reply-To: Message-ID: References: <20120229102255.74fa4291@shane-desktop> <20120229164716.36600.qmail@joyce.lan> <20120301120924.4e8f3d6e@shane-desktop> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop@ietf.org, Shane Kerr Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:51:46 -0000 John R Levine wrote: > > > the additional section. MX queries already have their kludge, > > > returning A and AAAA records. > > > > I'm pretty sure MX queries do NOT have a kludge. I don't believe that > > the additional section is actually used by any servers these days, > > Really? Caches throw away additional sections even when they're > authoritative? I find that rather surprising. It is also not very useful from the MTA point of view, since the MTA can't tell if A or AAAA records are missing because they don't exist or there wasn't enough space in the DNS reply etc. So in most cases (especially an IPv6 aware MTA getting no AAAA records in reply) the MTA still has to follow up an MX query with more queries to get address records. Tony. -- f.anthony.n.finch http://dotat.at/ Viking: Cyclonic becoming north or northwest 5 or 6, veering east or southeast 4 or 5 later. Slight or moderate, occasionally rough. Occasional rain. Moderate or good, occasionally poor. From johnl@taugh.com Thu Mar 1 07:02:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4D621E8185 for ; Thu, 1 Mar 2012 07:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYjPcjkVaABD for ; Thu, 1 Mar 2012 07:02:26 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EBEAD21E80F0 for ; Thu, 1 Mar 2012 07:02:21 -0800 (PST) Received: (qmail 96804 invoked from network); 1 Mar 2012 15:02:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=17a23.4f4f8f79.k1203; bh=dtFkK1cIbAKPcU5m4o+1xBKtnUemFVpJ7iVsris3iGE=; b=CLh0nvgqEOHxpimQ7y4i1sn1e7XS4pAxQD6dK9aRr/X7JCOXseatHJct2l+l+RHA726fq3M/LSpx6WyebjPpHpFeNtXWtqs/kEQVEQ6elpy7vtQjYyi+fHEBLQF9y8eCRIEHZPnGkptiR4Lc7G05akGtBl/Zmi7MrIZA+JJ8Suw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=17a23.4f4f8f79.k1203; bh=dtFkK1cIbAKPcU5m4o+1xBKtnUemFVpJ7iVsris3iGE=; b=iabwltqYMBnAVtSLC6Ysk0jh7kvKJ9oyUMi0Z3xk0LRkg42Psd9S2ia0yZtp5LphJrW1KkEzxN/TMN28g5v/mdMmPKx12MJ3AkqUkq6Jvj4mRCagMBfInTAM4bKU6wldg69ZctQLVbJvPPP6WeyNlo1g5XE1BrJuFJUb5vrbvNI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Mar 2012 15:01:55 -0000 Date: 1 Mar 2012 10:02:16 -0500 Message-ID: From: "John R Levine" To: "Tony Finch" In-Reply-To: References: <20120229102255.74fa4291@shane-desktop> <20120229164716.36600.qmail@joyce.lan> <20120301120924.4e8f3d6e@shane-desktop> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:02:26 -0000 > It is also not very useful from the MTA point of view, since the MTA can't > tell if A or AAAA records are missing because they don't exist or there > wasn't enough space in the DNS reply etc. So in most cases (especially an > IPv6 aware MTA getting no AAAA records in reply) the MTA still has to > follow up an MX query with more queries to get address records. Sounds like an AORAAAA record with flag bits would help there, too, so long as the authoritative server returned it in the addition section. The client asks for the MX, and gets the AORAAAA so it doesn't have to do A or AAAA requests separately. Alternate grosse hackque: some way to return an anti-result in the additional section that says there are no records of this type for this name, that can be negative cached. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From ajs@anvilwalrusden.com Thu Mar 1 07:09:55 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF46221E806C for ; Thu, 1 Mar 2012 07:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CSZyxnRgpi9 for ; Thu, 1 Mar 2012 07:09:55 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAB221F8B4A for ; Thu, 1 Mar 2012 07:09:55 -0800 (PST) Received: from mail.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 677D41ECB41C for ; Thu, 1 Mar 2012 15:09:54 +0000 (UTC) Date: Thu, 1 Mar 2012 10:09:49 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20120301150930.GA69334@mail.yitter.info> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <20120228100227.214bb6ef@shane-desktop> <4F4D1F9E.5090003@redbarn.org> <20120229102255.74fa4291@shane-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120229102255.74fa4291@shane-desktop> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:09:56 -0000 On Wed, Feb 29, 2012 at 10:22:55AM +0100, Shane Kerr wrote: > Paul, > > On Tuesday, 2012-02-28 18:40:30 +0000, > Paul Vixie wrote: > > i'd start over with a new port number first. dns wire encoding is > > already wildly complicated. > The main (only?) advantage of doing it with EDNS is that you can work > with existing name servers. It means adding more logic to our already > fabulously complicated resolvers to get full benefit, but nobody ever > said DNS was easy. It seems to me that, from the point of view of "dns-ng" and interoperation with dns, there are three possibilities: 1. End points use dns-ng. 2. End points use dns, but intermediate resolvers do dns-ng. 3. Everyone except authority servers do dns, and the authority server does dns-ng. Your suggestion is, in effect, a way of doing (2). But (3) isn't interesting (if nobody else uses dns-ng, then the authority servers aren't talking to anyone); and (1) is the actual goal we want, I think. If dns-ng is a superset of useful dns functionality, but cleans up certain issues with dns, then the intermediate resolvers in (2) can as easily use a new port as they can use more complicated dns handling. So I have to agree with Paul Vixie: if we're going to work on replacing the protocol, let's replace it for real. (FWIW, I think this is a noble goal doomed to failure. But I've been wrong before. Probably three times just this morning.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From fanf2@hermes.cam.ac.uk Thu Mar 1 07:12:11 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE1721F867D for ; Thu, 1 Mar 2012 07:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7zixF961Fax for ; Thu, 1 Mar 2012 07:12:10 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE5321E806C for ; Thu, 1 Mar 2012 07:12:10 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:37010) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1S37fs-0001ie-DI (Exim 4.72) (return-path ); Thu, 01 Mar 2012 15:12:08 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S37fr-00072e-NY (Exim 4.67) (return-path ); Thu, 01 Mar 2012 15:12:07 +0000 Date: Thu, 1 Mar 2012 15:12:07 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John R Levine In-Reply-To: Message-ID: References: <20120229102255.74fa4291@shane-desktop> <20120229164716.36600.qmail@joyce.lan> <20120301120924.4e8f3d6e@shane-desktop> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:12:11 -0000 John R Levine wrote: > > Sounds like an AORAAAA record with flag bits would help there, too, so long as > the authoritative server returned it in the addition section. The client asks > for the MX, and gets the AORAAAA so it doesn't have to do A or AAAA requests > separately. Doesn't solve the problem, because you can't infer anything about the existence of a record based on it not appearing in an additional section. > Alternate grosse hackque: some way to return an anti-result in the additional > section that says there are no records of this type for this name, that can be > negative cached. That would help. Tony. -- f.anthony.n.finch http://dotat.at/ South-east Iceland: Westerly, backing southerly or southeasterly, 5 to 7, perhaps gale 8 later. Rough or very rough. Wintry showers, occasional rain later. Good, occasionally poor. From johnl@taugh.com Thu Mar 1 08:00:03 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E10921E808C for ; Thu, 1 Mar 2012 08:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddN-swrGfbTy for ; Thu, 1 Mar 2012 08:00:02 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E7BFB21E80C8 for ; Thu, 1 Mar 2012 08:00:01 -0800 (PST) Received: (qmail 24621 invoked from network); 1 Mar 2012 16:00:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=602c.4f4f9d00.k1203; bh=4fftsh5z9Mn9jG3d9tu7spGG/Q0xI6Z7HLiXaKUS1pg=; b=qDJoNia9sQDTKAO6tlBXesBrZUK2xZoqz+33DAR3OHhGJOcmHd3WpO4e9nA4tfdSIqQPlNh8HvClU9NUgU46u5i3q8VRaL8FcZBi51gjfAaQAQkK5vnY/Q1izy4fr5TbZhtHbpIqVQ343RD5HvuuSXP33w2uDIEExKw1HVbveP0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=602c.4f4f9d00.k1203; bh=4fftsh5z9Mn9jG3d9tu7spGG/Q0xI6Z7HLiXaKUS1pg=; b=Q8Ci6QvYRJ0khgrjXv4YMHNE/tgXH8/D7/FHBqeP//50PxiXAfRdbs1YpqYJM6UhUYkpah0AndTlKJOsMQ2XH6zIHMgvaXhblD/Mtpg4dkZKFFRYst5m+vRJJ+TCMB5A9GmhR+uiEjZAHgzFPqRhuK0cFZA2MQVGHn9DJEawjB8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Mar 2012 15:59:37 -0000 Date: 1 Mar 2012 10:59:59 -0500 Message-ID: From: "John R Levine" To: "Nicholas Weaver" In-Reply-To: <453CF72C-6CB5-4015-B35B-EE00E668BD2D@icsi.berkeley.edu> References: <20120229102255.74fa4291@shane-desktop> <20120229164716.36600.qmail@joyce.lan> <20120301120924.4e8f3d6e@shane-desktop> <453CF72C-6CB5-4015-B35B-EE00E668BD2D@icsi.berkeley.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 16:00:03 -0000 > It is the caching of non-asked-for data, be it Auth, Additional, CNAME chains, etc, which enables race-until-win attacks like the Kaminski attack. > > Thus a resolver MUST NEVER cache data that wasn't specifically asked for if it can't DNSSEC validate this information. It can use the additional data received to indicate that it SHOULD ask for the information, but it shouldn't ever cache it in a general context. > > Or, if it does cache it, it should validate that the entry would be valid by performing an independent lookup, a'la Unbound and replace the information with the new version. This makes no sense. Assuming you ignore records for which the server isn't authoritative (which we all do since Kashpureff), why wouldn't you use the records in the additional section? Or to put it another way, if you're worried that the authoritative additional records are fake, why aren't the authoritative answer records equally fake? Same server, same authority. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From nweaver@ICSI.Berkeley.EDU Thu Mar 1 08:10:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB721E807B for ; Thu, 1 Mar 2012 08:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxo4g14YZoY2 for ; Thu, 1 Mar 2012 08:10:30 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id EE69621E806C for ; Thu, 1 Mar 2012 08:10:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id AF1282C4045; Thu, 1 Mar 2012 08:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kL66KyEn1qL8; Thu, 1 Mar 2012 08:10:29 -0800 (PST) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 5FF332C400E; Thu, 1 Mar 2012 08:10:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: Date: Thu, 1 Mar 2012 08:10:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <79ED8ED4-2921-4432-8749-A67CCE283C99@ICSI.Berkeley.EDU> References: <20120229102255.74fa4291@shane-desktop> <20120229164716.36600.qmail@joyce.lan> <20120301120924.4e8f3d6e@shane-desktop> <453CF72C-6CB5-4015-B35B-EE00E668BD2D@icsi.berkeley.edu> To: "John R Levine" X-Mailer: Apple Mail (2.1257) Cc: dnsop@ietf.org, Nicholas Weaver Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 16:10:31 -0000 On Mar 1, 2012, at 7:59 AM, John R Levine wrote: >> It is the caching of non-asked-for data, be it Auth, Additional, = CNAME chains, etc, which enables race-until-win attacks like the = Kaminski attack. >>=20 >> Thus a resolver MUST NEVER cache data that wasn't specifically asked = for if it can't DNSSEC validate this information. It can use the = additional data received to indicate that it SHOULD ask for the = information, but it shouldn't ever cache it in a general context. >>=20 >> Or, if it does cache it, it should validate that the entry would be = valid by performing an independent lookup, a'la Unbound and replace the = information with the new version. >=20 > This makes no sense. Assuming you ignore records for which the server = isn't authoritative (which we all do since Kashpureff), why wouldn't you = use the records in the additional section? >=20 > Or to put it another way, if you're worried that the authoritative = additional records are fake, why aren't the authoritative answer records = equally fake? Same server, same authority. Because caching un-asked-for records is what allows "race until win": = the ability of an attacker implementing blind cache poisoning to keep = retrying the attack until successful. If only the requested information is cached, an attacker targeting = "www.victim.com" can only try to poison once per TTL, because after = that, the resolver doesn't generate queries. But if ANY sort of authoritatitive or additional information is cached = unasked-for and unverified with a second request (INCLUDING the NS RRSET = from the authoritative field), the attacker can start with = "1.victim.com", with the additional information containing the poisoned = record for "www.victim.com". If success? Great. If failure? Retry = with "2.victim.com" and so-on. Even with halfway-decent port randomization, Race Until Win can be a = problem: Poison the NS entry for .com on a major resolver using your = botnet and, ohh, boy, can an attacker have some fun. From johnl@taugh.com Thu Mar 1 08:13:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE0A21E806C for ; Thu, 1 Mar 2012 08:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gjg9prI7Xfpt for ; Thu, 1 Mar 2012 08:13:19 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CA9EF21F8B70 for ; Thu, 1 Mar 2012 08:13:17 -0800 (PST) Received: (qmail 29499 invoked from network); 1 Mar 2012 16:13:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=733a.4f4fa01d.k1203; bh=BZZiYMtplkI63stBHU9vVlb9vd+Wv7WrZmRYYMxON30=; b=b7hEPws7luY50IUqr2/aDBrVqnHZ4o68L8CW02Mxy1iXzq4ZncVhslJuZLyo7ZZNn9r36cITzD8b8SeZpsUBbD3Qklmj+h0XSK/aHZbPIYbxr1ovg7VSOEbELWd94i3PuTXXlwgf6iFzK6Al0kaTVhgD+d2jnGSqMBKRCh5Wm9s= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=733a.4f4fa01d.k1203; bh=BZZiYMtplkI63stBHU9vVlb9vd+Wv7WrZmRYYMxON30=; b=h+MrrXqV8N0ZjmijRZpj+7dKvG4YsEZBdZwWpTz0PeQ1hAn22F6EfjMpAcFEfFUW9pzoHTAw7aySGQhkHvmHma0sGfmIsM4BbMX2Ecpk9QijUJ4WaE3YDS/lOGcX7jIeGab3gL4pbVQpGappjJ88eRDqvMxr9Q51MqyX6JazcEk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Mar 2012 16:12:55 -0000 Date: 1 Mar 2012 11:13:16 -0500 Message-ID: From: "John R Levine" To: "Tony Finch" In-Reply-To: References: <20120229102255.74fa4291@shane-desktop> <20120229164716.36600.qmail@joyce.lan> <20120301120924.4e8f3d6e@shane-desktop> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 16:13:20 -0000 >> Sounds like an AORAAAA record with flag bits would help there, too, so long as >> the authoritative server returned it in the addition section. The client asks >> for the MX, and gets the AORAAAA so it doesn't have to do A or AAAA requests >> separately. > > Doesn't solve the problem, because you can't infer anything about the > existence of a record based on it not appearing in an additional section. > >> Alternate grosse hackque: some way to return an anti-result in the additional >> section that says there are no records of this type for this name, that can be >> negative cached. New improved hackque: the AORAAAA record contains two fields, which contain the number of A and AAAA records at that name. The server tries to put the A and AAAA records in the additional section, if the number of A or AAAA records is less than the count, the client knows they were truncated and has to ask for them explicitly, but in most cases won't. The cache is allowed to synthesize a NODATA answer for A or AAAA if the AORAAAA value was zero, although I admit that the interaction with DNSSEC could be unpleasant. Of course, the NSEC record also tells you what kind of records are present at a name, so it can equally well synthesize NODATA from that. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From eosterweil@verisign.com Fri Mar 2 09:56:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA1B21E802D for ; Fri, 2 Mar 2012 09:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va0UiItnBpwO for ; Fri, 2 Mar 2012 09:56:51 -0800 (PST) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id AA4CF21E8034 for ; Fri, 2 Mar 2012 09:56:50 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP ID DSNKT1EJ4jXf9uweXEQrOX1YbGuTOxThXEkj@postini.com; Fri, 02 Mar 2012 09:56:50 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q22Hukjo018209 for ; Fri, 2 Mar 2012 12:56:49 -0500 Received: from [10.100.0.216] ([10.100.0.216]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 12:56:45 -0500 From: Eric Osterweil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 09:56:40 -0800 References: <20120223155730.20754.45643.idtracker@ietfa.amsl.com> To: dnsop@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 02 Mar 2012 17:56:45.0976 (UTC) FILETIME=[D557D980:01CCF89D] Subject: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 17:56:51 -0000 Hey everyone, We have resurrected our draft Improving DNS Service Availability by = Using Long TTL Values, and added some new polish to it. We've taken = some feedback from various people and would love to hear any thoughts = other people have. Thanks! Eric Begin forwarded message: > From: internet-drafts@ietf.org > Date: February 23, 2012 7:57:30 AM PST > To: i-d-announce@ietf.org > Subject: I-D Action: draft-pappas-dnsop-long-ttl-04.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Improving DNS Service Availability by Using = Long TTL Values > Author(s) : Vasileios Pappas > Eric Osterweil > Filename : draft-pappas-dnsop-long-ttl-04.txt > Pages : 17 > Date : 2012-02-23 >=20 > Due to the hierarchical tree structure of the Domain Name System > [RFC1034][RFC1035], losing all of the authoritative servers that > serve a zone can disrupt services to not only that zone but all of > its descendants. This problem is particularly severe if all the > authoritative servers of the root zone, or of a top level domain's > zone, fail. Although proper placement of secondary servers, as > discussed in [RFC2182], can be an effective means against isolated > failures, it is insufficient to protect the DNS service against a > Distributed Denial of Service (DDoS) attack. This document proposes > to reduce the impact of DDoS attacks against top level DNS servers = by > setting long TTL values for NS records and their associated A and > AAAA records. Our proposed changes are purely operational and can = be > deployed incrementally. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From mellon@fugue.com Mon Mar 5 15:39:37 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325B721F8664; Mon, 5 Mar 2012 15:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7zVoYO7iZNK; Mon, 5 Mar 2012 15:39:36 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 00CF321F85A0; Mon, 5 Mar 2012 15:39:36 -0800 (PST) Received: from [IPv6:2001:470:1f07:1486:3912:d05:2bd3:9497] (unknown [IPv6:2001:470:1f07:1486:3912:d05:2bd3:9497]) by toccata.fugue.com (Postfix) with ESMTPSA id 325662382178; Mon, 5 Mar 2012 18:39:33 -0500 (EST) From: Ted Lemon Content-Type: multipart/alternative; boundary="Apple-Mail=_34A1AE4E-28CA-48A1-A1E0-181B0B5CF1A4" Date: Mon, 5 Mar 2012 18:39:32 -0500 References: <20120305231736.20673.74948.idtracker@ietfa.amsl.com> To: " WG" , "dnsop@ietf.org WG" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) X-Mailer: Apple Mail (2.1426) X-Mailman-Approved-At: Tue, 06 Mar 2012 09:21:33 -0800 Subject: [DNSOP] Fwd: I-D Action: draft-lemon-dhc-dns-pd-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:39:37 -0000 --Apple-Mail=_34A1AE4E-28CA-48A1-A1E0-181B0B5CF1A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I just submitted a draft that talks about mechanisms for populating the = reverse tree for prefixes delegated using RFC3633. It's not complete = (I haven't documented the format of the options, for instance), but it = walks through all the scenarios that I think are relevant and (I think) = completely specifies how the requesting router and delegating router = should interact. The document takes no position on whether populating the reverse tree is = a good idea; rather, it provides mechanisms for service providers and = site administrators to populate the reverse tree if they choose to, or = request that it not be populated if they prefer. I think we got bogged down in the discussion of whether the reverse tree = should be populated or not, which is an interesting discussion, and so a = lot of what's in the document probably got talked about in the dnsop = working group, but I don't think anyone ever wrote it down in a draft. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-lemon-dhc-dns-pd-00.txt > Date: March 5, 2012 6:17:36 PM EST > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Populating the DNS Reverse Tree for DHCP = Delegated Prefixes > Author(s) : Ted Lemon > Filename : draft-lemon-dhc-dns-pd-00.txt > Pages : 18 > Date : 2012-03-05 >=20 > This document describes three alternatives for populating the DNS > reverse tree for prefixes delegated using DHCP, and provides > mechanisms for implementing each alternative. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lemon-dhc-dns-pd-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-lemon-dhc-dns-pd-00.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_34A1AE4E-28CA-48A1-A1E0-181B0B5CF1A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = just submitted a draft that talks about mechanisms for populating the = reverse tree for prefixes delegated using RFC3633.   It's not = complete (I haven't documented the format of the options, for instance), = but it walks through all the scenarios that I think are relevant and (I = think) completely specifies how the requesting router and delegating = router should interact.

The document takes no = position on whether populating the reverse tree is a good idea; rather, = it provides mechanisms for service providers and site administrators to = populate the reverse tree if they choose to, or request that it not be = populated if they prefer.

I think we got bogged = down in the discussion of whether the reverse tree should be populated = or not, which is an interesting discussion, and so a lot of what's in = the document probably got talked about in the dnsop working group, but I = don't think anyone ever wrote it down in a draft.

Begin = forwarded message:

Subject: I-D Action: = draft-lemon-dhc-dns-pd-00.txt
Date: March 5, 2012 = 6:17:36 PM EST
Reply-To: = internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.

Title =           : Populating = the DNS Reverse Tree for DHCP Delegated Prefixes
Author(s) =       : Ted Lemon
Filename =        : = draft-lemon-dhc-dns-pd-00.txt
Pages =           : = 18
= Date =            : = 2012-03-05

  This document describes three = alternatives for populating the DNS
  reverse tree for = prefixes delegated using DHCP, and provides
  mechanisms = for implementing each alternative.


A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lemon-dhc-dns-pd-00.txt
=
Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft = can be retrieved = at:
ftp://ftp.ietf.org/internet-drafts/draft-lemon-dhc-dns-pd-00.txt
_______________________________________________
I-D-Announce = mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=
= --Apple-Mail=_34A1AE4E-28CA-48A1-A1E0-181B0B5CF1A4-- From eosterweil@verisign.com Wed Mar 7 15:06:36 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48EE21F858B for ; Wed, 7 Mar 2012 15:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhTIsdnTOQo8 for ; Wed, 7 Mar 2012 15:06:36 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id B862921F84F3 for ; Wed, 7 Mar 2012 15:06:35 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKT1fp++tToP0aSCMqlbqe8Dk7W1misVrJ@postini.com; Wed, 07 Mar 2012 15:06:35 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q27N6VUS022230 for ; Wed, 7 Mar 2012 18:06:34 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 18:06:30 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Eric Osterweil In-Reply-To: Date: Wed, 7 Mar 2012 18:06:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120223155730.20754.45643.idtracker@ietfa.amsl.com> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 07 Mar 2012 23:06:30.0935 (UTC) FILETIME=[EEE84A70:01CCFCB6] Subject: Re: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 23:06:36 -0000 Hey list, So far, we have not gotten a huge amount of feedback on this draft (but = thank you _very_much_ to those that have responded). I think we were = really hoping that people could take a look at the draft and comment = before Paris. It focuses on how resolvers that query large TLD = registries can maintain connectivity during sustained outages at the = root (such as from DDoS attacks). While it may seem topical to some, we = were hoping that some of the distinctions and practices in this draft = would be useful in general (such as the distinction of Infrastructure RR = types). We would all very much appreciate any feedback from the list, thanks! Eric On Mar 2, 2012, at 12:56 PM, Eric Osterweil wrote: > Hey everyone, >=20 > We have resurrected our draft Improving DNS Service Availability by = Using Long TTL Values, and added some new polish to it. We've taken = some feedback from various people and would love to hear any thoughts = other people have. >=20 > Thanks! >=20 > Eric >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: February 23, 2012 7:57:30 AM PST >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-pappas-dnsop-long-ttl-04.txt >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >> Title : Improving DNS Service Availability by Using = Long TTL Values >> Author(s) : Vasileios Pappas >> Eric Osterweil >> Filename : draft-pappas-dnsop-long-ttl-04.txt >> Pages : 17 >> Date : 2012-02-23 >>=20 >> Due to the hierarchical tree structure of the Domain Name System >> [RFC1034][RFC1035], losing all of the authoritative servers that >> serve a zone can disrupt services to not only that zone but all of >> its descendants. This problem is particularly severe if all the >> authoritative servers of the root zone, or of a top level domain's >> zone, fail. Although proper placement of secondary servers, as >> discussed in [RFC2182], can be an effective means against isolated >> failures, it is insufficient to protect the DNS service against a >> Distributed Denial of Service (DDoS) attack. This document proposes >> to reduce the impact of DDoS attacks against top level DNS servers = by >> setting long TTL values for NS records and their associated A and >> AAAA records. Our proposed changes are purely operational and can = be >> deployed incrementally. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From hsantos@isdg.net Wed Mar 7 15:26:02 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971D111E808A for ; Wed, 7 Mar 2012 15:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhNIrpHdZYv8 for ; Wed, 7 Mar 2012 15:26:01 -0800 (PST) Received: from dkim.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3780811E8072 for ; Wed, 7 Mar 2012 15:26:01 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4218; t=1331162750; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Pab/M+ye1AV9lT82F+Cqrc914jc=; b=Iotoj7Cw/S/uz8qrvFpk L64VPoQ64rH2brrE3SriN6+YJfOr+BHiUfIn5hJDOKDSI3jBOGE/BfZZ2W5jbhTT S2FXVlyGefcQwbKjXtC4MOPoKmsDGeLLjfixEdcT5uguoaw0Ha0HMrHfdZyHBc1M qLuBO6+rV0USyRlQvsGsC9g= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for dnsop@ietf.org; Wed, 07 Mar 2012 18:25:50 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 69613298.12682.4760; Wed, 07 Mar 2012 18:25:49 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4218; t=1331162485; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6Ftjuye kFF0FKZvV7QqPhFIF8KoSzSc22d6IKiPlOLI=; b=gHCce3c46xBlptVCpKPq6qU paecjDdCSupX8vEqschglSVaUycB8Usm+Se7+x/BDKoRp8xjm77TnZgbpPtnKQ1f JhBoqlgPlWfPXOi6N0sGTa9E35RE6HxbrXlbURKoWEHX6P0w17zG1Ck2ZXbfNs5c x2Wu0ylGcyG18MURFTFA= Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for dnsop@ietf.org; Wed, 07 Mar 2012 18:21:25 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 668541002.25136.2652; Wed, 07 Mar 2012 18:21:24 -0500 Message-ID: <4F57EEC1.5010208@isdg.net> Date: Wed, 07 Mar 2012 18:26:57 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eric Osterweil References: <20120223155730.20754.45643.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 23:26:02 -0000 Hi Eric, the only thing that came to mind was that we already have recommended TTL values and yet, it is highly abused with short values. I did not read the draft yet, but does it touch base with how to control it or enforce a longer TTL? I say that based on a last year project to single source our DNS resolver for an integrated system that was beginning to expand using different DNS resolvers and APIs and there was a growth of query duplicity with different caching, including round robin or lack there of. TTL/Caching was its anchor for reissuing queries to optimize it and one of the immediate highlight was the huge amount of low TTLs. What does disseminate or discriminate these? -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Eric Osterweil wrote: > Hey list, > > So far, we have not gotten a huge amount of feedback on this draft (but thank you _very_much_ to those that have responded). I think we were really hoping that people could take a look at the draft and comment before Paris. It focuses on how resolvers that query large TLD registries can maintain connectivity during sustained outages at the root (such as from DDoS attacks). While it may seem topical to some, we were hoping that some of the distinctions and practices in this draft would be useful in general (such as the distinction of Infrastructure RR types). > > We would all very much appreciate any feedback from the list, thanks! > > Eric > > On Mar 2, 2012, at 12:56 PM, Eric Osterweil wrote: > >> Hey everyone, >> >> We have resurrected our draft Improving DNS Service Availability by Using Long TTL Values, and added some new polish to it. We've taken some feedback from various people and would love to hear any thoughts other people have. >> >> Thanks! >> >> Eric >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Date: February 23, 2012 7:57:30 AM PST >>> To: i-d-announce@ietf.org >>> Subject: I-D Action: draft-pappas-dnsop-long-ttl-04.txt >>> Reply-To: internet-drafts@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> Title : Improving DNS Service Availability by Using Long TTL Values >>> Author(s) : Vasileios Pappas >>> Eric Osterweil >>> Filename : draft-pappas-dnsop-long-ttl-04.txt >>> Pages : 17 >>> Date : 2012-02-23 >>> >>> Due to the hierarchical tree structure of the Domain Name System >>> [RFC1034][RFC1035], losing all of the authoritative servers that >>> serve a zone can disrupt services to not only that zone but all of >>> its descendants. This problem is particularly severe if all the >>> authoritative servers of the root zone, or of a top level domain's >>> zone, fail. Although proper placement of secondary servers, as >>> discussed in [RFC2182], can be an effective means against isolated >>> failures, it is insufficient to protect the DNS service against a >>> Distributed Denial of Service (DDoS) attack. This document proposes >>> to reduce the impact of DDoS attacks against top level DNS servers by >>> setting long TTL values for NS records and their associated A and >>> AAAA records. Our proposed changes are purely operational and can be >>> deployed incrementally. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > From internet-drafts@ietf.org Thu Mar 8 01:14:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFDD21F8547; Thu, 8 Mar 2012 01:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohjq2IH7OW6g; Thu, 8 Mar 2012 01:14:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0042C21F8681; Thu, 8 Mar 2012 01:14:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308091405.4616.98708.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 01:14:05 -0800 Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-dps-framework-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 09:14:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Domain Name System Operations Working= Group of the IETF. Title : DNSSEC Policy & Practice Statement Framework Author(s) : Fredrik Ljunggren Anne-Marie Eklund Lowinder Tomofumi Okubo Filename : draft-ietf-dnsop-dnssec-dps-framework-07.txt Pages : 28 Date : 2012-03-08 This document presents a framework to assist writers of DNSSEC Policy and Practice Statements such as Domain Managers and Zone Operators on both the top-level and secondary level, who is managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-dps-framework-0= 7.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-dps-framework-07= .txt From fredrik@kirei.se Thu Mar 8 01:23:00 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9321F8698 for ; Thu, 8 Mar 2012 01:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxysJR6NqIck for ; Thu, 8 Mar 2012 01:23:00 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 63F4521F869F for ; Thu, 8 Mar 2012 01:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=tq7pVvSNa9u8p/mP+VvocCfx6K4N5fEsmytuoTcFWvQ=; b=pNrYMmx/8y2vZ/14RoZfrerzWIoHiBd30bAjyrBfDXneDfn6lc1Fm0fyeOW+EjFZiWDdaghgqhk2g maW/CI7z5856uh7tXTu+bw2HmufbZGSybnlgNIpn8SgScLsZSp3EPmrWAxV0wWijsmNqA2SgdHuhvh JICCjb2e/xU73DzE= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Thu, 8 Mar 2012 10:22:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Fredrik Ljunggren In-Reply-To: <20120308091405.4616.98708.idtracker@ietfa.amsl.com> Date: Thu, 8 Mar 2012 10:23:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120308091405.4616.98708.idtracker@ietfa.amsl.com> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-dps-framework-07.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 09:23:01 -0000 Dear WG, We've made a rapid update of the -06 version, including a new set of = fixed nits and some rewordings in section 4.2.=20 best regards, -- Fredrik On 2012-03-08, at 10:14, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Domain Name System = Operations Working Group of the IETF. >=20 > Title : DNSSEC Policy & Practice Statement Framework > Author(s) : Fredrik Ljunggren > Anne-Marie Eklund Lowinder > Tomofumi Okubo > Filename : draft-ietf-dnsop-dnssec-dps-framework-07.txt > Pages : 28 > Date : 2012-03-08 >=20 > This document presents a framework to assist writers of DNSSEC = Policy > and Practice Statements such as Domain Managers and Zone Operators = on > both the top-level and secondary level, who is managing and = operating > a DNS zone with Security Extensions (DNSSEC) implemented. >=20 > In particular, the framework provides a comprehensive list of topics > that should be considered for inclusion into a DNSSEC Policy > definition and Practice Statement. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-dps-framework-= 07.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-dnssec-dps-framework-0= 7.txt >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From shane@isc.org Thu Mar 8 02:42:13 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34C821F8546 for ; Thu, 8 Mar 2012 02:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKUYuieXu8Sn for ; Thu, 8 Mar 2012 02:42:13 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D510E21F8537 for ; Thu, 8 Mar 2012 02:42:12 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id D51FCC9422; Thu, 8 Mar 2012 10:42:00 +0000 (UTC) (envelope-from shane@isc.org) Received: from shane-desktop (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E5A1E216C33; Thu, 8 Mar 2012 10:41:59 +0000 (UTC) (envelope-from shane@isc.org) Date: Thu, 8 Mar 2012 11:41:49 +0100 From: Shane Kerr To: Ray Bellis Message-ID: <20120308114149.02a0f5a7@shane-desktop> In-Reply-To: <638707AE-5E70-43E5-921C-2F62496F7A73@nominet.org.uk> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <20120228100227.214bb6ef@shane-desktop> <4F4D1F9E.5090003@redbarn.org> <638707AE-5E70-43E5-921C-2F62496F7A73@nominet.org.uk> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 10:42:13 -0000 Ray, On Wednesday, 2012-02-29 10:17:26 +0000, Ray Bellis wrote: > > On 28 Feb 2012, at 18:40, Paul Vixie wrote: > > if the EDNS option for this just had an array of additional QTYPE, > such that the real QNAME and QCLASS pertained to all of these > additional questions, then i could definitely see value in this. the > response's OPT option would include the list of qtypes which were > found to be non-empty. all of the rrsets would be in the answer > section. > > > Yes, that's pretty much what was in the draft I wrote (but didn't > publish) and discussed with you during the last Prague IETF. > > My rationale likewise was that having constant QNAME and QCLASS but > multiple QTYPEs should eliminate the need for multiple RCODEs. > > However further discussion with other folks revealed issues (ISTR > around DNSSEC?) where it would be possible to get inconsistent RCODEs > for different QTYPEs. > > I've attached a copy of that document. It could be resurrected if > there's sufficient interest. It looks reasonable to me. I'd support it moving forward. An additional document that would complete the picture would be describing recommended client & resolver behavior. In the case of a stub resolver, this would simply be trying a query to probe for support on the resolver, perhaps keeping this information for a limited period of time. In the case of a recursive resolver, then when a client query is received that: 1. does not contain the EDNS0 option asking for multiple types, and 2. is for a RR type that usually involves a separate query for a related RR type Then the resolver could add on the EDNS0 option when it tries to resolve the name. That way the resolver could group A and AAAA queries, or MX and A queries, or whatever, based on what users usually want. If a subsequent query comes in while this is in process, then the resolver is already busy looking up. In order for this to work most effectively, the resolvers will need to remember which authoritative servers support the EDNS0 option, so they can break down queries with the option sent from clients if the server does not support it. For lowest latency, probably the default should be to assume that authoritative servers do not support the option. Perhaps it makes sense to provide the server with a way to specify how long it makes sense for a stub resolver or recursive resolver to cache information about it (there is a lot of this kind of information, not only this particular EDNS0 option). -- Shane From eosterweil@verisign.com Thu Mar 8 07:25:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744D621F8584 for ; Thu, 8 Mar 2012 07:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3-wiL-HM6+k for ; Thu, 8 Mar 2012 07:25:05 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id AB43D21F856F for ; Thu, 8 Mar 2012 07:25:04 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKT1jPTrn0fjnN655b9taKblBjiEE5CpUc@postini.com; Thu, 08 Mar 2012 07:25:04 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q28FOv2w021176; Thu, 8 Mar 2012 10:25:01 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 10:24:57 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <4F57EEC1.5010208@isdg.net> Date: Thu, 8 Mar 2012 10:24:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120223155730.20754.45643.idtracker@ietfa.amsl.com> <4F57EEC1.5010208@isdg.net> To: Hector Santos X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 Mar 2012 15:24:57.0092 (UTC) FILETIME=[9E80F440:01CCFD3F] Cc: dnsop@ietf.org Subject: Re: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 15:25:07 -0000 Hey Hector, Thanks for the comments, I've tried to address them inline: On Mar 7, 2012, at 6:26 PM, Hector Santos wrote: > Hi Eric, the only thing that came to mind was that we already have = recommended TTL values and yet, it is highly abused with short values. = I did not read the draft yet, but does it touch base with how to control = it or enforce a longer TTL? Rather than place an enforcement tone on the problem, the analysis is = based on observing the benefits that a zone (and its resolver clients) = get from acting this way. It doesn't propose that any zone must follow = this behavior, but says that if large zones consider their = Infrastructure RRs as different than the rest, and want to survive = large/sustained DDoS attacks, this is a simple practice that can = measurably help. Moreover, since no new protocol behavior is even being = attempted, it doesn't require anyone to follow this approach. It simply = evaluates the benefits for anyone who does it. >=20 > I say that based on a last year project to single source our DNS = resolver for an integrated system that was beginning to expand using = different DNS resolvers and APIs and there was a growth of query = duplicity with different caching, including round robin or lack there = of. >=20 > TTL/Caching was its anchor for reissuing queries to optimize it and = one of the immediate highlight was the huge amount of low TTLs. What = does disseminate or discriminate these? >=20 My guess, though I could quite likely be wrong, is that tackling the = idea of TTLs on non-Infrastructure RRs might cause various people to = come up with different reasons to be contrary. I admit that I could be = off base, as I'm not familiar with this project you mentioned. Does that make sense? Eric > --=20 > Hector Santos, CTO > http://www.santronics.com > http://santronics.blogspot.com >=20 > Eric Osterweil wrote: >> Hey list, >> So far, we have not gotten a huge amount of feedback on this draft = (but thank you _very_much_ to those that have responded). I think we = were really hoping that people could take a look at the draft and = comment before Paris. It focuses on how resolvers that query large TLD = registries can maintain connectivity during sustained outages at the = root (such as from DDoS attacks). While it may seem topical to some, we = were hoping that some of the distinctions and practices in this draft = would be useful in general (such as the distinction of Infrastructure RR = types). >> We would all very much appreciate any feedback from the list, thanks! >> Eric >> On Mar 2, 2012, at 12:56 PM, Eric Osterweil wrote: >>> Hey everyone, >>>=20 >>> We have resurrected our draft Improving DNS Service Availability by = Using Long TTL Values, and added some new polish to it. We've taken = some feedback from various people and would love to hear any thoughts = other people have. >>>=20 >>> Thanks! >>>=20 >>> Eric >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Date: February 23, 2012 7:57:30 AM PST >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action: draft-pappas-dnsop-long-ttl-04.txt >>>> Reply-To: internet-drafts@ietf.org >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>=20 >>>> Title : Improving DNS Service Availability by Using = Long TTL Values >>>> Author(s) : Vasileios Pappas >>>> Eric Osterweil >>>> Filename : draft-pappas-dnsop-long-ttl-04.txt >>>> Pages : 17 >>>> Date : 2012-02-23 >>>>=20 >>>> Due to the hierarchical tree structure of the Domain Name System >>>> [RFC1034][RFC1035], losing all of the authoritative servers that >>>> serve a zone can disrupt services to not only that zone but all of >>>> its descendants. This problem is particularly severe if all the >>>> authoritative servers of the root zone, or of a top level domain's >>>> zone, fail. Although proper placement of secondary servers, as >>>> discussed in [RFC2182], can be an effective means against isolated >>>> failures, it is insufficient to protect the DNS service against a >>>> Distributed Denial of Service (DDoS) attack. This document = proposes >>>> to reduce the impact of DDoS attacks against top level DNS servers = by >>>> setting long TTL values for NS records and their associated A and >>>> AAAA records. Our proposed changes are purely operational and can = be >>>> deployed incrementally. >>>>=20 >>>>=20 >>>> A URL for this Internet-Draft is: >>>> = http://www.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> This Internet-Draft can be retrieved at: >>>> = ftp://ftp.ietf.org/internet-drafts/draft-pappas-dnsop-long-ttl-04.txt >>>>=20 >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 >=20 >=20 From Joe.Gersch@Secure64.com Thu Mar 8 08:16:00 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D748A21F8639 for ; Thu, 8 Mar 2012 08:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVx9BxpOiOHE for ; Thu, 8 Mar 2012 08:16:00 -0800 (PST) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4705F21F8555 for ; Thu, 8 Mar 2012 08:16:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 1088BB84BD for ; Thu, 8 Mar 2012 09:16:00 -0700 (MST) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na83KAzRPXCb; Thu, 8 Mar 2012 09:15:59 -0700 (MST) Received: from [10.138.15.14] (unknown [192.168.254.4]) by zimbra.secure64.com (Postfix) with ESMTPSA id 1B118B84B6 for ; Thu, 8 Mar 2012 09:15:59 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1331223359; bh=qvWrGmAWaqbD7q/c7FW7EPxzU2voprR76ywAriAZY9w=; h=From:Content-Type:Subject:Date:Message-Id:To:Mime-Version; b=aRS+ n0rj2bVlNfVXEOqeYuPiWFyo4YG2yAnOm7MVQnDzGG9izUSodfoY5ElIKYZiBfdGObn h5OML5OnP2vb/yHUxGqKlC+kAJ9zBj1TCt2vZOrfxPHMHNwTGP9zMN0KI2S9daa9N67 UnD41hVVb8C+7iGiA3gX7NhVM4gnOt/0M= From: Joseph Gersch Content-Type: multipart/alternative; boundary="Apple-Mail=_D9A9F525-6679-4EDB-9198-AB69392FD6C8" Date: Thu, 8 Mar 2012 09:15:57 -0700 Message-Id: <5E9B2EA9-FE35-49DA-9FB4-9D80A310D5CC@Secure64.com> To: dnsop@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [DNSOP] 2 internet drafts relevant to DNSOP X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:16:01 -0000 --Apple-Mail=_D9A9F525-6679-4EDB-9198-AB69392FD6C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii DNSOP members, We have recently submitted two internet drafts for review at the = Paris IETF meeting. =20 The first document, "draft-gersch-dnsop-revdns-cidr-01" describes a = reverse-DNS naming method to specify CIDR address blocks. We will be = presenting this proposal, its motivation and its purpose at the DNSOP = session on Friday, March 30. The second document, "draft-gersch-grow-revdns-bgp-00" was also = submitted. It describes two new DNS record types that can be used to = specify BGP route origins in the reverse DNS. It uses the domain naming = method described earlier. We will be presenting this at the GROW = session on Friday, March 30, and possibly at the SIDR session on = Wednesday, March 28 as well. Although one of the drafts was submitted to GROW, the documents = propose a DNS naming convention and new DNS record types that could = benefit from the expert review by the members in DNSEXT and DNSOP. We = encourage you to review these internet drafts and to submit comments to = the DNSOP mailing list. =20 If you want to know more about the use of the names and record types, = a live testbed is available at the web site "rover.secure64.com". This = web site contains various documents and slide sets explaining the BGP = publishing and verification methods, as well as the testbed itself with = over 390,000 routes published in an in-addr.arpa shadow zone. You can = submit your own BGP data into the shadow zones if you wish. The web = site also lets you perform queries to verify the origin authenticity of = a BGP announcement. If anyone wants a demo of the testbed during the IETF week, we will be = happy to show how it works; or you can simply create an account and try = it out for yourself at any time. Thanks, Joseph Gersch Dan Massey Eric Osterweil Lixia Zhang --Apple-Mail=_D9A9F525-6679-4EDB-9198-AB69392FD6C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
DNSOP members,

   We = have recently submitted two internet drafts for review at the Paris IETF = meeting.  

   The first document, = "draft-gersch-dnsop-revdns-cidr-01" describes a reverse-DNS naming = method to specify CIDR address blocks.  We will be presenting this = proposal, its motivation and its purpose at the DNSOP session on Friday, = March 30.

  The second document, = "draft-gersch-grow-revdns-bgp-00" was also submitted.  It describes = two new DNS record types that can be used to specify BGP route origins = in the reverse DNS.  It uses the domain naming method described = earlier.   We will be presenting this at the GROW session on = Friday, March 30, and possibly at the SIDR session on Wednesday, March = 28 as well.

  Although one of the drafts was submitted = to GROW, the documents propose a DNS naming convention and new DNS = record types that could benefit from the expert review by the members in = DNSEXT and DNSOP.  We encourage you to review these internet drafts =  and to submit comments to the DNSOP mailing list. =  

  If you want to know more about the use of the = names and record types, a live testbed is available at the web site "rover.secure64.com".  This = web site contains various documents and slide sets explaining the BGP = publishing and verification methods, as well as the testbed itself with = over 390,000 routes published in an in-addr.arpa shadow zone.  You = can submit your own BGP data into the shadow zones if you wish. =   The web site also lets you perform queries to verify the = origin authenticity of a BGP announcement.
If anyone wants a demo of = the testbed during the IETF week, we will be happy to show how it works; = or you can simply create an account and try it out for yourself at any = time.

 Thanks,

Joseph Gersch
Dan Massey
Eric = Osterweil
Lixia Zhang

= --Apple-Mail=_D9A9F525-6679-4EDB-9198-AB69392FD6C8-- From paul@redbarn.org Sat Mar 10 08:28:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED8121F8658 for ; Sat, 10 Mar 2012 08:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G80M6ZUijRuz for ; Sat, 10 Mar 2012 08:28:21 -0800 (PST) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9171721F8655 for ; Sat, 10 Mar 2012 08:28:21 -0800 (PST) Received: from [198.18.136.198] (unknown [201.204.76.162]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id E5C07EDAE6; Sat, 10 Mar 2012 16:28:19 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F5B811E.9050602@redbarn.org> Date: Sat, 10 Mar 2012 16:28:14 +0000 From: paul vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Joseph Gersch References: <5E9B2EA9-FE35-49DA-9FB4-9D80A310D5CC@Secure64.com> In-Reply-To: <5E9B2EA9-FE35-49DA-9FB4-9D80A310D5CC@Secure64.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] 2 internet drafts relevant to DNSOP X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 16:28:28 -0000 joe, et al, your draft-gersch-dnsop-revdns-cidr-01 is very clean and simple; the draft and the design are of admirable quality. as a co-author of RFC 2317 i agree that it does not suit the needs of bgp security since it seeks only to provide a method of fully naming hosts, not networks. importantly, i see no reference to RFC 1101 in your draft. RFC 1101 describes a way to name networks, and while at first it did not seem to be compatible with CIDR, implementation (in "netstat -r" back in BSD/OS 3.1) showed that RFC 1101 was in fact not as classful as it appeared. i recommend a review of these functions, contained in the file dns_nw.c, present in bind8 as src/lib/irs/dns_nw.c, and also present in older versions of bind9, as well as various versions of netbsd and athena. static struct nwent * get1101byaddr(struct irs_nw *, u_char *, int); static struct nwent * get1101byname(struct irs_nw *, const char *); static struct nwent * get1101answer(struct irs_nw *, u_char *ansbuf, int anslen, enum by_what by_what, int af, const char *name, const u_char *addr, int addrlen); static struct nwent * get1101mask(struct irs_nw *this, struct nwent *); static int make1101inaddr(const u_char *, int, char *, int); you may find that some of your work has already been done for you, or, you may find that this is related work that should be referenced in your draft along with the reasons why your proposed method is necessary. paul From bortzmeyer@nic.fr Tue Mar 13 08:21:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C897F21F8961 for ; Tue, 13 Mar 2012 08:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVezSOEcBJgN for ; Tue, 13 Mar 2012 08:21:27 -0700 (PDT) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29A21F8960 for ; Tue, 13 Mar 2012 08:21:27 -0700 (PDT) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id CB87B1C0109; Tue, 13 Mar 2012 16:21:23 +0100 (CET) Received: by mx2.nic.fr (Postfix, from userid 500) id AF21A1C010E; Tue, 13 Mar 2012 16:21:21 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [IPv6:2001:67c:2218:9::4:163]) by mx2.nic.fr (Postfix) with ESMTP id 9CD1A1C0109; Tue, 13 Mar 2012 16:21:21 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id 9B262B38055; Tue, 13 Mar 2012 16:21:21 +0100 (CET) Date: Tue, 13 Mar 2012 16:21:21 +0100 From: Stephane Bortzmeyer To: Eric Osterweil Message-ID: <20120313152121.GA10495@nic.fr> References: <20120223155730.20754.45643.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.1.0-1-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: No, tests=bogofilter, spamicity=0.000002, version=1.1.5 X-PMX-Version: 5.4.6.353000, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2012.3.13.151224 X-PerlMx-Spam: Gauge=IIIIIII, Probability=8%, Report='HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_700_799 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CD 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __USER_AGENT 0' Cc: dnsop@ietf.org Subject: Re: [DNSOP] Fwd: I-D Action: draft-pappas-dnsop-long-ttl-04.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 15:21:27 -0000 On Fri, Mar 02, 2012 at 09:56:40AM -0800, Eric Osterweil wrote a message of 61 lines which said: > We have resurrected our draft Improving DNS Service Availability by > Using Long TTL Values, > A.1. Frequency of Infra-RR Changes A very interesting survey. Thanks for the data. But it works only for zones who plan their NS change in advance (like most TLDs). For Joe Smith or Jane Jones, holders of example.com, it won't help because, although the NS changes are infrequent, they are typically not planned in advance and the user would like them to be fast. I suspect that, if ordinary user's domains in .com adopt the 7-days TTL, many will be surprised the first time they attempt to change the NS set. From sm@resistor.net Wed Mar 14 00:18:46 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1C921F8516 for ; Wed, 14 Mar 2012 00:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60VePy3otgEj for ; Wed, 14 Mar 2012 00:18:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3BB21F849C for ; Wed, 14 Mar 2012 00:18:44 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2E7IcfY004629 for ; Wed, 14 Mar 2012 00:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331709523; i=@resistor.net; bh=yAgot/5Kv3OVmr1lOG6S05cXujONl4/s4n3ZBAJI1dA=; h=Date:To:From:Subject:Cc; b=LbOqIExVaoxVIHNhLM0eIQjYeS0UpJT2lv4SQdBqwq3cVENMvuHTxSiR5k/kmb889 GBEjnxsYwUm2IAXyi5fmm46Zh1RThJWowjvMlnXaYEPDmSaOLvMJ9T9fP+YCYLtpzN J/h+YewOgisX4ImSXcs2hngBC0u/sgdlr5zJJ1FU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1331709523; i=@resistor.net; bh=yAgot/5Kv3OVmr1lOG6S05cXujONl4/s4n3ZBAJI1dA=; h=Date:To:From:Subject:Cc; b=bBWu38Zh47ZDStpYwfNlBHG9397AMhwATbVD9H4RSJdms9/EiuDlSbxSvQ2DZwmvX 0iar5hRGkq24Js/Y0/QYXrK/7TK4NATqW07zBA/ci6DSXUy8lylwRg0f7EJX7FD3wm sF5i1OKlkEXa4QRNgcEKDWV/MGD/B9y94BCrsMeE= Message-Id: <6.2.5.6.2.20120313235447.0ae96c58@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Mar 2012 00:14:03 -0700 To: dnsop@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [DNSOP] .local X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 07:18:46 -0000 There is an IESG Note in BCP 44 (RFC 2964) about using .local. RFC 6265 obsoleted RFC 2965 which contained a similar note. Below are a reply from an ISP's DNS server for local. : ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53996 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;local. IN A ;; ANSWER SECTION: local. 10800 IN A [removed] Is there any survey about ISP DNS servers returning an answer for such queries? Regards, -sm From sm@resistor.net Wed Mar 14 07:22:02 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C4F21F87DA for ; Wed, 14 Mar 2012 07:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.635 X-Spam-Level: X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrofTapXs++G for ; Wed, 14 Mar 2012 07:22:01 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CB221F87D8 for ; Wed, 14 Mar 2012 07:22:01 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2EELtCa008519; Wed, 14 Mar 2012 07:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331734921; i=@resistor.net; bh=ISciF6jPgKof1nQra1AUYB7wVNqzgxGfTYNeRujs6yQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=i0RF564cXOVTFmGAHPI+3e7TeVcsrfNd29p+GmqbM4xt1atPGMFvhj9G+65PdMpaH DgfDQ05psmmlxnXT5w/ludK2RF6IXS8a3X3Cp43CirzrxkZpotF/NJyQzu4HZoaAsB Pckk55c6EBiVwMM+VCKn+9sxF8MoetKmiqXG2jGU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1331734921; i=@resistor.net; bh=ISciF6jPgKof1nQra1AUYB7wVNqzgxGfTYNeRujs6yQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=n8LHdYhncjt+WxPrO7BgHRhFLagTgLBR+dNs0W9FLKUVRAVoLHeE6vXqWdcUq5/GN UC+R+g0JIuHe9qvNwKlRT2JmsOoAHnFP8R3LE0Ia3GDRt8aOgxF66sFiGMQSEjeMu/ DbC7kSyJZuXS90OS8KGhxZ618HLG7UgkrcpIJ1lk= Message-Id: <6.2.5.6.2.20120314065759.0a7363c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Mar 2012 07:16:24 -0700 To: Simon Josefsson From: SM In-Reply-To: <87pqcftxm1.fsf@latte.josefsson.org> References: <6.2.5.6.2.20120313235447.0ae96c58@elandnews.com> <87pqcftxm1.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] .local X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:22:02 -0000 Hi Simon, At 01:06 14-03-2012, Simon Josefsson wrote: >I ran into a related issue recently too, and it appears indeed that the >problem is widespread. See: Thanks for the feedback. >Btw, I don't see the note about .local in RFC 6265? In RFC 2965, ".local" is appended to a "dotless" host name. RFC 6265 does not contain that text. Regards, -sm From simon@josefsson.org Wed Mar 14 07:24:19 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7897421F880B for ; Wed, 14 Mar 2012 07:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-2.090, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH8S3n0FzAkn for ; Wed, 14 Mar 2012 07:24:18 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id F024E21F880C for ; Wed, 14 Mar 2012 07:24:17 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2EEO9LJ019571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Mar 2012 15:24:10 +0100 From: Simon Josefsson To: SM References: <6.2.5.6.2.20120313235447.0ae96c58@elandnews.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120314:dnsop@ietf.org::7TjQplkUhM8S5CPG:0Gp5 X-Hashcash: 1:22:120314:sm@resistor.net::nWij/243XEYv07M8:0l8i Date: Wed, 14 Mar 2012 15:24:09 +0100 In-Reply-To: <6.2.5.6.2.20120313235447.0ae96c58@elandnews.com> (sm@resistor.net's message of "Wed, 14 Mar 2012 00:14:03 -0700") Message-ID: <87ty1rgt12.fsf@latte.josefsson.org> User-Agent: Gnus/5.130003 (Ma Gnus v0.3) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: dnsop@ietf.org Subject: Re: [DNSOP] .local X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:24:19 -0000 (I'm re-sending this e-mail from the proper subscription address, it seems amsl.com's auto-authorizer doesn't work or is slow.) SM writes: > There is an IESG Note in BCP 44 (RFC 2964) about using .local. RFC > 6265 obsoleted RFC 2965 which contained a similar note. Below are a > reply from an ISP's DNS server for local. : > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53996 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;local. IN A > > ;; ANSWER SECTION: > local. 10800 IN A [removed] > > Is there any survey about ISP DNS servers returning an answer for such queries? I ran into a related issue recently too, and it appears indeed that the problem is widespread. See: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/327362 At least the following ISPs appears to serve .local zones (although not necessarily with A records) to their customers: TeliaSonera (Nordic) Bredbandsbolaget (Sweden) True Internet (Thailand) M1 Home Broadband (Singapore) Golden Telecom (Russia) Beeline (Russia) Corbina (Russia) New Orleans city wifi Mac OS X appears to filter out all .local data received via DNS from the net, see the end of: https://support.apple.com/kb/TA20999?viewlocale=en_US Given the widespread damage, I have sympathy for that approach. Btw, I don't see the note about .local in RFC 6265? /Simon From Joe.Gersch@Secure64.com Wed Mar 14 09:18:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2B21F8712 for ; Wed, 14 Mar 2012 09:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdm9VphT89m2 for ; Wed, 14 Mar 2012 09:18:53 -0700 (PDT) Received: from zimbra.secure64.com (unknown [64.92.221.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE2221F870E for ; Wed, 14 Mar 2012 09:18:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.secure64.com (Postfix) with ESMTP id 66A5CB84E1; Wed, 14 Mar 2012 10:18:53 -0600 (MDT) X-Virus-Scanned: amavisd-new at secure64.com Received: from zimbra.secure64.com ([127.0.0.1]) by localhost (zimbra.secure64.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMJ4tf1bRokR; Wed, 14 Mar 2012 10:18:53 -0600 (MDT) Received: from [10.138.15.6] (unknown [192.168.254.4]) by zimbra.secure64.com (Postfix) with ESMTPSA id A66C4B8488; Wed, 14 Mar 2012 10:18:52 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=secure64.com; s=2010; t=1331741932; bh=xR+npyxjbnY5bzZa8jkxaS1JI6ACYhPCdjDxjmTEdCI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Ir6VtNyGryQa ihinr1kzjXlBND/DoGRVOJ8+0jXq/aUBv0lh05ykNgO1UhdOEYcaK4CV9gjAFiSf9Pw hLB2nLQgSaBLYRmcvPrhT3OBQ09//9sW57TCP+odPC1bYH+L/UuCvQ7xeq4/WgXBw7p 1IS9VFjwHivGYIqpTedH40cmQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Joseph Gersch In-Reply-To: <4F5B811E.9050602@redbarn.org> Date: Wed, 14 Mar 2012 10:18:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <58848A45-8510-43EE-8FD6-6073AC6C9370@Secure64.com> References: <5E9B2EA9-FE35-49DA-9FB4-9D80A310D5CC@Secure64.com> <4F5B811E.9050602@redbarn.org> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1257) Cc: Joseph Gersch , Daniel Massey Subject: Re: [DNSOP] 2 internet drafts relevant to DNSOP X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:18:54 -0000 Paul, thanks for your comments and support. We will definitely reference = RFC draft 1101 in our next version. - Joe and Dan On Mar 10, 2012, at 9:28 AM, paul vixie wrote: > joe, et al, >=20 > your draft-gersch-dnsop-revdns-cidr-01 is very clean and simple; the > draft and the design are of admirable quality. as a co-author of RFC > 2317 i agree that it does not suit the needs of bgp security since it > seeks only to provide a method of fully naming hosts, not networks. >=20 > importantly, i see no reference to RFC 1101 in your draft. RFC 1101 > describes a way to name networks, and while at first it did not seem = to > be compatible with CIDR, implementation (in "netstat -r" back in = BSD/OS > 3.1) showed that RFC 1101 was in fact not as classful as it appeared. >=20 > i recommend a review of these functions, contained in the file = dns_nw.c, > present in bind8 as src/lib/irs/dns_nw.c, and also present in older > versions of bind9, as well as various versions of netbsd and athena. >=20 > static struct nwent * get1101byaddr(struct irs_nw *, u_char *, int); > static struct nwent * get1101byname(struct irs_nw *, const char *); > static struct nwent * get1101answer(struct irs_nw *, > u_char *ansbuf, int anslen, > enum by_what by_what, > int af, const char *name, > const u_char *addr, int addrlen); > static struct nwent * get1101mask(struct irs_nw *this, struct nwent = *); > static int make1101inaddr(const u_char *, int, char *, = int); >=20 > you may find that some of your work has already been done for you, or, > you may find that this is related work that should be referenced in = your > draft along with the reasons why your proposed method is necessary. >=20 > paul Joseph Gersch Chief Operating Officer Secure64 Software Corporation From fanf2@hermes.cam.ac.uk Wed Mar 14 09:20:51 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F1921F8770 for ; Wed, 14 Mar 2012 09:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id berY9yDB6dFe for ; Wed, 14 Mar 2012 09:20:48 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 5798921F87D2 for ; Wed, 14 Mar 2012 09:20:48 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:37629) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1S7qwQ-0004V9-Yw (Exim 4.72) (return-path ); Wed, 14 Mar 2012 16:20:46 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1S7qwQ-0001zd-OD (Exim 4.67) (return-path ); Wed, 14 Mar 2012 16:20:46 +0000 Date: Wed, 14 Mar 2012 16:20:46 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: SM In-Reply-To: <6.2.5.6.2.20120313235447.0ae96c58@elandnews.com> Message-ID: References: <6.2.5.6.2.20120313235447.0ae96c58@elandnews.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop@ietf.org Subject: Re: [DNSOP] .local X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:20:51 -0000 SM wrote: > There is an IESG Note in BCP 44 (RFC 2964) about using .local. RFC 6265 > obsoleted RFC 2965 which contained a similar note. Below are a reply from an > ISP's DNS server for local. : > > local. 10800 IN A [removed] > > Is there any survey about ISP DNS servers returning an answer for such > queries? That seems rather foolish to me! On my recursive servers, .local is a locally-served empty zone, to avoid leakage problems from mDNS names. Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: Southerly or southwesterly 5 to 7, but mainly 4 in southeast. Rough. Rain. Moderate, occasionally poor. From jason_livingood@cable.comcast.com Mon Mar 26 00:58:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE8221F85B5 for ; Mon, 26 Mar 2012 00:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=-1.421, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihZnrsk89t1V for ; Mon, 26 Mar 2012 00:58:09 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id B917921F8582 for ; Mon, 26 Mar 2012 00:58:03 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7147795; Mon, 26 Mar 2012 03:52:00 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 03:58:01 -0400 From: "Livingood, Jason" To: dnsop Thread-Topic: New I-D on Negative Trust Anchors Thread-Index: AQHNCyYpeZAZwGV2Bk2QEn5IpxhAYw== Date: Mon, 26 Mar 2012 07:57:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_CB95EE2556B17jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:58:10 -0000 --_000_CB95EE2556B17jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I just posted a =9600 of a draft that may be of interest to this WG. It cov= ers an issue we have found in our DNSSEC deployment. My co-author is doing = some markup of the doc now so I am hoping to post a =9601 before the end of= this week. (I've already found some minor typographical and grammatical er= rors.) http://www.ietf.org/id/draft-livingood-negative-trust-anchors-00.txt Feel free to share any other questions or feedback. Regards, Jason --_000_CB95EE2556B17jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9A3AB63A9B478448BD5F08C06A0E9489@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
I just posted a =9600 of a draft that may be of interest to this WG. I= t covers an issue we have found in our DNSSEC deployment. My co-author is d= oing some markup of the doc now so I am hoping to post a =9601 before the e= nd of this week. (I've already found some minor typographical and grammatical errors.)


Feel free to share any other questions or feedback.

Regards,
Jason
--_000_CB95EE2556B17jasonlivingoodcablecomcastcom_-- From ogud@ogud.com Mon Mar 26 01:13:24 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9836121F84B6 for ; Mon, 26 Mar 2012 01:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btyO6gZKTY-i for ; Mon, 26 Mar 2012 01:13:22 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2592521F8472 for ; Mon, 26 Mar 2012 01:13:21 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2Q8DJYI061500 for ; Mon, 26 Mar 2012 04:13:19 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4F702519.9090802@ogud.com> Date: Mon, 26 Mar 2012 04:13:13 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: dnsop@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:13:24 -0000 Jason, I read the draft and like the direction of it. It looks like you are proposing turning off a validation for domain by the negative trust anchor. An alternative is to insert a negative trust anchor for a particular trust anchor. In the first case there is an action required by the validator operator to remove the negative trust anchor, but in the second case once an alternate trust anchor is available then the domain starts validating again. Olafur On 26/03/2012 03:57, Livingood, Jason wrote: > I just posted a –00 of a draft that may be of interest to this WG. It > covers an issue we have found in our DNSSEC deployment. My co-author is > doing some markup of the doc now so I am hoping to post a –01 before the > end of this week. (I've already found some minor typographical and > grammatical errors.) > > http://www.ietf.org/id/draft-livingood-negative-trust-anchors-00.txt > > Feel free to share any other questions or feedback. > > Regards, > Jason > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From jason_livingood@cable.comcast.com Mon Mar 26 01:31:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EF121F8503 for ; Mon, 26 Mar 2012 01:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=-1.263, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDffN--vKph3 for ; Mon, 26 Mar 2012 01:31:53 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 15C5021F8507 for ; Mon, 26 Mar 2012 01:31:53 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7148553; Mon, 26 Mar 2012 04:25:47 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 04:31:53 -0400 From: "Livingood, Jason" To: Olafur Gudmundsson , dnsop Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNCyYpeZAZwGV2Bk2QEn5IpxhAY5Z8fVWAgAAmtYA= Date: Mon, 26 Mar 2012 08:31:47 +0000 Message-ID: In-Reply-To: <4F702519.9090802@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:31:54 -0000 >I read the draft and like the direction of it. >It looks like you are proposing turning off a validation for domain by >the negative trust anchor. Correct >An alternative is to insert a negative trust anchor for a particular >trust anchor. Do you mean when an alternative trust anchor is used by a validating resolver? Like the ITAR or the ISC DLV trust anchor (or for other islands where the TLD is not signed)? >In the first case there is an action required by the validator operator >to remove the negative trust anchor, >but in the second case once an >alternate trust anchor is available then the domain starts validating >again. Hmmm=8A So who takes the action to create or remove the (temporary?) alternate trust anchor? - Jason From fanf2@hermes.cam.ac.uk Mon Mar 26 07:24:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429A821E809A for ; Mon, 26 Mar 2012 07:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-YEANVEa+-9 for ; Mon, 26 Mar 2012 07:24:04 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 265C221E8013 for ; Mon, 26 Mar 2012 07:24:04 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:47967) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1SCAq1-0004cF-qv (Exim 4.72) (return-path ); Mon, 26 Mar 2012 15:24:01 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SCAq1-0004sk-Bx (Exim 4.67) (return-path ); Mon, 26 Mar 2012 15:24:01 +0100 Date: Mon, 26 Mar 2012 15:24:01 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Olafur Gudmundsson , Jason_Livingood@cable.comcast.com In-Reply-To: <4F702519.9090802@ogud.com> Message-ID: References: <4F702519.9090802@ogud.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop@ietf.org Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:24:05 -0000 Olafur Gudmundsson wrote: > It looks like you are proposing turning off a validation for domain by the > negative trust anchor. > An alternative is to insert a negative trust anchor for a particular trust > anchor. > In the first case there is an action required by the validator operator to > remove the negative trust anchor, but in the second case once an alternate > trust anchor is available then the domain starts validating again. I think you are assuming that there is some trust anchor with which the broken domain can be validated. But that isn't true for a lot of DNSSEC problems, such as expired signatures or missing signatures. There's another use for a negative trust anchor which is likely to be a long-term setting rather than a short-term fix as the draft describes. Internal private zones often use made-up names. (I have seen horrible things in my mail logs like example.int for Example Corp's internal namespace.) It's usually easier to bodge around this kind of problem than change everything to use a real domain name; we don't want this kind of difficulty to discourage organizations from deploying DNSSEC on their resolvers and public DNS. These internal namespaces are often served by software that doesn't support DNSSEC, so you can't add a positive trust anchor to splice them into the namespace. The documentation for Unbound's domain-insecure option talks about this kind of scenario. Tony. -- f.anthony.n.finch http://dotat.at/ Viking: Variable 3 or 4. Smooth or slight, occasionally moderate later in northwest. Fog patches. Moderate or good, occasionally very poor. From Antoin.Verschuren@sidn.nl Tue Mar 27 00:39:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD9A21F87A5 for ; Tue, 27 Mar 2012 00:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.503 X-Spam-Level: X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42vXri21sC9h for ; Tue, 27 Mar 2012 00:39:27 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4F71621F8795 for ; Tue, 27 Mar 2012 00:39:21 -0700 (PDT) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q2R7dLdq000699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 27 Mar 2012 09:39:21 +0200 Received: from KAHUBCASN01.SIDN.local (192.168.2.75) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 27 Mar 2012 09:39:21 +0200 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn01.SIDN.local ([::1]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 09:39:21 +0200 From: Antoin Verschuren To: dnsop Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNCyYpeZAZwGV2Bk2QEn5IpxhAY5Z9oZ0A Date: Tue, 27 Mar 2012 07:39:20 +0000 Message-ID: <29599BA5-9513-432E-99E5-A5AE45CDAFB1@sidn.nl> References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.161] Content-Type: multipart/signed; boundary="Apple-Mail=_6EDA2251-756B-4114-945D-65F4AE3E770C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:39:28 -0000 --Apple-Mail=_6EDA2251-756B-4114-945D-65F4AE3E770C Content-Type: multipart/alternative; boundary="Apple-Mail=_600E1188-46EC-47A7-8B01-482E04AB2C18" --Apple-Mail=_600E1188-46EC-47A7-8B01-482E04AB2C18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I read the draft, and I seem to be missing a part where a domain is = intentionally insecure. Such a situation might occur f.e. in tools investigating if DNSSEC is = working properly from an end user perspective. I can also imagine there are other situations where DNSSEC validation is = broken on purpose. So somewhere in section 7 it should state not to use negative trust = anchors for domains that are intentionally insecure, though I wonder how = this could be signalled (in a secure way). - --=20 Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ Op 26 mrt. 2012, om 09:57 heeft Livingood, Jason het volgende = geschreven: > I just posted a =9600 of a draft that may be of interest to this WG. = It covers an issue we have found in our DNSSEC deployment. My co-author = is doing some markup of the doc now so I am hoping to post a =9601 = before the end of this week. (I've already found some minor = typographical and grammatical errors.) >=20 > http://www.ietf.org/id/draft-livingood-negative-trust-anchors-00.txt >=20 > Feel free to share any other questions or feedback. >=20 > Regards, > Jason > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail=_600E1188-46EC-47A7-8B01-482E04AB2C18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
- = -- 
Antoin Verschuren

Technical Policy Advisor = SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The = Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: = +31 6 23368970
mailto:antoin.verschuren@sidn.nl=   xmpp:antoin@jabber.sidn.nl
http://www.sidn.nl/

Op 26 mrt. 2012, om 09:57 heeft Livingood, Jason het = volgende geschreven:

I just posted a =9600 of a draft that may be of interest to this = WG. It covers an issue we have found in our DNSSEC deployment. My = co-author is doing some markup of the doc now so I am hoping to post a = =9601 before the end of this week. (I've already found some minor typographical and grammatical errors.)


Feel free to share any other questions or feedback.

Regards,
Jason
_______________________________________________
DNSOP mailing = list
DNSOP@ietf.org
https://www.ietf.org/= mailman/listinfo/dnsop

= --Apple-Mail=_600E1188-46EC-47A7-8B01-482E04AB2C18-- --Apple-Mail=_6EDA2251-756B-4114-945D-65F4AE3E770C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPcW6pAAoJEDqHrM883AgnMwIIAM0v1YLji04KMOdu1a76SWB8 tqz8TOsKPCMZCB+F6bu5R5y3i2mLTP9i0X+AOPLWY4Zf4moIN9BKlfWeMn+Lmdwq hsM+fiV52oUIIcUhsACXyuJXgN+ebMN8yeWajC9Y+OLyfjMhIgOIp5p5arAH7WAp vrkkV+hXaDbjNP11lt/EuO31g4b8bojDfB2kH398FuX6o+pBV8+PeX8VqZ1U16Hw PF7pyL2iNa73d/o4Ww0Z2FnVGmBsat/CQQdEWJKxDCFAULefeWADauGSG5uawVhY 5WgcexhD7L+Nspyz6a62EPQw7HXtz9B430dTlKxlf0WT/EiKiRmxlSTQSaqdoLk= =7AUx -----END PGP SIGNATURE----- --Apple-Mail=_6EDA2251-756B-4114-945D-65F4AE3E770C-- From fanf2@hermes.cam.ac.uk Tue Mar 27 03:04:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FB221E813D for ; Tue, 27 Mar 2012 03:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0UmxkKFYtqv for ; Tue, 27 Mar 2012 03:04:57 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 283FB21E8134 for ; Tue, 27 Mar 2012 03:04:56 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53921) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1SCTGp-0004GJ-Sk (Exim 4.72) (return-path ); Tue, 27 Mar 2012 11:04:55 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1SCTGp-0003un-R3 (Exim 4.67) (return-path ); Tue, 27 Mar 2012 11:04:55 +0100 Date: Tue, 27 Mar 2012 11:04:55 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Antoin Verschuren In-Reply-To: <29599BA5-9513-432E-99E5-A5AE45CDAFB1@sidn.nl> Message-ID: References: <29599BA5-9513-432E-99E5-A5AE45CDAFB1@sidn.nl> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:04:59 -0000 Antoin Verschuren wrote: > I read the draft, and I seem to be missing a part where a domain is > intentionally insecure. Such a situation might occur f.e. in tools > investigating if DNSSEC is working properly from an end user > perspective. I can also imagine there are other situations where DNSSEC > validation is broken on purpose. So somewhere in section 7 it should > state not to use negative trust anchors for domains that are > intentionally insecure, though I wonder how this could be signalled (in > a secure way). Do you mean insecure (no DS) or bogus (broken RRSIGs)? Tony. -- f.anthony.n.finch http://dotat.at/ Dover, Wight: Northeast 4 or 5, increasing 6 at times until later. Slight or moderate. Fair. Moderate or good. From pawal@blipp.com Tue Mar 27 03:29:42 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FD021F8942 for ; Tue, 27 Mar 2012 03:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY3LW0W559Px for ; Tue, 27 Mar 2012 03:29:41 -0700 (PDT) Received: from vic20.blipp.com (cl-682.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:2a9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2887621F8948 for ; Tue, 27 Mar 2012 03:29:36 -0700 (PDT) Received: from dhcp-503f.meeting.ietf.org (dhcp-503f.meeting.ietf.org [130.129.80.63]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id 869A23806D; Tue, 27 Mar 2012 12:29:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_Wallstr=F6m?= In-Reply-To: Date: Tue, 27 Mar 2012 12:29:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <29599BA5-9513-432E-99E5-A5AE45CDAFB1@sidn.nl> To: Tony Finch X-Mailer: Apple Mail (2.1257) Cc: dnsop Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:29:42 -0000 On Mar 27, 2012, at 12:04 PM, Tony Finch wrote: > Antoin Verschuren wrote: >=20 >> I read the draft, and I seem to be missing a part where a domain is >> intentionally insecure. Such a situation might occur f.e. in tools >> investigating if DNSSEC is working properly from an end user >> perspective. I can also imagine there are other situations where = DNSSEC >> validation is broken on purpose. So somewhere in section 7 it should >> state not to use negative trust anchors for domains that are >> intentionally insecure, though I wonder how this could be signalled = (in >> a secure way). >=20 > Do you mean insecure (no DS) or bogus (broken RRSIGs)? I have created such a domains for exactly these purposes. This one is no = longer signed (I think) but has a DS in its parent zone: trasigdnssec.se From Antoin.Verschuren@sidn.nl Tue Mar 27 05:04:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F7121E81C4 for ; Tue, 27 Mar 2012 05:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.503 X-Spam-Level: X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C5cX8t2Svti for ; Tue, 27 Mar 2012 05:04:31 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 67BE521E819D for ; Tue, 27 Mar 2012 05:04:31 -0700 (PDT) Received: from kahubcas1.SIDN.local ([192.168.2.41]) by ede1-kamx.sidn.nl with ESMTP id q2RC4UdK010445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 27 Mar 2012 14:04:30 +0200 Received: from KAHUBCASN01.SIDN.local (192.168.2.75) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 27 Mar 2012 14:04:30 +0200 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn01.SIDN.local ([::1]) with mapi id 14.02.0247.003; Tue, 27 Mar 2012 14:04:30 +0200 From: Antoin Verschuren To: dnsop Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNCyYpeZAZwGV2Bk2QEn5IpxhAY5Z9oZ0AgAAorYCAACFrgA== Date: Tue, 27 Mar 2012 12:04:30 +0000 Message-ID: <04482A48-AA10-4907-8AF0-41389E7F4EBE@sidn.nl> References: <29599BA5-9513-432E-99E5-A5AE45CDAFB1@sidn.nl> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.161] Content-Type: multipart/signed; boundary="Apple-Mail=_70CC5C88-9B28-4015-9BF6-D0B08EF0E46B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:04:32 -0000 --Apple-Mail=_70CC5C88-9B28-4015-9BF6-D0B08EF0E46B Content-Type: multipart/alternative; boundary="Apple-Mail=_865BB886-05EB-479E-A910-1FA940A1994D" --Apple-Mail=_865BB886-05EB-479E-A910-1FA940A1994D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Op 27 mrt. 2012, om 12:04 heeft Tony Finch het volgende geschreven: >=20 > Do you mean insecure (no DS) or bogus (broken RRSIGs)? Both, and also DS at parent but no RRSIGs or no DNSKEY in child. Actually it does not matter how they are broken, but that the brokenness = is not meant to be fixed by a negative trust anchor. --=20 Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/= --Apple-Mail=_865BB886-05EB-479E-A910-1FA940A1994D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Do you mean = insecure (no DS) or bogus (broken = RRSIGs)?

Both, and also DS  at = parent but no RRSIGs or no DNSKEY in child.
Actually it does = not matter how they are broken, but that the brokenness is not meant to = be fixed by a negative trust = anchor.

 -- 
Antoin = Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box = 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: = +31 26 3525505  M: +31 6 23368970
mailto:antoin.verschuren@sidn.nl=   xmpp:antoin@jabber.sidn.nl
http://www.sidn.nl/
= --Apple-Mail=_865BB886-05EB-479E-A910-1FA940A1994D-- --Apple-Mail=_70CC5C88-9B28-4015-9BF6-D0B08EF0E46B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPcazQAAoJEDqHrM883AgndgAH/1wA51YBlkQMSf049/dxJtlI Pvjhhk4aC2DEGnNwn62u/LN3e264WzJDy2F77pWwGsYYMI5UwUa/DzdrPUkxYvHt KgVMAv2jrqWbbj5y3EpKLecy0BkN/eZ3mouj5nEt1u4vrty6JockKVkGQGB+hxfJ cwca7jdP72uJ9OWYDDOqJ49pjPtj1rJSs/laMPnUvV5MepYUjuprhAAnc+kErCQF hidgZBza/Y2+ItCpxrRX5FvapoVp2Ze1hTL9/M6e+OCc1uKDqqwFwHKaBXzkyl4I 6o50W7BasExwnlTVkDxsDSkoiWIZzHWomXlELey1cag6u8Ij4830SHVecK2TbqM= =lCPh -----END PGP SIGNATURE----- --Apple-Mail=_70CC5C88-9B28-4015-9BF6-D0B08EF0E46B-- From jason_livingood@cable.comcast.com Tue Mar 27 08:19:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AB521F88F8 for ; Tue, 27 Mar 2012 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.055 X-Spam-Level: X-Spam-Status: No, score=-102.055 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoAy8GK0FF-Y for ; Tue, 27 Mar 2012 08:19:31 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id D263C21F88B2 for ; Tue, 27 Mar 2012 08:19:30 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.11054298; Tue, 27 Mar 2012 09:07:09 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.01.0355.002; Tue, 27 Mar 2012 11:19:30 -0400 From: "Livingood, Jason" Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNCyYpeZAZwGV2Bk2QEn5IpxhAY5Z9oZ0AgACNQoCAACFqAIAAV/YA Date: Tue, 27 Mar 2012 15:19:23 +0000 Message-ID: In-Reply-To: <04482A48-AA10-4907-8AF0-41389E7F4EBE@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.73] Content-Type: multipart/alternative; boundary="_000_CB97A6E757050jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 To: Antoin Verschuren , dnsop Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:19:31 -0000 --_000_CB97A6E757050jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I posted a =9601 a short time ago (http://tools.ietf.org/html/draft-livingo= od-negative-trust-anchors-01) and listed this in open items for the next ve= rsion. I may have some questions on the best way to include that. Jason On 3/27/12 2:04 PM, "Antoin Verschuren" > wrote: Op 27 mrt. 2012, om 12:04 heeft Tony Finch het volgende geschreven: Do you mean insecure (no DS) or bogus (broken RRSIGs)? Both, and also DS at parent but no RRSIGs or no DNSKEY in child. Actually it does not matter how they are broken, but that the brokenness is= not meant to be fixed by a negative trust anchor. -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschuren@sidn.nl xmpp:antoin@jabber.sidn.nl http://www.sidn.nl/ _______________________________________________ DNSOP mailing list DNSOP@ie= tf.org https://www.ietf.org/mailman/listinfo/dnsop --_000_CB97A6E757050jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I posted a =9601 a short time ago (http://tools.ietf.org/html/dr= aft-livingood-negative-trust-anchors-01) and listed this in open i= tems for the next version. I may have some questions on the best way to include that.

Jason

On 3/27/12 2:04 PM, "Antoin Verschuren" <Antoin.Verschuren@sidn.nl> wrote:

Op 27 mrt. 2012, om 12:04 heeft Tony Finch het volgende geschreven:

Do you mean insecure (no DS) or bogus (broken RRSIGs)?

Both, and also DS  at parent but no RRSIGs or no DNSKEY in child.=
Actually it does not matter how they are broken, but that the brokenne= ss is not meant to be fixed by a negative trust anchor.

 -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 233689= 70
mailto:antoin.verschuren@sidn.= nl  xmpp:antoin@jabber= .sidn.nl
http://www.sidn.nl/
_______________________________________________ DNSOP mailing list DNSOP@ietf.org = https://www.ietf.org/mailman/listinfo/dnsop
--_000_CB97A6E757050jasonlivingoodcablecomcastcom_-- From A.Hoenes@TR-Sys.de Tue Mar 27 15:51:38 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0EB21F8737 for ; Tue, 27 Mar 2012 15:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.637 X-Spam-Level: X-Spam-Status: No, score=-98.637 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2lvkkrXMmgn for ; Tue, 27 Mar 2012 15:51:37 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id DAB7621F8734 for ; Tue, 27 Mar 2012 15:51:36 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA272388627; Wed, 28 Mar 2012 00:50:27 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA08100; Wed, 28 Mar 2012 00:50:27 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203272250.AAA08100@TR-Sys.de> To: dnsop@ietf.org Date: Wed, 28 Mar 2012 00:50:26 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [DNSOP] A quick review of draft-cheshire-dnsext-special-names-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:51:38 -0000 The referenced draft seems strongly related to DNSOP as well, but to avoid cross-posting, here's only the initial part of my review just posted to the dnsext mailing list. -------- start of forwarded message -------- Hi, I've performed a quick review of the DNSEXT-related I-D, draft-cheshire-dnsext-special-names-02 and would like to submit a few notes. (A) Significant issues (A.1) Firstly, I'm surprised by the non-trivial overlap of this work with RFC 6303 and the IANA Registry created by it, the "AS112" RFCs, and the ongoing work-in-progress to address more emerging overload reasons for the authoritative root/infrastructure DNS servers by extending the scope of the AS112 project, registering more "special" domain names in that "Locally Served DNS Zones" IANA registry, and specifying that they be treated as specified in RFC 6303. The present draft not even quotes RFC 6303 for Sect. 5.1, where the largest overlap with RFC 6303 occurs. (I have not yet studied in detail inhowfar the new specification in that section is compatible or collides with the normative behavior specified in RFC 6303.) [...snip...] -------- end of forwarded message -------- To see the full review, please refer to the copy archived in the DNSEXT list archive: Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From wmaton@ryouko.imsb.nrc.ca Tue Mar 27 23:33:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8921F876A for ; Tue, 27 Mar 2012 23:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgS8SUaT+M1T for ; Tue, 27 Mar 2012 23:33:08 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (ryouko.imsb.nrc.ca [IPv6:2604:8400:0:127::10]) by ietfa.amsl.com (Postfix) with ESMTP id 64F0321F8768 for ; Tue, 27 Mar 2012 23:33:08 -0700 (PDT) Received: from ryouko.imsb.nrc.ca (localhost [127.0.0.1]) by ryouko.imsb.nrc.ca (8.14.5/8.14.4) with ESMTP id q2S6X1ur009706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2012 02:33:06 -0400 Received: from localhost (wmaton@localhost) by ryouko.imsb.nrc.ca (8.14.5/8.14.4/Submit) with ESMTP id q2S6X1xx009703; Wed, 28 Mar 2012 02:33:01 -0400 Date: Wed, 28 Mar 2012 02:33:01 -0400 (EDT) From: "William F. Maton Sotomayor" To: Alfred =?hp-roman8?B?SM5uZXM=?= In-Reply-To: <201203272250.AAA08100@TR-Sys.de> Message-ID: References: <201203272250.AAA08100@TR-Sys.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-159118721-1672490271-1332916381=:7486" Cc: dnsop@ietf.org Subject: Re: [DNSOP] A quick review of draft-cheshire-dnsext-special-names-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: wmaton@ryouko.imsb.nrc.ca List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 06:33:09 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---159118721-1672490271-1332916381=:7486 Content-Type: TEXT/PLAIN; charset=hp-roman8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE as one of the as112 co-authors, i'll chime-in here. you're right, there's an opportunity to leverage an existing mechanism and= =20 registry for this draft. both rfc 6303 and rfc 6304 were developed at=20 different times so there's a little bit of a disconnect between those as=20 well. i think my draft submitted to dnsop for their adoption tries to=20 bridge the two by making reference to the registry. if it does't, it=20 should. i've been contemplating a rfc6304bis that would: - extend as112 operations to use ipv6 addressing; - reference the registry in 6303 as well; and, - propose a registry for special names the latter two points are important in that i am mindful of duplicating=20 efforts and placing more workload on the iana to keep track of yet more=20 registries. if these drafts/rfcs could keep the registries to just one,=20 (or two maximum) it may be better for everyone. btw, early discussions in the life of the draft versions of rfc 6304 kept= =20 special names out for two reasons: a) we intended to document the current practice b) we didn't want to invite potentially heated discussions that treaded=20 into someone else's territory when it came to special names. another point for consideration is the discrepancy between 6303 and 6304=20 in that one is a bcp while the other isn't. not sure what the impact is=20 beyond face-value though and if that should be fixed. i gauge the feeling= =20 on as112-ops. thanks, On Wed, 28 Mar 2012, Alfred H=CEnes wrote: > The referenced draft seems strongly related to DNSOP as well, > but to avoid cross-posting, here's only the initial part of > my review just posted to the dnsext mailing list. > > > -------- start of forwarded message -------- > Hi, > I've performed a quick review of the DNSEXT-related I-D, > draft-cheshire-dnsext-special-names-02 > and would like to submit a few notes. > > > (A) Significant issues > > (A.1) > Firstly, I'm surprised by the non-trivial overlap of this work > with RFC 6303 and the IANA Registry created by it, the "AS112" RFCs, > and the ongoing work-in-progress to address more emerging overload > reasons for the authoritative root/infrastructure DNS servers by > extending the scope of the AS112 project, registering more "special" > domain names in that "Locally Served DNS Zones" IANA registry, and > specifying that they be treated as specified in RFC 6303. > > The present draft not even quotes RFC 6303 for Sect. 5.1, where > the largest overlap with RFC 6303 occurs. (I have not yet studied > in detail inhowfar the new specification in that section is > compatible or collides with the normative behavior specified in > RFC 6303.) > > > [...snip...] > > -------- end of forwarded message -------- > > To see the full review, please refer to the copy archived in the > DNSEXT list archive: > > > > Kind regards, > Alfred H=CEnes. > > --=20 > > +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | > +------------------------+--------------------------------------------+ > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > wfms ---159118721-1672490271-1332916381=:7486-- From Ralf.Weber@nominum.com Wed Mar 28 01:03:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1F21F88BD for ; Wed, 28 Mar 2012 01:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF6ma8tlEDKT for ; Wed, 28 Mar 2012 01:03:06 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 4218221F88B7 for ; Wed, 28 Mar 2012 01:02:52 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT3LFq6kqUu/gsdJIzRWT1IYATgBIdv9j@postini.com; Wed, 28 Mar 2012 01:02:52 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 696AC1B80D5 for ; Wed, 28 Mar 2012 01:02:51 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5D73A190064; Wed, 28 Mar 2012 01:02:51 -0700 (PDT) (envelope-from Ralf.Weber@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Wed, 28 Mar 2012 01:02:51 -0700 From: Ralf Weber To: "Livingood, Jason" Thread-Topic: [DNSOP] New I-D on Negative Trust Anchors Thread-Index: AQHNDLkrB9/Lvm0QsEG1L8N/7yX4fQ== Date: Wed, 28 Mar 2012 08:02:50 +0000 Message-ID: <1A780B69-0723-4B8E-9203-8818A7B02B97@nominum.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2177B5B1CACDCB40BE8FD665503E63C4@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dnsop Subject: Re: [DNSOP] New I-D on Negative Trust Anchors X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:03:09 -0000 Moin! On 27.03.2012, at 17:19, Livingood, Jason wrote: > I posted a =9601 a short time ago (http://tools.ietf.org/html/draft-livin= good-negative-trust-anchors-01) and listed this in open items for the next = version. I may have some questions on the best way to include that. Ok here are some comments on that: 1. While I agree that the use of negative trust anchors will be become less= necessary as we get more mature deploying the technology I don't think it = will become obsolete and should not be used in the future. As long as peopl= e are handling technology there will be error, so the ability to deploy neg= ative trust anchors has to exist indefinitely. 2. We either should enumerate all the possible failures (which is hard I gu= ess) or just reference the examples of zone administrator errors we already= had (still hard, but probably doable). While nasa.gov was the most promine= nt there are others that happened before. And of course there are errors th= at only affect certain implementations, which may relate to yet not exactly= defined handling of certain aspects of the protocol, or because of the way= the application handles validation. We should also name these as possible = reasons for Domain validation failures. 7. The example in the text should match the graph and we should maybe add s= ome other TLDs to show effect on TLD negative trust anchors (we already nee= ded those ;-), and that it doesn't affect any domain beside or above it. 8. Aren't negative trust anchors a configuration option of an validator imp= lementation (they are named the same in my companies product and are called= domain-insecure in another implementation). I think this paragraph should = leave the management of these to the implementation, but should urge valida= tor implementers to include such a feature, as AFAIK only two implementatio= ns have it now. Appendix B.: Yes we all have those purposely broke domains and we definitel= y don't want negative trust anchors on these. As a negative trust anchor is= something an operator (human) has to deploy he certainly will look hard be= fore he does this. So why not put an TXT record at the zone apex saying "Th= is domain is purposely DNSSEC broken". Another thing that we maybe could include in this documents are steps that = people should do to find out if a domain is broken because of an attack or = an administrator error, although these may change as the bad guys read the = document. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400=20 Redwood City, California 94063 ralf.weber@nominum.com From ietf.fact.check@gmail.com Wed Mar 28 12:38:06 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9601B21E8173 for ; Wed, 28 Mar 2012 12:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, US_DOLLARS_3=0.63] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SPxCK+LtNrT for ; Wed, 28 Mar 2012 12:38:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 595EE21E80D8 for ; Wed, 28 Mar 2012 12:38:05 -0700 (PDT) Received: by iazz13 with SMTP id z13so2190860iaz.31 for ; Wed, 28 Mar 2012 12:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EOtUrEzvIZ5DjVly3mkeciw6v7EZFMzHWGwTMNYA2Gw=; b=qvP3+OMHJ9MvCQ/177ni+YZ/TJ4SzhyUh8wC9zPGONpa9rBcC57b9H+Lf74sYzozEi 2YnlQ/pmEF1Loo6WXkdI2Pg3JL2Jh4ppKzXqkft42/HNH4+agkuu7rMVrm9Apcu6p3L7 g0UgzTpjviq7MmoCYLzAFLVU7Cth+FBQLda6eSSF7DgVMDbwxT29OpjBa5VGnmslj6YA fm608237XVLp7lGNOfxf6jrA5kwariw8QuTlUVjfqmMiUG8l285EJ9LtNf9h3/jHzI4i pLrOfk71w8CzpB5SwgcXHr1oSI6/9uLvnz2aikw9bNhfz5ym1o5GFOU30KgtCAQDK2nr lCng== MIME-Version: 1.0 Received: by 10.50.149.131 with SMTP id ua3mr259100igb.41.1332963484277; Wed, 28 Mar 2012 12:38:04 -0700 (PDT) Received: by 10.50.171.38 with HTTP; Wed, 28 Mar 2012 12:38:04 -0700 (PDT) Date: Wed, 28 Mar 2012 14:38:04 -0500 Message-ID: From: Jim Fleming To: dnsop@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [DNSOP] IETF.Fact.Check - .COM .NET .ORG Legacy DNS vs Peer-2-Peer DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:38:06 -0000 ZOOM://IETF.Fact.Check IETF.Fact.Check - .COM .NET .ORG Legacy DNS vs Peer-2-Peer DNS 1. The .COM .NET .ORG ICANN (IANA) U.S. Department of Commerce contracts are coming up for renewal.[1] 2. The Legacy Client-Server DNS is OUT-DATED and highly monetized for Meat.Space.Mammals 3. Netizens clearly prefer True.Internet.Technology with a Peer-2-Peer Architecture 4. Peer-2-Peer DNS and Virtual Currency are finally gaining market-share with BitCoin and NameCoin using Bit.Throttles.[2] 5. Migration of existing .COM and .NET owners to Peer-2-Peer DNS negates the need for .COM and .NET contract renewals. 6. Migration of existing .ORG owners to Peer-2-Peer DNS appears to be a waste of time.**** 7. Peer-2-Peer DNS begins with Digital.Wallets and many companies are working on variations and services.[3] ZOOM://IETF.Fact.Check - It does not appear that the IETF has any current interest in Peer-2-Peer DNS **** ZOOM://IETF.Fact.Check - The .ORG contract renewal could impact the ISOC (IETF) and a $34,000,000 annual donation from the PIR (set up by the ISOC). People with $600,000 annual non-profit compensation packages may oppose any changes. SEARCH://BITCOIN http://bitcoin.org/ SEARCH://NAMECOIN https://en.bitcoin.it/wiki/Namecoin [1] http://www.icann.org/en/news/announcements/announcement-27mar12-en.htm [2] http://bittco.yolasite.com [3] http://code.google.com/p/bitcoin-wallet/ From Ed.Lewis@neustar.biz Thu Mar 29 02:17:57 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D5921F88CE for ; Thu, 29 Mar 2012 02:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.386 X-Spam-Level: X-Spam-Status: No, score=-106.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4f+sRYk53qHn for ; Thu, 29 Mar 2012 02:17:56 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 088AB21F88AE for ; Thu, 29 Mar 2012 02:17:55 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q2T9HXXW096747; Thu, 29 Mar 2012 05:17:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.130.74] by Work-Laptop-2.local (PGP Universal service); Thu, 29 Mar 2012 11:17:55 +0200 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 29 Mar 2012 11:17:55 +0200 Mime-Version: 1.0 Message-Id: Date: Thu, 29 Mar 2012 11:17:28 +0200 To: "dnsop@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [DNSOP] Want this to be a WG doc? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 09:17:57 -0000 Any thoughts on whether the following would be a DNSOP document? I'm asking DNSEXT too. http://tools.ietf.org/html/draft-lewis-dns-undocumented-types-01 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! From ondrej.sury@nic.cz Thu Mar 29 12:59:50 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1E221F87A2; Thu, 29 Mar 2012 12:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvjeEI9HkhQ6; Thu, 29 Mar 2012 12:59:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5557B21F8795; Thu, 29 Mar 2012 12:59:48 -0700 (PDT) Received: from [10.10.0.6] (howl.nic.cz [217.31.204.249]) by mail.nic.cz (Postfix) with ESMTPSA id 5CBD5141255; Thu, 29 Mar 2012 21:59:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333051187; bh=/t/CsfjJ+rnzgQMaoSyxsMOGEwMsiuGeoNszVrsz2QQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CUVWr3XaFQoEKP4jjUm02uOKw05jFdzDKxro7tNh+XHp/llW6b6EthhFdQruAGxA7 uX2bVKdTvALTkCUR6Y5UjYVARgPPB3OyHiXZzHgKSOh3lWVF3MzPm/BEN6twGRmn/D AB87DNR0U2x9jeeiu04SRA7tImo2PX95gVu2flmE= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120301150930.GA69334@mail.yitter.info> Date: Thu, 29 Mar 2012 21:59:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B2D527E-D62A-444B-BC21-4565F5AC4FE7@nic.cz> References: <4F4BCD01.2090401@isdg.net> <4F4C24A0.2010804@redbarn.org> <20120228100227.214bb6ef@shane-desktop> <4F4D1F9E.5090003@redbarn.org> <20120229102255.74fa4291@shane-desktop> <20120301150930.GA69334@mail.yitter.info> To: dnsop@ietf.org, dnsext@ietf.org, dnsext-chairs chairs X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Shane Kerr Subject: [DNSOP] DNS-NG (Re: Batch Multiple Query Packet) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 19:59:50 -0000 [cross-posting: dnsext readers please check the full thread on dnsop] On 1. 3. 2012, at 16:09, Andrew Sullivan wrote: > If dns-ng is a superset of useful dns functionality, but cleans up > certain issues with dns, then the intermediate resolvers in (2) can as > easily use a new port as they can use more complicated dns handling. > So I have to agree with Paul Vixie: if we're going to work on > replacing the protocol, let's replace it for real. (FWIW, I think > this is a noble goal doomed to failure. But I've been wrong before. > Probably three times just this morning.) On the other hand, it might be just the right time to do this. With dnsext closure we can start with clean table and redesign the underlying mechanisms hopefully with lessons learned so far. I like the idea very much and I would like to initiate BoF in Vancouver if there is an interest to pursue this dns-ng thing. And no it is not meant as replacement for dnsext. The WG should do it's job, produce WG document(s) and close. I am not trying to get mad, y'know :-). O. P.S.: I know I am responding to a month-old email, but better now than = never... -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From A.Hoenes@TR-Sys.de Thu Mar 29 16:11:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9505A21E8019 for ; Thu, 29 Mar 2012 16:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.334 X-Spam-Level: X-Spam-Status: No, score=-98.334 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqtHN6Ov-hdY for ; Thu, 29 Mar 2012 16:11:53 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 99A1A21F84F6 for ; Thu, 29 Mar 2012 16:11:52 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA287162641; Fri, 30 Mar 2012 01:10:41 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id BAA21224; Fri, 30 Mar 2012 01:10:35 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203292310.BAA21224@TR-Sys.de> To: hsantos@isdg.net Date: Fri, 30 Mar 2012 01:10:35 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] Batch Multiple Query Packet X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 23:11:54 -0000 On 27 Feb 2012 13:35:45 -0500, Hector Santos wrote: > > I am interesting to find information about past or possible current > interest regarding the support of a Batch single call of multiple > query packets. > > If it doesn't already exist or not considered in the past as an > unfeasible concept, I am interest in seeing if this is something > worth pursuing. Below are a few comments, and pointers to references, to my past, humble contributions to a possible solution for the issue at hands. In response to a draft that suggested a form of A+AAAA query type, which was submitted/refreshed for the Hiroshima IETF meeting, draft-li-dnsext-ipv4-ipv6-02, on 09 Nov 2009 I have submitted a "more versatile proposal" to the DNSEXT WG's list [1], which was only one possible variant (for brevity) for a "RR Group Query" (RRGQ) to query for a group of RRtypes with the same QNAME and QCLASS using an EDNS option to indicate the Data RRtypes wanted. The distinguishing idea was to build in some kind of integrity of RRsets using feedback signaling that allows to indicate empty RRsets ("nodata" indication per RRtype); caches that do not "know" the entire RRset of an RRtype asked for do not send a partial RRset but indicate that the response does not answer for such RRtype. The initially posted single variant made use of a Pseudo-RRtype as draft-li-dnsext-ipv4-ipv6, but another potential variant of RRGQ that uses a traditiona Data RRtype in the query section (plus the same EDNS option to indicate the desired Data RRtypes) has been explained later, near the end of a follow-up message [2]. Among the possible applications motivating the proposal and mentioned in the thread were DNSBLs and mail policy records (as you mention). This proposal has been discussed on the list during the Hiroshima IETF timeframe (see the thread started with [1], and shortly in the DNSEXT session in Hiroshima. However, unfortunately I never happened to fully write up this idea as an I-D, but Ray Bellis' dnsext-multy-qtypes draft revives it now (with some variation in the encoding of the EDNS option). This solution -- although not "perfect" or "optimally coded" in the present DNS protocol (with EDNS) -- might have the potential to find enough traction to allow relatively fast deployment, eased by its property that it has save fallback to traditional behavior with servers that support EDNS0. The obstacle to fast automatic fallback with responders that do not support EDNS0 due to the rule in RFC 2671[bis] that such responders MUST signal FormErr to query messages carrying an EDNS OPT RR -- unlike in the case of unknown EDNS options (that are to be ignored) is likely to be less of a problem now, because the increase in response sizes expected, and corresponding normative requirements to support EDNS0, for IPv6 and DNSSEC, has lead to now widespread support for EDNS0. So stakeholders interested in a tractable solution who do not want to wait for some future "dns-ng" allowing this (and much more) in some optimal way are invited to chime in and follow up in the discussion of draft-bellis-dnsext-multi-qtypes on the dnsext list! References to ancient messages on RRGQ -- once sent to the late namedroppers list, and now archived in the dnsext list archive: [1] http://www.ietf.org/mail-archive/web/dnsext/current/msg05291.html [2] http://www.ietf.org/mail-archive/web/dnsext/current/msg05305.html Please follow the entire thread to evaluate the raised point-of-views. Recent messages on multi-qtypes : http://www.ietf.org/mail-archive/web/dnsext/current/msg12398.html http://www.ietf.org/mail-archive/web/dnsext/current/msg12403.html Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From internet-drafts@ietf.org Fri Mar 30 02:36:22 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747A321F8925; Fri, 30 Mar 2012 02:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPzVIRXUc3VJ; Fri, 30 Mar 2012 02:36:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164AB21F88C9; Fri, 30 Mar 2012 02:36:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120330093622.27470.57719.idtracker@ietfa.amsl.com> Date: Fri, 30 Mar 2012 02:36:22 -0700 Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc4641bis-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:36:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Domain Name System Operations Working= Group of the IETF. Title : DNSSEC Operational Practices, Version 2 Author(s) : Olaf M. Kolkman W. (Matthijs) Mekking Filename : draft-ietf-dnsop-rfc4641bis-10.txt Pages : 78 Date : 2012-03-30 This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-10.txt From ondrej.sury@nic.cz Fri Mar 30 03:09:14 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D6421F86B5 for ; Fri, 30 Mar 2012 03:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCsRpXkQBE2D for ; Fri, 30 Mar 2012 03:09:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BDA4321F8690 for ; Fri, 30 Mar 2012 03:09:12 -0700 (PDT) Received: from [IPv6:2001:df8::96:70e4:97af:392a:a0d0] (unknown [IPv6:2001:df8:0:96:70e4:97af:392a:a0d0]) by mail.nic.cz (Postfix) with ESMTPSA id A71AE141260; Fri, 30 Mar 2012 12:09:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1333102151; bh=FE50SvH5Cpgexr4xKcg3dIiBQv3mA/q24blLotCp2bw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qoA0+oLnnFGJHSFQwiPkrdGAkkOppSNEUU+AKDhV0LDrOL2eY/VDLNca+KGSBcG1X jZOymJi862gjsf7rGJwnDVMZ8WsnX5DLZUiL6fJAVvn4bGun8XEKyilNhZ//Uw6MFs +z2TJJlTkEXyOYA8GjvMd2E5e6uEvwbJmkjkUtwA= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 30 Mar 2012 12:09:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> <017101ccefd5$51790560$f46b1020$@lampo@eurid.eu> To: Joseph Gersch X-Mailer: Apple Mail (2.1257) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dnsop@ietf.org Subject: Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:09:14 -0000 Hi Joseph, since I am not sure if you understood my point (I am not sure if I was = able to understand it myself :), I am summarizing it to the mailing list. I like the direction of your work, but I miss a way how to put more = stuff under the named prefix. I would like you to update RFC2317 together with your document, so the = end customers don't have two distinct trees in their DNS infrastructure. F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have = delegate it to the customer, how do I put my PTRs in? The block owner would = still have to delegate another "dummy" prefix with CNAMEs and you have to handle it = in separate zone. BTW one more observation. Since you don't have to do any zone cuts in = the binary part, why not merge them into just one label? E.g. something like = 10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa. O. On 20. 2. 2012, at 23:33, Joseph Gersch wrote: > Hello Marco, >=20 > Thanks for reading and commenting on our draft. We have a couple of = weeks to make corrections to draft-00 before they get frozen for the = IETF meeting. We appreciate your pointing out the typos (we found the = ipv6 one ourselves, oops.....) and the suggestions for clarification. >=20 > This draft on CIDR naming is mainly focused on proposing a simple, = direct way to name CIDR addresses and eliminates the need for CNAME = indirection. It can be used for a number of purposes. >=20 > Regarding the intro on pre-populating the reverse-DNS... you are = correct, this is a draft on CIDR naming, not on fixing that particular = IPv6 issue. We will make that clarification in our next draft. The = ipv6 issue "might" be able to be addressed with this approach, but more = thought needs to be put in to it before a complete solution could be = proposed. We were mentioning this issue in order to give multiple = examples of the reasons why CIDR naming is a useful concept. >=20 > Again, thanks, > - Joe Gersch and Dan Massey >=20 >=20 > On Feb 20, 2012, at 6:41 AM, Marc Lampo wrote: >=20 >> Hello, >>=20 >> (sorry =E2=80=93 previously sent email was not finished =E2=80=A6) >>=20 >> Some =E2=80=9Ctypographic=E2=80=9D remarks : >> 1) 5.2 IPv4 Address Block Naming =E2=86=92 IPv6 Address Block Naming >> 2) In 5.2 there are 2 examples that have missing =E2=80=9C::=E2=80=9D, >> (2607:fa88:8000:/33 =E2=86=92 2607:fa88:8000::/33 and >> 2607:fa88:8000:/35 =E2=86=92 2607:fa88:8000::/35) >> in 5.3 there is 1 example with missing =E2=80=9C::=E2=80=9D. >> (2607:fa88:8000:/36 =E2=86=92 2607:fa88:8000::/36) >>=20 >> About =E2=80=9Ccontent=E2=80=9D : >> 1) 3. Design Requirement =E2=86=92 2. Coverage Authority. >> =E2=80=9CAny =E2=80=A6 with a data record or NXDOMAIN =E2=80=A6=E2=80=9D= >> to be completed with : NODATA >> =E2=86=92 =E2=80=9CAny =E2=80=A6 with a data record or NODATA or = NXDOMAIN =E2=80=A6=E2=80=9D >>=20 >> 2) In 5.2 IPv6 Address Block Naming >> Why not add some examples to show conversion from a reverse-DNS name = back to=20 >> CIDR ? >> (just like in 5.1) >>=20 >> Globally : >> 1) It is implied by the content of the present draft, >> but should it be stated (in Design Requirements) >> that the proposal should be valid for both IPv4 and IPv6 addresses ? >>=20 >> 2) In the Introduction, where you correctly state that ISP=E2=80=99s = pre-populate=20 >> reverse DNS, >> the problem is stated that the approach of pre-populating does not = scale for=20 >> IPv6. >> However, by itself, this draft does not solve that problem, does it ? >> (needs programmatic support) >> (this example in the Introduction made me think/assume that this = draft >> also applies to =E2=80=9Csimple=E2=80=9D reverse mapping. In which = case I wondered how >> this draft does away with CNAME (a la RFC 2317). >> But then, after rereading it occurred to me that this draft is about=20= >> storing >> CIDR info in revdns. >> =E2=86=92 isn=E2=80=99t it confusing to give, in the intro, an = example that does not apply=20 >> to CIDR info ? >> (it got at least me confused, not that I=E2=80=99d want to be taken = as a reference=20 >> ;-) >>=20 >> Kind regards, >>=20 >> Marc Lampo >> Security Officer >> EURid >>=20 >>=20 >> From: Joseph Gersch [mailto:joe.gersch@secure64.com] >> Sent: 17 February 2012 06:17 PM >> To: dnsop@ietf.org >> Subject: [DNSOP] Fwd: New Version Notification for=20 >> draft-gersch-dnsop-revdns-cidr-00.txt >>=20 >> All, >> we have submitted a new draft that will be presented at the Paris = IETF=20 >> meeting. >> Please take the time to send any comments and suggestions regarding = this=20 >> idea on naming CIDR address blocks in the Reverse DNS. >>=20 >> Best regards, >> - Joe Gersch and Dan Massey >>=20 >>=20 >> Begin forwarded message: >>=20 >>=20 >> From: internet-drafts@ietf.org >> Date: February 16, 2012 5:09:18 PM MST >> To: joe.gersch@secure64.com >> Cc: joe.gersch@secure64.com, massey@cs.colostate.edu >> Subject: New Version Notification for = draft-gersch-dnsop-revdns-cidr-00.txt >>=20 >> A new version of I-D, draft-gersch-dnsop-revdns-cidr-00.txt has been=20= >> successfully submitted by Joe Gersch and posted to the IETF = repository. >>=20 >> Filename: draft-gersch-dnsop-revdns-cidr >> Revision: 00 >> Title: Reverse DNS Naming Convention for CIDR Address = Blocks >> Creation date: 2012-02-14 >> WG ID: Individual Submission >> Number of pages: 19 >>=20 >> Abstract: >> The current reverse DNS naming method is used to specify a complete >> IP address. It has not been used to handle address ranges; for >> example, there is no formal mechanism for specifying a reverse DNS >> name for the block of addresses specified by the IPv4 prefix >> 129.82.0.0/16. Defining such a reverse DNS naming convention would >> be useful for a number of applications. These include applications >> for secure BGP routing, and applications that need host-information >> for a device owning a complete IPv6 address block. This draft >> proposes a naming convention for encoding CIDR address blocks in the >> reverse DNS. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >> Joseph Gersch >> Chief Operating Officer >> Secure64 Software Corporation >>=20 >>=20 >>=20 >=20 > Joseph Gersch > Chief Operating Officer > Secure64 Software Corporation >=20 >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From Ray.Bellis@nominet.org.uk Fri Mar 30 03:19:47 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E3A21F894B for ; Fri, 30 Mar 2012 03:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.25 X-Spam-Level: X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+-aEM6PZPtS for ; Fri, 30 Mar 2012 03:19:46 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6762021F891A for ; Fri, 30 Mar 2012 03:19:46 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=kY5Szk2TOQFN3dRJ8HfdZAjFtSLiPWcD5WIHaL0NN9qpYW02ns+RSWuI HYx9M2oHaKVKgLiAC7nc/cIuVUcg1d67RTwMZV3MVkoQMGNVdUjbNDDLa H2LtbhD7Y5JQUnU; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1333102786; x=1364638786; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[DNSOP]=20New=20Version=20Notification =20for=0D=0A=09draft-gersch-dnsop-revdns-cidr-00.txt |Date:=20Fri,=2030=20Mar=202012=2010:19:43=20+0000 |Message-ID:=20<2C012FE1-A40D-473F-89D8-52673182A581@nomi net.org.uk>|To:=20=3D?utf-8?B?T25kxZllaiBTdXLDvQ=3D=3D? =3D=20|CC:=20"dnsop@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20base64|Content-ID:=20|In-Reply-To:=20|References:=20<20120 217000918.22307.43753.idtracker@ietfa.amsl.com>=0D=0A=20< 2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com>=0D=0A =20<017101ccefd5$51790560$f46b1020$@lampo@eurid.eu>=0D=0A =20=0D =0A=20; bh=N4SUXNnRuOcgDnkZn0bg3OS+0yMYmmjPr6NVOp55pnI=; b=xaakfYE1iQJ4fB1hFJxZNyHVS4eS4F8HjRGzNYYJoVbulGXb11GpaUH0 KBPfyYUf21WUf+Yii6eITyc7aUft2sC4ofO/7Or6Z//q5uD0bp7LdBwlG u4fHu3DRiZaGraU; X-IronPort-AV: E=Sophos;i="4.75,343,1330905600"; d="scan'208";a="32260397" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 30 Mar 2012 11:19:45 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Fri, 30 Mar 2012 11:19:44 +0100 From: Ray Bellis To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= Thread-Topic: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt Thread-Index: AQHNDl02iNxAl6YiKkK0tj1P/kJikZaCj8GA Date: Fri, 30 Mar 2012 10:19:43 +0000 Message-ID: <2C012FE1-A40D-473F-89D8-52673182A581@nominet.org.uk> References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> <017101ccefd5$51790560$f46b1020$@lampo@eurid.eu> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:19:47 -0000 DQpPbiAzMCBNYXIgMjAxMiwgYXQgMTI6MDksIE9uZMWZZWogU3Vyw70gd3JvdGU6DQoNCj4gSGkg Sm9zZXBoLA0KPiANCj4gc2luY2UgSSBhbSBub3Qgc3VyZSBpZiB5b3UgdW5kZXJzdG9vZCBteSBw b2ludCAoSSBhbSBub3Qgc3VyZSBpZiBJIHdhcyBhYmxlDQo+IHRvIHVuZGVyc3RhbmQgaXQgbXlz ZWxmIDopLCBJIGFtIHN1bW1hcml6aW5nIGl0IHRvIHRoZSBtYWlsaW5nIGxpc3QuDQo+IA0KPiBJ IGxpa2UgdGhlIGRpcmVjdGlvbiBvZiB5b3VyIHdvcmssIGJ1dCBJIG1pc3MgYSB3YXkgaG93IHRv IHB1dCBtb3JlIHN0dWZmIHVuZGVyDQo+IHRoZSBuYW1lZCBwcmVmaXguDQo+IA0KPiBJIHdvdWxk IGxpa2UgeW91IHRvIHVwZGF0ZSBSRkMyMzE3IHRvZ2V0aGVyIHdpdGggeW91ciBkb2N1bWVudCwg c28gdGhlIGVuZA0KPiBjdXN0b21lcnMgZG9uJ3QgaGF2ZSB0d28gZGlzdGluY3QgdHJlZXMgaW4g dGhlaXIgRE5TIGluZnJhc3RydWN0dXJlLg0KDQorMQ0KDQo+IEYuZS4gaWYgSSBoYXZlIDEuMC5t LjgyLjEyOS5pbi1hZGRyLmFycGEgcHJlZml4IGluIHRoZSBETlMgYW5kIEkgaGF2ZSBkZWxlZ2F0 ZQ0KPiBpdCB0byB0aGUgY3VzdG9tZXIsIGhvdyBkbyBJIHB1dCBteSBQVFJzIGluPyAgVGhlIGJs b2NrIG93bmVyIHdvdWxkIHN0aWxsIGhhdmUNCj4gdG8gZGVsZWdhdGUgYW5vdGhlciAiZHVtbXki IHByZWZpeCB3aXRoIENOQU1FcyBhbmQgeW91IGhhdmUgdG8gaGFuZGxlIGl0IGluDQo+IHNlcGFy YXRlIHpvbmUuDQo+IA0KPiBCVFcgb25lIG1vcmUgb2JzZXJ2YXRpb24uICBTaW5jZSB5b3UgZG9u J3QgaGF2ZSB0byBkbyBhbnkgem9uZSBjdXRzIGluIHRoZSBiaW5hcnkNCj4gcGFydCwgd2h5IG5v dCBtZXJnZSB0aGVtIGludG8ganVzdCBvbmUgbGFiZWw/ICBFLmcuIHNvbWV0aGluZyBsaWtlIDEw Lm0uODIuMTI5LmluLWFkZHIuYXJwYSBvciAxMDAwMTEwMS5tLjgyLjEyOS5pbi1hZGRyLmFycGEu DQoNCldpdGggdGhlIGN1cnJlbnQgc2NoZW1lIGl0J3MgcG9zc2libGUgdG8gZGVsZWdhdGUgbG9u Z2VyIHByZWZpeGVzLCBhbmQgdGhpcyBpcyBhIG5lY2Vzc2FyeSBmZWF0dXJlLg0KDQpUaGUgc3R1 ZmYgRGFuIHdhcyBzYXlpbmcgYWJvdXQgdHdvIGFsdGVybmF0ZSByZXByZXNlbnRhdGlvbnMgY29u Y2VybnMgbWUsIHRob3VnaC4gIEFzIHdyaXR0ZW4sIGJ5IGRlZmF1bHQ6DQoNCiAgMTkyLjE2OC42 NC8xOCBpcyAxLjAubS4xNjguMTkyDQoNCmJ1dA0KDQogIDE5Mi4xNjguNjQvMjQgaXMgNjQuMTY4 LjE5Mg0KDQp3aGljaCBpcyBub3QgYSBzdWItZG9tYWluIG9mIHRoZSBlbmNsb3NpbmcgLzE4IHJl cHJlc2VudGF0aW9uLg0KDQpUaGlzIHdheSBsaWVzIGRyYWdvbnMsIEkgdGhpbmsuLi4NCg0KUmF5 DQoNCg== From fneves@registro.br Fri Mar 30 03:27:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E921F869C for ; Fri, 30 Mar 2012 03:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeaR6EDSuPvT for ; Fri, 30 Mar 2012 03:27:33 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id D9DDA21F84F3 for ; Fri, 30 Mar 2012 03:27:32 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 36D74E04A0; Fri, 30 Mar 2012 07:27:32 -0300 (BRT) Date: Fri, 30 Mar 2012 07:27:32 -0300 From: Frederico A C Neves To: Ray Bellis Message-ID: <20120330102732.GA61566@registro.br> References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> <017101ccefd5$51790560$f46b1020$@lampo@eurid.eu> <2C012FE1-A40D-473F-89D8-52673182A581@nominet.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2C012FE1-A40D-473F-89D8-52673182A581@nominet.org.uk> Cc: Ond??ej =?iso-8859-1?Q?Sur=FD?= , "dnsop@ietf.org" Subject: Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 10:27:33 -0000 On Fri, Mar 30, 2012 at 10:19:43AM +0000, Ray Bellis wrote: > > On 30 Mar 2012, at 12:09, Ond??ej Surý wrote: > > > Hi Joseph, > > > > since I am not sure if you understood my point (I am not sure if I was able > > to understand it myself :), I am summarizing it to the mailing list. > > > > I like the direction of your work, but I miss a way how to put more stuff under > > the named prefix. > > > > I would like you to update RFC2317 together with your document, so the end > > customers don't have two distinct trees in their DNS infrastructure. > > +1 I'm not quite sure 2317 can be used for shorter prefixes but it's actually only seen in the wild for /25 onwards. The proposed idea works for any prefix outside the 8 or 4 bit boundary depending on what family we are talking. > > F.e. if I have 1.0.m.82.129.in-addr.arpa prefix in the DNS and I have delegate > > it to the customer, how do I put my PTRs in? The block owner would still have > > to delegate another "dummy" prefix with CNAMEs and you have to handle it in > > separate zone. > > > > BTW one more observation. Since you don't have to do any zone cuts in the binary > > part, why not merge them into just one label? E.g. something like 10.m.82.129.in-addr.arpa or 10001101.m.82.129.in-addr.arpa. > > With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature. > > The stuff Dan was saying about two alternate representations concerns me, though. As written, by default: > > 192.168.64/18 is 1.0.m.168.192 > > but > > 192.168.64/24 is 64.168.192 > > which is not a sub-domain of the enclosing /18 representation. > > This way lies dragons, I think... If your parent have't made their mind I agree with you, but this is very unlekely. > Ray Fred From paul@redbarn.org Fri Mar 30 06:51:52 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB71721F85DB for ; Fri, 30 Mar 2012 06:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S8iLjGEiGNT for ; Fri, 30 Mar 2012 06:51:52 -0700 (PDT) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F69C21F85EA for ; Fri, 30 Mar 2012 06:51:52 -0700 (PDT) Received: from [192.168.127.231] (host.37.100.23.62.rev.coltfrance.com [62.23.100.37]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.com (Postfix) with ESMTPSA id 0CB03EBC93; Fri, 30 Mar 2012 13:51:49 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <4F75BA74.2070008@redbarn.org> Date: Fri, 30 Mar 2012 13:51:48 +0000 From: paul vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ray Bellis References: <20120217000918.22307.43753.idtracker@ietfa.amsl.com> <2D04DB88-9570-4DE3-A796-F4F07AF5EF74@secure64.com> <017101ccefd5$51790560$f46b1020$@lampo@eurid.eu> <2C012FE1-A40D-473F-89D8-52673182A581@nominet.org.uk> In-Reply-To: <2C012FE1-A40D-473F-89D8-52673182A581@nominet.org.uk> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , "dnsop@ietf.org" Subject: Re: [DNSOP] New Version Notification for draft-gersch-dnsop-revdns-cidr-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:51:53 -0000 On 3/30/2012 10:19 AM, Ray Bellis wrote: > With the current scheme it's possible to delegate longer prefixes, and this is a necessary feature. > > The stuff Dan was saying about two alternate representations concerns me, though. As written, by default: > > 192.168.64/18 is 1.0.m.168.192 > > but > > 192.168.64/24 is 64.168.192 > > which is not a sub-domain of the enclosing /18 representation. > > This way lies dragons, I think... +1. thus my earlier observation: RFC 1101 supports classless networks even though it didn't mean to. RFC 2317 is entirely compatible with RFC 1101 (there's only one delegation tree covering both.) if there's a need for a new netblock-specific DNS schema like the one in the gersch draft, then i recommend learning from what we did in RPZ, where the prefix size is _always_ given as are all octets of the mantissa except the "::" longest-zero string which is given as ".zz.". more information about RPZ can be had from: https://deepthought.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html and specifically from: https://deepthought.isc.org/article/AA-00512/0 which has the actual spec, in .txt and .pdf format.