From owner-namedroppers@ops.ietf.org Wed Aug 1 10:12:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04428 for ; Wed, 1 Aug 2001 10:12:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RwRx-000DBr-00 for namedroppers-data@psg.com; Wed, 01 Aug 2001 06:54:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RwRw-000DBl-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 06:54:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RwRw-000KoP-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 06:54:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: namedroppers@ops.ietf.org Subject: list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 01 Aug 2001 06:54:13 -0700 Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. the general topic of mailing list moderation is a topic for the poisson wg. poisson's charter can be found at questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e, followup with area directors, then iesg, etc.). --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 1 10:13:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04444 for ; Wed, 1 Aug 2001 10:13:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RwVQ-000DGh-00 for namedroppers-data@psg.com; Wed, 01 Aug 2001 06:57:48 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RwVQ-000DGb-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 06:57:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RwVQ-000KvP-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 06:57:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <2914.996582086@brandenburg.cs.mu.OZ.AU> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 01 Aug 2001 06:57:48 -0700 Content-Transfer-Encoding: 7bit Date: Tue, 31 Jul 2001 16:17:17 -0700 From: "D. J. Bernstein" Message-ID: | In the aol.com example, the sysadmin sets up dns-01.ns.aol.com A6 ... | prefix.aol.net, and similarly dns-02.ns.aol.com A6 ... prefix.aol.net. | What's ``ludicrous'' about that? It's exactly what the A6 specifications | encourage him to do. The A6 specs don't encourage anything. They indicate some ways that A6 might perhaps be used. It also says that for NS records, A6 0 should be used... | But it destroys connectivity to AOL. Even though this fictional example doesn't follow the suggestions for NS records, it only "destroys connectivity" when accompanied with one perverse method of ignoring "glue". What's more, one method which isn't even consistent with its proponent's views of how the DNS ought to have been designed. With any reasonable implementation, the setup described would work. [Aside: it really would be better to use fictional domains - like example.com or .xx for illustrative purposes, as best I can tell, AOL have never deployed A6 records this way, however dumb some of their other DNS setups might have been] | All the efficiency issues are minor. The reliability issues are crucial. Reliability is important. Yes. But we cannot go to the extreme of preferring reliability over everything else - if we did, the DNS protocol would probably require a database retained at every node, containing a complete list of all the other nodes on the internet and their addresses (etc). That way, lookups would never fail, and they'd be as quick as we care to make them. We could even call that database HOSTS.TXT. | The A6 proponents keep claiming that a limited form of A6 is safe, but | they never answer when I ask them to identify the exact limitation that | has this magical effect. Because there is none. A6 is safe in any event. But just like NS, etc, some configurations make more sense than others (are more likely to work in more environments). | How is the DNS administrator supposed to tell | the difference between ``ludicrous'' A6 records and normal A6 records? Valid point - we certainly need more written on how to use A6 well. That's some of what I am hoping to achieve in the near future - after the experiments have actually been done that collect the data that will have been analysed so as to actually have some basis for giving this kind of advice. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 1 10:28:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05301 for ; Wed, 1 Aug 2001 10:28:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RwlD-000Dib-00 for namedroppers-data@psg.com; Wed, 01 Aug 2001 07:14:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RwlD-000DiV-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 07:14:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RwlD-000LRx-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 07:14:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 01 Aug 2001 07:14:07 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > it only "destroys connectivity" when accompanied with one > perverse method of ignoring "glue". This ``perverse method'' has been used by all versions of BIND since 1997, and of course by every version of my cache. The need for it is explained in detail in http://cr.yp.to/djbdns/notes.html. > as best I can tell, AOL have never deployed A6 records this way Of course they haven't. We have a wonderful opportunity to abort the A6 and DNAME proposals before anyone starts relying on them. > for NS records, A6 0 should be used... How is that going to be enforced? How is the DNS administrator supposed to know which machines might later be used as name servers? Are caches going to abort NS lookups that involve A6 indirection? What about all the other ways that A6 can lead to loops? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 1 10:36:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05895 for ; Wed, 1 Aug 2001 10:36:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RwuY-000E29-00 for namedroppers-data@psg.com; Wed, 01 Aug 2001 07:23:46 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RwuY-000E23-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 07:23:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RwuY-000Lm4-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 07:23:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <20010801124445.30844.qmail@cr.yp.to> References: <20010801124445.30844.qmail@cr.yp.to> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 01 Aug 2001 07:23:46 -0700 Content-Transfer-Encoding: 7bit Date: 1 Aug 2001 12:44:45 -0000 From: "D. J. Bernstein" Message-ID: <20010801124445.30844.qmail@cr.yp.to> | This ``perverse method'' has been used by all versions of BIND since | 1997, and of course by every version of my cache. The need for it is | explained in detail in http://cr.yp.to/djbdns/notes.html. I haven't looked to see whether BIND really does that or not, but there is certainly no need for it (and I actually doubt it a bit). To be more clear, the web page (originally) referred to suggests that the DNS should have originally used foo.example.com. IN NS 192.168.1.17 instead of foo.example.com. IN NS ns.example.com. ns.example.com. IN A 192.168.1.17 That is, advocating server resolution of indirection. If one were to assume that that is how things should be done, then one must also assume that a DNS packet containing foo.example.com. IN NS 192.168.1.17 encoded in some DNS format binary form would be acceptable. But apparently it isn't, if the DNS binary form is ... foo.example.com. IN NS trash-name. trash-name. IN A 192.168.1.17 where the 2nd occurrence of "trash-name." is, of course, just a pointer back to the first one using internal DNS name compression techniques. Given the currently adopted format for DNS packets, which contains a (compressible) label as the value of a NS RR, encoding the server side resolution of the NS record indirection in this (2 RR) way is the obvious thing to do - it retains compatability with the rest of the deployed DNS. The pair of RRs given there allow the IP address of the nameserver for the foo.example.com. domain to be located, which is what is needed to actually use it to lookup names in the foo.example.com. domain of course. That's exactly the same as if the NS record had contained the address in the first place. The two encoding methods are isomorphic. For anyone to seriously claim that server side resolution of the indirection is the way things should be done, and that for some security or reliability related reason, this cannot be be made to work, begs credulity. Note: no-one said anything about caching the "trash-name. IN A .." record anywhere, or using it for any purpose at all, other than for finding the address of the nameserver for the domain. This works for NS records, it works for A6, it works for anything else, and is exactly as reliable and secure as would putting all of the data into one RR. The only difference is in the cases where the extra A record is not included with the original response, which is a deliberate choice to trade off some extra round trips (queries) (and hence lower reliability a little) for the extra flexibility it gives. | > for NS records, A6 0 should be used... | How is that going to be enforced? I didn't say it needed to be enforced - I was reacting to the suggestion that people were being encouraged to use A6 in the way your web page suggests. But if it were to be enforced, the place to do it would be when the delegation is done. eg: right now, if you attempt to delegate a domain in a zone I manage, your listed NS list will be checked, and if any of those is a CNAME, rather than having an A record (for IPv4 delegations) then I simply won't do the delegation. You either give the name an A record, or use a different NS name, or your domain isn't delegated. For IPv6 I can, if I desire, simply check that the A6 record of the NS is an A6 0 format - if that turns out to be the right thing to do (which the A6 RFC suggests it probably will be, but until we get it tested it is hard to know for sure). | Are caches going to abort NS lookups that involve A6 indirection? I expect not, as they don't necessarily abort NS lookups when a CNAME is found. That the resolver (a cache is just a storage mechanism for results that have been obtained previously, it is the resolver that is doing the lookup) is able to translate the name doesn't mean that it is the way that it should be deployed. | What about all the other ways that A6 can lead to loops? They will result in lookup failures - just as do CNAME loops, and NS loops, and all of the other ways that people can shoot themselves. If you want your names to be useful for people, you make sure they're entered in a way that works. If you don't care, then you don't, and people won't be able to use your name. That's the way it is now, it is the way it should remain. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 1 10:39:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06108 for ; Wed, 1 Aug 2001 10:39:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RwwZ-000E66-00 for namedroppers-data@psg.com; Wed, 01 Aug 2001 07:25:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RwwZ-000E60-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 07:25:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RwwZ-000LqW-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 07:25:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: itojun@iijlab.net To: Robert Elz Cc: Olafur Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, Alain Durand , ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-reply-to: kre's message of Tue, 31 Jul 2001 07:42:36 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 01 Aug 2001 07:25:51 -0700 Content-Transfer-Encoding: 7bit > | 4 Jun-ichiro itojun Hagino : > | >This one contains a bunch of info on the current state of the world, >followed by a large amount of FUD. There's essentially nothing in it >of value to the discussion. I could analyse this doc paragraph by >paragraph, and was once planning to do so - but I think that would be >a waste of everyone's time. plesae comment paragraphs one by one, or drop the assertion that it is a FUD. i wrote this because i believe there are serious problems with respect to the deployment as well as operation. if you don't get the problem, please say so (and I will need to describe it better). if you saw any mistakes in the draft. please say so (and i will need to correct those points, or describe them better). it's not productive to assert someone's draft as a FUD! itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 1 15:19:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29031 for ; Wed, 1 Aug 2001 15:19:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15S0yz-000Ja9-00 for namedroppers-data@psg.com; Wed, 01 Aug 2001 11:44:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15S0yy-000Ja2-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 11:44:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15S0yy-0003wT-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 11:44:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> <20010801124445.30844.qmail@cr.yp.to> <2862.996673933@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 01 Aug 2001 11:44:37 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > For anyone to seriously claim that server side resolution of the > indirection is the way things should be done, and that for some > security or reliability related reason, this cannot be be made to > work, begs credulity. You are, as usual, massively confused. The reliability problems are not caused by the normal anti-poisoning rules. The problems are caused by servers that DO NOT HAVE ALL THE INFORMATION THE CLIENT NEEDS. For example, when a .com server says barclays.com NS ns1.barclays.co.uk, the client has to go look up the ns1.barclays.co.uk address. Is this because the client is protecting itself against poison? No. It's because the .com servers DO NOT HAVE THAT ADDRESS. Server-side indirection means that the server _does_ have the address. In this case, the server can easily use an in-bailiwick name for the address, so the normal anti-poisoning rules once again have no effect. The client avoids the extra lookups and the possibility of loops. The reason I recommend in-bailiwick names within the existing DNS architecture is that those names force the server to collect the address. Putting IP addresses into NS records directly would have the same beneficial effect. Summary: * Good situation: The server has the information. * Bad situation: The server doesn't have the information. The bad situation produces reliability problems. The point of A6 and DNAME is to move from the good situation to the bad situation; this is why I oppose A6 and DNAME. Of course, all of this is already explained on my web page. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 1 15:35:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29869 for ; Wed, 1 Aug 2001 15:35:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15S1VL-000KcB-00 for namedroppers-data@psg.com; Wed, 01 Aug 2001 12:18:03 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15S1VL-000Kc4-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 12:18:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15S1VL-00052V-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 12:18:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: namedroppers@ops.ietf.org Cc: lewis@tislabs.com Subject: DNSSEC status meeting at 51st IETF Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 01 Aug 2001 12:18:03 -0700 Content-Transfer-Encoding: 7bit There will be an open meeting of folks working on experiments and/or implementations in Hilton Rooms 9/10 on Tuesday at 1830-1930. This is different from the DNSSEC topic in the DNSEXT meeting as the Subj: meeting is an implementation/experimentation status meeting, as opposed to a specifications discussion. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 1 16:12:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02511 for ; Wed, 1 Aug 2001 16:12:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15S1yr-000LNg-00 for namedroppers-data@psg.com; Wed, 01 Aug 2001 12:48:33 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15S1yr-000LNa-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 12:48:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15S1yr-00062o-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 12:48:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roy Arends To: Olafur Gudmundsson Cc: , DNSEXT mailing list Subject: Re: 51 IETF DNSEXT meeting Agenda In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 01 Aug 2001 12:48:33 -0700 Content-Transfer-Encoding: 7bit On Mon, 30 Jul 2001, Olafur Gudmundsson wrote: > 10 min No SIG Roy Arens > I won't be at the upcoming IETF in London. Regards, Roy Arends to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 1 18:07:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07001 for ; Wed, 1 Aug 2001 18:07:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15S3H1-000NMR-00 for namedroppers-data@psg.com; Wed, 01 Aug 2001 14:11:23 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15S3H1-000NML-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 14:11:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15S3H1-0008jM-00 for namedroppers@ops.ietf.org; Wed, 01 Aug 2001 14:11:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: gson@nominum.com (Andreas Gustafsson) To: Robert Elz Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <20010801124445.30844.qmail@cr.yp.to> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Wed, 01 Aug 2001 14:11:23 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > From: "D. J. Bernstein" > | This ``perverse method'' has been used by all versions of BIND since > | 1997, and of course by every version of my cache. The need for it is > | explained in detail in http://cr.yp.to/djbdns/notes.html. > > I haven't looked to see whether BIND really does that or not, but there > is certainly no need for it (and I actually doubt it a bit). This time, DJB is correct. When resolving, BIND 8 and 9 do reject all records that are not within the domain whose authoritative qservers are being queried. If they did not, we would be seeing much more cases of cache poisoning that we do now. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 11:30:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02107 for ; Thu, 2 Aug 2001 11:30:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJ1v-000ADp-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:00:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJ1o-000ADO-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:00:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJ07-000Dcr-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 06:58:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Greg Hudson To: gson@nominum.com (Andreas Gustafsson) cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: Your message of "Wed, 01 Aug 2001 14:11:23 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:00:51 -0700 Content-Transfer-Encoding: 7bit > This time, DJB is correct. When resolving, BIND 8 and 9 do reject > all records that are not within the domain whose authoritative > qservers are being queried. If they did not, we would be seeing > much more cases of cache poisoning that we do now. To be precise: to avoid cache poisoning, out of domain records must not be used for future queries. There is no problem with using them for the purpose of the current query, although that may be considered too complicated to implement. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 11:50:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02827 for ; Thu, 2 Aug 2001 11:50:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJdn-000BcD-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:39:59 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJdm-000Bc7-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:39:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJdm-000Elr-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:39:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: gson@nominum.com (Andreas Gustafsson) cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <20010801124445.30844.qmail@cr.yp.to> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:39:59 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 01 Aug 2001 14:11:23 -0700 From: gson@nominum.com (Andreas Gustafsson) Message-ID: | When resolving, BIND 8 and 9 do reject | all records that are not within the domain whose authoritative | qservers are being queried. That's broken, and should be fixed. If it really is as you have explained it, it guarantees that some perfectly legal DNS configurations can never be properly resolved. | If they did not, we would | be seeing much more cases of cache poisoning that we do now. How? No-one is suggesting that these records be put in the cache. How can the cache be poisoned without that? kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 11:51:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02904 for ; Thu, 2 Aug 2001 11:51:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJfX-000BiP-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:41:47 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJfX-000BiJ-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:41:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJfX-000EpC-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:41:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: itojun@iijlab.net To: Robert Elz Cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-reply-to: kre's message of Thu, 02 Aug 2001 17:25:40 +0700. <2019.996747940@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:41:47 -0700 Content-Transfer-Encoding: 7bit One last comment - you and I are not agreeing on the urgency of this. If we don't pick AAAA or A6 right now, we cannot deploy IPv6 NS records and/or IPv6 MX records, we cannot convince gTLDs/ccTLDs to accept IPv6 NS record registrations. The deadline for picking them up is at the London IETF. We wanted the choice like a couple of years ago. We operate commercial IPv6 backbone and selling services to customers since the summer of 1999. And we don't have an official choice of IPv6 DNS records? The situation is like a very very bad joke. We cannot wait forever. This way we can never deploy IPv6. (btw, I'm using no IPv4 from my laptop as I type this!) I appreciate your intent to do the analysis, but I cannot wait forever. We did the analysis and test operations, and the result is in my draft. I did my homework. > | So in your world unanswered questions are called "FUD"? >No, just unanswered questions whose point is to remain unanswered, and >thus just raise the fear of the unknown. The open questions in my drafts are intended to be answered, or get the consensus among people. This is not intended to be left ununsewered (What suggested you like that? Did I tell you so? how can can you assert like that without checking with me?). itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 11:51:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03008 for ; Thu, 2 Aug 2001 11:51:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJiP-000Bq5-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:44:45 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJiP-000Bpz-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:44:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJiP-000EuZ-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:44:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <14511.996750216@itojun.org> <2437.996752010@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:44:45 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > before it has even had a reasonable chance to be tested We're saying ``deployment will be a disaster, and here's why.'' You're saying ``let's deploy it and see what happens.'' That's unacceptable. A6 and DNAME need to be killed _before_ people start relying on them. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 11:54:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03139 for ; Thu, 2 Aug 2001 11:53:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJdU-000Bbc-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:39:40 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJdU-000BbW-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:39:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJdU-000ElC-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:39:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> <20010801124445.30844.qmail@cr.yp.to> <2862.996673933@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:39:40 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 01 Aug 2001 11:44:37 -0700 From: "D. J. Bernstein" Message-ID: | For example, when a .com server says barclays.com NS ns1.barclays.co.uk, | the client has to go look up the ns1.barclays.co.uk address. Is this | because the client is protecting itself against poison? No. It's because | the .com servers DO NOT HAVE THAT ADDRESS. What your web page said was ... Even if the address is provided, the cache won't accept it because .net addresses are not within the bailiwick of a .com server; this is the standard protection against poison. If the address is needed for correct operation, it is trivially easy for the COM server to be told it (or even go look it up, as a part of a server side indirection, other than the volume requirements in that particlar case). This is just standard glue processing (the way it is supposed to be done anyway). It is only this "standard protection against poison", which is totally bogus, as I showed in my last message, that would actually cause this to be a problem that can't easily be fixed. | Server-side indirection means that the server _does_ have the address. | In this case, the server can easily use an in-bailiwick name for the | address, so the normal anti-poisoning rules once again have no effect. But there's no poison involved, no-one ever said anything about putting anything in the cache. All that's relevant is that the address be associated with the NS record for the purposes of finding the nameserver, right now. What the name is should be 100% irrelevant. | The client avoids the extra lookups and the possibility of loops. And instead, the server does the extra lookups, and gets the possibility of loops? One of the design goals of many protocols (I wasn't around for the original DNS design, so I can't say for sure it was one here, but I wouldn't be surprised if it was) is to take the hard work away from the critical point, and distribute it. In this scenario, the DNS server is the critical point, the clients are distributed all over. DNS servers typically have lots of queries to answer - clients usually have nothing much else to do while doing the name lookup. Having the client do more work to make less work for the server is an attractive proposition - even if that means more overall work for the internet as a whole. | The reason I recommend in-bailiwick names within the existing DNS | architecture is that those names force the server to collect the | address. Putting IP addresses into NS records directly would have the | same beneficial effect. As my previous message showed, if implemented properly, any name can have the same benefit of the server knows the address, so can supply it. If the server doesn't know the address, then we're asking that the additional work be done at the point where it can be done with less impact. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 12:03:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03601 for ; Thu, 2 Aug 2001 12:03:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJlP-000BxV-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:47:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJlP-000BxP-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:47:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJlP-000F0I-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:47:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Tony Hain" Reply-To: To: "Robert Elz" , Cc: , , Subject: RE: Joint DNSEXT & NGTRANS agenda In-Reply-To: <2437.996752010@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:47:51 -0700 Content-Transfer-Encoding: 7bit Robert Elz wrote: > A couple of years ago we made the choice. That was A6. =20 > It has taken since then until about now (or even a bit=20 > beyond now) to get to the point where A6 can be deployed=20 >(when the implementations exist, etc). > This isn't a case where we have 2 competing proposals on=20 > a more or less equal footing, and want to choose one, its=20 > a case where we have an IETF consensus doc, and are now=20 > considering deprecating it, before it has even had a=20 > reasonable chance to be tested, and without doing any actual=20 > testing (that has been reported anyway) to suggest that=20 > it won't work. I have no doubt we could figure out how to make A6 work, and with a few = guidelines written up even keep it from being noticeably different. My = concern is that the basic premise for its need is explicitly = contradictory to economic realities. As much as people claim they need = to renumber their customers to compress the routing table, how many will = really tell the people paying them that to continue being a customer = they have to go through some level of routine pain? Even if it is only a = few records a couple of times a year, the customers will quickly bail = and find a provider that can deal with the entropy. This is just another = case of the point of pain not matching with the gain, so it simply won't = happen. Tony to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 12:05:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03731 for ; Thu, 2 Aug 2001 12:05:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJa0-000BTk-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:36:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJZz-000BTd-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:36:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJZz-000Eex-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:36:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: itojun@iijlab.net cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <11603.996735329@itojun.org> References: <11603.996735329@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:36:04 -0700 Content-Transfer-Encoding: 7bit Date: Thu, 02 Aug 2001 15:55:29 +0900 From: itojun@iijlab.net Message-ID: <11603.996735329@itojun.org> | Now I can respond to your comments, I'm very happy. First of all | I would like to thank for all the comments for all the paragraphs | (just for clarification - even if people don't agree with each other's | opinion, it is Japanese custom to thank for the effort itself in | the first place. "thank you" does not mean that I agree with you). OK, and thank you for the response. | Please note that, in i-d, there could be issues with my English skills | (like I'm asserting something I did not mean to assert, or I write | "must" where I should have used "may"). I think I understood it all OK, and I am pretty sure that none of my comments related to the wording (alone). | In short, I cannot believe how can you assert these problems as | just "FUD". This way there will be no progress. Not from that doc (nor from my response), that's true. That's why I really didn't want to go through all of this line by line - there's almost nothing of value to be gained from it. | In your comment it seems that you are using the word "FUD" for | "unanswered questions". I don't understand your choice of word, and | I really really object. Oh. "FUD" is "Fear Uncertainty and Doubt". Unanswered questions are uncertainty - one of the principal attributes of FUD. That is, "here are all these things we don't know (uncertainty), all kinds of things might go wrong (fear), we aren't sure this is right (doubt)". That's exactly what FUD is. I should have made that clear before, sorry. That is, FUD is an argument which goes along the lines of "we don't really understand this, so let's not do it". | Also, you are asking for evidence multiple times, for something noone | can possibly prove. I don't think that's so. I think that evidence can be collected. | This way of discussion is unfair, and I'd like | to ask you to try to prove them by yourself while I think about | them too. Yes, that is what I want to do. As I said, my response doesn't add anything to the debate about which of A6 and AAAA is best to use - all it was intended to do was to point out that your draft doesn't either. That's why I really didn't want to waste everyone's time with a lengthy message. | You also wrote some text that can be considered a FUD under your rule, That might be true too. | I don't feel the need to put multiple addresses onto the example here, | since in the following sections we don't use them much. Yes, I understand ... but also since it isn't used much, you could also have given a much simpler example - more along the lines of what a net with just a few nodes would actually use. Not that this matters much. | >> If we are to resolve IPv6 addresses using fragmented A6 records, we | >> need to query DNS multiple times to resolve a single DNS name into | >> an IPv6 address. | >should be "we might need to query". | | do you include "A6 0" case into "fragmented A6 records"? if so, | I can understand your wording change. Otherwise, I don't get it. No, I mean a response like A.MY.EXAMPLE. IN A6 64 B.MY.EXAMPLE. B.MY.EXAMPLE. IN A6 48 C.MY.EXAMPLE. C.MY.EXAMPLE. IN A6 0 . That is, we still have fragmented A6 records, but they're all from the same zone, and hence all can be included in the same response packet. No extra queries, no extra delay, and a packet that might be bigger and might be smaller, depending upon just what data is being included (or if you like, how many RRs actually exist in the RRsets for each of the 3 names above). This is the kind of usage I'd actually expect A6 to see - rather than having the domain names sprayed around all over the place, which is theoretically possible, but not really very likely in practice. | How can you ignore part of my text ("of the address itself") and assert | the lines as "not true"? This is totally unfair. A6 is the only | resource record type that composes a single address itself from | multiple query results. It is true. Yes, but it is irrelevant - it is just provoking fear. The technique of chasing DNS chains to get answers is as old as the DNS itself. | Again, I did not include "A6 0" into "fragmented A6 records" case. Nor did I. | This problem is not new but I believe it worth mentioning it. | If I do not mention it, readers would mistakenly think that it is | possible to parallelize the queries for A6 fragments. It is OK to say that, but you should also make it clear that it isn't new. Otherwise readers might mistakenly believe that this is some new problem that has never existed before. | Do you have problem with it? If I cannot things that are not new | how can I write up an analysis document. You need to make sure that you're not raising evils, which when investigated turn out to be just the same as what we have already, and which when viewed in that light don't look nearly as problematic. That is, almost all that you're worried about being possible with A6 is just as possible with A6. Yet in practice none of it actually bothers anyone. There should be a lesson in that. | With A6 the problem is more apparent as it is the only resource record | type which composes a single address out of multiple query results. Apart from being new (fear, doubt...) what's supposed to be significant about that? | For example, you can get a completely different IPv6 address out of | multiple queries, if you get part of A6 chains swapped with other item. | Assuming that this one is correct: | A6 64 ::t:u:v:w | A6 48 ::s:0:0:0:0 | A6 0 p:q:r:: | now if you get "A6 48 ::x:0:0:0:0", you will have a whole lot of fun. This is djb's argument - it is possible to configure A6 and blow yourself away. This is also not new to A6. It applies to lots of the DNS. Step back and look at your arguments more carefully, and you'll see that almost all of them could be made against using the DNS at all - except that the DNS is now familiar, everyone is used to it, and that it generally works pretty well, so it is much harder to be worried by anyone showing that in theory all kinds of things could go wrong. | The problem had not been obvious with other resource record types. | For other record types, we would get a completely correct answer, | or completely hosed answer. With A6 we would get a partially | correct answer (incorrect bits within a part of 128bit address). That's a completely hosed answer. This is no different than a CNAME chain that is accidentally pointed at the wrong place somewhere in the middle. That in the A6 case the bits returned happen to be built out of pieces returned from different records is really irrelevant - other than that it is new (fear of the unknown). | No, this is not a FUD. You are mixing up two different issues. | Because A6 is the only resource record type which composes a single | address out of multiple query results: | - for other record types, the result is binary - completely believable | or not. | - for A6, the result is not binary - part of bits can be believable, | part of bits can be not believable. No, this is nonsense. Either you get the right answer, or you have the wrong one. However many bits of the wrong one would have been correct under other circumstances is irrelevant. | This is from our implementation experiences. There are very few | people out there (I believe) who have actually implemented A6 | reassembly/decoding code, so I believe it worth mentioning. Try it | by yourself and see how many mistakes you will make due to the | bitwise manipulations. I didn't ever say that the code was easy to get right. What I said was that this is irrelevant. This code will only be written a handful of times through eternity. And while it might take a while to get right those few times, in the overall scheme of things, it simply doesn't matter. I have faith in your ability to debug the code, and to get it right... | No. Try to implement it into libc resolver (like BIND8) and | experience the pain we had. It isn't clear to me that a dumb resolver (like the libc one) should ever be doing this, or doing DNSSEC validation, or anything else like that. The very existence of such a thing is really an accident of history. The bind9 lwresd approach (in one form or another) was what was envisaged when the DNS was designed (a resolver/cache that all applications would share, rather than one that exists just for the purpose of a single name lookup, or two, after which it vanishes leaving no history). | Bitwise operations are so much more painful than 8-bit boundary | operations. Sure, but you do them, get them right, and forget them. | But how can you enforce that? Resolver side can protect themselves | by using the upper-limit, however, it is not possible to avoid | longer-than-limit A6 chains be placed onto the DNS zone files. No, it isn't. Nor is it possible to prevent CNAME chains that loop forever in the DNS zone files, or NS record chains that go on forever (consider a set of NS records each of which is 63 levels down some completely unrelated tree...) The point is that none of this is new - it is not something that we need to worry about specifically - we can already see from operational experience that it is perfectly possible to define things in such a way that they do work. Now if you were able to point to something in the A6 spec which guaranteed that these kinds of problems must occur, then you'd have a valid point. But just saying that it is possible for people to create stupid configurations is just causing fear - what matters is that it is possible to create configurations that have no problems. Or, if the point was that it is possible to create configurations that others could never escape from (ie: that it really is possible to create new DoS attacks) that would also be a valid point - but as you concede above, resolvers can easily protect themselves from this. | A6 fragments are likely to be maintained by different administrative | domains. "Likely"? Says who? | It is not likely that a single admin to control over the | whole A6 chain (otherwise, there's no benefit of A6 chain). Actually, I think it is likely, and there's lots of benefit from that. There are other possible benefits from allowing others to control the upper parts, but there are also costs in doing that. Until we get some operational experience with this, we simply don't know what is going to be reasonable to do, and what isn't. | If you define upper bits (than the part that have assigned to you, | like less than /48) you become less ready to renumber events. Of course. But that's what the policy that you postulated mandated. There are plenty of other ways to set things up to avoid that, and still keep A6, and still avoid building in addresses, what is going to be good to use in any particular case will depend upon the particular circumstances. | Therefore, the former one in your example will jeopardize the | renumbering benefits of A6. The latter one is better, however, I don't | think it manageable (can you prove it is manageable for random dumb | admins like me?). No, and even ignoring the "random dumb admin" comment, which I don't think applies to you at all, if you're not happy with configuring A6 fragments in a way that will work for you, for any reason at all, then you can just use A6 0, and you have essentially the same as you would if AAAA was all that was used. What this argument essentially amounts to is "I don't see the need for A6 for myself, I don't think I could use it, therefore you aren't allowed to use it either". I don't think I'll have any trouble at all configuring A6 in a way that will work just fine for me, and unless you can show some problem that I will cause to you by so doing, I'd appreciate it if you'd just allow me to do that. | If we take "A6 0" route, it is highly likely that vendors do not | bother to implement A6 chain chasing, or with a buggy reassembly | support. We just do some interop testing. Just as we have done for lots of other stuff in IPv6 (and elsewhere) which isn't really all that likely to be deployed in the real world very much (or not immediately). There's nothing new about this - there was a bunch of interop testing done for DNS dynamic updates for example, which uncovered a whole host of bugs in various implementations, long before anyone in the outside world was going anywhere near dynamic DNS. | These systems will be deployed into the real world, | and we will never be able to enable fragmented A6 usage. Therefore, | I consider "A6 0" approach be a complete waste of 1 byte per an | IPv6 record (you can never transition to fragmented A6 situation | so there's no benefit against AAAA). This is not a FUD. If there's no | operational needs, people won't bother to implement them. I still think you're misinterpreting the "A6 0" approach. It isn't that we tell everyone that they must use only "A6 0", and hence implementors need implement only that - it is that we tell people that they can use "A6 0", it will work 100% identically to AAAA (once A6 resolvers exist at all), and hence is perfectly safe to do. No-one will be melting down the internet with all the extra queries, or setting up names that no-one else will be able to use, or ... But anyone who wants to try it will still be able to use A6 n. | Now, can you predict how many people will have cache in stub resolvers | in year 2005? No, but that's also so near term as to barely be worth it anyway. (But my definition of a stub resolver is one that doesn't have cache, or recursive abilities, etc, anyway, so perhaps I can predict 0 as the answer using that definition.) | In this year, as BIND4/8 resolvers and other non-caching | resolver are around, cache deployment in the stub resolver (say, | for UNIX and Windows systems) is almost equal to zero. Yes. This was exactly my point in my response to your fears about what happens to people who define their A6 records with minute TTLs. | How long did you wait for this? No idea. Perhaps forever - it could be that we always have dumb stub resolvers, and back end resolvers. That might mean AAAA synthesis at that level forever. But so what? Who cares where it is done, the 128 bits of address have to be collected together somewhere. | I'm equally worried about A6 fragment reassembly code deployment. ie: I don't know that it is going to happen, hence we can't rely upon it. That's FUD. If you could show some reason why it will not happen, that would be different, but you can't (or aren't) - only that you aren't sure that it will. | I mentioned "A6 0" and "A6 non-zero" this just for clarity. How can | you assert it as a FUD? It is not a FUD, you just did not understand | (or I did not describe it well). Whether with AAAA synthesis the A6 records collected are A6 0 or A6 n makes no difference at all. But raising points of uncertainty makes the proposal look flawed. It isn't when the answer simply doesn't matter. That is, the only point for mentioning this is to increase the fear. That may not have been what you intended, but it is the outcome. | Maybe correct. However, when back end resolvers do not implement AAAA | synthesis, the AAAA queries will get propagated into servers for the zones. Yes, that's true. Most likely, to handle this, in the near term, sites will include both AAAA and A6 records for any names that they expect to be looked up by random others, where it isn't clear whether an AAAA or A6 query will arrive. That is, I'd do that for my mail server, FTP server, web server, etc - but I wouldn't bother for all my workstations, etc, as the only people I care about being able to find their addresses are local, and locally I know (or will know) that A6 records will work. This is just the same as what happened when MX records were introduced. Initially, everyone had to have A records for their mail domain as well as an MX record that indicted the server (and which would have had an A record). That was because mail servers (SMTP clients) were used to simply looking up the A record, and the simple deployment of MX records wasn't going to change that overnight. Today however, MX records exist all the time with no A record for the same name - and even worse, which will not have an analogy with AAAA->A6, there can be an A record at the same node as an MX record, where the address given has no idea how to handle mail for the domain. That is, all the SMTP clients that only do A lookups rather than MX, have been delegated to the dust heap, if any still exist anywhere, they're so locked down as to be completely irrelevant to anyone. | My worry is that, the approach will hurt us if we deploy it without | analyzing it in detail before we do so. I have no problem with that - I believe more work needs to be done on analysing A6 setups, and how well they will work. However, there's no point at all doing that if before it is finished, someone (some group, even the wrong group, like ngtrans) decides not to bother waiting for the analysis, but to simply abandon A6 and keep AAAA, because it is the safe familiar way. What would be the point of even starting collecting any data if that is likely to be the result? | So in your world unanswered questions are called "FUD"? No, just unanswered questions whose point is to remain unanswered, and thus just raise the fear of the unknown. | Did we have consensus for any of the following questions and answers? No, of not that I know of - all I gave were some plausible answers, not necessarily the right ones. I thought I made that clear in my message. That is, my objective was to remove some of the fear (no more than that). | These questions are left open as (1) it is an analysis draft (2) we | don't have consensus for ANY of them. And then you call them FUD? Yes, when the result of them being left as open questions is "suggest that A6 be abandoned". If your point had simply been that we still have things to do before we can deploy A6, then I wouldn't be objecting, I'd be agreeing. But that wasn't your point - it was to have A6 made historic (it's there in the draft...) | Do we all need to obey your answers as you are the prophet of DNS? Of course not, we need to get answers. But for that to make sense, A6 needs to still remain as the DNS record intended to be used. That is, there has to be some point to bother finding the answers. | Now you are contradicting with yourself. In the above you have mentioned | that there would be stub resolvers with caching, and now you are saying | that there will be no stub resolvers with caching. Which one do you mean? stub resolvers are the dumb things with no caches. If I ever said anything different to that, it was an accident. | I agree that it has to be between 0 and min(TTL of A6 fragments), but | for the choice of the value, there's no consensus. My point was that it simply doesn't matter. DNS implementations have always been free to send any value as the TTL smaller than the max permitted. Older versions of BIND actually used to multiply the TTL left by some constant (I forget what, for this, assume 0.8 or something) whenever an RR was taken from the cache. That was perfectly legal. It resulted in decreased cache effectiveness of course, but also make it easy to get rid of bad data from someone's cache (just query it lots of times and the TTL would quickly reduce to 0). The same is true here, you can use any TTL you like, up to the max that makes sense, there doesn't need to be a consensus. And that's without relying on the stub resolvers ignoring the TTL you send anyway (which would not be good to rely on, even though it is most likely true). | There's no mention in Rob's presentation nor Rob's draft. Rob's draft (assuming you mean the one which is on the agenda for this discussion) is a bunch of open issues. I didn't hear the presentation. So, that's no surprise. | AAAA queries | can get propagated into non-first nameservers at ease, when the first | one does not have AAAA synthesis. Given that there are whole lot of DNS | servers (1) with AAAA support (2) no A6 support and (3) no AAAA synthesis, | it is highly likely that AAAA queries will be propagaged. You cannot blame | people for propagating them (or you will blame everyone running BIND < 9.2). I think this is the same thing I answered above. Of course I don't blame anyone - but please be clear to separate out the two issues here. The first is the way that IPv6 records ought to be looked up in the ideal IPv6 internet. And the second is how we get to there from where we are now. Only if the second one says "no way, impossible" should we take much notice of that when answering the first question. | The problem here is, again, with A6 there can be certified bits | and uncertified bits within a single 128bit IPv6 address, and it | is difficult for us to decide whether the synthesized AAAA record is | really trustable or not. No, if any of it isn't trustworthy (authenticated) then all of it is unauthenticated. That much is certain. | The above is just your proposal, not the consensus. As I said (in the first reply, and again this time), that is absolutely correct. "Just a few plausible answers". | Without an answer/consensus we cannot implement AAAA synthesis right. No, that isn't correct. That would be saying that we can't implement A6 correctly, and that simply isn't correct. The only extra parts with AAAA synthesis are the TTL (which as long as it is within bounds is correct, whatever value is picked) and DNSSEC. The latter is simply impossible, the resolver inventing the AAAA record out of pieces can't possibly also invent a SIG record for it (no matter whether or not it gets and verifies SIG records for all of the A6 fragments). If the stub resolver really wanted the SIGs so it could do its own validation of the answers, then it is really going to have to get the A6 fragments and validate those. But as A6 handling is certainly easier than DNSSEC, that shouldn't pose too much of a problem. Where the back end resolver is telling the stub resolver that the data is authenticated in some other way than sending a SIG record (eg: if it is using TSIG) then it say say "authenticated" the same way it would in any other answer (but only if *all* the A6 fragments were authenticated of course). | This is not a FUD. A6 makes the problem more apparent, and is slightly | different from other resource record types. No it isn't. It is all just the same. The only difference is that you're looking for evidence against A6, and we don't get have any operational experience that says that this matters no more to A6 than it does to anything else - so it is a good way to raise the fear levels. | Yes there is such an approach proposed. Rob Austin's transitional approach | (endnode resolvers use AAAA and DNS servers use A6) is one of them. No, that's a different thing entirely. We can keep AAAA queries, without keeping AAAA RRs in the zone files. What makes no sense is to keep AAAA in the zone files, and also allow A6 0. (Of course, as a transitional aid, servers could read "AAAA" in a zone file and build "A6 0" out of it, provided that the zone signer does the same thing, where dnssec is in use). | Thanks for wording pickiness, but I don't think the change is necessary. This one isn't just working pickiness - it is a fundamental point. How often we'd like to have to renumber, and how often we actually will have to renumber are not necessarily the same thing, or even related. What we're supposed to be doing (what we set out to do way back when ipng first started) is to remove as many impediments to easy renumbering as possible. That is, every time we find something that looks like it will cause problems, we look for a solution that will allow those problems to be avoided. We don't simply say "there's this other problem that isn't solved yet, so there's no point doing anything about this one" - that's defeatism. We can do better than that - but we have to keep working on each problem, each little obstacle to renumbering, as we find it. | So you are objecting to write down something obvious to you? No. I'm objecting to using something which is obvious, but irrelevant, as an argument. | >In any case what counts here isn't what is possible right now, but what | >we should be aiming at producing. What would be the ideal outcome? | | I don't agree that it is something we should be aiming. You mean that we should simply give up on making renumbering easier? | Not a FUD. The above statement is totally correct, and you are | asserting it a FUD. Yes. Most FUD is correct. That's how it works. What it is, when analysed, is irrelevant. That's what that was. | So again you are objecting to document something obvious to you. No, again, just to its use in an argument where it carries no force. This is more bad style - throw in all kinds of stuff that everyone agrees with, in the hope that they'll just go on agreeing when you get to the issues which aren't so clear. Its a standard trick. | I'm questioning if it is necessary to renumber that frequently, My point is that we don't know. And we won't know, for ages. 20 years ago we would have said it was never necessary (for external reasons) to renumber an IPv4 net. But things have changed since... What we need to be doing now is planning for the possibility that you might be wrong. If you're right, the cost will have been small (or that's the way it looks to me at the minute - we still need data to determine that one way or the other). On the other hand, if you're wrong, and we go your way and assume that you're right, the cost might be huge. | and introduce | very high complexity and overhead for normal case ("optimized for write"). I disagree with the complexity and overheads - but just like you, I have no data to back up my guesses. But I am planning to collect some data. | Could you prove that we need higher frequency of renumber? No, of course not. Nor can I (or you) prove that we won't need it. I prefer to plan now for the possibility, so it it happens we'll be able to cope without years more of deployment effort. Or at least, as much as can be done without huge costs. | Then what is A6 really? Describe me in 10 words. For me, after doing the | analysis, it is "overly complicated alternative of AAAA with less benefit". It is v6 addresses with increased notational and operational flexibility. | Yes it is a benefit of A6, however, from the experiment result from Bill | Sommerfeld and othres, That concentrated only on the CPU overheads, you ignored the operational overheads. | I believe it is not big enough to amend the complexity of A6. I don't believe that A6 needs to be complex. It is certainly simpler (though different) than the DNS SRV record (which has weights, and probabilities, and references to other names, ...) but which is being deployed now. You can certainly make it complex, and you can dream up all kinds of foul looking configurations that no-one will ever understand. I don't care. I can do a clean A6 config for my environment, that's all that matters to me. | Prove that we need to renumber so often that we can amend the complexity | of A6. As above, I can't prove we need to renumber, nor can you prove that we won't (ever). But I can, and intend to, measure the complexity and overheads of A6 (the necessary complexity in particular). | Prove it and drop me a note when you're done. You mean prove that the University of Melbourne only has a small handful of glue records? I could do that easily enough, but what would be the point? | >The first clause there is true, I'd like to see some evidence for the | >second one, without that it is just more FUD. | | I described them in the draft and you did not get it, and you assert it as | a FUD. How nice. There was no evidence in the draft that A6 and AAAA synthesis makes the problem more apparent, and more complex to diagnose. which was the 2nd clause referred to. Just the assertion of that. As you keep asking me -- prove it. Without the proof, or even any suggestion of some evidence to suggest it, all you're doing is raising the fear level. ie: FUD. | >> To remedy this problem, we have a couple of solutions: | >> (1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the | >> problem goes away. | >No it doesn't, only this particular way of causing it. | | A6 makes the problem more apparent, so if we don't have A6, we have the | same amount of problems as today. What are you trying to mean? You said "the problem goes away." What I meant was that no, it doesn't. Sure, if we had no A6 then there'd be one less way to cause it. If we had no CNAME, there'd be another way less. If we had no MX, there'd be another way less, if we had no NS, there'd be another way less. Let's just rid ourselves of the DNS completely, then this problem is really gone ... Is that seriously the argument? | >> (2) Even if we use A6, do not configure nameservers for AAAA synthesis. | >> Deployment issues with existing IPv6 hosts get much harder. | >Something still has to build the 128 bit address out of the A6 fragments, | >if we're using A6. That can be called "AAAA synthesis" (the work is all | >identical) regardless of whether a RR with the AAAA type is ever actually | >produced. Thus this would make no difference at all - there's no benefit | >at all to be gained by prohibiting back end resolvers from doing AAAA | >generation for their stub resolvers from this line of argument. | | You must give analysis to "A6 0 synthesis", otherwise your word is | considered a FUD under your rule. I'm not sure what you're getting at there, but perhaps I can try to be clearer. Note that what I am trying to do is to allay the fear, so I seriously hope that my statements aren't FUD... But also note, nothing in this message, or the previous one, in an argument in favour of keeping A6, or that's not how the messages are intended - which is why there's almost no point in anyone reading them, there is very little affirmative point here (which is why I didn't want to start this in the first place). My only point is to show that your draft is not a valid argument against A6. There might be others, and AAAA might still turn out to be the answer, but your draft does nothing to advance that case. But, your point above was that one way to avoid the DoS problem would be to not do AAAA synthesis (and then, from that, to show that no-one would be able to use A6 anytime soon without it, and so deploying A6 would be useless). The fallacy is in assuming that AAAA synthesis has anything to do with the DoS attack you're describing at all (that is AAAA synthesis in the way proposed, which is so dumb stub resolvers don't have to learn about A6 records). That's simply false - something has to compose the 128 bit address out of the A6 fragments, any DoS attack that was available against the back end resolver doing AAAA synthesis would be available in exactly the same way against any smart A6 capable resolver. Adding in the back end resolver doing AAAA synthesis doesn't change a thing. Hence eliminating that also doesn't fix anything, hence there's no reason to eliminate the back end resolver, and thus, that stub resolvers only know AAAA today, and need to get back AAAA, doesn't matter - AAAA synthesis can happen. I have no idea what "A6 0 synthesis" is supposed to refer to. | I presented real information and you just did not understand. I think I understand it all. | Also, it is a FUD to say "there is nothing in the doc" while you are | agreeing part of the document (see some of the comments *made by yourself*). There's lots of truth in the doc, there always is in an argument based upon FUD. What there isn't is any connection between the truth and the conclusion reached. That all relies on the fear of the unknown. | Do you have an expected date to get more experiences and data? No, but soon. I had hoped to have a draft written for London (the current IETF), but it just didn't happen. A few months would be about the limit though (I hope). I have some resources to devote to doing this, but not huge amounts. Of course, anyone else is welcome to go actually do some tests, and collect the data as well... | >> The author do not see benefit in keeping both AAAA and A6 records | >No, nor do I (except perhaps for stub-resolvers - ie: keep the RR type, | >but deprecate its use in zone files). | | So we should drop Rob's "AAAA synthesis" from the candidates. no, you didn't read what I said. What I said was "deprecate its use in zone files" (it being AAAA). That is, still allow AAAA queries, and AAAA responses, but all the data in AAAA responses (after a transition period, of course) will have come from AAAA synthesis. | >> Given the unlikeliness of frequent network renumbering | >There's no evidence for that. Only for renumbering being difficult | >to achieve. That something is hard doesn't mean that we won't be | >forced to do it. | | I have already discussed, in the earlier part of the draft, | that the frequency of renumbering is not likely to be high. You asserted that. You hope that it will be true. But we simply have no way to know what will happen in the future, do we? That's my point, that we don't know (and yes, there's some FUD in this). | Now, if you are asked to prove it, how can you prove this? | The way of discussion is not correct - you are asking for an evidence | for something noone can really prove, I am asking for evidence before you rely on it to prove a point, yes. If you can't collect the evidence, then neither can you rely upon the conclusion. | and because of that you are | asserting that the draft is a FUD. Total nonsense. Yes, you're speculating on how complex A6 must be (using the worst case scenarios) and speculating on how little benefit it will be (assuming the best possible scenarios), and from that concluding that A6 isn't needed. | Now its my turn. Can you prove that the signing cost difference is | significant? I thought that had been done already... But if you like, I can take one of the zones I serve (it has something like 200K names in it, I don't know how many RRs that translates into) and run the bind 9 signer on it on one of my DNS servers (that's a SS5 85MHz incidentally - NetBSD) and after however long it takes, post the numbers. Do I really have to do that? What would it achieve? Everyone already knows that it is going to be a big number... | For what kind of zone file structure? For what kind of | situation? Can you cover all the cases we would possibly encounter? These would be valid questions if you were treating my message as one in favour of keeping A6. Once again, that isn't what it was. All it was was showing that your draft isn't much of an excuse to deprecate A6. | Agree in general, but I think I saw enough evidence from our | experimental operations as well as analysis (like this draft). What experimental operations? The draft doesn't mention any. It clearly implies some investigation of the code, but doesn't give any hint that you have actually set up some zones containing A6 record and measured the extra delays, the extra round trips, ... If you've done that, you ought to be publishing that data, that would be valuable (that includes the zone file configurations, costs observed, ...) | And you did not present any evidence either. no, because all I'm doing is analysing your draft - and that only because you asked me to. Initially I rejected this approach, and instead just pointed out that in my opinion your draft had nothing to offer (which anyone could conclude after reading it). Eventually I hope to have some evidence to present, when that happens, the conclusion might be in favour of A6, or might be in favour of AAAA. The whole point of collecting data is to provide some basis for making a decision - making the decision before the data is collected seems backwards to me. | No it is not FUD. You cannot assert like this. If you say "I did not | understnd this" or "I think this part is not correct", I can accept | those. Asserting someone's draft a FUD is not fair and unproductive. It is fair, if that is what the draft is - its that alone, to justify my assertion in the first message, that caused me to send the second one (the previous long one) and then this one. To rebut my assertion all you need to do is produce the evidence that backs up your opinions - actually provide some facts rather than simple assertions. And facts which actually lead to some relevant conclusion, rather than irrelevant ones. That is, you could easily show that the ASCII code for 'A' is 65, and spend pages proving that, and from that show that there are indeed proven facts in the draft (or some later one) - but that doesn't add anything to the actual conclusion reached. | No new inventions, please please. It can only hurt the deployment more. Yes, I understand that a major concern is deployment as fast as possible. I have some sympathy for that. But I'm not willing to sacrifice IPv6's potential to achieve it a month, or a year, faster. It may be that events will overtake us all, and that the decision will be made in the field before the right amount of data has been collected to allow it to be made well - I hope not, but that's a possibility. But I really don't want the IETF to go rushing headlong into a decision only because there's some feeling that any decision is better than none, right now. This is going to be the last long message I send on this topic. I'd prefer to do something that's actually productive. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 12:20:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04740 for ; Thu, 2 Aug 2001 12:20:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJoP-000C3l-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:50:57 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJoO-000C3f-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:50:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJoO-000F5a-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:50:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> <20010801124445.30844.qmail@cr.yp.to> <2862.996673933@brandenburg.cs.mu.OZ.AU> <2051.996749243@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:50:57 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > This is just standard glue processing (the way it is supposed to be > done anyway). That's not what the DNS standards say. RFC 1034 states quite clearly that glue is necessary only for in-bailiwick names. RFC 1537 says the same thing, and specifically recommends against glue for out-of-bailiwick names. So does RFC 1912. So does the c.p.t-i.d FAQ: ``Adding [out-of-bailiwick glue] is a very bad idea.'' Of course, BIND has thrown away out-of-bailiwick glue for years. You claim that discrimination against out-of-bailiwick glue poses ``a problem that can't easily be fixed.'' That's absurd. The fix is trivial: use in-bailiwick names. What's important---what avoids the reliability problems---is to have all the information available on the server. This is why I tell my users to select in-bailiwick names (the server _must_ collect the address in this case) and to avoid CNAME records. It's also why I oppose A6 and DNAME. > What your web page said was ... > Even if the address is provided, the cache won't accept it > because .net addresses are not within the bailiwick of a .com server; > this is the standard protection against poison. You are taking this out of context. The crucial point is that the address is _not_ provided. The next paragraph on my web page explains this in more detail. > | The client avoids the extra lookups and the possibility of loops. > And instead, the server does the extra lookups, and gets the possibility > of loops? Wrong. Server-side indirection never causes loops. You would understand this if you read my web page: http://cr.yp.to/djbdns/killa6.html ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 13:02:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07048 for ; Thu, 2 Aug 2001 13:02:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJl6-000Bx2-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:47:32 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJl6-000Bww-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:47:32 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJl6-000EzW-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:47:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bert hubert To: Robert Elz Cc: Andreas Gustafsson , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <2062.996749378@brandenburg.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Thu, Aug 02, 2001 at 05:49:38PM +0700 References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> <2062.996749378@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:47:32 -0700 Content-Transfer-Encoding: 7bit On Thu, Aug 02, 2001 at 05:49:38PM +0700, Robert Elz wrote: > | When resolving, BIND 8 and 9 do reject > | all records that are not within the domain whose authoritative > | qservers are being queried. > > That's broken, and should be fixed. If it really is as you have > explained it, it guarantees that some perfectly legal DNS configurations > can never be properly resolved. We had that problem. This leads to frantic phonecalls from Verisign, who explained it all very clearly and kindly suggested we move to using glue records ASAP. Verisign sees a very large number of requests on the (gtld?) rootservers for your nameservers otherwise. The situation was like this: At Amnic: I.AM NS select.powerdns.com. I.AM NS mincore.powerdns.com. At the GTLD servers: powerdns.com NS dns-us1.powerdns.net. powerdns.com NS dns-eu1.powerdns.net. dns-us1.powerdns.net A 63.123.33.130 dns-eu1.powerdns.net A 213.244.168.217 on the dns-{us,eu}1.powerdns.net: select.powerdns.com A 212.72.48.170 mincore.powerdns.com A 204.198.135.70 This sequence does not allow WWW.I.AM to be resolved by Bind 8.2.3. If you start from an empty cache, bind will not believe the answers it gets, and get stuck. We've now moved the I.AM NS records to the glued ns1.i.am and ns2.i.am, which get sent in the additional section, thus helping bind. I'm by nature not a bind-basher since I think it is unwise for competitors to throw mud at eachother, but this *is* rather silly behaviour. Having said that, writing a recursing nameserver is very difficult - so far we stick to only being authoritative. Regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 13:14:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07753 for ; Thu, 2 Aug 2001 13:14:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJ1o-000ADg-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:00:44 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJ1n-000ADO-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:00:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SIy7-000DZD-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 06:56:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: itojun@iijlab.net cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <2244.996674591@itojun.org> References: <2244.996674591@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:00:44 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 01 Aug 2001 23:03:11 +0900 From: itojun@iijlab.net Message-ID: <2244.996674591@itojun.org> | plesae comment paragraphs one by one, OK, I'll do that. I'd actually suggest that most people not read much of this message - if my original assertion is correct, you'll just be wasting your time. If it isn't, then it will be the responses to this message that show that. | or drop the assertion that it is a FUD. I'm afraid you'll be seeing a bit more of that in this message. | i wrote this because i believe there are serious problems | with respect to the deployment as well as operation. I don't doubt that at all - no aspersions on your motives, or anyone else's. I just don't think that this doc adds much to the debate. That isn't to say that A6 should be adopted because of this, but nor is there anything here to suggest it shouldn't. | it's not productive to assert someone's draft as a FUD! Unfortunately, sometimes it is. I'll omit the boilerplate, abstract, and similar sections in this analysis of course... Section 1 is just a brief restatement of the basics of the RR types. No problems there. Though in 1.2, if you wanted to be truly fair, you'd add M O P Q R as more nodes in the zone file (same as N with different interface identifiers). After all, your typical zone file has more end nodes than subnets, and there are usually more of those that providers, etc... The example shown makes it look like A6 will have of the order of 13 RRs for a single node's addresses, whereas AAAA only requires 3. Make that be 6 nodes (a very small network) and you get 18 RR's for the A6 case, 18 RRs for the AAAA case. And that's with an overly elaborate A6 setup for most people (especially for a net that small). Section 2 is a statement about the state of the world as it is, no problems there either. Section 3 is where the comparisons are. 3.1 is how AAAA is familiar, we know it works, ... the beginnings of FUD.= 3.2 = If we are to use fragmented A6s (128bit splitted into multiple A6s), we have a lot of issues/worries." FUD. = If we are to resolve IPv6 addresses using fragmented A6 records, we need to query DNS multiple times to resolve a single DNS name into an IPv6 address. should be "we might need to query". Since there has been no DNS record types that require multiple queries for resolution of the address itself, we have very little experience on such resource records. Not true, all non-trivial DNS lookups require multiple queries. In parti= cular doing a lookup for any alias (owner of a CNAME) requires the CNAME be resolved, and then the A record be found (potentially via more CNAMEs). We have lots of experience with such things. The only part that differs= is the "of the address itself". More FUD. There will be more delays in name resolution compared to queries to A/AAAA records. Not true. "There might be more delays" would be better. If we define a record with more number of fragments, there will be more query roundtrips. Same. There might be more round trips. How many more (what the average= increase is, for a typical query) hasn't been measured. ie: FUD. There are only few possibilities to query fragments in parallel. True, but this is not new. In the above example, we can resolve A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others. Take a complex example and treat it as a common case ... create FUD. At this moment, there is very little documents available, regarding to the relationship between DNS record TTL and the query delays. This is true, but it is nothing new for A6. The same applies to very short TTLs in NS, CNAME, ... eg: if I do an A lookup of www.example.com and get back www.example.com. 1 IN CNAME www.example.net. and then it takes more than 1 second to figure out the A related to www.example.net, am I allowed to still return that CNAME? If not, then all the rest of the resolution is useless, it doesn't apply. A6 is just= this same problem. It would be a good idea to codify Rob Austein's response to this issue and settle it. Raising it in the context of A6 in particular is just more FUD. The rest of page 5 is just exploring this issue in more detail, it isn't related to A6 specifically at all. If some of the fragments are DNSSEC-signed and some are not, how should we treat that address? RFC2874 section 6 briefly talks about it, not sure if complete answer is given. There's no difference here with A6 or any other DNS chain, which is only partially secure. Either you have en unbroken chain of sigs/keys back t= o something that you trust, or the data is unsecured. Nothing new for A6. = FUD. It is much harder to implement A6 fragment reassemble code, than to implement AAAA record resolver. AAAA record resolver can be implemented= as a straight extension of A record resolver. More FUD. More, this is irrelevant FUD. It is more difficult to implement a DNS resolver than a HOST.TXT lookup, but we still switched from HOSTS.TXT to the DNS. The resolver gets implemented just a small number of times, how difficult each of those happens to be is pretty much= irrelevant in the grand scheme of things. o It is much harder to design timeout handling for the A6 reassembly. FUD. o In the case of library resolver implementation, it is harder to deal with exceptions (signals in UNIX case) for the large code fragment for= resolvers. This basically says that writing resolvers isn't easy. Nothing at all related to A6 in this paragraph. Just FUD. There's nothing qualitative= ly new in A6, as far as DNS lookups go - just perhaps more of it. Nothing specially new (in this area) is required to implement A6. o When A6 prefix length field is not multiple of 8, address suffix portion needs to be shifted bitwise while A6 fragments are reassembled. [...] FUD. "I can create coding bugs" ... AAAA records are are 128 bits long, but aren't aligned, in DNS packets, implementations might not correctly align the data before using it, .... Gibberish. In RFC2874, a suggestion is made to use limited number of fragments per an IPv6 address. However, there is no protocol limitation defined. This is true. Perhaps we need to define a limit. Or perhaps we don't.= We need some experience with what works and what doesn't. The lack makes it easier for malicious parties to impose DoS attacks using lots of A6 fragments (see the section on security consideration). More FUD. There are lots of ways to use the DNS to cause a remote node to do more work than it would prefer to do. Almost none of them have any= practical effect, A6 less than some others. Nodes will only be doing A6 lookups when they have some reason to contact another node (like A). Sur= e you can arrange A6 to make it difficult or impossible for another node to= contact you, and to make it do a whole lot of extra work. There are a zi= llion other ways to make a node do a whole bunch of extra work when it tries to= contact you as well, both using the DNS, and via other means. With fragmented A6 records, in multi-prefix network configuration, it is= not possible for us to limit the address on the DNS database to the specific set of records, like for load distribution purposes. Consider the following example. Even if we would like to advertise only 2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible= to do so. It becomes mandatory for us to define the whole IPv6 address by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6 (renumber friendliness) goes away. This is simply not true. All that is needed is more imaginative use of the A6 records. Eg; N.X.EXAMPLE. IN A6 40 ::11:1:1234:5678:9ABC:DEF0 A.NET.IP6.D.NET. or, if there were other nodes on the same subnet that we wanted to do the= same thing to N.X.EXAMPLE. IN A6 64 ::1234:5678:9ABC:DEF0 A-D-ONLY A-D-ONLY IN A6 40 0:0:0011:: A.NET.IP6.D.NET. (and apologies if I got either of the details of those wrong, the details= aren't important here, so I didn't think about them much). In either case, we still gain from not building in D.NET...'s prefix. So the benefit of A6 (renumber friendliness) does not "go away". Obviously though the more constraints we put on which addresses we are willing to allow to be advertised, that is, the more we build in addressing knowledge into our policy requirements, the more the DNS info will be tied to out specific address blocks - that's unavoidable for this= kind of policy. It is also comparatively rare. The example at the top of page 7 is just more misguided configuration. 3.3 There are proposals to use non-fragmented A6 records in most of the places, like ``A6 0 <128bit>'', so that we would be able to switch to fragmented A6 records when we find a need for A6. This hs been suggested as a first step, yes. "In most of the places" isn't what has been suggested though that I have seen. Using A6 0 for NS records (which isn't most of anything) has been suggested. Using A6 0= as the first deployment step for A6 - before we have determined what costs those potential extra round trips might be (ie: to avoid the FUD relted to slower name resolution) has been suggested. From the packet format point of view, the approach has no benefit against AAAA. Rather, there is a one-byte overhead to every (unfragmented) A6 record compared to a AAAA record. It also has almost no cost. If the nameserver/resolver programs hardcode A6 processing to handle no fragments, there will be no future possibility for us to introduce fragmented A6 records. Yes, but that isn't what is being suggested. When there is no need for A6 reassembly, there will be no code deployment, and even if the reassembly code gets deployed they will not be tested enough. FUD. We can always do testing. Where lack of testing bites implementations is with the stuff that no-one thought to test, either because it was "obvious" that it would work, or because it was some wild case that no-on= e ever thought would happen (or thought of at all). A6 reassembly cerainly is neither of those. Testing it in the lab is trivial. Getting the bugs out is almost as trivial. How much it actually occurs in the wild doesn't matter. The author believes that the ``prepare for the future, use non-fragmented A6'' argument is not worthwhile. I won't dispute that - but just be sure that the case in favour of it is just to avoid the FUD that surrounds the extra queries that might be needed - have people set up their zones with A6 0, and then they'll know that they'll work just the same as AAAA would work, it is a safe option which will cause no problems. As the same time, braver souls can use more complex A6 setups. In the event of renumbering, non-fragmented A6 record has the same property as AAAA (the whole zone file has to be updated). This is certainly true (just a re-statement of part of the A6 design). 3.4 At this moment, end hosts support AAAA records only. Some people wou= ld like to see A6 deployment in DNS databases even with the lack of end hosts support. To workaround the deployment issues of A6, the following= approach is proposed in IETF50 dnsext working group slot. It is called ``AAAA synthesis'' [Austein, 2001] : This is obviously a transiton method (or likely to be) - though having stub resolvers that only ever do AAAA, much as we have stub resolvers wit= h no cache, and no way to do any kind of recursive lookups, with everything= in a back end resolver, is a possibility. o Deploy A6 DNS records worldwide. The proposal was not specific about whether we would deploy fragmented A6 records, or non-fragmented A6 records (``A6 0''). It doesn't matter for this purpose. That's back to how important avoidi= ng the FUD with the extra queries is seen to be. There's no need for everyone to adopt the same approach. o When a host queries AAAA record to a DNS server, the DNS server queries A6 fragments, reassemble it, and respond with a AAAA record. "DNS server" there should really be back end resolver. It is for the box near the stub resolver to do this, not the server for the zone. The approach needs to be diagnosed/specified in far more detail. Perhaps. It certainly wouldn't hurt, but I'm not sure it is needed eith= er. That is, this is really something of a local issue between the stub resolver and its back end. That could be standardised, but doesn't have to be. Just to show it can be done, I'll give some answers. Not necessarily th= e right answers all the time, but plausible ones I think. That's to remov= e the FUD that comes from giving a list of unanswered questions, which impl= ies that all this stuff must be difficult... o What is the DNS error code against AAAA querier, if the A6 reassembly fails? SERVFAIL, the same as when any DNS lookup fails. o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap uses TTL=3D0] It almost certainly doesn't matter, stub resolvers tend to have no caches= anyway (whatever the TTL is, it is ignored). But anything between 0 and= the minimum TTL from the A6 fragments combined would work. One of those two extremes would be most likely. o Which nameserver should synthesize the AAAA record, in the DNS recursize query chain? Is the synthesis mandatory for every DNS server implementation? The first one queried - the same one that does the recursive query work for the stub resolver. And no, of course not, it is only needed if you deply stub resolvers that need it (just the same as implementing resursiv= e lookups in a server). o What should we do if the A6 reassembly takes too much time? Same as if chasing CNAME records takes too much time, or NS's don't respond soon enough, or ... Nothing even slightly new here. o What should we do about DNSSEC signatures? Most likely verify them in the back end resolver, and then (most likely using TSIG) indicate to the stub resolver that the data is OK. If we ever get stub resolvers that are doing their own signature validation, then I think they can be doing their own A6 resolution as well - dnssec is certainly lots more work than A6... o What if the resolver wants no synthesis? Do we want to have a flag bit in DNS packet, to enable/disable AAAA synthesis? It just queries for A6 records instead of AAAA. This whole scheme only makes sense if A6 records are to be the ones selected to be used. That i= s, there are no AAAA records in the wild any more. The only sense to ever query for AAAA is if you are requesting AAAA synthesis. (Of course, in the short term, you might actually get an original AAAA record, but that'= s just a transitional artifact). o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query timeouts, and other timeout parameters? This looks to be some (most) of the above points, simply restated more briefly. The approach seems to be vulnerable against DoS attacks, because the nameserver reassembles A6 fragments on behalf of the AAAA querier. FUD. There is nothing different here from any case where a back end res= olver does all the work and then hands the final result of the query back to th= e stub resolver. 3.5. Issues in keeping both AAAA and A6 Did anyone actually suggest doing that? It makes no sense at all. If w= e adopt A6, then anyone who prefers the AAAA style, simply uses A6 0, that gives them all they would ever get from AAAA (at the cost of 1 byte per A6 0 record returned). If we are to keep both AAAA and A6 records onto the worldwide DNS database, it would impose more query delays to the client resolvers. It might indeed, if we were to do that nonsense thing, and do it in a na=EFve way. If for some strange reason we did decide that keeping both A6 and AAAA made some kind of sense, then the obvious thing to do would be to invent a "meta-A" query (ANYA) which would return both AAAA and A6 records. It might be worth doing that anyway, and have it return A records as well - make it easier for dual stack implementations to discover all v4 and v6 addresses in a single query (could even have it return all the other address forms that we currently know of, for all those nodes in the internet with X.25 and NSAP and such records defined..= =2E) The rest of section 3.5 is just more FUD induced by not suggesting a more sensible method of dealing with an environment that will never exist (other than for a shortish transition period) anyway. 4 Some says that there will be more frequent renumbers in IPv6 network operation, and A6 is necessary to reduce the zone modification cost as well as zone signing costs on renumber operation. That is an argument, yes. It is not clear if we really want to renumber that frequently. How often we want to renumber is not really relevant. We don't want to renumber at all. What matters is how often we need to. We don't know. We might not know for another 20 years. With IPv6, it should be easier for ISPs to assign addresses statically to the= downstream customers, rather than dynamically like we do in IPv4 dialup connectivity today. Probably true, as there are more IPv6 addresses (plenty) and so there sho= uld be much less need to share addresses. However, many ISPs seem to want to shuffle addresses not because of addre= ss shortage (ie: they switch addresses from A to B even while the client is connected, so the number of addresses assigned isn't altering), and is more to discourage the client from running servers than from any other cause (if the client can't advertise a stable address, then it is almost impossible for them to run any kind of server). But this kind of renumbering has never been what we're trying to deal wit= h (or not very much) - nodes that only get dynamic addresses when they dial= up are almost never in the DNS to start with - A6 affects only renumberin= g the DNS, so those nodes/sites aren't the ones of interest. So, this whole line of argument is achieving nothing at all. The rest of= this paragraph adds nothing. It is questionable if it is possible to renumber IPv6 networks more frequently than with IPv4. FUD. In any case what counts here isn't what is possible right now, but what we should be aiming at producing. What would be the ideal outcome? Router renumbering protocol [Crawford, 2000] , IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998] can help us renumber the IPv6 network, however, network renumbering itself is not an easy task. FUD. But it even contradicts the previous paragraph, all of that stuff from the first 2 lines makes IPv6 renumbering easier than IPv4, and if it= is easier it can (not necessarily will) be done more often. If you would like to maintain reachability from the outside world, a site administrator needs to carefully coordinate site renumber. True. So? The minimal interval between renumber is restricted by DNS record timeouts, as DNS records will be cached around the world True, which is why working on the DNS wrt renumbering is relevant in the first place. That is, to enable frequent renumbering we need to keep th= e DNS TTL low. But a low TTL has negative effects on caching. That's wh= ere A6 has benefits - the low TTL can be on just the few A6 records at the higher level (the upper bits of the addresses). Lower bits change rarely= , and can have much longer TTLs. Whether this is 1 day and 1 month, or 1 hour and 1 day, or 1 minute and 1 hour (or 1 minute and 1 month) doesn'= t matter. What the costs and benefits of this will be we don't know yet - no-one th= at I know of has actually measured them. Most of the rest of section 4 is just more on how hard renumbering can be= =2E That's not disputed. It is also no excuse for giving up, claiming it is= too hard to ever be solved, and hence not worth doing anything that might= help. A6 was designed to help administators update zone files during network renumbering events. Even with AAAA, zone file modification itself is easy; you can just query-replace the addresses in the zone files. The difficulty of network renumber comes from elsewhere. That's certainly true. But if you're thinking of A6 as some kind of weird macro processor for the zone file, then it is no wonder that you don't think of it as being useful. That is certainly not where its benefit lies. With AAAA, we need to sign the whole zone again with DNSSEC keys, after renumbering the network. With A6, we need to sign upper bits only with DNSSEC keys. Therefore, A6 will impose less zone signing cost on the event of network renumbering. Yes, this is one (comparatively minor really) A6 benefit. The DNSSEC issue of greater import is that only those parts of an organis= ation concerned with the renumbering need to go update their records, and re-si= gn them. Eg: if a university gets a new link, and adds a new prefix, then = the university prefix A6 record would be updated, and all of the departments = would get that new prefix applied to all of their addresses in the DNS, without= any of them having to re-generate anything at all. That's where the ben= efits really start to acrue, not in the saving of a few hours of CPU time (thou= gh that's not completely irrelevant either - if it takes too long to sign a zone file, sites won't do it, or won't do it in a secure manner). As seen above, it is questionable if we renumber network that often, so it is questionable if A6 brings us an overall benefit. FUD. Note, however, even if we use A6 to facilitate more frequent renumbering and lower signing cost, all glue records has to be installed as non-fragmented A6 records (``A6 0''), and required to be signed again on renumbering events. This is very likely true, though I haven't actually done the analysis to prove it is actually necessary - but in any case, there are small handful= s of such things (the University of Melbourne probably has about 20 glue A records for the whole institution...) 5. Security consideration Sect 5 before 5.1 is a simple restatement of stuff already covered. I won't go through that again. Essentially all FUD. 5.1 explores one particular attack that could be mounted. It isn't a very effective attack, as all the attacker really achieves is preventing the client from accessing the attacker's own systems, and doing a bunch o= f extra packet sending/receiving while that is happening. The client woul= d keep on doing other stuff while all this is happening, probably wihout ev= en noticing (just as it does while any other problematic DNS lookup is being= done - and if you don't know that those happen all the time, you should s= pend some time watching what any large mail server spends most of its time doing today - yet mail still gets through just fine to all the systems wh= ose DNS isn't totally hosed). It is quite possible that a totally hopeless implementation could get its= elf stuck attempting to resolve a name forever, but when we start to base decisions on what trash implementations might do, we're really delving th= e depths of poor decision making. Note, however, this problem could be considered as a problem in recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA synthesis makes the problem more apparent, and more complex to diagnose.= The first clause there is true, I'd like to see some evidence for the second one, without that it is just more FUD. To remedy this problem, we have a couple of solutions: (1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the problem goes away. No it doesn't, only this particular way of causing it. (2) Even if we use A6, do not configure nameservers for AAAA synthesis. Deployment issues with existing IPv6 hosts get much harder. Something still has to build the 128 bit address out of the A6 fragments,= if we're using A6. That can be called "AAAA synthesis" (the work is all= identical) regardless of whether a RR with the AAAA type is ever actually= produced. Thus this would make no difference at all - there's no benefi= t at all to be gained by prohibiting back end resolvers from doing AAAA generation for their stub resolvers from this line of argument. (3) Impose a protocol limitation to the number of A6 fragments. This might be a good thing to do. But even if we don't, any rational implementaton is going to do it anyway. (4) Do not query the expired records in A6 chain again. In other words,= implement resolvers that ignore TTL on DNS records. Not sure if it is the right thing to do. This is not "ignore" but "treat differently than you were thinking". This is actually no different than what everyone does with the TTLs we have no anyway - they're only ever used for deciding whether a record tha= t is in a cache is still valid. No-one does an A lookup, sees that the TTL= returned is 1, thinks to himself "it was a second ago that I did that loo= kup, so this A record is invalid now, I'd better go do it again". Nothing lik= e that at all - the old gethostbyname() inteface doesn't even return the TT= L to the application, so it has no idea at all how long the data it just fetched is valid. What is done everywere now, and would be perfectly reasonable (or at the very least, not at all worse) is to ignore the TTLs= from the records being used to build the answer (this includes NS records= , CNAME records, and any others, including A6, that we need to fetch to eventually get the result we want) - excepting in the one case that we're= fetching a result from a cache from some earlier result, in which case if= the TTL has expired, then we have to go get it again. This has some perhaps unusual effects when we have TTL's that are very small, but that's OK. After all, if you're worried about records with TTL 1 expiring before the rest of the answer is obtained, how do you justify dealing with records with TTL 0 at all? Those would be nominall= y expired while the packet that contains them is en route to the resolver (no matter how close it is). Thus, by this theory, the trivial infinite loop DNS DoS attack would be www 0 IN A 1.2.3.4 as soon as the resolver gets that, it sees it has expired, and so has to go fetch it again... This one bothers no-one, nor will the A6 cases. 6 Conclusion Since there is nothing in the doc that actually provides any real informa= tion, other than FUD, drawing conclusions from it isn't going to be easy. A6/AAAA discussion has been an obstacle for IPv6 deployment, as the deployment of IPv6 NS recodrs have been deferred because of the discussion. = This one I can't dispute - the discussion might very well be delaying deployment in some places. We still need to get it right, this really isn't a case where any answer will do, even the wrong one. Tossing a coin isn't a good solution here. We need more experience, and at least some data. The author do not see benefit in keeping both AAAA and A6 records No, nor do I (except perhaps for stub-resolvers - ie: keep the RR type, but deprecate its use in zone files). Given the unlikeliness of frequent network renumbering There's no evidence for that. Only for renumbering being difficult to achieve. That something is hard doesn't mean that we won't be forced to do it. the author believes that the A6's benefit in lower zone signing cost is not significant. I think it is significant, I'm not sure that it alone would be compelling= =2E But the stright CPU costs to sign zones are only one of the issues. From the above discussions, the author suggests to keep AAAA and deprecate A6 (move A6 document to historic state). That's OK, that's just an opinion (as the note at the beginning of the section makes clear). The author believes that A6 can cause a lot of problem than the benefits it may have. That this is believed is quite likely correct. But before we take any notice, we really need some kind of evidence. A6 will make IPv6 DNS operation more complicated and vulnerable to attacks. This is FUD. AAAA is proven to work right in our IPv6 network operation since 1996. AAAA has been working just fine in existing IPv6 networks, and the author believes that it will in the coming days. And this is the warm fuzzy alternative. Note: I am not claiming that anything in this analysis is an argument for= preferring A6 over AAAA, all this message sets out to achieve is to show that this particular draft contains no useful arguments the other way. We still need more data to provide some of the answers. However urgent it may seem to get this issue resolved, it is more important that we get = it right. For something to do in the immediate future, invent the ANYA meta-query record, have it return A AAAA and A6 records, get back end resolvers doin= g that, and creating AAAA records for stub resolvers that do AAAA requests.= That way, either AAAA or A6 records can be deployed, which allows sites to start sticking in A6, while not breaking those still doing AAAA lookup= s, and without requiring everyone to do lookups of both (and throwing in free IPv4 answers to the local cache as a side benefit). Apologies for the length of this message, I hope not too many people have= reached this far in processing it (unless you skipped all the middle bit)= =2E It really would have been better to not have needed to send it at all. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 13:14:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07762 for ; Thu, 2 Aug 2001 13:14:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJgm-000BlE-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:43:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJgl-000Bl8-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:43:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJgl-000ErQ-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:43:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: itojun@iijlab.net cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <14511.996750216@itojun.org> References: <14511.996750216@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:43:04 -0700 Content-Transfer-Encoding: 7bit Date: Thu, 02 Aug 2001 20:03:36 +0900 From: itojun@iijlab.net Message-ID: <14511.996750216@itojun.org> | One last comment - you and I are not agreeing on the urgency of this. Perhaps not, though I don't think we're that far apart on that. | If we don't pick AAAA or A6 right now, we cannot deploy IPv6 NS | records and/or IPv6 MX records, we cannot convince gTLDs/ccTLDs to | accept IPv6 NS record registrations. The deadline for picking them up | is at the London IETF. We wanted the choice like a couple of years ago. A couple of years ago we made the choice. That was A6. It has taken since then until about now (or even a bit beyond now) to get to the point where A6 can be deployed (when the implementations exist, etc). This isn't a case where we have 2 competing proposals on a more or less equal footing, and want to choose one, its a case where we have an IETF consensus doc, and are now considering deprecating it, before it has even had a reasonable chance to be tested, and without doing any actual testing (that has been reported anyway) to suggest that it won't work. | We operate commercial IPv6 backbone and selling services to customers | since the summer of 1999. And we don't have an official choice of | IPv6 DNS records? We do, that is A6. What we don't have is those actually deployed yet. | We did the analysis and test operations, and the result is in my draft. Maybe the draft is just lacking the necessary information, but I see nothing in it that is more than speculation, and fear of the unknown. | The open questions in my drafts are intended to be answered, or get | the consensus among people. This is not intended to be left | ununsewered (What suggested you like that? Did I tell you so? | how can can you assert like that without checking with me?). That's from the conclusion of the draft. It makes no sense to want answers to questions that are only relevant if A6 is to be used, if the answer is to deprecate A6. You say that A6 should be deprecated. In that case, it can't possibly be interesting to find the answers to questions that are only relevant if A6 is to be used... kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 13:29:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08432 for ; Thu, 2 Aug 2001 13:29:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJlP-000BxV-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:47:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJlP-000BxP-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:47:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJlP-000F0I-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:47:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Tony Hain" Reply-To: To: "Robert Elz" , Cc: , , Subject: RE: Joint DNSEXT & NGTRANS agenda In-Reply-To: <2437.996752010@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:47:51 -0700 Content-Transfer-Encoding: 7bit Robert Elz wrote: > A couple of years ago we made the choice. That was A6. =20 > It has taken since then until about now (or even a bit=20 > beyond now) to get to the point where A6 can be deployed=20 >(when the implementations exist, etc). > This isn't a case where we have 2 competing proposals on=20 > a more or less equal footing, and want to choose one, its=20 > a case where we have an IETF consensus doc, and are now=20 > considering deprecating it, before it has even had a=20 > reasonable chance to be tested, and without doing any actual=20 > testing (that has been reported anyway) to suggest that=20 > it won't work. I have no doubt we could figure out how to make A6 work, and with a few = guidelines written up even keep it from being noticeably different. My = concern is that the basic premise for its need is explicitly = contradictory to economic realities. As much as people claim they need = to renumber their customers to compress the routing table, how many will = really tell the people paying them that to continue being a customer = they have to go through some level of routine pain? Even if it is only a = few records a couple of times a year, the customers will quickly bail = and find a provider that can deal with the entropy. This is just another = case of the point of pain not matching with the gain, so it simply won't = happen. Tony to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 13:31:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08543 for ; Thu, 2 Aug 2001 13:31:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SJEO-000Ah9-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 07:13:44 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SJEO-000Agw-01 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:13:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SJ3s-000Djg-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 07:02:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: itojun@iijlab.net To: Robert Elz Cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-reply-to: kre's message of Thu, 02 Aug 2001 01:24:46 +0700. <590.996690286@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 07:13:44 -0700 Content-Transfer-Encoding: 7bit > | plesae comment paragraphs one by one, >OK, I'll do that. I'd actually suggest that most people not read much >of this message - if my original assertion is correct, you'll just be >wasting your time. If it isn't, then it will be the responses to this >message that show that. Now I can respond to your comments, I'm very happy. First of all I would like to thank for all the comments for all the paragraphs (just for clarification - even if people don't agree with each other's opinion, it is Japanese custom to thank for the effort itself in the first place. "thank you" does not mean that I agree with you). Please note that, in i-d, there could be issues with my English skills (like I'm asserting something I did not mean to assert, or I write "must" where I should have used "may"). In short, I cannot believe how can you assert these problems as just "FUD". This way there will be no progress. In your comment it seems that you are using the word "FUD" for "unanswered questions". I don't understand your choice of word, and I really really object. Also, you are asking for evidence multiple times, for something noone can possibly prove. This way of discussion is unfair, and I'd like to ask you to try to prove them by yourself while I think about them too. You also wrote some text that can be considered a FUD under your rule, which leds me to believe that you don't understand the issue and your objective is jut to object. I have tweaked the quotation marks (">") so that it gets more clearer which part is from the draft and which part is your comment. itojun --- >Section 1 is just a brief restatement of the basics of the RR types. >No problems there. Though in 1.2, if you wanted to be truly fair, >you'd add M O P Q R as more nodes in the zone file (same as N with >different interface identifiers). After all, your typical zone file >has more end nodes than subnets, and there are usually more of those >that providers, etc... The example shown makes it look like A6 will >have of the order of 13 RRs for a single node's addresses, whereas AAAA >only requires 3. Make that be 6 nodes (a very small network) and >you get 18 RR's for the A6 case, 18 RRs for the AAAA case. And that's >with an overly elaborate A6 setup for most people (especially for a net >that small). I don't feel the need to put multiple addresses onto the example here, since in the following sections we don't use them much. >3.1 is how AAAA is familiar, we know it works, ... the beginnings of FUD.= >>3.2 >> If we are to use fragmented A6s (128bit splitted into multiple A6s), >> we have a lot of issues/worries." >FUD. You cannot assert like this. I have presented worries and issues in the following texts, and the line summarizes these. If you can provide a better wording, I'd love to see that. >> If we are to resolve IPv6 addresses using fragmented A6 records, we >> need to query DNS multiple times to resolve a single DNS name into >> an IPv6 address. >should be "we might need to query". do you include "A6 0" case into "fragmented A6 records"? if so, I can understand your wording change. Otherwise, I don't get it. >> Since there has been no DNS record types that require multiple >> queries for resolution of the address itself, we have very little >> experience on such resource records. >Not true, all non-trivial DNS lookups require multiple queries. In parti= >cular >doing a lookup for any alias (owner of a CNAME) requires the CNAME be >resolved, and then the A record be found (potentially via more CNAMEs). >We have lots of experience with such things. The only part that differs >is the "of the address itself". More FUD. How can you ignore part of my text ("of the address itself") and assert the lines as "not true"? This is totally unfair. A6 is the only resource record type that composes a single address itself from multiple query results. It is true. >> There will be more delays in name resolution compared to queries to >> A/AAAA records. >Not true. "There might be more delays" would be better. >> If we define a record with more number of fragments, >> there will be more query roundtrips. >Same. There might be more round trips. How many more (what the average >increase is, for a typical query) hasn't been measured. ie: FUD. Again, I did not include "A6 0" into "fragmented A6 records" case. >> There are only few possibilities to query fragments in parallel. >True, but this is not new. >> In the above example, we can resolve >> A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others. >Take a complex example and treat it as a common case ... create FUD. This problem is not new but I believe it worth mentioning it. If I do not mention it, readers would mistakenly think that it is possible to parallelize the queries for A6 fragments. Do you have problem with it? If I cannot things that are not new how can I write up an analysis document. >> At this moment, there is very little documents available, regarding to >> the relationship between DNS record TTL and the query delays. >This is true, but it is nothing new for A6. The same applies to very >short TTLs in NS, CNAME, ... >eg: if I do an A lookup of www.example.com and get back > www.example.com. 1 IN CNAME www.example.net. >and then it takes more than 1 second to figure out the A related to >www.example.net, am I allowed to still return that CNAME? If not, then >all the rest of the resolution is useless, it doesn't apply. A6 is just >this same problem. It would be a good idea to codify Rob Austein's >response to this issue and settle it. Raising it in the context of A6 >in particular is just more FUD. >The rest of page 5 is just exploring this issue in more detail, it isn't >related to A6 specifically at all. With A6 the problem is more apparent as it is the only resource record type which composes a single address out of multiple query results. For example, you can get a completely different IPv6 address out of multiple queries, if you get part of A6 chains swapped with other item. Assuming that this one is correct: A6 64 ::t:u:v:w A6 48 ::s:0:0:0:0 A6 0 p:q:r:: now if you get "A6 48 ::x:0:0:0:0", you will have a whole lot of fun. The problem had not been obvious with other resource record types. For other record types, we would get a completely correct answer, or completely hosed answer. With A6 we would get a partially correct answer (incorrect bits within a part of 128bit address). >> If some of the fragments are DNSSEC-signed and some are not, how should >> we treat that address? RFC2874 section 6 briefly talks about it, not >> sure if complete answer is given. >There's no difference here with A6 or any other DNS chain, which is only >partially secure. Either you have en unbroken chain of sigs/keys back to >something that you trust, or the data is unsecured. Nothing new for A6. > FUD. No, this is not a FUD. You are mixing up two different issues. Because A6 is the only resource record type which composes a single address out of multiple query results: - for other record types, the result is binary - completely believable or not. - for A6, the result is not binary - part of bits can be believable, part of bits can be not believable. >> It is much harder to implement A6 fragment reassemble code, than to >> implement AAAA record resolver. AAAA record resolver can be implemented >> as a straight extension of A record resolver. >More FUD. More, this is irrelevant FUD. It is more difficult to >implement a DNS resolver than a HOST.TXT lookup, but we still switched >from HOSTS.TXT to the DNS. The resolver gets implemented just a small >number of times, how difficult each of those happens to be is pretty much >irrelevant in the grand scheme of things. This is from our implementation experiences. There are very few people out there (I believe) who have actually implemented A6 reassembly/decoding code, so I believe it worth mentioning. Try it by yourself and see how many mistakes you will make due to the bitwise manipulations. >> o It is much harder to design timeout handling for the A6 reassembly. >FUD. No. See the above. >> o In the case of library resolver implementation, it is harder to deal >> with exceptions (signals in UNIX case) for the large code fragment for >> resolvers. >This basically says that writing resolvers isn't easy. Nothing at all >related to A6 in this paragraph. Just FUD. There's nothing qualitative= >ly >new in A6, as far as DNS lookups go - just perhaps more of it. Nothing >specially new (in this area) is required to implement A6. No. Try to implement it into libc resolver (like BIND8) and experience the pain we had. >> o When A6 prefix length field is not multiple of 8, address suffix >> portion needs to be shifted bitwise while A6 fragments are >> reassembled. [...] >FUD. "I can create coding bugs" ... AAAA records are are 128 bits >long, but aren't aligned, in DNS packets, implementations might not >correctly align the data before using it, .... Gibberish. Bitwise operations are so much more painful than 8-bit boundary operations. >> In RFC2874, a suggestion is made to use limited number of fragments per >> an IPv6 address. However, there is no protocol limitation defined. >This is true. Perhaps we need to define a limit. Or perhaps we don't. >We need some experience with what works and what doesn't. But how can you enforce that? Resolver side can protect themselves by using the upper-limit, however, it is not possible to avoid longer-than-limit A6 chains be placed onto the DNS zone files. A6 fragments are likely to be maintained by different administrative domains. It is not likely that a single admin to control over the whole A6 chain (otherwise, there's no benefit of A6 chain). If you have some proposal for the enforcement please let me know. >> The lack makes it easier for malicious parties to impose DoS attacks >> using lots of A6 fragments (see the section on security consideration). >More FUD. There are lots of ways to use the DNS to cause a remote node >to do more work than it would prefer to do. Almost none of them have any >practical effect, A6 less than some others. Nodes will only be doing A6 >lookups when they have some reason to contact another node (like A). Sure >you can arrange A6 to make it difficult or impossible for another node to >contact you, and to make it do a whole lot of extra work. There are a zillion >other ways to make a node do a whole bunch of extra work when it tries to >contact you as well, both using the DNS, and via other means. I agree this is not just a problem of A6, however, A6 makes the problem much more easier to exploit. >> With fragmented A6 records, in multi-prefix network configuration, it is >> not possible for us to limit the address on the DNS database to the >> specific set of records, like for load distribution purposes. Consider >> the following example. Even if we would like to advertise only >> 2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible >> to do so. It becomes mandatory for us to define the whole IPv6 address >> by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6 >> (renumber friendliness) goes away. >This is simply not true. All that is needed is more imaginative use of >the A6 records. Eg; > N.X.EXAMPLE. IN A6 40 ::11:1:1234:5678:9ABC:DEF0 A.NET.IP6.D.NET. >or, if there were other nodes on the same subnet that we wanted to do the= >same thing to > N.X.EXAMPLE. IN A6 64 ::1234:5678:9ABC:DEF0 A-D-ONLY > A-D-ONLY IN A6 40 0:0:0011:: A.NET.IP6.D.NET. >(and apologies if I got either of the details of those wrong, the details >aren't important here, so I didn't think about them much). If you define upper bits (than the part that have assigned to you, like less than /48) you become less ready to renumber events. Therefore, the former one in your example will jeopardize the renumbering benefits of A6. The latter one is better, however, I don't think it manageable (can you prove it is manageable for random dumb admins like me?). >>3.3 There are proposals to use non-fragmented A6 records in most of the >> places, like ``A6 0 <128bit>'', so that we would be able to switch to >> fragmented A6 records when we find a need for A6. >This hs been suggested as a first step, yes. "In most of the places" >isn't what has been suggested though that I have seen. Using A6 0 for >NS records (which isn't most of anything) has been suggested. Using A6 0 >as the first deployment step for A6 - before we have determined what >costs those potential extra round trips might be (ie: to avoid the FUD >relted to slower name resolution) has been suggested. My text describes what I got from the past IETF presentations and slides. Maybe you right, maybe I'm right. >> From the packet format point of view, the approach has no benefit >> against AAAA. Rather, there is a one-byte overhead to every >> (unfragmented) A6 record compared to a AAAA record. >It also has almost no cost. >> If the nameserver/resolver programs hardcode A6 processing to handle no >> fragments, there will be no future possibility for us to introduce >> fragmented A6 records. >Yes, but that isn't what is being suggested. >> When there is no need for A6 reassembly, there >> will be no code deployment, and even if the reassembly code gets >> deployed they will not be tested enough. >FUD. >We can always do testing. Where lack of testing bites implementations >is with the stuff that no-one thought to test, either because it was >"obvious" that it would work, or because it was some wild case that no-one >ever thought would happen (or thought of at all). A6 reassembly >cerainly is neither of those. Testing it in the lab is trivial. >Getting the bugs out is almost as trivial. How much it actually occurs >in the wild doesn't matter. If we take "A6 0" route, it is highly likely that vendors do not bother to implement A6 chain chasing, or with a buggy reassembly support. These systems will be deployed into the real world, and we will never be able to enable fragmented A6 usage. Therefore, I consider "A6 0" approach be a complete waste of 1 byte per an IPv6 record (you can never transition to fragmented A6 situation so there's no benefit against AAAA). This is not a FUD. If there's no operational needs, people won't bother to implement them. >>3.4 At this moment, end hosts support AAAA records only. Some people would >> like to see A6 deployment in DNS databases even with the lack of end >> hosts support. To workaround the deployment issues of A6, the following >> approach is proposed in IETF50 dnsext working group slot. It is called >> ``AAAA synthesis'' [Austein, 2001] : >This is obviously a transiton method (or likely to be) - though having >stub resolvers that only ever do AAAA, much as we have stub resolvers with >no cache, and no way to do any kind of recursive lookups, with everything >in a back end resolver, is a possibility. Now, can you predict how many people will have cache in stub resolvers in year 2005? In this year, as BIND4/8 resolvers and other non-caching resolver are around, cache deployment in the stub resolver (say, for UNIX and Windows systems) is almost equal to zero. There could be one-entry caching with very short lifetime implemented in some of them, or bad caching mechanisms in applications without TTL handling, that's all. With deployment of PDAs and smaller devices, it is unlikely to see the change of ratio between caching stub resolvers and non-chacing ones. How long did you wait for this? I'm equally worried about A6 fragment reassembly code deployment. >> o Deploy A6 DNS records worldwide. The proposal was not specific about >> whether we would deploy fragmented A6 records, or non-fragmented A6 >> records (``A6 0''). >It doesn't matter for this purpose. That's back to how important avoiding >the FUD with the extra queries is seen to be. There's no need for >everyone to adopt the same approach. I mentioned "A6 0" and "A6 non-zero" this just for clarity. How can you assert it as a FUD? It is not a FUD, you just did not understand (or I did not describe it well). >> o When a host queries AAAA record to a DNS server, the DNS server >> queries A6 fragments, reassemble it, and respond with a AAAA record. >"DNS server" there should really be back end resolver. It is for the >box near the stub resolver to do this, not the server for the zone. Maybe correct. However, when back end resolvers do not implement AAAA synthesis, the AAAA queries will get propagated into servers for the zones. >> The approach needs to be diagnosed/specified in far more detail. >Perhaps. It certainly wouldn't hurt, but I'm not sure it is needed either. >That is, this is really something of a local issue between the stub >resolver and its back end. That could be standardised, but doesn't have >to be. My worry is that, the approach will hurt us if we deploy it without analyzing it in detail before we do so. >Just to show it can be done, I'll give some answers. Not necessarily the >right answers all the time, but plausible ones I think. That's to remove >the FUD that comes from giving a list of unanswered questions, which implies >that all this stuff must be difficult... So in your world unanswered questions are called "FUD"? Did we have consensus for any of the following questions and answers? These questions are left open as (1) it is an analysis draft (2) we don't have consensus for ANY of them. And then you call them FUD? Nonsense. Do we all need to obey your answers as you are the prophet of DNS? >> o What is the DNS error code against AAAA querier, if the A6 reassembly >> fails? >SERVFAIL, the same as when any DNS lookup fails. Maybe, but I'm not sure. I need to hear voice from others. >> o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap >> uses TTL=0] >It almost certainly doesn't matter, stub resolvers tend to have no caches >anyway (whatever the TTL is, it is ignored). But anything between 0 and >the minimum TTL from the A6 fragments combined would work. One of those >two extremes would be most likely. Now you are contradicting with yourself. In the above you have mentioned that there would be stub resolvers with caching, and now you are saying that there will be no stub resolvers with caching. Which one do you mean? I agree that it has to be between 0 and min(TTL of A6 fragments), but for the choice of the value, there's no consensus. >> o Which nameserver should synthesize the AAAA record, in the DNS >> recursize query chain? Is the synthesis mandatory for every DNS >> server implementation? >The first one queried - the same one that does the recursive query work >for the stub resolver. And no, of course not, it is only needed if you >deply stub resolvers that need it (just the same as implementing resursive >lookups in a server). There's no mention in Rob's presentation nor Rob's draft. AAAA queries can get propagated into non-first nameservers at ease, when the first one does not have AAAA synthesis. Given that there are whole lot of DNS servers (1) with AAAA support (2) no A6 support and (3) no AAAA synthesis, it is highly likely that AAAA queries will be propagaged. You cannot blame people for propagating them (or you will blame everyone running BIND < 9.2). >> o What should we do if the A6 reassembly takes too much time? >Same as if chasing CNAME records takes too much time, or NS's don't >respond soon enough, or ... Nothing even slightly new here. Okay, that is one possiblity. >> o What should we do about DNSSEC signatures? >Most likely verify them in the back end resolver, and then (most likely >using TSIG) indicate to the stub resolver that the data is OK. If we >ever get stub resolvers that are doing their own signature validation, >then I think they can be doing their own A6 resolution as well - dnssec >is certainly lots more work than A6... The problem here is, again, with A6 there can be certified bits and uncertified bits within a single 128bit IPv6 address, and it is difficult for us to decide whether the synthesized AAAA record is really trustable or not. The above is just your proposal, not the consensus. >> o What if the resolver wants no synthesis? Do we want to have a flag >> bit in DNS packet, to enable/disable AAAA synthesis? >It just queries for A6 records instead of AAAA. This whole scheme only >makes sense if A6 records are to be the ones selected to be used. That is, >there are no AAAA records in the wild any more. The only sense to ever >query for AAAA is if you are requesting AAAA synthesis. (Of course, in >the short term, you might actually get an original AAAA record, but that's >just a transitional artifact). This part you don't have a concrete answer so I'll wait for others to add more opinions. >> o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query >> timeouts, and other timeout parameters? >This looks to be some (most) of the above points, simply restated more >briefly. Without an answer/consensus we cannot implement AAAA synthesis right. >> The approach seems to be vulnerable against DoS attacks, because the >> nameserver reassembles A6 fragments on behalf of the AAAA querier. >FUD. There is nothing different here from any case where a back end resolver >does all the work and then hands the final result of the query back to the >stub resolver. This is not a FUD. A6 makes the problem more apparent, and is slightly different from other resource record types. >>3.5. Issues in keeping both AAAA and A6 >Did anyone actually suggest doing that? It makes no sense at all. If we >adopt A6, then anyone who prefers the AAAA style, simply uses A6 0, that >gives them all they would ever get from AAAA (at the cost of 1 byte per >A6 0 record returned). (snip) >The rest of section 3.5 is just more FUD induced by not suggesting a >more sensible method of dealing with an environment that will never >exist (other than for a shortish transition period) anyway. Yes there is such an approach proposed. Rob Austin's transitional approach (endnode resolvers use AAAA and DNS servers use A6) is one of them. You just did not understand the problem and asserting it as a FUD. Not fair. >>4 Some says that there will be more frequent renumbers in IPv6 network >> operation, and A6 is necessary to reduce the zone modification cost as >> well as zone signing costs on renumber operation. >That is an argument, yes. >> It is not clear if we really want to renumber that frequently. >How often we want to renumber is not really relevant. We don't want to >renumber at all. What matters is how often we need to. We don't know. >We might not know for another 20 years. Thanks for wording pickiness, but I don't think the change is necessary. >> With >> IPv6, it should be easier for ISPs to assign addresses statically to the >> downstream customers, rather than dynamically like we do in IPv4 dialup >> connectivity today. >Probably true, as there are more IPv6 addresses (plenty) and so there sho= >uld >be much less need to share addresses. (snip) >But this kind of renumbering has never been what we're trying to deal with >(or not very much) - nodes that only get dynamic addresses when they dialup are almost never in the DNS to start with - A6 affects only renumbering >the DNS, so those nodes/sites aren't the ones of interest. >So, this whole line of argument is achieving nothing at all. The rest of >this paragraph adds nothing. So you are objecting to write down something obvious to you? Then what's the point in compiling list of "host requirement" which has batch of duplicated text from other RFCs? I don't see your point. Nonsense. >> It is questionable if it is possible to renumber IPv6 networks more >> frequently than with IPv4. >FUD. >In any case what counts here isn't what is possible right now, but what >we should be aiming at producing. What would be the ideal outcome? I don't agree that it is something we should be aiming. >> Router renumbering protocol [Crawford, 2000] >> , IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998] >> can help us renumber the IPv6 network, however, network renumbering >> itself is not an easy task. >FUD. But it even contradicts the previous paragraph, all of that stuff >from the first 2 lines makes IPv6 renumbering easier than IPv4, and if it >is easier it can (not necessarily will) be done more often. Not a FUD. The above statement is totally correct, and you are asserting it a FUD. >> If you would like to maintain reachability >> from the outside world, a site administrator needs to carefully >> coordinate site renumber. >True. So? So again you are objecting to document something obvious to you. Rediculous. >> The minimal interval between renumber is >> restricted by DNS record timeouts, as DNS records will be cached around >> the world >True, which is why working on the DNS wrt renumbering is relevant in the >first place. That is, to enable frequent renumbering we need to keep the >DNS TTL low. But a low TTL has negative effects on caching. That's where >A6 has benefits - the low TTL can be on just the few A6 records at the >higher level (the upper bits of the addresses). Lower bits change rarely, >and can have much longer TTLs. Whether this is 1 day and 1 month, or >1 hour and 1 day, or 1 minute and 1 hour (or 1 minute and 1 month) doesn't >matter. I'm questioning if it is necessary to renumber that frequently, and introduce very high complexity and overhead for normal case ("optimized for write"). Could you prove that we need higher frequency of renumber? >> A6 was designed to help administators update zone files during network >> renumbering events. Even with AAAA, zone file modification itself is >> easy; you can just query-replace the addresses in the zone files. The >> difficulty of network renumber comes from elsewhere. >That's certainly true. But if you're thinking of A6 as some kind of >weird macro processor for the zone file, then it is no wonder that you >don't think of it as being useful. That is certainly not where its >benefit lies. Then what is A6 really? Describe me in 10 words. For me, after doing the analysis, it is "overly complicated alternative of AAAA with less benefit". >> With AAAA, we need to sign the whole zone again with DNSSEC keys, after >> renumbering the network. With A6, we need to sign upper bits only with >> DNSSEC keys. Therefore, A6 will impose less zone signing cost on the >> event of network renumbering. >Yes, this is one (comparatively minor really) A6 benefit. >The DNSSEC issue of greater import is that only those parts of an organisation >concerned with the renumbering need to go update their records, and re-sign >them. Eg: if a university gets a new link, and adds a new prefix, then the >university prefix A6 record would be updated, and all of the departments would >get that new prefix applied to all of their addresses in the DNS, without >any of them having to re-generate anything at all. That's where the benefits >really start to acrue, not in the saving of a few hours of CPU time (though >that's not completely irrelevant either - if it takes too long to sign a >zone file, sites won't do it, or won't do it in a secure manner). Yes it is a benefit of A6, however, from the experiment result from Bill Sommerfeld and othres, I believe it is not big enough to amend the complexity of A6. >> As seen above, it is questionable if we >> renumber network that often, so it is questionable if A6 brings us an >> overall benefit. >FUD. No. Prove that we need to renumber so often that we can amend the complexity of A6. >> Note, however, even if we use A6 to facilitate more >> frequent renumbering and lower signing cost, all glue records has to be >> installed as non-fragmented A6 records (``A6 0''), and required to be >> signed again on renumbering events. >This is very likely true, though I haven't actually done the analysis to >prove it is actually necessary - but in any case, there are small handfuls >of such things (the University of Melbourne probably has about 20 glue A >records for the whole institution...) Prove it and drop me a note when you're done. >5. Security consideration >Sect 5 before 5.1 is a simple restatement of stuff already covered. >I won't go through that again. Essentially all FUD. Because previous sections are not FUD, 5.1 is not a FUD too. >> Note, however, this problem could be considered as a problem in >> recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA >> synthesis makes the problem more apparent, and more complex to diagnose. >The first clause there is true, I'd like to see some evidence for the >second one, without that it is just more FUD. I described them in the draft and you did not get it, and you assert it as a FUD. How nice. >> To remedy this problem, we have a couple of solutions: >> (1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the >> problem goes away. >No it doesn't, only this particular way of causing it. A6 makes the problem more apparent, so if we don't have A6, we have the same amount of problems as today. What are you trying to mean? >> (2) Even if we use A6, do not configure nameservers for AAAA synthesis. >> Deployment issues with existing IPv6 hosts get much harder. >Something still has to build the 128 bit address out of the A6 fragments, >if we're using A6. That can be called "AAAA synthesis" (the work is all >identical) regardless of whether a RR with the AAAA type is ever actually >produced. Thus this would make no difference at all - there's no benefit >at all to be gained by prohibiting back end resolvers from doing AAAA >generation for their stub resolvers from this line of argument. You must give analysis to "A6 0 synthesis", otherwise your word is considered a FUD under your rule. >> (3) Impose a protocol limitation to the number of A6 fragments. >This might be a good thing to do. But even if we don't, any rational >implementaton is going to do it anyway. Okay. >> (4) Do not query the expired records in A6 chain again. In other words, >> implement resolvers that ignore TTL on DNS records. Not sure if it >> is the right thing to do. (snip) >This has some perhaps unusual effects when we have TTL's that are very >small, but that's OK. After all, if you're worried about records with >TTL 1 expiring before the rest of the answer is obtained, how do you >justify dealing with records with TTL 0 at all? Those would be nominally >expired while the packet that contains them is en route to the resolver >(no matter how close it is). Thus, by this theory, the trivial >infinite loop DNS DoS attack would be > www 0 IN A 1.2.3.4 >as soon as the resolver gets that, it sees it has expired, and so has to >go fetch it again... This one bothers no-one, nor will the A6 cases. (4) maybe a leftover from the previous revision of the draft. Sorry about it. >>6 Conclusion >Since there is nothing in the doc that actually provides any real information, >other than FUD, drawing conclusions from it isn't going to be easy. I presented real information and you just did not understand. Also, it is a FUD to say "there is nothing in the doc" while you are agreeing part of the document (see some of the comments *made by yourself*). >> A6/AAAA discussion has been an obstacle for IPv6 deployment, as the >> deployment of IPv6 NS recodrs have been deferred because of the >> discussion. = >This one I can't dispute - the discussion might very well be delaying >deployment in some places. We still need to get it right, this really >isn't a case where any answer will do, even the wrong one. Tossing a >coin isn't a good solution here. We need more experience, and at >least some data. Do you have an expected date to get more experiences and data? >> The author do not see benefit in keeping both AAAA and A6 records >No, nor do I (except perhaps for stub-resolvers - ie: keep the RR type, >but deprecate its use in zone files). So we should drop Rob's "AAAA synthesis" from the candidates. >> Given the unlikeliness of frequent network renumbering >There's no evidence for that. Only for renumbering being difficult >to achieve. That something is hard doesn't mean that we won't be >forced to do it. I have already discussed, in the earlier part of the draft, that the frequency of renumbering is not likely to be high. I felt that the discussion should have been enough to lead to the conclusion, so I did that. Now, if you are asked to prove it, how can you prove this? The way of discussion is not correct - you are asking for an evidence for something noone can really prove, and because of that you are asserting that the draft is a FUD. Total nonsense. >> the author believes that the A6's benefit in lower zone signing >> cost is not significant. >I think it is significant, I'm not sure that it alone would be compelling, >But the stright CPU costs to sign zones are only one of the issues. Now its my turn. Can you prove that the signing cost difference is significant? For what kind of zone file structure? For what kind of situation? Can you cover all the cases we would possibly encounter? >> From the above discussions, the author suggests to keep AAAA and >> deprecate A6 (move A6 document to historic state). >That's OK, that's just an opinion (as the note at the beginning of >the section makes clear). Yes. >> The author believes >> that A6 can cause a lot of problem than the benefits it may have. >That this is believed is quite likely correct. But before we take any >notice, we really need some kind of evidence. Agree in general, but I think I saw enough evidence from our experimental operations as well as analysis (like this draft). And you did not present any evidence either. >> A6 will make IPv6 DNS operation more complicated and vulnerable >> to attacks. >This is FUD. >> AAAA is proven to work right in our IPv6 network operation since 1996. >> AAAA has been working just fine in existing IPv6 networks, and the >> author believes that it will in the coming days. >And this is the warm fuzzy alternative. No it is not FUD. You cannot assert like this. If you say "I did not understnd this" or "I think this part is not correct", I can accept those. Asserting someone's draft a FUD is not fair and unproductive. >For something to do in the immediate future, invent the ANYA meta-query >record, have it return A AAAA and A6 records, get back end resolvers doing >that, and creating AAAA records for stub resolvers that do AAAA requests. >That way, either AAAA or A6 records can be deployed, which allows sites >to start sticking in A6, while not breaking those still doing AAAA lookups, >and without requiring everyone to do lookups of both (and throwing in >free IPv4 answers to the local cache as a side benefit). No new inventions, please please. It can only hurt the deployment more. >Apologies for the length of this message, I hope not too many people have >reached this far in processing it (unless you skipped all the middle bit), >It really would have been better to not have needed to send it at all. Well, now you need to go through my comments again. A bad day for you. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 13:53:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09673 for ; Thu, 2 Aug 2001 13:53:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SLoz-000GuH-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 09:59:41 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SLoz-000GuA-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 09:59:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SLoz-000Ie7-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 09:59:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Michael Richardson To: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Re: Joint DNSEXT & NGTRANS agenda In-reply-to: Your message of "02 Aug 2001 12:02:46 -0000." <20010802120246.31021.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 09:59:41 -0700 Content-Transfer-Encoding: 7bit My main fear about A6 is documentation: it seems too complicated, and the failure cases for it seem very hard to explain to muggles. Muggles have enough time maintaining IPv4 DNS records without DNSSEC. I am not certain if DJB is correct about the technical argument about signatures. I do not have a problem resigning my zones every day. I think that I have enough CPU. Maybe this won't be true for ccTLDs, etc. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 14:40:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12162 for ; Thu, 2 Aug 2001 14:40:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SKnm-000EUL-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 08:54:22 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SKnk-000EU5-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 08:54:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SKnk-000GqI-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 08:54:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Greg Hudson To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: Your message of "Thu, 02 Aug 2001 07:50:57 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 08:54:22 -0700 Content-Transfer-Encoding: 7bit > Wrong. Server-side indirection never causes loops. You would > understand this if you read my web page: > http://cr.yp.to/djbdns/killa6.html I read your web page (just now) and I don't understand that server-side indirection never causes loops. Before the isc.org server can serve the address of ftp.isc.org, it has to have looked up the address of isrv4.pa.vix.com. If the pa.vix.com server is misconfigured and has a "server-side cname" pointing back to ftp.isc.org, it could be unable to serve the isrv4.pa.vix.com address before looking up the address of ftp.isc.org. That sounds like a loop to me. The two servers might detect the loop and behave intelligently, but so can a client. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 2 14:40:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12178 for ; Thu, 2 Aug 2001 14:40:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SLoz-000GuH-00 for namedroppers-data@psg.com; Thu, 02 Aug 2001 09:59:41 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15SLoz-000GuA-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 09:59:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15SLoz-000Ie7-00 for namedroppers@ops.ietf.org; Thu, 02 Aug 2001 09:59:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Michael Richardson To: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Re: Joint DNSEXT & NGTRANS agenda In-reply-to: Your message of "02 Aug 2001 12:02:46 -0000." <20010802120246.31021.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Thu, 02 Aug 2001 09:59:41 -0700 Content-Transfer-Encoding: 7bit My main fear about A6 is documentation: it seems too complicated, and the failure cases for it seem very hard to explain to muggles. Muggles have enough time maintaining IPv4 DNS records without DNSSEC. I am not certain if DJB is correct about the technical argument about signatures. I do not have a problem resigning my zones every day. I think that I have enough CPU. Maybe this won't be true for ccTLDs, etc. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 3 19:40:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01045 for ; Fri, 3 Aug 2001 19:40:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15So98-000NIV-00 for namedroppers-data@psg.com; Fri, 03 Aug 2001 16:14:22 -0700 Received: from [217.33.136.18] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15So96-000NIC-00 for namedroppers@ops.ietf.org; Fri, 03 Aug 2001 16:14:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Sl6h-0000QR-00 for namedroppers@ops.ietf.org; Fri, 03 Aug 2001 20:59:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Dancer Vesperman To: "D. J. Bernstein" CC: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Re: Joint DNSEXT & NGTRANS agenda References: <14511.996750216@itojun.org> <2437.996752010@brandenburg.cs.mu.OZ.AU> <20010802120246.31021.qmail@cr.yp.to> X-Accept-Language: en-us Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 03 Aug 2001 16:14:22 -0700 Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > Robert Elz writes: > >>before it has even had a reasonable chance to be tested >> > > We're saying ``deployment will be a disaster, and here's why.'' You're > saying ``let's deploy it and see what happens.'' That's unacceptable. > A6 and DNAME need to be killed _before_ people start relying on them. You know, I seem to recall that I said the same about HTTP, way back when... I get the impression that it's too late to deploy something that isn't already ready. I agree with itojun (It's true that I spend a lot of time doing this): There is no time. A broken thing is probably better than no thing. IT people tend to laugh at IPv6 as vaporware these days. Personally, I don't much _CARE_ if it's possible for a DNS administrator to get things Horribly Wrong(tm) with A6 records. They _already_ get things Horribly Wrong(tm) with A records, NS records, MX records, SOA records and CNAME records....screwing up their domains with yet another record type would merely be continuing a grand tradition. Dan: You have a point. Maybe a good one. Personally, I don't think it's quite good enough given the apparent time-frames. Fait accompli and all that. D to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 3 20:35:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01046 for ; Fri, 3 Aug 2001 19:40:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15So98-000NIX-00 for namedroppers-data@psg.com; Fri, 03 Aug 2001 16:14:22 -0700 Received: from [217.33.136.18] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15So97-000NIC-00 for namedroppers@ops.ietf.org; Fri, 03 Aug 2001 16:14:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15SlVx-0000Vj-00 for namedroppers@ops.ietf.org; Fri, 03 Aug 2001 21:25:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 03 Aug 2001 16:14:22 -0700 Content-Transfer-Encoding: 7bit Greg Hudson writes: > That sounds like a loop to me. It isn't. Here's what the isc.org server does: 1. Look up isrv4.pa.vix.com. 2. Set up ftp.isc.org with the same information. See? No loop. The procedure is guaranteed to end in two steps. The ftp.isc.org information at any moment is a correct copy of the recent isrv4.pa.vix.com information, exactly as specified. It doesn't matter where the isrv4.pa.vix.com information comes from. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 4 04:23:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23682 for ; Sat, 4 Aug 2001 04:23:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SwLv-000Cij-00 for namedroppers-data@psg.com; Sat, 04 Aug 2001 01:00:07 -0700 Received: from [217.33.136.18] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15SwLu-000Cid-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 01:00:07 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15SwLt-0001gW-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 09:00:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson To: Jakob Schlyter , Brian Wellington Cc: Edward Lewis , , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 04 Aug 2001 01:00:07 -0700 Content-Transfer-Encoding: 7bit At 09:17 AM 7/30/2001, Jakob Schlyter wrote: >On Sun, 29 Jul 2001, Brian Wellington wrote: As Brian's co-author I agree with most of what he as said. Given that I'm the co-chair of the working group I have not been jumping into this argument. But I think it is time to put my foot down. As far as I can tell there are two religious camps arguing here and as in any good theological argument there is no way for one to agree with the other ;-) And of course the argument is over a real fine point. The two arguments are: #1 Server can set the AD bit on SECURE AUTHORATIVE data in accordance local policy, all other data must be cryptographically verified before setting the AD bit. #2 Server can ONLY set the AD bit after cryptographically verifying signatures. If we follow the second policy then server needs to verify all authoritative data before including it in answer, this implies either verify-on-load or verify-on-answer. Now lets think about this in a different way, if the secure zone cryptographic checksum (similar to SIG(0) or TSIG). on the master file is verifying that checksum acceptable under policy #2? Under strict interpretation the answer is NO, but the data is just as secure as if all the signatures are verified. Also who trusts the AD bit ? Only resolvers that are pre configured to trust a particular server will accept the AD bit, ALL OTHERS MUST ignore it. Someone should write a BCP on when it is ok to set the AD bit on secure authoritative data. > > This is the problem. The stub resolver should not care whether the > > server has validated the data or not. If the resolver trusts the > > server, the server trusts the data, and the communication is secure, > > the resolver should trust the data. > >the stub resolver may care whether the server has validated the data or >not. if the servers hasn't validated the data, e.g. data data was never >protected by dnssec, it can choose not to trust it at all. Ok, now we are in hair splinting mode, IMHO if client trusts server it must accept the whole policy of the server. If that is unacceptable I think the way to solve this is to add EDNS options that request specific services from the server, such as "VERIFY ALL data before setting AD". That should satisfy your desire, and allows the server to tell you if it is not willing by returning REFUSED. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 4 04:27:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23709 for ; Sat, 4 Aug 2001 04:27:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SwbX-000DB8-00 for namedroppers-data@psg.com; Sat, 04 Aug 2001 01:16:15 -0700 Received: from [217.33.136.18] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15SwbX-000DB2-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 01:16:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15SwbW-0001ht-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 09:16:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta To: Robert Elz CC: Andreas Gustafsson , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <2062.996749378@brandenburg.cs.mu.OZ.AU> from Robert Elz at "Aug 2, 2001 05:49:38 pm" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 04 Aug 2001 01:16:15 -0700 Content-Transfer-Encoding: 7bit Kre; > | When resolving, BIND 8 and 9 do reject > | all records that are not within the domain whose authoritative > | qservers are being queried. > > That's broken, and should be fixed. If it really is as you have > explained it, it guarantees that some perfectly legal DNS configurations > can never be properly resolved. > > | If they did not, we would > | be seeing much more cases of cache poisoning that we do now. > > How? No-one is suggesting that these records be put in the cache. I have been suggesting that these records be put in a referral-local cache content of which is not used for usual A query nor glue A of other referral points. Other approaches are broken w.r.t. performance. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 4 04:44:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23844 for ; Sat, 4 Aug 2001 04:44:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15SwcV-000DDN-00 for namedroppers-data@psg.com; Sat, 04 Aug 2001 01:17:15 -0700 Received: from [217.33.136.18] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15SwcV-000DDF-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 01:17:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15SwcU-0001iF-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 09:17:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta To: Olafur Gudmundsson CC: namedroppers@ops.ietf.org Subject: Re: Discovery discussion restrictions NOT In-Reply-To: from Olafur Gudmundsson at "Jul 31, 2001 07:13:54 pm" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 04 Aug 2001 01:17:15 -0700 Content-Transfer-Encoding: 7bit Olafur; > > > For those who for some strange reason do not seem to notice that the > > > discussion is taking place, with his message of June 19 Thomas Narten > > > lifted the restrictions imposed on discussion on above draft by chair > > > on June 5th. > > > > "above"? Which draft? > > > draft-ymbk--opcode-discover-02.txt Thanks. I think the basic assumption of the draft With the development of multicast capabilities in the DNS is wrong. The Internet or DNS is not going anywhere with multicast, yet. A better solution for a small offices, where security is not an issue, is to use site-local unicast addresses (3 should be enough) for site-local DNS servers and put them to default /etc/resolv.conf etc. We can make the address anycast for a very large office, if site administrators can keep routing to the servers bi-directional. But, it is easier to divide the office into smaller ones. If there is some security concern, we must configure secret information, compared to which configuraing DNS server addresses are negligible (though the local unicast addresses are usable). Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 4 12:30:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28512 for ; Sat, 4 Aug 2001 12:30:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15T3yr-0001bt-00 for namedroppers-data@psg.com; Sat, 04 Aug 2001 09:08:49 -0700 Received: from [217.33.136.77] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15T3yo-0001aK-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 09:08:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15T3Z1-0002Ue-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 16:42:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: gson@nominum.com (Andreas Gustafsson) To: Masataka Ohta Cc: Robert Elz , Andreas Gustafsson , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 04 Aug 2001 09:08:49 -0700 Content-Transfer-Encoding: 7bit Masataka Ohta writes: > > How? No-one is suggesting that these records be put in the cache. > > I have been suggesting that these records be put in a referral-local > cache content of which is not used for usual A query nor glue A of > other referral points. I think that's an excellent approach, and one that should be seriously considered when designing new resolver implementations. BIND 8 and 9 have the concept of a single, global cache too deeply ingrained to be changed at this point. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 4 18:43:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01948 for ; Sat, 4 Aug 2001 18:43:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15T9p9-000C6P-00 for namedroppers-data@psg.com; Sat, 04 Aug 2001 15:23:11 -0700 Received: from host217-33-136-77.ietf.ignite.net ([217.33.136.77] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15T9p8-000C6I-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 15:23:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15T2Kb-0000Bz-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 15:23:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta To: Andreas Gustafsson CC: Robert Elz , Andreas Gustafsson , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <200108041536.IAA01336@gulag.araneus.fi> from Andreas Gustafsson at "Aug 4, 2001 08:36:00 am" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 04 Aug 2001 15:23:11 -0700 Content-Transfer-Encoding: 7bit Andreas; > > > How? No-one is suggesting that these records be put in the cache. > > > > I have been suggesting that these records be put in a referral-local > > cache content of which is not used for usual A query nor glue A of > > other referral points. > > I think that's an excellent approach, and one that should be seriously > considered when designing new resolver implementations. BIND 8 and 9 > have the concept of a single, global cache too deeply ingrained to be > changed at this point. As I have been suggesting it long before BIND 8 or9, I have no intention to check them specifically by myself. But, if they are implemented rationally, the modification would be: Add a field of referral point for a cache entry structure. Referral point would be null pointer unless it is cached from additional A for NS. Otherwise the referral point for the NS would be stored. Cache entries are matched considering the referral point, unless the answer is used for additional A for NS. Additonal A for NS may use cache entry with null referral point As all the referral points of a zone share the same glue information, zone may be used instead of referral point. I estimate the modification is a lot easier than several generations of misdirected attempts to obtain the true weak security. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 5 02:27:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23491 for ; Sun, 5 Aug 2001 02:27:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TH27-000N5G-00 for namedroppers-data@psg.com; Sat, 04 Aug 2001 23:05:03 -0700 Received: from host217-33-136-77.ietf.ignite.net ([217.33.136.77] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15TH26-000N59-00 for namedroppers@ops.ietf.org; Sat, 04 Aug 2001 23:05:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15TGwi-0000bx-00 for namedroppers@ops.ietf.org; Sun, 05 Aug 2001 06:59:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 04 Aug 2001 23:05:03 -0700 Content-Transfer-Encoding: 7bit Masataka Ohta writes: > I have been suggesting that these records be put in a referral-local > cache content of which is not used for usual A query nor glue A of > other referral points. What records are you talking about? Typical A6 reliability problems involve servers that don't know the next step in the A6 chain. How is the server going to provide records that it doesn't have? Of course, we can eliminate the reliability problems by making sure that the servers have the entire A6 chain---in which case it's far simpler to use AAAA. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 5 12:23:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15601 for ; Sun, 5 Aug 2001 12:23:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TQR0-0009la-00 for namedroppers-data@psg.com; Sun, 05 Aug 2001 09:07:22 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15TQQz-0009lU-00 for namedroppers@ops.ietf.org; Sun, 05 Aug 2001 09:07:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15TQLa-0000k5-00 for namedroppers@ops.ietf.org; Sun, 05 Aug 2001 17:01:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Sommerfeld Reply-To: sommerfeld@orchard.arlington.ma.us To: Olafur Gudmundsson Cc: Jakob Schlyter , Brian Wellington , Edward Lewis , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: Message from Olafur Gudmundsson of "Sat, 04 Aug 2001 01:00:07 PDT." Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 05 Aug 2001 09:07:22 -0700 Content-Transfer-Encoding: 7bit > If we follow the second policy then server needs to verify all > authoritative data before including it in answer, this implies either > verify-on-load or verify-on-answer. There's also verify-and-cache-on-first-answer .. - Bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 5 12:28:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15662 for ; Sun, 5 Aug 2001 12:28:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TQXq-0009w0-00 for namedroppers-data@psg.com; Sun, 05 Aug 2001 09:14:26 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15TQXq-0009vt-00 for namedroppers@ops.ietf.org; Sun, 05 Aug 2001 09:14:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15TQSR-0000ko-00 for namedroppers@ops.ietf.org; Sun, 05 Aug 2001 17:08:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 05 Aug 2001 09:14:26 -0700 Content-Transfer-Encoding: 7bit Date: Sat, 04 Aug 2001 23:05:03 -0700 From: "D. J. Bernstein" Message-ID: | What records are you talking about? Otha-san was talking about glue A records that accompany NS records, which is a side avenue that this discussion was taking. | Typical A6 reliability problems involve servers that don't know the next | step in the A6 chain. How is the server going to provide records that it | doesn't have? It isn't. Obviously. Whether or not there's a reliability problem in this case will depend upon how reliable the other servers, that have the rest of the data are of course. This is no different than an MX record that names a host served by a different server, or a similar NS record. And, yes, I know that you recommend to your users that they don't do that. And that's fine. And you can do the same with A6 as well... | Of course, we can eliminate the reliability problems by making sure that | the servers have the entire A6 chain---in which case it's far simpler to | use AAAA. But if A6 is used, each site has 3 choices. It can use A6 0, which is identical in effect to AAAA. Or it can use an A6 chain, where all the RR's are available at the same server. Or it can use an A6 chain, with one or more of the A6 records at some other server (hence requiring more lookups). Each site gets to make that choice, and make it indiviually for each v6 address to be placed in the DNS. That is, each site gets to choose between the degree of reliability, and the degree of flexibility that meets its needs best. You are, of course, free to keep recommending to your users that they only use A6 0 if you want to. You could even (assuming you ever implement any of this) refuse to allow your server to load any A6 record other than A6 0. But is there any good reason that you can give us why others shouldn't be free to make other choices? kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 5 12:31:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15703 for ; Sun, 5 Aug 2001 12:30:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TQc3-000A3p-00 for namedroppers-data@psg.com; Sun, 05 Aug 2001 09:18:47 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15TQc2-000A3e-00 for namedroppers@ops.ietf.org; Sun, 05 Aug 2001 09:18:47 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15TQWe-0000lY-00 for namedroppers@ops.ietf.org; Sun, 05 Aug 2001 17:13:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> <6947.997018207@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 05 Aug 2001 09:18:47 -0700 Content-Transfer-Encoding: 7bit Robert Elz writes: > That is, each site gets to choose between the degree of reliability, and > the degree of flexibility that meets its needs best. You're saying that the I.AM administrators _chose_ to make their domain only sporadically reachable by BIND 8 caches around the Internet? Sure, BIND 9 and dnscache have higher gluelessness limits, but those limits can be exceeded too. A cache can't let a single lookup consume arbitrary amounts of memory! See RFC 1034, section 5.3.3. If people start relying on A6 and DNAME, this type of failure---and the other two types described in http://cr.yp.to/djbdns/killa6.html---will become much more common. Are you going to claim that the victims _chose_ to screw up their own DNS service? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 6 01:53:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08206 for ; Mon, 6 Aug 2001 01:53:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Td6S-0002Vm-00 for namedroppers-data@psg.com; Sun, 05 Aug 2001 22:39:00 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Td6R-0002Vg-00 for namedroppers@ops.ietf.org; Sun, 05 Aug 2001 22:38:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Td13-0000vT-00 for namedroppers@ops.ietf.org; Mon, 06 Aug 2001 06:33:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Jakob Schlyter To: DNSEXT Subject: draft-ietf-dnsext-delegation-signer-01 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 05 Aug 2001 22:39:00 -0700 Content-Transfer-Encoding: 7bit section 2.1, protocol change, says: DS record MUST only appear at secure delegations in the parent zone. The record lists the child's keys that SHOULD sign the child's key set. Insecure delegation MUST NOT have a DS record, the presence of DS record SHOULD be considered a hint that the child might be secure. Resolver MUST only trust KEY records that match a DS record. I think is to vague as it does allow you to get into a situation where the parent says the child might be secure but it is not. perhaps this is a better wording: DS record MUST only appear at secure delegations in the parent zone. Secure delegations MUST have a DS record. Insecure delegations MUST NOT have a DS record. Therefore the presence of a DS record should be an indication that the child is secure. The child MUST sign its key set with at least one of the keys listed in the DS record at the parent. Regarding NULL DS, I believe we don't need them as could use NXT/NO instead if desired (as explained in the draft). jakob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 6 01:53:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08219 for ; Mon, 6 Aug 2001 01:53:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Tczm-0002Kr-00 for namedroppers-data@psg.com; Sun, 05 Aug 2001 22:32:06 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Tczl-0002Kl-00 for namedroppers@ops.ietf.org; Sun, 05 Aug 2001 22:32:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15TcuN-0000uu-00 for namedroppers@ops.ietf.org; Mon, 06 Aug 2001 06:26:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta To: "D. J. Bernstein" CC: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: from "D. J. Bernstein" at "Aug 4, 2001 11:05:03 pm" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sun, 05 Aug 2001 22:32:06 -0700 Content-Transfer-Encoding: 7bit Dan; > > I have been suggesting that these records be put in a referral-local > > cache content of which is not used for usual A query nor glue A of > > other referral points. > > What records are you talking about? Just a history on glue A. You can apply it to glue AAAA (if any) and glue A6. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 6 03:53:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18591 for ; Mon, 6 Aug 2001 03:53:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Tex2-0005nK-00 for namedroppers-data@psg.com; Mon, 06 Aug 2001 00:37:24 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Tex1-0005nE-00 for namedroppers@ops.ietf.org; Mon, 06 Aug 2001 00:37:23 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Tera-00014K-00 for namedroppers@ops.ietf.org; Mon, 06 Aug 2001 08:31:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> <6947.997018207@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 06 Aug 2001 00:37:24 -0700 Content-Transfer-Encoding: 7bit Date: Sun, 05 Aug 2001 09:18:47 -0700 From: "D. J. Bernstein" Message-ID: | You're saying that the I.AM administrators _chose_ to make their domain | only sporadically reachable by BIND 8 caches around the Internet? No, of course not. That seems to have been the result of a straight out implementation bug. When that kind of thing happens, the domain admins will generally find a way to avoid the bug (which seems to be what happened here), at the same time, the implementation should be fixing the bug so it doesn't bite others. | A cache can't let a single lookup consume | arbitrary amounts of memory! See RFC 1034, section 5.3.3. Of course it can't. So an administrator will make sure not to ask too much of caches, by creating rational configuration that remains well within reasonable limits. That's what people are doing now - the DNS actually works... (despite all these theoretical demonstrations that it can't possibly work... and the occasional reported case of things not working). | If people start relying on A6 and DNAME, this type of failure---and the | other two types described in http://cr.yp.to/djbdns/killa6.html---will | become much more common. Are you going to claim that the victims _chose_ | to screw up their own DNS service? No, and perhaps for a while, we will see some more failures, while people experiment, and before they learn what works. Everything has costs, A6 included, A6's added complexity, and hence more opportunities to accidentally configure things badly is one of those costs. Fortunately, A6 also has a trivial workaround for anyone who isn't sure what is a good config, and what isn't - they can always just use A6 0, and be just as safe as if they had used AAAA. No question about it. But with A6, I can use a more complex config if I feel confident of it. With AAAA I cannot. What's more, you can always use A6 as a chance to demonstrate your server indirection if you like - implement A6, and for any A6 n (n > 0) that gets loaded, have your server go and fetch all of the rest of the chain, and keep it up to date, so it is always there to be sent to clients in one packet, so the client can always get all of the data quickly. Sure the client will need to expend a little more CPU time combining the RR values (either the end resolver, or some back end resolver doing AAAA synthesis), but in the grand scheme of things, that's trivial. [Aside: just in case anyone thinks otherwise, this isn't just a challenge to do something I think is a dumb idea - on the contrary, I have for a long time believed that this is just what servers should be doing, for MX, and NS, and everything else where there could be a benefit - it is only the "too much work" arguments that have persuaded me not to try to make this at the very least a BCP as recommended practice for all servers]. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 6 08:29:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22015 for ; Mon, 6 Aug 2001 08:29:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15TjAi-000CXw-00 for namedroppers-data@psg.com; Mon, 06 Aug 2001 05:07:49 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15TjAi-000CXq-00 for namedroppers@ops.ietf.org; Mon, 06 Aug 2001 05:07:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Tj5K-0001BH-00 for namedroppers@ops.ietf.org; Mon, 06 Aug 2001 13:02:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Edward Lewis To: Olafur Gudmundsson Cc: Edward Lewis , DNSEXT Subject: Re: restart: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Mon, 06 Aug 2001 05:07:49 -0700 Content-Transfer-Encoding: 7bit At 4:00 AM -0400 8/4/01, Olafur Gudmundsson wrote: >As far as I can tell there are two religious camps arguing here and >as in any good theological argument there is no way for one to agree >with the other ;-) >And of course the argument is over a real fine point. And the setting of one bit. >If we follow the second policy then server needs to verify all >authoritative data before including it in answer, this implies either >verify-on-load or verify-on-answer. Not true - the server could just return AA=1, AD=0. >Now lets think about this in a different way, >if the secure zone cryptographic checksum (similar to SIG(0) or TSIG). >on the master file is verifying that checksum acceptable under policy #2? >Under strict interpretation the answer is NO, but the data is just >as secure as if all the signatures are verified. What, you mean SIG(AXFR)? I would say no - the AD means that the cryptograhic chain was checked back to some point, a la RFC 300[78]. IMHO, if we don't specify a particular way of doing this, there will be too many possible interpretations. >Also who trusts the AD bit ? >Only resolvers that are pre configured to trust a particular server >will accept the AD bit, ALL OTHERS MUST ignore it. Not true. If I want to view a web page and only care that the address is reasonably right (ie, I'm just view an cartoon for entertainment), I may be willing to trust the server local to me, that I have reached via IPsec, or behind a firewall. This is a case where I may value the setting of the AD bit without knowing the policy of the server, just that I have faith that the provider of the moment is sane. >Someone should write a BCP on when it is ok to set the AD bit on >secure authoritative data. Isn't this what your document is about? >Ok, now we are in hair splinting mode, IMHO if client trusts server >it must accept the whole policy of the server. The issue of "trust" isn't the problem - its the setting of the bit. Let's define what the bit means and worry about how resolvers and client applications interpret it later. (Applications will have different requirements, there's no interoperability issue when we are talking about the interpretation of a bit within an application.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 6 19:56:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04437 for ; Mon, 6 Aug 2001 19:56:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ttm5-0004mn-00 for namedroppers-data@psg.com; Mon, 06 Aug 2001 16:27:05 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Ttm4-0004mX-00 for namedroppers@ops.ietf.org; Mon, 06 Aug 2001 16:27:05 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Ttgh-0001fm-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 00:21:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 06 Aug 2001 16:57:13 -0500 From: Matt Crawford Subject: Re: Joint DNSEXT & NGTRANS agenda In-reply-to: "02 Aug 2001 13:37:24 BST." To: alh-ietf@tndh.net Cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Message-id: <200108062157.f76LvDm21797@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (Gee, I almost wish there had been time to catch up on mail before today...) > Even if it is only a few records a couple of times a year, the > customers will quickly bail and find a provider that can deal > with the entropy. This is just another case of the point of pain > not matching with the gain, so it simply won't happen. These customers that bolt to avoid renumbering -- they will take their portable IPv6 address blocks with them? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 06:42:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29943 for ; Tue, 7 Aug 2001 06:42:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U3sf-000KQJ-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 03:14:33 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U3se-000KQD-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 03:14:32 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U3nG-00025J-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 11:08:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 07 Aug 2001 05:10:34 -0500 From: Matt Crawford Subject: Joint DNSEXT & NGTRANS summary To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Message-id: <200108071010.f77AAYm24838@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have overheard nearly opposite outcomes quoted by random people in the halls, and some of the joint co-chairs (all the ones I've asked so far) seem reluctant to say anything substantive in public about the outcome of the joint dnsext/ngtrans meeting. I know there are some interested parties who were not present and I have no idea whether or how well they heard it on the mbone. So, here's my view from the floor ... other views would be welcome, the sooner the better. There was a lot of discussion, culminating with a "hum" on the following four choices: 1. Deploy A6 in full panoply, synthesize AAAA for transition period 2. Deploy A6 conservatively ("A6 0"), synthesize as above 3. Reclassify A6 as experimental, use AAAA for production 4. Reclasify A6 as historic, use AAAA for production. The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all accounts. There was quite obviously no consensus (i.e., unanimity) or rough consensus (in the usual IETF sense of near-unanimity). It could not even be concluded that the loudest hum represented a majority of those voicing an opinion. The difference in impressions taken away, therefore, I would account for by differences in opinion about whether the preference of a plurality, possibly a slim majority, represent a decision to alter the status quo. (That being A6 on the standards track.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 08:20:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02035 for ; Tue, 7 Aug 2001 08:20:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U5en-000N3E-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 05:08:21 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U5em-000N36-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 05:08:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U5ZM-00028c-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 13:02:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matt Crawford Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: crawdad's message of Tue, 07 Aug 2001 05:10:34 EST. <200108071010.f77AAYm24838@gungnir.fnal.gov> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Tue, 07 Aug 2001 19:16:29 +0900 Message-Id: <20010807101629.AA1BA7BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >1. Deploy A6 in full panoply, synthesize AAAA for transition period >2. Deploy A6 conservatively ("A6 0"), synthesize as above >3. Reclassify A6 as experimental, use AAAA for production >4. Reclasify A6 as historic, use AAAA for production. > >The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all >accounts. There was quite obviously no consensus (i.e., unanimity) I would say 3 >> 2 > 1 > 4, heard from my location (near the VGA projector). itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 08:20:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02049 for ; Tue, 7 Aug 2001 08:20:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U5hO-000N66-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 05:11:02 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U5hN-000N5z-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 05:11:02 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U5c0-00028y-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 13:05:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 7 Aug 2001 06:28:30 -0400 (EDT) From: Jim Bound To: Matt Crawford Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108071010.f77AAYm24838@gungnir.fnal.gov> Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I felt consensus for number 3 is my input. /jim On Tue, 7 Aug 2001, Matt Crawford wrote: > I have overheard nearly opposite outcomes quoted by random people > in the halls, and some of the joint co-chairs (all the ones I've > asked so far) seem reluctant to say anything substantive in public > about the outcome of the joint dnsext/ngtrans meeting. I know there > are some interested parties who were not present and I have no idea > whether or how well they heard it on the mbone. So, here's my > view from the floor ... other views would be welcome, the sooner > the better. > > There was a lot of discussion, culminating with a "hum" on the > following four choices: > > 1. Deploy A6 in full panoply, synthesize AAAA for transition period > 2. Deploy A6 conservatively ("A6 0"), synthesize as above > 3. Reclassify A6 as experimental, use AAAA for production > 4. Reclasify A6 as historic, use AAAA for production. > > The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all > accounts. There was quite obviously no consensus (i.e., unanimity) > or rough consensus (in the usual IETF sense of near-unanimity). It > could not even be concluded that the loudest hum represented a > majority of those voicing an opinion. > > The difference in impressions taken away, therefore, I would account > for by differences in opinion about whether the preference of a > plurality, possibly a slim majority, represent a decision to alter the > status quo. (That being A6 on the standards track.) > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 08:21:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02073 for ; Tue, 7 Aug 2001 08:21:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U5f4-000N3Q-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 05:08:38 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U5f4-000N3J-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 05:08:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U5Zg-00028h-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 13:03:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200108071018.f77AIY619105@zed.isi.edu> Subject: Re: Joint DNSEXT & NGTRANS summary To: crawdad@fnal.gov (Matt Crawford) Date: Tue, 7 Aug 2001 03:18:33 -0700 (PDT) Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <200108071010.f77AAYm24838@gungnir.fnal.gov> from "Matt Crawford" at Aug 07, 2001 05:10:34 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % There was a lot of discussion, culminating with a "hum" on the % following four choices: % % 1. Deploy A6 in full panoply, synthesize AAAA for transition period % 2. Deploy A6 conservatively ("A6 0"), synthesize as above % 3. Reclassify A6 as experimental, use AAAA for production % 4. Reclasify A6 as historic, use AAAA for production. I took a (perhaps) stricter view on these four choices: 1) A6 stays on Stds track, syth AAAA when needed, AAAA is depricated 2) A6 stays on Stds track, tempered by a recommendation to operationally use A6 0. 3) Leave AAAA on Stds track, move A6 to experimental. 4) Move A6 to historic, leave AAAA on Stds track. % The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all % accounts. There was quite obviously no consensus (i.e., unanimity) % or rough consensus (in the usual IETF sense of near-unanimity). It % could not even be concluded that the loudest hum represented a % majority of those voicing an opinion. That was my impression as well. --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 08:23:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02102 for ; Tue, 7 Aug 2001 08:23:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U5j5-000NB2-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 05:12:47 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U5j4-000NAw-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 05:12:46 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U5db-00029D-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 13:07:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: James Aldridge To: Jim Bound cc: Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Tue, 07 Aug 2001 06:28:30 EDT." Date: Tue, 07 Aug 2001 12:34:52 +0200 Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Bound wrote: > I felt consensus for number 3 is my input. That was my view too. There certainly seemed to be consensus for using AAAA records for production and deprecating A6 records (either as experimental or historic) --James > > /jim > > > On Tue, 7 Aug 2001, Matt Crawford wrote: > > > I have overheard nearly opposite outcomes quoted by random people > > in the halls, and some of the joint co-chairs (all the ones I've > > asked so far) seem reluctant to say anything substantive in public > > about the outcome of the joint dnsext/ngtrans meeting. I know there > > are some interested parties who were not present and I have no idea > > whether or how well they heard it on the mbone. So, here's my > > view from the floor ... other views would be welcome, the sooner > > the better. > > > > There was a lot of discussion, culminating with a "hum" on the > > following four choices: > > > > 1. Deploy A6 in full panoply, synthesize AAAA for transition period > > 2. Deploy A6 conservatively ("A6 0"), synthesize as above > > 3. Reclassify A6 as experimental, use AAAA for production > > 4. Reclasify A6 as historic, use AAAA for production. > > > > The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all > > accounts. There was quite obviously no consensus (i.e., unanimity) > > or rough consensus (in the usual IETF sense of near-unanimity). It > > could not even be concluded that the loudest hum represented a > > majority of those voicing an opinion. > > > > The difference in impressions taken away, therefore, I would account > > for by differences in opinion about whether the preference of a > > plurality, possibly a slim majority, represent a decision to alter the > > status quo. (That being A6 on the standards track.) > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 08:50:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02572 for ; Tue, 7 Aug 2001 08:50:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U6At-000O6v-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 05:41:31 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U6Ar-000O6e-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 05:41:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U65U-0002B8-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 13:35:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <5.1.0.14.1.20010807080026.034287b0@127.0.0.1> Date: Tue, 07 Aug 2001 08:01:17 -0400 To: Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Marc Blanchet Subject: Re: Joint DNSEXT & NGTRANS summary In-Reply-To: <200108071010.f77AAYm24838@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit While I vote for 3, I do agree with your reading that: - 3 > others - the hummm was not cristal clear. Marc. At/À 05:10 2001-08-07 -0500, Matt Crawford you wrote/vous écriviez: >I have overheard nearly opposite outcomes quoted by random people >in the halls, and some of the joint co-chairs (all the ones I've >asked so far) seem reluctant to say anything substantive in public >about the outcome of the joint dnsext/ngtrans meeting. I know there >are some interested parties who were not present and I have no idea >whether or how well they heard it on the mbone. So, here's my >view from the floor ... other views would be welcome, the sooner >the better. > >There was a lot of discussion, culminating with a "hum" on the >following four choices: > >1. Deploy A6 in full panoply, synthesize AAAA for transition period >2. Deploy A6 conservatively ("A6 0"), synthesize as above >3. Reclassify A6 as experimental, use AAAA for production >4. Reclasify A6 as historic, use AAAA for production. > >The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all >accounts. There was quite obviously no consensus (i.e., unanimity) >or rough consensus (in the usual IETF sense of near-unanimity). It >could not even be concluded that the loudest hum represented a >majority of those voicing an opinion. > >The difference in impressions taken away, therefore, I would account >for by differences in opinion about whether the preference of a >plurality, possibly a slim majority, represent a decision to alter the >status quo. (That being A6 on the standards track.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 08:54:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02696 for ; Tue, 7 Aug 2001 08:54:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U6FT-000OD8-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 05:46:15 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U6FS-000OD2-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 05:46:14 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U6A5-0002Bg-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 13:40:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS summary In-Reply-To: Message from Matt Crawford of "Tue, 07 Aug 2001 05:10:34 CDT." <200108071010.f77AAYm24838@gungnir.fnal.gov> Date: Tue, 07 Aug 2001 13:41:20 +0100 From: Rob Austein Message-Id: <20010807124125.D8C884A5@z.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Er, Matt, AAAA -and- A6 are both currently proposed standards. Other than that (and its implications on what the "status quo" is), I agree with your summary. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 10:29:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04829 for ; Tue, 7 Aug 2001 10:29:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U7aW-0000sG-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 07:12:04 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U7aW-0000s9-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 07:12:04 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U7V8-0002Gs-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:06:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108071335.f77DZmH23156@birch.ripe.net> To: namedroppers@ops.ietf.org Subject: Implementation detail in DS-draft Date: Tue, 07 Aug 2001 15:35:48 +0200 From: Olaf Kolkman Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Olafur, I'm trying to hack DS into Net::DNS I have a small implementation question. In section 2.3 you allow a textual representation of the algorithm. I have not seen this in other DNSSEC specs and I am affraid it might lead to confusion and errors. It could be confusing for system admins to find the propper way to type the name of an algorithm. RSA RSA/SHA1 RSA-SHA1 RSASHA1 In perl this will be easy to implement with a couple of regexps but if the exact names of the algorithms are not defined one might get confusion while implementing. Unless names are used for algorithms elsewhere in the DNSSEC implementations I'd vouch for a number representation of the algorithm only. --Olaf to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 10:29:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04840 for ; Tue, 7 Aug 2001 10:29:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U7e8-00013V-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 07:15:48 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U7e7-00013I-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 07:15:47 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U7Yj-0002H8-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:10:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 7 Aug 2001 09:56:05 -0400 (EDT) From: Olafur Gudmundsson To: DNSEXT mailing list , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com cc: dnsop@cafax.se Subject: DNSEXT NGTRANS Joint meeting DRAFT minutes In-Reply-To: <20010807124125.D8C884A5@z.hactrn.net> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit DNS-EXT/NGTRANS joint meeting on How to represent IPv6 addresses in DNS IETF-51, London - 6 August 2001 Olafur Gudmundsson, Alain Durand & Tony Hain chairing Minutes by: Bob Fink, David Lawrence, Jun-ichiro itojun Hagino (thanks for great minutes) Edited by Bob Fink and Olafur Gudmundsson This is draft minutes, please send edits/corrections for final minutes before 23:00 London time Thursday (2001/08/09) to ogud@ogud.com ----- Agenda Introduction (2 min) - Olafur Bit labels (5 min) - Alain DNAME use in reverse IPv6 tree (5 min) - Alain AAAA vs A6 (60 min) - Alain Consensus building (40 min) - Tony Summary (8 min) -Olafur ----- Short names: Full names Alain Alain Durand Bob Bob Hinden Christian Christian Huitema Erik Erik Nordmark Itojun Jun-ichiro itojun Hagino Matt Matt Crawford Olafur Olafur Gudmundsson Perry Perry Metzger Randy Randy Bush Rob Rob Austein Steve Steve Deering Thomas Thomas Narten Tony Tony Hain Introduction Olafur explained that the meeting goal is to find rough consensus on how to go forward with representation of IPv6 addresses in DNS. The meeting output will be an ID summarizing the meeting consensus, which will be taken to the appropriate mailing list(s). ---- Bit labels - Alain Are bit labels necessary in IPv6 DNS reverse tree, and is anybody planning to delegate on the last 4 bits? Matt Crawford stated that Bit Labels are not necessary if you are willing to do the delegation hack on non-nibble boundaries. Rob Austein explained that the last 4 bits meant a /125 or larger. There was no response from the floor to the questions posed by Alain. Andrea Gustafsson asked for someone to clarify why last 4 bits are special. Randy Bush explained that the issue is allocations in the last label when using a text-based name format in the reverse tree. In IN-ADDR.ARPA that means allocations in the last octet; in the text based version of IP6.ARPA (nibbles, not bitlabels), that means allocations in the last nibble. Being there was no discussion, Alain moved on. -- DNAME use in reverse IPv6 tree - Do we need DNAME in the IPv6 reverse tree? Alain noted that other DNAME uses were out of scope for the discussion. Christian noted that if you really want renumbering on fly, DNAME is needed, thus it follows the decision on need for A6. Matt Crawford noted that there is value in forward tree, even if not in reverse tree. Michael Patton said that we if we do A6, require DNAME in reverse tree, but if AAAA only, there is some value. Matt said that DNAME can be used to keep reverse map in the same zone as direct map. Alain asked if this was still true if there were only AAAA and no A6. Matt said yes. Olafur summarized that, given the limited defense of DNAME it was a DNS decision on whether other uses of DNAME justified it. --- AAAA vs A6 - Does anybody have any other application that requires A6, that can not be done by back-end processing and are not covered by draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt? Christian noted a point only partially covered by Rob's ID. Assumption is a db with all systems listed. There are schemes where hosts push addresses to db and when renumbering, there are individual decision that 1000's of hosts could to update the DNS with. Perry Metzger stated that if one does the db right, then tools can do it cleanly, no special protocol hacks are needed. We only think not due to lack of tools. It's only a SMOP :-), like MOIRA (sp) at MIT. Matt Crawford noted that this still relies on tools not yet written. A6 buys ability to register as single RR in db for all prefixes as it goes. Perry understands desire, but believes tools are needed, and for more than A6. Jim Bound asked if, assuming backend processing (with better tools than we now have), to evaluate if A6 make it more efficient, and thus worth implementing in this context. Olafur said, yes, a natural representation in db looking something like A6, would help. Jim Bound responded if we then agree, lets focus in the direction A6 points. Bill Sommerfield - I worked on MOIRA (sp) at MIT (that Perry mentioned as example) and I don't think that is for all sites. Wrong to force on all sites where model might not fit. Matt Crawford noted that missing from questions is, we focus on "today", not if it is needed in future. E.g., changes in routing system might need A6. - Is IPv6 going to do rapid renumbering or GSE-like routing? Bob Hinden asked if hourly or daily likely? Weekly/monthly most likely, i.e., not all that rapid. Rapid renumbering was not an original (or even current) goal for IPv6. Tony GSE is a "per packet" renumbering Matt Crawford noted that there was lots of discussion for minimal allocation size (i.e., the /48 issue). There are other ways for a body/system to move that might require rapid renumbering. One can't say for sure rapid renumbering won't be needed, and thus A6. Margaret Wasserman asked if we ware talking automated renumbering or not. Rob stated that if IPv6 going to do automated renumbering frequently, that quad A can't cope with it, even with better tools, due to issues like resigning time Christian noted there are scenarios with several prefixes: e.g., one might toggle between them on a daily basis or faster. Christian felt that for fire exit usage, if renumbering not used often (to check that it works) it would never be used. Steve Deering felt that many sites will have to renumber enough to know protocol (and implementations) work. Christian noted that the argument on renumbering seems to be gated on resigning. He is not convinced that we can't do security right. Steve stated that on issues other than security, an important goal with IPv6 is to make renumbering easier, but to make it occur very fast is unsolved, for more than just DNS records. Thus if we do rapid renumbering, it will be a very different architecture, e.g., GSE, and it is likely that it would keep site ignorant of changes and thus A6 wouldn't help. Ted Hardy asked if there are there applications for rapid renumbering, that happen faster than route propagation, that fall under multi-homing. Renumbering that happens faster than route propagation won't work. Alex K (?) asked if we know what the future is. IPv6 will be used in new applications beyond our current Internet, and who knows what these uses are. Choice is either put A6 flexibility there for the future, or stop developing A6 now and invent something new in future. Jim Bound agreed w/Steve that one can't guarantee rapid renumbering. A6 is a tool that underwent significant development and that it is an abstraction like scoping, multi-casting, that adds quality to the IPv6 architecture. Users will need renumbering to adopt IPv6. Perry asked at what costs. DNS queries are under fire for getting slower. Confident that he could renumber in hours or days, but probably not faster. It does work with AAAA, though he admitted his experience was for a small site. Randy noted that the problem with doing A6 for possibility of rapid renumbering is following dreams, not reality. To get v6 traction, A6 not helping. Jim Bound agreed with Randy, but would like to see if A6 0 would work and do testbeds to see what works. Concerned that the code base (we now have) might be useful might be thrown away before we learn from it. Simon Leinen noted that the performance issues are not straight forward. A6 request might be handled faster than AAAA, when host has many addresses. Matt Crawford asked do you think we can deploy A6 later on and really get it deployed? Randy noted that playing with A6, IPv6 folk are maintaining their code better than v4 folk may be. If we do renumbering it is analogous to, "do we do the routing thing". A6 is a solution to a problem we haven't yet defined, and constrains our solutions in future. Rather solve our problems and solve DNS stuff after. Matt Crawford asked again if we can make a change in the future like that? Thomas Narten asked, if we do rapid renumbering, are other changes needed? Then couldn't putting in changes for DNS be done too? Steve Deering noted that we have AAAA, and going to A6 0 is a "no brainer", but if it is lots of work to change to A6 for a limited value, is it worth it? Someone (name please ??) asked if we do A6 0, isn't it really just as hard to do a full-blown A6 later? Theo Pagtzis asked how would A6 handle really rapid renumbering? Steve Deering noted again, Mobile IP could do it, thus A6 not needed useful for rapid renumbering. Olafur felt that translation of A6 0 is easy, synthesis easy. The only question is then one of delay. Some company has done this already. Steve Deering asked, at what transition cost? Simon Linen (??) stated that AAAA and A6 are easy, and both can be deployed at the same time in the same zone, simple to have tools maintain one record type from the other. Itojun stated that maintaining A6 and AAAA is not easy. Rob Austein asked if mechanisms ease pain, as it is several years to do transition. This was discussed in Minneapolis. Another variation is to modify servers to generate A6 0 when quad AAAA is found. Though, when translating either way, signature is lost. However, it is important to not use A6 in complex ways. It is an attractive nuisance in that it does encourage people to try to exploit A6 beyond reasonable usage. Matt Crawford felt that transition best be kept short. Itojun is concerned that Rob says years to do transition tools and that his users can't wait. Alain stated that the plan from Minneapolis roughly described the transition. Rob said that Itojun correct; we can't take a long time for a transition. It is important to decide on A6 very soon. Mohsen Suissi from FRNIC noted that many users have been waiting for years to move to IPv6 production. AAAA works fine. If we say we have to move to A6 0 and wait for bind 9, and/or new O/S, we are waiting for more years. customers keep waiting. Itojun asked how many BIND 4 servers are still around versus BIND 9? Perry - how many folks using v6 all the time. A number of hands. Of these how many could run A6 soon, not so many of the hands. Folks around us using AAAA, can we go backwards and wait? Randy asked that for installed AAAA base would you use A6, and the he would, if it was a significant value, which it isn't. Jim Bound would change resolvers not O/S thus AAAA use would continue and this is only an operational issue. Margaret Wasserman asked why this is an issue of one against other. We have AAAA, so question is do we continue to work on A6, say as experimental. Plan for success, for renumbering, why not keep both? Steve Deering agree w/Margaret and Jim. Lack of decision here doesn't keep people from moving to IPv6. It should not be viewed as blocking IPv6. Alain said that the root operators are trying to get IPv6 accessible root servers, and that they are concerned about what to implement. --- Returning to GSE-like routing usage for A6 Randy stated that if a critical architectural change needed for A6, he would support it. However, we don't know what it will be yet. Thomas said that when Rob talked about transition time being a couple years this means at least 2, but he believes it would take 5 years given what is shipping and what current plans are. Tony Hain also noted that since decision is taking a while, we are talking about 6 months. before real development could even start. Maybe it's a 7 year transition. ==== consensus building (one minute break while chairs huddle) Tony Hain summarized what we are hearing from this meeting's discussions: --- Bitstring not necessary, so will take to list to confirm. --- DNAME - only one case where its necessary is if we choose A6. Matt believes you don't need but will really wish for it. Rob said without A6, DNAME use is a more general DNS question, i.e., equally relevant to v4. So again Tony noted that we will take to list to confirm. --- A6/AAAA - tools needed, and could make host push update vs relational db work. So again Tony noted that we will take to list to confirm. --- Renumbering - no consensus on time frames and out of scope here. If rapid implies less than hourly and requires significant architectural change than DNSSEC fails in verifying signature changes. Randy agreed but asked that GSE/8+8 also is in category of rapid renumbering (i.e., can't tell now if it will happen or when, and what it will look like). Also, noted that it is an operationally attractive nuisance. --- Consensus building - Straw polling the 4 address options for rough consensus: - full A6 development with AAAA synthesis - low hum, then a slightly louder hum when asked again - A6 0 w/ AAAA synthesis - medium hum, then a slightly louder hum when asked again - AAAA deployed, A6 to experimental - larger hum, then a slightly louder hum when asked again Randy elaborated that the value of going to Experimental means anyone using A6 has a consistently specified A6 spec to use. Thomas added, we want to signal developers about our A6 shipping intentions, and how defaults are set. Bill Manning believes AAAA should be left in standards track, and A6 to experimental. - AAAA deployed, A6 to historic - medium hum, then a slightly louder hum when asked again It was sense of the room that the hums indicated deploying AAAA and putting A6 to Experimental. Again, this will be take to list to confirm. - Bit labels - - make historic - medium hum - make experimental - loud hum - keep - no hum taken due to lack of comment earlier Therefore, DNAME for bit label use is limited to experimental use. When someone asked if the ip6.int vs ip6.arpa choice was going to be discussed, it was noted that it was out of scope for this group as it was an IAB decision. There was a brief discussion of what list the discussion should go to. Randy and Erik (our area directors in attendance) agreed it should fall under DNSEXT. and the results published to all the other lists. --- Meeting adjourned (ahead of schedule) Summary of of meeting consensus to be verified on mailing lists: - AAAA stays on standards track in DNSEXT, - A6 moved to experimental by DNSEXT - Bitlabels moved to experimental by DNSEXT - DNAME standardization is out scope. -end to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 10:45:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05247 for ; Tue, 7 Aug 2001 10:45:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U7u0-0001oQ-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 07:32:12 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U7u0-0001oJ-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 07:32:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U7oc-0002It-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:26:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.0.2.1.2.20010807071618.020ca308@localhost> Date: Tue, 07 Aug 2001 07:21:31 -0700 To: , "Matt Crawford" From: "David R. Conrad" Subject: RE: Joint DNSEXT & NGTRANS agenda Cc: , , In-Reply-To: References: <200108062157.f76LvDm21797@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 03:07 PM 8/7/2001 +0100, Tony Hain wrote: >> These customers that bolt to avoid renumbering -- they will take >> their portable IPv6 address blocks with them? Portable IPv6 address blocks? Interesting concept. >The point was simply they would find a way to avoid recurring pain. Yeah. Like NAT. Rgds, -drc to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 10:45:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05255 for ; Tue, 7 Aug 2001 10:45:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U7ox-0001Wv-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 07:26:59 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U7ox-0001Wm-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 07:26:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U7jZ-0002IX-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:21:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Tony Hain" To: "Matt Crawford" Cc: , , Subject: RE: Joint DNSEXT & NGTRANS agenda Date: Tue, 7 Aug 2001 15:07:40 +0100 Message-ID: In-Reply-To: <200108062157.f76LvDm21797@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Matt Crawford wrote: > These customers that bolt to avoid renumbering -- they will take=20 > their portable IPv6 address blocks with them? The point was simply they would find a way to avoid recurring pain.=20 Tony =20 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 10:46:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05331 for ; Tue, 7 Aug 2001 10:46:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U7uJ-0001q6-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 07:32:31 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U7uJ-0001pv-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 07:32:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U7os-0002Iw-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:26:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108071423.f77ENqd68433@open.nlnetlabs.nl> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: "from James Aldridge at Aug 7, 2001 12:34:52 pm" To: James Aldridge Date: Tue, 7 Aug 2001 16:23:52 +0200 (CEST) CC: Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Alexis Yushin Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once James Aldridge wrote: >Jim Bound wrote: >> I felt consensus for number 3 is my input. > >That was my view too. There certainly seemed to be consensus for using AAAA >records for production and deprecating A6 records (either as experimental or >historic) I see a big difference between deprecating/moving to historic and changing status to experimental. Experemental implies further development. Alexis to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 12:29:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07739 for ; Tue, 7 Aug 2001 12:29:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U9NO-0004Jt-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 09:06:38 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U9NO-0004Jm-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 09:06:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U9I3-0000BV-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 17:01:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: James Aldridge To: alexis@nlnetlabs.nl cc: Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Tue, 07 Aug 2001 16:23:52 +0200." <200108071423.f77ENqd68433@open.nlnetlabs.nl> Date: Tue, 07 Aug 2001 17:22:37 +0200 Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alexis Yushin wrote: > I see a big difference between deprecating/moving to historic and changing > status to experimental. Experemental implies further development. I think that "implies" might be a bit strong - "permits" might be more appropriate (just check rfc-index.txt for all those ancient "experimental" RFCs). But, yes, I do recognise the difference. James to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 12:33:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07851 for ; Tue, 7 Aug 2001 12:33:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U9Qt-0004PD-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 09:10:15 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U9Qt-0004Ox-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 09:10:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U9LY-0000Bl-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 17:04:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 7 Aug 2001 17:35:41 +0200 (MEST) From: Jakob Schlyter To: DNSEXT Cc: Olafur Gudmundsson Subject: Re: draft-ietf-dnsext-delegation-signer-01 In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 5 Aug 2001, Jakob Schlyter wrote: > section 2.1, protocol change, says: > > DS record MUST only appear at secure delegations in the parent zone. > The record lists the child's keys that SHOULD sign the child's key > set. Insecure delegation MUST NOT have a DS record, the presence of > DS record SHOULD be considered a hint that the child might be secure. > Resolver MUST only trust KEY records that match a DS record. as olafur pointed out personally to me, you may not write should in lowercase. updated text below: DS record MUST only appear at secure delegations in the parent zone. Secure delegations MUST have a DS record. Insecure delegations MUST NOT have a DS record. Therefore the presence of a DS record is an indication that the child is secure. The child MUST sign its key set with at least one of the keys listed in the DS record at the parent. jakob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 12:36:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07902 for ; Tue, 7 Aug 2001 12:36:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U9XH-0004Zn-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 09:16:51 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U9XH-0004Zh-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 09:16:51 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U9XG-0000C4-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 17:16:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108071600.f77G0TH62930@as.vix.com> To: Alexis Yushin cc: James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: Message from Alexis Yushin of "Tue, 07 Aug 2001 16:23:52 +0200." <200108071423.f77ENqd68433@open.nlnetlabs.nl> Date: Tue, 07 Aug 2001 09:00:29 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I see a big difference between deprecating/moving to historic and changing > status to experimental. Experemental implies further development. I don't see that difference here. Just as "let's let the market decide" really just means "let's do whatever Microsoft wants", so it is that "let's make it experimental" really just means "let's move on." (I find it amusing that SRV was experimental but that Microsoft's use of it pulled it forward.) I was not able to be in London, but had I been there my comments would've been: Let's not expect stub resolvers to do the caching necessary to understand either A6 or SIG/KEY -- those are things which servers ought to use to talk to other servers. Stub resolvers making recursive requests of their name servers should be using AAAA and TSIG. AAAA synthesis of underlying A6, and TSIG to protect verified KEY/SIG data for the last mile, is all a client needs. Every argument against SIG/KEY or against A6 comes down to either the caching problem or the complexity problem, and if we insulate the end-stations from those problems, the arguments are reduced to things which authority-side tools can be made to cope with. Hopefully this point was made by somebody. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 12:42:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08036 for ; Tue, 7 Aug 2001 12:42:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15U9dH-0004ks-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 09:23:03 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15U9dG-0004kk-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 09:23:02 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15U9dF-0000DY-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 17:23:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul A Vixie Cc: Alexis Yushin , James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: vixie's message of Tue, 07 Aug 2001 09:00:29 MST. <200108071600.f77G0TH62930@as.vix.com> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 08 Aug 2001 01:20:00 +0900 Message-Id: <20010807162000.AC56F7BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I see a big difference between deprecating/moving to historic and changing >> status to experimental. Experemental implies further development. > >I don't see that difference here. Just as "let's let the market decide" >really just means "let's do whatever Microsoft wants", so it is that "let's >make it experimental" really just means "let's move on." (I find it amusing >that SRV was experimental but that Microsoft's use of it pulled it forward.) > >I was not able to be in London, but had I been there my comments would've been: > > Let's not expect stub resolvers to do the caching necessary to > understand either A6 or SIG/KEY -- those are things which servers > ought to use to talk to other servers. Stub resolvers making > recursive requests of their name servers should be using AAAA and > TSIG. AAAA synthesis of underlying A6, and TSIG to protect > verified KEY/SIG data for the last mile, is all a client needs. > Every argument against SIG/KEY or against A6 comes down to either > the caching problem or the complexity problem, and if we insulate > the end-stations from those problems, the arguments are reduced to > things which authority-side tools can be made to cope with. i have a major concern with AAAA synthesis - which is, it is unclear as to who needs to AAAA synthesis. the concern is mentioned in my draft. - you can't guarantee every first-hop DNS server to do AAAA synthesis. - if anyone does not, AAAA queries go into non-first-hop DNS servers by recurse (imagine when pre-BIND9/non-BIND name server is used as the first-hop name server). therefore, AAAA synthesis basically asks everyone to run AAAA and A6 in parallel, which raises a lot of concerns (query delays if you query both, database maintenance cost if you maintain both in zone, no-sign if you synthesize, and a lot of others). itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 18:22:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13374 for ; Tue, 7 Aug 2001 18:22:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UEyN-000Dks-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 15:05:11 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UEyN-000Dkm-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:05:11 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UEyL-0000He-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 23:05:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108071638.f77GclL68959@open.nlnetlabs.nl> Subject: Re: DNSEXT NGTRANS Joint meeting DRAFT minutes In-Reply-To: "from Olafur Gudmundsson at Aug 7, 2001 09:56:05 am" To: Olafur Gudmundsson Date: Tue, 7 Aug 2001 18:38:47 +0200 (CEST) CC: DNSEXT mailing list , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, dnsop@cafax.se From: Alexis Yushin Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once Olafur Gudmundsson wrote: >Alex K (?) asked if we know what the future is. IPv6 will be used in Alexis Yushin, thank you very much! Alexis >new applications beyond our current Internet, and who knows what these >uses are. Choice is either put A6 flexibility there for the future, or >stop developing A6 now and invent something new in future. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 18:24:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13390 for ; Tue, 7 Aug 2001 18:24:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UF3A-000Dto-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 15:10:08 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UF3A-000Dth-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:10:08 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UF39-0000Hs-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 23:10:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200108071640.BAA29773@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA29773; Wed, 8 Aug 2001 01:40:40 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010807101629.AA1BA7BA@starfruit.itojun.org> from Jun-ichiro itojun Hagino at "Aug 7, 2001 07:16:29 pm" To: Jun-ichiro itojun Hagino Date: Wed, 8 Aug 2001 01:40:38 +0859 () CC: Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun; > >1. Deploy A6 in full panoply, synthesize AAAA for transition period > >2. Deploy A6 conservatively ("A6 0"), synthesize as above > >3. Reclassify A6 as experimental, use AAAA for production > >4. Reclasify A6 as historic, use AAAA for production. > > > >The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all > >accounts. There was quite obviously no consensus (i.e., unanimity) > > I would say 3 >> 2 > 1 > 4, heard from my location (near the > VGA projector). So? Considering that mailing lists are the WGs... Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 18:27:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13443 for ; Tue, 7 Aug 2001 18:27:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UF2s-000DtJ-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 15:09:50 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UF2r-000DtD-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:09:49 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UF2q-0000Ho-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 23:09:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108071640.f77Ge9K68980@open.nlnetlabs.nl> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: "from James Aldridge at Aug 7, 2001 05:22:37 pm" To: James Aldridge Date: Tue, 7 Aug 2001 18:40:09 +0200 (CEST) CC: alexis@nlnetlabs.nl, Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Alexis Yushin Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once James Aldridge wrote: >Alexis Yushin wrote: >> I see a big difference between deprecating/moving to historic and changing >> status to experimental. Experemental implies further development. > >I think that "implies" might be a bit strong - "permits" might be more >appropriate (just check rfc-index.txt for all those ancient "experimental" >RFCs). But, yes, I do recognise the difference. Well, to be more specific we do plan on doing quite some more research and testing in the A6 area. (We as in NLnet Labs) Alexis to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 18:30:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13520 for ; Tue, 7 Aug 2001 18:30:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UF8X-000E60-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 15:15:41 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UF8W-000E5u-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:15:40 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UF8V-0000IA-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 23:15:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108071748.f77HmHH64664@as.vix.com> To: Jun-ichiro itojun Hagino cc: Alexis Yushin , James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: Message from Jun-ichiro itojun Hagino of "Wed, 08 Aug 2001 01:20:00 +0900." <20010807162000.AC56F7BA@starfruit.itojun.org> Date: Tue, 07 Aug 2001 10:48:17 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > i have a major concern with AAAA synthesis - which is, it is unclear > as to who needs to AAAA synthesis. the concern is mentioned > in my draft. > > - you can't guarantee every first-hop DNS server to do AAAA synthesis. > - if anyone does not, AAAA queries go into non-first-hop DNS servers > by recurse (imagine when pre-BIND9/non-BIND name server is used > as the first-hop name server). > > therefore, AAAA synthesis basically asks everyone to run AAAA and A6 > in parallel, which raises a lot of concerns (query delays if you query > both, database maintenance cost if you maintain both in zone, no-sign > if you synthesize, and a lot of others). i would much rather deal with those problems, since they are solvable, then to deal with non-renumberable 128 bit addresses, since they simply lead to NAT. i cannot emphasize strongly enough that vast numbers of transit-consumers who lack the various powers needed to own portable address space will NOT deploy globally addressable IPv6 space if it simply means that they will become even more captive of their ipv6-transit providers than they are of their ipv4-transit providers today. the gprs and other mobile data providers are mostly going to be able to own portable address space so they don't care about this issue. but for "the enterprise" this is a real problem. if ipv6 is no easier to renumber than ipv4, then we're going to see large scale NAT. much larger scale NAT than we see today. being a captive customer of some transit provider when you only have an ipv4 /24 or even a /20 that you have to renumber if you change providers has difficulty N. being a captive customer of some transit provider when you have an ipv6 /64 to renumber if you change providers has difficulty N*(2^44). if NAT is used then the difficulty in either case is a constant, and for that matter, it's the same constant. so, "let's standardize both and let the market decide." but right now i'm hearing three camps trying to kill A6: implementors who consider bitstring, A6, and DNAME "too hard to do" transit providers who like the idea of captive ipv6 /64 customers transit customers who have enough power to own their own ipv6 blocks who in this mix is representing the interests of the average MIS manager? (and who do you think is going to drive the ipv6 economy, anyhow?) this debate borders on "simply unbelievable." to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 7 18:37:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13615 for ; Tue, 7 Aug 2001 18:37:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UFDM-000EGj-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 15:20:40 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UFDL-000EGX-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:20:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UFDK-0000Ii-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 23:20:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20010807143808.00a8ed00@mail.amaranth.net> Date: Tue, 07 Aug 2001 14:43:18 -0400 To: Keith Moore , James Aldridge From: Daniel Senie Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <200108071823.OAA07760@astro.cs.utk.edu> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 02:23 PM 8/7/01, Keith Moore wrote: >Seems like we really need a group to study how to do renumbering. >Such a group needs to consider not just DNS but everything that >renumbering affects - e.g. DNS, routers, hosts, firewalls, applications >using address-based authentication, long-running applications, and >large-scale distributed applications. We need to consider the >whole process of renumbering rather than trying to solve the problem >in a piecemeal fashion. > >Keith This could be a worthwhile undertaking. There are two possible aspects of such a group: developing protocols and standards to lessen the effort in renumbering, and providing information on how to survive renumbering in the present world. An example of providing information would be a handbook for the administrator facing a move to a new colo. Getting the timing of Registry changes (for TLD zone NS glue), DNS changes, and server changes done in proper order requires significant planning. I suspect many folks just get it wrong, and suffer with outages for longer than they need to. Having a document to enumerate the steps to follow could be a good deliverable of such a group. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 02:47:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06962 for ; Wed, 8 Aug 2001 02:47:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UMmv-0001bk-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 23:25:53 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UMmu-0001be-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 23:25:52 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UMms-0000cQ-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 07:25:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 8 Aug 2001 00:14:32 -0000 Message-ID: <20010808001432.8394.qmail@cr.yp.to> From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <200108071748.f77HmHH64664@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie writes: > so, "let's standardize both and let the market decide." So you don't mind us deploying clients that look for only AAAA and A? And you don't mind us deploying caches that don't convert A6 to AAAA? The BIND company will stop saying things like I will note that djbdns does not support A6, DNAME, bitstring labels, and other modern features of the DNS. We did not have the luxury of ignoring IETF standards; we prefer to work and play well with others. and start saying things like ``Apparently the market has decided to use AAAA'' and ``Beware that clients won't look for your A6/DNAME records''? > who in this mix is representing the interests of the average MIS manager? Such as a manager wondering why his users are having sporadic problems reaching www.i.am? Or a manager who wants his site renumbered _now_, and can't wait several years for universal client-side A6 support? Or a manager unable to find DNS software with the features he wants, because DNS implementors have to waste so much time on garbage like A6? > if ipv6 is no easier to renumber than ipv4, then we're going to see large > scale NAT. much larger scale NAT than we see today. Explain. If the renumbering costs are the same, why will NAT become more popular? Why will users become ``even more captive''? The NAT sites I've seen are using it for precisely one reason: to conserve precious IPv4 address space. They won't use NAT with IPv6. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 02:51:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07023 for ; Wed, 8 Aug 2001 02:51:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UMnk-0001d7-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 23:26:44 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UMnj-0001d1-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 23:26:43 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UMni-0000cU-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 07:26:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.0.2.1.2.20010807172339.0301adb0@localhost> Date: Tue, 07 Aug 2001 17:31:59 -0700 To: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: "David R. Conrad" Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010808001432.8394.qmail@cr.yp.to> References: <200108071748.f77HmHH64664@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan, At 12:14 AM 8/8/2001 +0000, D. J. Bernstein wrote: >The NAT sites I've seen are using it for precisely one reason: to >conserve precious IPv4 address space. Large organizations also use NAT so they aren't held hostage by their service provider. Really. If you don't believe me, ask any large organization that does not have "portable" address space. >They won't use NAT with IPv6. Yes, they will. As soon as they are told by their new ISP that they must renumber, they'll question if they are any better off than they were with IPv4. Neat thing about IPv6 is that everyone will be in the same boat -- no historical "portable" prefixes, right? The argument can be made that you can renumber with AAAA, but pretending that renumbering is not an incentive to use NAT is just silly. Rgds, -drc P.S. Sorry if this is considered heretical. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 05:06:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08559 for ; Wed, 8 Aug 2001 05:06:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UP4M-0005bV-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 01:52:02 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UP4L-0005bP-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 01:52:01 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UP4K-0000mQ-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 09:52:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200108080830.RAA02821@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA02821; Wed, 8 Aug 2001 17:30:21 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.0.2.1.2.20010807172339.0301adb0@localhost> from "David R. Conrad" at "Aug 7, 2001 05:31:59 pm" To: "David R. Conrad" Date: Wed, 8 Aug 2001 17:30:20 +0859 () CC: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit drc; > >The NAT sites I've seen are using it for precisely one reason: to > >conserve precious IPv4 address space. > > Large organizations also use NAT so they aren't held hostage by their > service provider. Really. If you don't believe me, ask any large > organization that does not have "portable" address space. So, you are saying that the large organiation is currently accepting to manually change IP addresses of DNS servers on renumbering, aren't you? They should have small (maybe two) number of nameservers for the entire organization visible from the outside in the public Internet and willing to renumber them or have none and ask someone operate ones. If so, A6 is perfectly fine for it for easy and quick renumbering. > The argument can be made that you can renumber with AAAA, but pretending > that renumbering is not an incentive to use NAT is just silly. The only thing to do is to have an RFC for the organization to tell renumbering with A6 is as easy as with NAT. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 05:30:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08854 for ; Wed, 8 Aug 2001 05:30:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UPWO-0006T5-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 02:21:00 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UPWN-0006Sy-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 02:20:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UPWM-0000nb-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 10:20:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200108080906.f7896Nf20107@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: moore@cs.utk.edu (Keith Moore) Date: Wed, 8 Aug 2001 02:06:23 -0700 (PDT) Cc: jhma@KPNQwest.net (James Aldridge), seamus@bit-net.com (Jim Bound), crawdad@fnal.gov (Matt Crawford), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <200108071823.OAA07760@astro.cs.utk.edu> from "Keith Moore" at Aug 07, 2001 02:23:41 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % % Seems like we really need a group to study how to do renumbering. % Such a group needs to consider not just DNS but everything that % renumbering affects - e.g. DNS, routers, hosts, firewalls, applications % using address-based authentication, long-running applications, and % large-scale distributed applications. We need to consider the % whole process of renumbering rather than trying to solve the problem % in a piecemeal fashion. % % Keith % PIER did look at renumbering from the IPv4 perspective. We explicitly did not consider IPv6 issues as IPv6 was still newly hatched. Perhaps it is time to revisit PIER in light of the current state of IPv6. If there is interest, pier-request@isi.edu -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 06:09:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09416 for ; Wed, 8 Aug 2001 06:09:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UQ2D-0007V4-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 02:53:53 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UQ2D-0007Ux-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 02:53:53 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UQ2C-0000qz-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 10:53:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 04:40:59 -0500 From: Matt Crawford Subject: Re: (ngtrans) DNSEXT NGTRANS Joint meeting DRAFT minutes In-reply-to: "07 Aug 2001 09:56:05 EDT." To: Olafur Gudmundsson Cc: DNSEXT mailing list , ipng@sunroof.eng.sun.com Reply-to: DNSEXT mailing list Message-id: <200108080941.f789f0m00339@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Matt Crawford noted that missing from questions is, we focus on "today", not if it is needed in future. E.g., changes in routing system might need A6. Not "changes in routing system" but "coupling of DNS prefix delegation to routing system's idea of prefix delegation." > Consensus building Here's the problem. There was no attempt at consenus *building* after the discussion, only a quick measurement of opinions at that point. Given that a state of consensus did not already exist at this point > Straw polling the 4 address options for rough consensus: > ...then a slightly louder hum when asked again... It is my possibly-mistaken recollection that only the first two question were asked twice, becaused of a long interval of discussion after the second. It seems to be everyone's recollection that the fourth alternative got distinctly less volume than any of the other three, yet these minutes state it otherwise. > Therefore, DNAME for bit label use is limited to experimental use. Er, I don't think there was any coupling of DNAME and bit-string labels in the question, so I think you mean to say "bit labels under the reverse tree" or something of that sort. > It was sense of the room that the hums indicated .. There was no meta-question asked about what the hums indicated. Maybe you mean to say "The sense of the room, as measured by hums, was...". But this raises the question of what does this phrase "sense of the room" mean? Further own your minutes you make the leap to > Summary of of meeting consensus to be verified on mailing lists: The sole contentious point seemed to be the four-pronged AAAA vs A6 question, and the aggregated (hum) mass of opinion did not show consensus by any accepted definition of the word, nor even rough consensus by most reckonings. > - AAAA stays on standards track in DNSEXT, > - A6 moved to experimental by DNSEXT I do not believe there was rough consensus on these points. There was a plurality in favor of this option. It's impossible to say whether it was a majority, but it was clearly not an overwhelming majority. > - Bitlabels moved to experimental by DNSEXT There was rough consensus on this. > - DNAME standardization is out scope. I do not recall this question having been asked of the room. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 06:09:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09425 for ; Wed, 8 Aug 2001 06:09:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UQ68-0007dE-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 02:57:56 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UQ68-0007d8-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 02:57:56 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UQ67-0000rV-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 10:57:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Richardson Cc: DNSEXT mailing list , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) DNSEXT NGTRANS Joint meeting DRAFT minutes References: <200108080118.f781IT001109@marajade.sandelman.ottawa.on.ca> From: Johan Ihren Date: 08 Aug 2001 11:54:00 +0200 In-Reply-To: Michael Richardson's message of "Tue, 07 Aug 2001 21:18:29 -0400" Message-ID: <2cd766c1xj.fsf@snout.autonomica.se> Lines: 47 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michael Richardson writes: > >>>>> "Olafur" == Olafur Gudmundsson writes: > Olafur> Steve Deering noted that we have AAAA, and going to A6 0 is a "no > Olafur> brainer", but if it is lots of work to change to A6 for a limited > Olafur> value, is it worth it? > > While going to A6 0 is simple, if the stub resolver implementers > simply ask for "A6 0", i.e. ask for A6 instead of AAAA as if it was > AAAA, then if we come up with a new situation that *requires* A6 X > (X!=0), then we are in trouble. Which is exactly why I think that the claim that A6 0 is equivalent to AAAA is wrong. We should keep the AAAA as "what stub resolvers use" and synthesize it from a DNS infrastructure built from A6. Non-stub resolvers have a choice of whether to deal with possible chains by querying for an A6, or stay with the easier-to-digest form by querying for a AAAA. I really think that the humming in the room was based very much upon fears of delaying deployment further, regardless of technical solution. And a feeling that A6, even in the form of A6 0, would do that (which is correct). Since AAAA synthesis was presented as a transition mechanism, not the "final solution" those concerns won out. > Secondly, those code paths where X!=0 will not get tested even if > they are written, and security may be involved, and wouldn't a > buffer overflow bug in a stub resolver be pretty! By staying with the AAAA for stub resolvers this will simply not happen. Regards, Johan Ihren Autonomica PS. A popular description of the differences between AAAA and A6 is to claim that AAAA is optimized for read, while A6 is optimized for write. Possibly a better way out putting it would have been to say that AAAA is optimised for the (stub) resolver and end applications, while A6 is optimized for the nameserver and DNS infrastructure. By keeping AAAA synthetization as a permenent mechanism rather than as a transition issue it would be possible to optimize for both... to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 06:49:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09939 for ; Wed, 8 Aug 2001 06:49:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UQZc-0008aW-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 03:28:24 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UQZb-0008aQ-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 03:28:23 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UQZa-0000sk-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 11:28:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul A Vixie Cc: Alexis Yushin , James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <200108071600.f77G0TH62930@as.vix.com> From: Johan Ihren Date: 08 Aug 2001 12:02:58 +0200 In-Reply-To: Paul A Vixie's message of "Tue, 07 Aug 2001 09:00:29 -0700" Message-ID: <2c8zguc1il.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie writes: > > I see a big difference between deprecating/moving to historic and changing > > status to experimental. Experemental implies further development. > > I don't see that difference here. Just as "let's let the market decide" > really just means "let's do whatever Microsoft wants", so it is that "let's > make it experimental" really just means "let's move on." (I find it amusing > that SRV was experimental but that Microsoft's use of it pulled it forward.) > > I was not able to be in London, but had I been there my comments would've been: > > Let's not expect stub resolvers to do the caching necessary to > understand either A6 or SIG/KEY -- those are things which servers > ought to use to talk to other servers. Stub resolvers making > recursive requests of their name servers should be using AAAA and > TSIG. AAAA synthesis of underlying A6, and TSIG to protect > verified KEY/SIG data for the last mile, is all a client needs. > Every argument against SIG/KEY or against A6 comes down to either > the caching problem or the complexity problem, and if we insulate > the end-stations from those problems, the arguments are reduced to > things which authority-side tools can be made to cope with. > > Hopefully this point was made by somebody. It was made, but not as succinctly. However, AAAA synthesis was mostly presented as a transition mechanism leading towards an A6-only future. I think that is a mistake and what worries people who are satisfied with their working AAAA-based stub resolver. Your point (in another mail) about renumbering as a defence againg being locked in by your provider was definitely not made. Johan Ihren Autonomica to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 08:35:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11187 for ; Wed, 8 Aug 2001 08:35:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15USCB-000BhF-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 05:12:19 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15USCA-000Bh8-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 05:12:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15USC8-0000w5-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 13:12:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081027.f78ARfH03649@birch.ripe.net> To: Jakob Schlyter cc: DNSEXT , Olafur Gudmundsson Subject: Re: draft-ietf-dnsext-delegation-signer-01 In-reply-to: Your message of Tue, 07 Aug 2001 17:35:41 +0200. References: From: Olaf Kolkman Date: Wed, 08 Aug 2001 12:27:41 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jakob Schlyter writes: * On Sun, 5 Aug 2001, Jakob Schlyter wrote: * * > section 2.1, protocol change, says: * > * > DS record MUST only appear at secure delegations in the parent zone. * > The record lists the child's keys that SHOULD sign the child's key * > set. Insecure delegation MUST NOT have a DS record, the presence of * > DS record SHOULD be considered a hint that the child might be secure. * > Resolver MUST only trust KEY records that match a DS record. * * as olafur pointed out personally to me, you may not write should in * lowercase. updated text below: * * DS record MUST only appear at secure delegations in the parent zone. * Secure delegations MUST have a DS record. Insecure delegations MUST NOT * have a DS record. Therefore the presence of a DS record is an indication * that the child is secure. The child MUST sign its key set with at least * one of the keys listed in the DS record at the parent. After a little chat with Ed, Lars, Johan and Jakob I think we want to word this even more carefully. The problem is in: 'The child MUST sign its key set with at least one of the keys listed' In the case of key compromise the zone administrator of a child zone might want to resign the zones with a completely new key even before the parent has had a change to update their DS record. The 'MUST' in the line quoted above indicates that this operational procedure is illegal. On the other hand it must be clear to a resolver that if the DS record indicates a child zone is secure. The original sentence: ' Insecure delegation MUST NOT have a DS record, the presence of DS record SHOULD be considered a hint that the child might be secure. Resolver MUST only trust KEY records that match a DS record. ' will allow spoofing of unsecured child zone data. I think if the resolver cannot validate the child zone's data using any of the keys that the DS records are pointing to, the child zone MUST be considered bad. I propose the following wording: DS records MUST only appear at secure delegations in the parent zone. The records list the child's keys that SHOULD sign the child's key set. Insecure delegation MUST NOT have a DS record. Secure delegations MUST have at least one DS record. The presence of one or more DS records MUST be considered an indication that the child zone is secure. Resolvers that are not able to find or verify at least one of the child's keys pointed to by the DS records, MUST consider the child zone non-authentic. --Olaf ----------------------------------------------------- Olaf M. Kolkman | RIPE NCC DISI Project ----------- | --------------- RIPE NCC | Phone: +31 20 535 4444 Singel 258 | Fax: +31 20 535 4445 1016 AB Amsterdam | http://www.ripe.net/disi The Netherlands | OKolkman@ripe.net to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 08:40:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11345 for ; Wed, 8 Aug 2001 08:40:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15USLU-000C0N-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 05:21:56 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15USLU-000C0G-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 05:21:56 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15USLS-0000wR-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 13:21:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: From: "Tony Hain" To: "Keith Moore" , "David R. Conrad" Cc: "D. J. Bernstein" , , , , Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Wed, 8 Aug 2001 12:56:27 +0100 Message-ID: In-Reply-To: <200108080130.VAA10224@astro.cs.utk.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > So if we want to avoid NAT in IPv6, we need to make renumbering=20 > *much* easier than it is now. Or accept the reality that enforcing PA as the 'only' approach is=20 in direct conflict with the ultimate goals of the consumer.=20 > ... I think it's reasonable to assume that large numbers of=20 > people will follow the path of least resistance, or perhaps,=20 > of least apparent risk. This is the best description of the problem I have seen. A missing piece is that the local minimum is different depending on your=20 perspective as provider or consumer. Our whole approach is biased toward the provider, partially because of scale, but mostly because=20 they had a voice in the decision while the consumer did not. Yes=20 scale is a real problem, but the fact that the consumer will find the path of least resistance is at least as big. Tony to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 08:47:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11514 for ; Wed, 8 Aug 2001 08:47:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15USQl-000CAK-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 05:27:23 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15USQl-000CAD-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 05:27:23 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15USQk-0000wx-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 13:27:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081212.f78CC7V08616@horst.ait.utk.edu> To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se, uther@horst.ait.utk.edu Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: Message from "D. J. Bernstein" of "08 Aug 2001 00:14:32 -0000." <20010808001432.8394.qmail@cr.yp.to> Date: Wed, 08 Aug 2001 08:12:07 -0400 From: Ron Tipton Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The NAT sites I've seen are using it for precisely one reason: to > conserve precious IPv4 address space. They won't use NAT with IPv6. > > ---Dan Dan, I can only speak for myself, but we (the University of Tennessee) seriously considered using NAT for our dorm network, not because of lack of IPv4 address space, but because of lack of PORTABLE IPv4 address space. Most of our free IPv4 address space belonged to one of our ISPs and we DO NOT want to stay captive to them. In the end we decided to renumber our entire network to avoid NAT, but for us, NAT was a better solution than using IPv4 address space belonging to an ISP. After the pain of that renumbering, I assure you that if IPv6 address space only belongs to ISPs and not to the University of Tennessee, we will NAT to avoid captivity! r Ron Tipton Advanced Internet Technologies University of Tennessee to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 09:30:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12187 for ; Wed, 8 Aug 2001 09:30:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UTE3-000DtS-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 06:18:19 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UTE3-000DtK-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 06:18:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UTE2-00010Y-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 14:18:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081308.JAA12968@astro.cs.utk.edu> From: Keith Moore To: Masataka Ohta cc: "David R. Conrad" , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 17:30:20 +0859." <200108080830.RAA02821@necom830.hpcl.titech.ac.jp> Date: Wed, 08 Aug 2001 09:08:37 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The only thing to do is to have an RFC for the organization to tell > renumbering with A6 is as easy as with NAT. only thing is, it's not as easy with A6 as it is with NAT. if you use NATs to renumber, when you change prefixes the only thing you change is the NAT. the NAT does translation of addresses within external DNS queries and responses for you. all of your internal routers, firewalls, hosts, applications, etc. stay the same. if you renumber using IPv6, all of that state in routers, firewalls, hosts, applications, etc has to change somehow, and it has to change with minimal disruption of service. A6 only addresses one part of that. renumbering is a hard problem. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 09:39:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12379 for ; Wed, 8 Aug 2001 09:39:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UTFw-000Dvz-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 06:20:16 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UTFv-000Dvt-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 06:20:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UTFu-00010w-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 14:20:14 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: alh-ietf@tndh.net cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: "Tony Hain"'s message of "Wed, 08 Aug 2001 12:56:27 +0100." References: Date: Wed, 08 Aug 2001 20:14:50 +0700 Message-ID: <4260.997276490@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit alh-ietf@tndh.net said: | Or accept the reality that enforcing PA as the 'only' approach is in | direct conflict with the ultimate goals of the consumer. The ultimate goals of the consumer are surely to have a stable internet connection that works, and allows all available services. Or for many perhaps at an even higher level, to make lots of money however it can be made, and care about very little else. Very few ultimate consumers care at all about renumbering, except to the extent that it interferes with one of the above real goals. They care even less about the format of DNS resource records of course. If renumbering is forced, and that causes problems, and NAT seems to allow those problems to be avoided, then NAT is what people will do. Once NAT is seen as an inappropriate solution (which it will be once people start wanting most of their systems to be available as servers, not just clients, for at least some protocols) then they'll look to find something else that works. Geographic based addresses, with their likely increased costs might be the solution. Of course, if we can keep on working and get renumbering to work so easily and cleanly that it ceases to be any kind of real cost, then perhaps enforcing PA won't be seen as being in direct conflict with anything any more - as no-one (at the ultimate consumer level) will even notice it happening. That's what we should be working towards, what's more, it should be an attainable target - there's nothing so complex about configuring an IP address that it needs to be seen as some kind of black art, to be done once and never repeated. The only real problems are that with IPv4 we allowed the IP addresses to be configured everywhere, we assumed they were a fixture (more permanent that even a domain name, as they have essentially no vanity value) - and that has made the update process absurdly difficult. We just need to make sure that everyone is aware that the only places an IPv6 address should ever be written are in the DNS zone files and in router configs for networks (and there, in a form that router renumbering can update). Anywhere else you're ever tempted to enter an IPv6 address we need to find an alternative. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 10:15:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13137 for ; Wed, 8 Aug 2001 10:15:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UTuw-000FO9-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 07:02:38 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UTuv-000FO3-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 07:02:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UTuv-0001A0-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 15:02:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Tony Hain" To: "Robert Elz" Cc: , , , Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Wed, 8 Aug 2001 14:53:20 +0100 Message-ID: In-Reply-To: <4260.997276490@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: I have no arguments with your comments other than: > The only real problems are that with IPv4 we > allowed the IP addresses to be configured everywhere ... If *configuration* were the 'only' problem it might be possible to fix renumbering. The fact that applications expect they need to know about the addresses in use will compound the problem such that it will be very difficult if not impossible to make renumbering completely transparent. I have no doubt we can find a way to completely automate renumbering, but I seriously doubt that we can 'fix' all of the application developers, and their=20 products. Given this state, the end user will be exposed to=20 renumbering events. We either accept this and find a way to=20 scale routing without renumbering, or accept that NAT will=20 persist. Tony=20 =20 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 10:15:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13148 for ; Wed, 8 Aug 2001 10:15:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UTvE-000FOM-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 07:02:56 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UTvD-000FOF-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 07:02:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UTvC-0001A3-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 15:02:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Rob Austein Cc: namedroppers Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <4260.997276490@brandenburg.cs.mu.OZ.AU> <20010808135037.63BE11AED@thrintun.hactrn.net> Message-Id: Date: Wed, 08 Aug 2001 14:54:30 +0100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > you just sent out a message that i'm pretty sure originated with kre > but it showed up under your name. oops.... new approval macro. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 11:17:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14735 for ; Wed, 8 Aug 2001 11:17:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UUvh-000Hjl-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 08:07:29 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UUvg-000HjO-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 08:07:28 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UUvf-0001Ft-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 16:07:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081501.LAA13833@astro.cs.utk.edu> From: Keith Moore To: Masataka Ohta cc: Tony Hain , Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 23:30:43 +0859." <200108081430.XAA04529@necom830.hpcl.titech.ac.jp> Date: Wed, 08 Aug 2001 11:01:07 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > With end-to-end multihoming, it is possible that application/transport > program periodically check DNS to be smoothly renumbered. that's insane. you've just decreased the reliability of applications by at least two nines. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 11:17:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14757 for ; Wed, 8 Aug 2001 11:17:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UUsv-000HZh-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 08:04:37 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UUsu-000HZD-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 08:04:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UUst-0001Fc-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 16:04:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200108081413.XAA04324@necom830.hpcl.titech.ac.jp> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081308.JAA12968@astro.cs.utk.edu> from Keith Moore at "Aug 8, 2001 09:08:37 am" To: Keith Moore Date: Wed, 8 Aug 2001 23:13:27 +0859 () CC: "David R. Conrad" , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith; > > The only thing to do is to have an RFC for the organization to tell > > renumbering with A6 is as easy as with NAT. > > only thing is, it's not as easy with A6 as it is with NAT. It is. > if you use NATs to renumber, when you change prefixes the only thing > you change is the NAT. the NAT does translation of addresses within > external DNS queries and responses for you. all of your internal > routers, firewalls, hosts, applications, etc. stay the same. It is stupid if internal routers, firewalls, hosts, applications, etc. do not rely on DNS and use raw addresses. DNS does translation of addresses for all of your internal routers, firewalls, hosts, applications. However, the problem is that router autoconfiguration is a bad thing to do if we use DNS, regardless of whether we use renumbering on ISP change or not. > A6 only addresses one part of that. So, we should have router configuration mechanism where routers (and firewalls) automatically accept upper 48 bit of addresses but nothing more. > renumbering is a hard problem. Except for DNS glue, renumbering is trivially easy. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 11:17:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14777 for ; Wed, 8 Aug 2001 11:17:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UUsH-000HVo-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 08:03:57 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UUsG-000HVi-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 08:03:56 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UUsF-0001FY-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 16:03:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200108081430.XAA04529@necom830.hpcl.titech.ac.jp> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: from Tony Hain at "Aug 8, 2001 02:53:20 pm" To: Tony Hain Date: Wed, 8 Aug 2001 23:30:43 +0859 () CC: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony; > > The only real problems are that with IPv4 we > > allowed the IP addresses to be configured everywhere ... > > If *configuration* were the 'only' problem it might be possible > to fix renumbering. The fact that applications expect they need > to know about the addresses in use will compound the problem > such that it will be very difficult if not impossible to make > renumbering completely transparent. Are you talking about ancient whois implementation? > I have no doubt we can find > a way to completely automate renumbering, but I seriously doubt > that we can 'fix' all of the application developers, and their=20 > products. Given this state, the end user will be exposed to > renumbering events. We either accept this and find a way to > scale routing without renumbering, or accept that NAT will > persist. Or, are you saying an NAT server can be detached from old ISP and attached to new ISP keeping the existing connections? Masataka Ohta PS With end-to-end multihoming, it is possible that application/transport program periodically check DNS to be smoothly renumbered. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 11:17:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14819 for ; Wed, 8 Aug 2001 11:17:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UUtL-000Hbk-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 08:05:03 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UUtK-000Hbe-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 08:05:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UUtK-0001Fg-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 16:05:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081308.JAA12968@astro.cs.utk.edu> References: <200108081308.JAA12968@astro.cs.utk.edu> Date: Wed, 08 Aug 2001 21:44:48 +0700 Message-ID: <4666.997281888@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 09:08:37 -0400 From: Keith Moore Message-ID: <200108081308.JAA12968@astro.cs.utk.edu> | if you use NATs to renumber, when you change prefixes the only thing | you change is the NAT. This is only true if you only consider your own work. When you change addresses though, lots of other people need to update their firewall configurations, etc. The recent message on the ipng list from Isaac Aldrin (and apologies if I inverted that name - the mail headers weren't clear...) shows that quite clearly - a major problem is notifying your peers of the new address and having them update their configurations. Of course, A6 doesn't solve that problem, though its use might make it a little simpler. That is, if have an A6 record that defines my network prefix, that I refer to from the A6 records for all my host names, etc, then I can tell my peer sites that they can use that same A6 record to configure their firewalls (and they can verify it using dnssec, etc). Then, when my addresses change, which I make known in the DNS by updating my prefix A6 record, your firewall should be able to automatically update itself. Assuming I'm sane (and the circumstances allow), I'll have two different prefixes for a while, both would be made known from the same prefix name in the DNS, your firewall would then allow both through during the transition - when the old address expires, your firewall will automatically stop allowing that old address in. I'd hate to think how many IPv4 firewalls exist that have IP addresses configured in them, where the owner (user) of the IPv4 address now is completely unrelated to the user at the time the firewall was configured. It's possible to achieve all this with AAAA as well, I could have an AAAA record that defines my prefix, but that would be used by nothing that I care about, so it would require real discipline to remember to keep that one updated. On the other hand, the A6 record would be referred to by most other A6 records in the zone file - that's one of the few that would need to be touched by a renumbering, so you can be fairly sure that updating it will never be forgotten. | if you renumber using IPv6, all of that state in routers, firewalls, | hosts, applications, etc has to change somehow, and it has to change | with minimal disruption of service. A6 only addresses one part of that. This is certainly true. I don't think anyone is claiming that A6 solves any problems of itself. What it does is remove a part of one impediment to getting a solution. That doesn't sound like much, and it probably isn't ... but I'd rather not have that impediment, than have to deal with it forever. | renumbering is a hard problem. That's certainly true too. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 11:27:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15007 for ; Wed, 8 Aug 2001 11:27:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UUvM-000Hj1-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 08:07:08 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UUvM-000Hiv-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 08:07:08 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UUvL-0001Fq-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 16:07:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081457.KAA13753@astro.cs.utk.edu> From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 21:44:48 +0700." <4666.997281888@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 10:57:32 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | if you renumber using IPv6, all of that state in routers, firewalls, > | hosts, applications, etc has to change somehow, and it has to change > | with minimal disruption of service. A6 only addresses one part of that. > > This is certainly true. I don't think anyone is claiming that A6 > solves any problems of itself. What it does is remove a part of one > impediment to getting a solution. That doesn't sound like much, and > it probably isn't ... but I'd rather not have that impediment, than > have to deal with it forever. agreed that we'd be better off without that impediment. but the A6 method of removing that impediment creates impediments of its own, and some folks believe it's not a good tradeoff. and it's hard to understand the value of A6 (to understand whether it is worth the cost) without having a good understanding of the total cost of renumbering. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 11:50:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15529 for ; Wed, 8 Aug 2001 11:50:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UVK5-000IzV-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 08:32:41 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UVK4-000IzP-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 08:32:40 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UVK3-0001HH-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 16:32:39 +0100 Message-Id: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> Date: Wed, 08 Aug 2001 11:13:52 -0400 To: Keith Moore From: Daniel Senie Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <200108081501.LAA13833@astro.cs.utk.edu> References: Mime-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:01 AM 8/8/01, Keith Moore wrote: > > With end-to-end multihoming, it is possible that application/transport > > program periodically check DNS to be smoothly renumbered. > >that's insane. you've just decreased the reliability of applications by >at least two nines. Not to mention melting the 'net under ever increasing DNS load, since we'd no longer be able to cache anything. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 11:52:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15618 for ; Wed, 8 Aug 2001 11:52:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UVNf-000J79-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 08:36:23 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UVNf-000J73-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 08:36:23 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UVNe-0001HO-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 16:36:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081501.LAA13833@astro.cs.utk.edu> References: <200108081501.LAA13833@astro.cs.utk.edu> Date: Wed, 08 Aug 2001 22:20:35 +0700 Message-ID: <4836.997284035@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 11:01:07 -0400 From: Keith Moore Message-ID: <200108081501.LAA13833@astro.cs.utk.edu> | that's insane. you've just decreased the reliability of applications by | at least two nines. That makes no sense at all. If an application goes and checks the DNS, and gets no answer back, or anything else to indicate that communications should fail, it can simply ignore that, and just keep on using the address it has. That is, until/unless that address stops working. On the other hand, if the DNS tells you that the entity you're connecting to has been renumbered, then if you were willing to trust the address the DNS gave you initially, you'd be foolish to ignore it now... Using the updated address just has to be better than simply having things fail because the old address is no longer available. Of course, there are truly dumb ways to use addresses that can be imagined (and are probably even used) where you see changing addresses from what is really load balancing or similar. Implemented sanely those cause no problems (you see all the addresses, as long as the one you're using is still there, carry on, even if it isn't the one you'd pick if you were starting again now). And even there, using A6 as the DNS mechanism allows much better heuristics, if you have an A6 record that says "this is my address, and it relies on this other A6 for its prefix", and later you get the same result, but the value of the prefix has changed, then you can be fairly sure that a renumbering has happened - as distinct from simply getting back a different address, which gives you no clue as to why the address is no longer the same (and you can't really just compare bits, because from afar, you have no idea what is prefix and what isn't). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 11:55:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15736 for ; Wed, 8 Aug 2001 11:55:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UVNv-000J9O-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 08:36:39 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UVNv-000J9I-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 08:36:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UVNu-0001HR-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 16:36:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 8 Aug 2001 11:23:14 -0400 From: Dan Massey To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-delegation-signer-01 Message-ID: <20010808112314.A10365@bb.nge.isi.edu> References: <200108081027.f78ARfH03649@birch.ripe.net> In-Reply-To: <200108081027.f78ARfH03649@birch.ripe.net>; from OKolkman@ripe.net on Wed, Aug 08, 2001 at 12:27:41PM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 08, 2001 at 12:27PM, Olaf Kolkman wrote: | | The problem is in: | | 'The child MUST sign its key set with at least one of the keys listed' | | In the case of key compromise the zone administrator of a child zone | might want to resign the zones with a completely new key even | before the parent has had a change to update their DS record. | | The 'MUST' in the line quoted above indicates that this operational | procedure is illegal. | But shouldn't this be illegal since it would cause the zone to black-hole itself? The isi.edu KEY is compromised and isi.edu wants to resign its zone with a new KEY. Suppose it does resign its zone with this new KEY before the DS record is updated at the parent. This is allowed under the above wording, but the isi.edu zone MUST not remove the compromised KEY and SIGs yet... If the isi.zone does removed the compromised KEY/SIGs before the parent has updated its DS, then isi.edu has just blackholed itself. Resolvers know that isi.edu is signed because of the (now outdated) DS record at the parent and the resolver expects signed data. The resolver will get signed data, but the data is signed using the new KEY. The resolver has no reason to trust this new key and should disregard the data. (otherwise, what stops an attacker from simply pretending there is a key compromise anytime its want to forge data for a secure zone?) I will be very happy if I'm missing something here... | | On the other hand it must be clear to a resolver that if the DS record | indicates a child zone is secure. The original sentence: | | ' Insecure delegation MUST NOT have a DS record, the presence of | DS record SHOULD be considered a hint that the child might be secure. | Resolver MUST only trust KEY records that match a DS record. ' | | will allow spoofing of unsecured child zone data. I think if the | resolver cannot validate the child zone's data using any of the keys | that the DS records are pointing to, the child zone MUST be | considered bad. | This sounds like what I'm saying above so doesn't that imply the original sentence was really what you wanted: 'The child MUST sign its key set with at least one of the keys listed' | I propose the following wording: | | DS records MUST only appear at secure delegations in the parent zone. | The records list the child's keys that SHOULD sign the child's key | set. Insecure delegation MUST NOT have a DS record. Secure delegations | MUST have at least one DS record. | The presence of one or more DS records MUST be considered an indication | that the child zone is secure. | | Resolvers that are not able to find or verify at least one of the | child's keys pointed to by the DS records, MUST consider the child zone | non-authentic. | Could you replace the second sentence with: The records list the child's keys and at least one of these keys MUST sign the child's key set. Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:13:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19604 for ; Wed, 8 Aug 2001 15:13:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYQX-0002mD-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 11:51:33 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYQX-0002lr-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 11:51:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYQX-0001LL-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 19:51:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Daniel Senie cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> References: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> Date: Wed, 08 Aug 2001 22:44:44 +0700 Message-ID: <4979.997285484@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 11:13:52 -0400 From: Daniel Senie Message-ID: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> | Not to mention melting the 'net under ever increasing DNS load, since we'd | no longer be able to cache anything. Huh??? No-one ever said anything about changing the definition or use of the TTL field in DNS replies. If you get a TTL that says an address is valid for a day, then you can keep using it for a day without checking again. Or you can check again every 5 minutes if you want to, but the answers will just keep coming back from your local cache, each with a TTL 5 minutes shorter than the previous time... kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:14:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19616 for ; Wed, 8 Aug 2001 15:13:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYTd-0002u4-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 11:54:45 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYTc-0002ty-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 11:54:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYTb-0001LY-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 19:54:43 +0100 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA5F@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , alh-ietf@tndh.net Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Wed, 8 Aug 2001 09:07:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C12024.4066E080" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C12024.4066E080 Content-Type: text/plain; charset="iso-8859-1" NAT is here and will stay irregardless of what the IETF might want. The principal benefit of NAT to many businesses is that it is a very effective means of cutting off approximately 80% of network security problems at a stroke. Less functionality is precisely what these users want. On the home user front the popularity of NAT is increasing as people discover that a $100 box from Frys allows them to plug four computers into the home network instead of one. Rather than demanding that the network change to match the protocols it is time to accept the fact that for the next twenty years at least NAT is going to be a part of the infrastructure and look for ways in which that mode of use can be supported without denying the end user a substantial degree of functionality. Since the only part of a TCP/IP session that needs the external address is the initial setup, why not design protocols that allow that part to be delegated to a third party 'connection server'? After all any personal presence type protocol will need some form of static server since the user will hop between devices even if the devices themselves had static addresses. The trick would be to find some way to get the NAT boxes to cooperate. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, August 08, 2001 9:15 AM > To: alh-ietf@tndh.net > Cc: ngtrans@sunroof.eng.sun.com; namedroppers@ops.ietf.org; > ipng@sunroof.eng.sun.com; dnsop@cafax.se > Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary > > > alh-ietf@tndh.net said: > | Or accept the reality that enforcing PA as the 'only' > approach is in > | direct conflict with the ultimate goals of the consumer. > > The ultimate goals of the consumer are surely to have a > stable internet > connection that works, and allows all available services. > > Or for many perhaps at an even higher level, to make lots of > money however > it can be made, and care about very little else. > > Very few ultimate consumers care at all about renumbering, > except to the > extent that it interferes with one of the above real goals. > They care > even less about the format of DNS resource records of course. > > If renumbering is forced, and that causes problems, and NAT > seems to allow > those problems to be avoided, then NAT is what people will > do. Once NAT > is seen as an inappropriate solution (which it will be once > people start > wanting most of their systems to be available as servers, not > just clients, > for at least some protocols) then they'll look to find > something else that > works. Geographic based addresses, with their likely > increased costs might > be the solution. > > Of course, if we can keep on working and get renumbering to > work so easily > and cleanly that it ceases to be any kind of real cost, then perhaps > enforcing PA won't be seen as being in direct conflict with > anything any > more - as no-one (at the ultimate consumer level) will even notice it > happening. > > That's what we should be working towards, what's more, it should be an > attainable target - there's nothing so complex about configuring an IP > address that it needs to be seen as some kind of black art, to be done > once and never repeated. The only real problems are that with IPv4 we > allowed the IP addresses to be configured everywhere, we assumed they > were a fixture (more permanent that even a domain name, as they have > essentially no vanity value) - and that has made the update process > absurdly difficult. We just need to make sure that everyone is aware > that the only places an IPv6 address should ever be written are in the > DNS zone files and in router configs for networks (and there, > in a form > that router renumbering can update). Anywhere else you're > ever tempted > to enter an IPv6 address we need to find an alternative. > > kre > > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > ------_=_NextPart_000_01C12024.4066E080 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C12024.4066E080-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:14:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19638 for ; Wed, 8 Aug 2001 15:14:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYTz-0002uW-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 11:55:07 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYTy-0002uQ-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 11:55:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYTy-0001Lc-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 19:55:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> Date: Wed, 08 Aug 2001 12:12:15 -0400 To: Robert Elz From: Daniel Senie Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <4979.997285484@brandenburg.cs.mu.OZ.AU> References: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:44 AM 8/8/01, Robert Elz wrote: > Date: Wed, 08 Aug 2001 11:13:52 -0400 > From: Daniel Senie > Message-ID: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> > > | Not to mention melting the 'net under ever increasing DNS load, since > we'd > | no longer be able to cache anything. > >Huh??? > >No-one ever said anything about changing the definition or use of the >TTL field in DNS replies. If you get a TTL that says an address is >valid for a day, then you can keep using it for a day without checking >again. Or you can check again every 5 minutes if you want to, but >the answers will just keep coming back from your local cache, each with >a TTL 5 minutes shorter than the previous time... Reread what Keith wrote. If applications are going to use DNS to check for changes in addressing, how is caching going to help? You're suggesting the local caches just answer the every-5-minute lookups, but that's useless if the DNS lookups are used as a part of multihoming. I interpreted the periodic lookup as being a way for applications to find out that a remote machine has migrated to a new address. If local caches mask that migration, how's that help? Multihoming has to involve resiliancy. If the addresses are cached for a day, saying "oh, your application will start working again tomorrow" is unlikely to cut it. So, I guess the question back to the original point was, what information is going to be IN those lookups that happen every 5 minutes? If that information needs to change on a minute by minute basis (or a 5 minute by 5 minute basis) then caching is not going to help. So, the question is, to use this effectively, do zones have to be set up with their TTL set to 60 seconds? ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:18:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19697 for ; Wed, 8 Aug 2001 15:18:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYW8-00032N-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 11:57:20 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYW7-00032G-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 11:57:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYW7-0001Ln-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 19:57:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081635.MAA14428@astro.cs.utk.edu> From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 22:20:35 +0700." <4836.997284035@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 12:35:52 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | that's insane. you've just decreased the reliability of applications by > | at least two nines. > > That makes no sense at all. > > If an application goes and checks the DNS, and gets no answer back, or > anything else to indicate that communications should fail, it can simply > ignore that, and just keep on using the address it has. That is, > until/unless that address stops working. but if the application starts using a new address, and that address doesn't reach the same peer (same socket on the same host) as before, then switching to the new address causes premature failure. the application is always better off continuing to use the old address, attempting to switch addresses only to recover from apparently broken connections. even then, the application has to guess as to whether it's more likely that the connection will begin working again or whether the old address is now permanently invalid. furthermore, it's always been the case that you could get multiple addresses in response to a name lookup, and there's no license to assume that those addresses are interchangable for open connections. in that case, which address does an application choose? > On the other hand, if the DNS tells you that the entity you're connecting > to has been renumbered, then if you were willing to trust the address the > DNS gave you initially, you'd be foolish to ignore it now... and you'd be foolish to switch while the old address is still working, for reasons cited above. > Of course, there are truly dumb ways to use addresses that can be > imagined (and are probably even used) where you see changing addresses > from what is really load balancing or similar. Implemented sanely those > cause no problems (you see all the addresses, as long as the one you're > using is still there, carry on, even if it isn't the one you'd pick > if you were starting again now). but this doesn't facilitate renumbering. > And even there, using A6 as the DNS mechanism allows much better > heuristics, if you have an A6 record that says "this is my address, and > it relies on this other A6 for its prefix", and later you get the same > result, but the value of the prefix has changed, then you can be fairly > sure that a renumbering has happened no you can't. just because DNS thinks that a new prefix exists for an address is no indication that the application on the other end can deal with your using the new prefix. it's hard enough to keep MX records in sync with SMTP servers, and that's something that should be explicitly managed. asking applications to keep track of changes in DNS doesn't strike me as an effective way to do renumbering. we need an interrupt mechanism, not a polling one, and we need something that works at the IP level, not using an application that is layered on top of IP. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:19:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19716 for ; Wed, 8 Aug 2001 15:19:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYXz-00038r-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 11:59:15 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYXy-00038l-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 11:59:14 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYXy-0001M5-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 19:59:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081651.MAA14676@astro.cs.utk.edu> From: Keith Moore To: Robert Elz cc: Daniel Senie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 22:44:44 +0700." <4979.997285484@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 12:51:23 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > No-one ever said anything about changing the definition or use of the > TTL field in DNS replies. this is a common source of confusion. the TTL field in DNS refers to the binding between the DNS name and the address. it has nothing whatsoever to do with the lifetime of the binding between the address and any hosts/sockets/processes that might be attached to it. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:20:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19738 for ; Wed, 8 Aug 2001 15:20:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYVh-000320-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 11:56:53 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYVg-00031u-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 11:56:52 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYVg-0001Lj-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 19:56:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Daniel Senie cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> References: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> Date: Wed, 08 Aug 2001 23:35:12 +0700 Message-ID: <5162.997288512@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 12:12:15 -0400 From: Daniel Senie Message-ID: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> | Reread what Keith wrote. It was actually what Keith quoted that Otha-san wrote, not that that really matters. | If applications are going to use DNS to check for | changes in addressing, how is caching going to help? It isn't going to help, but it isn't going to be eliminated either. | You're suggesting the | local caches just answer the every-5-minute lookups, but that's useless if | the DNS lookups are used as a part of multihoming. I'm not sure of the relevance of multihoming - it was renumbering we were discussing, but never mind. | I interpreted the | periodic lookup as being a way for applications to find out that a remote | machine has migrated to a new address. Yes. | If local caches mask that migration, how's that help? It is giving the answer (as authorised by the owner of the data). Consider what happens now, and forget about long lived applications periodically polling - instead consider a series of short lived applications (like web page accesses, which do a DNS lookup for every URL usually). Given that caches answer now for those queries, for as long as the TTL allows, do you really see any difference at all? | Multihoming has to involve resiliancy. If the addresses are cached for a | day, saying "oh, your application will start working again tomorrow" is | unlikely to cut it. No. But that's never been the idea. | So, I guess the question back to the original point was, what information | is going to be IN those lookups that happen every 5 minutes? Nothing, which is why a sane app wouldn't do that, only when the TTL it originally received (assuming it is using an API that reveals the TTL of course) has expired. On the other hnd, other than increased traffic at the local DNS cache, checking the address more frequently doesn't hurt either. | If that | information needs to change on a minute by minute basis (or a 5 minute by 5 | minute basis) then caching is not going to help. No. Somehow I think you're missing the context of this whole discussion though. | So, the question is, to | use this effectively, do zones have to be set up with their TTL set to 60 | seconds? No, bit when you set a TTL on a record in the DNS, that's a promise that the data isn't going to change from the time someone fetches the record until the TTL has expired. No-one is planning on altering that. That is, that's true today, and will remain true tomorrow (you can cache this answer for at least 6 months...) The effect is that you need to handle TTLs and address changes together. The old address needs to remain valid while any RRs that were handed out are still alive. That's the DNS, and will remain. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:21:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19753 for ; Wed, 8 Aug 2001 15:21:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYcY-0003RE-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:03:58 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYcY-0003R7-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:03:58 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYcY-0001Mf-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:03:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200108081722.CAA06350@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA06350; Thu, 9 Aug 2001 02:22:40 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081651.MAA14676@astro.cs.utk.edu> from Keith Moore at "Aug 8, 2001 12:51:23 pm" To: Keith Moore Date: Thu, 9 Aug 2001 02:22:39 +0859 () CC: Robert Elz , Daniel Senie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith; > > No-one ever said anything about changing the definition or use of the > > TTL field in DNS replies. > > this is a common source of confusion. > > the TTL field in DNS refers to the binding between the DNS name and > the address. it has nothing whatsoever to do with the lifetime > of the binding between the address and any hosts/sockets/processes > that might be attached to it. What you don't understand is that, today, most users/applications use DNS name for identification. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:22:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19778 for ; Wed, 8 Aug 2001 15:22:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYbv-0003NL-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:03:19 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYbu-0003NE-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:03:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYbt-0001MZ-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:03:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081725.NAA14897@astro.cs.utk.edu> From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Thu, 09 Aug 2001 00:17:09 +0700." <5403.997291029@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 13:25:59 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | it's even more realistic to say that TTL indicates the amount of time > | for which the DNS administrator is willing to accept that the services > | associated with the DNS name will be effectively unavailable, should > | he/she need to change the addresses. > > That's not an unfair description of what often happens, mostly through > ignorance of how things should be done though. sometimes ignorance, and sometimes a realistic assessment (based on knowledge of the users and applications affected) of the harm that will be done. > Fortunately, with v6 > (whatever DNS RR format is chosen) having multiple addresses assigned to > an interface is designed as a normal case, rather than an unusual one. the stacks are designed to deal with this, yes. whether ISPs and network administrators and firewalls and applications will also deal with this is a separate question. even so, renumbering for the purpose of new connections is a lot easier than renumbering established connections. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:22:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19791 for ; Wed, 8 Aug 2001 15:22:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYYG-00039i-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 11:59:32 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYYF-00039M-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 11:59:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYYF-0001M8-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 19:59:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081635.MAA14428@astro.cs.utk.edu> References: <200108081635.MAA14428@astro.cs.utk.edu> Date: Wed, 08 Aug 2001 23:54:30 +0700 Message-ID: <5264.997289670@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 12:35:52 -0400 From: Keith Moore Message-ID: <200108081635.MAA14428@astro.cs.utk.edu> | the application is always | better off continuing to use the old address, attempting to switch | addresses only to recover from apparently broken connections. Yes, probably, but you still need to discover the changed address. | furthermore, it's always been the case that you could get multiple addresses | in response to a name lookup, and there's no license to assume that those | addresses are interchangable for open connections. in that case, which | address does an application choose? Does it matter? If the connection is going to be broken anyway, because the old address is no longer valid, then you either pick a new one that works (and in many, probably even most, cases, any would do), or it fails and things are no more broken than they were before. The app could even try all the possible new addresses (assuming there are more than one) if it likes. | no you can't. just because DNS thinks that a new prefix exists for an | address is no indication that the application on the other end can | deal with your using the new prefix. No, it isn't. But if the DNS tells you that the old address is no longer valid, that is an indication that you're going to have to do something, sometime pretty soon. | to do renumbering. we need an interrupt mechanism, not a polling one, | and we need something that works at the IP level, not using an application | that is layered on top of IP. Unfortunately, not possible. IP is stateless, it has no idea who its peers are, to send some kind of "I just renumbered" indication (or I am about to renumber - same problem). TCP could handle that, but not everything uses TCP (UDP has the same problem as IP). Apps that need to deal with this (and that's really only those few that have long lived connections that need to be able to continue through events like renumbering ... that is, forget about HTTP, SMTP, probably FTP as well) are going to have to deal with this at the application level. That either means adding stuff to all the protocols ("I'm moving now...") or having the apps find some other way to discover that a peer has renumbered. Or outlaw renumbering, and somehow route flat /48's (or find some other addressing method that both aggregates nicely, and avoids needing renumbering). Or simply accept that some applications will necessarily fail when renumbering happens (and NAT can't fix it). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:22:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19802 for ; Wed, 8 Aug 2001 15:22:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYYn-0003CW-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:00:05 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYYn-0003CQ-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:00:05 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYYn-0001MB-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:00:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081656.MAA14715@astro.cs.utk.edu> From: Keith Moore To: Robert Elz cc: Daniel Senie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 23:35:12 +0700." <5162.997288512@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 12:56:41 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | So, the question is, to > | use this effectively, do zones have to be set up with their TTL set to 60 > | seconds? > > No, bit when you set a TTL on a record in the DNS, that's a promise that > the data isn't going to change from the time someone fetches the record > until the TTL has expired. actually, it's not. if that were the case, we could never change a name-to-address binding without first setting TTL to zero (or providing a mechanism that allows them to diminish to zero) and waiting for older TTLs to expire. it's somewhat more realistic to say that a TTL indicates (for an address record) that any services referred to by the DNS name will continue to be available at that IP address until the TTL expires, if they're available at all. it's even more realistic to say that TTL indicates the amount of time for which the DNS administrator is willing to accept that the services associated with the DNS name will be effectively unavailable, should he/she need to change the addresses. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:22:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19814 for ; Wed, 8 Aug 2001 15:22:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYaY-0003Iw-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:01:54 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYaX-0003Iq-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:01:54 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYaX-0001MN-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:01:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081709.NAA14777@astro.cs.utk.edu> From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 23:54:30 +0700." <5264.997289670@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 13:09:38 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | no you can't. just because DNS thinks that a new prefix exists for an > | address is no indication that the application on the other end can > | deal with your using the new prefix. > > No, it isn't. But if the DNS tells you that the old address is no > longer valid, that is an indication that you're going to have to do > something, sometime pretty soon. DNS cannot tell you that old addresses are no longer valid, it can only tell you that some addresses should be valid. The absence of some address in a list of A (or AAAA or A6) records is not an indication that the address is not valid. > | to do renumbering. we need an interrupt mechanism, not a polling one, > | and we need something that works at the IP level, not using an application > | that is layered on top of IP. > > Unfortunately, not possible. IP is stateless, it has no idea who its > peers are, to send some kind of "I just renumbered" indication (or I am > about to renumber - same problem). TCP could handle that, but not > everything uses TCP (UDP has the same problem as IP). any system for renumbering (including the one you are proposing) will require changes to existing protocols. the question is, where is the best place to make these changes? my guess is, some combination of ND/RD and ICMP. but they're not going to be simple changes (well, not if we expect them to work well) because right now we don't even have the concept of a host or stack identifier in the architecture. (with the possible exception of the last 64 bits of a v6 address, and even then, not in all cases) > Apps that need to deal with this (and that's really only those few that > have long lived connections that need to be able to continue through events > like renumbering ... that is, forget about HTTP, SMTP, probably FTP as well) which apps are affected depends on the frequency of renumbering and the overlap during which multiple addresses are valid. and yes, if we can make these periods large enough (and the number of apps affected few enough) we can shift the burden of recovery to those apps. we really need for these to be explicitly chosen design parameters. my feeling is that the mean time between renumbering should be no worse than the mean time between shutdown of reasonable hosts for other reasons, which is to say, several months. that way, renumbering doesn't significantly affect application reliability. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:23:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19827 for ; Wed, 8 Aug 2001 15:23:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYcP-0003Qn-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:03:49 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYcO-0003Qf-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:03:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYcO-0001Mc-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:03:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200108081718.CAA06297@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA06297; Thu, 9 Aug 2001 02:18:30 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> from Daniel Senie at "Aug 8, 2001 12:12:15 pm" To: Daniel Senie Date: Thu, 9 Aug 2001 02:18:28 +0859 () CC: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Daniel; > > | Not to mention melting the 'net under ever increasing DNS load, since > > we'd > > | no longer be able to cache anything. > > > >Huh??? > > > >No-one ever said anything about changing the definition or use of the > >TTL field in DNS replies. If you get a TTL that says an address is > >valid for a day, then you can keep using it for a day without checking > >again. Or you can check again every 5 minutes if you want to, but > >the answers will just keep coming back from your local cache, each with > >a TTL 5 minutes shorter than the previous time... > > Reread what Keith wrote. that he is crazy? > If applications are going to use DNS to check for > changes in addressing, how is caching going to help? Caching helps because applications won't check DNS again until TTL expires and even if it does cache will supress actual query. Caching helps other applications share the result of query. > You're suggesting the > local caches just answer the every-5-minute lookups, but that's useless if > the DNS lookups are used as a part of multihoming. I interpreted the > periodic lookup as being a way for applications to find out that a remote > machine has migrated to a new address. If local caches mask that migration, > how's that help? You are merely saying that DNS TTL should not be unnecessarily small. DNS semantics is that if TTL expires applications still relying on the answer should query again. BTW, it is also possible to modify applications to carry information that addresses change occurred and a list of new addresses. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:24:00 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19838 for ; Wed, 8 Aug 2001 15:23:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYb8-0003Js-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:02:30 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYb8-0003Jl-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:02:30 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYb8-0001MU-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:02:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081718.f78HILH85940@as.vix.com> To: Daniel Senie cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: Message from Daniel Senie of "Wed, 08 Aug 2001 11:13:52 EDT." <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> Date: Wed, 08 Aug 2001 10:18:21 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Not to mention melting the 'net under ever increasing DNS load, since we'd > no longer be able to cache anything. that's a hyberbolic comment if ever i've heard one. there would still be caching. TTL's would be the same as they are now, which means they'd have to be reduced one TTL in advance of a renumbering event. btw, i'm seeing a moderate amount (hundreds of packets per second to a /23) of icmp from all of the companies (some white hat, some black hat) probing my network for security problems. traffic in and of itself is not a worry, is it? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:25:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19862 for ; Wed, 8 Aug 2001 15:25:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYap-0003JJ-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:02:11 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYao-0003JC-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:02:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYao-0001MQ-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:02:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081656.MAA14715@astro.cs.utk.edu> References: <200108081656.MAA14715@astro.cs.utk.edu> Date: Thu, 09 Aug 2001 00:17:09 +0700 Message-ID: <5403.997291029@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 12:56:41 -0400 From: Keith Moore Message-ID: <200108081656.MAA14715@astro.cs.utk.edu> | actually, it's not. if that were the case, we could never change | a name-to-address binding without first setting TTL to zero (or | providing a mechanism that allows them to diminish to zero) | and waiting for older TTLs to expire. That's the way it should be done, yes. And it is the way that people who really care about keeping things working make changes where that is needed, but ... | it's somewhat more realistic to say that a TTL indicates (for an address | record) that any services referred to by the DNS name will continue to be | available at that IP address until the TTL expires, if they're available | at all. that's fine too. When I reread my words I see that I didn't really say the right thing, what I should have said, rather than "that the data isn't going to change" is "that the data is going to remain valid" and as long as you can keep reaching the address that you were given, that's OK, even if some other application, doing a new query (and not hitting the cache for whatever reason) would get a different answer. (and if I were a pedantic nerd, I'd make that "data are going to remain valid", or better, since a TTL applies to an RR "datum is going to remain valid", but I won't do either of those...) However... | it's even more realistic to say that TTL indicates the amount of time | for which the DNS administrator is willing to accept that the services | associated with the DNS name will be effectively unavailable, should | he/she need to change the addresses. That's not an unfair description of what often happens, mostly through ignorance of how things should be done though. Fortunately, with v6 (whatever DNS RR format is chosen) having multiple addresses assigned to an interface is designed as a normal case, rather than an unusual one. There should rarely be a need to make an old address go away before its old DNS data has had a chance to naturally expire, so the IPv4 style of "old address out, new address in" as a indivisible operation should gradually fade away, as the new methodology becomes familiar. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:30:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19936 for ; Wed, 8 Aug 2001 15:30:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYfO-0003b2-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:06:54 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYfN-0003aw-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:06:53 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYfN-0001Mu-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:06:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081709.NAA14777@astro.cs.utk.edu> References: <200108081709.NAA14777@astro.cs.utk.edu> Date: Thu, 09 Aug 2001 00:56:50 +0700 Message-ID: <5600.997293410@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 13:09:38 -0400 From: Keith Moore Message-ID: <200108081709.NAA14777@astro.cs.utk.edu> | DNS cannot tell you that old addresses are no longer valid, it can only | tell you that some addresses should be valid. The absence of some address | in a list of A (or AAAA or A6) records is not an indication that the | address is not valid. I'm not sure I agree with that. The RRset should be the complete list of addresses that belong to a name (which isn't necessarily the complete set that belong to the node that owns the name of course). If an address isn't in the RRset, then it doesn't belong to the name, by definition, and hence, is invalid as a translation of the name. Whether that address still happens to reach the entity that it reached yesterday, when it was a valid translation of the name is a different question. | any system for renumbering (including the one you are proposing) | will require changes to existing protocols. the question is, | where is the best place to make these changes? my guess is, | some combination of ND/RD and ICMP. I'm not sure it is possible. Sure, a node could respond with some kind of message to a peer that sends a packet to an address that the node is in the process of deprecating - but that doesn't help at all for all the other peers that don't happen to send any traffic during the deprecation period. | which apps are affected depends on the frequency of renumbering and the | overlap during which multiple addresses are valid. The overlap period, yes, the frequency, no, not really. I can renumber 7 times in a day, and as long as the first (and rest) of those addresses remain valid long enough, then all is OK. | we really need for these to be explicitly chosen design parameters. That means then the overlap period. Unfortunately, I suspect that's not possible. | my feeling is that the mean time between renumbering should be no worse | than the mean time between shutdown of reasonable hosts for other reasons, | which is to say, several months. that way, renumbering doesn't | significantly affect application reliability. And unfortunately you're trying to equate two measures that are likely moving in opposite directions. Hosts (and OS's) are becoming more stable, and remaining running between shutdowns far longer than used to be possible (I recall the days when computers were turned off each night when people went home...) And renumbering is likely to become more necessary, hence more frequent, as the net gets bigger, and the routing problems get worse (assuming no revolutionary solution of course). But in any case, it isn't host uptime that counts, but application connection time - what you would like is for addresses to remain valid (after ceasing to be preferred) for at least as long as the average app connection is likely to remain. It would be nice to aim for that where possible, but circumstances being what they are, mandating it would just make us look foolish. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:35:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20028 for ; Wed, 8 Aug 2001 15:35:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYi0-0003nu-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:09:36 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYhz-0003nP-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:09:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYhz-0001NQ-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:09:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081854.OAA15722@astro.cs.utk.edu> From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Thu, 09 Aug 2001 00:56:50 +0700." <5600.997293410@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 14:54:32 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | DNS cannot tell you that old addresses are no longer valid, it can only > | tell you that some addresses should be valid. The absence of some address > | in a list of A (or AAAA or A6) records is not an indication that the > | address is not valid. > > I'm not sure I agree with that. The RRset should be the complete > list of addresses that belong to a name (which isn't necessarily the > complete set that belong to the node that owns the name of course). why? nothing in the standards requires that all IP addresses be listed, and most applications are quite capable of using IP addresses as names for services. there's also no reason that you couldn't use a completely different mechanism than DNS to determine the IP address associated with a service. (we will certainly need to do this someday, as DNS cannot last forever) > If an address isn't in the RRset, then it doesn't belong to the name, > by definition, and hence, is invalid as a translation of the name. perhaps, but it might still be a valid address for the service that the user wants. > | any system for renumbering (including the one you are proposing) > | will require changes to existing protocols. the question is, > | where is the best place to make these changes? my guess is, > | some combination of ND/RD and ICMP. > > I'm not sure it is possible. Sure, a node could respond with some > kind of message to a peer that sends a packet to an address that the > node is in the process of deprecating - but that doesn't help at all > for all the other peers that don't happen to send any traffic during > the deprecation period. if hosts are notified when their address prefixes change, that notification can be forwarded to any connections (TCP or otherwise) that the host knows about. similarly, if those hosts can notify resident applications that the addresses prefixes have changed, those applications can at least potentially notify their peers. this doesn't solve the problem entirely, since more than one host in a conversation could be concurrently changing addresses. but since only the hosts and applications know who their communications peers are, that's where you have to start. > | which apps are affected depends on the frequency of renumbering and the > | overlap during which multiple addresses are valid. > > The overlap period, yes, the frequency, no, not really. I can renumber > 7 times in a day, and as long as the first (and rest) of those addresses > remain valid long enough, then all is OK. probably so. but there is also probably a practical limit to the number of address prefixes that should be used at any one time. > | we really need for these to be explicitly chosen design parameters. > > That means then the overlap period. > > Unfortunately, I suspect that's not possible. well, we appear to have some people assuming that renumberings will be so infrequent that we can disregard them, and others assuming that renumberings will be so frequent that protocols have to deal with them explicitly. that's no way to do engineering. for applications to make use of IPv6 there needs to be some reasonable bounds on tbe behavior of the network. > | my feeling is that the mean time between renumbering should be no worse > | than the mean time between shutdown of reasonable hosts for other reasons, > | which is to say, several months. that way, renumbering doesn't > | significantly affect application reliability. > > And unfortunately you're trying to equate two measures that are likely > moving in opposite directions. Hosts (and OS's) are becoming more > stable, and remaining running between shutdowns far longer than used to > be possible (I recall the days when computers were turned off each night > when people went home...) > > And renumbering is likely to become more necessary, hence more frequent, > as the net gets bigger, and the routing problems get worse (assuming no > revolutionary solution of course). I concur. > But in any case, it isn't host uptime that counts, but application connection > time - what you would like is for addresses to remain valid (after ceasing to > be preferred) for at least as long as the average app connection is likely > to remain. I don't think that's the right criterion - first of all, that would have 50% of all connections being broken; second, it's based on assumptions about the nature of traffic, which will vary widely over time. I'd rather say that we have expectations about how the network behaves - just as (say) end-to-end packet loss should be no worse than 20%, address bindings should be good for at least several days. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 15:40:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20111 for ; Wed, 8 Aug 2001 15:40:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UYml-00047C-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:14:31 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UYml-00046q-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:14:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UYmk-0001O0-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:14:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081910.PAA15947@astro.cs.utk.edu> From: Keith Moore To: "David R. Conrad" cc: Masataka Ohta , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 11:10:50 PDT." <5.0.2.1.2.20010808093637.02ff22f8@localhost> Date: Wed, 08 Aug 2001 15:10:55 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Sorta reminds me of the IDN situation. Instead of focusing on the real > problem (getting higher layers to do the right thing), the focus is on > fixing the DNS... we might disagree that higher layers are the best place to fix the problem or that the fix exclusively belongs there. but it should be clear that we cannot do a good job of fixing this with DNS alone. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 16:06:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20368 for ; Wed, 8 Aug 2001 16:06:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UZOs-0006ai-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:53:54 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UZOs-0006aa-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:53:54 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UZOq-0001Pf-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:53:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 8 Aug 2001 21:26:17 +0200 (MEST) From: Jakob Schlyter To: Dan Massey Cc: Subject: Re: draft-ietf-dnsext-delegation-signer-01 In-Reply-To: <20010808112314.A10365@bb.nge.isi.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 8 Aug 2001, Dan Massey wrote: > The isi.edu KEY is compromised and isi.edu wants to resign its zone > with a new KEY. Suppose it does resign its zone with this new KEY > before the DS record is updated at the parent. This is allowed > under the above wording, but the isi.edu zone MUST not remove the > compromised KEY and SIGs yet... if my key is compromised, why should someone - by specification - prevent me from removing it from my zone if I like to? it may be stupid, but it is really my call. I'm not saying I would do that (I would probably wait for my parent zone to put in the new key first), but some people may choose to actually break their zone rather than have someone spoof it. jakob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 16:07:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20384 for ; Wed, 8 Aug 2001 16:07:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UZRB-0006n0-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:56:17 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UZRA-0006lj-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:56:16 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UZR4-0001Ps-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:56:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108081947.PAA16310@astro.cs.utk.edu> From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Thu, 09 Aug 2001 02:28:57 +0700." <6017.997298937@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 15:47:22 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Date: Wed, 08 Aug 2001 14:54:32 -0400 > From: Keith Moore > Message-ID: <200108081854.OAA15722@astro.cs.utk.edu> > > | why? nothing in the standards requires that all IP addresses be listed, > > Again, it depends upon exactly what you're measuring here. The DNS > defines the name, and if it has A (or AAAA or A6) RR's, then those define > the addresses that belong to that name. > > That someone might know of some other address that happens to reach > the same piece of hardware isn't really relevant - even if the other > address happens to work just as well. it's relevant to renumbering, because renumbering affects whether those addresses continue to work well - independently of what the DNS says. > | there's also no reason that you couldn't use a completely > | different mechanism than DNS to determine the IP address associated with > | a service. (we will certainly need to do this someday, as DNS cannot > | last forever) > > Perhaps. When that happens then we'll have two ways to define the > mapping between names and addresses not necessarily. the input to such a service doesn't have to be service names (they could for instance be queries for resources matching several criteria). even if the input were service names, those names don't have to be from the same space as DNS names. there are already several applications that work this way, because DNS doesn't suit their needs. > | if hosts are notified when their address prefixes change, that > | notification can be forwarded to any connections (TCP or otherwise) > | that the host knows about. > > Yes, at the TCP level, things are easy (well, could be, assuming > adequate protocol support, and "easy" is probably the wrong term > even then, "possible" would be better). Right, I'm just generalizing this to "any thing for which the host's OS maintains per-connection state". So (for example) it would also be true of UDP sockets for which a remote address were bound to the socket. > If the client just validates the name it was given whenever its address > has expired, then it can pick up on address changes, and use the new > address (the server doesn't care what address requests come to). as explained earlier, this doesn't work in general. you're overloading the DNS name to do something it wasn't designed to do. > Each protocol really needs to be investigated separately, what might > work, and what mightn't will vary enormously. Which is another reason > why attempting to fix it at the IP layer probably isn't the solution. no, you can't fix everything at the IP layer. but the notifications that address prefixes are being changed (or that old ones are invalid) should originate with the network, not with DNS. > | similarly, if those hosts can notify resident applications that the > | addresses prefixes have changed, those applications can at least > | potentially notify their peers. > > Only if the end that is renumbering has any idea who its peers are. > That isn't always the case. no, but at least this will provide a mechanisms by which applications can be aware of their peers. existing non-connection-based applications won't be able to survive renumbering, no matter what fix we come up with. > | this doesn't solve the problem entirely, since more than one host > | in a conversation could be concurrently changing addresses. > > yes, that part is the real hard one to handle - but if we can't get it > right without that case, worrying about that one is a waste of energy. true enough. the question is whether a solution that fails to address that case is adequate. (or, are we also wasting our energy if we fail to address that case?) > | well, we appear to have some people assuming that renumberings will be > | so infrequent that we can disregard them, and others assuming that > | renumberings will be so frequent that protocols have to deal with them > | explicitly. that's no way to do engineering. for applications to > | make use of IPv6 there needs to be some reasonable bounds on tbe > | behavior of the network. > > Yes. Unfortunately, the very disagreement that you mention means that > deciding what those bounds should be isn't going to be easy. Still, I think we'd be better off if we started trying to get consensus on a figure, than by trying to make progress without a shared understanding of the problem. We've made recommendations on other design parameters, like prefix length. > Personally, I'm also not sure I need to know - I want to make it possible > to renumber easily, which should make it possible to do frequently if needed, > and then hope I almost never have to actually do it... > > That is, I want to be able to deal with the worst case, but will hope that > the best case is what occurs. Right. But I want to know what the worst reasonable case is so that I can design my applications to deal with it. > | I'd rather say that we have expectations about how the network behaves - > | just as (say) end-to-end packet loss should be no worse than 20%, > > Hmm... if it gets to double figures I give up for the day... I wish the network to my home worked that well. > But I don't think we've ever had such a definition, what packet loss > is tolerable also depends heavily upon the applications. Right. But at some point you stop expecting anything to work. > | address bindings should be good for at least several days. > > Would be a nice target. Just as long as we don't actually assume that > we will be able to meet it. Again, I think we need to be able to make *some* assumptions. Just as TCP doesn't survive arbitrary amounts of packet lossage, neither do applications survive arbitrary amounts of renumbering. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 16:11:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20488 for ; Wed, 8 Aug 2001 16:11:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UZPL-0006bD-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 12:54:23 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UZPK-0006b6-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 12:54:22 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UZPI-0001Pj-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 20:54:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081854.OAA15722@astro.cs.utk.edu> References: <200108081854.OAA15722@astro.cs.utk.edu> Date: Thu, 09 Aug 2001 02:28:57 +0700 Message-ID: <6017.997298937@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 14:54:32 -0400 From: Keith Moore Message-ID: <200108081854.OAA15722@astro.cs.utk.edu> | why? nothing in the standards requires that all IP addresses be listed, Again, it depends upon exactly what you're measuring here. The DNS defines the name, and if it has A (or AAAA or A6) RR's, then those define the addresses that belong to that name. That someone might know of some other address that happens to reach the same piece of hardware isn't really relevant - even if the other address happens to work just as well. | there's also no reason that you couldn't use a completely | different mechanism than DNS to determine the IP address associated with | a service. (we will certainly need to do this someday, as DNS cannot | last forever) Perhaps. When that happens then we'll have two ways to define the mapping between names and addresses, and when they're not the same, we'll have a mess (unless we also design a whole new naming scheme to go with it, which is a rat hole I think I'll avoid in this discussion). | if hosts are notified when their address prefixes change, that notification | can be forwarded to any connections (TCP or otherwise) that the host knows | about. Yes, at the TCP level, things are easy (well, could be, assuming adequate protocol support, and "easy" is probably the wrong term even then, "possible" would be better). It is everything else that causes the problems. Long lived UDP NFS mounts are one to really worry about. With v6 they're almost all going to be able to use site local addressing, and so be immune, but they still show the problem - the server explicitly has no knowledge of who is connected, and it can be weeks between packets from clients to servers if nothing is happening... If the client just validates the name it was given whenever its address has expired, then it can pick up on address changes, and use the new address (the server doesn't care what address requests come to). Client renumberings in this scenario don't matter, as the server doesn't send unsolicited packets - only replies (so as long as the address remains valid for a RTT, that's enough...) Each protocol really needs to be investigated separately, what might work, and what mightn't will vary enormously. Which is another reason why attempting to fix it at the IP layer probably isn't the solution. | similarly, if those hosts can notify resident applications that the | addresses prefixes have changed, those applications can at least potentially | notify their peers. Only if the end that is renumbering has any idea who its peers are. That isn't always the case. | this doesn't solve the problem entirely, since more than one host | in a conversation could be concurrently changing addresses. yes, that part is the real hard one to handle - but if we can't get it right without that case, worrying about that one is a waste of energy. | but there is also probably a practical limit to the number | of address prefixes that should be used at any one time. Yes, but thanks to virtual web hosting (the old way) it isn't a limit we're going to reach with almost any renumbering frequency that is practical by any means... | well, we appear to have some people assuming that renumberings will be | so infrequent that we can disregard them, and others assuming that | renumberings will be so frequent that protocols have to deal with them | explicitly. that's no way to do engineering. for applications to | make use of IPv6 there needs to be some reasonable bounds on tbe | behavior of the network. Yes. Unfortunately, the very disagreement that you mention means that deciding what those bounds should be isn't going to be easy. Personally, I'm also not sure I need to know - I want to make it possible to renumber easily, which should make it possible to do frequently if needed, and then hope I almost never have to actually do it... That is, I want to be able to deal with the worst case, but will hope that the best case is what occurs. If the hopes fade, I will at least know that I'm not sunk - if they're realised, then everyone is happy. | I don't think that's the right criterion - first of all, that would have | 50% of all connections being broken; A factor of 2 or whatever isn't going to make any marked difference. | second, it's based on assumptions | about the nature of traffic, which will vary widely over time. Sure. Though we only care about the traffic that is likely to get caught in this net - anything too short lived, or whose characteristics make broken connections essentially irrelevant (ie: will retry anyway) can be ignored. We only need to include the stuff that wants to live a long life. | I'd rather say that we have expectations about how the network behaves - | just as (say) end-to-end packet loss should be no worse than 20%, Hmm... if it gets to double figures I give up for the day... But I don't think we've ever had such a definition, what packet loss is tolerable also depends heavily upon the applications. | address bindings should be good for at least several days. Would be a nice target. Just as long as we don't actually assume that we will be able to meet it. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 8 20:15:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24100 for ; Wed, 8 Aug 2001 20:15:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ud8s-000HaD-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 16:53:38 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Ud8r-000HZw-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 16:53:37 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Ud8p-0001eJ-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 00:53:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 8 Aug 2001 18:26:11 -0400 From: Dan Massey To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-delegation-signer-01 Message-ID: <20010808182611.A11259@bb.nge.isi.edu> References: <20010808112314.A10365@bb.nge.isi.edu> In-Reply-To: ; from jakob@crt.se on Wed, Aug 08, 2001 at 09:26:17PM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 08, 2001 at 09:26PM, Jakob Schlyter wrote: | | if my key is compromised, why should someone - by specification - prevent | me from removing it from my zone if I like to? it may be stupid, but it is | really my call. | | I'm not saying I would do that (I would probably wait for my parent zone | to put in the new key first), but some people may choose to actually break | their zone rather than have someone spoof it. | But how does breaking your zone prevent anyone from spoofing it? If it does help prevent spoofing, then I agree you should be allowed to do it. I claim removing the KEY/SIGs actually makes your zone more vulnerable to spoofing, not less vulnerable. Assume your key has been compromised and your parent is still reporting this KEY as valid. Three things can happen when a resolver asks for your data: 1) the resolver gets only a non-forged response - remove the KEY/SIGs from your zone and you make any response from the real namesevers invalid. - keep the KEY/SIGs and the resolver will still declare the response valid. 2) the resolver gets only a forged response (using the compromised key) - remove the KEY/SIGs from your zone and it still does not help since the forged response is signed by a key and the parent declares the key valid. - keep the KEY/SIGs and it also does not help and the forged response is still declared valid. 3) the resolver gets both a forged and real response - remove the KEY/SIGs and you make the real response appear to be forged and the forged response will be believed. - keep the the KEY/SIGs and you get two conflicting responses, both signed by the same KEY and both appearing to be valid. the resolver can't tell which response is right but at least the resolver could realize something is wrong. So in my view you always lose by removing the KEY/SIGs. In general, the compromised key MUST remain in the DNS until the parent updates its zone to prevent black holes. It is bad to have compromised keys in the DNS but creating black holes doesn't help. The compromised key remains a threat until the parent's SIG expires. Or am I missing something? Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 03:04:51 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16254 for ; Thu, 9 Aug 2001 03:04:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ujdy-000CAa-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 23:50:10 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Ujdx-000CAT-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 23:50:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Ujdw-0001iL-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 07:50:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 8 Aug 2001 18:31:31 -0700 From: David Terrell To: Masataka Ohta Cc: Tony Hain , Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010808183131.C31440@pianosa.catch22.org> References: <200108081430.XAA04529@necom830.hpcl.titech.ac.jp> In-Reply-To: <200108081430.XAA04529@necom830.hpcl.titech.ac.jp>; from mohta@necom830.hpcl.titech.ac.jp on Wed, Aug 08, 2001 at 11:30:43PM +0859 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, Aug 08, 2001 at 11:30:43PM +0859, Masataka Ohta wrote: > With end-to-end multihoming, it is possible that application/transport > program periodically check DNS to be smoothly renumbered. If you need this sort of feature set, you should probably be using something like SCTP which has explicit layer 4 support for multiple valid layer 3 addresses. -- David Terrell | "My question is, if a mime types, isn't dbt@meat.net | that kinda cheating?" http://wwn.nebcorp.com/ | - Jason Zych to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 03:04:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16262 for ; Thu, 9 Aug 2001 03:04:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uja9-000BzY-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 23:46:13 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Uja8-000BzS-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 23:46:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Uja6-0001i5-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 07:46:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B71D94C.7B04AA17@daimlerchrysler.com> Date: Wed, 08 Aug 2001 20:29:00 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: REFER Record Type? (was Re: Joint DNSEXT & NGTRANS agenda) References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit gson@nominum.com wrote: > Masataka Ohta writes: > > > How? No-one is suggesting that these records be put in the cache. > > > > I have been suggesting that these records be put in a referral-local > > cache content of which is not used for usual A query nor glue A of > > other referral points. > > I think that's an excellent approach, and one that should be seriously > considered when designing new resolver implementations. BIND 8 and 9 > have the concept of a single, global cache too deeply ingrained to be > changed at this point. Why not create a new record type for referrals, basically just a container type for arbitrary-yet-non-overlapping sets of NS and/or address records? Synthesizing traditional (NS RRset + address-record RRsets) referral data into REFER records should take care of your cache-database-structure problems. REFER records could also be used by authoritative nameservers and caches, under appropriate OPTION control of course, as a more compact format for expressing referrals to resolvers. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 03:05:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16277 for ; Thu, 9 Aug 2001 03:05:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UjdI-000C6d-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 23:49:28 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UjdH-000C6X-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 23:49:27 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UjdG-0001iI-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 07:49:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 8 Aug 2001 18:29:54 -0700 From: David Terrell To: Daniel Senie Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010808182954.B31440@pianosa.catch22.org> References: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <4979.997285484@brandenburg.cs.mu.OZ.AU> <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> In-Reply-To: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net>; from dts@senie.com on Wed, Aug 08, 2001 at 12:12:15PM -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, Aug 08, 2001 at 12:12:15PM -0400, Daniel Senie wrote: > At 11:44 AM 8/8/01, Robert Elz wrote: > > Date: Wed, 08 Aug 2001 11:13:52 -0400 > > From: Daniel Senie > > Message-ID: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> > > > > | Not to mention melting the 'net under ever increasing DNS load, since > > we'd > > | no longer be able to cache anything. > > > >Huh??? > > > >No-one ever said anything about changing the definition or use of the > >TTL field in DNS replies. If you get a TTL that says an address is > >valid for a day, then you can keep using it for a day without checking > >again. Or you can check again every 5 minutes if you want to, but > >the answers will just keep coming back from your local cache, each with > >a TTL 5 minutes shorter than the previous time... > > Reread what Keith wrote. If applications are going to use DNS to check for > changes in addressing, how is caching going to help? You're suggesting the > local caches just answer the every-5-minute lookups, but that's useless if > the DNS lookups are used as a part of multihoming. I interpreted the > periodic lookup as being a way for applications to find out that a remote > machine has migrated to a new address. If local caches mask that migration, > how's that help? > > Multihoming has to involve resiliancy. If the addresses are cached for a > day, saying "oh, your application will start working again tomorrow" is > unlikely to cut it. I think they're talking about reestablishing existing connections if the address published in the DNS changes. I think that's pretty silly. Application protocols should (where appropriate) be able to reconnect, or users can -- and DNS records near a renumbering event should have low TTLs, or multiple A* records for a multihomed situation, and applications should not be caching records excessively (or at all, really), and making multiple attempts at multiple A* records. -- David Terrell | "We must go forward, not backwards; upwards, Nebcorp Prime Minister | not forwards; and always twirling, twirling, dbt@meat.net | twirling towards freedom!" http://wwn.nebcorp.com/ | - The Simpsons to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 03:05:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16288 for ; Thu, 9 Aug 2001 03:05:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ujf6-000CFo-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 23:51:20 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Ujf5-000CFg-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 23:51:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Ujf4-0001iP-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 07:51:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: David Terrell cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010808182954.B31440@pianosa.catch22.org> References: <20010808182954.B31440@pianosa.catch22.org> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <4979.997285484@brandenburg.cs.mu.OZ.AU> <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> Date: Thu, 09 Aug 2001 10:21:35 +0700 Message-ID: <944.997327295@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 8 Aug 2001 18:29:54 -0700 From: David Terrell Message-ID: <20010808182954.B31440@pianosa.catch22.org> For the purposes of this discussion, the difference between: | I think they're talking about reestablishing existing connections | if the address published in the DNS changes. and | Application protocols should (where appropriate) be able to reconnect, is immaterial. The question is whether the user sees an interruption, not how the interruption is handled. Keith was asking for it to be fixed below the level of the applications, presumably because updating lots of applications (different kinds, and just different implementations) is going to be a very long process, whereas if things could be fixed below that everything would see instant benefits. That's also why SCTP isn't the immediate answer, as aside from actually getting that implemented and deployed itself, the applications would still need to be converted to use it. | or users can But that is exactly what people are claiming is unacceptable. I suspect that what it really depends upon is the particular application's nature. Which also suggests that handling this in the applications, rather than below, is the appropriate place. | -- and DNS records | near a renumbering event should have low TTLs, or multiple A* records | for a multihomed situation, and applications should not be caching | records excessively (or at all, really), and making multiple attempts | at multiple A* records. Yes - but the question is how the app determines that it needs to do this. If a peer renumbers, and you don't get told that happened, then all you can expect to see is either packets vanishing into the void, or perhaps an ICMP host unreachable. Both of those are also consistent with a net link going down. If you wait long enough to be fairly confident that it isn't just a transient net blip, then you've already caused enough of an interruption to the service that there's a noticeable problem. So, the question then is just how you decide that you should be establishing a new connection (or somehow making an old one shift addresses). That's where the possibility of looking in the DNS and seeing that the address you were told to use before is no longer there arose in the first place. If there's some way that you can do that before there's any packet interruption, then the renumbering can be made truly invisible to the users. If we decide that we have to wait until we get some kind of failure indication (even just a single RTT (or RTO) without a response - even though that usually just indicates mild congestion) then you have already altered the operation of the app - though perhaps imperceptably. If it was possible to create a signalling protocol so peers could be informed of address changes, that would solve the problems (any address validity overlap time would allow for a seamless address switch). But I can't see how to make that work for stateless protocols (DNS, NFS, ...) where the server is renumbered - basically the server simply has no idea who should be informed. Perhaps we can live with these failing, given that it is likely to be rare that such things cross site boundaries (the general DNS case is already doing DNS watching for address changes of course, using the TTL - it is a proof by example that it can be made to work - the cases that fail are the two where addresses are configured, that is root servers (where the problems are so great that the answer seems to be to simply give those immutable addresses forever) and locating a back end resolver for a stub - which is unlikely to cross a site boundary). As for apps caching DNS replies - I disgaree there. The TTL is there to allow caching, anyone who agrees to respect the TTL should be able to cache a DNS reply and re-use it until the TTL expires. Attempt to outlaw that and you just end up with semantic quibbles "That's not my application caching that address, it is my application's local resolver that is doing the caching..." kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 03:05:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16300 for ; Thu, 9 Aug 2001 03:05:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ujb7-000C1o-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 23:47:13 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Ujb6-000C1i-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 23:47:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Ujb3-0001i9-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 07:47:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108090105.VAA18362@astro.cs.utk.edu> From: Keith Moore To: "Hallam-Baker, Phillip" cc: "'Randy Bush'" , alh-ietf@tndh.net, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 09:07:41 PDT." <2F3EC696EAEED311BB2D009027C3F4F40154CA5F@vhqpostal.verisign.com> Date: Wed, 08 Aug 2001 21:05:30 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The principal benefit of NAT to many businesses is that it is a very > effective means of cutting off approximately 80% of network security > problems at a stroke. Less functionality is precisely what these users want. Understood. But very little of that security benefit is really due to NAT; most of it is due to the fact that connections have to be initiated from within. That's certainly an artifact of NAT (actually NAPT) but it can be done just as easily without translating addresses. > Rather than demanding that the network change to match the protocols it is > time to accept the fact that for the next twenty years at least NAT is going > to be a part of the infrastructure and look for ways in which that mode of > use can be supported without denying the end user a substantial degree of > functionality. You may be right about NAT being here to stay. Problem is, once you have a NAT in the signal path there's no way to repair the damage that has been done. That substantial degree of functionality (not to mention reliability) is inherently lost. > Since the only part of a TCP/IP session that needs the external address is > the initial setup, why not design protocols that allow that part to be > delegated to a third party 'connection server'? Your premise is false. TCP/IP doesn't need the external address at all; it's happy as long as each end sees consistent source and destination addresses throughout the entire connection. It's the applications that need globally usable and stable endpoint identifiers. > After all any personal > presence type protocol will need some form of static server since the user > will hop between devices even if the devices themselves had static > addresses. The trick would be to find some way to get the NAT boxes to > cooperate. With this approach you need the NAT boxes to explicitly support every protocol, and that makes new protocols difficult to deploy. The alternative is to teach the NAT boxes to support 6to4, which any v6 protocol can use. But you make a good point about security. If people get the idea (correctly or not) that they're sacrificing security by supporting v6, they won't bother deploying it. We need to have v6 border routers that deliver the same degree of security as NATs do, without actually translating addresses. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 03:12:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16393 for ; Thu, 9 Aug 2001 03:12:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ujgq-000CLk-00 for namedroppers-data@psg.com; Wed, 08 Aug 2001 23:53:08 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Ujgp-000CLb-00 for namedroppers@ops.ietf.org; Wed, 08 Aug 2001 23:53:07 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Ujgo-0001iV-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 07:53:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108090413.AAA19383@astro.cs.utk.edu> From: Keith Moore To: Robert Elz cc: David Terrell , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Thu, 09 Aug 2001 10:21:35 +0700." <944.997327295@brandenburg.cs.mu.OZ.AU> Date: Thu, 09 Aug 2001 00:13:47 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Keith was asking for it to be fixed below the level of the applications, > presumably because updating lots of applications (different kinds, and > just different implementations) is going to be a very long process, > whereas if things could be fixed below that everything would see instant > benefits. or more generally, I'm asking for some agreement on the degree of address stability an application should be able to expect - hopefully one that is large enough that most applications can work without having to explicitly deal with the potential for renumbering. even for those applications that do have to deal with renumbering, DNS names do not always suffice as peer names, due to the common need to map a single DNS name onto multiple addresses, the delay inherent in DNS queries, and the degraded reliability. Keith to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 04:25:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17254 for ; Thu, 9 Aug 2001 04:25:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UkxV-000Fm0-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 01:14:25 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UkxU-000Flu-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 01:14:25 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UkxT-0001nu-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 09:14:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: REFER Record Type? (was Re: Joint DNSEXT & NGTRANS agenda) In-Reply-To: <3B71D94C.7B04AA17@daimlerchrysler.com> References: <3B71D94C.7B04AA17@daimlerchrysler.com> <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> Date: Thu, 09 Aug 2001 14:51:00 +0700 Message-ID: <3898.997343460@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 08 Aug 2001 20:29:00 -0400 From: Kevin Darcy Message-ID: <3B71D94C.7B04AA17@daimlerchrysler.com> | Why not create a new record type for referrals, basically just a container | type for arbitrary-yet-non-overlapping sets of NS and/or address records? That isn't needed, what exists now in the protocol is just fine. The only requirement is that the implementations use it rationally. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 04:54:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17856 for ; Thu, 9 Aug 2001 04:54:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UlNh-000Gqe-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 01:41:29 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UlNg-000GqX-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 01:41:28 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UlNf-0001pZ-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 09:41:27 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Thu, 9 Aug 2001 01:31:28 -0700 Message-ID: From: "Christian Huitema" To: "Paul A Vixie" , "Alexis Yushin" Cc: "James Aldridge" , "Jim Bound" , "Matt Crawford" , , , , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA17856 Paul, Just for the record -- Microsoft as a corporation did not try to sway this issue one way or the other; individual IETF contributors who happen to work for Microsoft have various opinions in this debate. OTOH, we are shipping software, and we would really want the debate to be resolved very soon. -- Christian Huitema -----Original Message----- From: Paul A Vixie [mailto:vixie@vix.com] Sent: Tue 8/7/2001 9:00 AM To: Alexis Yushin Cc: James Aldridge; Jim Bound; Matt Crawford; ngtrans@sunroof.eng.sun.com; namedroppers@ops.ietf.org; ipng@sunroof.eng.sun.com; dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary > I see a big difference between deprecating/moving to historic and changing > status to experimental. Experemental implies further development. I don't see that difference here. Just as "let's let the market decide" really just means "let's do whatever Microsoft wants", so it is that "let's make it experimental" really just means "let's move on." (I find it amusing that SRV was experimental but that Microsoft's use of it pulled it forward.) I was not able to be in London, but had I been there my comments would've been: Let's not expect stub resolvers to do the caching necessary to understand either A6 or SIG/KEY -- those are things which servers ought to use to talk to other servers. Stub resolvers making recursive requests of their name servers should be using AAAA and TSIG. AAAA synthesis of underlying A6, and TSIG to protect verified KEY/SIG data for the last mile, is all a client needs. Every argument against SIG/KEY or against A6 comes down to either the caching problem or the complexity problem, and if we insulate the end-stations from those problems, the arguments are reduced to things which authority-side tools can be made to cope with. Hopefully this point was made by somebody. ¶‹§²æìr¸›zǧu©ž²Æ zÚ'jg®Šiz»ÿ­ê®zËÿ¢›ÿ‰ë_þŠàÂ+a¶°¢·ÿº{.nÇ+‰·ÿŠv¬Šx%zX§y«-…鞲Ơz×±µº From owner-namedroppers@ops.ietf.org Thu Aug 9 06:41:17 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20481 for ; Thu, 9 Aug 2001 06:41:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UmtH-000KWC-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 03:18:11 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UmtH-000KW6-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 03:18:11 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UmtG-0001vK-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 11:18:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: "Christian Huitema" , "Paul A Vixie" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: kre's message of Thu, 09 Aug 2001 16:16:12 +0700. <4216.997348572@brandenburg.cs.mu.OZ.AU> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Thu, 09 Aug 2001 18:22:52 +0900 Message-Id: <20010809092252.3EBEA7BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >I suspect that's half right - what microsoft put in their clients would >only matter if they start doing A6 lookups - if they just do AAAA, then >AAAA synthesis can allow A6 deployment to work just fine. as I repeatedly commented, AAAA synthesis does not really work in the wild due to the deployment hurdles and ambiguity as to who is going to synthesize. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 06:42:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20503 for ; Thu, 9 Aug 2001 06:42:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Umsl-000KTz-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 03:17:39 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Umsk-000KTt-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 03:17:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Umsj-0001vG-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 11:17:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "Christian Huitema" cc: "Paul A Vixie" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: References: Date: Thu, 09 Aug 2001 16:16:12 +0700 Message-ID: <4216.997348572@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 9 Aug 2001 01:31:28 -0700 From: "Christian Huitema" Message-ID: | Just for the record -- Microsoft as a corporation did not try to sway | this issue one way or the other; That wasn't the way I read Paul's comment - I read it more as suggesting that if the IETF doesn't pick one way or the other, and completely stamp out the other (ie: if one gets marked as experimental, or if both get left as PS), then you (Microsoft) will just pick whichever one that appeals to you most, and that will effectively set the standard, regardless of what any of the rest of us think later. I suspect that's half right - what microsoft put in their clients would only matter if they start doing A6 lookups - if they just do AAAA, then AAAA synthesis can allow A6 deployment to work just fine. I'm less convinced about the power of microsoft to sway the world via the server behaviour. The one thing that is pretty clear, is that if microsoft clients start doing A6 queries to find IPv6 addresses, then it is A6 that the world will deploy (we won't be synthesising A6 records out of AAAA, while possible, that makes no sense at all). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 06:45:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20535 for ; Thu, 9 Aug 2001 06:45:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Umts-000KWu-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 03:18:48 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Umtr-000KWl-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 03:18:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Umtr-0001vU-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 11:18:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Jun-ichiro itojun Hagino cc: "Christian Huitema" , "Paul A Vixie" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010809092252.3EBEA7BA@starfruit.itojun.org> References: <20010809092252.3EBEA7BA@starfruit.itojun.org> Date: Thu, 09 Aug 2001 16:41:41 +0700 Message-ID: <4348.997350101@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 09 Aug 2001 18:22:52 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20010809092252.3EBEA7BA@starfruit.itojun.org> | as I repeatedly commented, AAAA synthesis does not really work in the | wild due to the deployment hurdles and ambiguity as to who is going | to synthesize. There's no ambiguity. It gets done at your local resolver/cache. For deployment, yes, to make use of A6 lookups code is going to need to be deployed - if that means just that it is required that you deploy a back end resolver that understands A6 and AAAA synthesis, then that seems like a fairly easy upgrade path (much easier than if all the clients had to be upgraded). And yes, as you have pointed out, if the local back end resolver doesn't understand A6, and AAAA synthesis, then AAAA queries will still get transmitted to the rest of the net. In the short term, the existing AAAA records can just be returned, that's the first step of transition. But it also does no great harm if some other server does AAAA synthesis on your behalf (you'll have no good way to verify the data, but the chances are that you wouldn't be bothering even if you had). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 08:34:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21852 for ; Thu, 9 Aug 2001 08:34:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uok6-00003H-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 05:16:50 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Uok5-000034-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 05:16:49 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Uok4-00020J-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 13:16:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 09 Aug 2001 05:32:22 -0500 From: Matt Crawford Subject: Question on Stewart's last mDNS item To: namedroppers@ops.ietf.org Message-id: <200108091032.f79AWMm08455@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Did svrloc crash & burn without me noticing? Or is there a terrible gap in coverage? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 08:35:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21895 for ; Thu, 9 Aug 2001 08:35:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uois-000Pyy-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 05:15:34 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Uois-000Pyq-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 05:15:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Uoiq-000209-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 13:15:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: draft-guttman-dhc-mdns-enable-01.txt From: Jun-ichiro itojun Hagino Date: Thu, 09 Aug 2001 19:28:33 +0900 Message-Id: <20010809102833.11A5E7BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit i support local.arpa approach. - there are environments without DHCP, therefore the approach is not generic enough. i.e. autoconfigured IPv6 network. - responder side of mDNS can be always enabled, local.arpa should change the querier side behavior only. - it is still unclear to me how does "mDNS" and "normal DNS" search order interact with existing search path. NOTE: I have implemented many of past mDNS drafts and testing these mostly using IPv6. also I would say that I'm a bit tired of chasing changes in revs. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 08:42:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22035 for ; Thu, 9 Aug 2001 08:42:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UoqP-0000K8-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 05:23:21 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UoqO-0000K2-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 05:23:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UoqN-00020e-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 13:23:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 9 Aug 2001 08:03:20 -0400 (EDT) From: Greg Maxwell To: Robert Elz cc: David Terrell , , , , Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <944.997327295@brandenburg.cs.mu.OZ.AU> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 9 Aug 2001, Robert Elz wrote: [snip] > Keith was asking for it to be fixed below the level of the applications, > presumably because updating lots of applications (different kinds, and > just different implementations) is going to be a very long process, > whereas if things could be fixed below that everything would see instant > benefits. That's also why SCTP isn't the immediate answer, as aside > from actually getting that implemented and deployed itself, the applications > would still need to be converted to use it. [snip] Why would this be unacceptable? Having connections survive renumbering is an enhanced feature, and yet another reason applications should move to an improved transport. For the general case of site renumbering, such a change could typically occur in off-hours (where they exist), and go service by service so I don't think it's critical that every application should be able to survive it seemlessly. Mobile IP is a more intresting situation, It would be useful if a mobile host could carry two prefixes, it's tunneled prefix, and a local prefix and could utilize transport layer renumbering support to seemlessly move between networks without the constant overhead of tunneling or dropping connections. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 08:52:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22286 for ; Thu, 9 Aug 2001 08:52:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Up0j-0000nT-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 05:34:01 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Up0i-0000nM-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 05:34:01 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Up0h-00021M-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 13:33:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200108091230.f79CURE21508@zed.isi.edu> Subject: Re: Question on Stewart's last mDNS item To: crawdad@fnal.gov (Matt Crawford) Date: Thu, 9 Aug 2001 05:30:27 -0700 (PDT) Cc: namedroppers@ops.ietf.org In-Reply-To: <200108091032.f79AWMm08455@gungnir.fnal.gov> from "Matt Crawford" at Aug 09, 2001 05:32:22 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % % Did svrloc crash & burn without me noticing? Or is there a % terrible gap in coverage? % If you were on the old srv-loc list, you should have seen this: ----------------------------------------- Date: Wed, 13 Jun 2001 08:08:02 -0700 Welcome to the Srvloc-discuss@lists.sourceforge.net mailing list! A lot of changes have occurred for the SVRLOC WG. First, as you probably noticed, our server 'srvloc.org' has gone away. We have found a new host on sourceforge.net. Second, with the publication of RFC 3111 "Service Location Protocol Modifications for IPv6", the SVRLOC WG has completed all the work on its charter. The working group has concluded. Work on SLP is continuing. - There are individual submission internet drafts are continuing on their way towards being RFCs - all in need of review. draft-guttman-svrloc-vendor-ext-04.txt draft-zhao-slp-da-interaction-10.txt draft-day-svrloc-exclusion-01.txt - We are working on (and will soon be discussing actively) promoting SLPv2 to draft standard. This will require a list of changes (dropped features and clarifications) a new specification thorough interoperability testing an implemenatation report an IETF last call - We are gathering service templates. If you have any to register, send them to svrloc-list@iana.org. You can join this mailing list. This mailing list is inactive - but hopefully will pick up. Its (currently empty) archive is located at: http://www.merit.edu/mail.archives/svrloc-template Even though the official IETF working group has concluded, work on SLP will continue through participation on this mailing list. I look forward to further collaboration and progress standardizing and developing this protocol. Please continue to support this work. Erik Guttman Chair of the now concluded SVRLOC WG To post to this list, send your email to: srvloc-discuss@lists.sourceforge.net General information about the mailing list is at: http://lists.sourceforge.net/lists/listinfo/srvloc-discuss -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 09:07:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22639 for ; Thu, 9 Aug 2001 09:07:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UpJq-0001nq-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 05:53:46 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UpJp-0001ni-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 05:53:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UpJo-00022O-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 13:53:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010809054034.01a8fd90@jurassic> Date: Thu, 09 Aug 2001 05:47:18 -0700 To: namedroppers@ops.ietf.org From: Alain Durand Subject: mDNS vs DNS Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Somebody said this morning that the wg did not wanted to combine mDNS & DNS. There is something I do not understand and I would like some clarification. On most systems I know, there is a switch that tells the system which name service to use, and in which order. e.g. check /etc/hosts first, then NIS, then DNS... or a different order. Why couldn't there be an entry in the switch that says check /etc/hosts first, then try mDNS, then try DNS? - Alain. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 09:39:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22034 for ; Thu, 9 Aug 2001 08:42:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UosZ-0000Qi-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 05:25:35 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UosY-0000Qb-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 05:25:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UosX-00020n-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 13:25:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108091210.f79CAWu76993@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Keith Moore cc: "Hallam-Baker, Phillip" , "'Randy Bush'" , alh-ietf@tndh.net, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of Wed, 08 Aug 2001 21:05:30 EDT. <200108090105.VAA18362@astro.cs.utk.edu> Date: Thu, 09 Aug 2001 14:10:32 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In your previous mail you wrote: But you make a good point about security. If people get the idea (correctly or not) that they're sacrificing security by supporting v6, they won't bother deploying it. We need to have v6 border routers that deliver the same degree of security as NATs do, without actually translating addresses. => this is easy for TCP (or any connected transport, cf the tcp established of Cisco routers) but I can't see a way to do this for UDP without keeping state... Of course this argument doesn't apply if a real firewall is used (stateless firewalls are out of the market or should be ASAP). Regards Francis.Dupont@enst-bretagne.fr to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 09:47:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23540 for ; Thu, 9 Aug 2001 09:47:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uq0N-0003gc-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 06:37:43 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Uq0N-0003gJ-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 06:37:43 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Uq0M-00025O-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 14:37:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 09 Aug 2001 08:25:52 -0500 From: Matt Crawford Subject: Re: Question on Stewart's last mDNS item In-reply-to: "09 Aug 2001 05:30:27 PDT." <200108091230.f79CURE21508@zed.isi.edu> To: Bill Manning Cc: namedroppers@ops.ietf.org Message-id: <200108091325.f79DPrm09624@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > % Did svrloc crash & burn without me noticing? Or is there a > % terrible gap in coverage? > % > If you were on the old srv-loc list, you should have seen this: OK, so did they or didn't they solve the problems that it seemed like Stewrt wanted addressed in mDNS. I thought they had, but I had tuned out ... to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 09:51:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23671 for ; Thu, 9 Aug 2001 09:51:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Upyr-0003a7-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 06:36:09 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Upyq-0003Zr-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 06:36:08 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Upyp-00025H-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 14:36:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Alain Durand Cc: namedroppers@ops.ietf.org Subject: Re: mDNS vs DNS References: <5.1.0.14.0.20010809054034.01a8fd90@jurassic> Message-Id: Date: Thu, 09 Aug 2001 14:23:31 +0100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Somebody said this morning that the wg did not wanted to combine mDNS & DNS. > ... > Why couldn't there be an entry in the switch that says > check /etc/hosts first, then try mDNS, then try DNS? and this precisely makes clear that mDNS is not part of the DNS. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 10:57:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25979 for ; Thu, 9 Aug 2001 10:57:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Ur21-0006of-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 07:43:29 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Ur20-0006oZ-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 07:43:28 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Ur20-00028d-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 15:43:28 +0100 Date: Thu, 9 Aug 2001 07:25:08 -0700 (PDT) From: Bernard Aboba To: Alain Durand cc: namedroppers@ops.ietf.org Subject: Re: mDNS vs DNS In-Reply-To: <5.1.0.14.0.20010809054034.01a8fd90@jurassic> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On most systems I know, there is a switch that tells the system which name > service > to use, and in which order. > e.g. check /etc/hosts first, then NIS, then DNS... or a different order. > Why couldn't there be an entry in the switch that says > check /etc/hosts first, then try mDNS, then try DNS? > You've just described the "use the name service searchlist" school of thought on configuring mDNS. As with the domain searchlist, this approach can be used with a DHCP option (RFC 2937) or based on local configuration. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 11:44:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27898 for ; Thu, 9 Aug 2001 11:44:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UrkW-00091h-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 08:29:28 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UrkV-00091b-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 08:29:27 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UrkU-0002Al-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 16:29:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696C6@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Cc: "'Randy Bush'" , alh-ietf@tndh.net, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Thu, 9 Aug 2001 08:15:19 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Understood. But very little of that security benefit is > really due to NAT; most of it is due to the fact that > connections have to be initiated from within. That's > certainly an artifact of NAT (actually NAPT) but it can > be done just as easily without translating addresses. Unfortunately the problem with anything labelled 'security' is that once it is installed it is practically impossible to shift. We still have people who refuse to countenance moving from DES which has been broken in practice to AES because they don't know how secure AES will prove... well duuhh, it ain't gonna be worse than DES. So we give them 3DES rather than argue. Co-opting the NAT box as you suggest to become a 6 to 4 type box is the real answer. Wishing they will go away is simply futile. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 19:16:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07205 for ; Thu, 9 Aug 2001 19:16:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uypl-0007NY-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 16:03:21 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Uypl-0007NS-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 16:03:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Uypk-0002O5-00 for namedroppers@ops.ietf.org; Fri, 10 Aug 2001 00:03:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 9 Aug 2001 20:05:02 -0000 Message-ID: <20010809200502.2501.qmail@cr.yp.to> From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <5.0.2.1.2.20010807172339.0301adb0@localhost> <200108080830.RAA02821@necom830.hpcl.titech.ac.jp> <5.0.2.1.2.20010808093637.02ff22f8@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David R. Conrad writes: > But it wouldn't be since addresses are embedded in (manually edited) > configuration files, filter lists, etc. What relevance does this have to the topic at hand? If you want to change the software to look up addresses in DNS, go ahead. A6 doesn't make this any easier. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 19:16:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07216 for ; Thu, 9 Aug 2001 19:16:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uyop-0007Ks-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 16:02:23 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Uyop-0007Km-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 16:02:23 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Uyoo-0002Ny-00 for namedroppers@ops.ietf.org; Fri, 10 Aug 2001 00:02:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B72F0F6.A48A9850@daimlerchrysler.com> Date: Thu, 09 Aug 2001 16:22:14 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: REFER Record Type? (was Re: Joint DNSEXT & NGTRANS agenda) References: <3B71D94C.7B04AA17@daimlerchrysler.com> <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> <3898.997343460@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: Wed, 08 Aug 2001 20:29:00 -0400 > From: Kevin Darcy > Message-ID: <3B71D94C.7B04AA17@daimlerchrysler.com> > > | Why not create a new record type for referrals, basically just a container > | type for arbitrary-yet-non-overlapping sets of NS and/or address records? > > That isn't needed, what exists now in the protocol is just fine. > The only requirement is that the implementations use it rationally. Empirically speaking, I think you're setting the bar for "rationality" way too high. BIND mushes everything into one "global" cache, djbdns is lost somewhere in Bailiwicksville and I shudder to think how other implementations deal with referrals. Probably just as poorly, if not worse. I'm simply trying to come up with something that encapsulates referrals in a straightforward way. Something without so many implementation pitfalls, caveats and exceptions. The fact that it might also save a little packet space is just a bonus. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 19:18:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07235 for ; Thu, 9 Aug 2001 19:18:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UypH-0007Lh-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 16:02:51 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UypH-0007LU-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 16:02:51 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UypG-0002O1-00 for namedroppers@ops.ietf.org; Fri, 10 Aug 2001 00:02:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 9 Aug 2001 19:50:55 -0000 Message-ID: <20010809195055.20375.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <4216.997348572@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz writes: > if microsoft clients start doing A6 queries to find IPv6 addresses, > then it is A6 that the world will deploy Do you mean that they'll look for A6 and _not_ AAAA? If so, they'll cut themselves off from practically the entire IPv6 network: administrators provide addresses as AAAA, not A6. Or do you mean that they'll look for A6 _and_ AAAA? If so, how does that motivate administrators to switch to A6? Administrators who switch will cut themselves off from all the other clients that look only for AAAA. Or are you talking about an imaginary world in which AAAA and A6 are both starting from scratch? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 19:19:52 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07265 for ; Thu, 9 Aug 2001 19:19:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UyrX-0007VA-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 16:05:11 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UyrW-0007V3-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 16:05:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UyrV-0002OJ-00 for namedroppers@ops.ietf.org; Fri, 10 Aug 2001 00:05:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.0.2.1.2.20010809141410.0303ce78@localhost> Date: Thu, 09 Aug 2001 14:46:15 -0700 To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: "David R. Conrad" Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010809200502.2501.qmail@cr.yp.to> References: <5.0.2.1.2.20010807172339.0301adb0@localhost> <200108080830.RAA02821@necom830.hpcl.titech.ac.jp> <5.0.2.1.2.20010808093637.02ff22f8@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan, I know it is hard when you're so busy lying about "The BIND Company", but do try to keep up. I was responding to a message that said A6 makes renumbering trivial. I was suggesting that the real renumbering problem can't be solved just in the DNS. It would, at best, solve only a portion of the problem. However, please continue to remove context and misrepresent -- you do it so well. Rgds, -drc At 08:05 PM 8/9/2001 +0000, D. J. Bernstein wrote: >David R. Conrad writes: > > But it wouldn't be since addresses are embedded in (manually edited) > > configuration files, filter lists, etc. > >What relevance does this have to the topic at hand? > >If you want to change the software to look up addresses in DNS, go >ahead. A6 doesn't make this any easier. > >---Dan >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 9 19:20:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07321 for ; Thu, 9 Aug 2001 19:20:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Uylg-00077d-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 15:59:08 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15Uylf-00077I-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 15:59:07 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15Uyle-0002Iw-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 23:59:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B72D0DD.4000806@zeor.simegen.com> Date: Fri, 10 Aug 2001 04:05:17 +1000 From: Dancer Vesperman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+; Debian/GNU) Gecko/20010701 To: Christian Huitema CC: Paul A Vixie , Alexis Yushin , James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Paul, > > Just for the record -- Microsoft as a corporation did not try to sway this issue one way or the other; individual IETF contributors who happen to work for Microsoft have various opinions in this debate. OTOH, we are shipping software, and we would really want the debate to be resolved very soon. > > -- Christian Huitema > > -----Original Message----- > From: Paul A Vixie [mailto:vixie@vix.com] > > > > I see a big difference between deprecating/moving to historic and changing > > status to experimental. Experemental implies further development. > > I don't see that difference here. Just as "let's let the market decide" > really just means "let's do whatever Microsoft wants", so it is that "let's I think what Paul meant was an invocation of the Golden Rule of Arts and Sciences ("He who has the gold, makes the rules" for those not versed in the classics). There's probably no need to wave loaded disclaimers around where they might go off, and injure a bystander :) Microsoft's name (rightly or wrongly) is commonly substituted by those in the halls of Information Technology for any amoral, monopolising concern or manufacturer of low-quality merchandise. It is not at all unusual (in my personal experience) to hear a shoddy telecommunications provider, or a Harmful Products Manufacturer(tm) referred to as 'A Microsoft' or 'A Microsoft Subsidiary'. Oh, well. I guess any publicity is good publicity...Or at least that's what I've heard Marketing say. :) D to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 10 03:03:10 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00040 for ; Fri, 10 Aug 2001 03:03:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V64l-0006Wf-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 23:47:19 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15V64j-0006WY-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 23:47:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15V64i-0002a8-00 for namedroppers@ops.ietf.org; Fri, 10 Aug 2001 07:47:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 9 Aug 2001 20:14:18 -0700 (PDT) From: Bernard Aboba To: Robert Elz cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <4216.997348572@brandenburg.cs.mu.OZ.AU> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > That wasn't the way I read Paul's comment - I read it more as suggesting > that if the IETF doesn't pick one way or the other, and completely > stamp out the other (ie: if one gets marked as experimental, or if both > get left as PS), then you (Microsoft) will just pick whichever one that > appeals to you most, and that will effectively set the standard, > regardless of what any of the rest of us think later. > I believe that it was Pogo that said: "We have met the enemy... and it is us." Rather than worrying so much about what this or that company might do, the IETF might better spend its time and energy making clear decisions within a reasonable timeframe. Most IPv6 implementors will need to make a decision on how to handle AAAA/A6 in the next 6 months. Without guidance from the IETF, history suggests that they will each make the decision based on their own analysis, and then once having shipped, less flexibility will be available in order to accomodate the installed base. We've already gone down this road with IKE -- where the most basic VPN scenarios do not interoperate. In many cases "no decision" is actually the worst possible decision. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 10 03:12:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00191 for ; Fri, 10 Aug 2001 03:12:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V6F5-00077b-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 23:57:59 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15V6F5-00077L-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 23:57:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15V6F4-0002ac-00 for namedroppers@ops.ietf.org; Fri, 10 Aug 2001 07:57:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010809195055.20375.qmail@cr.yp.to> References: <20010809195055.20375.qmail@cr.yp.to> <4216.997348572@brandenburg.cs.mu.OZ.AU> Date: Fri, 10 Aug 2001 13:23:30 +0700 Message-ID: <1957.997424610@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: 9 Aug 2001 19:50:55 -0000 From: "D. J. Bernstein" Message-ID: <20010809195055.20375.qmail@cr.yp.to> This is a pointless exercise, but anyway... | Do you mean that they'll look for A6 and _not_ AAAA? I meant if they did that - I'm not expecting it to be very likely. | If so, they'll cut themselves off from practically the entire IPv6 | network: administrators provide addresses as AAAA, not A6. Some now do both.. but they wouldn't, the point of the original comment was that whatever the dominant market share does, everyone else is forced to follow. If 90% of the clients happened to be doing A6 lookups, then administrators would be providing A6 records. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 10 03:14:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00254 for ; Fri, 10 Aug 2001 03:14:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15V6GT-0007Dg-00 for namedroppers-data@psg.com; Thu, 09 Aug 2001 23:59:25 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15V6GS-0007Da-00 for namedroppers@ops.ietf.org; Thu, 09 Aug 2001 23:59:24 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15V6GR-0002ar-00 for namedroppers@ops.ietf.org; Fri, 10 Aug 2001 07:59:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200108100621.PAA14172@necom830.hpcl.titech.ac.jp> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.0.2.1.2.20010808093637.02ff22f8@localhost> from "David R. Conrad" at "Aug 8, 2001 11:10:50 am" To: "David R. Conrad" Date: Fri, 10 Aug 2001 15:20:58 +0859 () CC: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit drc; > >So, you are saying that the large organiation is currently accepting > >to manually change IP addresses of DNS servers on renumbering, aren't > >you? > > Yes. > > >If so, A6 is perfectly fine for it for easy and quick renumbering. > > I don't think so. A6 is only a small part of the full problem. The beggest part of the full problem is updating DNS glue. > >The only thing to do is to have an RFC for the organization to tell > >renumbering with A6 is as easy as with NAT. > > But it wouldn't be since addresses are embedded in (manually edited) > configuration files, filter lists, etc. It is really painful to do so with 128 bit addresses. With A6, DNS provides not only addresses but also bitmasks that writing cofiguration becomes easy. > Sorta reminds me of the IDN situation. Instead of focusing on the real > problem (getting higher layers to do the right thing), the focus is on > fixing the DNS... The right thing to do for IDN and NAT, is not to use them. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 11 03:05:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04292 for ; Sat, 11 Aug 2001 03:05:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15VSKi-000Iki-00 for namedroppers-data@psg.com; Fri, 10 Aug 2001 23:33:16 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15VSKi-000Ikc-00 for namedroppers@ops.ietf.org; Fri, 10 Aug 2001 23:33:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15VSKi-000EqY-00 for namedroppers@ops.ietf.org; Fri, 10 Aug 2001 23:33:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Olafur Gudmundsson To: DNSEXT mailing list , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com cc: dnsop@cafax.se Subject: Final DNSEXT NGTRANS Joint meeting minutes In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 10 Aug 2001 23:33:16 -0700 Content-Transfer-Encoding: 7bit Final Minutes of the DNS-EXT/NGTRANS joint meeting on How to represent IPv6 addresses in DNS IETF-51, London - 6 August 2001 Olafur Gudmundsson, Alain Durand & Tony Hain chairing Minutes by: Bob Fink, David Lawrence, Jun-ichiro itojun Hagino (thanks for great minutes) Edited by Bob Fink and Olafur Gudmundsson ----- Agenda Introduction (2 min) - Olafur Bit labels (5 min) - Alain DNAME use in reverse IPv6 tree (5 min) - Alain AAAA vs A6 (60 min) - Alain Consensus building (40 min) - Tony Summary (8 min) -Olafur ----- Short names: Full names Alain Alain Durand Bob Bob Hinden Christian Christian Huitema Erik Erik Nordmark Itojun Jun-ichiro itojun Hagino Matt Matt Crawford Olafur Olafur Gudmundsson Perry Perry Metzger Randy Randy Bush Rob Rob Austein Steve Steve Deering Thomas Thomas Narten Tony Tony Hain Introduction Olafur explained that the meeting goal is to find rough consensus on how to go forward with representation of IPv6 addresses in DNS. The meeting output will be an ID summarizing the meeting consensus, which will be taken to the appropriate mailing list(s). ---- Bit labels - Alain Are bit labels necessary in IPv6 DNS reverse tree, and is anybody planning to delegate on the last 4 bits? Matt Crawford stated that Bit Labels are not necessary if you are willing to do the delegation hack on non-nibble boundaries. Rob Austein explained that the last 4 bits meant a /125 or larger. There was no response from the floor to the questions posed by Alain. Andrea Gustafsson asked for someone to clarify why last 4 bits are special. Randy Bush explained that the issue is allocations in the last label when using a text-based name format in the reverse tree. In IN-ADDR.ARPA that means allocations in the last octet; in the text based version of IP6.ARPA (nibbles, not bitlabels), that means allocations in the last nibble. Being there was no discussion, Alain moved on. -- DNAME use in reverse IPv6 tree - Do we need DNAME in the IPv6 reverse tree? Alain noted that other DNAME uses were out of scope for the discussion. Christian noted that if you really want renumbering on fly, DNAME is needed, thus it follows the decision on need for A6. Matt Crawford noted that there is value in forward tree, even if not in reverse tree. Michael Patton said that we if we do A6, require DNAME in reverse tree, but if AAAA only, there is some value. Matt said that DNAME can be used to keep reverse map in the same zone as direct map. Alain asked if this was still true if there were only AAAA and no A6. Matt said yes. Olafur summarized that, given the limited defense of DNAME it was a DNS decision on whether other uses of DNAME justified it. --- AAAA vs A6 - Does anybody have any other application that requires A6, that can not be done by back-end processing and are not covered by draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt? Christian noted a point only partially covered by Rob's ID. Assumption is a db with all systems listed. There are schemes where hosts push addresses to db and when renumbering, there are individual decision that 1000's of hosts could to update the DNS with. Perry Metzger stated that if one does the db right, then tools can do it cleanly, no special protocol hacks are needed. We only think not due to lack of tools. It's only a SMOP :-), like MOIRA (sp) at MIT. Matt Crawford noted that this still relies on tools not yet written. A6 buys ability to register as single RR in db for all prefixes as it goes. Perry understands desire, but believes tools are needed, and for more than A6. Jim Bound asked if, assuming backend processing (with better tools than we now have), to evaluate if A6 make it more efficient, and thus worth implementing in this context. Olafur said, yes, a natural representation in db looking something like A6, would help. Jim Bound responded if we then agree, lets focus in the direction A6 points. Bill Sommerfield - I worked on MOIRA (sp) at MIT (that Perry mentioned as example) and I don't think that is for all sites. Wrong to force on all sites where model might not fit. Matt Crawford noted that missing from questions is, we focus on "today", not if it is needed in future. E.g., coupling of DNS prefix delegation to routing system's idea of prefix delegation. - Is IPv6 going to do rapid renumbering or GSE-like routing? Bob Hinden asked if hourly or daily likely? Weekly/monthly most likely, i.e., not all that rapid. Rapid renumbering was not an original (or even current) goal for IPv6. Tony GSE is a "per packet" renumbering Matt Crawford noted that there was lots of discussion for minimal allocation size (i.e., the /48 issue). There are other ways for a body/system to move that might require rapid renumbering. One can't say for sure rapid renumbering won't be needed, and thus A6. Margaret Wasserman asked if we ware talking automated renumbering or not. Rob stated that if IPv6 going to do automated renumbering frequently, that quad A can't cope with it, even with better tools, due to issues like resigning time Christian noted there are scenarios with several prefixes: e.g., one might toggle between them on a daily basis or faster. Christian felt that for fire exit usage, if renumbering not used often (to check that it works) it would never be used. Steve Deering felt that many sites will have to renumber enough to know protocol (and implementations) work. Christian noted that the argument on renumbering seems to be gated on resigning. He is not convinced that we can't do security right. Steve stated that on issues other than security, an important goal with IPv6 is to make renumbering easier, but to make it occur very fast is unsolved, for more than just DNS records. Thus if we do rapid renumbering, it will be a very different architecture, e.g., GSE, and it is likely that it would keep site ignorant of changes and thus A6 wouldn't help. Ted Hardy asked if there are there applications for rapid renumbering, that happen faster than route propagation, that fall under multi-homing. Renumbering that happens faster than route propagation won't work. Alexis Yushin asked if we know what the future is. IPv6 will be used in new applications beyond our current Internet, and who knows what these uses are. Choice is either put A6 flexibility there for the future, or stop developing A6 now and invent something new in future. Jim Bound agreed w/Steve that one can't guarantee rapid renumbering. A6 is a tool that underwent significant development and that it is an abstraction like scoping, multi-casting, that adds quality to the IPv6 architecture. Users will need renumbering to adopt IPv6. Perry asked at what costs. DNS queries are under fire for getting slower. Confident that he could renumber in hours or days, but probably not faster. It does work with AAAA, though he admitted his experience was for a small site. Randy noted that the problem with doing A6 for possibility of rapid renumbering is following dreams, not reality. To get v6 traction, A6 not helping. Jim Bound agreed with Randy, but would like to see if A6 0 would work and do testbeds to see what works. Concerned that the code base (we now have) might be useful might be thrown away before we learn from it. Simon Leinen noted that the performance issues are not straight forward. A6 request might be handled faster than AAAA, when host has many addresses. Matt Crawford asked do you think we can deploy A6 later on and really get it deployed? Randy noted that playing with A6, IPv6 folk are maintaining their code better than v4 folk may be. If we do renumbering it is analogous to, "do we do the routing thing". A6 is a solution to a problem we haven't yet defined, and constrains our solutions in future. Rather solve our problems and solve DNS stuff after. Matt Crawford asked again if we can make a change in the future like that? Thomas Narten asked, if we do rapid renumbering, are other changes needed? Then couldn't putting in changes for DNS be done too? Steve Deering noted that we have AAAA, and going to A6 0 is a "no brainer", but if it is lots of work to change to A6 for a limited value, is it worth it? Someone (name please ??) asked if we do A6 0, isn't it really just as hard to do a full-blown A6 later? Theo Pagtzis asked how would A6 handle really rapid renumbering? Steve Deering noted again, Mobile IP could do it, thus A6 not needed useful for rapid renumbering. Olafur felt that translation of A6 0 is easy, synthesis easy. The only question is then one of delay. Some company has done this already. Steve Deering asked, at what transition cost? Simon Linen (??) stated that AAAA and A6 are easy, and both can be deployed at the same time in the same zone, simple to have tools maintain one record type from the other. Itojun stated that maintaining A6 and AAAA is not easy. Rob Austein asked if mechanisms ease pain, as it is several years to do transition. This was discussed in Minneapolis. Another variation is to modify servers to generate A6 0 when quad AAAA is found. Though, when translating either way, signature is lost. However, it is important to not use A6 in complex ways. It is an attractive nuisance in that it does encourage people to try to exploit A6 beyond reasonable usage. Matt Crawford felt that transition best be kept short. Itojun is concerned that Rob says years to do transition tools and that his users can't wait. Alain stated that the plan from Minneapolis roughly described the transition. Rob said that Itojun correct; we can't take a long time for a transition. It is important to decide on A6 very soon. Mohsen Suissi from FRNIC noted that many users have been waiting for years to move to IPv6 production. AAAA works fine. If we say we have to move to A6 0 and wait for bind 9, and/or new O/S, we are waiting for more years. customers keep waiting. Itojun asked how many BIND 4 servers are still around versus BIND 9? Perry - how many folks using v6 all the time. A number of hands. Of these how many could run A6 soon, not so many of the hands. Folks around us using AAAA, can we go backwards and wait? Randy asked that for installed AAAA base would you use A6, and the he would, if it was a significant value, which it isn't. Jim Bound would change resolvers not O/S thus AAAA use would continue and this is only an operational issue. Margaret Wasserman asked why this is an issue of one against other. We have AAAA, so question is do we continue to work on A6, say as experimental. Plan for success, for renumbering, why not keep both? Steve Deering agree w/Margaret and Jim. Lack of decision here doesn't keep people from moving to IPv6. It should not be viewed as blocking IPv6. Alain said that the root operators are trying to get IPv6 accessible root servers, and that they are concerned about what to implement. --- Returning to GSE-like routing usage for A6 Randy stated that if a critical architectural change needed for A6, he would support it. However, we don't know what it will be yet. Thomas said that when Rob talked about transition time being a couple years this means at least 2, but he believes it would take 5 years given what is shipping and what current plans are. Tony Hain also noted that since decision is taking a while, we are talking about 6 months. before real development could even start. Maybe it's a 7 year transition. ==== consensus building (one minute break while chairs huddle) Tony Hain summarized what we are hearing from this meeting's discussions: --- Bitstring not necessary, so will take to list to confirm. --- DNAME - only one case where its necessary is if we choose A6. Matt believes you don't need but will really wish for it. Rob said without A6, DNAME use is a more general DNS question, i.e., equally relevant to v4. So again Tony noted that we will take to list to confirm. --- A6/AAAA - tools needed, and could make host push update vs relational db work. So again Tony noted that we will take to list to confirm. --- Renumbering - no consensus on time frames and out of scope here. If rapid implies less than hourly and requires significant architectural change than DNSSEC fails in verifying signature changes. Randy agreed but asked that GSE/8+8 also is in category of rapid renumbering (i.e., can't tell now if it will happen or when, and what it will look like). Also, noted that it is an operationally attractive nuisance. --- Next the chairs attempted to get the sense of the room to the reading material and discussions. Consensus is to be judged on the mailing list. - Straw polling the 4 address options for rough consensus: The first 3 questions where asked then there was restart after clarification on what experimental status was. - full A6 development with AAAA synthesis - low hum, then a slightly louder hum when asked again - A6 0 w/ AAAA synthesis - medium hum, then a slightly louder hum when asked again - AAAA deployed, A6 to experimental - larger hum, then a slightly louder hum when asked again Randy elaborated that the value of going to Experimental means anyone using A6 has a consistently specified A6 spec to use. Thomas added, we want to signal developers about our A6 shipping intentions, and how defaults are set. Bill Manning believes AAAA should be left in standards track, and A6 to experimental. - AAAA deployed, A6 to historic - medium hum The chairs judged the sense of the room that the hums indicated deploying AAAA and moving A6 to Experimental. Again, this will be taken to list to confirm. - Bit labels - - make historic - medium hum - make experimental - loud hum - keep - no hum taken due to lack of comment earlier Therefore, DNAME for bit label use is limited to experimental use of bitlabels in the reverse tree. When someone asked if the ip6.int vs ip6.arpa choice was going to be discussed, it was noted that it was out of scope for this group as it was an IAB decision. There was a brief discussion of what list the discussion should go to. Randy and Erik (our area directors in attendance) agreed it should fall under DNSEXT. and the results published to all the other lists. --- Meeting adjourned (ahead of schedule) Summary of the sense of the meeting, to be verified on mailing lists: - AAAA stays on standards track in DNSEXT, - A6 moved to experimental by DNSEXT - Bitlabels moved to experimental by DNSEXT - DNAME standardization is out scope. -end to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 11 14:16:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07949 for ; Sat, 11 Aug 2001 14:16:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Vcsh-0007KO-00 for namedroppers-data@psg.com; Sat, 11 Aug 2001 10:49:03 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Vcsh-0007KH-00 for namedroppers@ops.ietf.org; Sat, 11 Aug 2001 10:49:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Vcsh-0007yg-00 for namedroppers@ops.ietf.org; Sat, 11 Aug 2001 10:49:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Erik Guttman Reply-To: Erik Guttman To: Matt Crawford Cc: Bill Manning , namedroppers@ops.ietf.org Subject: Re: Question on Stewart's last mDNS item In-Reply-To: "Your message with ID" <200108091325.f79DPrm09624@gungnir.fnal.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 11 Aug 2001 10:49:03 -0700 Content-Transfer-Encoding: 7bit > > % Did svrloc crash & burn without me noticing? Or is there a > > % terrible gap in coverage? > > % > > If you were on the old srv-loc list, you should have seen this: > > OK, so did they or didn't they solve the problems that it > seemed like Stewrt wanted addressed in mDNS. I thought they > had, but I had tuned out ... SLP **does** solve the problem of discovering named abstract services, etc. SLPv2 was specifically designed to provide functions to obselete NetBIOS and Appletalk. A specific doc describing how to do this would probably be useful. The SVRLOC WG has concluded. There is ongoing work on a mailing list hosted by sourceforge.net. We are working toward advancing SLPv2 to draft standard. See http://www.srvloc.org Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 13 00:31:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24195 for ; Mon, 13 Aug 2001 00:31:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15W90N-000G2L-00 for namedroppers-data@psg.com; Sun, 12 Aug 2001 21:07:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15W90N-000G2F-00 for namedroppers@ops.ietf.org; Sun, 12 Aug 2001 21:07:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15W90N-000J2e-00 for namedroppers@ops.ietf.org; Sun, 12 Aug 2001 21:07:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20010813140229.C4458@connect.com.au> Date: Mon, 13 Aug 2001 14:02:29 +1000 From: Nathan Jones To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <4216.997348572@brandenburg.cs.mu.OZ.AU> In-Reply-To: ; from Bernard Aboba on Thu, Aug 09, 2001 at 08:14:18PM -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A6 supporters have spent a lot of time promoting flexibility, arguing that we shouldn't limit our options because of fear of what might happen. AAAA supporters have spent a lot of time telling us that such flexibility is not required and that possible A6 implementation problems can't be fixed just by making recommendations for DNS administrators. The debate has gone on and on, but no consensus has been reached. (I don't consider hums at London's meeting to be consensus.) Is there merit in asking the Area Directors (or possibly the IESG) for arbitration? -- nathanj Matt Crawford wrote: >Here's the problem. There was no attempt at consenus *building* after >the discussion, only a quick measurement of opinions at that point. Bernard Aboba wrote: >Rather than worrying so much about what this or that company might do, the >IETF might better spend its time and energy making clear decisions within >a reasonable timeframe. > >In many cases "no decision" is actually the worst possible decision. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 13 11:21:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21991 for ; Mon, 13 Aug 2001 11:21:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WIzz-0000WO-00 for namedroppers-data@psg.com; Mon, 13 Aug 2001 07:47:23 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15WIzy-0000WI-00 for namedroppers@ops.ietf.org; Mon, 13 Aug 2001 07:47:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15WIzy-00002d-00 for namedroppers@ops.ietf.org; Mon, 13 Aug 2001 07:47:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 13 Aug 2001 15:17:27 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Question on Stewart's last mDNS item To: Matt Crawford Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200108091032.f79AWMm08455@gungnir.fnal.gov> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Did svrloc crash & burn without me noticing? Or is there a > terrible gap in coverage? svrloc was closed a few months back. They had completed all items on their charter - which was to standardize SLP. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 13 22:12:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02830 for ; Mon, 13 Aug 2001 22:12:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WTIj-00093g-00 for namedroppers-data@psg.com; Mon, 13 Aug 2001 18:47:25 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15WTIi-00093a-00 for namedroppers@ops.ietf.org; Mon, 13 Aug 2001 18:47:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15WTIi-0005yc-00 for namedroppers@ops.ietf.org; Mon, 13 Aug 2001 18:47:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Tony Hain" To: "Nathan Jones" , , , , Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Mon, 13 Aug 2001 18:45:26 -0700 Message-ID: In-Reply-To: <20010813140229.C4458@connect.com.au> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Well I told the other chairs to let the discussion on this thread continue through today as a mechanism to allow consensus to emerge, and then I would step up and try to summarize. As Matt noted in originating the thread there was no absolutely overwhelming position by those in the room in London, but to a degree that really doesn't matter. What matters is the position of those participating in the mail lists. What the question in London did was allow the chairs and IESG observers to gauge the distinction between a few very loud voices vs. a broad based level of support, and gauge how many had a willingness to express an opinion on the subject (which from what I could tell was everyone). Nathan and Bernard have a good start to the summary, in terms of boiling down the essential viewpoints. The things I would add from the discussion include: - It is clear that we know how to make A6 resolvers deal with AAAA clients. - It appears that with current tools A6 reduces the burden of renumbering on the zone administrator. - It is not clear that renumbering will occur faster than a AAAA zone file could be resigned. - It is clear that we could evolve from AAAA to A6 later if it became necessary. Additionally: - It is clear that on either path we need better tools for DNS management. - It is also clear that address renumbering can't be solved simply through DNS magic. Shortly, an Internet-Draft will be sent to the lists that describes the rough consensus (possibly very rough) of the joint group and recommends a course of action to the IESG. For this reason it would be inappropriate for the IESG to be asked to arbitrate the creation of a recommendation to themselves. While the WG chairs are listed as authors, it is still an I-D subject to comment and editing like any other. If you feel the positions presented in the draft do not represent the collective working group opinion, speak up. Tony -----Original Message----- From: owner-ipng@sunroof.eng.sun.com = [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Nathan Jones Sent: Sunday, August 12, 2001 9:02 PM To: ngtrans@sunroof.eng.sun.com; namedroppers@ops.ietf.org; = ipng@sunroof.eng.sun.com; dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary A6 supporters have spent a lot of time promoting flexibility, arguing that we shouldn't limit our options because of fear of what might happen. AAAA supporters have spent a lot of time telling us that such flexibility is not required and that possible A6 implementation problems can't be fixed just by making recommendations for DNS administrators. The debate has gone on and on, but no consensus has been reached. (I don't consider hums at London's meeting to be consensus.) Is there merit in asking the Area Directors (or possibly the IESG) for arbitration? -- nathanj Matt Crawford wrote: >Here's the problem. There was no attempt at consenus *building* after >the discussion, only a quick measurement of opinions at that point. Bernard Aboba wrote: >Rather than worrying so much about what this or that company might do, = the >IETF might better spend its time and energy making clear decisions = within >a reasonable timeframe. > >In many cases "no decision" is actually the worst possible decision. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 13 23:07:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04430 for ; Mon, 13 Aug 2001 23:07:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WUJg-0009mH-00 for namedroppers-data@psg.com; Mon, 13 Aug 2001 19:52:28 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15WUJg-0009mB-00 for namedroppers@ops.ietf.org; Mon, 13 Aug 2001 19:52:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15WUJg-00096T-00 for namedroppers@ops.ietf.org; Mon, 13 Aug 2001 19:52:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 14 Aug 2001 02:38:06 -0000 Message-ID: <20010814023806.10986.qmail@cr.yp.to> From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010813140229.C4458@connect.com.au> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have a DNS server, a DNS cache, and a DNS client library. Current situation: (1) The server talks to caches only through IPv4. It can provide AAAA and ip6.int records, as per RFC 1123 section 6.1.3.5, but the input format is not as streamlined as the input format for A and in-addr.arpa. (2) The cache talks to servers and clients only through IPv4. It can forward AAAA records, as per RFC 1123 section 6.1.3.5, but it does not use them to locate servers. (3) The client library talks to caches only through IPv4. It doesn't include any functions related to IPv6 addresses. Plans: (1) Server: Talk to caches through IPv6. Include streamlined syntax to generate AAAA/ip6.int. (2) Cache: Talk to servers and clients through IPv6. Use AAAA records to locate servers. (3) Client library: Talk to caches through IPv6. Incorporate AAAA lookups, falling back to A. Incorporate ip6.int lookups. Things that I do _not_ plan to do: (1) A6, DNAME, bit labels, and ip6.arpa in the server. (2) A6, DNAME, bit labels, and ip6.arpa in the cache. (3) A6, DNAME, bit labels, and ip6.arpa in the client library. I want it to be crystal clear to the users that they have to set up AAAA records and ip6.int. They can't expect to be reachable if they use A6 or DNAME or ip6.arpa. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 06:55:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25902 for ; Tue, 14 Aug 2001 06:55:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WbQc-000E4o-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 03:28:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15WbQc-000E4i-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 03:28:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15WbQb-0005On-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 03:28:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tony Hain" Cc: "Nathan Jones" , , , , Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: From: Johan Ihren Date: 14 Aug 2001 11:34:12 +0200 In-Reply-To: "Tony Hain"'s message of "Mon, 13 Aug 2001 18:45:26 -0700" Message-ID: <2cr8ufkmsr.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Tony Hain" writes: > Nathan and Bernard have a good start to the summary, in > terms of boiling down the essential viewpoints. The things > I would add from the discussion include: > > - It is clear that we know how to make A6 resolvers deal with > AAAA clients. > - It appears that with current tools A6 reduces the burden of > renumbering on the zone administrator. > - It is not clear that renumbering will occur faster than a > AAAA zone file could be resigned. > - It is clear that we could evolve from AAAA to A6 later if > it became necessary. I think that such evolution will quickly move from the realm of clear possibilities to "things that simply will not happen" as the base of resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. Today it would be easy, since the resolver base is small and mostly based upon various versions of bind9 that will (all?) be upgraded to a version with AAAA synthesis built in. Tomorrow, with a large base of resolvers without that functionality, anyone who attempts to move from AAAA to A6 will literaly saw off the branch of the tree he is sitting on (from the perspective of AAAA on-lookers on the ground). On the other hand, I fully realize the issues with keeping a (mostly unused) code-path of AAAA synthesis around in the resolvers with A6 not on the standards track. All I am saying is that I think any attempt att consensus through the "we can always upgrade later" argument is bound to misfire. Johan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 06:55:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25914 for ; Tue, 14 Aug 2001 06:55:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WbRv-000E5l-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 03:29:27 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15WbRv-000E5e-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 03:29:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15WbRv-0005So-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 03:29:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 14 Aug 2001 11:34:12 +0200. <2cr8ufkmsr.fsf@snout.autonomica.se> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Tue, 14 Aug 2001 18:37:05 +0900 Message-Id: <20010814093706.4A2D47BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >I think that such evolution will quickly move from the realm of clear >possibilities to "things that simply will not happen" as the base of >resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. > >Today it would be easy, since the resolver base is small and mostly >based upon various versions of bind9 that will (all?) be upgraded to a >version with AAAA synthesis built in. the observation seems misleading to me. BIND4/8 happily serves AAAA client (over IPv4 UDP/TCP), therefore, the resolver base is already quite big for AAAA. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 06:57:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25933 for ; Tue, 14 Aug 2001 06:57:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WbVe-000E8p-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 03:33:18 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15WbVe-000E8j-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 03:33:18 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15WbVe-0005eY-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 03:33:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200108141024.f7EAOUj03215@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: johani@autonomica.se Date: Tue, 14 Aug 2001 03:24:30 -0700 (PDT) Cc: alh-ietf@tndh.net (Tony Hain), nathanj@optimo.com.au (Nathan Jones), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <2cr8ufkmsr.fsf@snout.autonomica.se> from "Johan Ihren" at Aug 14, 2001 11:34:12 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % > - It is clear that we could evolve from AAAA to A6 later if % > it became necessary. % % I think that such evolution will quickly move from the realm of clear % possibilities to "things that simply will not happen" as the base of % resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. Lets see, pretty much every resolver "shipped" since 1996 has AAAA support but does not do A4synth. One could infer that this is a fairly large base. % Today it would be easy, since the resolver base is small and mostly % based upon various versions of bind9 that will (all?) be upgraded to a % version with AAAA synthesis built in. This is a much smaller base but might be growing... at least on the server side. Of course, with the "genetic diversity" that is now present, we have a number of suppliers to consider. DJB has stated that he has no intention of supporting either A4synth or A6. % Tomorrow, with a large base of resolvers without that functionality, % anyone who attempts to move from AAAA to A6 will literaly saw off the % branch of the tree he is sitting on (from the perspective of AAAA % on-lookers on the ground). True of the adoption of any new feature. % All I am saying is that I think any attempt att consensus through the % "we can always upgrade later" argument is bound to misfire. Hum... while using this arguement to try and reach consensus may be fraught with danger, the basic premise, that the Internet is evolutionary, e.g. "we can always upgrade later" is a core concept in many peoples minds. Revolutionary techniques, e.g. flag days, non-backward compatability, etc. are much harder to float past the "powers that be". These days, such techniques tend to come from outside, and blindside the PTB, then we all have to scramble to adapt/adopt. e.g. Netscape, RealNetworks, etc. come to mind. % % Johan % -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 11:07:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06843 for ; Tue, 14 Aug 2001 11:07:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WfYz-000HFW-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 07:53:01 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15WfYz-000HFQ-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 07:53:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15WfYy-000I2R-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 07:53:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20010814221925.U4458@connect.com.au> Date: Tue, 14 Aug 2001 22:19:25 +1000 From: Nathan Jones To: Bill Manning , johani@autonomica.se Cc: Tony Hain , Nathan Jones , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2cr8ufkmsr.fsf@snout.autonomica.se> <200108141024.f7EAOUj03215@zed.isi.edu> In-Reply-To: <200108141024.f7EAOUj03215@zed.isi.edu>; from Bill Manning on Tue, Aug 14, 2001 at 03:24:30AM -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, Aug 14, 2001 at 03:24:30AM -0700, Bill Manning wrote: >% I think that such evolution will quickly move from the realm of clear >% possibilities to "things that simply will not happen" as the base of >% resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. > > Lets see, pretty much every resolver "shipped" since 1996 > has AAAA support but does not do A4synth. One could infer > that this is a fairly large base. A large base of software that handles AAAA, but not necessarily a large base of DNS administrators using AAAA records. Probably the majority of sysadmins have not yet dealt with IPv6. When they start, they will look to standards for guidance. If we leave A6 on the standards track now, it will become natural to use A6. This can drive deployment of resolvers which do AAAA synthesis. By contrast, if we remove A6 from the standards track now, then there is no incentive to implement support for AAAA synthesis. If we then turn around and say "we do need A6 after all", there is little momentum to implement and deploy A6. > Hum... while using this arguement to try and reach consensus > may be fraught with danger, the basic premise, that the Internet > is evolutionary, e.g. "we can always upgrade later" is a > core concept in many peoples minds. While "we can always upgrade later", it seems to me to be odd that we would plan it that way. If 128 bit IP addresses had been specified a year or so after IPv4 came out, would a working group then have said "we probably don't -really- need it - let's deprecate it and encourage 32 bit addresses instead"? Standards are sometimes created but not used. But at least the standard is available if a need arises. A6 is already on the standards track and people want to deprecate it before it has been given a chance. If the specification is not worthy, perhaps the "market" will decide to ignore it, but at least it is available. -- nathanj to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 11:23:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07143 for ; Tue, 14 Aug 2001 11:23:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Wfq0-000HVf-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 08:10:36 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Wfq0-000HVZ-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:10:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Wfq0-000IvD-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:10:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200108141310.f7EDAXH03576@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: nathanj@optimo.com.au (Nathan Jones) Date: Tue, 14 Aug 2001 06:10:33 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), johani@autonomica.se, alh-ietf@tndh.net (Tony Hain), nathanj@optimo.com.au (Nathan Jones), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <20010814221925.U4458@connect.com.au> from "Nathan Jones" at Aug 14, 2001 10:19:25 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % % On Tue, Aug 14, 2001 at 03:24:30AM -0700, Bill Manning wrote: % >% I think that such evolution will quickly move from the realm of clear % >% possibilities to "things that simply will not happen" as the base of % >% resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. % > % > Lets see, pretty much every resolver "shipped" since 1996 % > has AAAA support but does not do A4synth. One could infer % > that this is a fairly large base. % % A large base of software that handles AAAA, but not necessarily a % large base of DNS administrators using AAAA records. Note that Joahn mentioned resolvers and I followed up on that idea. You introduce Humans in the form of sysadmins. % Probably the majority of sysadmins have not yet dealt with IPv6. When % they start, they will look to standards for guidance. If we leave A6 % on the standards track now, it will become natural to use A6. This can % drive deployment of resolvers which do AAAA synthesis. Or they can use AAAA, also on the standards track. (this is the nub of the issue at hand, at least from here) Itojan (sp?) has an excellent draft on the experience of sysadmins who have used both AAAA and A6. The results are instructive. % By contrast, if we remove A6 from the standards track now, then there % is no incentive to implement support for AAAA synthesis. If we then % turn around and say "we do need A6 after all", there is little % momentum to implement and deploy A6. Until it gets put back on the Standards track, like SRV. % A6 is already on the standards track and people want to deprecate it before % it has been given a chance. If the specification is not worthy, perhaps % the "market" will decide to ignore it, but at least it is available. Not depricate, move to a responsible track, for now. % % -- % nathanj % -------------------------------------------------------------------- % IETF IPng Working Group Mailing List % IPng Home Page: http://playground.sun.com/ipng % FTP archive: ftp://playground.sun.com/pub/ipng % Direct all administrative requests to majordomo@sunroof.eng.sun.com % -------------------------------------------------------------------- % -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 11:25:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07175 for ; Tue, 14 Aug 2001 11:25:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Wfv9-000Hap-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 08:15:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Wfv9-000Haj-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:15:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Wfv9-000JBt-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:15:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 14 Aug 2001 15:27:04 +0200. <2cae12lql3.fsf@snout.autonomica.se> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Tue, 14 Aug 2001 22:37:49 +0900 Message-Id: <20010814133749.B56A77BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >If we look at DNS configuration for the v6 part of the world it is at >present based upon various kinds of ugliness to get around the fact >that there is almost no hierarchy deployed over v6 transport (starting >with the lack of roots accessible over v6 transport). > >The most common is to use a forwarding configuration to escape over to >the v4 transport universe with full DNS connectivity. > >*All* this will have to change over the coming years if or when or >wherever we decide to start deploying roots accessible over v6 >transport. I don't get your argument at all. Because first part of the IPv6 transition will be toward IPv4/v6 dual stack, AAAA over IPv4 transport works just fine for us. The history proves that it works fine for us - due to the lack of IPv6 accessible root, IPv6 accessible ccTLD/gTLD, and lack of IPv6 NS record registration support by many of the registries, we IPv6 users are forced to rely upon IPv4 DNS infrastructure. Luckily, it works quite well. total transition to AAAA (or A6) over IPv6 transport is of course better, however, it needs a major upgrades, including: - IPv6-ready root - IPv6-ready ccTLD and gTLD - IPv6-ready random .com servers all of them needs to be done before the total transition, so it is unrealistic to talk about total transition this time. So, what I'm saying is, AAAA deployment is already so wide enough (all BIND4/8/9 do support them okay), and for me it is way too late already to transition to anything else (including A6). If we are to transition to something other than AAAA, the transition needs to be coordinated very delicately, like transition from IPv4 to IPv6 and it will take multiple years to do so. We cannot wait any more. Think DNS transport issue (DNS over IPv6, or IPv4) and DNS payload issue (AAAA, A or A6) separately. What we are talking about is mainly the payload issue, though, it affects the deployment of the IPv6 DNS transport (as NS records need to point to AAAA, or A6). I guess you are mixing up these two. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 11:25:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07193 for ; Tue, 14 Aug 2001 11:25:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Wfty-000HZd-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 08:14:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Wftx-000HZX-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:14:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Wftx-000J81-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:14:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010814093706.4A2D47BA@starfruit.itojun.org> From: Johan Ihren Date: 14 Aug 2001 15:27:04 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Tue, 14 Aug 2001 18:37:05 +0900" Message-ID: <2cae12lql3.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino writes: > >I think that such evolution will quickly move from the realm of clear > >possibilities to "things that simply will not happen" as the base of > >resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. > > > >Today it would be easy, since the resolver base is small and mostly > >based upon various versions of bind9 that will (all?) be upgraded to a > >version with AAAA synthesis built in. > > the observation seems misleading to me. BIND4/8 happily serves AAAA > client (over IPv4 UDP/TCP), therefore, the resolver base is already > quite big for AAAA. Ahem. Let me put it this way: If we look at DNS configuration for the v6 part of the world it is at present based upon various kinds of ugliness to get around the fact that there is almost no hierarchy deployed over v6 transport (starting with the lack of roots accessible over v6 transport). The most common is to use a forwarding configuration to escape over to the v4 transport universe with full DNS connectivity. *All* this will have to change over the coming years if or when or wherever we decide to start deploying roots accessible over v6 transport. So, regardless of whether the present numbers of deployed resolvers is large or small (I think it is small compared to what we hope to have in three years, you think it is large compared to what we had three years ago, both positions are fine) it is still not a problem since their configurations will all change when v6 roots appear. However, the point of v6 root deployment is the *only* time in IPv6 history that we will be able to make such a change (push a configuration change like AAAA synthesis into all corners) which is one of several reasons why we should be (and are) so very careful before introducing v6 glue for the roots. When I talked about experimental deployment of v6 roots during dnsop in Minneapolis I was clearly overly optimistic about the timeframe. And while the A6 vs AAAA issue has been one reason for delay it is not the only concern. Johan PS. On the other hand, I do understand your argument about old bind4/8 serving AAAA over v4 transport. And, yes, the consequence is that clients on the IPv4 Internet will not find the AAAAddresses of whatever they are trying to lookup. No one said this was easy. DS. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 11:26:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07218 for ; Tue, 14 Aug 2001 11:26:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WfvM-000Hbj-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 08:16:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15WfvM-000Hbd-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:16:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15WfvM-000JCW-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:16:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Bill Manning cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108141024.f7EAOUj03215@zed.isi.edu> References: <200108141024.f7EAOUj03215@zed.isi.edu> Date: Tue, 14 Aug 2001 20:47:19 +0700 Message-ID: <15206.997796839@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 14 Aug 2001 03:24:30 -0700 (PDT) From: Bill Manning Message-ID: <200108141024.f7EAOUj03215@zed.isi.edu> | Hum... while using this arguement to try and reach consensus | may be fraught with danger, the basic premise, that the Internet | is evolutionary, e.g. "we can always upgrade later" is a | core concept in many peoples minds. It may be, but they're deluding themselves. The only plausible argument now for ignoring A6, and persisting with AAAA, is the current deployed base, and the difficulty of getting all of it upgraded, and the desire to make IPv6 "real" as soon as possible. If that's an argument to be listened to now, it can only possibly have greater and greater force as time passes and AAAA is deployed more, and used more, than the comparatively trivial amount it is now. The comment in Tony Hain's message: - It is clear that we could evolve from AAAA to A6 later if it became necessary. is not only not clear, it is simply wrong. There's no way to change such a basic part of the infrastructure once it is widely deployed. No way at all. (That is, unless "later" means next month, of course, if it is soon enough, it would still be possible - that is, it needs to happen while the 6bone is still the major long haul IPv6 net, once we have enough real v6 users that we start getting v6 real v6 infrastructure, then the time will have passed). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 11:36:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07402 for ; Tue, 14 Aug 2001 11:36:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15WfzG-000HiM-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 08:20:10 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15WfzG-000HiG-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:20:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15WfzG-000JOw-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:20:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Nathan Jones Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2cr8ufkmsr.fsf@snout.autonomica.se> <200108141024.f7EAOUj03215@zed.isi.edu> <20010814221925.U4458@connect.com.au> Message-Id: Date: Tue, 14 Aug 2001 07:57:00 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Standards are sometimes created but not used. But at least the > standard is available if a need arises. that is one of the major uses of the experimental class of rfcs, this is not the way we do it today, but if you want to do it, do it this way. then, when we need it, we pull it off experimental to standard track. for example, we are doing this with 2770 now. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 14 11:38:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07433 for ; Tue, 14 Aug 2001 11:38:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15Wfxf-000HfW-00 for namedroppers-data@psg.com; Tue, 14 Aug 2001 08:18:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15Wfxe-000HfP-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:18:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Wfxe-000JJr-00 for namedroppers@ops.ietf.org; Tue, 14 Aug 2001 08:18:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Manning Cc: nathanj@optimo.com.au (Nathan Jones), alh-ietf@tndh.net (Tony Hain), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <200108141310.f7EDAXH03576@zed.isi.edu> From: Johan Ihren Date: 14 Aug 2001 16:17:41 +0200 In-Reply-To: Bill Manning's message of "Tue, 14 Aug 2001 06:10:33 -0700 (PDT)" Message-ID: <2c66bqlo8q.fsf@snout.autonomica.se> Lines: 72 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Manning writes: > % > % On Tue, Aug 14, 2001 at 03:24:30AM -0700, Bill Manning wrote: > % >% I think that such evolution will quickly move from the realm of clear > % >% possibilities to "things that simply will not happen" as the base of > % >% resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. > % > > % > Lets see, pretty much every resolver "shipped" since 1996 > % > has AAAA support but does not do A4synth. One could infer > % > that this is a fairly large base. > % > % A large base of software that handles AAAA, but not necessarily a > % large base of DNS administrators using AAAA records. > > Note that Joahn mentioned resolvers and I followed up > on that idea. You introduce Humans in the form of sysadmins. Oops. Let's be careful with our terminology. "Resolver", to me, denotes a full-service DNS client, like the part of a recursive server that does lookups, and possibly follows A6 chains and such strange things. "Stub resolver" denotes a bare-bones subset of the resolver that is present as part of an application. I've been exclusively discussing full-service resolvers, since I believe that AAAA synthesis (in the local caching resolver aka name server) is the right solution to (among other things) the problem of *not* having to upgrade all the deployed and implemented *stub resolvers*. > % Probably the majority of sysadmins have not yet dealt with IPv6. When > % they start, they will look to standards for guidance. If we leave A6 > % on the standards track now, it will become natural to use A6. This can > % drive deployment of resolvers which do AAAA synthesis. > > Or they can use AAAA, also on the standards track. > (this is the nub of the issue at hand, at least from here) > Itojan (sp?) has an excellent draft on the experience > of sysadmins who have used both AAAA and A6. The results > are instructive. ...but it should be mentioned that many of the issues Itojun discusses are relative to implementing A6 in *stub resolvers*, which is not what I am arguing for. Another part of the document decribes various (fully valid) worries about timeouts and delays etc due to following long A6 chains that extend beyond the organizational border into the unknown territory of the ISP and beyond (above?). I think that this is perhaps not the only perspective since a clueful leaf node is not the main problem here. A possibly more interesting perspective would be that of a clueful central organisation with lots of delegated prefixes in various directions. I also think that perspective is posibly more valid, since statistically the amount of clue goes down as you move down the delegation chain. The problem then becomes one of "how do I propagate this need to change the prefix" recursively down all these delegations and into whatever tools and scripts they have decided to use for zone management and no longer even know how they work. With A6 this particular sub-part of the renumbering problem becomes a non-issue. Not so with AAAA. Not even close. Johan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:07:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21368 for ; Wed, 15 Aug 2001 10:07:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X0ul-000Ict-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 06:40:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X0ul-000Icn-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 06:40:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X0ul-0001HG-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 06:40:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> Date: Tue, 14 Aug 2001 22:55:37 -0700 To: Robert Elz From: Alain Durand Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org In-Reply-To: <15663.997800535@brandenburg.cs.mu.OZ.AU> References: <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 09:48 PM 8/14/2001 +0700, Robert Elz wrote: > >No, assuming you're right, long term what will happen is that people >will lament that the wrong decision was made in 2001, but regret that >there's no way to transition any more, the combination of resolvers >doing only AAAA lookups, and servers providing only AAAA records, means >there's no clean way to get out from under (sure, servers could provide >A6 records as well, but they'll have to keep providing AAAA records >forever to keep the old resolvers happy, and resolvers could do A6 lookups >but they'd have to fall back on doing AAAA so they can find names that >are only available that way - given that AAAA would have to remain, and >resolvers would have to do lookups of it, just for practical reasons, >there's no way to actually transition to A6). Doing AAAA synthesis at the resolver side helps a stub resolver that knows only about AAAA to get data from servers that knows only about A6. This transition scenario will work if we can upgrade the resolvers at the same time we introduce A6 in the servers. (note that upgrading the resolvers is a much simpler task than upgrading all the stub resolvers) Still, it may not be possible to upgrade them all before we introduce A6 in some servers. So what you are highlighting is the need for servers that are populated with A6 to answer resolvers (not stub-resolver) that know only about AAAA. Of course, as you mentioned, servers could be manually populated with AAAA at well as A6, but there are other possibilities. In other words, we have to explore AAAA synthesis done at the server side: - the server could automatically generate all the corresponding AAAA records when loading its A6 database. Of course, the missing pieces will have to be provided. - the server could generate AAAA on request. Of course, there are drawbacks and issues with such mechanisms and more study will have to be made to understand them, but they are transition mechanism and as such, do not need to be perfect. The point i'm trying to make is that by combining AAAA synthesis at the server side with AAAA synthesis at the resolver side, we may have a way to transition from an all AAAA world to a world with a mix of AAAA and A6 if/when we need it. Note also that such techniques would have to be used now if we decided to move to A6 today. - Alain. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:26:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22070 for ; Wed, 15 Aug 2001 10:26:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1Ms-000JBP-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:09:58 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1Ms-000JBJ-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:09:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1Ms-0002hE-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:09:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 15 Aug 2001 09:34:23 +0200. <2czo91kc8w.fsf@snout.autonomica.se> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 17:57:32 +0900 Message-Id: <20010815085732.742B37BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >I'm pointing out that due to the configuration change that will follow >from deployment of v6 roots it will be comparatively easy to reach all >the caching resolvers (i.e. name servers) on v6 transport to ensure >that they all do AAAA synthesis. isn't it just a root.hint change, not a server replacement? as I have pointed out repeatedly, AAAA synthesis has its own problems and I don't feel like deploying it. (1) A6 chasing is traffic multiplication = DoS possibility (recursive servers), (2) it is unclear as to how will be doing AAAA synthesis, and we cannot ensure that it will happen at the leaf (3) by deploying AAAA synthesis you end up maintaining both A6 and AAAA: (3a) impose lookup delays to IPv6 clients. (3b) server admins need to maintain both A6 and AAAA in zoen file, which is unhappy. >However, while agreeing that the deployed base of AAAA-aware caching >resolvers on the IPv4-only Internet is large it is less clear to me >how many of those actually care about v6 address records at all. Nor >is it clear how many of those that will start to care before having >upgraded their name server software (which contrary to popular belief >actually happens, although certainly not to all of them). a lot of them do care about AAAA records, since IPv6 people are forced to use IPv4 infrastructure. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:26:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22081 for ; Wed, 15 Aug 2001 10:26:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1Ng-000JCX-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:10:48 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1Nf-000JCN-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:10:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1Nf-0002jg-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:10:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010815085732.742B37BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 11:57:01 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 17:57:32 +0900" Message-ID: <2cpu9xk5n6.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino writes: Hi Itojun, > >I'm pointing out that due to the configuration change that will follow > >from deployment of v6 roots it will be comparatively easy to reach all > >the caching resolvers (i.e. name servers) on v6 transport to ensure > >that they all do AAAA synthesis. > > isn't it just a root.hint change, not a server replacement? Well, if you are running in a forwarding configuration *with your present server* and replace the root.hint file with one that includes v6 glue for one or several roots not much will happen. So there is no point to it. Because you are using a forwarding configuration. However, what you want is a root accessible over v6 transport (and of course all the TLDs, etc, etc) so that you can move away from your forwarding configuration. However, to avoid walking around in a barren wasteland of almost no DNS hierarchy initially I strongly suspect that you would like some sort of fallback mechanism so that you can still get to the data that is presently only available over v4 transport. But to do that you *will* need a server replacement, since no server deployed does that today. There are various icky schemes for doing such transport bridging (Alain Durand and I have spent some time in that mess and there is a draft outlining some of the problems). All of these schemes are ugly, but without something like that I see little point to the v6 roots that you want. So, I still claim that the time of deployment of v6 glue for the first root is a "magic date" since that will initiate a configuration change and in all likelihood a server replacement for all the v6 caching resolvers that want to utilize this v6 root for anything useful. Look at it as a synchronization barrier for IPv6 DNS functionality. Johan Ihren to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:30:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22230 for ; Wed, 15 Aug 2001 10:30:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1MM-000JA6-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:09:26 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1MM-000JA0-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:09:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1MM-0002fZ-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:09:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010814133749.B56A77BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 09:34:23 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Tue, 14 Aug 2001 22:37:49 +0900" Message-ID: <2czo91kc8w.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino writes: > >If we look at DNS configuration for the v6 part of the world it is at > >present based upon various kinds of ugliness to get around the fact > >that there is almost no hierarchy deployed over v6 transport (starting > >with the lack of roots accessible over v6 transport). > > > >The most common is to use a forwarding configuration to escape over to > >the v4 transport universe with full DNS connectivity. > > > >*All* this will have to change over the coming years if or when or > >wherever we decide to start deploying roots accessible over v6 > >transport. > > I don't get your argument at all. > > Because first part of the IPv6 transition will be toward IPv4/v6 > dual stack, AAAA over IPv4 transport works just fine for us. > The history proves that it works fine for us - due to the lack of > IPv6 accessible root, IPv6 accessible ccTLD/gTLD, and lack of IPv6 > NS record registration support by many of the registries, we IPv6 > users are forced to rely upon IPv4 DNS infrastructure. Luckily, > it works quite well. > > total transition to AAAA (or A6) over IPv6 transport is of course > better, however, it needs a major upgrades, including: > - IPv6-ready root > - IPv6-ready ccTLD and gTLD > - IPv6-ready random .com servers > all of them needs to be done before the total transition, so it is > unrealistic to talk about total transition this time. > > So, what I'm saying is, AAAA deployment is already so wide enough > (all BIND4/8/9 do support them okay), and for me it is way too late > already to transition to anything else (including A6). If we are > to transition to something other than AAAA, the transition needs to > be coordinated very delicately, like transition from IPv4 to IPv6 > and it will take multiple years to do so. We cannot wait any more. > > Think DNS transport issue (DNS over IPv6, or IPv4) and DNS payload > issue (AAAA, A or A6) separately. What we are talking about is > mainly the payload issue, though, it affects the deployment of > the IPv6 DNS transport (as NS records need to point to AAAA, or A6). > I guess you are mixing up these two. No, I am not mixing them up. I'm pointing out that due to the configuration change that will follow from deployment of v6 roots it will be comparatively easy to reach all the caching resolvers (i.e. name servers) on v6 transport to ensure that they all do AAAA synthesis. I agree that this will not by itself help the deployed base of AAAA-aware, A6-ignorant caching resolvers that are v4 single stack. Furthermore there are obvious problems with doing AAAA synthesis in response to non-recursive AAAA queries, so we cannot shield those servers easily by doing the synthesis in the authoritative end. However, while agreeing that the deployed base of AAAA-aware caching resolvers on the IPv4-only Internet is large it is less clear to me how many of those actually care about v6 address records at all. Nor is it clear how many of those that will start to care before having upgraded their name server software (which contrary to popular belief actually happens, although certainly not to all of them). It is certainly a non-trivial number, but as Bill touched upon, somewhere there is a price to evolution, and I much rather have it there (among v4-only servers not caring about v6) than tying the hands of people that care very much about IPv6. Johan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:31:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22253 for ; Wed, 15 Aug 2001 10:31:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1QU-000JH5-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:13:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1QT-000JGz-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:13:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1QT-0002sK-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:13:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Alain Durand cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> Date: Wed, 15 Aug 2001 17:00:43 +0700 Message-ID: <2361.997869643@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 14 Aug 2001 22:55:37 -0700 From: Alain Durand Message-ID: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> | Doing AAAA synthesis at the resolver side helps a stub resolver that | knows only about AAAA to get data from servers that knows only about A6. yes, sure. | This transition scenario will work if we can upgrade the resolvers | at the same time we introduce A6 in the servers. (note that upgrading | the resolvers is a much simpler task than upgrading all the stub resolvers) It would work if we did it now. There's no way we can ever upgrade all the resolvers (the real resolvers, the back ends) once IPv6 becomes mainstream. Just imagine now that you wanted to upgrade all the IPv4 resolvers (back end resolvers) - there's simply no way. When IPv6 starts being deployed the net will be able to grow faster than it has, it is going to be lots bigger 5 years from now than it is now. Upgrading anything that requires everyone to upgrade anything at all will simply be impossible. | Still, it may not be possible to upgrade them all before we introduce A6 | in some servers. Actually, it would probably be easier the other way. Adding anything in zone files requires deliberate administrator effort. People will only do that if there's a benefit. On the other hand, AAAA synthesis can be slipped in along with other changes in back end resolvers, so that people (some people) would have it without really even realising it. Some people have it now without realising it... But there's no way to get everyone to have it - which means that administrators will always have to add AAAA records so those people can find their web server, mail server, .... And if AAAA records have to exist, and resolvers will be looking for them (because no way are all servers going to start supplying A6 all at once, even with a fairly broad concept of the time quantum) then there's no point adding A6 records at all - they'd be just one more thing that has to be maintained (excess duplicate data). Further, they wouldn't help do anything, as the AAAA records are still all going to be there. If there's a problem that A6 would be useful to solve, then what will happen is that people will find some hack that allows it to be solved using AAAA instead, as AAAA will be what exists. If you want examples of this, look at Mobile IP - which has a whole mechanism all created, with packet forwarding via home agents, and stuff, all because there's simply no way to upgrade TCP stacks to allow the identifier of a connection to be changed (not even with enough security added to make the change secure). Not even given that only major servers really would need that upgrade (and mobile nodes of course, which need upgraded code anyway). Rather than upgrading TCP, we invent a hack to work around the fact that TCP simply cannot be upgraded. Or, look at IDN, which is doing obscene things to the DNS, to work around the fact that it is impossible to upgrade all the old mailers (etc) to handle arbitrary (non-ascii) domain names. Rather than fix the problem where it ought to be fixed, hacks are done in other places - because there is simply no practical way to get the upgrade done that people are willing to live with (me: I'd just break all the old mailers, etc, and tell people to upgrade if they'll ever receive/send mail to a domain with a non-ascii name, but most people aren't willing to do that). | So what you are highlighting is the need for servers | that are populated with A6 to answer resolvers (not stub-resolver) | that know only about AAAA. No. What I was highlighting is that if AAAA is nominated now as the way that we go, then AAAA is it for eternity. Pretending that we might sometime later upgrade to A6 if it seemed to be a better idea is no more than an attempt to handle people who think "A6 probably is better, but it isn't deployed yet - let's go with what we have now so we can make it happen, then we'll upgrade later". Pretend that the upgrade can happen, and selecting AAAA now doesn't seem so bad. It cannot happen - net wide infrastructure upgrades are close to impossible (for them to be even worth considering, the rationale has to be more than compelling, there must be no other choice - for A6, or mobile IP, or IDN, or anything else like that, there's always going to be some other way than the right way). | Of course, as you mentioned, servers could be manually populated with AAAA | at well as A6, but there are other possibilities. In other words, we have | to explore AAAA synthesis done at the server side: If we were to make the change now, then yes, that's exactly what we should be doing. Now there isn't enough deployment to make it all that hard. For the next 6 months or so (maybe even longer if IPv6 takeup remains slow) we'll still have that option. But not much further away. | - the server could automatically generate all the corresponding AAAA records | when loading its A6 database. Yes. I'd actually thought of making a hack to bind9 that would convert all AAAA records into A6 0, and supplying only A6 whatever the admin configured into the zone file... | The point i'm trying to make is that by combining AAAA synthesis | at the server side with AAAA synthesis at the resolver side, we | may have a way to transition from an all AAAA world to a world | with a mix of AAAA and A6 if/when we need it. We have a way to do it now, or soon. There's no way that it can ever be made to happen once we get wide deployment. Expecting it is just fantasy. eg: now the DNS has SRV records, they do so everything that MX can do, and more. In a way they're the analog of A6 and AAAA (MX is a subset of SRV). There would be benefits to converting SMTP to use SRV instead of MX. Can you imagine anyone seriously suggesting that that happen however? Can you really imagine that there'd ever be a day when we could deprecate the MX record? | Note also that such techniques would have to be used now if we decided | to move to A6 today. Yes, sure. Though it is also possible that AAAA synthesis would never be a transition technique, but rather a permanent part of the way things work (even if we decided that we wanted to move away from it, and there probably wouldn't be much reason, there'd be no way to ever upgrade all the clients, so back end resolvers would always need to provide it, so new clients may as well just use the service that they know will be there...) kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:32:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22322 for ; Wed, 15 Aug 2001 10:32:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1RK-000JJB-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:14:34 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1RK-000JJ5-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:14:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1RK-0002uw-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:14:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 15 Aug 2001 03:21:35 -0700 From: David Terrell To: Robert Elz Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010815032134.A1896@pianosa.catch22.org> References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <2361.997869643@brandenburg.cs.mu.OZ.AU> In-Reply-To: <2361.997869643@brandenburg.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Wed, Aug 15, 2001 at 05:00:43PM +0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, Aug 15, 2001 at 05:00:43PM +0700, Robert Elz wrote: > | Still, it may not be possible to upgrade them all before we introduce A6 > | in some servers. > > Actually, it would probably be easier the other way. Adding > anything in zone files requires deliberate administrator effort. > People will only do that if there's a benefit. On the other hand, > AAAA synthesis can be slipped in along with other changes in back > end resolvers, so that people (some people) would have it without > really even realising it. Some people have it now without realising > it... > But there's no way to get everyone to have it - which means that > administrators will always have to add AAAA records so those people > can find their web server, mail server, .... And if AAAA records > have to exist, and resolvers will be looking for them (because no > way are all servers going to start supplying A6 all at once, even > with a fairly broad concept of the time quantum) then there's no > point adding A6 records at all - they'd be just one more thing that > has to be maintained (excess duplicate data). There's no reason why it can't be a gradual upgrade. Authoritative servers for zones with A6 can do AAAA synthesis at query time just as easily as the local non-stub resolver can. It becomes a server-side indirection mechanism, which is available to A6-grokking caches. Considering that like it or not A) BIND is still a majority of nameservers, B) bind9 is the first version to support v6 transport and C) I don't imagine Nominum/ISC/"The BIND Company" removing A6 support just because it's not "the thing", this feature is basically already present today. ISPs can provide A6 prefix records for their customers, those customers can use A6 chains to point to their ISPs and do authoritative server-side AAAA synthesis (well, ok, bind needs to add this I guess), and most people can go on using AAAA and be happy. I'm squarely in the "Let's take AAAA because it works and let's get IPv6 off the ground" camp. -- David Terrell | p = "you are nasty" q = "my first name is Janet" Nebcorp PM | r = "my first name is baby" s = "My name is Miss Jackson" dbt@meat.net | (!r -> q) & (p -> s) - Braverman's Third Lemma wwn.nebcorp.com | !r & (!p -> q) & (p -> s) - Libor's Corollary to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:33:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22370 for ; Wed, 15 Aug 2001 10:33:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1UW-000JQ2-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:17:52 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1UW-000JPv-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:17:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1UV-00034t-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:17:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Jun-ichiro itojun Hagino cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010815085732.742B37BA@starfruit.itojun.org> References: <20010815085732.742B37BA@starfruit.itojun.org> Date: Wed, 15 Aug 2001 18:16:22 +0700 Message-ID: <2674.997874182@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 15 Aug 2001 17:57:32 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20010815085732.742B37BA@starfruit.itojun.org> | (1) A6 chasing is traffic multiplication = DoS possibility (recursive | servers), That has nothing at all to do with AAAA synthesis - it is an argument against A6 in general, but a very weak one. A site that wants to avoid this with A6 can easily avoid it. A site that wants to create lots of traffic with lookups can easily create it with AAAA (just add a few CNAMEs going into other domains...) A6 adds one more opportunity for people to configure things badly, but nothing at all new. | (2) it is unclear as to how will be doing AAAA synthesis, and we cannot | ensure that it will happen at the leaf Who cares? If someone asks for an AAAA, and gets back an AAAA, then they're happy right? If the server provided an A6, was asked for an A6, and answered with an A6, it is happy, right? Something between original (probably stub) resolver and server converted. Who cares what it was? The operators of the resolver might care - for lots of reasons, in which case they provide the back end resolver that does the synthesis. | (3) by deploying AAAA synthesis you end up maintaining both A6 and AAAA: No, exactly the opposite, you end up maintaining A6 only. The AAAA RR type remains in use, but that's no work for anyone. Actual AAAA records remain in zone files only long enough for the current (small) infrastructure to be mostly upgraded (so that it has back end resolvers in enough places). Once a fair proportion has that installed, the AAAA records simply get yanked from everywhere. That provides the incentive for everyone else to install a capable back end. | (3a) impose lookup delays to IPv6 clients. No, no delays at all (other than what is involved in the A6 lookup). | (3b) server admins need to maintain both A6 and AAAA in zoen file, | which is unhappy. No, only A6 records, that's what AAAA synthesis is all about, remember... kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:34:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22387 for ; Wed, 15 Aug 2001 10:34:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1Qt-000JIO-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:14:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1Qt-000JIH-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:14:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1Qt-0002ta-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:14:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 15 Aug 2001 11:57:01 +0200. <2cpu9xk5n6.fsf@snout.autonomica.se> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 19:08:52 +0900 Message-Id: <20010815100852.480907BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> >I'm pointing out that due to the configuration change that will follow >> >from deployment of v6 roots it will be comparatively easy to reach all >> >the caching resolvers (i.e. name servers) on v6 transport to ensure >> >that they all do AAAA synthesis. >> isn't it just a root.hint change, not a server replacement? >Well, if you are running in a forwarding configuration *with your >present server* and replace the root.hint file with one that includes >v6 glue for one or several roots not much will happen. So there is no >point to it. > >Because you are using a forwarding configuration. I don't understand what you are saying, AT ALL. I'm not using forwarding configuration. you must have some assumption in your head which is not presented here. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:36:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22462 for ; Wed, 15 Aug 2001 10:36:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1X5-000JUa-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:20:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1X4-000JUT-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:20:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1X4-0003Cg-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:20:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010815100852.480907BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 13:27:07 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 19:08:52 +0900" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino writes: > >> >I'm pointing out that due to the configuration change that will follow > >> >from deployment of v6 roots it will be comparatively easy to reach all > >> >the caching resolvers (i.e. name servers) on v6 transport to ensure > >> >that they all do AAAA synthesis. > >> isn't it just a root.hint change, not a server replacement? > >Well, if you are running in a forwarding configuration *with your > >present server* and replace the root.hint file with one that includes > >v6 glue for one or several roots not much will happen. So there is no > >point to it. > > > >Because you are using a forwarding configuration. > > I don't understand what you are saying, AT ALL. I'm not using > forwarding configuration. you must have some assumption in > your head which is not presented here. Ok. Before I repeat the mistake of guessing at your configuration I suggest you tell me about it. Personally I use a forwarding config for v6-only nameservers and I believe that this is by far the most common case. Johan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:39:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22531 for ; Wed, 15 Aug 2001 10:39:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1Rz-000JKv-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:15:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1Ry-000JKo-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:15:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1Ry-0002x5-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:15:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: David Terrell Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <2361.997869643@brandenburg.cs.mu.OZ.AU> <20010815032134.A1896@pianosa.catch22.org> From: Johan Ihren Date: 15 Aug 2001 12:30:37 +0200 In-Reply-To: David Terrell's message of "Wed, 15 Aug 2001 03:21:35 -0700" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit David Terrell writes: > > But there's no way to get everyone to have it - which means that > > administrators will always have to add AAAA records so those people > > can find their web server, mail server, .... And if AAAA records > > have to exist, and resolvers will be looking for them (because no > > way are all servers going to start supplying A6 all at once, even > > with a fairly broad concept of the time quantum) then there's no > > point adding A6 records at all - they'd be just one more thing that > > has to be maintained (excess duplicate data). > > There's no reason why it can't be a gradual upgrade. Authoritative > servers for zones with A6 can do AAAA synthesis at query time just > as easily as the local non-stub resolver can. It becomes a server-side > indirection mechanism, which is available to A6-grokking caches. This is *wrong*. An authoritative, non-recursive server with only A6 fragments around can not synthesise the AAAA since that would require it to query for missing fragments. Johan Ihren to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:40:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22591 for ; Wed, 15 Aug 2001 10:40:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1cL-000JhZ-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:25:57 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1cL-000JhR-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:25:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1cL-0003TU-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:25:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: kre's message of Wed, 15 Aug 2001 19:30:28 +0700. <2962.997878628@brandenburg.cs.mu.OZ.AU> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 21:34:11 +0900 Message-Id: <20010815123411.E40457BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | you should care about this. >Why? > | there's no guarantee that AAAA synthesis > | happen between end client and master/slave nameservers. AAAA will > | leak from leaf to the core. >Yes. That doesn't tell me why I need to care. People send queries >for all kinds of RR types that I don't have in my zone files, my >servers return NO DATA responses (no error, no answer). Perfectly >normal. That's what is likely to happen if they request an AAAA and >all I have is A6. (Just maybe I'll do AAAA synthesis for random people >in the very early days). > >Exactly why is this a problem to care about? we (pick any community i'm involved with) are already operating AAAA in a lot of places. we need to keep those configuration to work fine while we migrate to A6 + AAAA synthesis. we have serious users of IPv6 using AAAA, and we cannot break their configuration, nor transition them into some other record type in one night. you have been proposing a migration path with a hard "flag day", with: - all existing zone files must be rewritten to from AAAA to A6 in one night (of which timezone?) - all AAAA queriers can stay as is, but there has to be AAAA synthesis server at every leaf - no AAAA traffic in core DNS cloud, only A6 traffic. this is totally unacceptable to us. the story applies only if we are going to move to A6 + AAAA synthesis. if we don't migrate, we have no worry and everyone is happy. itojun@tired. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:40:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22607 for ; Wed, 15 Aug 2001 10:40:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1bw-000Jfx-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:25:32 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1bv-000Jfq-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:25:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1bv-0003S4-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:25:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: kre's message of Wed, 15 Aug 2001 19:30:28 +0700. <2962.997878628@brandenburg.cs.mu.OZ.AU> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 21:34:11 +0900 Message-Id: <20010815123411.E40457BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | you should care about this. >Why? > | there's no guarantee that AAAA synthesis > | happen between end client and master/slave nameservers. AAAA will > | leak from leaf to the core. >Yes. That doesn't tell me why I need to care. People send queries >for all kinds of RR types that I don't have in my zone files, my >servers return NO DATA responses (no error, no answer). Perfectly >normal. That's what is likely to happen if they request an AAAA and >all I have is A6. (Just maybe I'll do AAAA synthesis for random people >in the very early days). > >Exactly why is this a problem to care about? we (pick any community i'm involved with) are already operating AAAA in a lot of places. we need to keep those configuration to work fine while we migrate to A6 + AAAA synthesis. we have serious users of IPv6 using AAAA, and we cannot break their configuration, nor transition them into some other record type in one night. you have been proposing a migration path with a hard "flag day", with: - all existing zone files must be rewritten to from AAAA to A6 in one night (of which timezone?) - all AAAA queriers can stay as is, but there has to be AAAA synthesis server at every leaf - no AAAA traffic in core DNS cloud, only A6 traffic. this is totally unacceptable to us. the story applies only if we are going to move to A6 + AAAA synthesis. if we don't migrate, we have no worry and everyone is happy. itojun@tired. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:41:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22622 for ; Wed, 15 Aug 2001 10:41:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1eJ-000Jmd-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:27:59 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1eI-000JmX-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:27:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1eI-0003aG-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:27:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Nathan Jones Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: njones's message of Wed, 15 Aug 2001 22:54:28 +1000. <20010815225428.A11162@connect.com.au> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 21:49:58 +0900 Message-Id: <20010815124958.E27BE7BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> you seem to be assuming that there's some AAAA synthesis server >> between IPv6 end node and nameservers. your assumption does not hold, >> especially during the transition period. because the assumption >> does not hold, zone admins need to maintain AAAA records too. >It is only during the transition period that this assumption does not >hold true. The result of the transition is that there is an AAAA synth >server between the IPv6 end node and the nameserver. It is only during >the transition that AAAA records will be maintained alongside A6 records. how long do you think it will take, and how many people do you think get bitten by this? itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:41:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22633 for ; Wed, 15 Aug 2001 10:41:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1b9-000Jdc-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:24:43 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1b9-000JdW-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:24:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1b9-0003Pd-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:24:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Jun-ichiro itojun Hagino cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010815114010.CA9C17BA@starfruit.itojun.org> References: <20010815114010.CA9C17BA@starfruit.itojun.org> Date: Wed, 15 Aug 2001 19:30:28 +0700 Message-ID: <2962.997878628@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 15 Aug 2001 20:40:10 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20010815114010.CA9C17BA@starfruit.itojun.org> | you should care about this. Why? | there's no guarantee that AAAA synthesis | happen between end client and master/slave nameservers. AAAA will | leak from leaf to the core. Yes. That doesn't tell me why I need to care. People send queries for all kinds of RR types that I don't have in my zone files, my servers return NO DATA responses (no error, no answer). Perfectly normal. That's what is likely to happen if they request an AAAA and all I have is A6. (Just maybe I'll do AAAA synthesis for random people in the very early days). Exactly why is this a problem to care about? | if people query both AAAA and A6, there will be more delays. Yes, so they shouldn't. End nodes can do AAAA to their back end. The back end should do A6 only, and synthesise the AAAA. No extra delays. | you seem to be assuming that there's some AAAA synthesis server | between IPv6 end node and nameservers. your assumption does not hold, | especially during the transition period. Right now it doesn't, no, it will take a little while to get them installed everywhere if we decide on A6 now. | because the assumption | does not hold, zone admins need to maintain AAAA records too. No, I can use A records as backup. They backup both the peers that only know about AAAA, and the ones that don't know IPv6 at all. We all agree that IPv4 is still going to be needed for a while yet, so it is just fine with me if peers who cannot handle A6 at all simply use IPv4. That will work. If the remote end wants to use IPv6, then it can install a synthesis server for its AAAA only nodes, and the A6 records will work fine. We can do this, because right now IPv4 works, and is a backup that we need to have anyway - so it is just fine to simply toss out all the AAAA records and replace them with A6. Nothing is going to break because of that. We won't be able to do that when we start getting native IPv6 nets though, which is why if this change is ever to be made, it needs to be made very soon - otherwise never. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:41:12 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22646 for ; Wed, 15 Aug 2001 10:41:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1aH-000Jbe-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:23:49 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1aH-000JbY-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:23:49 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1aH-0003Mp-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:23:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: kre's message of Wed, 15 Aug 2001 18:16:22 +0700. <2674.997874182@brandenburg.cs.mu.OZ.AU> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 20:40:10 +0900 Message-Id: <20010815114010.CA9C17BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | (2) it is unclear as to how will be doing AAAA synthesis, and we cannot > | ensure that it will happen at the leaf >Who cares? If someone asks for an AAAA, and gets back an AAAA, then >they're happy right? If the server provided an A6, was asked for an >A6, and answered with an A6, it is happy, right? Something between >original (probably stub) resolver and server converted. Who cares >what it was? >The operators of the resolver might care - for lots of reasons, in which >case they provide the back end resolver that does the synthesis. you should care about this. there's no guarantee that AAAA synthesis happen between end client and master/slave nameservers. AAAA will leak from leaf to the core. > | (3a) impose lookup delays to IPv6 clients. >No, no delays at all (other than what is involved in the A6 lookup). if people query both AAAA and A6, there will be more delays. > | (3b) server admins need to maintain both A6 and AAAA in zoen file, > | which is unhappy. >No, only A6 records, that's what AAAA synthesis is all about, remember... you seem to be assuming that there's some AAAA synthesis server between IPv6 end node and nameservers. your assumption does not hold, especially during the transition period. because the assumption does not hold, zone admins need to maintain AAAA records too. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:41:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22675 for ; Wed, 15 Aug 2001 10:41:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1a5-000JbE-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:23:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1a4-000Jb8-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:23:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1a4-0003MC-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:23:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 15 Aug 2001 13:27:07 +0200. <2chev9k1h0.fsf@snout.autonomica.se> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 20:36:09 +0900 Message-Id: <20010815113609.84BB87BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I don't understand what you are saying, AT ALL. I'm not using >> forwarding configuration. you must have some assumption in >> your head which is not presented here. > >Ok. Before I repeat the mistake of guessing at your configuration I >suggest you tell me about it. > >Personally I use a forwarding config for v6-only nameservers and I >believe that this is by far the most common case. I have been talking about a nameserver, with root.hint, on IPv4/v6 dual stack machine. to be more precise, see below. I never have talked about nameservers on IPv6-only machine, they will never work without some help from IPv4/v6 dual stack nameserver. (and it is rather unrealistic to talk about nameeservers in IPv6-only network today...) itojun --- # $NetBSD: named.conf,v 1.5 2000/03/01 11:06:29 itojun Exp $ # boot file for secondary name server # Note that there should be one primary entry for each SOA record. options { directory "/etc/namedb"; listen-on-v6 { any; }; }; zone "." { type hint; file "root.cache"; }; zone "localhost" { type master; file "localhost"; }; zone "127.IN-ADDR.ARPA" { type master; file "127"; }; to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:42:04 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22691 for ; Wed, 15 Aug 2001 10:42:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1eZ-000JnP-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:28:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1eY-000JnJ-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:28:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1eY-0003b8-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:28:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20010815225428.A11162@connect.com.au> Date: Wed, 15 Aug 2001 22:54:28 +1000 From: Nathan Jones To: Jun-ichiro itojun Hagino , Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2674.997874182@brandenburg.cs.mu.OZ.AU> <20010815114010.CA9C17BA@starfruit.itojun.org> In-Reply-To: <20010815114010.CA9C17BA@starfruit.itojun.org>; from Jun-ichiro itojun Hagino on Wed, Aug 15, 2001 at 08:40:10PM +0900 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun wrote: > you should care about this. there's no guarantee that AAAA synthesis > happen between end client and master/slave nameservers. AAAA will > leak from leaf to the core. David Terrell's suggestion that AAAA synth be performed by nameservers which are authoritative for zones with A6 data seems worth considering here. DNS admins can then use A6 without fear that their hosts will not be found. Over time, the authoritative nameserver will not have to synthesise AAAA records as frequently, as it will receive more requests for A6 RRs. This increase in A6 requests will come from the normal uptake of resolvers that support A6 and perform AAAA synth for the remaining base of non-A6 stub resolvers. > if people query both AAAA and A6, there will be more delays. People won't always query both RR types. The idea of transition is to move to A6; once there is wide spread use of A6 records and resolvers that query for A6 records, there won't be frequent querying for both. >> | (3b) server admins need to maintain both A6 and AAAA in zoen file, >> | which is unhappy. >>No, only A6 records, that's what AAAA synthesis is all about, remember... > > you seem to be assuming that there's some AAAA synthesis server > between IPv6 end node and nameservers. your assumption does not hold, > especially during the transition period. because the assumption > does not hold, zone admins need to maintain AAAA records too. It is only during the transition period that this assumption does not hold true. The result of the transition is that there is an AAAA synth server between the IPv6 end node and the nameserver. It is only during the transition that AAAA records will be maintained alongside A6 records. (And once again, if you run a nameserver that can do AAAA synth, then you don't even need to maintain AAAA records too.) Lastly, there seems to be a number of people here supporting A6 in principle, but saying that we should shelve the idea now and consider it later. Surely it is preferable to follow those principles now, rather than putting the idea in the "too hard basket"... -- njones to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:42:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22706 for ; Wed, 15 Aug 2001 10:42:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1g6-000Js4-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:29:50 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1g6-000Jry-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:29:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1g6-0003fl-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:29:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010815113609.84BB87BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 15:16:12 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 20:36:09 +0900" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino writes: > >Ok. Before I repeat the mistake of guessing at your configuration I > >suggest you tell me about it. > > > >Personally I use a forwarding config for v6-only nameservers and I > >believe that this is by far the most common case. > > I have been talking about a nameserver, with root.hint, on > IPv4/v6 dual stack machine. to be more precise, see below. > > I never have talked about nameservers on IPv6-only machine, > they will never work without some help from IPv4/v6 dual stack > nameserver. (and it is rather unrealistic to talk about > nameeservers in IPv6-only network today...) Ok, we were clearly talking about different things. And this further clarifies the initial difference in opinion on the size of the deployed base of full-service resolvers that are IPv6-aware and -caring. The issue with roots available over v6 transport was mostly a side track that was relevant only for the subset of full-service resolvers that are v6-only. As to whether it is unrealistic to talk about name servers on IPv6-only networks or not, I still argue that although they are a small base today (which we now agree upon) they will be the dominant species at some point in the future. And now is the time we have to decide how the world they will populate should work. But the core issue is still whether it is too late to upgrade the deployed full-service resolvers to do AAAA synthesis or not. And if not too late then how long it will take. I think that given a clear decision (which seems impossible) this could be fairly rapid for the full-service resolvers that actually see real traffic since they are almost certainly to a large degree waiting for the outcome of this A6/AAAA commotion. And given A6, that would not delay deployment [of IPv6], since new deployment would have the benefit of doing it right [i.e. A6] from the outset thereby rapidly creating even more incentive for the installed base (i.e. the dual-stack or forwarding servers, all of them bind9) to upgrade. It is important to weigh in the difficulties of pushing a deployed base to upgrade. But in this particular case I worry that that problem unnecessarily may be overshadowing the design issues. Anyone that presently operate a dual-stack server or a forwarding server with only v6 transport and isn't aware that there are unsolved problems with DNS for IPv6 and that it will in all likelihood be necessary to change configs/upgrade software/modify tools/etc is not really on top of his or her responsibilities. Fortunately, since we are still in the early days, I really think they constitute a small minority. The rest, regardless of their position on the A6/AAAA issue, are at least fully aware that such issues *exist* and hence aware that they will possibly have to change stuff somewhat as those issues get resolved. The v4-only-dont-care-about-v6-although- their-resolver-groks-aaaa is a different story, but I care less about breaking lookups of v6 records for them. So, to my mind, A6 would not necessarily delay deployment of IPv6 significantly. What is clearly delaying deployment is lack of consensus. But I don't know. It has to be a judgement call. Johan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:47:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22794 for ; Wed, 15 Aug 2001 10:47:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1k0-000K4l-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:33:52 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1jz-000K4e-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:33:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1jz-0003sJ-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:33:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Nathan Jones Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: njones's message of Wed, 15 Aug 2001 23:13:37 +1000. <20010815231337.B11162@connect.com.au> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 22:22:51 +0900 Message-Id: <20010815132251.72CFE7BA@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> transition them into some other record type in one night. you have >> been proposing a migration path with a hard "flag day", with: >I don't recall anyone saying that this needs to be an instant change. > >I do recall people saying that A6 has merit and that it is worth the >effort to migrate. > >The whole idea of transition mechanisms like AAAA synth is to allow >gradual adoption of A6 as people start adopting A6. well, this is because you guys have been ignorant about transition issue from the current situation to "AAAA synthesis" situation. >Obviously there will be a transition period during which members of >the existing (comparatively small) IPv6 community will either provide >both AAAA and A6, or run DNS software that can synthesise AAAA RRs to >serve requests from other existing IPv6 users. what I have been arguing about is that, AAAA synthesis advocators never mention about transition period like the above four lines. it was very first time it was admitted by AAAA synthesis advocators. AAAA synthesis advocators never talk about this "issues during transition period to AAAA synthesis" wait, AAAA synthesis is a transition tool to A6, and we need a transition period to move to AAAA synthesis? what is the merit of doing such a complex thing? will the effort really buy us anything? there has to be more detailed analysis made, before AAAA synthesis be even taken into consideration. I'm serious. someone has to write up a whole analysis document. I tried it in my draft, but you may say I'm biased :-P >> - all existing zone files must be rewritten to from AAAA to A6 in one >> night (of which timezone?) >> - all AAAA queriers can stay as is, but there has to be AAAA synthesis >> server at every leaf >> - no AAAA traffic in core DNS cloud, only A6 traffic. >These claims seem to stem from either disbelieve that the transition >can be made, or from desire to stop A6 regardless of its merits. you can't control what I believe, or disbelieve. what I'm keep saying is AAAA synthesis advocators are too optimistic about the mess that happens during the transition period. and if we don't transition, there's no mess! itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:49:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22835 for ; Wed, 15 Aug 2001 10:49:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1gL-000Jt7-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:30:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1gL-000Jt0-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:30:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1gL-0003gX-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:30:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20010815231337.B11162@connect.com.au> Date: Wed, 15 Aug 2001 23:13:37 +1000 From: Nathan Jones To: Jun-ichiro itojun Hagino , Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2962.997878628@brandenburg.cs.mu.OZ.AU> <20010815123411.E40457BA@starfruit.itojun.org> In-Reply-To: <20010815123411.E40457BA@starfruit.itojun.org>; from Jun-ichiro itojun Hagino on Wed, Aug 15, 2001 at 09:34:11PM +0900 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, Aug 15, 2001 at 09:34:11PM +0900, Jun-ichiro itojun Hagino wrote: > transition them into some other record type in one night. you have > been proposing a migration path with a hard "flag day", with: I don't recall anyone saying that this needs to be an instant change. I do recall people saying that A6 has merit and that it is worth the effort to migrate. The whole idea of transition mechanisms like AAAA synth is to allow gradual adoption of A6 as people start adopting A6. Obviously there will be a transition period during which members of the existing (comparatively small) IPv6 community will either provide both AAAA and A6, or run DNS software that can synthesise AAAA RRs to serve requests from other existing IPv6 users. > - all existing zone files must be rewritten to from AAAA to A6 in one > night (of which timezone?) > - all AAAA queriers can stay as is, but there has to be AAAA synthesis > server at every leaf > - no AAAA traffic in core DNS cloud, only A6 traffic. These claims seem to stem from either disbelieve that the transition can be made, or from desire to stop A6 regardless of its merits. >itojun@tired. :-) -- nathanj to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:49:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22847 for ; Wed, 15 Aug 2001 10:49:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1qN-000KSh-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:40:27 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1qN-000KSZ-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:40:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1qN-0004DO-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:40:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun-ichiro itojun Hagino Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010815123411.E40457BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 15:49:26 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 21:34:11 +0900" Message-ID: <2c1ymdjuvt.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino writes: > the story applies only if we are going to move to A6 + AAAA synthesis. > if we don't migrate, we have no worry and everyone is happy. I'm not! Johan PS. Sorry about that, but I simply could not resist that response in the grand tradition of the british Monty Python-comedians... now back to our regular programme of intense disagreements ;-) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 10:57:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22988 for ; Wed, 15 Aug 2001 10:57:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X1w5-000KrS-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 07:46:21 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X1w5-000KrM-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:46:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X1w5-0004V9-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 07:46:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Jun-ichiro itojun Hagino cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010815123411.E40457BA@starfruit.itojun.org> References: <20010815123411.E40457BA@starfruit.itojun.org> Date: Wed, 15 Aug 2001 21:31:35 +0700 Message-ID: <3203.997885895@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 15 Aug 2001 21:34:11 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20010815123411.E40457BA@starfruit.itojun.org> | we (pick any community i'm involved with) are already operating AAAA | in a lot of places. Fine. | we need to keep those configuration to work fine | while we migrate to A6 + AAAA synthesis. Of course. | you have | been proposing a migration path with a hard "flag day", No I haven't. What I said was that I can change my AAAA records to A6 records any time I like. I can simply delete my AAAA records and not replace them at all any time I like. You will never notice, I'm quite sure that you don't care in the least about my few AAAA records. For any new systems I can install only A6 records - while you're only doing AAAA lookups you won't find them. You won't find them now while they have no v6 records at all either... Either way, you cope. | - all existing zone files must be rewritten to from AAAA to A6 in one | night (of which timezone?) No, I didn't say anything like that. I said that a server could convert (or a human operating a server could), I didn't ever claim that it all has to happen at once, there's no reason for that. | - all AAAA queriers can stay as is, but there has to be AAAA synthesis | server at every leaf Eventually, yes. In the short term, one used as a forwarder anywhere (one per ISP would do just fine). | - no AAAA traffic in core DNS cloud, only A6 traffic. That's not a requirement, just a target. It will probably never be reached. But who cares? There are probably MB queries out there in the net now, somewhere, no-one cares about those either. In another message you asked (Nathan Jones I think, but I will answer anyway) | how long do you think it will take, and how many people do you think | get bitten by this? Time, depending upon how committed various people are, a month or two, perhaps three. It depends how urgent it is seen to be. People, maybe 10K or so, perhaps realistically just a thousand. Compared to the millions of internet users, almost no-one. Of course, if you're one of the 10K (or 1K or whatever it is) then you're going to suffer a bit - you'll have some extra work to do, and you might want to maintain both AAAA and A6 for a while (you probably would, I wouldn't). That's extra work. It is also a part of the price of being an early adopter, which tends to hit everything new as it is being introduced. You get the benefits of being among the first, you have to pay the costs as well. And in another message ... | what I have been arguing about is that, AAAA synthesis advocators | never mention about transition period like the above four lines. That's because it is kind of obvious. Clearly the net that we have now is going to have to transition (assuming A6 is selected). You can read my messages about how impossible that will be if left a few years as implying that I don't think this is a trivial exercise, even now. It isn't. But it is manageable now. It can be done. We could even do it in stages, ask everyone to put A6 records in their servers wherever AAAA records exist. Then when we see (by querying the servers that we care about) that has been done, we can install A6->AAAA synthesis resolvers. Then when we see that the number of AAAA queries hitting our servers has dropped to an acceptably low level (which each of us can define individually), remove the AAAA records from our servers. Allow 3 weeks for the first step, and then everything is self timimg (we each proceed at our own pace). | wait, AAAA synthesis is a transition tool to A6, You can view it that way - but it is also possible to view it as simply a part of the infrastructure, the same way that TSIG/AD is a part of the DNSSEC infrastructure. Allow end nodes to do just simple things (if they want, they can always do A6, or full dnssec, if they prefer - most won't) forever. Nothing transition about it. | and we need a transition period to move to AAAA synthesis? Yes, but this isn't hard. | what is the merit of doing such a complex thing? It isn't complex. It is simple. It gets us to a much more flexible DNS RR - one which incidentally (aside from all the other benefits) means we need just N+M RR's in the DNS (and answers) rather than N*M for every node (where N is the number of interfaces a node has, and M is the number of prefixes). That may very well allow UDP queries to continue to work in situations (especially major serves - which are what most people want to reach) that AAAA would require TCP be used instead (ie: the 1280 (or 512 for basic v4 transport) bytes of DNS packet will hold much bigger A6 RRsets - sanely designed - then it will AAAA RRsets). eg: for AAAA, in a 512 byte packet, you can fit (maybe, if you're lucky and the name isn't too long) 27 RRs. If you have 4 providers, then the max addresses for a node before you get TC problems is 6. That's pretty limiting... With A6, you could probably fit 20 addresses for the node (and the 4 providers). This is one of the things the tests I am about to start doing will measure... If you're using many addresses to get load balancing, this matters. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 12:24:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25162 for ; Wed, 15 Aug 2001 12:24:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X3J9-0002IX-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 09:14:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X3J9-0002IR-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 09:14:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X3J9-0008sc-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 09:14:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20010816020435.A25502@connect.com.au> Date: Thu, 16 Aug 2001 02:04:35 +1000 From: Nathan Jones To: Johan Ihren , David Terrell Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <2361.997869643@brandenburg.cs.mu.OZ.AU> <20010815032134.A1896@pianosa.catch22.org> In-Reply-To: ; from Johan Ihren on Wed, Aug 15, 2001 at 12:30:37PM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Johan Ihren wrote: >An authoritative, non-recursive server with only A6 fragments around >can not synthesise the AAAA since that would require it to query for >missing fragments. True, but it could still be an option for DNS administrators happy to run a recursive nameserver. Also, I haven't thought this through fully, but is there any reason a nameserver couldn't have an option to use recursion for AAAA synthesis, but still deny to recurse when answering client queries? -- nathanj to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 15 13:30:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27103 for ; Wed, 15 Aug 2001 13:30:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15X48n-0003e5-00 for namedroppers-data@psg.com; Wed, 15 Aug 2001 10:07:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15X48n-0003dz-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 10:07:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15X48n-000BSM-00 for namedroppers@ops.ietf.org; Wed, 15 Aug 2001 10:07:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010815100613.033a7378@jurassic> Date: Wed, 15 Aug 2001 10:10:28 -0700 To: Johan Ihren From: Alain Durand Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org In-Reply-To: <2clmklk436.fsf@snout.autonomica.se> References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <2361.997869643@brandenburg.cs.mu.OZ.AU> <20010815032134.A1896@pianosa.catch22.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12:30 PM 8/15/2001 +0200, Johan Ihren wrote: > > There's no reason why it can't be a gradual upgrade. Authoritative > > servers for zones with A6 can do AAAA synthesis at query time just > > as easily as the local non-stub resolver can. It becomes a server-side > > indirection mechanism, which is available to A6-grokking caches. > >This is *wrong*. > >An authoritative, non-recursive server with only A6 fragments around >can not synthesise the AAAA since that would require it to query for >missing fragments. Those fragments could be provided (or queried) when the server is started. - Alain. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 16 13:10:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16282 for ; Thu, 16 Aug 2001 13:10:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XQC5-000BBa-00 for namedroppers-data@psg.com; Thu, 16 Aug 2001 09:40:29 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15XQC5-000BBU-00 for namedroppers@ops.ietf.org; Thu, 16 Aug 2001 09:40:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15XQC4-0004b1-00 for namedroppers@ops.ietf.org; Thu, 16 Aug 2001 09:40:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Nathan Jones Cc: Jun-ichiro itojun Hagino , Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2674.997874182@brandenburg.cs.mu.OZ.AU> <20010815114010.CA9C17BA@starfruit.itojun.org> <20010815225428.A11162@connect.com.au> From: Johan Ihren Date: 16 Aug 2001 15:34:22 +0200 In-Reply-To: Nathan Jones's message of "Wed, 15 Aug 2001 22:54:28 +1000" Message-ID: <2cwv44gmch.fsf@snout.autonomica.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Nathan Jones writes: > itojun wrote: > > you should care about this. there's no guarantee that AAAA synthesis > > happen between end client and master/slave nameservers. AAAA will > > leak from leaf to the core. > > David Terrell's suggestion that AAAA synth be performed by > nameservers which are authoritative for zones with A6 data seems > worth considering here. I think that is a very dangerous idea that we shouldn't use anywhere in an argument to ease a possible transistion to A6 + AAAA synthesis. Many authoritative servers run in non-recursive mode for security reasons, which is sound practice. Doing synthesis in the authoritative end would a) expose the servers doing it to possible cache pollution b) remove incentive from leaf sites to enable synthesis in the local full-service resolver thereby prolonging and increasing the leakage of AAAA queries into the core ("hey, it already works, why should we upgrade"). Both are bad. If AAAA synthesis turns out to be the correct answer then it should be done in the right place. Johan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 17 08:25:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26650 for ; Fri, 17 Aug 2001 08:25:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15XiCw-000HeN-00 for namedroppers-data@psg.com; Fri, 17 Aug 2001 04:54:34 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15XiCw-000HeH-00 for namedroppers@ops.ietf.org; Fri, 17 Aug 2001 04:54:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15XiCv-000CRT-00 for namedroppers@ops.ietf.org; Fri, 17 Aug 2001 04:54:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 17 Aug 2001 09:54:03 +0200 (SAST) From: Alan Barrett To: Johan Ihren cc: , , , Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <2cwv44gmch.fsf@snout.autonomica.se> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 16 Aug 2001, Johan Ihren wrote: > Many authoritative servers run in non-recursive mode for security > reasons, which is sound practice. The information that the authoritative servers would need to perform AAAA synthesis could conceivably be provided as "glue". There's no absolute need for it to be obtained via any sort of recursive query. --apb (Alan Barrett) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 18 21:35:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17808 for ; Sat, 18 Aug 2001 21:35:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YH0V-00073A-00 for namedroppers-data@psg.com; Sat, 18 Aug 2001 18:04:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15YH0U-000734-00 for namedroppers@ops.ietf.org; Sat, 18 Aug 2001 18:04:02 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15YH0U-0002Lm-00 for namedroppers@ops.ietf.org; Sat, 18 Aug 2001 18:04:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 18 Aug 2001 17:16:29 -0700 (PDT) From: Bernard Aboba To: namedroppers@psg.com Subject: Sense of the WG: mDNS configuration? Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At IETF 51, we had a discussion relating to configuration of mDNS. A number of alternatives were discussed, including: Domain Searchlist (draft-aboba-dhc-domsearch-05.txt) mDNS enable (draft-guttman-dhc-mdns-enable-01.txt) Name Service Searchlist (RFC 2937) Note that each of these alternative approaches allows for local configuration, in addition to control via a DHCP option. This is a request for a "sense of the WG" on which alternative should be pursued. Please post your opinion to the list, along with a few words on why you think your choice makes sense. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 18 23:30:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19632 for ; Sat, 18 Aug 2001 23:30:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YJ4B-0008Yz-00 for namedroppers-data@psg.com; Sat, 18 Aug 2001 20:15:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15YJ4B-0008Ys-00 for namedroppers@ops.ietf.org; Sat, 18 Aug 2001 20:15:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15YJ4B-0005wi-00 for namedroppers@ops.ietf.org; Sat, 18 Aug 2001 20:15:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bernard Aboba Cc: namedroppers@psg.com In-reply-to: aboba's message of Sat, 18 Aug 2001 17:16:29 MST. Subject: Re: Sense of the WG: mDNS configuration? From: Jun-ichiro itojun Hagino Date: Sun, 19 Aug 2001 11:06:57 +0900 Message-Id: <20010819020657.83AF37C2@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >At IETF 51, we had a discussion relating to configuration of mDNS. A >number of alternatives were discussed, including: > > Domain Searchlist (draft-aboba-dhc-domsearch-05.txt) > mDNS enable (draft-guttman-dhc-mdns-enable-01.txt) > Name Service Searchlist (RFC 2937) > >Note that each of these alternative approaches allows for local >configuration, in addition to control via a DHCP option. > >This is a request for a "sense of the WG" on which alternative should be >pursued. Please post your opinion to the list, along with a few words on >why you think your choice makes sense. i vote for domain searchlist. there are environments without DHCP server, like IPv6 stateless address autoconf (RFC2937 and guttman-dhc-mbdns-enable both assumes that a DHCP server is there). itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 19 00:07:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20377 for ; Sun, 19 Aug 2001 00:07:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YJef-00094K-00 for namedroppers-data@psg.com; Sat, 18 Aug 2001 20:53:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15YJef-00094E-00 for namedroppers@ops.ietf.org; Sat, 18 Aug 2001 20:53:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15YJef-0006xk-00 for namedroppers@ops.ietf.org; Sat, 18 Aug 2001 20:53:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B7F37A1.374F89C3@ehsco.com> Date: Sat, 18 Aug 2001 22:50:58 -0500 From: "Eric A. Hall" To: Jun-ichiro itojun Hagino CC: Bernard Aboba , namedroppers@psg.com Subject: Re: Sense of the WG: mDNS configuration? References: <20010819020657.83AF37C2@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > i vote for domain searchlist. there are environments without DHCP > server, like IPv6 stateless address autoconf I vote for anything other than searchlist overloads. Forced to choose, I would vote for local configuration option, with the ability to use DHCP as a modification of the local configuration option getting a strong positive. [can we please stop calling it multicast DNS, since it isn't?] -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 19 06:24:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10613 for ; Sun, 19 Aug 2001 06:23:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YPM4-000EG9-00 for namedroppers-data@psg.com; Sun, 19 Aug 2001 02:58:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15YPM4-000EG3-00 for namedroppers@ops.ietf.org; Sun, 19 Aug 2001 02:58:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15YPM4-000H7t-00 for namedroppers@ops.ietf.org; Sun, 19 Aug 2001 02:58:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 18 Aug 2001 23:51:44 -0700 (PDT) From: Bernard Aboba To: Jun-ichiro itojun Hagino cc: namedroppers@psg.com Subject: Re: Sense of the WG: mDNS configuration? In-Reply-To: <20010819020657.83AF37C2@starfruit.itojun.org> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > i vote for domain searchlist. there are environments without DHCP > server, like IPv6 stateless address autoconf > (RFC2937 and guttman-dhc-mbdns-enable both assumes that a DHCP > server is there). > > itojun Currently the DNS server addresses and the domain searchlist can be statelessly discovered in IPv6, but the other candidates cannot be, thereby creating a DHCPv6 dependency, which is a show-stopper. Would your opinion change if the other candidates (mDNS enable, name service searchlist) could be statelessly discovered? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 19 06:24:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10624 for ; Sun, 19 Aug 2001 06:24:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YPKC-000EET-00 for namedroppers-data@psg.com; Sun, 19 Aug 2001 02:56:56 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15YPKC-000EEN-00 for namedroppers@ops.ietf.org; Sun, 19 Aug 2001 02:56:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15YPKC-000H4f-00 for namedroppers@ops.ietf.org; Sun, 19 Aug 2001 02:56:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 19 Aug 2001 14:16:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jun-ichiro itojun Hagino Cc: namedroppers@psg.com Subject: Re: Sense of the WG: mDNS configuration? In-Reply-To: <20010819020657.83AF37C2@starfruit.itojun.org> References: <20010819020657.83AF37C2@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> On Sun, 19 Aug 2001 11:06:57 +0900, >>>>> Jun-ichiro itojun Hagino said: >> Domain Searchlist (draft-aboba-dhc-domsearch-05.txt) >> mDNS enable (draft-guttman-dhc-mdns-enable-01.txt) >> Name Service Searchlist (RFC 2937) >> >> Note that each of these alternative approaches allows for local >> configuration, in addition to control via a DHCP option. >> >> This is a request for a "sense of the WG" on which alternative should be >> pursued. Please post your opinion to the list, along with a few words on >> why you think your choice makes sense. > i vote for domain searchlist. there are environments without DHCP > server, like IPv6 stateless address autoconf > (RFC2937 and guttman-dhc-mbdns-enable both assumes that a DHCP > server is there). I agree with itojun for the same reason. At least we should have a method of configuration without stateful servers. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 19 06:28:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10645 for ; Sun, 19 Aug 2001 06:28:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YPRz-000ELt-00 for namedroppers-data@psg.com; Sun, 19 Aug 2001 03:04:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15YPRz-000ELn-00 for namedroppers@ops.ietf.org; Sun, 19 Aug 2001 03:04:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15YPRz-000HIO-00 for namedroppers@ops.ietf.org; Sun, 19 Aug 2001 03:04:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Bernard Aboba cc: namedroppers@psg.com Subject: Re: Sense of the WG: mDNS configuration? In-Reply-To: References: Date: Sun, 19 Aug 2001 15:11:41 +0700 Message-ID: <1134.998208701@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Sat, 18 Aug 2001 17:16:29 -0700 (PDT) From: Bernard Aboba Message-ID: | Domain Searchlist (draft-aboba-dhc-domsearch-05.txt) | mDNS enable (draft-guttman-dhc-mdns-enable-01.txt) | Name Service Searchlist (RFC 2937) Either of the latter two - the mdns-enable option is basically just a special case of 2937, in a sense - but as I read 2937, it would need another DNS option defined anyway, so its option number can be used in the 2937 option (there's no current dhcp option giving the addresses of the servers for mDNS .. for obvious reasons). That is, adapting 2937 is probably more work than it is worth, so mdns-enable is probably the better choice. dhc-domsearch (with the magic string) is just wrong - overloads an option with a totally irrelevant meaning. And for itojun - none of these assume the existence of a dhcp server, merely that if it does exist, then it can be used to configure nodes. dhc-domsearch is basically setting the search line of resolv.conf and the other two, the hosts line of nsswitch.conf (from a NetBSD perspective, which I'm sure you understand). When there's no dhcp server, those can be configured manually (or simply default to whatever the OS vendor decides is best - perhaps based upon an IETF recommendation). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 20 10:11:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21637 for ; Mon, 20 Aug 2001 10:11:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YpMa-000K5J-00 for namedroppers-data@psg.com; Mon, 20 Aug 2001 06:45:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15YpMa-000K5D-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 06:45:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15YpMa-000AXi-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 06:45:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 20 Aug 2001 03:42:06 -0700 (PDT) From: Ramakrishna Gummadi To: namedroppers@ops.ietf.org Subject: DNSSec NXT records Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, RFC2535 specifies that the NXT replies should contain the existing next name in the zone but observes that query chaining through NXT records can reveal all the names in a zone, even though zone transfers are administratively prohibited. It also says that alternate NXT formats can be specified in the future to avoid this. I propose an alternate mechanism that avoids having to give out valid name in NXT replies: simply replace names with one-way hashes. This way, two signed one-way hash values would be returned to prove that the non-existant name would be translated into a hash that would lie within this interval. Everything else should just work fine. -ramki to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 20 11:11:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23380 for ; Mon, 20 Aug 2001 11:11:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YqNh-000Lk0-00 for namedroppers-data@psg.com; Mon, 20 Aug 2001 07:50:21 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15YqNg-000Lju-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 07:50:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15YqNg-000CLF-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 07:50:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <043e01c12986$e78082c0$b9370681@antd.nist.gov> From: "Scott Rose" To: "Ramakrishna Gummadi" , References: Subject: Re: DNSSec NXT records Date: Mon, 20 Aug 2001 10:46:32 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ramki, It's been suggested to replace the next domain name in the NXT record with a hash of the name. The proposal has been called the NO record (draft-ietf-dnsext-not-existing-rr-01). The current opinion/leaning of the DNSEXT group has been to go with the NXT record instead of the NO (which is still experimental, so some implementers may be using it). Until someone comes up with a "killer reason" for going with NO or some better way of offering authenticated denial. Your idea sounds different, but the NO record is very similar to your suggestion. If you think I've gotten something incorrect, feel free to write up your idea as an Internet Draft and submit it to the IETF as an alternate proposal to the NXT record. It might bring the authenticated denial discussion thread back to life (which may not be the best thing for people suffering during the current list mail glut ;-) Scott ----- Original Message ----- From: "Ramakrishna Gummadi" To: Sent: Monday, August 20, 2001 6:42 AM Subject: DNSSec NXT records > Hi, > RFC2535 specifies that the NXT replies should contain the existing next > name in the zone but observes that query chaining through NXT records > can reveal all the names in a zone, even though zone transfers are > administratively prohibited. It also says that alternate NXT formats can > be specified in the future to avoid this. > > I propose an alternate mechanism that avoids having to give out > valid name in NXT replies: > simply replace names with one-way hashes. This way, two signed one-way > hash values would be returned to prove that the non-existant name would be > translated into a hash that would lie within this interval. > > Everything else should just work fine. > > -ramki > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 20 12:24:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25680 for ; Mon, 20 Aug 2001 12:24:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15YrZT-000Nts-00 for namedroppers-data@psg.com; Mon, 20 Aug 2001 09:06:35 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15YrZT-000Ntm-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 09:06:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15YrZT-000ET1-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 09:06:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 20 Aug 2001 18:00:17 +0200 (CEST) From: Roy Arends To: Ramakrishna Gummadi Cc: Subject: Re: DNSSec NXT records In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 20 Aug 2001, Ramakrishna Gummadi wrote: > Hi, > RFC2535 specifies that the NXT replies should contain the existing next > name in the zone but observes that query chaining through NXT records > can reveal all the names in a zone, even though zone transfers are > administratively prohibited. It also says that alternate NXT formats can > be specified in the future to avoid this. > > I propose an alternate mechanism that avoids having to give out > valid name in NXT replies: > simply replace names with one-way hashes. This way, two signed one-way > hash values would be returned to prove that the non-existant name would be > translated into a hash that would lie within this interval. > > Everything else should just work fine. Good idea, but already has been thought of: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr-01.txt Authenticating denial of existence in DNS with minimum disclosure (or; An alternative to DNSSEC NXT records) draft-ietf-dnsext-not-existing-rr-01 Abstract This draft present an alternative to NXT records, used to achieve authenticated denial of existence of a domain name, class and type. Problems with NXT records, as specified in RFC 2535, are identified. One solution, the NO record, is presented. The NO record differ from the NXT record by using a cryptographic hash value instead of the domain name. This prevent an adversery from collecting information by "chaining" through a zone. It also remove delegation point concerns that was a side effect of NXT records. The document also describe hash truncation and record merging that reduces storage/network load. Regards, Roy Arends Nominum ------------- 0-14-023750-X dcrpt ths 43.0D.01 01.05.0C 84.18.03 8A.13.04 2D.0B.0A to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 20 17:01:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04065 for ; Mon, 20 Aug 2001 17:01:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Yvmd-00067N-00 for namedroppers-data@psg.com; Mon, 20 Aug 2001 13:36:27 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15Yvmb-00067H-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 13:36:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15Yvma-000N9B-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 13:36:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 20 Aug 2001 11:39:26 -0700 (PDT) From: Ramakrishna Gummadi To: namedroppers@ops.ietf.org Subject: Re: DNSSec NXT records In-Reply-To: <043e01c12986$e78082c0$b9370681@antd.nist.gov> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My thanks to all the folks who pointed me to this reference. I somehow missed this completely. There is another unrelated idea I have been tossing about, that I think can reduce public key data required for TLDs within KEY records, and can thus reduce traffic at root-servers when using DNSSec. I think this is an interesting idea (at least conceptually), and would like to know if it has been brought up somewhere as well. The basic idea is to use names themselves as public keys; a name, such as foo.com, can itself specify a public key k_p that anybody can derive *offline* (given public constants of the algorithm, of course). Like other public key schemes, a client should have beforehand the required algorithm constants for the "." zone; once there are known, however, a client can also automatically derive the public keys of gTLDs and ccTLDs, unlike in traditional public key cryptosystems such as RSA and DSA where public keys have to be separately created and explicitly delegated via certificates, KEY RR data, etc. One way to derive a publick key, k_pub, from a name, foo.com, could be: k_pub=g^(h(foo.com)), where g is a generator in Z_n^*, n is the RSA modulus, and h is a one-way hash function. This n can be the same one used in the RSA/MD5 algorithm by the "." zone. Like in RSA/MD5, it should be statically known to every client. The corresponding private key, which only the "." zone will be able to derive because only it knows the factorization of n, is k_priv such that h=k_pub*(k_priv)^d mod n, where d is the RSA decryption exponent of n, and h can be a public constant known statically to all, and same for all TLDs. The "." zone would then give the k_priv private key to foo.com, which can then prove to anyone it knows k_priv for foo.com, sign discrete logarithm-based messages using k_priv, etc. Any gTLD and ccTLD can obtain private keys this way, playing the role of foo.com in the above description. This is basically a Brands/Okamoto algorithm whose security has been proven elsewhere. Its attractiveness here is its ability to create "self-certifying" tld's. One can think of the entire scheme as an public key mechanism that binds names to keys tighter than alternate schemes using explicit certificates would. Any feedback is appreciated. cheers, ramki On Mon, 20 Aug 2001, Scott Rose wrote: > ramki, > > It's been suggested to replace the next domain name in the NXT record with a > hash of the name. The proposal has been called the NO record > (draft-ietf-dnsext-not-existing-rr-01). The current opinion/leaning of the > DNSEXT group has been to go with the NXT record instead of the NO (which is > still experimental, so some implementers may be using it). Until someone > comes up with a "killer reason" for going with NO or some better way of > offering authenticated denial. > > Your idea sounds different, but the NO record is very similar to your > suggestion. If you think I've gotten something incorrect, feel free to > write up your idea as an Internet Draft and submit it to the IETF as an > alternate proposal to the NXT record. It might bring the authenticated > denial discussion thread back to life (which may not be the best thing for > people suffering during the current list mail glut ;-) > > Scott > > ----- Original Message ----- > From: "Ramakrishna Gummadi" > To: > Sent: Monday, August 20, 2001 6:42 AM > Subject: DNSSec NXT records > > > > Hi, > > RFC2535 specifies that the NXT replies should contain the existing next > > name in the zone but observes that query chaining through NXT records > > can reveal all the names in a zone, even though zone transfers are > > administratively prohibited. It also says that alternate NXT formats can > > be specified in the future to avoid this. > > > > I propose an alternate mechanism that avoids having to give out > > valid name in NXT replies: > > simply replace names with one-way hashes. This way, two signed one-way > > hash values would be returned to prove that the non-existant name would be > > translated into a hash that would lie within this interval. > > > > Everything else should just work fine. > > > > -ramki > > > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 20 17:06:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04305 for ; Mon, 20 Aug 2001 17:06:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Yw0x-0006aj-00 for namedroppers-data@psg.com; Mon, 20 Aug 2001 13:51:15 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15Yw0w-0006ad-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 13:51:14 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15Yw0v-000NAb-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 13:51:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <20010808182611.A11259@bb.nge.isi.edu> References: ; from jakob@crt.se on Wed, Aug 08, 2001 at 09:26:17PM +0200 <20010808112314.A10365@bb.nge.isi.edu> Date: Mon, 20 Aug 2001 16:32:27 -0400 To: Dan Massey From: Edward Lewis Subject: Re: draft-ietf-dnsext-delegation-signer-01 Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit There are two arguements here. At 6:26 PM -0400 8/8/01, Dan Massey wrote: >But how does breaking your zone prevent anyone from spoofing it? There may be value in causing confusion. If the parent indicates that key #1 is signing the child, but I can only see key #2, I can conclude that something is amiss. In this state, I could try contacting the admin, delay my current attempt to access data, etc. >Or am I missing something? Part of the problem is the definition of "MUST." I think the text being offered is mixing protocol definition and operational procedure, a mix which leads to confusion. Perhaps I'll try to restate the specification under discussion: "In a properly secured parent zone, at a delegation point there MUST be a DS RR set present if the child zone is to be considered secure. In the case of an unsecured child zone, there MUST NOT be a DS RR set present. "The intent of the DS RR set is to list the child zone keys that are recognized to sign the zone. The parent signing of this set of data indicates that the child has indicated that these are the proper zone key(s). "For any set of data in the child zone, if there is no SIG RR generated by one of the recognized keys for an RR set that is supposed to be signed (), a resolver could conclude that something is broken with respect to the child zone. The behavior of the resolver at this point is not specificed here. (Begging the question: where to we specify the behavior.)" A specification cannot "MUST" that two entities have the same value for something. A specification can suggest this and should indicate what to do when the entities differ. To push the limits of sane conversation - because of the special theory of relativity - it is impossible for two entities to change a value simultaneously to all observers, ergo, you can't MUST that the set at the parent agree with the child's set. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 21 01:37:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17964 for ; Tue, 21 Aug 2001 01:37:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Z3ro-00007d-00 for namedroppers-data@psg.com; Mon, 20 Aug 2001 22:14:20 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15Z3ro-00007X-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 22:14:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15Z3d0-000NFN-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 21:59:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 20 Aug 2001 19:01:01 -0400 From: Dan Massey To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-delegation-signer-01 Message-ID: <20010820190101.A1318@bb.nge.isi.edu> Mail-Followup-To: namedroppers@ops.ietf.org References: ; <20010808112314.A10365@bb.nge.isi.edu> <20010808182611.A11259@bb.nge.isi.edu> In-Reply-To: ; from lewis@tislabs.com on Mon, Aug 20, 2001 at 04:32:27PM -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, August 20, 2001 at 04:32PM, Ed Lewis wrote: | There are two arguements here. | | At 6:26 PM -0400 8/8/01, Dan Massey wrote: | >But how does breaking your zone prevent anyone from spoofing it? | | There may be value in causing confusion. If the parent indicates that key | #1 is signing the child, but I can only see key #2, I can conclude that | something is amiss. In this state, I could try contacting the admin, delay | my current attempt to access data, etc. | I also initially thought it would be okay to remove the compromised key, but it turns out to be a very bad idea. Doing what you suggest will either: blackhole your zone if you aren't under attack make it easier to spoof your data if you are under attack Consider the example you describe above. In your example, the parent has indicated (via a DS record) that key #1 should be used to sign the child zone (or at least the child zone's key set). In your example, the child has removed key #1 and is now using key #2 to sign it zone. Here is what happens when a resolver tries to get data from the child zone. A resolver knows the zone is secure and is getting data signed by key #2. This key #2 is not signed by any trusted entity and differs from the expected zone key. The resolver will ignore this data. If the resolver does not ignore this data, nothing stops me from creating random keys and using them to spoof the zone's data. So the child zone has just blackholed itself. It gets worse if someone is sending spoofed response. In this case, the resolver gets a spoofed response signed by the compromised key #1 and a valid response signed by your new key #2. As before, the resolver will drop the response signed by key #2. The resolver will also believe the (forged) response signed by key #1. If you had kept key #1, the resolver would have received two different answers that were both signed by key #1. If you had kept key #1, there would be confusion that might cause you to "try contacting the admin, delay my current attempt to access data, etc." You create confusion only by keeping key #1. Removing key #1 just makes the forged answer look better. For more general cases, look at the 4 possible scenarios described in my last message and note that removing key #1 causes you to lose everytime. | | Part of the problem is the definition of "MUST." I think the text being | offered is mixing protocol definition and operational procedure, a mix | which leads to confusion. | I also disagree with this. The protocol needs a MUST here and this is not mixing operation with specification. There are a number of possible operational procedures that let you achieve the requirements and I list one possible operational procedure below. | | A specification cannot "MUST" that two entities have the same value for | something. A specification can suggest this and should indicate what to do | when the entities differ. | | To push the limits of sane conversation - because of the special theory of | relativity - it is impossible for two entities to change a value | simultaneously to all observers, ergo, you can't MUST that the set at the | parent agree with the child's set. | There is no requirement for things to be done simultaneously and this lack of simultaneous changes is one of the big advantages of DS. Here is the operational procedure we are planning to start experimenting with in our testbed: 1) create the new KEY, add it to the KEY set, add the SIGs. 2) send the new DS record to the parent 3) wait for parent to update the DS set in the parent zone 4) removed the old KEY/SIGs (after in step 3 parent has updated the DS set). Note it always meets the specification wording (assuming MUST) and requires no simultaneous changes at parent and child. The consequence of not obeying the MUST in the spec wording is that you blackhole the zone and make it easier for someone to spoof your data so the MUST belongs in the protocol spec. I agree that the operational procedures like the one described above belong elsewhere. Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 21 01:45:01 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18768 for ; Tue, 21 Aug 2001 01:45:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Z3vP-0000HK-00 for namedroppers-data@psg.com; Mon, 20 Aug 2001 22:18:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15Z3vP-0000HE-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 22:18:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15Z3sV-000NIN-00 for namedroppers@ops.ietf.org; Mon, 20 Aug 2001 22:15:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.2.20010821003049.028bc060@localhost> Date: Tue, 21 Aug 2001 00:33:39 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Draft IETF-51 DNSEXT WG minutes Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Here are my draft minutes, please send in corrections/changes/additions before August 28'th. Olafur DNSEXT IETF-51 meeting 2001/August/9 9:00-11:30 GMT. Chairs: Randy Bush Olafur Gudmundsson WG STATUS: Olafur Gudmundsson - 1 new RFC: APL - 2 documents at RFC editor, message size + DNSSEC OK bit - 2 docs at IESG: DNSSEC roadmap + RFC161{1,2} retire - AXFR has passed working group call - MUST figure out DNSSEC status - Please adopt RFC to advance Summary of DNSEXT/NGTRANS Olafur Gudmundsson Summary of DNSSEXT & NGTRANS MEETING - DNSEXT will take lead on standardizing IPv6 address related RFCs. - A6, bitlabels => experimental - DNAME standardization is by DNSEXT it stays for now at proposed. - AAAA to go to drafter standard, need volunteer to adopt for interop testing and reporting. Agenda was the main focus of the meeting to asses the current DNSSEC status and how it should evolve from now on. Then new proposals are on the agenda followed by an open discussion on how to go forward. Goal: determine how close to operationally deployable DNSSEC Subgoal: collect list of threats to DNS that only DNSSEC can address Output: proposed plan of action posted to mailing list - --- Current DNSSEC status and options on how to progress Edward Lewis + Olafur Gudmundsson context DNSSEC had a spurt of definition from 1994 to 1998 partial implementation in bind822 1999 workshop followed bind9 full 2535 DNSSEC with tweaks Jnamed has almost full DNSSEC compliance recently, as a result of experiments an explosion in issues, discussion, activity set forth a few options regarding to the future of DNSSEC judge the severity and volume of current issues to see what outcome is recommended no intention to discuss the issues or solutions here DNSSEC seems to be healthy in terms of interest but with its potential importance and this healthy interest, why aren't we done yet? what could be done: - allow just some tweaking - pursue significant changes - scrap the current approach and start over - freeze the current design and advance it allow just some tweaking: means leaving most of the definition intact can we solve the rest of the problems with tweaks and adjustments? or are we running in circles before it all come crashing down? major surgery: a few IETFs ago (oslo or dc) an edict was set forth that DNSSEC must settle down too many theorists, not enough operators the hope was to give the current definition a real litmus test how much longer to we wait for the test to begin? or should the edict be rescinded? has the test begun already or not? scrap the current approach and start over well, at least we've learned a lot perhaps the initial conditions set forth are doomed to lead us to a dead end is dns1.0 (rfc1035) inherently unsecurable? perhaps we need to restart, perhaps with dns2.0 threat model, requirement document are needed freeze the current design and advance it issues somewhat arbitrary division of the issues CERT records TSIG operations management, TKEY SIG/KEY operations exposure of data, delegation management, dynamic update applications and stub resolution authority at delegations CERT records nothing to mention really not much activity, but this isn't a fault of dns one issue area down... just a doc, noone is using it. TSIG - Workshops demonstrated that TSIG is maturing well. - Work has lagged in secret management. - Two pending drafts, GSS-API and TKEY renewal. - Open issue is use of TSIG in general purpose queries. SIG/KEY a much more problematic area basic operations are defined, but not always scalable some issues are even recognized as issues - exposure of data - via authenticated denial other issues - delegation management - dynamic update refresh SIG/KEY exposure NXT record different approach: NO modified approach - allowing exclusion of sets from NXT this issue relates to delegation management excluding records from NXT eases burden provides cheaper means to signify unsecured delegations exposure drafts opt-in-00, rrsets-00, not-existing-rr-00 delegation management difficult set of issues RFC1035 has the same delegation records in parent and child, with the child one more credible, and no record type that only exist in parent DNSSEC requires more complex communication between parent and child registrar, registry, registrant complicates KEY signing opens up liability issues for parents QoS issues for child SIG/KEY at delegations APEX KEY set can be large, change frequently contain non DNS zone KEY records proposals to solve problems reduce communication between parent and child allow partial security in secure zones allow zones to express security policies in use parent-store-zone-keys-01, delegation-signer-01, dnssec-opt-in-00, dnsext-rrsets-00, sec-rr-00 SIG/KEY dynamic update this topic suffers from a lack of activity early experiments noted problems in early implementations may have been fixed but no one is exercising this area (publicly) in order to sign zone, you have to have private key present on the server application and stubs how are answers to be interpreted? what are the meaning of the bits in the header? should application keys be stored differently than DNSSEC keys? dnssec-okbit02, key-genprot-00, ad-is-secure-03 design tradeoffs delegation maintenance is hard, thus some new proposals suggest changes that increase resolver work and add latency in protocol is it acceptable to secure only fraction of a zone? when there is choice what part of operation should be favored, operation or resolution? anyone address some of the problems? ohta: public key crypto violates e2e principle. - --- DNSSEC editing status Dan Massey, Scott Rose - --- Opt IN plan Mark Kosters opt-in for large zones DNSSEC is painful for large zones huge up front cost null keys, nxt rrs for unsecured child zones little initial buy-in high performance penalty on lookup (hash vs tree) high generation cost ordering, signing, distribution desire to have autonomous DNSSEC processing changes since last version of draft. dropped additional rcode "retry-no-sec" in response to DNSSEC queries for delegations that are not secure now answers from "unsecure" side folded in with secure response for a query on a unsecured or non-existent domain so no need for query semantics of NXT changed from "non-existence" to "secure but not in range" indicated by setting bit 3 in KEY RR pros - incremental cost to DNSSEC adoption - independent processing for DNSSEC - no changes for 1035 processing - DNSSEC not widely deployed yet so now is the time for change cons - resolvers need to be updated to deal with opt-in (easy according to nominum) pilot implemented an opt-in pilot for com/net/org demonstrate ease of use, implementation for conformance testing use parent sig over child (for now) code is *not* based on bind 3 example zones with web-based zone editor to show how easy it could be to secure/unsecure a zone with opt-in key mgmt web interface for other domains under com/net/org http://www.research.netsol.com/ Q: updating recursive resolvers is hard. more elegant solution needed than verisign needs to do. Rob Austein: signing time issue is not quite it looks like, because it can be done in parallel, except when changing keys frequently, which you're not planning on doing.) look at it at first NO SIG Mark Kosters for Roy Arens diff between NOsigRR and opt-in - NXT changed from non-existence to not-secure - OPT-IN defines this in KEY RR - NOSIG defines this with pseudo-RR hel in NXT type bitmap - Pros: accomplishes opt-in goals, adds in-zone RRs that could be unsecured, allows thin layer of security from zone to zone Ed Lewis: Create a type different from NXT rather than trying to change its existing definition. SIG@Parent Miek Gieben good points: works very well operationally reduces administrator involvement makes key rollover possible but: resolver must be adapted local (ssh) keys are also signed solution: new record at the parent -> DS? - --- Delegation Signer Olafur Gudmundsson APEX records issue. motivations key record repeats the mistake of NS record in delegations, same record in two zones key at child is cumbersome key@parent has liability issues for parent QoS child is totally at parent mercy on changes parent may only allow dns keys in key set is there another way? DS advantages - minimizes communication only when child changes key set signed key - less data in parent DS much smaller than key DS only at secure delegations child in full control of security status no conflicting key sets DS disadvantages - More work for resolves, worst case doubling number of sig verifications - Has to calculate checksums for keys DS record checksum - SHA1(canonical fqdn + key rdata) data format: 25 bytes, fixed size key id (2), key size (2), algorithm, sha-1 digest possible to make the record smaller. Donald Eastlake commented that the statement in presentation about childs independence was to strong. Ian Jackson liked the flexibility this gives child for key policies. Dan Massey: wondered about the right actions to take if child key gets compromised, he will post discussion points on mailing list. ================================================================ SEC RR, Ed Lewis Currently a place holder for discussion. IF and only if some of the new ideas discussed such as opt-in, DS etc are adopted, it might be nice to tell resolvers what to expect in each zone. SEC RR is indented to express the policies and security records used. ================================================================ 40 min Next steps in DNSSEC Randy Bush This will be open mike session to air opinions on which of the following options to go with. The chairs will take the suggestions and results of straw polls to formulate a plan of action to propose to the working group on the the mailing list. The options are: - Finished tweaking DNSSEC (no more changes) - Few more tweaks (which ones) - Major Surgery (any collection new proposals such as opt-in, delegation signer, no, no-sig, ) - Start over, because the current approach is not going to work - Do we really need it?) Tom Monday: List of issues is representative of what we know of today but there are probably more we have not yet discovered. Unfortunately the IETF is not good at establishing when things have been explored enough. Q: dynamic update part/stuff really works or not? OG: Dynamic update needs more attention. Randy Bush: We need to have a serious, week long workshop with very few people, but throwing in dynamic update with add at least another week, maybe two. ...: [something about dynamic update] Olafur: Dynamic update needs more attention than it has been given, which is not nearly enough. Randy: We need to have a serious, week long workshop with very few people, but throwing in dynamic update with add at least another week, maybe two. Lars Liman: Cost of security is highly relevant, needs to be balanced against the risk of losing money if you don't have it. Need to ask people how much they could lose without it, much they are willing to invest in the hard work to protect the money they stand to lose? Randy: How many people here seriously working on DNSSEC are funded by commercial interests? [2.] How many by military interests? [A few more.] Rob Austein: Biggest single thing that keeps whacking us in the face seems like we have a handle on it, but it would take a lot of time to implement and test. If we decided to undertake this, we need to go back and re-examine the threat model and see just what problems we're trying to address. Think we could do dynamic update work in parallel. My major hope is the last major thing we really need to change with DNSSEC is the delegation signing issue, so shouldn't run into needs to major change the protocol further when work on dynamic update is done. Ian: A lot of problems are related to not having clear layering model, that DNSSEC simultaneously looks like part of the normal, accepted DNS layer, and part of it looks like a layer on top but with lots of layering violations. Donald: Wrote some of original documents but have not been all that active recently. The problem with multilevel hierarchal delegation is intrinsically difficult with no working models anywhere. Could move the security communication completely out of the DNS -- but not clear that would make a bit of difference. If we have DNS security, we need to know what services it is offering and focus on offering them strongly. Biggest mistake would be offering many services and providing them with weak security. Derek Atkins: One thing about security is that it is very pervasive, it is going to violate layers when you add it to something that was not designed with it, either that or you have to wholly replace the system. With regard to secure dynamic update, I did an implementation in 1995 with the biggest issue being online vs offline signing. You could do it with delegating a signing key to the updater, like the DHCP server. In terms of the real problems that DNSSEC is trying to solve, the biggest one is that DNSSEC solves the problem of name referrals, getting from one name (a host abbreviation alias) to a full name and hence its associated data. Rip Loomis: Military spending a huge amount of money on trying to make this work, consider it crucial. Ed: SIG and KEY are where all the problems are, others seem to be ready to go. Michael Patton: Was agnostic about DNSSEC originally when chaired the DNSng BOF, but now think it is very important to get something out there ASAP. We really need the experience of having a V1.0 in order to learn enough to have a V2.0 which does it right. In favor of doing both very little tweaking to move forward, and also scrapping the current approach to design from scratch a better oe. Ian: We will always need to have a way to send secured data end-to-end over unsecured path, with full service resolvers doing verification. Olafur: Early adopters always face a risk. Randy: I'm not a security weenie, but security experts I trust tell me that complexity is inversely proportional to strength of security, and having a complex process that is not terminating makes me really uncomfortable about the ultimate security of this system. Concerned about the choice of pushing forward with the intent to fix things later. The DNS was bleedingly complex before we even tried to graft DNSSEC into it. Trying to figure out how to get comfortable with any of the choices. Russ Monday: From NAI, working with ISI on DNSSEC. Important thing NAI/ISI can do is provide a testbed for all this, willing to make available to researchers from other organizations. Sometimes one person's tweak is another's significant change. Should focus on the delegation problem. Should test various proposals and come back with results from that for next IETF meeting. Bill Manning: Part of the problem is that DNSSEC is a lot like porn in that we claim to know it when we see it (implying there is not an objective way to measure it). ...missed... At some point we really do need to start over with the design of it. Also, I don't believe there can be a single threat model, we can and should have multiple good ones. Derek Atkins: Regarding simplicity versus complexity, Einstein said, "You should design your system to be as simple as possible and no simpler," and I really think DNSSEC really is as simple as we can make it. Rob: Propose parallel approach: work on threat model, and rigorously test delegation proposals. Sense of room seems to agree, no one spoke against. Donald: Move TSIG to the side. Ian: Can we have a definition on what's a tweak and what's a major change? Randy: NO. Matt Larson: Let's not forget the large zone problem! Not as significant as large zone problem, but still really significant. Mark Kosters: Since we have to change the recursive nameserver anyway, we might as well address the large zone issue at the same time. Have not liked NXT since the beginning, but I have become resigned to authenticated denial. Rob Austein: Confidentiality of data was explicitly NOT one of stated goals of DNSSEC, so people who don't like NXT, tough noogies. Also, because of the interdependence of MX and A records, you can misroute mail. Without authenticated denial there are other attacks possible. Sense of the room is to pursue parallel work on: - delegation management Russ will pursue with NAI/ISI testbed - protocol discussion on partially signed (ie, large) zones Mark's work converging - get serious about dynamic update ... need someone to adopt, contact chairs - threat models / requirements Rob Austein and Derek Atkins - --- Old Working Group documents 05 min Multicast DNS Dave Thaler - Use of "solicited name" multicast addresses for IPv6, using same mechanism as used elsewhere (icmp) - Clarification of multihoming behavior - dynamic update for conflict detection - added .ARPA domain considerations section Open Issues - Configuration of mdns - still assumes domain search option for configuration, but there are other proposals. - Draft useful as stands? - Original goal was to allow retirement of NetBIOS and AppleTalk in unconfigured networks. - Has this goal been met? - --- Relevant Documents in Other working groups 05 min DHC MulticastDNS enable option Erik Guttman mdns enable dhc option complete replacement to local.arpa zone wants to replace appletalk with IP services. ================================================================ REPLACE APPLETALK & NETBIOS, Stuart Cheshire draft-cheshire-dnsext-multicastdns-00 An alternative multicast DNS proposal. Goals/features: - Free choice of names for machines only on local link - Name _services_ at first class entities, not just hosts - Browse for services, like the printers on the network - Failsafe reliability - Simple to implement ================================================================ At this point working group was out of time, chair wanted to resolve one issue, Olafur Gudmundsson asked Bill Manning a question: If the working group wants to adopt your discover draft will you change the copyright to boilerplate #1? Bill Manning: YES End of meeting: Number of agenda items did not get a hearing this time including following documents. - --- New documents requesting to become working group documents 05 min TKEY rekey mode Yuji Kamite - --- 05 min Generic KEY RR Protocol value Edward Lewis - --- 05 min ECC KEY rr Donald Eastlake to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 21 13:42:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25251 for ; Tue, 21 Aug 2001 13:42:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZFBy-0004ib-00 for namedroppers-data@psg.com; Tue, 21 Aug 2001 10:19:54 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZFBy-0004iV-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 10:19:54 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15ZFBx-000NRY-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 10:19:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ramakrishna Gummadi Cc: namedroppers@ops.ietf.org Subject: Re: DNSSec NXT records References: From: Derek Atkins Date: 21 Aug 2001 09:11:02 -0400 In-Reply-To: Ramakrishna Gummadi's message of "Mon, 20 Aug 2001 11:39:26 -0700 (PDT)" Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ramakrishna Gummadi writes: > This is basically a Brands/Okamoto algorithm whose security has been > proven elsewhere. Its attractiveness here is its ability to create > "self-certifying" tld's. > One can think of the entire scheme as an public key mechanism that binds > names to keys tighter than alternate schemes using explicit certificates > would. > > Any feedback is appreciated. While a clever algorithm, this presents a number of problems (mostly operational): - The root zone has complete power over everyone (and knows everyone's private key) - Nobody can secure their own zone until the root buys into the process. - Anyone who wants to secure their zone must wait until they are handed their key by the root, which means they cannot pre-sign their data. - Re-Keying is a nightmare. You effectively have to rekey everyone at once, and somehow have to tell all clients the new 'N' or 'H' values. - If 'N' is ever broken, it is hell in a handbasket to recover. Keep in mind that the 'global N' would be a mighty appealing target. Personally, I don't think the problems with DNSSec stem from the amount of data stored in the DNS, or the size of KEY records or anything like that. Yes, the 512-byte problem _is_ a problem, but that's easily surmountable. I don't think we need (or want) to change the current KEY/SIG definitions or uses much, we just need to solve the delegation-point problem. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 21 15:04:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28252 for ; Tue, 21 Aug 2001 15:04:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZGfF-0009J6-00 for namedroppers-data@psg.com; Tue, 21 Aug 2001 11:54:13 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZGfE-0009Iz-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 11:54:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15ZGfD-000NUt-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 11:54:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Aug 2001 08:41:16 -0700 (PDT) From: Ramakrishna Gummadi To: Dan Massey cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-delegation-signer-01 In-Reply-To: <20010820190101.A1318@bb.nge.isi.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > blackhole your zone if you aren't under attack > make it easier to spoof your data if you are under attack I completely agree. This is a problem in any mechanism where parent stores any kind of signatures over child data, but can not immediately synchronize with the child after child key compromise. One solution to this could be for the child itself to announce key compromise into its name servers. The idea is that packet hijacking (either removing/redirecting packets from wire, or a man-in-the-middle attack) is MUCH harder (although by no means impossible) than spoofing or introducing bogus packets. This way, the resolver (or a cache server) would get both bogus info signed under the compromised key introduced by the hacker as well as revocation information signed under the compromised key from the legitimate server. By preferring and caching such revocation info, servers can protect themselves from bogus info. Thus, the attacker would be successful under this model only for the first query, even after compromising the key and spoofing replies. BTW, has there been any discussion on impact of DoS attacks on DNSSec in general? If someone can even observe DNSSec-enabled query requests and spoof replies, he can make life miserable for a resolver/cache... -ramki to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 21 15:07:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28367 for ; Tue, 21 Aug 2001 15:07:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZGdN-0009D0-00 for namedroppers-data@psg.com; Tue, 21 Aug 2001 11:52:17 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZGdM-0009Cu-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 11:52:16 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15ZGdL-000NUl-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 11:52:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <20010820190101.A1318@bb.nge.isi.edu> References: ; from lewis@tislabs.com on Mon, Aug 20, 2001 at 04:32:27PM -0400 ; <20010808112314.A10365@bb.nge.isi.edu> <20010808182611.A11259@bb.nge.isi.edu> Date: Tue, 21 Aug 2001 10:54:01 -0400 To: Dan Massey From: Edward Lewis Subject: Re: draft-ietf-dnsext-delegation-signer-01 Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'll try to restate myself. Under normal conditions, the keys indicated in the parent-held DS RR set are a superset of the keys is use in the child zone. Under a normal key change, the keys indicated in the parent-held DS RR set include a subset of keys in retirement, a subset of keys in current use and a subset of keys to be used in the future. (Note that a set may be empty.) (The two paragraphs above are actually the same, I just put more detail in the key change to be more explicit.) Under an emergency condition, things are a bit different. There are a few different situations that may arise. Case 1. The child zone has lost the zone keys. (E.g., disk crash, no backups.) Case 2. The child zone suspects someone has guessed or seen the private keys. Case 3. Some one is spoofing data without bothering to guess the key. In case 1, the child needs to create new zone keys, perhaps retype in zone data, and fire the administrator. In the moment of time that the child signs the new zone and is trying to contact the parent, the DS RR set of keys and child set of keys do not agree. Eventually that will be fixed, but in the mean time, the sets are not in agreement. In case 2, all bets are off. Because DNS does not have a means to revoke data, nor does DNSSEC add any revocation service, as long as the previous DS RR set is in a cache somewhere, an attacker can continue to spoof data. IMHO, it would be wise if the child simply dumped the bad keys and regenerated new ones and immediately started to use the new keys, then contact the parent. Of course this means that no resolver will trust the child at this moment in time - but during an emergency, its not always possible to maintance a state of grace. In case 3, the appearance to the resolver is the same as case 1 with the exception that this is a persistent error (no eventual reconcilliation). In case 1, there is a temporary blackholing of the child zone. In case 3, there is a conflict between persistently failing data and perhaps some of the right data getting through. In case 2, the attacker is able to convince some resolvers that it is sending the right data - until the old DS RR set vanishes. I suppose yet another exercise is: Case 1: Query, followed by one unvalidated response. Case 2a: Query, followed by multiple validated responses Case 2b: same as in case 3... Case 3: Query, followed by an unvalidated response and a valid response. In case 1, the resolver should accept the lone response. In case 2a (pre-discovery), the resolver should pick the right one. In case 2b, the resolver should pick the invalid one. In case 3, the resolver should pick the valid one. (Notice the inconsistency.) There's no clear "right thing to do." Perhaps if in case 2, the new keys aren't used, then case 2b never arises. But you are still under a potentially successful attack before falling into case 1. .... Looking at this, I can't justify the use of a "MUST" when linking the set of keys indicated by the DS RR set and the keys used to sign the child zone. It is obvious that in normal situations the DS RR set is supposed to indicate the child's zone keys. But given case 1 of the emergency, the child cannot be in compliance with this MUST. BTW, what is the penalty for failing to comply with the MUST? A US$500 fine? ;) My problem with the MUST is that I can't see it as a testable feature of the software implementing this record. I understand the intent, but I think the use of MUST is wrong. .... My point here is: The MUST requiring the DS RR set to have the child zone keys is misplaced and an untestable requirement. Emergency processing in DNS is a mess, and DNSSEC can't *completely* clean this up. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 21 15:13:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28764 for ; Tue, 21 Aug 2001 15:13:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZGnI-0009jj-00 for namedroppers-data@psg.com; Tue, 21 Aug 2001 12:02:32 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZGnH-0009jZ-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 12:02:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15ZGnG-000NVI-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 12:02:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Aug 2001 12:23:57 -0400 From: Dan Massey To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-delegation-signer-01 Message-ID: <20010821122357.A2185@bb.nge.isi.edu> References: ; ; <20010808112314.A10365@bb.nge.isi.edu> <20010808182611.A11259@bb.nge.isi.edu> <20010820190101.A1318@bb.nge.isi.edu> In-Reply-To: ; from lewis@tislabs.com on Tue, Aug 21, 2001 at 10:54:01AM -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, August 21, 2001 at 10:54AM, Ed Lewis wrote: | | My point here is: The MUST requiring the DS RR set to have the child zone | keys is misplaced and an untestable requirement. Emergency processing in | DNS is a mess, and DNSSEC can't *completely* clean this up. | There is no magical untestable requirement being added here and no attempt to clean up anything after emergencies. The use of the MUST simply reflects what is actually required to make the zone accessible to a resolver. The text says: DS records MUST only appear at secure delegations in the parent zone. The records list the child's keys and at least one of these keys MUST sign the child's key set. Insecure delegation MUST NOT have a DS record. Secure delegations MUST have at least one DS record. The presence of one or more DS records MUST be considered an indication that the child zone is secure. I strongly object to replacing any of the MUSTs with SHOULD. If you fail to follow any of these MUSTs, then there is a real penalty. The penalty is that you blackhole your zone and make it easier for others to spoof you. Failing to follow the above MUSTs defeats the purpose of DNS since your data becomes inaccessilbe and defeats the purpose of DNSSEC since it becomes easier to spoof data. Adding a SHOULD instead of a MUST implies that there are some rare scenarios where it would be okay to deviate from the above text. There are no such scenarios. I could live with the following text that removes the MUST but conveys the same basic instructions to zones: DS records MUST only appear at secure delegations in the parent zone. The records list the child's keys. If none of these keys are used sign the child's key set, then the child zone data is not accessible to any resolvers and the child zone is more vulnerable to spoofing attacks. Insecure delegation MUST NOT have a DS record. Secure delegations MUST have at least one DS record. The presence of one or more DS records MUST be considered an indication that the child zone is secure. Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 21 15:21:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28982 for ; Tue, 21 Aug 2001 15:21:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZGx5-000AIS-00 for namedroppers-data@psg.com; Tue, 21 Aug 2001 12:12:39 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZGx5-000AIL-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 12:12:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15ZGx3-000NW0-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 12:12:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Aug 2001 10:57:19 -0700 (PDT) From: Bernard Aboba To: Thomas Narten cc: namedroppers@psg.com Subject: Re: Sense of the WG: mDNS configuration? In-Reply-To: <200108211739.f7LHdPF02566@cichlid.adsl.duke.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This strikes me somewhat as comparing apples to oranges. The three > choices above do not do the same thing, so if the goal is to pick one, > I would back up and ask: Can we get some agreement on what problem > needs to be solved? I suspect that a choice of one approach over the > other reflects at least partially disagreement on what the actual > problem is that folks think is being addressed. > Good point. My understanding was that configuration is attempting to provide the following information: a. Whether mDNS is to be used at all. b. If it is to be used, the order in which it is used relative to other alternatives (e.g. unicast DNS first, then mDNS) c. For the future, it would be useful to be able to control the scope used in mDNS (e.g. linklocal vs. wider scope). This isn't something we care about now, but the configuration choice we make shouldn't preclude this down the road. It is also desirable that configuration be possible in the following scenarios: * IPv6 stateless auto-configuration (e.g. no DHCPv6 server) * IPv6 stateful configuration (e.g. DHCPv6) * IPv4 w/DHCPv4 * IPv4 or IPv6 with local configuration to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 21 15:22:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28993 for ; Tue, 21 Aug 2001 15:22:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZGvE-000AB5-00 for namedroppers-data@psg.com; Tue, 21 Aug 2001 12:10:44 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZGvE-000AAz-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 12:10:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15ZGvD-000NVt-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 12:10:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108211739.f7LHdPF02566@cichlid.adsl.duke.edu> To: Bernard Aboba cc: namedroppers@psg.com Subject: Re: Sense of the WG: mDNS configuration? In-Reply-To: Message from Bernard Aboba of "Sat, 18 Aug 2001 17:16:29 PDT." Date: Tue, 21 Aug 2001 13:39:25 -0400 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > At IETF 51, we had a discussion relating to configuration of mDNS. A > number of alternatives were discussed, including: > Domain Searchlist (draft-aboba-dhc-domsearch-05.txt) > mDNS enable (draft-guttman-dhc-mdns-enable-01.txt) > Name Service Searchlist (RFC 2937) > Note that each of these alternative approaches allows for local > configuration, in addition to control via a DHCP option. > This is a request for a "sense of the WG" on which alternative should be > pursued. Please post your opinion to the list, along with a few words on > why you think your choice makes sense. This strikes me somewhat as comparing apples to oranges. The three choices above do not do the same thing, so if the goal is to pick one, I would back up and ask: Can we get some agreement on what problem needs to be solved? I suspect that a choice of one approach over the other reflects at least partially disagreement on what the actual problem is that folks think is being addressed. Thomas to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 21 18:21:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02731 for ; Tue, 21 Aug 2001 18:21:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZJgu-000JOB-00 for namedroppers-data@psg.com; Tue, 21 Aug 2001 15:08:08 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15ZJgu-000JO5-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 15:08:08 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15ZJgl-000New-00 for namedroppers@ops.ietf.org; Tue, 21 Aug 2001 15:07:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Aug 2001 15:04:13 -0700 (PDT) From: Ramakrishna Gummadi To: Dan Massey cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-delegation-signer-01 In-Reply-To: <20010821174408.A2638@bb.nge.isi.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | One solution to this could be for the child itself to announce key > | compromise into its name servers. The idea is that packet > | hijacking > | (either removing/redirecting packets from wire, or a man-in-the-middle > | attack) is MUCH > | harder (although by no means impossible) than spoofing or introducing > | bogus packets. This way, the resolver (or a cache server) would get both > | bogus info signed under the compromised key introduced by the hacker as > | well as revocation information signed under the compromised key from the > | legitimate server. By preferring and caching such revocation info, servers > | can protect themselves from bogus info. > | > | Thus, the attacker would be successful under this model only for the > | first query, even after compromising the key and spoofing replies. > | > > Interesting idea... so you would add a new revocation record? That's what I propose---a new revocation record that would be published by the child and would be in effect until the parent changes the key. We can exploit DNS's "pull" model, and even if the attacker caches and spoofs data using compromised key, the presence of a "revocation key" record returned in the legitimate client's answer would render attackers data useless in most cases. Note that revocation is not an issue in the DNSSec rfc, but I think a clean delegation scheme as described in draft-ietf-dnsext-delegation-signer-01 offers enough operational benefits to outweigh the cost of an extra signature verification. I plan to write up a short note with the exact details on how to support revocation in this case. cheers, ramki to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 22 17:40:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24623 for ; Wed, 22 Aug 2001 17:40:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZfP1-000IJr-00 for namedroppers-data@psg.com; Wed, 22 Aug 2001 14:19:07 -0700 Received: from roam.psg.com ([147.28.0.10]) by psg.com with esmtp (Exim 3.33 #1) id 15ZfP0-000IJl-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 14:19:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15ZatF-000NrR-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 09:30:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Thomas Narten cc: Bernard Aboba , namedroppers@psg.com Subject: Re: Sense of the WG: mDNS configuration? In-Reply-To: <200108211739.f7LHdPF02566@cichlid.adsl.duke.edu> References: <200108211739.f7LHdPF02566@cichlid.adsl.duke.edu> Date: Wed, 22 Aug 2001 14:40:31 +0700 Message-ID: <1489.998466031@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 21 Aug 2001 13:39:25 -0400 From: Thomas Narten Message-ID: <200108211739.f7LHdPF02566@cichlid.adsl.duke.edu> | > Domain Searchlist (draft-aboba-dhc-domsearch-05.txt) | > mDNS enable (draft-guttman-dhc-mdns-enable-01.txt) | > Name Service Searchlist (RFC 2937) | This strikes me somewhat as comparing apples to oranges. I don't think so. | The three choices above do not do the same thing, Not in general, but for the issue here, they're being bent (to greater or lesser degrees) into answering the same question. The issue is which of those we should use to get the answer. | so if the goal is to pick one, | I would back up and ask: Can we get some agreement on what problem | needs to be solved? Bernard replied to that already - but I don't think there was ever any real question over what the issue was (why the above question was asked). | I suspect that a choice of one approach over the | other reflects at least partially disagreement on what the actual | problem is that folks think is being addressed. I doubt it. I think it is more along the lines of what else comes for free when one of the choices is adopted, and what else gets lost when one of the choices is adopted, and the relative priorities people place on those. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 22 17:42:37 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24642 for ; Wed, 22 Aug 2001 17:42:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZfVg-000IWK-00 for namedroppers-data@psg.com; Wed, 22 Aug 2001 14:26:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ZfVg-000IWE-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 14:26:00 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ZfVg-000Ezc-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 14:26:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <004001c12b17$97c50c00$b9370681@antd.nist.gov> From: "Scott Rose" To: "Ramakrishna Gummadi" , "Dan Massey" Cc: References: Subject: Re: draft-ietf-dnsext-delegation-signer-01 Date: Wed, 22 Aug 2001 10:34:46 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Didn't this idea come up some time ago? I don't think anyone suggested a "revocation RR", but the idea of adding a revocation list to DNS was suggested. I think it was because the idea was a full revocation list (all the KEYs ever used, then expired by the zone - which makes a large list). The other point brought up was that most applications don't check revocation lists anyway, so what's the point ;-) This new revocation record will be short lived (i.e. removed from the zone after a period of time) or be persistant of all expired KEYs? What's stopping an attacker from deleting the revocation RR in transit? Scott ----- Original Message ----- From: "Ramakrishna Gummadi" To: "Dan Massey" Cc: Sent: Tuesday, August 21, 2001 6:04 PM Subject: Re: draft-ietf-dnsext-delegation-signer-01 > > | One solution to this could be for the child itself to announce key > > | compromise into its name servers. The idea is that packet > > | hijacking > > | (either removing/redirecting packets from wire, or a man-in-the-middle > > | attack) is MUCH > > | harder (although by no means impossible) than spoofing or introducing > > | bogus packets. This way, the resolver (or a cache server) would get both > > | bogus info signed under the compromised key introduced by the hacker as > > | well as revocation information signed under the compromised key from the > > | legitimate server. By preferring and caching such revocation info, servers > > | can protect themselves from bogus info. > > | > > | Thus, the attacker would be successful under this model only for the > > | first query, even after compromising the key and spoofing replies. > > | > > > > Interesting idea... so you would add a new revocation record? > > That's what I propose---a new revocation record that would be published by > the child and would be in effect until the parent changes the key. We can > exploit DNS's "pull" model, and even if the attacker caches and > spoofs data using compromised key, the presence of a "revocation > key" record returned in the legitimate client's answer would render > attackers data useless in most cases. > > Note that revocation is not an issue in the DNSSec rfc, > but I think a clean delegation scheme as > described in draft-ietf-dnsext-delegation-signer-01 > offers enough > operational benefits to outweigh the cost of an extra signature > verification. I plan to write up a short note with the exact details on > how to support revocation in this case. > > cheers, > ramki > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 23 00:27:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01968 for ; Thu, 23 Aug 2001 00:27:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Zlqd-0001VH-00 for namedroppers-data@psg.com; Wed, 22 Aug 2001 21:12:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15Zlqd-0001VB-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 21:12:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15Zlqd-000La3-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 21:12:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <004001c12b17$97c50c00$b9370681@antd.nist.gov> References: Date: Wed, 22 Aug 2001 21:13:36 -0400 To: "Ramakrishna Gummadi" From: Edward Lewis Subject: dns&revocation, was Re: draft-...-delegation-signer-01 Cc: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit IMHO, DNS != PKI, and we shouldn't make it one. There are many reasons why I feel this way. Probably the most basic is the observation that a lookup service, such as DNS, is so critical to the operations of the distributed system surrounding it that we need to keep it as simple as possible. This should be done to limit the chance the service will fail (principly by keeping the implementation software simple). Note that what constitutes simplicity is poorly defined. DNS as of RFC 1035 (and clarifications such as 2181) is much simpler than DNS + DNSSEC and/or DNS + A6. But the services added by DNSSEC and A6 are (argueably) simple enough and important enough to stretch the mission a bit more. Augmenting DNS to become a PKI is not so simple, take for example the PKIX WG documents and try "porting" them to DNS. (Some of the document titles are longer than DNS drafts. :)) Note: I don't intend to make the claim that A6 is a must do for DNS - especially not in this thread - but it is an example of a recent effort to significantly augment DNS. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 23 00:27:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01978 for ; Thu, 23 Aug 2001 00:27:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Zlq7-0001V1-00 for namedroppers-data@psg.com; Wed, 22 Aug 2001 21:11:31 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15Zlq7-0001Uv-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 21:11:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15Zlq7-000LZ5-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 21:11:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Wed, 22 Aug 2001 18:01:47 -0700 Message-ID: From: "Christian Huitema" To: "Jun-ichiro itojun Hagino" , "Robert Elz" Cc: , , , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In retrospect, I believe I made at least one mistake when writing the A6 RFC, which is going for a "full recursion" model. This triggers all kinds of "interesting" possibilities. Going for a site model would have been more appropriate: basically, one could request that the "prefix domain name" points to a set of AAAA records, allowing for exactly one level of indirection.=20 -- Christian Huitema to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 23 00:27:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01989 for ; Thu, 23 Aug 2001 00:27:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15ZllF-0001PB-00 for namedroppers-data@psg.com; Wed, 22 Aug 2001 21:06:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15ZllF-0001P5-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 21:06:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15ZllE-000LQ6-00 for namedroppers@ops.ietf.org; Wed, 22 Aug 2001 21:06:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 22 Aug 2001 17:02:57 -0700 (PDT) From: Ramakrishna Gummadi To: Scott Rose cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-delegation-signer-01 In-Reply-To: <004001c12b17$97c50c00$b9370681@antd.nist.gov> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Aug 2001, Scott Rose wrote: > Didn't this idea come up some time ago? I don't think anyone suggested a > "revocation RR", but the idea of adding a revocation list to DNS was > suggested. I think it was because the idea was a full revocation list (all > the KEYs ever used, then expired by the zone - which makes a large list). > The other point brought up was that most applications don't check revocation > lists anyway, so what's the point ;-) In this case, the resolver/cache would get a positive affirmation of revocation for just the name being resolved, in place of further resolution information. Such a "revocation" is an answer produced on-demand that aborts the secure name-resolution process, and applications don't have to be aware of all revocations in the world. Therefore, revocation *decreases* availability temporarily to avoid the risk of being redirected to bogus servers. Such a behavior may be deemed acceptable for some servers (mail, etc.) but not for others, and it can be a policy choice at the client/resolver whether it wants to heed this info. > > This new revocation record will be short lived (i.e. removed from the zone > after a period of time) or be persistant of all expired KEYs? The child does revocation only to convey the information that the parent has not yet been able to host a signature over the newly created key (in other words, the parent still holds signature over a compromised key), and, as such, no revocation history info need be stored. The child deletes a revocation record permanently once the parent hosts the new signature. > What's > stopping an attacker from deleting the revocation RR in transit? The assumption here is that packets are much harder to delete/hijack, rather than spoof/watch/copy. This does not offer any provable/perfect security because it relies on the physical media (wire/wireless) properties, and on "reversibility" property of routing. However, note that even a large chunk of DNSSec relies on this---for example, if a hacker can subvert routing, then the attacked host can still end up talking to bogus hacker-controlled web servers and mail servers (or any server that does not use end-to-end authentication) even though these addresses are obtained securely. cheers, ramki > Scott > > ----- Original Message ----- > From: "Ramakrishna Gummadi" > To: "Dan Massey" > Cc: > Sent: Tuesday, August 21, 2001 6:04 PM > Subject: Re: draft-ietf-dnsext-delegation-signer-01 > > > > > | One solution to this could be for the child itself to announce key > > > | compromise into its name servers. The idea is that packet > > > | hijacking > > > | (either removing/redirecting packets from wire, or a man-in-the-middle > > > | attack) is MUCH > > > | harder (although by no means impossible) than spoofing or introducing > > > | bogus packets. This way, the resolver (or a cache server) would get > both > > > | bogus info signed under the compromised key introduced by the hacker > as > > > | well as revocation information signed under the compromised key from > the > > > | legitimate server. By preferring and caching such revocation info, > servers > > > | can protect themselves from bogus info. > > > | > > > | Thus, the attacker would be successful under this model only for the > > > | first query, even after compromising the key and spoofing replies. > > > | > > > > > > Interesting idea... so you would add a new revocation record? > > > > That's what I propose---a new revocation record that would be published by > > the child and would be in effect until the parent changes the key. We can > > exploit DNS's "pull" model, and even if the attacker caches and > > spoofs data using compromised key, the presence of a "revocation > > key" record returned in the legitimate client's answer would render > > attackers data useless in most cases. > > > > Note that revocation is not an issue in the DNSSec rfc, > > but I think a clean delegation scheme as > > described in draft-ietf-dnsext-delegation-signer-01 > > offers enough > > operational benefits to outweigh the cost of an extra signature > > verification. I plan to write up a short note with the exact details on > > how to support revocation in this case. > > > > cheers, > > ramki > > > > > > > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 23 11:33:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25882 for ; Thu, 23 Aug 2001 11:33:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15Zw2Z-000Cg3-00 for namedroppers-data@psg.com; Thu, 23 Aug 2001 08:05:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15Zw2Y-000Cfw-00 for namedroppers@ops.ietf.org; Thu, 23 Aug 2001 08:05:02 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15Zw2Y-000EAc-00 for namedroppers@ops.ietf.org; Thu, 23 Aug 2001 08:05:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <00a201c12bd7$cd1bd1c0$b9370681@antd.nist.gov> From: "Scott Rose" To: References: Subject: Re: draft-ietf-dnsext-delegation-signer-01 Date: Thu, 23 Aug 2001 09:30:39 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I guess I'm with Ed on this point when he says that DNS was designed as a lookup service, not a PKI. Putting more PKI features in DNS requires more coding on the server and resolver end, and we'll end up with a bloated protocol too. "Key revocation" in DNS has usually always meant "low TTL values in case of compromise". And if the DS record is used, the parent will be ultimately reponsible for stating the security status of the child zone. The best use (as I see it) of a revocation RR would be when the child has changed KEYs (emergancy) and the parent hasn't updated it's DS record to reflect that yet. IMHO, Since there are many security features DNS lacks, forcing it to try and be more like a PKI is counter productive. Scott =============================================================== Scott Rose Advanced Network Technologies Division NIST ph: 301-975-8439 fax: 301-590-0932 http://www.nist.gov =============================================================== ----- Original Message ----- From: "Ramakrishna Gummadi" To: "Scott Rose" Cc: Sent: Wednesday, August 22, 2001 8:02 PM Subject: Re: draft-ietf-dnsext-delegation-signer-01 > On Wed, 22 Aug 2001, Scott Rose wrote: > > > Didn't this idea come up some time ago? I don't think anyone suggested a > > "revocation RR", but the idea of adding a revocation list to DNS was > > suggested. I think it was because the idea was a full revocation list (all > > the KEYs ever used, then expired by the zone - which makes a large list). > > The other point brought up was that most applications don't check revocation > > lists anyway, so what's the point ;-) > > In this case, the resolver/cache would get a positive affirmation of > revocation for just the name being resolved, in place of further > resolution information. Such a "revocation" is an answer produced > on-demand that aborts the secure name-resolution process, and applications > don't have to be aware of all revocations in > the world. Therefore, > revocation *decreases* availability temporarily to avoid the risk of > being redirected to bogus servers. Such a behavior may be deemed > acceptable for some servers (mail, etc.) but not for others, and it > can be a policy choice at the client/resolver whether it wants to heed > this info. > > > > > This new revocation record will be short lived (i.e. removed from the zone > > after a period of time) or be persistant of all expired KEYs? > > The child does revocation only to convey the information that the parent > has not yet been able to host a signature over the newly created key (in > other words, the parent still holds signature over a compromised key), > and, as such, no revocation history info need be stored. The child > deletes a revocation record permanently once the > parent hosts the new signature. > > > > What's > > stopping an attacker from deleting the revocation RR in transit? > > The assumption here is that packets are much harder to delete/hijack, > rather than spoof/watch/copy. This does not offer any provable/perfect > security because it relies on the physical media > (wire/wireless) properties, and on > "reversibility" property of routing. However, note that even > a large chunk of DNSSec relies on this---for example, if a hacker can > subvert routing, then the attacked host can still end up talking to bogus > hacker-controlled web servers and mail servers (or any server that does > not use end-to-end authentication) even though these addresses are obtained > securely. > > cheers, > ramki > > > Scott > > > > ----- Original Message ----- > > From: "Ramakrishna Gummadi" > > To: "Dan Massey" > > Cc: > > Sent: Tuesday, August 21, 2001 6:04 PM > > Subject: Re: draft-ietf-dnsext-delegation-signer-01 > > > > > > > > | One solution to this could be for the child itself to announce key > > > > | compromise into its name servers. The idea is that packet > > > > | hijacking > > > > | (either removing/redirecting packets from wire, or a man-in-the-middle > > > > | attack) is MUCH > > > > | harder (although by no means impossible) than spoofing or introducing > > > > | bogus packets. This way, the resolver (or a cache server) would get > > both > > > > | bogus info signed under the compromised key introduced by the hacker > > as > > > > | well as revocation information signed under the compromised key from > > the > > > > | legitimate server. By preferring and caching such revocation info, > > servers > > > > | can protect themselves from bogus info. > > > > | > > > > | Thus, the attacker would be successful under this model only for the > > > > | first query, even after compromising the key and spoofing replies. > > > > | > > > > > > > > Interesting idea... so you would add a new revocation record? > > > > > > That's what I propose---a new revocation record that would be published by > > > the child and would be in effect until the parent changes the key. We can > > > exploit DNS's "pull" model, and even if the attacker caches and > > > spoofs data using compromised key, the presence of a "revocation > > > key" record returned in the legitimate client's answer would render > > > attackers data useless in most cases. > > > > > > Note that revocation is not an issue in the DNSSec rfc, > > > but I think a clean delegation scheme as > > > described in draft-ietf-dnsext-delegation-signer-01 > > > offers enough > > > operational benefits to outweigh the cost of an extra signature > > > verification. I plan to write up a short note with the exact details on > > > how to support revocation in this case. > > > > > > cheers, > > > ramki > > > > > > > > > > > > > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > > the word 'unsubscribe' in a single line as the message text body. > > > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 24 22:38:45 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19988 for ; Fri, 24 Aug 2001 22:38:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15aT0F-000Gnl-00 for namedroppers-data@psg.com; Fri, 24 Aug 2001 19:16:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15aT0E-000Gne-00 for namedroppers@ops.ietf.org; Fri, 24 Aug 2001 19:16:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15aT0E-0004c5-00 for namedroppers@ops.ietf.org; Fri, 24 Aug 2001 19:16:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B870690.66D19286@email.mot.com> Date: Sat, 25 Aug 2001 11:59:44 +1000 From: Aidan Williams To: Bernard Aboba CC: Thomas Narten , namedroppers@psg.com Subject: mdns configuration / .local.arpa. namespace definition References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Good point. My understanding was that configuration is attempting to > provide the following information: > > a. Whether mDNS is to be used at all. > b. If it is to be used, the order in which it is used relative to other > alternatives (e.g. unicast DNS first, then mDNS) > c. For the future, it would be useful to be able to control the scope > used in mDNS (e.g. linklocal vs. wider scope). This isn't something > we care about now, but the configuration choice we make shouldn't > preclude this down the road. > An observation: none of this configuration relates to the DNS namespace(s) themselves, just to the way they are looked up. Therefore, I am not in favour of overloading the DNS search list so that an entry of .local.arpa. means "use multicast" for DNS requests. Keeping the above configuration information away from the DNS searchlist is a good idea. So far, I haven't seen a clear description of the characteristics of the .local.arpa. namespace itself. Most discussion of it seems to be related to turning off/on multicast lookups. I see the namespace like this: - The .local.arpa. suffix is *not* globally unique. (a nice clear definition of this somewhere would be a good thing) - The .local.arpa. namespace is analogous to link-local, site-local or rfc1928 addressing. - The .local.arpa. namespace is useful independently of whether multicast lookups are used. Is there a good reason to preclude unicast lookup in this namespace? A standard configured DNS server could use these local names (one could imagine entries like pop3, smtp, etc in there). It could be a sensible default place to put non-global scoped address mappings. Zeroconf networks (which may not have a global DNS suffix) can use this suffix too. regards aidan ____ :wq! to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 24 22:50:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20189 for ; Fri, 24 Aug 2001 22:50:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15aTLM-000H7T-00 for namedroppers-data@psg.com; Fri, 24 Aug 2001 19:38:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15aTLM-000H7N-00 for namedroppers@ops.ietf.org; Fri, 24 Aug 2001 19:38:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15aTLM-0005ib-00 for namedroppers@ops.ietf.org; Fri, 24 Aug 2001 19:38:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B870F63.E7778FB4@email.mot.com> Date: Sat, 25 Aug 2001 12:37:23 +1000 From: Aidan Williams To: Robert Elz CC: Bernard Aboba , namedroppers@psg.com, Erik Guttman Subject: Re: Sense of the WG: mDNS configuration? References: <1134.998208701@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > > Date: Sat, 18 Aug 2001 17:16:29 -0700 (PDT) > From: Bernard Aboba > Message-ID: > > | Domain Searchlist (draft-aboba-dhc-domsearch-05.txt) > | mDNS enable (draft-guttman-dhc-mdns-enable-01.txt) > | Name Service Searchlist (RFC 2937) > > Either of the latter two - the mdns-enable option is basically just > a special case of 2937, in a sense - but as I read 2937, it would need > another DNS option defined anyway, so its option number can be used in > the 2937 option (there's no current dhcp option giving the addresses > of the servers for mDNS .. for obvious reasons). > > That is, adapting 2937 is probably more work than it is worth, so mdns-enable > is probably the better choice. > I agree that RFC2937 is the right concept, but I don't understand why it is a great deal of work to extend. Extending RFC2937 has the advantage that mDNS can be slotted in between whatever name lookup services are defined by it (e.g. NIS+, NetBIOS, ..). What would you do if you got *both* and mdns-enable option, and an RFC2937 option? I can think of two options for extending 2937: 1. add an RFC2937 option for mDNS, and use a seperate DHCP option to define the scopes. Doesn't seem to buy much else other than "getting with the existing program". Allows mDNS to be slotted in with the other zoo of name services. 2. add RFC2937 options for each mDNS scope to be checked. My initial thought was that this was a dumb idea because there might be a profusion of the same option, but with every random scope. However, there are probably only two relevant multicast scopes: link-local and site-local. This would basically incorporate the mdns-enable work into the RFC2937 framework. > dhc-domsearch (with the magic string) is just wrong - overloads an option > with a totally irrelevant meaning. > I whole-heartedly agree. > When there's no dhcp server, those can > be configured manually (or simply default to whatever the OS vendor > decides is best - perhaps based upon an IETF recommendation). > In the absence of configuration information, a sensible default is to try mdns. There isn't much else you can do (other than fail). For IPv6, it seems that just about all DHCP options can be re-specified as "stateless" router advert options, or new ICMP messages. What would prevent this one going the same way? regards aidan ____ :wq! to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 25 15:07:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13859 for ; Sat, 25 Aug 2001 15:07:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15aiJT-0004i8-00 for namedroppers-data@psg.com; Sat, 25 Aug 2001 11:37:43 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.33 #1) id 15aiJS-0004i2-00 for namedroppers@ops.ietf.org; Sat, 25 Aug 2001 11:37:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15aiJS-0001hf-00 for namedroppers@ops.ietf.org; Sat, 25 Aug 2001 11:37:42 -0700 Date: Sat, 25 Aug 2001 11:26:57 -0700 (PDT) From: Bernard Aboba To: Aidan Williams cc: Robert Elz , namedroppers@psg.com, Erik Guttman Subject: Re: Sense of the WG: mDNS configuration? In-Reply-To: <3B870F63.E7778FB4@email.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > For IPv6, it seems that just about all DHCP options can be re-specified > as "stateless" router advert options, or new ICMP messages. > What would prevent this one going the same way? Nothing prevents this. I might even argue that in "Inform mode" (e.g. where no address is being requested), DHCPv6 already enables "stateless" response by routers, so there is no new work required. But I am sure that there are many who don't agree with me ;) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 27 20:20:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04919 for ; Mon, 27 Aug 2001 20:20:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bWGY-000JmE-00 for namedroppers-data@psg.com; Mon, 27 Aug 2001 16:58:02 -0700 Received: from [210.61.172.63] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bWGX-000Jm8-00 for namedroppers@ops.ietf.org; Mon, 27 Aug 2001 16:58:02 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bWGW-0004Pg-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 07:58:00 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B8AD7E1.B15242B9@daimlerchrysler.com> Date: Mon, 27 Aug 2001 19:29:37 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-delegation-signer-01 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit How about a more comprehensive approach: a cache-invalidation protocol extension, like NOTIFY except generalized to all record types, including the DNSSEC record types? Such an extension might also be able to at last deal with the "tiny TTLs for load balancing and/or failover" syndrome as well (since client implementors aren't exactly racing with each other to get SRV support added to their codebases). - Kevin Ramakrishna Gummadi wrote: > > blackhole your zone if you aren't under attack > > make it easier to spoof your data if you are under attack > > I completely agree. This is a problem in any mechanism where > parent stores any kind of signatures over child data, but can not > immediately synchronize with the child after child key compromise. > > One solution to this could be for the child itself to announce key > compromise into its name servers. The idea is that packet > hijacking > (either removing/redirecting packets from wire, or a man-in-the-middle > attack) is MUCH > harder (although by no means impossible) than spoofing or introducing > bogus packets. This way, the resolver (or a cache server) would get both > bogus info signed under the compromised key introduced by the hacker as > well as revocation information signed under the compromised key from the > legitimate server. By preferring and caching such revocation info, servers > can protect themselves from bogus info. > > Thus, the attacker would be successful under this model only for the > first query, even after compromising the key and spoofing replies. > > BTW, has there been any discussion on impact of DoS attacks on DNSSec in > general? If someone can even observe DNSSec-enabled query requests > and spoof replies, he can make life miserable > for a resolver/cache... > > -ramki > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 27 21:51:27 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07267 for ; Mon, 27 Aug 2001 21:51:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bXrB-000LHz-00 for namedroppers-data@psg.com; Mon, 27 Aug 2001 18:39:57 -0700 Received: from [210.61.172.63] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bXrA-000LHt-00 for namedroppers@ops.ietf.org; Mon, 27 Aug 2001 18:39:57 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bXr2-0004V7-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 09:39:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 28 Aug 2001 03:01:56 +0200 (CEST) From: Roy Arends To: Kevin Darcy Cc: Subject: Re: draft-ietf-dnsext-delegation-signer-01 In-Reply-To: <3B8AD7E1.B15242B9@daimlerchrysler.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 27 Aug 2001, Kevin Darcy wrote: > How about a more comprehensive approach: a cache-invalidation protocol > extension, like NOTIFY except generalized to all record types, including the > DNSSEC record types? Such an extension might also be able to at last deal > with the "tiny TTLs for load balancing and/or failover" syndrome as well > (since client implementors aren't exactly racing with each other to get > SRV support added to their codebases). And how do you discriminate between notifies ? i.e. which one do you accept, and which will be ignored ? Do you "broadcast" a notify or send one to each individual cache (providing that there is such a list). Regards, Roy Arends Nominum ------------- 0-14-023750-X dcrpt ths 43.0D.01 01.05.0C 84.18.03 8A.13.04 2D.0B.0A to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 27 23:04:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09326 for ; Mon, 27 Aug 2001 23:04:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bYzI-000MTA-00 for namedroppers-data@psg.com; Mon, 27 Aug 2001 19:52:24 -0700 Received: from [210.61.172.63] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bYzH-000MT4-00 for namedroppers@ops.ietf.org; Mon, 27 Aug 2001 19:52:23 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bYzE-0004YM-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 10:52:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B8B05C7.389C2818@daimlerchrysler.com> Date: Mon, 27 Aug 2001 22:45:27 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy Arends wrote: > On Mon, 27 Aug 2001, Kevin Darcy wrote: > > > How about a more comprehensive approach: a cache-invalidation protocol > > extension, like NOTIFY except generalized to all record types, including the > > DNSSEC record types? Such an extension might also be able to at last deal > > with the "tiny TTLs for load balancing and/or failover" syndrome as well > > (since client implementors aren't exactly racing with each other to get > > SRV support added to their codebases). > > And how do you discriminate between notifies ? i.e. which one do you > accept, and which will be ignored ? Do you "broadcast" a notify or send > one to each individual cache (providing that there is such a list). As a client, you accept a NOTIFY from whomever has the same credentials as the answer you originally accepted. You could use source address as "credentials", if you trust it, or some form of crypto (e.g. TSIG), or both. As an answerer, by default you'd send the NOTIFY to each cache that asked for it, when the data changes. The NOTIFYs should cascade backwards through nth-level caches and/or forwarders. Yes, this requires keeping state. But the saving grace is that older entries can be purged -- there's no point in keeping state about a client after the point at which the client should have expired the entry. In resource-emergency situations, answerers could fall back to tiny TTLs (no worse than the current situation) until such time as sufficient resources can be reclaimed to start storing state again. Maybe NOTIFY could even be extended so as to allow answer data to be included in the packet, subject to crypto-authentication. This would help reduce the number of transactions to a minimum. I think such an extension, in a finished form, could restore some much-needed balance between the need for dynamism, e.g. load-balancing, failover, quick key revocation, on the one hand, and the need, on the other, to conserve nameserver and/or network resources. Currently I think that balance is way out of whack. - Kevin P.S. I have other ulterior motives for allowing NOTIFY packets to be signed. I eventually want to enable slave auto-configuration via the receipt of NOTIFY packets, and obviously this requires a degree of trust as to their authenticity. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 28 06:33:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01196 for ; Tue, 28 Aug 2001 06:33:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bfoZ-0003T9-00 for namedroppers-data@psg.com; Tue, 28 Aug 2001 03:09:47 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bfoY-0003T3-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 03:09:46 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bfoX-0004fg-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 18:09:45 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) In-Reply-To: <3B8B05C7.389C2818@daimlerchrysler.com> References: <3B8B05C7.389C2818@daimlerchrysler.com> Date: Tue, 28 Aug 2001 13:31:51 +0700 Message-ID: <2890.998980311@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2001 22:45:27 -0400 From: Kevin Darcy Message-ID: <3B8B05C7.389C2818@daimlerchrysler.com> | As a client, you accept a NOTIFY from whomever has the same credentials | as the answer you originally accepted. No, you can't do that unless the credentials are verifiable. | You could use source address as "credentials", if you trust it, No, you can't - there's a big difference between receiving an answer to a question you sent before, where getting it fro the address you expect to get it from isn't proof it came from there, but isn't trivial to fake either (at the very least it needs packet snooping to be able to spot the query and send the bogus data at just the right time). Accepting a random message based just on the source address would be lunacy. | As an answerer, by default you'd send the NOTIFY to each cache that | asked for it, when the data changes. That's way too much state to keep - the only way a server could ever survive would be to force all the TTLs to such low values that caching would effectively be disabled everywhere. Busy servers are probably doing upwards of 100K queries / second these days (not so busy ones do tens of thousands). Retaining the IP address of the resolver (16 bytes for IPv6...) the expiry time issued (time reply was sent + TTL), and a pointer to the RR in question (or from it and a linked list to the next) and you're at 24 bytes/query (and I probably neglected stuff you need). That's 2.4MB a second. Give a 300 second (5 minute) TTL, and you have a state database that's 7GB big. No thanks (not to forcing the TTLs to be that low, nor to requiring that quantity of state). | I think such an extension, in a finished form, could restore some | much-needed balance between the need for dynamism, There should be no such need in the DNS. All the nonsense that is requiring it should be being done other ways. While it can be done without perverting the DNS design, then there's not much point objecting. But deliberately changing things so that stuff which was never intended to work can be made to work is definitely not the direction to head. | P.S. I have other ulterior motives for allowing NOTIFY packets to be signed. | I eventually want to enable slave auto-configuration via the receipt of | NOTIFY packets, and obviously this requires a degree of trust as to | their authenticity. Like much which seems obvious, this is false. NOTIFY now is just a hint that you might want to do something (zone transfer currently). That's all it needs to be for your proposal - when the secondary gets an unexpected NOTIFY, it can go check the primary, using whatever authentication it needs, determine if it is supposed to be configured as secondary for the zone, and if so, configure itself. If the NOTIFY turns out to be bogus, then you've wasted an authenticated query/response. While someone could bombard you with bogus NOTIFY packets, and consume resources, whether the resources are consumed doing an extra query, or whether they're consumed doing SIG validation on the NOTIFY packets doesn't seem like a difference worth arguing about. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 28 06:39:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01362 for ; Tue, 28 Aug 2001 06:39:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bg5O-0003lv-00 for namedroppers-data@psg.com; Tue, 28 Aug 2001 03:27:10 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bg5O-0003lp-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 03:27:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bg5H-0004h8-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 18:27:03 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) In-Reply-To: <3B8B05C7.389C2818@daimlerchrysler.com> References: <3B8B05C7.389C2818@daimlerchrysler.com> Date: Tue, 28 Aug 2001 15:13:02 +0700 Message-ID: <3217.998986382@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In my previous message, I think I made an order of magnitude error in my mental arithmetic, but that doesn't matter, the answer is still too big, and the TTL too small... kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 28 21:42:18 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26305 for ; Tue, 28 Aug 2001 21:42:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15btw9-000MGr-00 for namedroppers-data@psg.com; Tue, 28 Aug 2001 18:14:33 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15btw8-000MGl-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 18:14:32 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15btw8-0004px-00 for namedroppers@ops.ietf.org; Wed, 29 Aug 2001 09:14:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <3B8B05C7.389C2818@daimlerchrysler.com> References: Date: Tue, 28 Aug 2001 10:50:16 -0400 To: Kevin Darcy From: Edward Lewis Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In summary: please stop this madness! (;)) At 10:45 PM -0400 8/27/01, Kevin Darcy wrote: >As a client, you accept a NOTIFY from whomever has the same credentials as the >answer you originally accepted. You could use source address as >"credentials", >if you trust it, or some form of crypto (e.g. TSIG), or >both. Consider the most popular website in existence. (Off hand, I don't know/care which it is, but whatever it is...) How many caches would have it's A record? A lot! (I won't feign numbers.) That means the authoritative name servers each need, roughly, a lot of TSIGs. If you go for the IP address as credential option - we'll let's not even try to argue that from a security perspective (now that Windows will let you change the IP header bits in the latest OS release). >As an answerer, by default you'd send the NOTIFY to each cache that asked for >it, when the data changes. The NOTIFYs should cascade backwards through >nth-level caches and/or forwarders. A new DDOS vulnerability - just get a million drones to ask for an address from a server. The server then has to keep a list of everywhere the data went. >Yes, this requires keeping state. But the saving grace is that older entries >can be purged -- there's no point in keeping state about a client after the >point at which the client should have expired the entry. In resource-emergency >situations, answerers could fall back to tiny TTLs (no worse than the >current >situation) until such time as sufficient resources can be >reclaimed to start >storing state again. This assumes the remote caches (strictly) enforce the TTL's. Otherwise a should-have-been-revoked and should-have-been-retired-by-TTL record might still hang around because the record was assumed to have been retired. ('Course, caches might ignore the NOTIFY too.) >I think such an extension, in a finished form, could restore some much-needed >balance between the need for dynamism, e.g. load-balancing, failover, >quick key >revocation, on the one hand, and the need, on the other, to conserve >nameserver >and/or network resources. Currently I think that balance is way out of whack. I admire the desire, but remember that we are dealing with DNS, circa RFC 1035. Such an overhaul would be more work than the original system - and makeing this work in a backwards compatible fashion would be harder than starting from scratch (no data to back this up). >P.S. I have other ulterior motives for allowing NOTIFY packets to be signed. I >eventually want to enable slave auto-configuration via the receipt of NOTIFY >packets, and obviously this requires a degree of trust as to their >authenticity. I believe (I haven't checked) that NOTIFY's are covered by TSIG in BIND if the "server" statement is the configuration file. (Not too pick on a particular implementation in this protocol discussion list.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 29 00:30:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29172 for ; Wed, 29 Aug 2001 00:30:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bwkA-0000PR-00 for namedroppers-data@psg.com; Tue, 28 Aug 2001 21:14:22 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bwk9-0000PL-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 21:14:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bwk8-00051m-00 for namedroppers@ops.ietf.org; Wed, 29 Aug 2001 12:14:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B8C67E9.47023D35@daimlerchrysler.com> Date: Tue, 28 Aug 2001 23:56:25 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > In summary: please stop this madness! (;)) > > At 10:45 PM -0400 8/27/01, Kevin Darcy wrote: > >As a client, you accept a NOTIFY from whomever has the same credentials as the > >answer you originally accepted. You could use source address as > >"credentials", >if you trust it, or some form of crypto (e.g. TSIG), or > >both. > > Consider the most popular website in existence. (Off hand, I don't > know/care which it is, but whatever it is...) How many caches would have > it's A record? A lot! (I won't feign numbers.) > > That means the authoritative name servers each need, roughly, a lot of > TSIGs. Perhaps "the most popular website in existence" would use something more scalable than TSIG to establish the trustworthiness of every DNS-resolution of its name, if such a thing were desired and/or even possible. > If you go for the IP address as credential option - we'll let's not > even try to argue that from a security perspective (now that Windows will > let you change the IP header bits in the latest OS release). Pardon my naivete, but why is it any more dangerous to accept a NOTIFY based on IP address that says "hey, this data has changed!" than it is to accept the answer in the first place from that IP address? (I think kre tried to explain this, but I had trouble parsing that particular sentence). Because the hacker has more time in which to cook up a bogus packet? Is that it? > >As an answerer, by default you'd send the NOTIFY to each cache that asked for > >it, when the data changes. The NOTIFYs should cascade backwards through > >nth-level caches and/or forwarders. > > A new DDOS vulnerability - just get a million drones to ask for an address > from a server. The server then has to keep a list of everywhere the data > went. No, it doesn't *have* to keep a list that long. It could choose to limit the amount of state it keeps for any given RRset and/or from any given client and/or the total amount of state it keeps *period*. Let's not assume the stupidest possible implementation of such an extension. I've always interpreted RFC 1034/1035's admonition to "bound the amount of work done" to apply to maintenance of metadata as well as plain data, and this would be no exception. In any case, if a hacker has a million drones at his or her disposal, I think there is plenty of havoc they can wreak with or without this extension. > >Yes, this requires keeping state. But the saving grace is that older entries > >can be purged -- there's no point in keeping state about a client after the > >point at which the client should have expired the entry. In resource-emergency > >situations, answerers could fall back to tiny TTLs (no worse than the > >current >situation) until such time as sufficient resources can be > >reclaimed to start >storing state again. > > This assumes the remote caches (strictly) enforce the TTL's. Otherwise a > should-have-been-revoked and should-have-been-retired-by-TTL record might > still hang around because the record was assumed to have been retired. > ('Course, caches might ignore the NOTIFY too.) There's only so much one can do in the face of non-compliance. At least if you send a revocation downstream you give an opportunity for revocation to actually occur. If there's no mechanism for revocation at all, however, then you just have to buckle up and live with the potential for being spoofed for the lifetime of the compromised key. > >I think such an extension, in a finished form, could restore some much-needed > >balance between the need for dynamism, e.g. load-balancing, failover, > >quick key > >revocation, on the one hand, and the need, on the other, to conserve > >nameserver > >and/or network resources. Currently I think that balance is way out of whack. > > I admire the desire, but remember that we are dealing with DNS, circa RFC > 1035. Such an overhaul would be more work than the original system - and > makeing this work in a backwards compatible fashion would be harder than > starting from scratch (no data to back this up). Actually, we're not dealing with DNS, circa RFC 1035; we're dealing with post-EDNS0 DNS. This special "NOTIFY callback" or whatever you want to call it could be put under OPTION control (could you let me know if the answer to this question changes? roger, will do!) without freaking out any backlevel clients or servers. > >P.S. I have other ulterior motives for allowing NOTIFY packets to be signed. I > >eventually want to enable slave auto-configuration via the receipt of NOTIFY > >packets, and obviously this requires a degree of trust as to their > >authenticity. > > I believe (I haven't checked) that NOTIFY's are covered by TSIG in BIND if > the "server" statement is the configuration file. (Not too pick on a > particular implementation in this protocol discussion list.) Well, as a minor technical nit, the NOTIFY RFC forbids anything in the Additional Section (although it invites a "future revision" to lift the prohibition), so officially TSIG-signed NOTIFYs remain illegal. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 29 00:38:15 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29254 for ; Wed, 29 Aug 2001 00:38:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15bwtj-0000h4-00 for namedroppers-data@psg.com; Tue, 28 Aug 2001 21:24:15 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15bwti-0000gx-00 for namedroppers@ops.ietf.org; Tue, 28 Aug 2001 21:24:14 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bwth-000533-00 for namedroppers@ops.ietf.org; Wed, 29 Aug 2001 12:24:13 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B8C6DDF.2E6DBE76@daimlerchrysler.com> Date: Wed, 29 Aug 2001 00:21:51 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) References: <3B8B05C7.389C2818@daimlerchrysler.com> <2890.998980311@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: Mon, 27 Aug 2001 22:45:27 -0400 > From: Kevin Darcy > Message-ID: <3B8B05C7.389C2818@daimlerchrysler.com> > > | As a client, you accept a NOTIFY from whomever has the same credentials > | as the answer you originally accepted. > > No, you can't do that unless the credentials are verifiable. If one requires verification, sure. > | You could use source address as "credentials", if you trust it, > > No, you can't - there's a big difference between receiving an answer to > a question you sent before, where getting it fro the address you expect > to get it from isn't proof it came from there, but isn't trivial to fake > either (at the very least it needs packet snooping to be able to spot the > query and send the bogus data at just the right time). Sorry, parse error. Which two things are you contrasting here? > Accepting a random message based just on the source address would be lunacy. It wouldn't be lunacy if something like IPSEC were in force, or for casual use where perhaps the local security policy deems source-address-based authentication to be sufficient. I'm not saying source-address-based authentication is to be recommended in the general case. If it helps, forget I even included source address as a possible form of credentials. Instead, assume only crypto. > | As an answerer, by default you'd send the NOTIFY to each cache that > | asked for it, when the data changes. > > That's way too much state to keep - the only way a server could ever > survive would be to force all the TTLs to such low values that caching > would effectively be disabled everywhere. And how is this different from domain owners reducing the TTLs to ridiculously low values, which they are doing today? I don't see that this proposal is any worse, and it could make things better. > Busy servers are probably doing > upwards of 100K queries / second these days (not so busy ones do tens of > thousands). Retaining the IP address of the resolver (16 bytes for IPv6...) > the expiry time issued (time reply was sent + TTL), and a pointer to the > RR in question (or from it and a linked list to the next) and you're at 24 > bytes/query (and I probably neglected stuff you need). That's 2.4MB > a second. Give a 300 second (5 minute) TTL, and you have a state database > that's 7GB big. No thanks (not to forcing the TTLs to be that low, norto > requiring that quantity of state). First of all, note that I said "to each cache that asked for it". Not all caches would necessarily ask for this. Secondly, not all data in the DNS is so volatile. It could be left up to the discretion of the domain owners which RRsets would be marked as NOTIFY-able, i.e. ones for which load-balancing was desired, or failover, or (as prompted this thread) keys for which fast revocation might be desired. Thirdly, your calculations do not reflect the fact that the number of queries/sec would probably *decrease* if this mechanism were in effect, assuming that the domain owners follow suit and start restoring their TTLs to reasonable values. That's largely (in addition to speeding up change-propagation) the whole point of the exercise. To reduce the query-transaction rate. Would one rather keep approx. 24 bytes of state data around or would one rather have that client make that same query 3 or 4 or 5 times as often, based on a tiny TTL reflecting the mere possibility that the data has changed because of node failure or load shift or key revocation or whatever? I expect the answer is usually: I'd rather keep the state and reduce my query rate since memory (who said all of this state data would even need to be held in RAM?) is cheaper in the grand scheme of things than network bandwidth/infrastructure. Fourthly, in high-volume situations as you describe, it might be possible to offload the NOTIFY-sending function onto another box. Fifthly, under certain circumstances the server may be able to play prediction games, e.g. if a particular name has historically been queried only infrequently by downstream clients ("infrequency" being judged relative to the TTL, of course), then maybe don't bother honoring NOTIFY-ability for it, since it'll probably just be a waste to store the state anyway. Lastly, any given server has the option of declining any client's request for a NOTIFY-upon-change, for any reason whatsoever. The presumption is that all of this will be under OPTION control. So this extension simply gives servers another item in their toolkit for optimizing their performance, one which they can choose to use or not use on an RRset-by-RRset or even a query-by-query basis, depending on policy and local conditions (e.g. which is closer to capacity at this very moment, my memory usage or the packet traffic on my primary network interface? which do I need to conserve more?) > | I think such an extension, in a finished form, could restore some > | much-needed balance between the need for dynamism, > > There should be no such need in the DNS. All the nonsense that is requiring > it should be being done other ways. Well, this gets to the crux of the matter, now doesn't it? DNS was undoubtedly never intended to provide dynamic-load-balancing, generalized failover (outside of MX records of course) or key-revocation functions. I can certainly empathize with not wanting to accommodate "perversions" of DNS. But let's face reality. DNS is being used for dynamic-load-balancing and non-MX-failover, and not via the "officially-approved" SRV method either (which is also perceived as lacking sufficient dynamism, not to mention requiring non-trivial rewrites of the DNS lookup code in every piece of client software). Accommodation is starting to look like the lesser of two evils, the greater evil being tiny TTLs and the consequent ever-increasing query rates and inefficiency. > While it can be done without perverting > the DNS design, then there's not much point objecting. But deliberately > changing things so that stuff which was never intended to work can be made to > work is definitely not the direction to head. > > | P.S. I have other ulterior motives for allowing NOTIFY packets to be signed. > | I eventually want to enable slave auto-configuration via the receipt of > | NOTIFY packets, and obviously this requires a degree of trust as to > | their authenticity. > > Like much which seems obvious, this is false. NOTIFY now is just a hint that > you might want to do something (zone transfer currently). That's all it needs > to be for your proposal - when the secondary gets an unexpected NOTIFY, it > can go check the primary, using whatever authentication it needs, determine > if it is supposed to be configured as secondary for the zone, and if so, > configure itself. If the NOTIFY turns out to be bogus, then you've wasted > an authenticated query/response. While someone could bombard you with > bogus NOTIFY packets, and consume resources, whether the resources are > consumed doing an extra query, or whether they're consumed doing SIG validation > on the NOTIFY packets doesn't seem like a difference worth arguing about. To distill things ever further, DoS-prevention requires that authentication occur *sometime* before the AXFR is requested. In my concept of a streamlined automatic slave-creation sequence, there would be no extra step for "determin[ing] if it is supposed to be configured as secondary for the zone"; this would be determined in an implementation-specific way, which would accommodate both stealth slaves as well as registered ones. It would just be a NOTIFY followed by an AXFR. In that case, signing the NOTIFY would be obligatory. Possibly it could be streamlined even more by having the master send unsolicited-yet-signed AXFRs to all of its intended slaves every time a new zone is configured. The recipient could always break the TCP connection if the AXFR is being sent to it in error. But, automatic slave-creation is getting a little far afield from generalized NOTIFY anyway... - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 29 13:20:53 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAB03606 for ; Wed, 29 Aug 2001 13:20:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15c8eQ-000LaM-00 for namedroppers-data@psg.com; Wed, 29 Aug 2001 09:57:14 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15c8eP-000LaF-00 for namedroppers@ops.ietf.org; Wed, 29 Aug 2001 09:57:14 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15c8eN-0000Td-00 for namedroppers@ops.ietf.org; Thu, 30 Aug 2001 00:57:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <3B8C67E9.47023D35@daimlerchrysler.com> References: Date: Wed, 29 Aug 2001 11:32:35 -0400 To: Kevin Darcy From: Edward Lewis Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:56 PM -0400 8/28/01, Kevin Darcy wrote: >Pardon my naivete, but why is it any more dangerous to accept a NOTIFY >based on >IP address that says "hey, this data has changed!" than it is to accept >the answer >in the first place from that IP address? (I think kre tried to explain this, >but I had trouble parsing that particular sentence). Because the hacker has >more time in which to cook up a bogus packet? Is that it? Since a zone transfer would require a TCP connection, if an attacker got to a machine between the primary and secondary, the attacker could fudge the NOTIFY to make the secondary request a zone transfer - which the attacker could provide. That's why an IP-based NOTIFY is more "dangerous" than a key-based NOTIFY. As far as the "is it any more ... than ..." question, I don't understand what you are asking. I don't understand what "the answer" is that I would "accept" from "that IP address." I understand the questioning the trustworthyness of the unsigned NOTIFY, but I don't know to what you are comparing that. PS - Also, given all the recent problems of putting IP addresses in applications, substituting secrets instead of IP's reduces the problem a bit. Not that we can erase all IP addresses from DNS. ;) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 29 22:08:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15814 for ; Wed, 29 Aug 2001 22:08:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cGor-000Ep3-00 for namedroppers-data@psg.com; Wed, 29 Aug 2001 18:40:33 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15cGoq-000Eow-00 for namedroppers@ops.ietf.org; Wed, 29 Aug 2001 18:40:32 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15cGoo-0000YZ-00 for namedroppers@ops.ietf.org; Thu, 30 Aug 2001 09:40:30 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B8D5160.CC681B52@daimlerchrysler.com> Date: Wed, 29 Aug 2001 16:32:32 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 11:56 PM -0400 8/28/01, Kevin Darcy wrote: > >Pardon my naivete, but why is it any more dangerous to accept a NOTIFY > >based on > >IP address that says "hey, this data has changed!" than it is to accept > >the answer > >in the first place from that IP address? (I think kre tried to explain this, > >but I had trouble parsing that particular sentence). Because the hacker has > >more time in which to cook up a bogus packet? Is that it? > > Since a zone transfer would require a TCP connection, if an attacker got to > a machine between the primary and secondary, the attacker could fudge the > NOTIFY to make the secondary request a zone transfer - which the attacker > could provide. That's why an IP-based NOTIFY is more "dangerous" than a > key-based NOTIFY. Agreed. Crypto-authenticated NOTIFY is, all other things being equal, obviously more secure than source-address-authenticated NOTIFY. But that wasn't what I was really getting at. > As far as the "is it any more ... than ..." question, I don't understand > what you are asking. I don't understand what "the answer" is that I would > "accept" from "that IP address." I understand the questioning the > trustworthyness of the unsigned NOTIFY, but I don't know to what you are > comparing that. Apparently I haven't made myself very clear. If NOTIFY were generalized to other types of RRs and transactions besides SOA refresh/serial-number-check, then under the "generalized NOTIFY" concept, conceivably any answer that is given to a client could (assuming the client requested it and the server agreed to provide it) result in a subsequent NOTIFY if the data changed. My question is: if the original answer were authenticated by source-address alone, why is it inherently any riskier than that to authenticate the subsequent NOTIFY by the same criterion? - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 29 22:52:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17230 for ; Wed, 29 Aug 2001 22:52:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cHi2-000GK2-00 for namedroppers-data@psg.com; Wed, 29 Aug 2001 19:37:34 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15cHi1-000GJv-00 for namedroppers@ops.ietf.org; Wed, 29 Aug 2001 19:37:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15cHi0-0000an-00 for namedroppers@ops.ietf.org; Thu, 30 Aug 2001 10:37:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108300228.f7U2Smr93280@drugs.dv.isc.org> To: Kevin Darcy Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) In-reply-to: Your message of "Wed, 29 Aug 2001 16:32:32 -0400." <3B8D5160.CC681B52@daimlerchrysler.com> Date: Thu, 30 Aug 2001 12:28:47 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > if the original answer were authenticated by source-address alone, why is it > inherently any riskier than that to authenticate the subsequent NOTIFY by the > same criterion? Because the first is the result of a pull operation, with a small window of vulnerability to spoofed respones. The second is the result of a push operation with a infinitly wide window to spoofed messages along with a flood of spoofed respones to the subsequent query. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 29 23:33:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17885 for ; Wed, 29 Aug 2001 23:33:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cIQP-000HrX-00 for namedroppers-data@psg.com; Wed, 29 Aug 2001 20:23:25 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15cIQP-000HrR-00 for namedroppers@ops.ietf.org; Wed, 29 Aug 2001 20:23:25 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15cIQJ-0000cC-00 for namedroppers@ops.ietf.org; Thu, 30 Aug 2001 11:23:19 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200108300313.f7U3DFH50356@as.vix.com> To: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) In-Reply-To: Message from Mark_Andrews@isc.org of "Thu, 30 Aug 2001 12:28:47 +1000." <200108300228.f7U2Smr93280@drugs.dv.isc.org> Date: Wed, 29 Aug 2001 20:13:15 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit quite aside from the other perfectly valid reasons mentioned here as to why generalized notify is dangerous from a security point of view, there's the question of scale. it's just not realistic to either (a) spam the universe every time an RR changes, or (b) remember who you've sent an answer to in case you learn that an RRset has changed before its TTL has expired. in fact if you combine concerns (a) and (b) from above you can easily see that even the simple act of transmitting a notify due only to (b) actually qualifies as (a) from the recipients' point of view since they may never use that cached RRset again or indeed they may not even have cached it. people who need their RRsets to change often have to use short TTL's. i do not regret specifying NOTIFY with the text... [RFC1996 1.2.] ... This specification only allows slaves to be notified of SOA RR changes, but the architechture of NOTIFY is intended to be extensible to other RR types. ...but i am mindful of the comments made during the preparation of RFC1996 as to NOTIFY's complete lack of scalability to any other imaginable use. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 30 02:40:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06838 for ; Thu, 30 Aug 2001 02:40:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cLCU-000OPH-00 for namedroppers-data@psg.com; Wed, 29 Aug 2001 23:21:14 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15cLCS-000OPA-00 for namedroppers@ops.ietf.org; Wed, 29 Aug 2001 23:21:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15cLCO-0000nE-00 for namedroppers@ops.ietf.org; Thu, 30 Aug 2001 14:21:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) In-Reply-To: <3B8C6DDF.2E6DBE76@daimlerchrysler.com> References: <3B8C6DDF.2E6DBE76@daimlerchrysler.com> <3B8B05C7.389C2818@daimlerchrysler.com> <2890.998980311@brandenburg.cs.mu.OZ.AU> Date: Thu, 30 Aug 2001 13:12:58 +0700 Message-ID: <2155.999151978@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 29 Aug 2001 00:21:51 -0400 From: Kevin Darcy Message-ID: <3B8C6DDF.2E6DBE76@daimlerchrysler.com> | And how is this different from domain owners reducing the TTLs | to ridiculously low values, which they are doing today? Only those domains which actually need this do that - and if we (generically not the DNS community) come up with a better way (perhaps using anycast, or something) for these purposes, then even that can be stopped. The DNS neither is, nor should be, a generic tool for every purpose anyone can imagine, however easily it may seem to be to tweak this or that to make it seem to work. The more we can do to prevent many of these hacks, the better. | First of all, note that I said "to each cache that asked for it". | Not all caches would necessarily ask for this. In that case you get no benefit at all. If you're doing load balancing or similar, the idea is to make the old data go away quickly - that means a small TTL, or could be done by revocation (notify). But you need it to go away from everywhere, not just a few random caches that happened to be kind to you - so with that caveat, you'd have to keep the low TTLs for everyone who didn't ask, and the state for everyone who did. Useless. What's more, a cache has no way to tell when it should ask, and when it shouldn't - it doesn't know what RRs are subject of load balancing or similar - so its only option would be to always ask. Given that, and the above, the obvious solution is to forget the "asked for it" stuff, and simply apply the technique to every query - then it doesn't scale - though allowing it to be specified for just some RRs helps. Not enough unfortunately, as the very reason you want to do this is because lots of people ask for those RRs - that's why you want to add load balancing in the first place. ie: it isn't some rarely used RR that would require keeping state of accesses, it is the ones used most often. | Thirdly, your calculations do not reflect the fact that the number | of queries/sec would probably *decrease* if this mechanism were in effect, Perhaps, but not by much, certainly not enough to account for just the natural growth of the net. If the data isn't changing often enough that the notify/re-query cycle isn't happening much, then the TTL could just be larger to start with. And none of this does anything to affect the use of small TTLs by people who aren't changing the data, but just want to get a count on how many times it is referenced, and find that the cache in the way lowers their counts... | I expect the answer is usually: I'd rather keep the state and reduce | my query rate since memory (who said all of this state data would even | need to be held in RAM?) is cheaper in the grand scheme of things than | network bandwidth/infrastructure. I think you'll find that either there's another way to solve the problem (most traditional "want to change now but TTL is big" problems can be handled just by duplicating the server for a while), or the net traffic rate doesn't actually decrease at all - if you're really dynamically changing RRs at a high rate (such that you currently need a small TTL to get the benefit) then you'd be sending NOTIFY and getting new queries at a similar rate. Much extra cost, almost no benefit. | Fourthly, in high-volume situations as you describe, it might be possible to | offload the NOTIFY-sending function onto another box. That changes nothing at all. | Fifthly, under certain circumstances the server may be able to play | prediction games, even more state to keep... and for 0 benefit - the names that no-one queries don't accumulate much state, and hence wouldn't cost much. It is the ones that lots of people send queries to that accumulate the state, and which are also the very ones that you want this to work for. The rest doesn't matter. | Lastly, any given server has the option of declining any client's request | for a NOTIFY-upon-change, for any reason whatsoever. But as the only rationale for any of this is to benefit the server (less queries need to be sent to it) this basically means that you're discarding the benefit. Hence low TTLs would need to remain, because no-one could be sure that the server will actually do what it should. | So this extension simply gives servers another item | in their toolkit for optimizing their performance, And one that only works if caches are all upgraded to know about it. SOA notify works because there's only a few systems that we need to care about (in any particular case) and I can easily discover whether or not they will accept a notify (and perhaps config the SOA parameters accordingly, using refresh as a backup for notify failure, rather than as a primary mechanism). You can't do that in general. You will never be able to reply upon any particular cache doing anything with a notify you send, so you have to guard against that in some other way. ie: you have to have the ttl remain low. Gain 0, cost huge. If you really think this through, including what happens to intermediate caches that asked for notify, but hand out answers to others who don't, etc, then I think you'll begin to see that this simply can't work. | Accommodation is starting to look like the lesser of two evils, not to me. | In my concept of a streamlined automatic slave-creation sequence, there | would be no extra step for "determin[ing] if it is | supposed to be configured as secondary for the zone"; And this happens so frequently that saving that extra step is worthwhile??? Really??? kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 30 19:13:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29999 for ; Thu, 30 Aug 2001 19:13:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15caXD-0005l2-00 for namedroppers-data@psg.com; Thu, 30 Aug 2001 15:43:39 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15caXC-0005kw-00 for namedroppers@ops.ietf.org; Thu, 30 Aug 2001 15:43:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15caXA-0000wc-00 for namedroppers@ops.ietf.org; Fri, 31 Aug 2001 06:43:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 30 Aug 2001 12:27:46 +0200 (MET DST) From: Erik Guttman Subject: Re: Sense of the WG: mDNS configuration? To: Bernard Aboba Cc: namedroppers@psg.com Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, Thanks for bringing this topic to the list. I've been on vacation - sorry for the delay in responding. On Aug 19, Bernard wrote: > At IETF 51, we had a discussion relating to configuration of mDNS. A > number of alternatives were discussed, including: > > Domain Searchlist (draft-aboba-dhc-domsearch-05.txt) > mDNS enable (draft-guttman-dhc-mdns-enable-01.txt) > Name Service Searchlist (RFC 2937) > > Note that each of these alternative approaches allows for local > configuration, in addition to control via a DHCP option. I hadn't considered RFC 2937. The mDNS enable option could be handled by assigning additional values for mDNS name resolution. Values corresponding to different multicast scopes could be used, exactly as described in draft-guttman-dhc-mdns-enable-01.txt. We could just update RFC 2937 with the new info instead of creating a new option. On Aug 19 Itojin wrote: > i vote for domain searchlist. there are environments without DHCP > server, like IPv6 stateless address autoconf > (RFC2937 and guttman-dhc-mbdns-enable both assumes that a DHCP > server is there). Thanks for your comment. I understand your concern that we want to allow mDNS in the case when there is no DHCP server. If no DNS configuration exists - this is the zeroconf case. There has been no objection to using mDNS in this case. Where there have been objections is the case where you have DNS configuration and you *still* use mDNS. In this case, the consensus on the namedroppers mailing list was to explicitely enable mDNS behavior (the default being NOT to use mDNS, as it is today :-). This can be done using a DHC option, or in the absence of DHC, static (non-default) configuration. The problems with the domain search list are serious: 1. It creates a binding between certain names and DNS transport protocols. Here the proposal is 'local.arpa' means use IPv4 LINKLOCAL multicast, sending with TTL=255, rejecting received if TTL != 255, hosts must be prepared to receive multiple replies, etc etc. In the future, if we define use of multicast DNS for admin local scope for IPv4, IPv6 multicast scopes, with different rules than those in draft-ietf-dnsext-mdns, then we need NEW NAMES for the search list! 2. The search list mechanism implies that names resolved by mdns are qualified by the search list name. In draft-ietf-dnsext-mdns I can only resolve names ending in 'local.arpa'. Why this artificial restriction? 3. Administration of name resolution behavior will be extremely obscure if users and administrators must add special purpose domain names to their search path to control DNS transport behavior... Coupling naming service behavior with special names is a bad idea. It is a hack to avoid confronting the real problem: We want DNS to work as it does today in the common case, to use mDNS in the unconfigured case. Only *when local policy allows* should we enable mDNS to coexist with DNS. Let's use a mechanism which allows this policy to be imposed on hosts, not a mechanism which imposes contortions upon standardization, applications, implementors and administrators. On 19 Aug, Robert Elz wrote: > Either of the latter two - the mdns-enable option is basically just > a special case of 2937, in a sense - but as I read 2937, it would need > another DNS option defined anyway, so its option number can be used in > the 2937 option (there's no current dhcp option giving the addresses > of the servers for mDNS .. for obvious reasons). Robert, I think you misread 2937. It gives only a list of 2 byte values corresponding to name services to try (in order), not addresses. 2937 is silent about how one gets addresses for name services and even how the option is interpreted by clients. --- My vote is to extend the Name Service Searchlist (RFC 2937) with new values for mDNS. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 30 19:47:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00462 for ; Thu, 30 Aug 2001 19:47:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cb8O-0006yF-00 for namedroppers-data@psg.com; Thu, 30 Aug 2001 16:22:04 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15cb8N-0006y9-00 for namedroppers@ops.ietf.org; Thu, 30 Aug 2001 16:22:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15cb8M-0000z9-00 for namedroppers@ops.ietf.org; Fri, 31 Aug 2001 07:22:02 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 30 Aug 2001 10:47:31 -0700 (PDT) From: Bernard Aboba To: Erik Guttman cc: namedroppers@psg.com Subject: Re: Sense of the WG: mDNS configuration? In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I hadn't considered RFC 2937. The mDNS enable option could be > handled by assigning additional values for mDNS name resolution. > Values corresponding to different multicast scopes could be used, > exactly as described in draft-guttman-dhc-mdns-enable-01.txt. > We could just update RFC 2937 with the new info instead of creating > a new option. > I think that a revision of RFC 2937 is required only because the numbers assigned to the name services correspond to DHCP option codes, and a new IANA considerations section would need to be written to describe allocation of name service codes without corresponding allocation of DHCP option codes. Otherwise, all that would be needed would be an IANA allocation of the mDNS name service codes. > Where there have been objections is the case where you have DNS > configuration and you *still* use mDNS. In this case, the consensus > on the namedroppers mailing list was to explicitely enable mDNS > behavior (the default being NOT to use mDNS, as it is today :-). > This can be done using a DHC option, or in the absence of DHC, > static (non-default) configuration. The question was how to explicitly enable mDNS using IPv6 stateless autoconfig. I would suggest that this be added as an objective of the DNS Discovery work ongoing in IPNG WG. > Robert, I think you misread 2937. It gives only a list of 2 byte > values corresponding to name services to try (in order), not > addresses. 2937 is silent about how one gets addresses for name > services and even how the option is interpreted by clients. > Yes, that's how I read RFC 2937. We would just need to allocate name service codes for mDNS, and re-write the IANA considerations section of it. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 30 19:53:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00567 for ; Thu, 30 Aug 2001 19:53:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15cbMI-0007PJ-00 for namedroppers-data@psg.com; Thu, 30 Aug 2001 16:36:26 -0700 Received: from ip-172-63.meeting.hinet.net ([210.61.172.63] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15cbMG-0007PB-00 for namedroppers@ops.ietf.org; Thu, 30 Aug 2001 16:36:25 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15cbMA-00010L-00 for namedroppers@ops.ietf.org; Fri, 31 Aug 2001 07:36:18 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B8EBBC4.11F72F37@daimlerchrysler.com> Date: Thu, 30 Aug 2001 18:18:44 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) References: <200108300228.f7U2Smr93280@drugs.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org wrote: > > if the original answer were authenticated by source-address alone, why is it > > inherently any riskier than that to authenticate the subsequent NOTIFY by the > > same criterion? > > Because the first is the result of a pull operation, with > a small window of vulnerability to spoofed respones. > > The second is the result of a push operation with a infinitly > wide window to spoofed messages along with a flood of > spoofed respones to the subsequent query. The window isn't "infinitely" wide, since, just as the server has no reason to send a NOTIFY after the calculated expiration of the entry on the client, the client has no reason to pay heed to a NOTIFY for an RRset which is not in cache. It should just assume those are spoofed and ignore them. If this is really an issue, folks who don't want to go all the way to crypto, but who are paranoid about trusting source addresses alone, could use, in addition, some intermediate-strength form of authentication, e.g. the original query provides a token consisting of, say, 32 bits of entropy, the response provides an independent token, and the NOTIFY would only be accepted if it bore a token consisting of an XOR of the two. This would be relatively hard to exploit, since it would require access to both the original query and the response. If a hacker has access to both of those, and the ability to spoof the server's address, then all bets are pretty much off anyway... - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 31 13:17:02 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10991 for ; Fri, 31 Aug 2001 13:17:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15crc8-0000fe-00 for namedroppers-data@psg.com; Fri, 31 Aug 2001 09:57:52 -0700 Received: from h-135-207-4-114.research.att.com ([135.207.4.114] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15crc5-0000fR-00 for namedroppers@ops.ietf.org; Fri, 31 Aug 2001 09:57:49 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15crc2-0000Kc-00 for namedroppers@ops.ietf.org; Sat, 01 Sep 2001 00:57:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B8F0A99.9AE55B18@daimlerchrysler.com> Date: Thu, 30 Aug 2001 23:55:05 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) References: <3B8C6DDF.2E6DBE76@daimlerchrysler.com> <3B8B05C7.389C2818@daimlerchrysler.com> <2890.998980311@brandenburg.cs.mu.OZ.AU> <2155.999151978@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You make some good points here, but I'm not sure I'm quite willing to abandon the idea. A further refinement might be: for the same answer, give *different* TTLs, depending on whether "generalized NOTIFY" is in effect or not. So backlevel caches, or caches that for whatever reason (e.g. a firewall in the way) choose not to request NOTIFY, get the smaller TTLs, and this is no different that what we have today. For caches that are willing and able to participate in the new regime, they request NOTIFY, get a "preferred", larger TTL and can potentially reap the benefits of a reduced query rate. There would thus be an incentive for caches to use generalized NOTIFY, but in cases where they don't, things would just degenerate into what we have now. I think this addresses the main thrust of your concerns, i.e. that one of two situations would occur, either a) state would need to be kept for *everybody*, which would only be possible by artificially reducing TTLs, thus defeating the whole purpose or b) the domain owners would never raise the TTLs because they would never get to a point of trusting that their changes would propagate quickly if they did so. I'll also answer some of the other miscellaneous points... Robert Elz wrote: > Date: Wed, 29 Aug 2001 00:21:51 -0400 > From: Kevin Darcy > Message-ID: <3B8C6DDF.2E6DBE76@daimlerchrysler.com> > > | And how is this different from domain owners reducing the TTLs > | to ridiculously low values, which they are doing today? > > Only those domains which actually need this do that - and if we (generically > not the DNS community) come up with a better way (perhaps using anycast, > or something) for these purposes, then even that can be stopped. > The DNS neither is, nor should be, a generic tool for every purpose > anyone can imagine, however easily it may seem to be to tweak this orthat to make > it seem to work. I think timely and efficient name-to-address resolution falls squarely within the mandate of DNS. The trouble is, small TTLs sacrifice efficiency for timeliness. It's become an either/or struggle. I'm just trying to find a way to get the best of both worlds. > | First of all, note that I said "to each cache that asked for it". > | Not all caches would necessarily ask for this. > > In that case you get no benefit at all. If you're doing load balancing > or similar, the idea is to make the old data go away quickly - that means > a small TTL, or could be done by revocation (notify). But you need it to > go away from everywhere, not just a few random caches that happened to be > kind to you - so with that caveat, you'd have to keep the low TTLs for > everyone who didn't ask, and the state for everyone who did. Useless. > > What's more, a cache has no way to tell when it should ask, and when it > shouldn't - it doesn't know what RRs are subject of load balancing or > similar - so its only option would be to always ask. Given that, and the > above, the obvious solution is to forget the "asked for it" stuff, and > simply apply the technique to every query - then it doesn't scale - though > allowing it to be specified for just some RRs helps. Not enough unfortunately, > as the very reason you want to do this is because lots of people ask for > those RRs - that's why you want to add load balancing in the first place. > ie: it isn't some rarely used RR that would require keeping state of > accesses, it is the ones used most often. See above. Caches would have an incentive to request NOTIFY. But there might be extenuating circumstances under which they might not request it. There shouldn't be any all-or-nothing mandate here. Caches should have some latitude as to whether and how much they use the extension, if at all. > | Thirdly, your calculations do not reflect the fact that the number > | of queries/sec would probably *decrease* if this mechanism were in effect, > > Perhaps, but not by much, certainly not enough to account for just the > natural growth of the net. If the data isn't changing often enough that > the notify/re-query cycle isn't happening much, then the TTL could just > be larger to start with. a) sometimes customers want failover but not necessarily load balancing. In these cases, an RRset may change infrequently, yet the TTL may be low so that when it does change, the change will be visible quickly. Generalized NOTIFY could be a big win here. Admittedly, the savings might not be as dramatic for truly *volatile* data that is actually changing all of the time, but then again, not much state is going to be necessary for such volatile data, since once you NOTIFY, you don't need to keep the state around any more. Also, remember that this thread sprouted from the question of how to handle key revocation. That's another situation in which the data wouldn't change very often, but when it does, you want the change to propagate quickly. That's why I thought generalized NOTIFY might be a good fit for that requirement. b) it wouldn't have to be a "notify/re-query cycle". It is sufficient that the recipient cache purge the NOTIFYed cache entry, or simply mark it as invalid. It can wait for one of its downstream clients to query the data again (if ever) before re-querying it. > And none of this does anything to affect the use of small TTLs by people > who aren't changing the data, but just want to get a count on how many times > it is referenced, and find that the cache in the way lowers their counts... I consider that DNS abuse. If there is a legitimate need for such statistics, maybe a "report query counts" extension could be added to DNS, or the idea of a nameserver MIB could be resurrected... > | I expect the answer is usually: I'd rather keep the state and reduce > | my query rate since memory (who said all of this state data would even > | need to be held in RAM?) is cheaper in the grand scheme of things than > | network bandwidth/infrastructure. > > I think you'll find that either there's another way to solve the problem > (most traditional "want to change now but TTL is big" problems can be > handled just by duplicating the server for a while), or the net traffic > rate doesn't actually decrease at all - if you're really dynamically > changing RRs at a high rate (such that you currently need a small TTL to > get the benefit) then you'd be sending NOTIFY and getting new queries > at a similar rate. Much extra cost, almost no benefit. > > | Fourthly, in high-volume situations as you describe, it might be possible to > | offload the NOTIFY-sending function onto another box. > > That changes nothing at all. Strictly at a protocol level, you are correct -- it changes nothing. But it might make the storage of the state-data more efficient and manageable. The main objection here, after all, as I understand it, is not that the protocol can't handle this extension, only that the benefits of implementing/using it would be more than offset by the (state-data management) costs of doing so. > | Fifthly, under certain circumstances the server may be able to play > | prediction games, > > even more state to keep... and for 0 benefit - the names that no-one queries > don't accumulate much state, and hence wouldn't cost much. It is the ones > that lots of people send queries to that accumulate the state, and which are > also the very ones that you want this to work for. The rest doesn't matter. > > | Lastly, any given server has the option of declining any client's request > | for a NOTIFY-upon-change, for any reason whatsoever. > > But as the only rationale for any of this is to benefit the server (less > queries need to be sent to it) this basically means that you're discarding > the benefit. Hence low TTLs would need to remain, because no-one could > be sure that the server will actually do what it should. > > | So this extension simply gives servers another item > | in their toolkit for optimizing their performance, > > And one that only works if caches are all upgraded to know about it. > SOA notify works because there's only a few systems that we need to > care about (in any particular case) and I can easily discover whether > or not they will accept a notify (and perhaps config the SOA parameters > accordingly, using refresh as a backup for notify failure, rather than > as a primary mechanism). You can't do that in general. You will never > be able to reply upon any particular cache doing anything with a notify > you send, so you have to guard against that in some other way. ie: you > have to have the ttl remain low. Gain 0, cost huge. > > If you really think this through, including what happens to intermediate > caches that asked for notify, but hand out answers to others who don't, > etc, then I think you'll begin to see that this simply can't work. > > | Accommodation is starting to look like the lesser of two evils, > > not to me. > > | In my concept of a streamlined automatic slave-creation sequence, there > | would be no extra step for "determin[ing] if it is > | supposed to be configured as secondary for the zone"; > > And this happens so frequently that saving that extra step is worthwhile??? > Really??? Yes, nameservers get configured as slaves quite frequently. Why do you think the extra "find out from the master whether I should really be a slave" step is necessary, by the way? Particularly in the case of a stealth slave, I don't see that it accomplishes anything useful at all. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 31 13:20:46 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11065 for ; Fri, 31 Aug 2001 13:20:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15crZi-0000dD-00 for namedroppers-data@psg.com; Fri, 31 Aug 2001 09:55:22 -0700 Received: from h-135-207-4-114.research.att.com ([135.207.4.114] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15crZg-0000d6-00 for namedroppers@ops.ietf.org; Fri, 31 Aug 2001 09:55:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15crZe-0000KV-00 for namedroppers@ops.ietf.org; Sat, 01 Sep 2001 00:55:18 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B8F09E7.164BB9CE@daimlerchrysler.com> Date: Thu, 30 Aug 2001 23:52:07 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: Generalized NOTIFY? (was Re: draft-ietf-dnsext-delegation-signer-01) References: <200108300313.f7U3DFH50356@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: > quite aside from the other perfectly valid reasons mentioned here as to why > generalized notify is dangerous from a security point of view, there's the > question of scale. it's just not realistic to either (a) spam the universe > every time an RR changes, or (b) remember who you've sent an answer to in > case you learn that an RRset has changed before its TTL has expired. I've already gone over most of this ground with kre. Highlights: a) only clients that ask for this would get it (non-caching resolvers, for instance, would have no reason to ask), b) the administrator could limit the clients/address-ranges/keys for which the NOTIFY service was offered, as well as perhaps a global limitation on the total amount of state data to be stored, c) the state information wouldn't grow without bound because old entries can be purged, d) in resource emergencies, the server could decline to honor *any* NOTIFY-callback requests until resources free back up again. > in fact > if you combine concerns (a) and (b) from above you can easily see that even > the simple act of transmitting a notify due only to (b) actually qualifies as > (a) from the recipients' point of view since they may never use that cached > RRset again or indeed they may not even have cached it. Again, it's up to the client to ask for the NOTIFY-callback service in the first place. (I assume you're familiar with EDNS0 OPTIONs? :-) Then the server chooses whether or not to honor that request. Non-caching resolvers simply don't play in this space. It's primarily a server-to-server (that is to say, primarily an authoritative-server-to-cache and cache-to-cache) extension. > people who need their RRsets to change often have to use short TTL's. i do > not regret specifying NOTIFY with the text... > > [RFC1996 1.2.] ... This specification only allows > slaves to be notified of SOA RR changes, but the architechture of > NOTIFY is intended to be extensible to other RR types. > > ...but i am mindful of the comments made during the preparation of RFC1996 > as to NOTIFY's complete lack of scalability to any other imaginable use. If formulated reasonably, it can be as scalable as the implementors and/or administrators wish to make it. It's only in the straw-man "remember everyone who asked this, unconditionally, for all eternity" formulation that it is inherently unscalable. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 31 13:28:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11303 for ; Fri, 31 Aug 2001 13:28:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15crn7-0000r2-00 for namedroppers-data@psg.com; Fri, 31 Aug 2001 10:09:13 -0700 Received: from h-135-207-4-114.research.att.com ([135.207.4.114] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15crn5-0000qv-00 for namedroppers@ops.ietf.org; Fri, 31 Aug 2001 10:09:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15crn2-0000Ln-00 for namedroppers@ops.ietf.org; Sat, 01 Sep 2001 01:09:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 31 Aug 2001 11:05:00 +0200 (MEST) From: Jakob Schlyter To: DNSEXT Subject: I-D ACTION:draft-schlyter-appkey-00.txt Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit this is probably interesting for this wg. jakob ---------- Forwarded message ---------- Date: Thu, 30 Aug 2001 07:13:41 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-schlyter-appkey-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Storing application public keys in the DNS Author(s) : J. Schlyter Filename : draft-schlyter-appkey-00.txt Pages : 8 Date : 29-Aug-01 This document specifies a new DNS RR type for applications to store public keys in. Experience with DNSSEC has indicated that mixing DNS keys and application keys is a bad idea in many regards. The new RR expands certain fields based on experience from early DNSSEC deployment. This document updates RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schlyter-appkey-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schlyter-appkey-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schlyter-appkey-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 31 13:33:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11434 for ; Fri, 31 Aug 2001 13:33:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.33 #1) id 15crt7-0000xE-00 for namedroppers-data@psg.com; Fri, 31 Aug 2001 10:15:25 -0700 Received: from h-135-207-4-114.research.att.com ([135.207.4.114] helo=roam.psg.com) by psg.com with esmtp (Exim 3.33 #1) id 15crt5-0000x4-00 for namedroppers@ops.ietf.org; Fri, 31 Aug 2001 10:15:24 -0700 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15crt2-0000MC-00 for namedroppers@ops.ietf.org; Sat, 01 Sep 2001 01:15:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Erik Guttman cc: Bernard Aboba , namedroppers@psg.com Subject: Re: Sense of the WG: mDNS configuration? In-Reply-To: References: Date: Fri, 31 Aug 2001 18:03:50 +0700 Message-ID: <1837.999255830@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 30 Aug 2001 12:27:46 +0200 (MET DST) From: Erik Guttman Message-ID: | Robert, I think you misread 2937. It gives only a list of 2 byte | values corresponding to name services to try (in order), not | addresses. 2937 is silent about how one gets addresses for name | services and even how the option is interpreted by clients. That may very well be, but I thought its values were the identifiers of other DHCP options, which have the information about the servers for the various nameserver lookup types (DNS, netbios, ...) I don't think there's any reason it would have to stay that way, but it certainly looked to be how it was defined right now. That is ... A DHCP server SHOULD return, in its preferred order, the 16-bit, network byte order (big-endian [4]) integer option code for the name services (the earlier in the list, the more preferred the name service). In the above diagram, ns1 and ns2 are 16-bit integers corresponding to two DHCP options which specify the IP addresses of two different types of name server. The current list of name services and their DHCP option codes, taken from RFC 2132, includes (etc). And 0 means /etc/hosts ("local naming information") as a special case. If we took any other special case values, we'd have to make sure that those particular identifiers never mapped into DHCP option numbers that specify IP addresses of nameserver tyoes. Somehow. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.