From owner-namedroppers@ops.ietf.org Sun Sep 1 06:16:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12692 for ; Sun, 1 Sep 2002 06:16:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17lRWY-000P3k-00 for namedroppers-data@psg.com; Sun, 01 Sep 2002 03:00:06 -0700 Received: from randy by psg.com with local (Exim 3.36 #1) id 17lRWS-000P37-00 for namedroppers@ops.ietf.org; Sun, 01 Sep 2002 03:00:00 -0700 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Sun, 01 Sep 2002 03:00:00 -0700 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 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. 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. 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., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- 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. archive: From owner-namedroppers@ops.ietf.org Sun Sep 1 12:15:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24076 for ; Sun, 1 Sep 2002 12:15:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17lX9s-000818-00 for namedroppers-data@psg.com; Sun, 01 Sep 2002 09:01:04 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17lX9o-0007zp-00 for namedroppers@ops.ietf.org; Sun, 01 Sep 2002 09:01:00 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 160664; Sun, 01 Sep 2002 10:58:28 -0500 Message-ID: <3D7239B7.1070908@ehsco.com> Date: Sun, 01 Sep 2002 11:00:55 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers Subject: Re: draft-dnsext-edns1-04.txt References: <20020823012804.B594528B6C@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/22/2002 8:28 PM Paul Vixie wrote: > more later. I'm going to assume that you've reach a state of torture over the higher processing demands from multiple queries, where fallback processing always requires two questions to the delegation tree, the first of which always results in SERVFAIL. Since this is a general problem whenever any new features are added to the message by the end-nodes, one way out of this may be to define a standardized caching scheme for SERVFAIL (defined as a separate document) which tells querying agents how long they should keep track of SERVFAIL errors. With this information, a querying agent would only need to discover once that a server did not support some feature, and could then use this information to avoid making the first query multiple times (at least for the duration of the timer value). In the context of multiple questions in EDNS1, this would mean that a cache which had learned that (say) the root servers did not support EDNS1 would be able to remember this for a certain amount of time, and that cache would be able to proceed directly to the fallback step, without having to get the SERVFAIL error first. As a first stab towards such an algorithm, I would suggest that the TTL for the NS RR query target be used for the seed value, with a reasonable upper limit of (say) ~48 hours. Example, an EDNS1 query for foo.vix.com is sent to a.root-servers.net, but triggers a SERVFAIL error. Upon receipt of this error, the querying node examines its cache for the TTL of a.root-servers.net (3,600,000 seconds in the default root-cache database, assuming that some other value has not yet been learned from an authoritative NS RRset), reduces this value to 48 hours, and applies the resulting value to the root zone. For the duration of that time, the querying node "remembers" not to issue the failing query and proceeds to the fallback step in the logic for any subsequent queries. So, if another EDNS1 query arrives for www.example.com which would normally be sent to f.root-servers.net, the server does not issue the query, but instead acts as if a SERVFAIL response has already been received for that query. This still leaves open the EDNS1-specific question of serialized (high-TTL) versus parallel (high-load) fallback queries, but it gets us to that point in the logic without having contributed to root meltdown. -- 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. archive: From owner-namedroppers@ops.ietf.org Sun Sep 1 20:10:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00268 for ; Sun, 1 Sep 2002 20:10:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17leWX-000M6p-00 for namedroppers-data@psg.com; Sun, 01 Sep 2002 16:52:57 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17leWT-000M6Z-00 for namedroppers@ops.ietf.org; Sun, 01 Sep 2002 16:52:53 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g81NqhB5041231; Mon, 2 Sep 2002 09:52:43 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200209012352.g81NqhB5041231@drugs.dv.isc.org> To: "Eric A. Hall" Cc: namedroppers From: Mark.Andrews@isc.org Subject: Re: draft-dnsext-edns1-04.txt In-reply-to: Your message of "Sun, 01 Sep 2002 11:00:55 EST." <3D7239B7.1070908@ehsco.com> Date: Mon, 02 Sep 2002 09:52:43 +1000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > on 8/22/2002 8:28 PM Paul Vixie wrote: > > > more later. > > I'm going to assume that you've reach a state of torture over the higher > processing demands from multiple queries, where fallback processing always > requires two questions to the delegation tree, the first of which always > results in SERVFAIL. > > Since this is a general problem whenever any new features are added to the > message by the end-nodes, one way out of this may be to define a > standardized caching scheme for SERVFAIL (defined as a separate document) > which tells querying agents how long they should keep track of SERVFAIL > errors. With this information, a querying agent would only need to > discover once that a server did not support some feature, and could then > use this information to avoid making the first query multiple times (at > least for the duration of the timer value). > > In the context of multiple questions in EDNS1, this would mean that a > cache which had learned that (say) the root servers did not support EDNS1 > would be able to remember this for a certain amount of time, and that > cache would be able to proceed directly to the fallback step, without > having to get the SERVFAIL error first. > > As a first stab towards such an algorithm, I would suggest that the TTL > for the NS RR query target be used for the seed value, with a reasonable > upper limit of (say) ~48 hours. > > Example, an EDNS1 query for foo.vix.com is sent to a.root-servers.net, but > triggers a SERVFAIL error. Upon receipt of this error, the querying node > examines its cache for the TTL of a.root-servers.net (3,600,000 seconds in > the default root-cache database, assuming that some other value has not > yet been learned from an authoritative NS RRset), reduces this value to 48 > hours, and applies the resulting value to the root zone. For the duration > of that time, the querying node "remembers" not to issue the failing query > and proceeds to the fallback step in the logic for any subsequent queries. > So, if another EDNS1 query arrives for www.example.com which would > normally be sent to f.root-servers.net, the server does not issue the > query, but instead acts as if a SERVFAIL response has already been > received for that query. > > This still leaves open the EDNS1-specific question of serialized > (high-TTL) versus parallel (high-load) fallback queries, but it gets us to > that point in the logic without having contributed to root meltdown. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ Eric, discover of EDNS rev is easy compared with discover of EDNS support. The latter is done by probing and look for SERVFAIL or NOTIMP or FORMERR or lack of a OPT record in the response of timeouts from servers that don't talk RFC 103[45]. The former is built into the EDNS spec. Note you can't use SERVFAIL by itself to determine if a server supports EDNS as it generates too many false positives. Similarly lack of response is not a good indication of lack of EDNS response. FORMERR and NOTIMP are good indications as is the lack of a OPT record in the response to a EDNS 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 2 00:33:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04107 for ; Mon, 2 Sep 2002 00:33:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ligQ-0006Ad-00 for namedroppers-data@psg.com; Sun, 01 Sep 2002 21:19:26 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17ligN-0006AQ-00 for namedroppers@ops.ietf.org; Sun, 01 Sep 2002 21:19:23 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 160707; Sun, 01 Sep 2002 23:16:52 -0500 Message-ID: <3D72E6C7.9080904@ehsco.com> Date: Sun, 01 Sep 2002 23:19:19 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Mark.Andrews@isc.org CC: namedroppers Subject: Re: draft-dnsext-edns1-04.txt References: <200209012352.g81NqhB5041231@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 9/1/2002 6:52 PM Mark.Andrews@isc.org wrote: > FORMERR and NOTIMP are good indications as is the lack of a OPT > record in the response to a EDNS query. Yeah, I meant to include FORMERR and NOTIMPL in the SERVFAIL category. > discover of EDNS rev is easy compared with discover of > EDNS support. This does bring up another point however, which is that the heuristics for failure are different for each different feature/extension. For example, consider an application which used an extended label type. That particular application would have its own heuristics apart from the other kinds of failures which might emerge. There is also the ugly condition where multiple failures are preventing progress. In this scenario, multiple fallback conditions may have to be exercised simultaneously by the requester, although detecting multiple failures from a single SERVFAIL [...] may not be practical. In the short term, a generalized protocol for caching errors may make some sense, as a sister spec to the negative caching spec. Separately, each application would also have to define its own heuristics as part of any fallback processing that it also defines (eg, detecting version failure versus no-EDNS failure). There is another issue with the proposed use of discrete NS RRs as an input, which is that a single failing server will mean that all of the servers for that zone will be marked as non-compliant with the spec in question. If one of the servers refuses an extension, then that extension would not be used for any of them for the duration of the error cache. Whether this is a problem or a feature, I haven't yet decided. In the loooong term, a mechanism for reporting multiple failures would be a nice feature (something like a pointer to the problematic field in the original question, or an array of pointers when multiple problems are found). I don't think this is feasible currently. -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 12:21:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03335 for ; Tue, 3 Sep 2002 12:21:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mG8a-000DFY-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 09:02:44 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17mG8X-000DF4-00; Tue, 03 Sep 2002 09:02:41 -0700 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g83FxJh90946; Tue, 3 Sep 2002 11:59:20 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020814133007.022c0008@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 03 Sep 2002 10:38:29 -0400 To: "Hallam-Baker, Phillip" , Randy Bush From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: RE: DNSSEXT Yokohama Minutes Cc: namedroppers In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40D813F3D@vhqpostal.verisig n.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:12 2002-08-14, Hallam-Baker, Phillip wrote: > > Bush: Current discussion is around corner cases. Both DS and > > OPT-IN need flag-date; DS signing testing will continue. By > > and of August there should be a document set for DS. Then > > estimate how long additional OPT-IN would take. So mid > > September an assessment will be made if to OPT-IN will be > > going into the document set. > >Randy, > > DNSSEC is undeployable without the NXT record being fixed. > For the record: Which problem or problems with NXT needs fixing IYHO ? > Filibustering will do absolutely nothing to change this fact. > > I will start the appeals process if any attempt is made to pre-empt >OPTIN by announcing a flag date on DS while OPTIN is blocked by political >tactics. This will not happen on my watch, but Opt-in camp needs to answer the open questions in their open park. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 14:07:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07719 for ; Tue, 3 Sep 2002 14:07:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mHvo-000JDm-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 10:57:40 -0700 Received: from h227.s231.netsol.com ([216.168.231.227] helo=pinion.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17mHvj-000JCK-00 for namedroppers@ops.ietf.org; Tue, 03 Sep 2002 10:57:35 -0700 Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id 33E501AF0C; Tue, 3 Sep 2002 13:57:34 -0400 (EDT) To: "=?iso-8859-1?q?=D3lafur?= Gudmundsson/DNSEXT co-chair" Cc: "Hallam-Baker, Phillip" , Randy Bush , namedroppers Subject: Re: DNSSEXT Yokohama Minutes References: <5.1.1.6.2.20020814133007.022c0008@localhost> From: David Blacka In-Reply-To: <5.1.1.6.2.20020814133007.022c0008@localhost> =?iso-8859-1?q?("=D3lafur?= Gudmundsson/DNSEXT co-chair"'s message of "Tue, 03 Sep 2002 10:38:29 -0400") Date: Tue, 03 Sep 2002 13:57:34 -0400 Message-ID: Lines: 11 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-mandrake-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "ogud" == Olafur Gudmundsson writes: ogud> This will not happen on my watch, but Opt-in camp needs to ogud> answer the open questions in their open park. Could somebody please restate the open questions about opt-in? Feel free to add new open questions. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 16:19:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12988 for ; Tue, 3 Sep 2002 16:19:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mJzt-0000Fo-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 13:10:01 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17mJzp-0000FX-00; Tue, 03 Sep 2002 13:09:57 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g83K9nLU028952; Tue, 3 Sep 2002 22:09:52 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g83K9nnD028948; Tue, 3 Sep 2002 22:09:49 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 3 Sep 2002 22:09:49 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: David Blacka cc: =?iso-8859-1?q?=D3lafur?= Gudmundsson/DNSEXT co-chair , "Hallam-Baker, Phillip" , Randy Bush , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 3 Sep 2002, David Blacka wrote: > >>>>> "ogud" == Olafur Gudmundsson writes: > > ogud> This will not happen on my watch, but Opt-in camp needs to > ogud> answer the open questions in their open park. > > Could somebody please restate the open questions about opt-in? Feel > free to add new open questions. As I recall, we need to write: - The impact on: Authoritative servers (but this is already clear in draft IMHO) [caching] resolvers (basically the change to the resolver algorihm) - The current issues: Clear AD-bit on an opt-in response. (I think this will be taken care of by the "AD-bit is secure" authors ). The other (main) issue is caching of NXT/SIG(NXT). When not individually queried for, they MUST be cached as properties of QNAME/QCLASS/QTYPE or as an integral part of the entire answer. They MUST NOT be stored as individual records. However, these are DNSSEC issues which are inherited by Opt-In. In other words, caches are not more then a "response replay" box, which is only allowed to alter the TTLs of records and the [E]DNS-header. Some of the above were stated by Olafur last week during the DS workshop, others were a result of research by Rob Austein and me (which was presented at Yokohama). Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 16:48:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13798 for ; Tue, 3 Sep 2002 16:48:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mKSA-0001jR-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 13:39:14 -0700 Received: from h227.s231.netsol.com ([216.168.231.227] helo=pinion.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17mKS5-0001j3-00 for namedroppers@ops.ietf.org; Tue, 03 Sep 2002 13:39:09 -0700 Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id E15CB1AF16; Tue, 3 Sep 2002 16:39:08 -0400 (EDT) To: Roy Arends Cc: namedroppers Subject: Re: DNSSEXT Yokohama Minutes References: From: David Blacka In-Reply-To: (Roy Arends's message of "Tue, 3 Sep 2002 22:09:49 +0200 (CEST)") Date: Tue, 03 Sep 2002 16:39:08 -0400 Message-ID: Lines: 63 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-mandrake-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Roy" == Roy Arends writes: Roy> On Tue, 3 Sep 2002, David Blacka wrote: >> >>>>> "ogud" == Olafur Gudmundsson writes: >> ogud> This will not happen on my watch, but Opt-in camp needs to ogud> answer the open questions in their open park. >> >> Could somebody please restate the open questions about opt-in? Feel >> free to add new open questions. Roy> As I recall, we need to write: Roy> - The impact on: Authoritative servers (but this is already Roy> clear in draft IMHO) Roy> [caching] resolvers (basically the change to the resolver Roy> algorihm) More specifically, what needs to be in the opt-in draft that isn't already there about this? Or is what is in the draft just not clear enough? (I am asking the list, not just Roy) Roy> - The current issues: Roy> Clear AD-bit on an opt-in response. Roy> (I think this will be taken care of by the "AD-bit is Roy> secure" authors ). Ok. Does this mean the AD bit behavior does not need to be opt-in draft at all? Or just a reference to a new AD-bit draft? Roy> The other (main) issue is caching of NXT/SIG(NXT). When not Roy> individually queried for, they MUST be cached as properties of Roy> QNAME/QCLASS/QTYPE or as an integral part of the entire Roy> answer. They MUST NOT be stored as individual records. However, Roy> these are DNSSEC issues which are inherited by Opt-In. In other Roy> words, caches are not more then a "response replay" box, which Roy> is only allowed to alter the TTLs of records and the Roy> [E]DNS-header. I do not understand the harm in also caching the NXTs as individual records. This is probably because I do not fully understand the corner case you and Rob Austein investigated. What I do understand is this: opt-in creates a case where for a postive response, a cache must be able to return the covering opt-in NXT that goes with the response, and that NXT record does NOT share its name with qname. Hence, the cache should store the NXT records as properties of the original qname. I also know that this case also shows up in negative caching, with or without opt-in. Well, there will most likely be more than one NXT record to cache in this manner, as there will most likely be at least one wild-card proof NXT. But why shouldn't the cache be able to respond for an explict query for one of those NXT records? Roy> Some of the above were stated by Olafur last week during the DS Roy> workshop, others were a result of research by Rob Austein and me Roy> (which was presented at Yokohama). -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 17:47:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15371 for ; Tue, 3 Sep 2002 17:47:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mLGF-0004UK-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 14:30:59 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17mLGC-0004U9-00 for namedroppers@ops.ietf.org; Tue, 03 Sep 2002 14:30:56 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g83LRQO94310; Tue, 3 Sep 2002 17:27:26 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Tue, 3 Sep 2002 17:27:26 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Roy Arends cc: David Blacka , "Hallam-Baker, Phillip" , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: <20020903171221.W94281-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 3 Sep 2002, Roy Arends wrote: > On Tue, 3 Sep 2002, David Blacka wrote: > > > >>>>> "ogud" == Olafur Gudmundsson writes: > > > > ogud> This will not happen on my watch, but Opt-in camp needs to > > ogud> answer the open questions in their open park. > > > > Could somebody please restate the open questions about opt-in? Feel > > free to add new open questions. > > As I recall, we need to write: > > - The impact on: Authoritative servers (but this is already clear in draft > IMHO) > [caching] resolvers (basically the change to the resolver > algorihm) > - The current issues: > Clear AD-bit on an opt-in response. > (I think this will be taken care of by the "AD-bit is > secure" authors ). This is for Opt-in to specify, not AD due to dependancy reasons, this definition is only needed if both AD and Opt-in are part of the standard. For the record: this relates to use of NXT between the two names on the NXT (record name and the target name). In DNSSEC where AD bit is used (either RFC2535 or AD-secure definition), the AD bit can be set on responce if it is authenticated denial with NXT, for the QNAME if the NXTNAME == QNAME or (NXTNAME < QNAME and QNAME < NXTargetNAME ) Opt-in NXT must define that this that NXT can only be used when NXTNAME == QNAME to set the AD bit. > Some of the above were stated by Olafur last week during the DS workshop, > others were a result of research by Rob Austein and me (which was > presented at Yokohama). Then there is the minor issue of bytes on the wire, are responses from Opt-in zones smaller/same/larger than from regular DNSSEC zones. And then there is the issue on memory usage in caches, there was an assertation that opt-in zones cause more memory consumption than other DNSSEC zones. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 18:05:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15890 for ; Tue, 3 Sep 2002 18:05:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mLgM-0005pj-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 14:57:58 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17mLgA-0005pI-00 for namedroppers@ops.ietf.org; Tue, 03 Sep 2002 14:57:46 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g83LviLU030129; Tue, 3 Sep 2002 23:57:44 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g83Lviig030125; Tue, 3 Sep 2002 23:57:44 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 3 Sep 2002 23:57:43 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: David Blacka cc: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 3 Sep 2002, David Blacka wrote: > >>>>> "Roy" == Roy Arends writes: > > Roy> On Tue, 3 Sep 2002, David Blacka wrote: > >> >>>>> "ogud" == Olafur Gudmundsson writes: > >> > ogud> This will not happen on my watch, but Opt-in camp needs to > ogud> answer the open questions in their open park. > >> > >> Could somebody please restate the open questions about opt-in? Feel > >> free to add new open questions. > > Roy> As I recall, we need to write: > > Roy> - The impact on: Authoritative servers (but this is already > Roy> clear in draft IMHO) > > Roy> [caching] resolvers (basically the change to the resolver > Roy> algorihm) > > More specifically, what needs to be in the opt-in draft that isn't > already there about this? Or is what is in the draft just not clear > enough? (I am asking the list, not just Roy) And I was just repeating comments. The draft is pretty clear on that, but hey, who am I to judge :-) > Roy> - The current issues: > Roy> Clear AD-bit on an opt-in response. > Roy> (I think this will be taken care of by the "AD-bit is > Roy> secure" authors ). > > Ok. Does this mean the AD bit behavior does not need to be opt-in > draft at all? Or just a reference to a new AD-bit draft? Then lets just fully specify it, better double effort that no effort at all. > Roy> The other (main) issue is caching of NXT/SIG(NXT). When not > Roy> individually queried for, they MUST be cached as properties of > Roy> QNAME/QCLASS/QTYPE or as an integral part of the entire > Roy> answer. They MUST NOT be stored as individual records. However, > Roy> these are DNSSEC issues which are inherited by Opt-In. In other > Roy> words, caches are not more then a "response replay" box, which > Roy> is only allowed to alter the TTLs of records and the > Roy> [E]DNS-header. > > I do not understand the harm in also caching the NXTs as individual > records. This is probably because I do not fully understand the > corner case you and Rob Austein investigated. Wait, thats not what I wrote. When explicitly queried for, yes, the cache can replay the response if, and only if it was cached as result of a previous explicit query for that NXT. > What I do understand is this: opt-in creates a case where for a > postive response, a cache must be able to return the covering opt-in > NXT that goes with the response, and that NXT record does NOT share > its name with qname. Hence, the cache should store the NXT records as > properties of the original qname. I also know that this case also > shows up in negative caching, with or without opt-in. Well, there > will most likely be more than one NXT record to cache in this manner, > as there will most likely be at least one wild-card proof NXT. > > But why shouldn't the cache be able to respond for an explict query > for one of those NXT records? Sure, explicit queries for qtype NXT are okay, as long as cache follows the query, and NOT _reconstruct_ responses from cache. If it has been cached as an individual QNAME/QCLASS/QTYPE, than the cache can simply respond that. But again, simply replay the response, not reconstruct. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 18:27:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16247 for ; Tue, 3 Sep 2002 18:27:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mM2P-00071G-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 15:20:45 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17mM2K-000715-00 for namedroppers@ops.ietf.org; Tue, 03 Sep 2002 15:20:41 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g83MKPLU030497; Wed, 4 Sep 2002 00:20:25 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g83MKPk4030493; Wed, 4 Sep 2002 00:20:25 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 4 Sep 2002 00:20:24 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Olafur Gudmundsson cc: David Blacka , "Hallam-Baker, Phillip" , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <20020903171221.W94281-100000@hlid.dc.ogud.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 3 Sep 2002, Olafur Gudmundsson wrote: > On Tue, 3 Sep 2002, Roy Arends wrote: > > > As I recall, we need to write: ..... > > - The current issues: > > Clear AD-bit on an opt-in response. > > (I think this will be taken care of by the "AD-bit is > > secure" authors ). > > This is for Opt-in to specify, not AD due to dependancy reasons, this > definition is only needed if both AD and Opt-in are part of the standard. Okay. > For the record: this relates to use of NXT between the two names > on the NXT (record name and the target name). > In DNSSEC where AD bit is used (either RFC2535 or AD-secure definition), > the AD bit can be set on responce if it is authenticated denial with NXT, > for the QNAME if the > NXTNAME == QNAME or (NXTNAME < QNAME and QNAME < NXTargetNAME ) > > Opt-in NXT must define that this that NXT can only be used when > NXTNAME == QNAME to set the AD bit. I don't understand what you just wrote. This issue is as follows: "AD-is-secure" states that the AD bit may be set when _all_ resource records in a [negative] response are cryptographically verified to be valid. An Opt-in negative response reaching the resolver only has signed records. This implies AD=1. But, this negative response might have been a positive Opt-In response when it has left the authoritative server. When AD=1 is sent to an application/stub/whatever which places trust in this bit, the application/stub/whatever is effectively misled. So, AD=0 on an Opt-In response effectively takes care of this situation. > > Some of the above were stated by Olafur last week during the DS workshop, > > others were a result of research by Rob Austein and me (which was > > presented at Yokohama). > > Then there is the minor issue of bytes on the wire, are responses > from Opt-in zones smaller/same/larger than from regular DNSSEC zones. > > And then there is the issue on memory usage in caches, there was an > assertation that opt-in zones cause more memory consumption than other > DNSSEC zones. This is true, A positive response with Opt-in holds: QTYPE+NXT+SIG(NXT). A positive response without Opt-in holds: QTYPE+SIG(QTYPE). Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 18:39:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16452 for ; Tue, 3 Sep 2002 18:39:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mMDl-0007fQ-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 15:32:29 -0700 Received: from h227.s231.netsol.com ([216.168.231.227] helo=pinion.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17mMDi-0007fE-00 for namedroppers@ops.ietf.org; Tue, 03 Sep 2002 15:32:26 -0700 Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id 7B0F11AF16; Tue, 3 Sep 2002 18:32:25 -0400 (EDT) To: Roy Arends Cc: namedroppers Subject: Re: DNSSEXT Yokohama Minutes References: From: David Blacka In-Reply-To: (Roy Arends's message of "Tue, 3 Sep 2002 23:57:43 +0200 (CEST)") Date: Tue, 03 Sep 2002 18:32:25 -0400 Message-ID: Lines: 44 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-mandrake-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Roy" == Roy Arends writes: Roy> The other (main) issue is caching of NXT/SIG(NXT). When not Roy> individually queried for, they MUST be cached as properties of Roy> QNAME/QCLASS/QTYPE or as an integral part of the entire Roy> answer. They MUST NOT be stored as individual records. However, Roy> these are DNSSEC issues which are inherited by Opt-In. In other Roy> words, caches are not more then a "response replay" box, which Roy> is only allowed to alter the TTLs of records and the Roy> [E]DNS-header. >> >> I do not understand the harm in also caching the NXTs as individual >> records. This is probably because I do not fully understand the >> corner case you and Rob Austein investigated. Roy> Wait, thats not what I wrote. When explicitly queried for, yes, the cache Roy> can replay the response if, and only if it was cached as result of a Roy> previous explicit query for that NXT. What I was really asking is why the "only if it was cached as result of a previous explicit query for that NXT" condition? If I get NXT records (opt-in or otherwise) in the authority section of a response, I need to cache these NXTs as properties of the qname, but why can't I ALSO cache them as ordinary records? Roy> Sure, explicit queries for qtype NXT are okay, as long as cache Roy> follows the query, and NOT _reconstruct_ responses from Roy> cache. If it has been cached as an individual Roy> QNAME/QCLASS/QTYPE, than the cache can simply respond that. But Roy> again, simply replay the response, not reconstruct. Specifically, what pitfalls exist in reconstructing a positive response to an explit NXT query? The reason I am pursuing this is that I'm trying to imagine how I would build a cache, and I am thinking that I would like to store the NXT records just like any other record in my cache, while having other cache values have pointers to it (rather than storing the NXT set in toto with the original qname). -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 19:51:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17532 for ; Tue, 3 Sep 2002 19:51:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mNI8-000AxL-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 16:41:04 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17mNI2-000Ax2-00 for namedroppers@ops.ietf.org; Tue, 03 Sep 2002 16:40:58 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g83NeZV15289; Tue, 3 Sep 2002 16:40:35 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Tue, 3 Sep 2002 16:40:34 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Roy Arends cc: Olafur Gudmundsson , David Blacka , "Hallam-Baker, Phillip" , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 4 Sep 2002, Roy Arends wrote: > > And then there is the issue on memory usage in caches, there was an > > assertation that opt-in zones cause more memory consumption than other > > DNSSEC zones. > > This is true, > > A positive response with Opt-in holds: QTYPE+NXT+SIG(NXT). > > A positive response without Opt-in holds: QTYPE+SIG(QTYPE). The positive response with opt-in also needs to contain proof that there's no secure wildcard, otherwise secure wildcards can be spoofed away. This will mean another SIG and SIG(NXT) in almost every case. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 3 23:32:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22289 for ; Tue, 3 Sep 2002 23:32:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mQiI-000O2y-00 for namedroppers-data@psg.com; Tue, 03 Sep 2002 20:20:18 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17mQiC-000O29-00 for namedroppers@ops.ietf.org; Tue, 03 Sep 2002 20:20:12 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA06753; Tue, 3 Sep 2002 23:20:08 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA18150; Tue, 3 Sep 2002 23:20:07 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA08714; Tue, 3 Sep 2002 23:20:06 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id XAA11101; Tue, 3 Sep 2002 23:20:05 -0400 (EDT) To: David Blacka Cc: Roy Arends , namedroppers From: Derek Atkins Subject: Re: DNSSEXT Yokohama Minutes References: Date: 03 Sep 2002 23:20:05 -0400 In-Reply-To: Message-ID: Lines: 73 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka writes: > If I get NXT records (opt-in or otherwise) in the authority section of > a response, I need to cache these NXTs as properties of the qname, but > why can't I ALSO cache them as ordinary records? Let me see if I can remember this example that Roy worked through with me in Yokohama (at a very expensive bar, eh Roy? ;) Assume you've got this record at time T0: a in ... in nxt k ... At time T1 you make a query for f and get the "a in nxt k" response. Now, at time T2 the zone is changed and you now have records: a ... in nxt d d ... in nxt k At time T3 you make a query for e. You now have two overlapping NXT records, a->k and d->k. Now you make a query for d. What do you do? You've now got an authoritative negative query for "d" in your cache, but you've also got an authoritative positive response for 'd' in the zone (not cached). Note that this is not just a problem with Opt-in, but opt-in makes the problem worse because records can not only change in terms of existance but also in terms of whether they are signed. Hopefully Roy can better explain this particular issue. > Roy> Sure, explicit queries for qtype NXT are okay, as long as cache > Roy> follows the query, and NOT _reconstruct_ responses from > Roy> cache. If it has been cached as an individual > Roy> QNAME/QCLASS/QTYPE, than the cache can simply respond that. But > Roy> again, simply replay the response, not reconstruct. > > Specifically, what pitfalls exist in reconstructing a positive > response to an explit NXT query? That's not the issue. The issue is if you make a request for NameA/ClassA/TypeA and cache the NXT response, then make a request for NameB/ClassB/TypeB, you should not respond with the NXT obtained from the A/A/A request. In other words, you should not promote the NXT response from request 1 across to request2 unless the Name/Class/Type are the same. > The reason I am pursuing this is that I'm trying to imagine how I > would build a cache, and I am thinking that I would like to store the > NXT records just like any other record in my cache, while having other > cache values have pointers to it (rather than storing the NXT set in > toto with the original qname). NXT records are just special.. The reason is that they can cause a failure in other records, which can lock out a large portion of a zone for long periods of time. As I said, hopefully Roy can better explain this. > David Blacka > Sr. Engineer Verisign Applied Research -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 03:13:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19363 for ; Wed, 4 Sep 2002 03:13:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mUF4-000Ba4-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 00:06:22 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17mUF0-000BZU-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 00:06:18 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g84769CY008473; Wed, 4 Sep 2002 09:06:09 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g84768uO008469; Wed, 4 Sep 2002 09:06:08 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 4 Sep 2002 09:06:08 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Brian Wellington cc: Olafur Gudmundsson , David Blacka , "Hallam-Baker, Phillip" , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 3 Sep 2002, Brian Wellington wrote: > On Wed, 4 Sep 2002, Roy Arends wrote: > > > > And then there is the issue on memory usage in caches, there was an > > > assertation that opt-in zones cause more memory consumption than other > > > DNSSEC zones. > > > > This is true, > > > > A positive response with Opt-in holds: QTYPE+NXT+SIG(NXT). > > > > A positive response without Opt-in holds: QTYPE+SIG(QTYPE). > > The positive response with opt-in also needs to contain proof that there's > no secure wildcard, otherwise secure wildcards can be spoofed away. This > will mean another SIG and SIG(NXT) in almost every case. No, you don't need proof for wildcards. If I was to spoof a resolver, proof of [non-]existence of secure wildcards does not prevent or help me do that. If you asked for something in an unsecured interval, all bets are off. Remember that this is for delegations only. Are you suggesting proof of [absent] signed wildcard delegations ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 03:24:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19528 for ; Wed, 4 Sep 2002 03:24:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mUQQ-000C3g-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 00:18:06 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17mUQN-000C3V-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 00:18:03 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g847HpCY008536; Wed, 4 Sep 2002 09:17:51 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g847HpiG008532; Wed, 4 Sep 2002 09:17:51 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 4 Sep 2002 09:17:51 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Derek Atkins cc: David Blacka , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD,PORN_3 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 3 Sep 2002, Derek Atkins wrote: > David Blacka writes: > > > If I get NXT records (opt-in or otherwise) in the authority section of > > a response, I need to cache these NXTs as properties of the qname, but > > why can't I ALSO cache them as ordinary records? > > Let me see if I can remember this example that Roy worked through > with me in Yokohama (at a very expensive bar, eh Roy? ;) Yes, it still hurts :-) > Assume you've got this record at time T0: > > a in ... > in nxt k ... > > At time T1 you make a query for f and get the "a in nxt k" response. > Now, at time T2 the zone is changed and you now have records: > > a ... > in nxt d > d ... > in nxt k > > At time T3 you make a query for e. You now have two overlapping NXT > records, a->k and d->k. > > Now you make a query for d. What do you do? You've now got an > authoritative negative query for "d" in your cache, but you've also > got an authoritative positive response for 'd' in the zone (not > cached). > > Note that this is not just a problem with Opt-in, but opt-in makes the > problem worse because records can not only change in terms of > existance but also in terms of whether they are signed. > > Hopefully Roy can better explain this particular issue. This is indeed the problem. This problem exist with any accidental "interval overlap". The example I gave in Yokohama had not a match with any QNAME: cached was: a NXT e c NXT f and the query is for d. Which proof of non-existence does a cache return. > > Roy> Sure, explicit queries for qtype NXT are okay, as long as cache > > Roy> follows the query, and NOT _reconstruct_ responses from > > Roy> cache. If it has been cached as an individual > > Roy> QNAME/QCLASS/QTYPE, than the cache can simply respond that. But > > Roy> again, simply replay the response, not reconstruct. > > > > Specifically, what pitfalls exist in reconstructing a positive > > response to an explit NXT query? > > That's not the issue. The issue is if you make a request for > NameA/ClassA/TypeA and cache the NXT response, then make a request for > NameB/ClassB/TypeB, you should not respond with the NXT obtained from > the A/A/A request. In other words, you should not promote the NXT > response from request 1 across to request2 unless the Name/Class/Type > are the same. Bingo. > > The reason I am pursuing this is that I'm trying to imagine how I > > would build a cache, and I am thinking that I would like to store the > > NXT records just like any other record in my cache, while having other > > cache values have pointers to it (rather than storing the NXT set in > > toto with the original qname). > > NXT records are just special.. The reason is that they can cause a > failure in other records, which can lock out a large portion of a zone > for long periods of time. > > As I said, hopefully Roy can better explain this. You did it very well. NXT records are more a statement on other records/types then that they are individual records. (or: NXT records just suck). Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 04:14:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20158 for ; Wed, 4 Sep 2002 04:14:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mV6i-000G6O-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 01:01:48 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17mV6e-000G6B-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 01:01:44 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g8481UCY008917; Wed, 4 Sep 2002 10:01:31 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g8481UXt008913; Wed, 4 Sep 2002 10:01:30 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 4 Sep 2002 10:01:30 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Brian Wellington cc: Olafur Gudmundsson , David Blacka , "Hallam-Baker, Phillip" , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 4 Sep 2002, Roy Arends wrote: > On Tue, 3 Sep 2002, Brian Wellington wrote: > > > On Wed, 4 Sep 2002, Roy Arends wrote: > > > > > > And then there is the issue on memory usage in caches, there was an > > > > assertation that opt-in zones cause more memory consumption than other > > > > DNSSEC zones. > > > > > > This is true, > > > > > > A positive response with Opt-in holds: QTYPE+NXT+SIG(NXT). > > > > > > A positive response without Opt-in holds: QTYPE+SIG(QTYPE). > > > > The positive response with opt-in also needs to contain proof that there's > > no secure wildcard, otherwise secure wildcards can be spoofed away. This > > will mean another SIG and SIG(NXT) in almost every case. > > No, you don't need proof for wildcards. > > If I was to spoof a resolver, proof of [non-]existence of secure wildcards > does not prevent or help me do that. > > If you asked for something in an unsecured interval, all bets are off. > > Remember that this is for delegations only. Are you suggesting proof > of [absent] signed wildcard delegations ? Note that wildcards are in a zone, delegation points are outside a zone, therefor you can't use wildcard delegations, and thus no proof for existing wildcard delegation is needed. roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 09:00:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26203 for ; Wed, 4 Sep 2002 09:00:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mZaY-0001hE-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 05:48:54 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17mZaV-0001h2-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 05:48:51 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g848oM23046438; Wed, 4 Sep 2002 08:50:22 GMT Received: from [192.149.252.169] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA18031; Wed, 4 Sep 2002 08:48:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20020903171221.W94281-100000@hlid.dc.ogud.com> References: <20020903171221.W94281-100000@hlid.dc.ogud.com> Date: Wed, 4 Sep 2002 08:25:22 -0400 To: Olafur Gudmundsson , Roy Arends From: Edward Lewis Subject: NXTNAME? was Re: DNSSEXT Yokohama Minutes Cc: David Blacka , "Hallam-Baker, Phillip" , namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,SUBJ_HAS_Q_MARK,DOUBLE_CAPSWORD,UPPERCASE_25_50 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:27 PM -0400 9/3/02, Olafur Gudmundsson wrote: > NXTNAME == QNAME or (NXTNAME < QNAME and QNAME < NXTargetNAME ) By "NXTNAME," do you mean the NXT RR set owner name? (ONAME?) Also, there is the case that the "target" name = apex name ( = signer name). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 10:05:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00359 for ; Wed, 4 Sep 2002 10:05:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mabc-0004sa-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 06:54:04 -0700 Received: from h227.s231.netsol.com ([216.168.231.227] helo=pinion.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17mabY-0004sP-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 06:54:00 -0700 Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id 0185E1AF16; Wed, 4 Sep 2002 09:53:57 -0400 (EDT) To: Derek Atkins Cc: Roy Arends , namedroppers Subject: Re: DNSSEXT Yokohama Minutes References: From: David Blacka In-Reply-To: (Derek Atkins's message of "03 Sep 2002 23:20:05 -0400") Date: Wed, 04 Sep 2002 09:53:57 -0400 Message-ID: Lines: 69 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-mandrake-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Derek" == Derek Atkins writes: >> Specifically, what pitfalls exist in reconstructing a positive >> response to an explit NXT query? Derek> That's not the issue. The issue is if you make a request for Derek> NameA/ClassA/TypeA and cache the NXT response, then make a Derek> request for NameB/ClassB/TypeB, you should not respond with Derek> the NXT obtained from the A/A/A request. In other words, you Derek> should not promote the NXT response from request 1 across to Derek> request2 unless the Name/Class/Type are the same. Suppose my caching resolver first issues the following: Q: foo.bar. IN A And gets back: AUTH: a.bar IN NXT g.bar a.bar IN SIG NXT ... Next, it issues the following: Q: a.bar. IN NXT is there a problem returning: ANS: a.bar IN NXT g.bar a.bar IN SIG NXT ... ? Or even: Q: a.bar. IN ANY ANS: a.bar IN NXT ... a.bar IN SIG NXT ... Note that I'm not suggesting that the resolver build negative proof out of NXT records that it has in its cache. You (and Roy) illustrated the potential problems with that fairly clearly. I am trying to draw a distinction between Roy's stated requirement that "[NXT records] MUST NOT be stored as individual records", and a slightly weaker restriction that resolvers MUST NOT use cached NXT records to construct new negative (or opt-in) proofs. Of course, I think that this particular example that I'm bringing up is not very natural. I'm not sure that this particular query sequence would occur except for debugging. >> The reason I am pursuing this is that I'm trying to imagine how I >> would build a cache, and I am thinking that I would like to store the >> NXT records just like any other record in my cache, while having other >> cache values have pointers to it (rather than storing the NXT set in >> toto with the original qname). When I said this, I was not imagining that the resolver be able to do anything with the NXT records other than respond to a direct query for them. Derek> As I said, hopefully Roy can better explain this. You did a pretty good job. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 10:34:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01922 for ; Wed, 4 Sep 2002 10:34:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mb42-0006Lz-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 07:23:26 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17mb3x-0006LC-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 07:23:21 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 4BEF428B6F for ; Wed, 4 Sep 2002 14:23:21 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from Roy Arends of "Wed, 04 Sep 2002 09:17:51 +0200." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 04 Sep 2002 14:23:21 +0000 Message-Id: <20020904142321.4BEF428B6F@as.vix.com> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The example I gave in Yokohama had not a match with any QNAME: > > cached was: > > a NXT e > c NXT f > > and the query is for d. Which proof of non-existence does a cache return. it's starting to seem to me that answers containing NXT should include an SOA in the authority section. (even though that means nonauthoritative servers will have to cache them, which today is illegal.) when new secure (verified) data arrives with a later SOA.SERIAL, all the older cached data for that zone becomes invalid. this is something we've discussed previously for all data, not just security metagoo. it has a high price both in storage, transport, and computation, but not as high as dnssec overall, so i think it's finally worth considering. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 10:37:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02147 for ; Wed, 4 Sep 2002 10:37:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mb9h-0006cv-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 07:29:17 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17mb9d-0006cV-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 07:29:13 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA01673; Wed, 4 Sep 2002 10:29:07 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA10466; Wed, 4 Sep 2002 10:29:06 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA16243; Wed, 4 Sep 2002 10:29:05 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA12302; Wed, 4 Sep 2002 10:29:06 -0400 (EDT) To: David Blacka Cc: Roy Arends , namedroppers From: Derek Atkins Subject: Re: DNSSEXT Yokohama Minutes References: Date: 04 Sep 2002 10:29:06 -0400 In-Reply-To: Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka writes: [example snipped] Let me give a different example (similar to before). Note that between query-1 and query-2 the zone has changed. Q: foo.bar. IN A AUTH: a.bar IN NXT g.bar a.bar IN SIG NXT ... Q: baz.bar. IN A AUTH: a.bar IN NXT d.bar a.bar IN SIG NXT ... Q: a.bar IN ANY (or IN NXT) AUTH: ??? What do you return here? This is still the same problem. Do you return both? Do you choose one? > Note that I'm not suggesting that the resolver build negative proof > out of NXT records that it has in its cache. You (and Roy) > illustrated the potential problems with that fairly clearly. > > I am trying to draw a distinction between Roy's stated requirement > that "[NXT records] MUST NOT be stored as individual records", and a > slightly weaker restriction that resolvers MUST NOT use cached NXT > records to construct new negative (or opt-in) proofs. > > Of course, I think that this particular example that I'm bringing up > is not very natural. I'm not sure that this particular query sequence > would occur except for debugging. Yes, but as I (hopefully) pointed out, it can be just as problematic. > Derek> As I said, hopefully Roy can better explain this. > > You did a pretty good job. Thank you. I wasn't so sure last night. > David Blacka > Sr. Engineer Verisign Applied Research -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 10:51:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03085 for ; Wed, 4 Sep 2002 10:51:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mbMC-0007LH-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 07:42:12 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17mbM1-0007Kv-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 07:42:02 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g84EfvCY013608; Wed, 4 Sep 2002 16:41:57 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian -7) with ESMTP id g84Efvug013604; Wed, 4 Sep 2002 16:41:57 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 4 Sep 2002 16:41:57 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: David Blacka cc: Derek Atkins , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 4 Sep 2002, David Blacka wrote: > >>>>> "Derek" == Derek Atkins writes: > > >> Specifically, what pitfalls exist in reconstructing a positive > >> response to an explit NXT query? > > Derek> That's not the issue. The issue is if you make a request for > Derek> NameA/ClassA/TypeA and cache the NXT response, then make a > Derek> request for NameB/ClassB/TypeB, you should not respond with > Derek> the NXT obtained from the A/A/A request. In other words, you > Derek> should not promote the NXT response from request 1 across to > Derek> request2 unless the Name/Class/Type are the same. > > Suppose my caching resolver first issues the following: > > Q: foo.bar. IN A > > And gets back: > > AUTH: a.bar IN NXT g.bar > a.bar IN SIG NXT ... > > Next, it issues the following: > > Q: a.bar. IN NXT > > is there a problem returning: > > ANS: a.bar IN NXT g.bar > a.bar IN SIG NXT ... > > ? Yes, the problem is that you synthesize parts of a negative response to satisfy a positive response. Next to the TTL issues involved, the matching algorithm to satisfy the query from cache is horribly complicated, especially when different caching methods are used for pos. and neg. caching. > Or even: > > Q: a.bar. IN ANY > > ANS: a.bar IN NXT ... > a.bar IN SIG NXT ... If you mean QTYPE=* then this poses another difficulty (DNSSEC, not Opt-In). With this optimised matching, you might not find a complete answer. Since you probably want all record types that exist at an owner name (listed in the NXT type bit map), but you only get the NXT record from cache, since that satisfies the matching. There is no way to get a better response, other then wait TTL+1 second. > Note that I'm not suggesting that the resolver build negative proof > out of NXT records that it has in its cache. You (and Roy) > illustrated the potential problems with that fairly clearly. Okay, but the first example looked like you are doing exactly that. > I am trying to draw a distinction between Roy's stated requirement > that "[NXT records] MUST NOT be stored as individual records", and a > slightly weaker restriction that resolvers MUST NOT use cached NXT > records to construct new negative (or opt-in) proofs. Wait, it is no problem to cache NXT records as individual records, but _only_ as a result of a query where QTYPE is NXT. This is what I said: "The other (main) issue is caching of NXT/SIG(NXT). When not individually queried for, they MUST be cached as properties of QNAME/QCLASS/QTYPE or as an integral part of the entire answer. They MUST NOT be stored as individual records." The key-sentence here is "When not individually queried for". I referred to type=NXT Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 12:56:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10087 for ; Wed, 4 Sep 2002 12:56:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mdDZ-000DkP-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 09:41:25 -0700 Received: from cpe-24-221-172-100.ca.sprintbbd.net ([24.221.172.100] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17mdDR-000Djs-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 09:41:17 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g84GepN19025; Wed, 4 Sep 2002 09:40:52 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 4 Sep 2002 09:40:51 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Roy Arends cc: Olafur Gudmundsson , David Blacka , "Hallam-Baker, Phillip" , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD, RCVD_IN_RFCI version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 4 Sep 2002, Roy Arends wrote: > On Tue, 3 Sep 2002, Brian Wellington wrote: > > > On Wed, 4 Sep 2002, Roy Arends wrote: > > > > > > And then there is the issue on memory usage in caches, there was an > > > > assertation that opt-in zones cause more memory consumption than other > > > > DNSSEC zones. > > > > > > This is true, > > > > > > A positive response with Opt-in holds: QTYPE+NXT+SIG(NXT). > > > > > > A positive response without Opt-in holds: QTYPE+SIG(QTYPE). > > > > The positive response with opt-in also needs to contain proof that there's > > no secure wildcard, otherwise secure wildcards can be spoofed away. This > > will mean another SIG and SIG(NXT) in almost every case. > > No, you don't need proof for wildcards. > > If I was to spoof a resolver, proof of [non-]existence of secure wildcards > does not prevent or help me do that. > > If you asked for something in an unsecured interval, all bets are off. > > Remember that this is for delegations only. Are you suggesting proof > of [absent] signed wildcard delegations ? No, I'm suggesting proof of absent wildcards. While opt-in might be restricted to delegations, that doesn't mean that the zone is. For example, consider the foo.com zone, with: @ SOA NS * A a NS c NS e NS Without DNSSEC, querying for www.b.foo.com will hit the wildcard A record, and querying for www.c.foo.com will return a referral. Now sign the zone, and have 'a' and 'e' signed, and 'c' unsigned: @ SOA SIG SOA NS SIG NS KEY SIG KEY NXT SIG NXT * A SIG A NXT SIG NXT a NS DS SIG DS NXT SIG NXT c NS e NS DS SIG DS NXT SIG NXT (Hope I didn't miss anything there) Query for www.c.foo.com. According to your claim, you should just give out the referral (NS + DS + SIG DS) and the proof that the name is insecure (a's NXT and SIG NXT). Query for www.b.foo.com, and have a malicious server replay a response with the same insecurity proof, and a forged unsigned referral. There's no way to prove it's false, and you've now spoofed away the existence of a secure name, since www.b.foo.com was secure in the non-optin case. Yes, this is bad. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 14:02:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13546 for ; Wed, 4 Sep 2002 14:02:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17meEh-000H3Y-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 10:46:39 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17meEe-000H3M-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 10:46:36 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id D049028B6F for ; Wed, 4 Sep 2002 17:46:35 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from Brian Wellington of "Wed, 04 Sep 2002 09:40:51 MST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 04 Sep 2002 17:46:35 +0000 Message-Id: <20020904174635.D049028B6F@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk can someone explain why we don't just outlaw wildcard records in signed zones? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 14:47:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15473 for ; Wed, 4 Sep 2002 14:47:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mf4x-000JUU-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 11:40:39 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17mf4u-000JUJ-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 11:40:36 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 2AAD1137F02; Wed, 4 Sep 2002 11:40:36 -0700 (PDT) To: Paul Vixie Cc: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from Paul Vixie of "Wed, 04 Sep 2002 17:46:35 -0000." <20020904174635.D049028B6F@as.vix.com> Date: Wed, 04 Sep 2002 11:40:36 -0700 Message-ID: <94553.1031164836@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Paul" == Paul Vixie writes: Paul> can someone explain why we don't just outlaw wildcard Paul> records in signed zones? Why stop at outlawing them in signed zones? :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 15:00:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16176 for ; Wed, 4 Sep 2002 15:00:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mfCz-000JuQ-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 11:48:57 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17mfCt-000Ju4-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 11:48:51 -0700 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g84IjSh96732; Wed, 4 Sep 2002 14:45:28 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020904144349.018351a0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 04 Sep 2002 14:48:05 -0400 To: Paul Vixie , namedroppers From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <20020904174635.D049028B6F@as.vix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:46 2002-09-04, Paul Vixie wrote: >can someone explain why we don't just outlaw wildcard records in signed zones? Once you convince the world that following is not needed in any zone. * MX 10 MX 20 Then killing wildcards is becomes a possibility. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 16:03:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19164 for ; Wed, 4 Sep 2002 16:03:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mgBT-000Mmi-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 12:51:27 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17mgBQ-000MmX-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 12:51:25 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 7D9AE28B6F for ; Wed, 4 Sep 2002 19:51:24 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= of "Wed, 04 Sep 2002 14:48:05 -0400." <5.1.1.6.2.20020904144349.018351a0@localhost> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 04 Sep 2002 19:51:24 +0000 Message-Id: <20020904195124.7D9AE28B6F@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Once you convince the world that following is not needed in any zone. > > * MX 10 > MX 20 > > Then killing wildcards is becomes a possibility. "convincing the world" == "boiling the ocean." let's just convince the world that if they want wildcards then they have already discarded all hope of security, so they don't need dnssec for zones using wildcards. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 16:22:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19759 for ; Wed, 4 Sep 2002 16:22:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mgXq-000Nuq-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 13:14:34 -0700 Received: from h070.p072.iij4u.or.jp ([210.130.72.70] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17mgXm-000Nua-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 13:14:31 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17mgXj-0005rE-00; Wed, 04 Sep 2002 13:14:27 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers Subject: Re: DNSSEXT Yokohama Minutes References: <20020904174635.D049028B6F@as.vix.com> Message-Id: Date: Wed, 04 Sep 2002 13:14:27 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > can someone explain why we don't just outlaw wildcard records in signed > zones? folk use wildcard MX. expect significant wildcard use in e164.arpa to point whole city or country codes off to ldap servers. etc. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 16:43:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20914 for ; Wed, 4 Sep 2002 16:43:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mgsX-000Ovd-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 13:35:57 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17mgsU-000OvQ-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 13:35:54 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 581733FDC; Wed, 4 Sep 2002 22:35:49 +0200 (CEST) Date: Wed, 4 Sep 2002 22:35:49 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers Subject: Re: DNSSEXT Yokohama Minutes Message-ID: <20020904203549.GA1626@outpost.ds9a.nl> References: <5.1.1.6.2.20020904144349.018351a0@localhost> <20020904195124.7D9AE28B6F@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020904195124.7D9AE28B6F@as.vix.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Sep 04, 2002 at 07:51:24PM +0000, Paul Vixie wrote: > > Once you convince the world that following is not needed in any zone. > > > > * MX 10 > > MX 20 > > > > Then killing wildcards is becomes a possibility. > > "convincing the world" == "boiling the ocean." let's just convince the > world that if they want wildcards then they have already discarded all > hope of security, so they don't need dnssec for zones using wildcards. the case for dnssec is thin enough as it is and right now can't withstand even the slightest restriction of functionality. Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 20:25:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25623 for ; Wed, 4 Sep 2002 20:25:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mkHH-0008rZ-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 17:13:43 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17mkH6-0008rH-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 17:13:32 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id C411528B6F for ; Thu, 5 Sep 2002 00:13:31 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: draft-dnsext-edns1-04.txt In-Reply-To: Message from "Eric A. Hall" of "Sun, 01 Sep 2002 11:00:55 EST." <3D7239B7.1070908@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 05 Sep 2002 00:13:31 +0000 Message-Id: <20020905001331.C411528B6F@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > more later. > > I'm going to assume that you've reach a state of torture over the higher > processing demands from multiple queries, where fallback processing always > requires two questions to the delegation tree, the first of which always > results in SERVFAIL. nope. i'm just giving up on pleasing you, for now at least. if i hear from anyone else i'll assume that EDNS1 is worth pursuing. otherwise it's dead and you should just repost the ADDR draft. i cannot keep up with such high argument-volume from a single participant unless there is some evidence from someone else in the community that the effort of continuing would be worthwhile. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 20:27:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25652 for ; Wed, 4 Sep 2002 20:27:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mkOd-0009Ej-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 17:21:19 -0700 Received: from c143.apnic14.nic.ad.jp ([202.11.26.143] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17mkOa-0009EY-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 17:21:16 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17mkOX-00064J-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 17:21:13 -0700 Message-Id: <200209042220.g84MKPcX015971@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: namedroppers Subject: draft-richardson-ipsec-rr-00.txt Date: Wed, 04 Sep 2002 18:20:24 -0400 From: Michael Richardson X-Spam-Status: No, hits=-2.6 required=5.0 tests=TO_LOCALPART_EQ_REAL,LINES_OF_YELLING,PGP_SIGNATURE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] -----BEGIN PGP SIGNED MESSAGE----- I have seen no discussion about my proposal. I will assume that it was well taken. I would ask that the WG consider adopting proposal for incorporation into the new set of DNSSEC documents that are being prepared. ==== I would very much like to make sure that restrict-key-for-dnssec properly documents the arguments, so that they don't need to repeated endlessly. This means detailing the following things: 1) "problematic" (I would write text, but I don't know what the problems are). 2) Detail, with an example, how additional KEY RR at the APEX of a zone cause problems for resolvers. 3) explain how public keys and IP addresses are different. Explain how it is that we are willing to sign A records, even though it is often the case that one is managed by network admins, while the other is managed by DNS admins. 4) how the solution of moving non-DNSSEC keys to another RR deals with the motivations 2,3,5,6. It seems that the presence of any non-DNSSEC key could "confuse" someone. 5) explain the impact of DS on the concerns about exchange of public key info with the parent. 6) explain why rules concerning placement of non-DNSSEC KEY RR will not solve the described problems. ] 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 Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPXaHJoqHRg3pndX9AQH9MgQAkinZ7iC5NPIb14tEZd1rx9TQn+GGRMvz FeI6O/PIzvfmnQ8bPowJ1SNUyHL3KJLYyxNC43wmwTjMHz1cahhOrK7GmzKvzwEa +ZY1sphB3gvCy/9y12FlsXDju+IfyQZYkaobvmfSBmnRnlqMd2QTXPNskFjesBoV vYJGv8wQVp0= =Sba5 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 21:05:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26136 for ; Wed, 4 Sep 2002 21:05:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mky2-000Ax4-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 17:57:54 -0700 Received: from c143.apnic14.nic.ad.jp ([202.11.26.143] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17mkxz-000Awt-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 17:57:51 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17mkxt-000686-00; Wed, 04 Sep 2002 17:57:45 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Richardson Cc: namedroppers Subject: Re: draft-richardson-ipsec-rr-00.txt References: <200209042220.g84MKPcX015971@marajade.sandelman.ottawa.on.ca> Message-Id: Date: Wed, 04 Sep 2002 17:57:45 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I have seen no discussion about my proposal. I will assume that > it was well taken. this assumption is not safe > I would ask that the WG consider adopting proposal for > incorporation into the new set of DNSSEC documents that are being > prepared. it should be in a security wg with coordination with dnsext > I would very much like to make sure that restrict-key-for-dnssec > properly documents the arguments, so that they don't need to > repeated endlessly. the arguments are simple, we need keys to sign dns data. on the other hand, arguing why it should not be used for an innumerable set of other things is not known to terminate. hence endlessness is expected. life goes on. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 23:03:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28731 for ; Wed, 4 Sep 2002 23:03:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mmkr-000GJ9-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 19:52:25 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.36 #1) id 17mmkn-000GIj-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 19:52:21 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; Wed, 4 Sep 2002 22:52:21 -0400 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Wed, 4 Sep 2002 22:52:05 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002090422520414248 ; Wed, 04 Sep 2002 22:52:04 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Sep 2002 22:51:54 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2DDE@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Paul Vixie '" Cc: "'namedroppers '" Subject: RE: draft-dnsext-edns1-04.txt Date: Wed, 4 Sep 2002 22:48:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie had written: > if i hear from anyone else i'll assume that EDNS1 is worth pursuing. > otherwise it's dead and you should just repost the ADDR draft. Paul-- Please don't put EDNS1 in a sack and throw it off a bridge. From my read of the re-written EDNS1 I believe it's worth pursuing, as I believe that it's A. better than the Eric's ADDR draft and B. correct and nearly sufficient as it currently stands. Actually, I think it's better already than some of the pre-existing DNS-related RFCs, in terms of adequately specifying the details. While I understand that Eric would prefer to have many more things included, I don't believe that such changes are immediately required...and EDNS1 would be better in several (small but useful) ways than what we have now. (If) there's going to be a flag day soon that will require many implementors to consider changes; now might be a sensible time to try to get EDNS1 out there as well--IMHO anyway. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 23:18:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29000 for ; Wed, 4 Sep 2002 23:18:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mn5C-000HPp-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 20:13:26 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17mn57-000HOu-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 20:13:21 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA27865; Wed, 4 Sep 2002 23:13:20 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA29293; Wed, 4 Sep 2002 23:10:39 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id XAA04865; Wed, 4 Sep 2002 23:06:28 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id XAA13602; Wed, 4 Sep 2002 23:06:29 -0400 (EDT) To: Paul Vixie Cc: namedroppers From: Derek Atkins Subject: Re: draft-dnsext-edns1-04.txt References: <20020905001331.C411528B6F@as.vix.com> Date: 04 Sep 2002 23:06:29 -0400 In-Reply-To: <20020905001331.C411528B6F@as.vix.com> Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > nope. i'm just giving up on pleasing you, for now at least. if i hear from > anyone else i'll assume that EDNS1 is worth pursuing. otherwise it's dead > and you should just repost the ADDR draft. i cannot keep up with such high > argument-volume from a single participant unless there is some evidence from > someone else in the community that the effort of continuing would be > worthwhile. I think multiple queries is a good idea, if we can work out all the corner cases. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 4 23:28:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29121 for ; Wed, 4 Sep 2002 23:28:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mnDk-000Hro-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 20:22:16 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17mnDh-000Hrd-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 20:22:13 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA26132; Wed, 4 Sep 2002 23:22:12 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA00867; Wed, 4 Sep 2002 23:22:12 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA00730; Wed, 4 Sep 2002 23:22:11 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id XAA15756; Wed, 4 Sep 2002 23:22:10 -0400 Subject: Re: draft-dnsext-edns1-04.txt From: Greg Hudson To: Derek Atkins Cc: namedroppers In-Reply-To: References: <20020905001331.C411528B6F@as.vix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 04 Sep 2002 23:22:10 -0400 Message-Id: <1031196130.5624.138.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2002-09-04 at 23:06, Derek Atkins wrote: > I think multiple queries is a good idea, if we can work out all > the corner cases. Agreed. And there are a couple of 90% answers to the initial-overhead problem: 1. Wait a few years before taking advantage of multiple queries on a large scale. Most name servers will have upgraded for other reasons. 2. Cache (by IP address) whether a name server supports EDNS1. Particularly at the stub resolver, this can effectively reduce the overhead. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 00:13:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29716 for ; Thu, 5 Sep 2002 00:13:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mnnq-000Jsv-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 20:59:34 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17mnnl-000JqG-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 20:59:30 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0C87A18E0 for ; Wed, 4 Sep 2002 23:58:58 -0400 (EDT) Date: Wed, 04 Sep 2002 23:58:57 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: draft-dnsext-edns1-04.txt In-Reply-To: <20020905001331.C411528B6F@as.vix.com> References: <3D7239B7.1070908@ehsco.com> <20020905001331.C411528B6F@as.vix.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020905035858.0C87A18E0@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 05 Sep 2002 00:13:31 +0000, Paul Vixie wrote: > > if i hear from anyone else i'll assume that EDNS1 is worth pursuing. > otherwise it's dead and you should just repost the ADDR draft. i > cannot keep up with such high argument-volume from a single > participant unless there is some evidence from someone else in the > community that the effort of continuing would be worthwhile. I don't know whether EDNS1 is worth pursuing at this time, and "don't know" isn't a euphemism for "it's not", I really don't know. If the caching system is hopelessly screwed and we need to do something else to let the application forcibly optimize the query process, I think that EDNS1 is the right "something else" to pursue. However, since the available evidence to date has not convinced me that the caching system is hopelessly screwed, I'd rather just let the caching system do its thing and avoid another nontrivial protocol change while we're trying to finish DNSSEC. Not blaming anybody for the lack of hard evidence or running down Paul's EDNS1 proposal, BTW, just trying to answer Paul's implied question. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 00:31:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00264 for ; Thu, 5 Sep 2002 00:31:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mo7i-000KxH-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 21:20:06 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17mo7e-000Kwt-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 21:20:02 -0700 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g854Gbh97526 for ; Thu, 5 Sep 2002 00:16:37 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020905000753.01584408@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 05 Sep 2002 00:19:17 -0400 To: namedroppers From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Wildcard elimination (Was Re: DNSEXT Yokohama Minutes) In-Reply-To: <20020904195124.7D9AE28B6F@as.vix.com> References: <5.1.1.6.2.20020904144349.018351a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:51 2002-09-04, Paul Vixie wrote: > > Once you convince the world that following is not needed in any zone. > > > > * MX 10 > > MX 20 > > > > Then killing wildcards is becomes a possibility. > >"convincing the world" == "boiling the ocean." let's just convince the >world that if they want wildcards then they have already discarded all >hope of security, so they don't need dnssec for zones using wildcards. Paul, I hope one day to kill wild cards but there is no way that can be done without educating the current users/abusers of wild cards how to accomplish the same thing without wild cards. You (as an author on a book about real popular mail delivery program) are in much better position than most of us to explain why wildcards are not needed for Mail delivery. If that argument can be made, then largest current usage of wildcards can be explained away, then we can take on the next group and so on. Before we know it there will be no reason to use wild cards at that point we can take on the standards action of removing wild card support in DNS. We must not offend potential users of DNSSEC by taking away something they depend on every day. 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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 02:05:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08344 for ; Thu, 5 Sep 2002 02:05:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mpVy-000PKK-00 for namedroppers-data@psg.com; Wed, 04 Sep 2002 22:49:14 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17mpVu-000PK9-00 for namedroppers@ops.ietf.org; Wed, 04 Sep 2002 22:49:10 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 0121728B6F for ; Thu, 5 Sep 2002 05:49:10 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: Wildcard elimination (Was Re: DNSEXT Yokohama Minutes) In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= of "Thu, 05 Sep 2002 00:19:17 -0400." <5.1.1.6.2.20020905000753.01584408@localhost> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 05 Sep 2002 05:49:09 +0000 Message-Id: <20020905054910.0121728B6F@as.vix.com> X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Paul, I hope one day to kill wild cards but there is no way that can > be done without educating the current users/abusers of wild cards how to > accomplish the same thing without wild cards. that's fine, though. there are three classes of wildcard user, and none of them is affected in any way by my proposal to preclude wildcard names from being present in signed zones. 1. for folks who use * because they don't want to enumerate a lot of names, they can just start enumerating those names. it's possible that they would then ask for opt-in depending on how many names we'd be talking about, but they have a workaround over and above "just don't sign that zone, then." 2. for folks who use * because they cannot enumerate because the names are not knowable in advance, dnssec would not make their zone more secure and they should not miss it since it wouldn't do them any good anyway. 3. for folks who use * because it was in some template zone and they never actually depend on it since their genericfrom mail addresses all end in @DOM rather than @HOST.DOM, they can just remove the nfg *. most uses of wildcard are of the third (completely gratuitious and unused) kind. i think we have overcomplicated an already fragile dnssec design and considerably lengthened its specification/development/deployment cycle for the protection of wildcarding that does not matter. the DS problem is just the last straw for secure wildcards. let's legislate them out of existence. > You (as an author on a book about real popular mail delivery program) > are in much better position than most of us to explain why wildcards > are not needed for Mail delivery. i see your mail here as From: ...@ogud.com. no wildcards are needed to reply to it. it's only if your mail was From: ...@ENGILL.ogud.com or From: ...@mail.dc.ogud.com *AND* you did not want to install MX's for both engill and mail.dc that a "* MX" would be necessary. > If that argument can be made, then largest current usage of wildcards > can be explained away, then we can take on the next group and so on. go for it. > Before we know it there will be no reason to use wild cards at that point > we can take on the standards action of removing wild card support in DNS. no. we must not invalidate existing zones. we can however make a sieve for them such that only zones without wildcards can utilize the DNSSEC featureset. > We must not offend potential users of DNSSEC by taking away something they > depend on every day. show 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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 04:35:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12800 for ; Thu, 5 Sep 2002 04:35:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mrs6-0005eH-00 for namedroppers-data@psg.com; Thu, 05 Sep 2002 01:20:14 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17mrs1-0005e6-00 for namedroppers@ops.ietf.org; Thu, 05 Sep 2002 01:20:09 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1D40128E16 for ; Thu, 5 Sep 2002 08:20:09 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: draft-dnsext-edns1-04.txt In-Reply-To: Message from Greg Hudson of "04 Sep 2002 23:22:10 -0400." <1031196130.5624.138.camel@error-messages.mit.edu> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 05 Sep 2002 08:20:09 +0000 Message-Id: <20020905082009.1D40128E16@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I think multiple queries is a good idea, if we can work out all > > the corner cases. > > Agreed. gentlemen, thank you for those affirmations, let's keep pushing EDNS1 then. i'll ask eric to find an intermediary -- rob a. would be ideal -- to try to collate and communicate his (eric's) concerns, since i'm having a LOT of trouble digesting them directly. > And there are a couple of 90% answers to the initial-overhead problem: i thought that kre's analysis of this was on point -- there is no problem. > 1. Wait a few years before taking advantage of multiple queries on a > large scale. Most name servers will have upgraded for other reasons. i wish that i agreed with that second sentence, but the surveys still show an awful lot of bind4.8.1 servers out on the net, plus others more recent. > 2. Cache (by IP address) whether a name server supports EDNS1. > Particularly at the stub resolver, this can effectively reduce the > overhead. this is mentioned, obliquely, in EDNS0: 5.3. Responders who do not understand these protocol extensions are expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL. Therefore use of extensions should be ``probed'' such that a responder who isn't known to support them be allowed a retry with no extensions if it responds with such an RCODE. If a responder's capability level is cached by a requestor, a new probe should be sent periodically to test for changes to responder capability. i think this is the part rob a. had trouble with, that begat edns0.5. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 04:51:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13104 for ; Thu, 5 Sep 2002 04:51:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ms8x-0006Ep-00 for namedroppers-data@psg.com; Thu, 05 Sep 2002 01:37:39 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17ms8u-0006Ed-00 for namedroppers@ops.ietf.org; Thu, 05 Sep 2002 01:37:36 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 3FDF128B6F for ; Thu, 5 Sep 2002 08:37:35 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-dnsext-edns1-04.txt In-Reply-To: Message from Rob Austein of "Wed, 04 Sep 2002 23:58:57 -0400." <20020905035858.0C87A18E0@thrintun.hactrn.net> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 05 Sep 2002 08:37:35 +0000 Message-Id: <20020905083735.3FDF128B6F@as.vix.com> X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,ORDER_NOW version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If the caching system is hopelessly screwed and we need to do > something else to let the application forcibly optimize the query > process, I think that EDNS1 is the right "something else" to pursue. > > However, since the available evidence to date has not convinced me > that the caching system is hopelessly screwed, I'd rather just let the > caching system do its thing and avoid another nontrivial protocol > change while we're trying to finish DNSSEC. > > Not blaming anybody for the lack of hard evidence or running down > Paul's EDNS1 proposal, BTW, just trying to answer Paul's implied > question. i think kre's analysis applies here, so i won't repeat it, but i will put in my own two bits. caching, specifically negative caching, can speed up the total dns transaction time and thus cut down the interval between "when you know where you want to go" and "when you can initiate your session". this is critical for overall "internet" performance, perhaps more significant than the bits per second per flow will be in the average case. i won't quibble about the lack of negative caching deployment, since EDNS1 would have a similar deployment mountain to climb. however, the cost of a cache miss will be higher with two full round trips from the intermediate server to the authority server than it is with one. if we expect AAAA and A, or MX and A, or all three, to be a common query pattern in the future, and if we expect any diversity among query patterns (such that some clients might query in one order while others query in some other order), then new successful flows will remain expensive due to the (positive) cache misses and new error flows will remain expensive due to the (negative) cache misses. forever. i see multiple queries as (1) an intended part of the original architecture which was left underspecified, and (2) a necessary feature in the long run if we don't want dns to remain a significant part of our total transaction or session initiation times. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 07:29:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15456 for ; Thu, 5 Sep 2002 07:29:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mugB-000C1w-00 for namedroppers-data@psg.com; Thu, 05 Sep 2002 04:20:07 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17mug5-000C1I-00 for namedroppers@ops.ietf.org; Thu, 05 Sep 2002 04:20:01 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14941; Thu, 5 Sep 2002 07:18:21 -0400 (EDT) Message-Id: <200209051118.HAA14941@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-00.txt Date: Thu, 05 Sep 2002 07:18:21 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,DOUBLE_CAPSWORD,EXCUSE_6 version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : KEY RR Key Signing (KS) Flag Author(s) : O. Kolkman Filename : draft-ietf-dnsext-keyrr-key-signing-flag-00.txt Pages : 6 Date : 2002-9-4 The Introduction of the DS [1] record has introduced the concept of KEY signing and zone signing keys. In general, KEY signing keys are the keys that are pointed to by DS records and are the secure entry points to a zone. The key signing keys only sign the KEY RRset at the apex of a zone, zone signing keys sign all data in a zone. We propose a flag to distinguish the KEY signing key from other keys in the KEY RR set during DNSSEC operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-dnsext-keyrr-key-signing-flag-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-ietf-dnsext-keyrr-key-signing-flag-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-4143038.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-4143038.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 09:53:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19476 for ; Thu, 5 Sep 2002 09:53:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mwph-000HTI-00 for namedroppers-data@psg.com; Thu, 05 Sep 2002 06:38:05 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17mwpY-000HT3-00 for namedroppers@ops.ietf.org; Thu, 05 Sep 2002 06:37:56 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA13224; Thu, 5 Sep 2002 09:37:54 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA08088; Thu, 5 Sep 2002 09:37:54 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA23358; Thu, 5 Sep 2002 09:37:53 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA14770; Thu, 5 Sep 2002 09:37:53 -0400 (EDT) To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: draft-dnsext-edns1-04.txt References: <20020905083735.3FDF128B6F@as.vix.com> Date: 05 Sep 2002 09:37:53 -0400 In-Reply-To: <20020905083735.3FDF128B6F@as.vix.com> Message-ID: Lines: 27 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > i see multiple queries as (1) an intended part of the original > architecture which was left underspecified, and (2) a necessary feature > in the long run if we don't want dns to remain a significant part of our > total transaction or session initiation times. When I first started playing with DNS implementations in '95 I was very surprised to find out that one could not send multiple queries in one message. What's the point of the query count if the value _must_ be 1? At the time, I was working on a Secure Dynamic Update implementation and, as I recall having multiple queries would have helped me significantly. In other words, I agree COMPLETELY that multiple queries were an intended part of the original archicture, but I also believe that (at the time) there were too many potential issues (corner cases) so people didn't want to cope. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 10:39:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21056 for ; Thu, 5 Sep 2002 10:39:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mxcy-000Jpd-00 for namedroppers-data@psg.com; Thu, 05 Sep 2002 07:29:00 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17mxcq-000Joy-00 for namedroppers@ops.ietf.org; Thu, 05 Sep 2002 07:28:52 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id BB05628E16 for ; Thu, 5 Sep 2002 14:28:51 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-dnsext-edns1-04.txt In-Reply-To: Message from Derek Atkins of "05 Sep 2002 09:37:53 -0400." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 05 Sep 2002 14:28:51 +0000 Message-Id: <20020905142851.BB05628E16@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In other words, I agree COMPLETELY that multiple queries were an > intended part of the original archicture, but I also believe that (at > the time) there were too many potential issues (corner cases) so > people didn't want to cope. i don't think they were de-coped at specification time. older versions of bind did not even check QDCOUNT at query time -- they just decoded a single QNAME, QCLASS, and QTYPE and assumed that this left them pointing at the first thing in the answer section. in one of my early sweeps, i chose to put in "if (qdcount != 1) fail" rather than a "for" loop, since the meaning of "(qdcount > 1)" was completely unclear in RFC 1035. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 12:11:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24036 for ; Thu, 5 Sep 2002 12:11:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mz1W-000Nv3-00 for namedroppers-data@psg.com; Thu, 05 Sep 2002 08:58:26 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17mz1O-000Nus-00 for namedroppers@ops.ietf.org; Thu, 05 Sep 2002 08:58:18 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 161193 for namedroppers@ops.ietf.org; Thu, 05 Sep 2002 10:55:48 -0500 Message-ID: <3D777F14.1040307@ehsco.com> Date: Thu, 05 Sep 2002 10:58:12 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: namedroppers Subject: Re: draft-dnsext-edns1-04.txt References: <20020905082009.1D40128E16@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=MISSING_HEADERS version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 9/5/2002 3:20 AM Paul Vixie wrote: > i'll ask eric to find an intermediary Suggesting that I be filtered to avoid your problem with ~too many questions is absurd. A reminder seems in order here, EDNS1 was dead *before* I restarted the discussion on multiple questions (see <3D51AEA8.9020600@ehsco.com>). You can either answer the questions I ask or answer them when they are asked by somebody else or let EDNS1 die again, but if you kill it again or if it is killed again, it certainly won't be my fault. -- 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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 5 12:35:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24760 for ; Thu, 5 Sep 2002 12:35:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mzLo-000Opc-00 for namedroppers-data@psg.com; Thu, 05 Sep 2002 09:19:24 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17mzLl-000OpN-00; Thu, 05 Sep 2002 09:19:21 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19998; Thu, 5 Sep 2002 10:19:18 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g85GJEA28675; Thu, 5 Sep 2002 18:19:14 +0200 (MEST) Date: Thu, 5 Sep 2002 18:16:57 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: IESG comments on draft-ietf-dnsext-restrict-key-for-dnssec-03.txt To: randy@psg.com, ogud@ogud.com Cc: namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document was discussed by the IESG today. Here are the comments: Section 2.1 describes some of the differences between Application Keys and DNSSEC Keys. However, some of the text (e.g., reasons 3 and onward) use upper case MUST/SHOULD language in a confusing way. I suspect the intent is to describe what the existing RFCs require from these Keys, but it would be better to not use that terminology at all here (since Application keys are being deprecated, it seems odd for this document to be saying what one SHOULD do when processing them) and just describe what the differences are in a more reader-friendly way. For example: 3. DNSSEC zone keys are used to authenticate application keys, but application keys MUST NOT be used to authenticate DNS zone keys. A DNS zone key is either configured as trusted key or authenticated by constructing a chain of trust in the DNS hierarchy. To participate in the chain of trust, a DNS zone needs to exchange zone key information with its parent zone [2]. Application keys are not configured as trusted keys in the DNS and are never part of any DNS chain of trust. Application key data SHOULD not be exchanged with the parent zone. A resolver considers an application key authenticated if it has a valid signature from the local DNS zone keys, but applications could impose additional requirements before the application key is accepted as authentic. might be better as: 3. DNSSEC zone keys are used to authenticate application keys, but by definition application keys are not allowed to authenticate DNS zone keys. A DNS zone key is either configured as a trusted key or authenticated by constructing a chain of trust in the DNS hierarchy. To participate in the chain of trust, a DNS zone needs to exchange zone key information with its parent zone [2]. In contrast, Application keys are not configured as trusted keys in the DNS and are never part of any DNS chain of trust. Application key data is not generally exchanged with the parent zone. A resolver considers an Application key authenticated if it has a valid signature from the local DNS zone keys. However, applications will likely impose additional requirements (outside the scope of DNSSEC checks) before accepting the application key as authentic. Sections 4-6 would benefit from similar changes. Nits: The document sometimes capitalizes "Application key" and sometimes doesn't. Be consistent? (And shouldn't it then be "Application Key".) uses "isi.edu" rather than "example.com". I don't have a big problem with this, but should they switch? > with a response that contain the www.isi.edu A record and SIG record. s/contain/contains/ > the SIG and authenticate the www.isi.edu A record. It is typical not s/typical/typically/ record. Note that by placing application keys in the KEY record, a resolver will need the IPSEC, email, TLS, and other key associated with isi.edu if the resolver intends to authenticate the isi.edu zone key (since signatures only apply to the entire KEY RR set). s/will/would/? I.e., this document is deprecated application keys, so this should not be "will" it seems. 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. archive: From owner-namedroppers@ops.ietf.org Sat Sep 7 04:21:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09725 for ; Sat, 7 Sep 2002 04:21:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17naZo-000JsY-00 for namedroppers-data@psg.com; Sat, 07 Sep 2002 01:04:20 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17naZi-000JsJ-00 for namedroppers@ops.ietf.org; Sat, 07 Sep 2002 01:04:14 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g86N1IBc012187; Fri, 6 Sep 2002 23:01:18 GMT Received: from [193.0.9.238] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id EAA21631; Sat, 7 Sep 2002 04:04:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: Date: Fri, 6 Sep 2002 07:40:33 -0400 To: David Blacka , Roy Arends From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,DATE_IN_PAST_06_12 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:39 PM -0400 9/3/02, David Blacka wrote: >I do not understand the harm in also caching the NXTs as individual >records. This is probably because I do not fully understand the >corner case you and Rob Austein investigated. (Reading this a few days late, so this may have been answered already...) The danger comes from NXT's whose reported owner name is the result of a wildcard match. Let's say I ask for data whose QNAME that does not exist but matches a wildcard. Further, the QTYPE is absent at the wildcard. So there will be a returned NXT that looks like it belongs to the QNAME (but the SIG label count will contain info that says it is a wildcard). Holding this NXT isn't dangerous, and it is fine to replay it (from the cache) for a repeat of the same query (QNAME, QTYPE, and QCLASS). The "danger" is in the cache's trying to use the NXT to respond to any other query - QTYPE'. Because the NXT is synthetic, it might be used incorrectly to declare QTYPE' does not exist (or that a QTYPE at it is absent). So the danger is not caching the record, the danger is in incorrectly using the cached, synthetic NXT. I can't think of any damage in answering with the cached, synthetic NXT if the QNAME is the same as the original and the QTYPE=IN. (And QCLASS is appropriately set - off hand I don't know what is "appropriate.") -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 9 08:19:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29215 for ; Mon, 9 Sep 2002 08:19:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oNDk-000LbP-00 for namedroppers-data@psg.com; Mon, 09 Sep 2002 05:00:48 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17oNDg-000LbE-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 05:00:44 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28781; Mon, 9 Sep 2002 07:59:04 -0400 (EDT) Message-Id: <200209091159.HAA28781@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-roadmap-06.txt Date: Mon, 09 Sep 2002 07:59:03 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Document Roadmap Author(s) : S. Rose Filename : draft-ietf-dnsext-dnssec-roadmap-06.txt Pages : 15 Date : 2002-9-6 DNS Security (DNSSEC)technology is composed of extensions to the Domain Name System (DNS) protocol that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Several documents exist to describe these extensions and the implementation-specific details regarding specific digital signing schemes. The interrelationship between these different documents is discussed here. A brief overview of what to find in which document and author guidelines for what to include in new DNS Security documents, or revisions to existing documents, is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-dnsext-dnssec-roadmap-06.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-ietf-dnsext-dnssec-roadmap-06.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-6143001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-roadmap-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-roadmap-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-6143001.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 9 09:48:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01658 for ; Mon, 9 Sep 2002 09:48:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oOkD-000P47-00 for namedroppers-data@psg.com; Mon, 09 Sep 2002 06:38:25 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17oOk9-000P3s-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 06:38:21 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29519; Mon, 9 Sep 2002 06:38:16 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g89DcCA06258; Mon, 9 Sep 2002 15:38:12 +0200 (MEST) Date: Mon, 9 Sep 2002 15:35:54 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNSEXT WGLC: Unknown types support To: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.1.6.2.20020815093727.00bb2f60@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The document uses rather inexact language about "case sensitive" and "lower case" - it would be quite helpful to point out that the DNS servers notion of "case" is limited to octets that are in the ASCII range. Otherwise folks will continue to discuss what case sensitive means for octet values >128. I don't know whether this belongs or not, but it would seem useful to somewhere specify the behavior of unknown classes. Would that make sense in this document? Or in a separate "unknown-classes" document? The reason I think this would be useful is because there are people that are contemplating introducing a new class to the DNS, and I don't know if we currently know how things behave and how we'd like things to behave when they see an unknown class. 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 9 09:54:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01951 for ; Mon, 9 Sep 2002 09:54:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oOvS-000PXD-00 for namedroppers-data@psg.com; Mon, 09 Sep 2002 06:50:02 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17oOvN-000PWs-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 06:49:57 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13707; Mon, 9 Sep 2002 07:49:54 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g89DnrA08031; Mon, 9 Sep 2002 15:49:53 +0200 (MEST) Date: Mon, 9 Sep 2002 15:47:35 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNSEXT WGLC: Unknown types support To: Rob Austein Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <20020823064820.3F8431945@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 2) DNS (from RFC 883 through the present day) is case-insensitive but > case-preserving for the range of octet values that correspond to > the US-ASCII alphabet. Basicly, this means that DNS preserves case > in DNS labels when it's convenient for an implementation to do so, > but you can't assume that case has been preserved in any particular > DNS name (except, maybe, for the leftmost label of a DNS name). > > 3) I would redirect any follow-up on point (2) to the IDN WG, except > that (a) anything that anyone could possibly say on this subject > has almost certainly already been said there, and (b) James and > Marc would hurt me. :) Indepedent of the IDN I think the DNS protocol specifications must be clear on how octets above 128 are processed, since all values are legal in the domain names as carried in the DNS protocol. Saying "case insensitive" is IMHO not sufficiently well defined. Saying that the octet values in the US-ASCII range are compared case insenstively but other octet values (128-255) are compared exactly would be a more clear specification. Similarly for "lower case". 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 9 11:37:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07618 for ; Mon, 9 Sep 2002 11:37:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oQSj-0003Xg-00 for namedroppers-data@psg.com; Mon, 09 Sep 2002 08:28:29 -0700 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 17oQSg-0003XU-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 08:28:26 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id g89FSlZN037673; Mon, 9 Sep 2002 11:28:47 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200209091528.g89FSlZN037673@nic-naa.net> To: Erik Nordmark cc: Rob Austein , namedroppers@ops.ietf.org, brunner@nic-naa.net Subject: Re: DNSEXT WGLC: Unknown types support In-Reply-To: Your message of "Mon, 09 Sep 2002 15:47:35 +0200." Date: Mon, 09 Sep 2002 11:28:47 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Saying that the octet values in the US-ASCII range are compared > case insenstively but other octet values (128-255) are compared > exactly would be a more clear specification. i agree. there is no necessity to specify that character processing is performed for octet values (128-255). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 9 12:53:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09991 for ; Mon, 9 Sep 2002 12:53:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oRau-0006ii-00 for namedroppers-data@psg.com; Mon, 09 Sep 2002 09:41:00 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17oRar-0006hn-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 09:40:57 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 885FE18F8 for ; Mon, 9 Sep 2002 12:40:25 -0400 (EDT) Date: Mon, 09 Sep 2002 12:40:25 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support In-Reply-To: References: <20020823064820.3F8431945@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020909164025.885FE18F8@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 9 Sep 2002 15:47:35 +0200 (CEST), Erik Nordmark wrote: > > Indepedent of the IDN I think the DNS protocol specifications must be > clear on how octets above 128 are processed, since all values are legal > in the domain names as carried in the DNS protocol. > > Saying "case insensitive" is IMHO not sufficiently well defined. > Saying that the octet values in the US-ASCII range are compared > case insenstively but other octet values (128-255) are compared > exactly would be a more clear specification. > Similarly for "lower case". Yet another of those things that (a) seemed "obvious" back when we all knew that one of the most heavily used server platforms on the Internet represented text as 7-bit bytes and (b) somehow never got written down in all the years since that platform went away. Yes, we probably need another short clarifying document, or another section to some omnibus clarifying document, or something. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 9 17:05:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16613 for ; Mon, 9 Sep 2002 17:05:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oVQX-000HPI-00 for namedroppers-data@psg.com; Mon, 09 Sep 2002 13:46:33 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17oVQP-000HP2-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 13:46:25 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03602; Mon, 9 Sep 2002 13:46:23 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g89KkHA23594; Mon, 9 Sep 2002 22:46:19 +0200 (MEST) Date: Mon, 9 Sep 2002 22:43:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNSEXT WGLC: Unknown types support To: Andreas Gustafsson Cc: Erik Nordmark , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200209091758.g89HwwZ05609@guam.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The language of the unknown-rrs draft is no more inexact than that of > STD0013, or of other RFCs that reference the case insensitivity, e.g., > RFC2535. You have a valid criticism of STD0013, but turning that into > a criticism of the unknown-rrs draft is inappropriate and unfair. Don't worry - from now on I'll be perfectly fair on this point. (And I've noted but not yet told folks that the same issue appears in at least one of draft-ietf-dnsext-dnssec-*). Since this is the first document with this language that is likely to come to IESG since we started the IDN discussions I think it makes sense to do it right. Of course, others are welcome to help draft the appropriate text to use for "case insensitive" and "lower case" - it would be good to use the same wording in the future specifications. > There are several other aspects of DNS classes that are poorly > specified or insufficiently explained in STD0013 and that would be of > interest to those contemplating the introduction new classes, but > those are unrelated to the questions of known versus unknown RDATA > formats that this draft is trying to address, and they apply equally > to known and unknown classes. Those would best be addressed in a > separate draft (named "classes", not "unknown-classes"). So the document at hand is about "uknown RDATA formats" independently of where they appear? Perhaps this should be made explicit somewhere (title/abstract/intro somewhere?) 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 9 20:11:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19993 for ; Mon, 9 Sep 2002 20:11:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oYSR-0000wF-00 for namedroppers-data@psg.com; Mon, 09 Sep 2002 17:00:43 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17oYSO-0000vn-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 17:00:40 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g89NsYv10880; Mon, 9 Sep 2002 18:54:35 -0500 (CDT) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g84LBIU8002378; Wed, 4 Sep 2002 17:11:18 -0400 (EDT) Date: Wed, 4 Sep 2002 17:11:18 -0400 Subject: Re: DNSSEXT Yokohama Minutes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Paul Vixie , namedroppers To: bert hubert From: Ted Lemon In-Reply-To: <20020904203549.GA1626@outpost.ds9a.nl> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) X-Spam-Status: No, hits=-2.5 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_96_XX version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > the case for dnssec is thin enough as it is and right now can't > withstand > even the slightest restriction of functionality. Sorry, this is FUD. You have made a completely unsupported statement that bears no relationship of which I am aware to anything that is actually happening in the world. The case for DNSSEC is thick as a brick. What is missing is a practical path to deployment for early adopters. This is, as far as I've been able to tell from watching this process for some time now, because the cost of providing support to early adopters is the same as the cost of providing support once everybody's adopted it, and this represents what is seen to be an unsurmountable barrier to adoption. This has absolutely nothing to do with functionality, or restrictions thereof. If we can lower the barrier for early adopters by getting rid of wildcards in secured zones, we should do it. If you think that this statement is incorrect, you should make a logical argument, based on verifiable facts, that refutes it. You should not engage in FUD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 10 02:18:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05500 for ; Tue, 10 Sep 2002 02:18:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17odzp-000Jr3-00 for namedroppers-data@psg.com; Mon, 09 Sep 2002 22:55:33 -0700 Received: from [193.0.9.125] (helo=roam) by psg.com with esmtp (Exim 3.36 #1) id 17odzl-000Jqr-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 22:55:30 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17odzk-000A8g-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 22:55:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200209091758.g89HwwZ05609@guam.araneus.fi> In-Reply-To: References: <5.1.1.6.2.20020815093727.00bb2f60@localhost> Date: Mon, 9 Sep 2002 10:58:58 -0700 (PDT) To: Erik Nordmark Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Erik Nordmark writes: > The document uses rather inexact language about "case sensitive" and "lower > case" - it would be quite helpful to point out that the DNS servers notion > of "case" is limited to octets that are in the ASCII range. > Otherwise folks will continue to discuss what case sensitive means > for octet values >128. The language of the unknown-rrs draft is no more inexact than that of STD0013, or of other RFCs that reference the case insensitivity, e.g., RFC2535. You have a valid criticism of STD0013, but turning that into a criticism of the unknown-rrs draft is inappropriate and unfair. > I don't know whether this belongs or not, but it would seem > useful to somewhere specify the behavior of unknown classes. > Would that make sense in this document? Or in a separate "unknown-classes" > document? > > The reason I think this would be useful is because there are people that > are contemplating introducing a new class to the DNS, and I don't know > if we currently know how things behave and how we'd like things to behave > when they see an unknown class. The draft already defines the behavior of unknown classes with respect to the draft's subject matter of known versus unknown RDATA formats: In the case of a type whose RDATA format is class specific, an RR is considered to be of unknown type when the RDATA format for that combination of type and class is not known. There are several other aspects of DNS classes that are poorly specified or insufficiently explained in STD0013 and that would be of interest to those contemplating the introduction new classes, but those are unrelated to the questions of known versus unknown RDATA formats that this draft is trying to address, and they apply equally to known and unknown classes. Those would best be addressed in a separate draft (named "classes", not "unknown-classes"). -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 10 02:36:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05791 for ; Tue, 10 Sep 2002 02:36:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oeSe-000Lfn-00 for namedroppers-data@psg.com; Mon, 09 Sep 2002 23:25:20 -0700 Received: from [193.0.9.125] (helo=roam) by psg.com with esmtp (Exim 3.36 #1) id 17oeSb-000Lfa-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 23:25:17 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17oeSZ-000ACD-00 for namedroppers@ops.ietf.org; Mon, 09 Sep 2002 23:25:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200209092117.g89LHYN05706@guam.araneus.fi> In-Reply-To: References: <200209091758.g89HwwZ05609@guam.araneus.fi> Date: Mon, 9 Sep 2002 14:17:34 -0700 (PDT) To: Erik Nordmark Cc: Andreas Gustafsson , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Erik Nordmark writes: > > The language of the unknown-rrs draft is no more inexact than that of > > STD0013, or of other RFCs that reference the case insensitivity, e.g., > > RFC2535. You have a valid criticism of STD0013, but turning that into > > a criticism of the unknown-rrs draft is inappropriate and unfair. > > Don't worry - from now on I'll be perfectly fair on this point. > (And I've noted but not yet told folks that the same issue > appears in at least one of draft-ietf-dnsext-dnssec-*). As Rob Austein said, this belongs in a separate draft of clarifications to STD0013. We shouldn't have to duplicate the clarifictions in every draft that happens to mention case insensitivity. > > There are several other aspects of DNS classes that are poorly > > specified or insufficiently explained in STD0013 and that would be of > > interest to those contemplating the introduction new classes, but > > those are unrelated to the questions of known versus unknown RDATA > > formats that this draft is trying to address, and they apply equally > > to known and unknown classes. Those would best be addressed in a > > separate draft (named "classes", not "unknown-classes"). > > So the document at hand is about "uknown RDATA formats" independently > of where they appear? I'm not sure I understand your question - would you care to elaborate? -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 10 04:10:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06975 for ; Tue, 10 Sep 2002 04:10:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ofyV-0000n0-00 for namedroppers-data@psg.com; Tue, 10 Sep 2002 01:02:19 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17ofyB-0000jz-00 for namedroppers@ops.ietf.org; Tue, 10 Sep 2002 01:02:00 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8A80vg27677; Tue, 10 Sep 2002 15:00:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8A80F805921; Tue, 10 Sep 2002 15:00:23 +0700 (ICT) From: Robert Elz To: gson@nominum.com (Andreas Gustafsson) cc: Erik Nordmark , Andreas Gustafsson , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support In-Reply-To: <200209092117.g89LHYN05706@guam.araneus.fi> References: <200209092117.g89LHYN05706@guam.araneus.fi> <200209091758.g89HwwZ05609@guam.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Sep 2002 15:00:15 +0700 Message-ID: <5919.1031644815@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 9 Sep 2002 14:17:34 -0700 (PDT) From: gson@nominum.com (Andreas Gustafsson) Message-ID: <200209092117.g89LHYN05706@guam.araneus.fi> | As Rob Austein said, this belongs in a separate draft of | clarifications to STD0013. We shouldn't have to duplicate the | clarifictions in every draft that happens to mention case | insensitivity. No, we shouldn't. But nor should we be writing language that is known now to be incomplete, or ambiguous. New drafts don't need to "fix" 1034/5 (except one written just for the purpose), but it should be possible to read them, and make sense of them, without the clarifications doc needing to also update this new one. If a new draft wants to just say "according to the DNS rules for character comparisons", that's fine I think - the doc isn't attempting to specify the rules. But if it says "lower case compare equal to upper case" or "ignore case" then a clarifications doc would have to fix this one, as well as the older ones, and since we know now that it needs fixing, that's plain dumb. Make this doc be correct as it stands (as best we know what correct is anyway). Or, if you like, pretend that there is a clarifications doc already existing which has already fixed this problem for the older docs - and write this one so that it makes sense in that environment (which would be one where just saying "ignore case when comparing labels" is simply inadequate). 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 10 04:26:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07248 for ; Tue, 10 Sep 2002 04:26:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ogFh-0001c1-00 for namedroppers-data@psg.com; Tue, 10 Sep 2002 01:20:05 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17ogFZ-0001bL-00 for namedroppers@ops.ietf.org; Tue, 10 Sep 2002 01:19:57 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17638; Tue, 10 Sep 2002 02:19:54 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8A8JrA14465; Tue, 10 Sep 2002 10:19:53 +0200 (MEST) Date: Tue, 10 Sep 2002 10:17:34 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNSEXT WGLC: Unknown types support To: Andreas Gustafsson Cc: Erik Nordmark , Andreas Gustafsson , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200209092117.g89LHYN05706@guam.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > As Rob Austein said, this belongs in a separate draft of > clarifications to STD0013. We shouldn't have to duplicate the > clarifictions in every draft that happens to mention case > insensitivity. If folks agree then I guess the co-chairs need to make sure that draft gets written so that it is available when unknown-rrs or the new DNSSEC documents (whichever comes first) are ready to be approved by the IESG. > > > There are several other aspects of DNS classes that are poorly > > > specified or insufficiently explained in STD0013 and that would be of > > > interest to those contemplating the introduction new classes, but > > > those are unrelated to the questions of known versus unknown RDATA > > > formats that this draft is trying to address, and they apply equally > > > to known and unknown classes. Those would best be addressed in a > > > separate draft (named "classes", not "unknown-classes"). > > > > So the document at hand is about "uknown RDATA formats" independently > > of where they appear? > > I'm not sure I understand your question - would you care to elaborate? You seem to say that unknown-rrs is about the cases where the RDATA format is unknown. Thus the fact that the RR type code is unknown is not the central part of the draft; both unknown RRs and unknown classes can result in an unknown RDATA format. If that's true, then perhaps this should be more clear in introductory material in the document and not just be mentioned in passing down in the document. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 10 14:18:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22348 for ; Tue, 10 Sep 2002 14:18:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17opIC-0005CM-00 for namedroppers-data@psg.com; Tue, 10 Sep 2002 10:59:16 -0700 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 17opI8-0005CB-00 for namedroppers@ops.ietf.org; Tue, 10 Sep 2002 10:59:12 -0700 Received: from guam.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id g8AHx8C03334; Tue, 10 Sep 2002 10:59:08 -0700 (PDT) Received: (from gson@localhost) by guam.araneus.fi (8.11.6/8.11.6) id g8AHwxM06855; Tue, 10 Sep 2002 10:58:59 -0700 (PDT) Date: Tue, 10 Sep 2002 10:58:59 -0700 (PDT) Message-Id: <200209101758.g8AHwxM06855@guam.araneus.fi> To: Erik Nordmark Cc: Andreas Gustafsson , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support In-Reply-To: References: <200209092117.g89LHYN05706@guam.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > > As Rob Austein said, this belongs in a separate draft of > > clarifications to STD0013. We shouldn't have to duplicate the > > clarifictions in every draft that happens to mention case > > insensitivity. > > If folks agree then I guess the co-chairs need to make sure that draft gets > written so that it is available when unknown-rrs or the new DNSSEC documents > (whichever comes first) are ready to be approved by the IESG. I would like to avoid delaying the unknown-rrs draft and the new DNSSEC documents by introducing a dependency on a new draft. Adding the text "according to the DNS rules for character comparisons" as Robert Elz suggested and publishing the case insensitivity clarifications separately should be sufficient. > You seem to say that unknown-rrs is about the cases where the RDATA format > is unknown. Thus the fact that the RR type code is unknown is not > the central part of the draft; both unknown RRs and unknown classes can result > in an unknown RDATA format. There may be some confusion regarding the definition of an "RR type" (as opposed to a "type code"). For example, consider "IN A" and "CH A": are they two distinct RR types, or one RR type with two class specific RDATA formats? The draft uses the former definition, which is consistent with existing RFCs that define class specific RR types - for example, RFC2874 claims to define the A6 RR type which specific to the IN class, not to define the class IN RDATA format for the A6 type. -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 10 16:35:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26073 for ; Tue, 10 Sep 2002 16:35:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17orTr-000CTy-00 for namedroppers-data@psg.com; Tue, 10 Sep 2002 13:19:27 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17orTo-000CTn-00 for namedroppers@ops.ietf.org; Tue, 10 Sep 2002 13:19:24 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g8AKFC913627 for ; Tue, 10 Sep 2002 16:15:14 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Tue, 10 Sep 2002 16:15:12 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: How does a sever for child answer a DS query. Message-ID: <20020910161306.R13618-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The following is based on some observations at the DS workshop at ISI/East. The issue is: what should DS aware authorative servers return/do in different cases, currently the draft under-specifies what the responses in certain cases. The under-specification affects servers that are authorative for the child and the query is for DS record at apex. Here are the different cases that need to be considered by the DS document, server is: 1. Authorative: for both parent and child Recursion: RD bit: Answer: if DS exists in parent it is returned with AA bit set. if no DS in parent Rcode= NOERROR Answer section: Authority section: SOA NXT if AD bit is set in query 2. Authorative: child only Recursion: Not allowed RD bit: Answer: 3. Authorative: child only Recursion: Allowed RD bit: not set Answer: 4. Authorative: child only Recursion: Allowed RD bit: SET Answer: if answer in cache return it without AA bit else perform recursion At least one of the authorative servers used at the workshop returned a referral to a zone above the QNAME. This caused some common resolvers to mark the server as LAME. If all the servers for the zone have this behavior the zone can be made to disappear. DS is the first real record that can only exist at the parent thus this issue has never been explored. In the early years of DS deployment non DS aware resolvers/caches will blindly send DS queries to the child servers, thus is it important that the answer returned have no negative implications for future queries for records from the child zone. At the DS workshop we performed a test of number of possibilities and tested them against number a available DNS cache programs: Bind-4.9.9 Bind-8.3.3 Bind-9.2.2rc2 Bind-9.3-.. The DS capable server was a specialized server hacked up in about 1 hour by Brian Wellington using DNSjava, that returned different answers depending on the right most label in the query name. Test procedure: start root server start authorative servers start caches for each cache for each test for each setup dig @cache . ns dig @cache . ds dig @cache findme.. txt end end end If findme.. was not found then that return code/value from the DS server will have bad effect during DS transition. The caches below appear in random order, but vendors know which one of the column is their implementation. ds.notauth OK OK OK OK OK SERVFAIL OK mixed.notauth OK OK OK OK OK OK OK not.notauth OK OK OK OK OK OK OK ds.referdown OK OK OK SERVFAIL OK SERVFAIL OK mixed.referdown OK OK OK OK OK OK OK not.referdown OK OK OK OK OK OK OK ds.noanswer OK OK OK OK OK OK OK mixed.noanswer OK OK OK OK OK OK OK not.noanswer OK OK OK OK OK OK OK ds.refused OK OK OK OK OK SERVFAIL OK mixed.refused OK OK OK OK OK OK OK not.refused OK OK OK OK OK OK OK ds.nodata OK OK OK OK OK OK OK mixed.nodata OK OK OK OK OK OK OK not.nodata OK OK OK OK OK OK OK 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 11 01:56:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05581 for ; Wed, 11 Sep 2002 01:55:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p0AX-000IYT-00 for namedroppers-data@psg.com; Tue, 10 Sep 2002 22:36:05 -0700 Received: from roam.psg.c ([193.0.9.125] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17p0AT-000IWx-00 for namedroppers@ops.ietf.org; Tue, 10 Sep 2002 22:36:01 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17p0AQ-000Ao6-00 for namedroppers@ops.ietf.org; Tue, 10 Sep 2002 22:35:58 -0700 Message-ID: <3D7E915C.2000601@motorola.com> MIME-Version: 1.0 References: <200208281155.HAA24447@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 11 Sep 2002 10:42:04 +1000 From: Aidan Williams To: namedroppers@ops.ietf.org, levone@microsoft.com, bernarda@microsoft.com, dthaler@microsoft.com Subject: clarification re mdns/llmnr X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On the zeroconf mailing list i recently wrote this: > Before leaping into the next set of comments I should summarise what > I believe the state of play is with zeroconf naming. I have been > following the discussion in dnsext, and my understanding was that > there was general agreement on the following points: > > - mDNS/LLMNR was *not* DNS, > rather it was a seperate protocol, seperate port, > seperate cache, etc > > - there was agreement that mDNS/LLMNR should not be used > as a substitute for DNS -- ie should not be used for > looking up "one true DNS names" > > - that mDNS/LLMNR should not be used to transport DNS requests > to a "back end resolver" > > In my opinion, these comments also apply to the IPv6 Node > Information Query proposal as well. > > > Right now, the -12 LLMNR document has examples with FQDNs in them. > Unless there have been conversations that I am unaware of, I > believe it was the intent of the working group *not* to support > the resolution of names such as mylaptop.microsoft.com using LLMNR. > Can someone clarify what is believed to be the current consensus on this stuff? - aidan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 11 05:18:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02183 for ; Wed, 11 Sep 2002 05:18:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p3Uy-00052C-00 for namedroppers-data@psg.com; Wed, 11 Sep 2002 02:09:24 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17p3Us-00051m-00 for namedroppers@ops.ietf.org; Wed, 11 Sep 2002 02:09:18 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16253; Wed, 11 Sep 2002 02:09:17 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8B99GA09605; Wed, 11 Sep 2002 11:09:16 +0200 (MEST) Date: Wed, 11 Sep 2002 11:06:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DNSEXT WGLC: Unknown types support To: Andreas Gustafsson Cc: Erik Nordmark , Andreas Gustafsson , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200209101758.g8AHwxM06855@guam.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I would like to avoid delaying the unknown-rrs draft and the new > DNSSEC documents by introducing a dependency on a new draft. Adding > the text "according to the DNS rules for character comparisons" as > Robert Elz suggested and publishing the case insensitivity > clarifications separately should be sufficient. OK. Let's try that. > There may be some confusion regarding the definition of an "RR type" > (as opposed to a "type code"). For example, consider "IN A" and > "CH A": are they two distinct RR types, or one RR type with two class > specific RDATA formats? > > The draft uses the former definition, which is consistent with > existing RFCs that define class specific RR types - for example, > RFC2874 claims to define the A6 RR type which specific to the IN > class, not to define the class IN RDATA format for the A6 type. Got it. Thanks, 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 11 14:03:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19416 for ; Wed, 11 Sep 2002 14:03:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pBYX-000AEw-00 for namedroppers-data@psg.com; Wed, 11 Sep 2002 10:45:37 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17pBYU-000A9l-00 for namedroppers@ops.ietf.org; Wed, 11 Sep 2002 10:45:34 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0450A198A; Wed, 11 Sep 2002 13:44:59 -0400 (EDT) Date: Wed, 11 Sep 2002 13:44:59 -0400 From: Rob Austein To: Aidan Williams Cc: namedroppers@ops.ietf.org, levone@microsoft.com, bernarda@microsoft.com, dthaler@microsoft.com Subject: Re: clarification re mdns/llmnr In-Reply-To: <3D7E915C.2000601@motorola.com> References: <200208281155.HAA24447@ietf.org> <3D7E915C.2000601@motorola.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020911174500.0450A198A@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 11 Sep 2002 10:42:04 +1000, Aidan Williams wrote: > > On the zeroconf mailing list i recently wrote this: > > > Before leaping into the next set of comments I should summarise what > > I believe the state of play is with zeroconf naming. I have been > > following the discussion in dnsext, and my understanding was that > > there was general agreement on the following points: > > > > - mDNS/LLMNR was *not* DNS, > > rather it was a seperate protocol, seperate port, > > seperate cache, etc > > > > - there was agreement that mDNS/LLMNR should not be used > > as a substitute for DNS -- ie should not be used for > > looking up "one true DNS names" > > > > - that mDNS/LLMNR should not be used to transport DNS requests > > to a "back end resolver" > > > > In my opinion, these comments also apply to the IPv6 Node > > Information Query proposal as well. I think I believe all of the above. > > Right now, the -12 LLMNR document has examples with FQDNs in them. > > Unless there have been conversations that I am unaware of, I > > believe it was the intent of the working group *not* to support > > the resolution of names such as mylaptop.microsoft.com using LLMNR. I don't think I believe this one, although I could of course be wrong. If it's a separate namespace, it's a separate namespace. The fact that a name in one might happen to look like a name in the other is not in itself a reason to forbid it. The real question underlying all of this, however, is how these names are going to be used. In particular, how applications are going to deal with the general problem of having multiple discrete namespaces, most particularly applications that were not designed to support such a thing. Solve that, and the question of whether there's a strong reason to restrict the syntax of LLMNR names will probably be obvious. Once upon a time (back when dinosaurs still roamed the machine rooms in mighty herds) I used a mailsystem on which a fully-specified address in the MUA looked like sra@xx.lcs.mit.edu.#Chaos sra@xx.lcs.mit.edu.#Internet while saying just sra@xx.lcs.mit.edu was an invitation to the MUA to pick whichever naming realm it felt good about today. The mail software of course stripped the .#whatever tag off the end before handing the message off to the MTA, so this was strictly a user interface issue, not a protocol issue. I'm not suggesting reviving that particular user interface or notation, just pointing out that this is not the first time that this problem has arisen, and that there's more than one way to attack this kind of problem. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 08:31:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20993 for ; Thu, 12 Sep 2002 08:31:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pSbh-0005VZ-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 04:58:01 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17pSbd-0005VN-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 04:57:57 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19691; Thu, 12 Sep 2002 07:56:15 -0400 (EDT) Message-Id: <200209121156.HAA19691@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-restrict-key-for-dnssec-04.txt Date: Thu, 12 Sep 2002 07:56:15 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Limiting the Scope of the KEY Resource Record out Author(s) : D. Massey, S. Rose Filename : draft-ietf-dnsext-restrict-key-for-dnssec-04.txt Pages : 15 Date : 2002-9-11 This document limits the Domain Name System KEY resource record to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY resource record used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY Resource Record Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-dnsext-restrict-key-for-dnssec-04.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-ietf-dnsext-restrict-key-for-dnssec-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-11142206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-restrict-key-for-dnssec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-restrict-key-for-dnssec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-11142206.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 08:31:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21007 for ; Thu, 12 Sep 2002 08:31:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pSbc-0005VL-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 04:57:56 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17pSbZ-0005V8-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 04:57:53 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19673; Thu, 12 Sep 2002 07:56:11 -0400 (EDT) Message-Id: <200209121156.HAA19673@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc1886bis-00.txt Date: Thu, 12 Sep 2002 07:56:11 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Extensions to support IP version 6 Author(s) : S. Thomson, C. Huitema Filename : draft-ietf-dnsext-rfc1886bis-00.txt Pages : 7 Date : 2002-9-11 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This document updates RFC 1886 [5]. Changes mainly consist in replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152 [6]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-dnsext-rfc1886bis-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-ietf-dnsext-rfc1886bis-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-11142149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc1886bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc1886bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-11142149.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 10:18:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24263 for ; Thu, 12 Sep 2002 10:18:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pUU1-000DCl-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 06:58:13 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17pUTy-000DCV-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 06:58:10 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8CDwERF061996 for ; Thu, 12 Sep 2002 09:58:14 -0400 (EDT) Received: from [193.0.9.238] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA17452; Thu, 12 Sep 2002 09:58:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 12 Sep 2002 16:58:00 +0300 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: dynamic update zone Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There is one implementation of dynamic update (snapshot of a future BIND) that allows a dynamically updated zone to be frozen - temporary suspension of dynamicity to allow of manual changes to a zone. It's a cool feature... When a zone is frozen, the returned status code is REFUSED, as per section 2.2 of RFC 2136. The implementation is faithful to this, but I wonder if defining a different status code such as "FROZEN" or "NOTDYN" is better. The rationale for this is that might be good to tell the updater that the refusal is temporary as opposed to a violation of policy. There has been talk of using dynamic update in situations where direct communications between the updater and the admin may be difficult (which is why dynamic updates are in use). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 10:56:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25658 for ; Thu, 12 Sep 2002 10:56:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pV7t-000Ftc-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 07:39:25 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17pV7k-000FtM-00; Thu, 12 Sep 2002 07:39:16 -0700 Received: from isi.edu (c1-vpn1.isi.edu [128.9.176.27]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g8CEdEC27572; Thu, 12 Sep 2002 07:39:14 -0700 (PDT) Message-ID: <3D80A70C.C1183106@isi.edu> Date: Thu, 12 Sep 2002 10:39:08 -0400 From: Dan Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: randy@psg.com, ogud@ogud.com, namedroppers@ops.ietf.org Subject: Re: IESG comments on draft-ietf-dnsext-restrict-key-for-dnssec-03.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, All of the changes discussed below were made and the new draft is now available: draft-ietf-dnsext-restrict-key-for-dnssec-04.txt Thanks, Dan Erik Nordmark wrote: > This document was discussed by the IESG today. > Here are the comments: > > Section 2.1 describes some of the differences between Application Keys > and DNSSEC Keys. However, some of the text (e.g., reasons 3 and > onward) use upper case MUST/SHOULD language in a confusing way. I > suspect the intent is to describe what the existing RFCs require from > these Keys, but it would be better to not use that terminology at all > here (since Application keys are being deprecated, it seems odd for > this document to be saying what one SHOULD do when processing them) > and just describe what the differences are in a more reader-friendly > way. For example: MUST/SHOULD terms were removed from this section. > > > Sections 4-6 would benefit from similar changes. > > Nits: > > The document sometimes capitalizes "Application key" and > sometimes doesn't. Be consistent? (And shouldn't it then be > "Application Key".) > fixed using "application key". > > uses "isi.edu" rather than "example.com". I don't have a big problem > with this, but should they switch? > fixed using "example.com". > > > with a response that contain the www.isi.edu A record and SIG record. > s/contain/contains/ > > > the SIG and authenticate the www.isi.edu A record. It is typical not > > s/typical/typically/ > fixed > > record. Note that by placing application keys in the KEY record, a > resolver will need the IPSEC, email, TLS, and other key associated > with isi.edu if the resolver intends to authenticate the isi.edu zone > key (since signatures only apply to the entire KEY RR set). > > s/will/would/? I.e., this document is deprecated application keys, so > this should not be "will" it seems. > fixed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 11:22:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26537 for ; Thu, 12 Sep 2002 11:22:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pVcy-000IIC-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 08:11:32 -0700 Received: from portal.hamachi.org ([140.239.227.17]) by psg.com with esmtp (Exim 3.36 #1) id 17pVcq-000IHc-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 08:11:24 -0700 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 54F0A17926; Thu, 12 Sep 2002 11:10:14 -0400 (EDT) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id g8CFA5J23380; Thu, 12 Sep 2002 11:10:05 -0400 (EDT) Message-Id: <200209121510.g8CFA5J23380@syn.hamachi.org> From: Bill Sommerfeld To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: dynamic update zone In-Reply-To: Message from Edward Lewis of "Thu, 12 Sep 2002 16:58:00 +0300." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Thu, 12 Sep 2002 11:10:04 -0400 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The rationale for this is that might be good to tell the updater that > the refusal is temporary as opposed to a violation of policy. There > has been talk of using dynamic update in situations where direct > communications between the updater and the admin may be difficult > (which is why dynamic updates are in use). Is there any change in desired client retry behavior for REFUSED vs your proposed FROZEN? I'm thinking mostly of the embedded/automatic case here.. - 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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 12:15:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28008 for ; Thu, 12 Sep 2002 12:15:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pWMH-000LbR-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 08:58:21 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17pWM3-000Lb8-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 08:58:07 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8CFvxmT030189; Thu, 12 Sep 2002 17:57:59 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8CFvv3f030185; Thu, 12 Sep 2002 17:57:57 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 12 Sep 2002 17:57:57 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Brian Wellington cc: Olafur Gudmundsson , David Blacka , "Hallam-Baker, Phillip" , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 4 Sep 2002, Brian Wellington wrote: > On Wed, 4 Sep 2002, Roy Arends wrote: > > > On Tue, 3 Sep 2002, Brian Wellington wrote: > > > > > On Wed, 4 Sep 2002, Roy Arends wrote: > > > > > > > > And then there is the issue on memory usage in caches, there was an > > > > > assertation that opt-in zones cause more memory consumption than other > > > > > DNSSEC zones. > > > > > > > > This is true, > > > > > > > > A positive response with Opt-in holds: QTYPE+NXT+SIG(NXT). > > > > > > > > A positive response without Opt-in holds: QTYPE+SIG(QTYPE). > > > > > > The positive response with opt-in also needs to contain proof that there's > > > no secure wildcard, otherwise secure wildcards can be spoofed away. This > > > will mean another SIG and SIG(NXT) in almost every case. > > > > No, you don't need proof for wildcards. > > > > If I was to spoof a resolver, proof of [non-]existence of secure wildcards > > does not prevent or help me do that. > > > > If you asked for something in an unsecured interval, all bets are off. > > > > Remember that this is for delegations only. Are you suggesting proof > > of [absent] signed wildcard delegations ? > > No, I'm suggesting proof of absent wildcards. While opt-in might be > restricted to delegations, that doesn't mean that the zone is. > > For example, consider the foo.com zone, with: > @ SOA > NS > * A > a NS > c NS > e NS > > Without DNSSEC, querying for www.b.foo.com will hit the wildcard A record, > and querying for www.c.foo.com will return a referral. > > Now sign the zone, and have 'a' and 'e' signed, and 'c' unsigned: > > @ SOA > SIG SOA > NS > SIG NS > KEY > SIG KEY > NXT > SIG NXT > * A > SIG A > NXT > SIG NXT > a NS > DS > SIG DS > NXT > SIG NXT > c NS > e NS > DS > SIG DS > NXT > SIG NXT > > (Hope I didn't miss anything there) > > Query for www.c.foo.com. According to your claim, you should just give > out the referral (NS + DS + SIG DS) and the proof that the name is > insecure (a's NXT and SIG NXT). Almost, you should just give out the referral (NS) and the proof that the name is insecure (a's NXT and SIG NXT). > Query for www.b.foo.com, and have a malicious server replay a response > with the same insecurity proof, and a forged unsigned referral. There's > no way to prove it's false, and you've now spoofed away the existence of a > secure name, since www.b.foo.com was secure in the non-optin case. > > Yes, this is bad. The problem is that when a query falls in an unsigned interval (yes, I know, delegations only) there may exist an unsigned delegation for QNAME eventhough there exist a signed wildcard. Whenever a query hits an unsigned interval, it is useless to proof of existing or non-existing wildcards. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 12:33:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28508 for ; Thu, 12 Sep 2002 12:33:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pWcP-000MlW-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 09:15:01 -0700 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #1) id 17pWcK-000MhG-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 09:14:56 -0700 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id g8CG8CY12973 for ; Thu, 12 Sep 2002 12:08:13 -0400 (EDT) Received: from shmrspr1-pf0.shdc.chrysler.com(129.9.145.48) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAANuaGvz; Thu, 12 Sep 02 12:08:12 -0400 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g8CGEdT23364 for ; Thu, 12 Sep 2002 12:14:39 -0400 (EDT) Message-ID: <3D80BD31.48241F11@daimlerchrysler.com> Date: Thu, 12 Sep 2002 12:13:37 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: dynamic update zone References: <200209121510.g8CFA5J23380@syn.hamachi.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > > The rationale for this is that might be good to tell the updater that > > the refusal is temporary as opposed to a violation of policy. There > > has been talk of using dynamic update in situations where direct > > communications between the updater and the admin may be difficult > > (which is why dynamic updates are in use). > > Is there any change in desired client retry behavior for REFUSED vs > your proposed FROZEN? I'm thinking mostly of the embedded/automatic > case here.. As I understand it, REFUSED is a "permanent" error, i.e. the same nameserver instance will continue to return REFUSED for the same request unless it is reconfigured, whereas this new rcode would indicate a temporary error that may succeed on a subsequent request without any reconfiguration of the server. Client implementations should be encouraged to use a sensible retry strategy, of course, in order to avoid hammering the server. I would prefer that such an rcode be general in nature, however, and not limited to the Dynamic Update case. There might be situations where it would be useful to temporarily "freeze" ordinary queries, zone transfers, etc. - 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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 14:55:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03367 for ; Thu, 12 Sep 2002 14:55:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pYjn-0005zC-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 11:30:47 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17pYjh-0005xA-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 11:30:41 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2EEBF18E0 for ; Thu, 12 Sep 2002 14:30:10 -0400 (EDT) Date: Thu, 12 Sep 2002 14:30:10 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: dynamic update zone In-Reply-To: <3D80BD31.48241F11@daimlerchrysler.com> References: <200209121510.g8CFA5J23380@syn.hamachi.org> <3D80BD31.48241F11@daimlerchrysler.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020912183010.2EEBF18E0@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 12 Sep 2002 12:13:37 -0400, Kevin Darcy wrote: > > As I understand it, REFUSED is a "permanent" error, i.e. the same > nameserver instance will continue to return REFUSED for the same request > unless it is reconfigured, whereas this new rcode would indicate a > temporary error that may succeed on a subsequent request without any > reconfiguration of the server. Client implementations should be encouraged > to use a sensible retry strategy, of course, in order to avoid hammering > the server. I think you're reading more into the spec than is there. While I've never heard of anyone bothering to do so, I don't think there's anything in the spec that'd rule out a name server implementation that returned REFUSED if and only if the system load average on the name server's host over the seven minutes immediately prior to receiving the query happened to have been above 0.84315315, or that returned REFUSED on October 31 if and only if the moon was full. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 16:03:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05791 for ; Thu, 12 Sep 2002 16:03:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pZg6-000AA3-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 12:31:02 -0700 Received: from fs3.antd.nist.gov ([129.6.50.151]) by psg.com with esmtp (Exim 3.36 #1) id 17pZg0-000A8E-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 12:30:56 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by fs3.antd.nist.gov (8.11.6/8.11.6) with SMTP id g8CJUsY12255; Thu, 12 Sep 2002 15:30:54 -0400 Message-ID: <00cd01c25a91$e5f917e0$b9370681@BARNACLE> From: "Scott Rose" To: , "Edward Lewis" References: Subject: Re: dynamic update zone Date: Thu, 12 Sep 2002 15:23:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Edward Lewis" > There is one implementation of dynamic update (snapshot of a future > BIND) that allows a dynamically updated zone to be frozen - temporary > suspension of dynamicity to allow of manual changes to a zone. It's > a cool feature... > > When a zone is frozen, the returned status code is REFUSED, as per > section 2.2 of RFC 2136. The implementation is faithful to this, but > I wonder if defining a different status code such as "FROZEN" or > "NOTDYN" is better. > > The rationale for this is that might be good to tell the updater that > the refusal is temporary as opposed to a violation of policy. There > has been talk of using dynamic update in situations where direct > communications between the updater and the admin may be difficult > (which is why dynamic updates are in use). > -- My guess is that updaters would know what the policy is, so when the got a REFUSED back, they know it is frozen, since they should be able to update the zone normally. But I can see the proposed RCODE if the process is automated (DHCP/DNS interaction). But there should be some sort of client retry rule of thumb to prevent server pounding as hundreds of new hosts try to update the IETF reverse DNS server with their name and newly allocated IP address (for example). In this case - is it necessarily bad that the client may never decide to try again and send another update request? Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 12 21:16:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12368 for ; Thu, 12 Sep 2002 21:16:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17peoY-000Gfv-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 18:00:06 -0700 Received: from mx04.gis.net ([208.218.130.12] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17peoT-000GfF-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 18:00:01 -0700 Received: from tecotoo.www.gis.net ([216.41.72.24]) by mx04.gis.net; Thu, 12 Sep 2002 20:59:58 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id sa028436 for ; Thu, 12 Sep 2002 20:33:11 -0400 Message-Id: <4.3.1.2.20020912202741.051e7670@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 12 Sep 2002 20:32:59 -0400 To: Rob Austein , namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: dynamic update zone In-Reply-To: <20020912183010.2EEBF18E0@thrintun.hactrn.net> References: <3D80BD31.48241F11@daimlerchrysler.com> <200209121510.g8CFA5J23380@syn.hamachi.org> <3D80BD31.48241F11@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Rcpt-To: X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 02:30 PM 9/12/02, Rob Austein wrote: >At Thu, 12 Sep 2002 12:13:37 -0400, Kevin Darcy wrote: > > > > As I understand it, REFUSED is a "permanent" error, i.e. the same > > nameserver instance will continue to return REFUSED for the same request > > unless it is reconfigured, whereas this new rcode would indicate a > > temporary error that may succeed on a subsequent request without any > > reconfiguration of the server. Client implementations should be encouraged > > to use a sensible retry strategy, of course, in order to avoid hammering > > the server. > >I think you're reading more into the spec than is there. While I've >never heard of anyone bothering to do so, I don't think there's >anything in the spec that'd rule out a name server implementation that >returned REFUSED if and only if the system load average on the name >server's host over the seven minutes immediately prior to receiving >the query happened to have been above 0.84315315, or that returned >REFUSED on October 31 if and only if the moon was full. I think that's overstating the case. The principle of least surprise should always apply so that the number of possible reasons for the refusal be limited to perfectly reasonable cases. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 13 03:08:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27097 for ; Fri, 13 Sep 2002 03:08:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pkLp-0007Zs-00 for namedroppers-data@psg.com; Thu, 12 Sep 2002 23:54:49 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17pkLl-0007Zh-00 for namedroppers@ops.ietf.org; Thu, 12 Sep 2002 23:54:45 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8D6siRF085362; Fri, 13 Sep 2002 02:54:44 -0400 (EDT) Received: from [193.0.9.238] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id CAA05199; Fri, 13 Sep 2002 02:54:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <00cd01c25a91$e5f917e0$b9370681@BARNACLE> References: <00cd01c25a91$e5f917e0$b9370681@BARNACLE> Date: Fri, 13 Sep 2002 09:40:35 +0300 To: "Scott Rose" , , "Edward Lewis" From: Edward Lewis Subject: Re: dynamic update zone Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 3:23PM -0400 9/12/02, Scott Rose wrote: >My guess is that updaters would know what the policy is, so when the got a >REFUSED back, they know it is frozen, since they should be able to update >the zone normally. I'm not so sure that is true even when the client is human (run). If the client is a regsitrar and the server is being run by a registry, the coupling of updater to admin may be very loose - esp. organization-wise. >example). In this case - is it necessarily bad that the client may never >decide to try again and send another update request? The problem is whether the client has the information to make the decision. E.g., a person may try an update and see a failure. Depending on a lot of factors, the person might be correct to retry in an hour or might be correct to not try that query again. One factor just might be whether the person is told that "your key might be authorized to make this change, but I'm not listening now" or "your key is not authorized to make that change." (Just an example scenario.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 13 08:39:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03209 for ; Fri, 13 Sep 2002 08:39:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ppTV-000HMS-00 for namedroppers-data@psg.com; Fri, 13 Sep 2002 05:23:05 -0700 Received: from fs3.antd.nist.gov ([129.6.50.151]) by psg.com with esmtp (Exim 3.36 #1) id 17ppTR-000HMG-00 for namedroppers@ops.ietf.org; Fri, 13 Sep 2002 05:23:02 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by fs3.antd.nist.gov (8.11.6/8.11.6) with SMTP id g8DCN0Y01448; Fri, 13 Sep 2002 08:23:00 -0400 Message-ID: <007c01c25b1f$4ac2cf30$b9370681@BARNACLE> From: "Scott Rose" To: , "Edward Lewis" References: <00cd01c25a91$e5f917e0$b9370681@BARNACLE> Subject: Re: dynamic update zone Date: Fri, 13 Sep 2002 08:15:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Edward Lewis" > > >example). In this case - is it necessarily bad that the client may never > >decide to try again and send another update request? > > The problem is whether the client has the information to make the > decision. E.g., a person may try an update and see a failure. > Depending on a lot of factors, the person might be correct to retry > in an hour or might be correct to not try that query again. One > factor just might be whether the person is told that "your key might > be authorized to make this change, but I'm not listening now" or > "your key is not authorized to make that change." (Just an example > scenario.) > Okay - that example clears things up for me. My only worry is poorly written implementations that interpret this new "FROZEN" or whatever, response and keep hammering away at the server until they get a more positive response. Of course this can happen already when REFUSED is returned... If I'm thinking correctly about this, the new interpretation of the rcodes would be: refused - means that the server will never accept an update from the sender until some misconfiguration is correct, or policy stuff. frozen(whatever) - means that the sender could normally make the update, but the server has been frozen by an admin for some time period. Try again later and it might suceed. correct? Scott > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 13 10:10:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06270 for ; Fri, 13 Sep 2002 10:10:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pqy1-000KWL-00 for namedroppers-data@psg.com; Fri, 13 Sep 2002 06:58:41 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17pqxy-000KW8-00 for namedroppers@ops.ietf.org; Fri, 13 Sep 2002 06:58:38 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C489B4B23 for ; Fri, 13 Sep 2002 22:58:33 +0900 (JST) To: namedroppers@ops.ietf.org 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 Subject: mDNS/LLMNR and "local.arpa" From: itojun@iijlab.net Date: Fri, 13 Sep 2002 22:58:33 +0900 Message-Id: <20020913135833.C489B4B23@coconut.itojun.org> X-Spam-Status: No, hits=1.6 required=5.0 tests=NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (thread from zeroconf mailing list. see http://www.merit.edu/mail.archives/zeroconf/msg00604.html and emails before that) >if there's no intent to support use of DNS names or DNS-like names, >and the group is willing to NOT overload existing name lookup APIs, >I'd like that to be stated explicitly and up-front. it simplifies >a number of problems, but it also makes zeroconf incompatible with >existing programs - so I have my doubts that this is the intent. then why "local.arpa" was removed from mDNS/LLMNR document? indicators like "local.arpa" or "local" (used by Apple Rendezvous) is a good indication of different name space. 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. archive: From owner-namedroppers@ops.ietf.org Fri Sep 13 14:52:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15618 for ; Fri, 13 Sep 2002 14:52:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pvKR-0003tj-00 for namedroppers-data@psg.com; Fri, 13 Sep 2002 11:38:07 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17pvKN-0003t8-00 for namedroppers@ops.ietf.org; Fri, 13 Sep 2002 11:38:04 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 000211915 for ; Fri, 13 Sep 2002 14:37:31 -0400 (EDT) Date: Fri, 13 Sep 2002 14:37:31 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: dynamic update zone In-Reply-To: <007c01c25b1f$4ac2cf30$b9370681@BARNACLE> References: <00cd01c25a91$e5f917e0$b9370681@BARNACLE> <007c01c25b1f$4ac2cf30$b9370681@BARNACLE> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020913183732.000211915@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I completely agree that we need some RCODE that we agree to interpret as "permanently refused" where "permanently" may or may not mean "forever" but definitely does mean "do not retry!". I have no real problem with concluding that the existing REFUSED RCODE should be interpreted that way, assuming that (a) nobody knows of an existing implementation that this would break and (b) this gets written up. While I see some potential value in some kind of "refused temporarily" RCODE per Ed's scenario, I am leery of heading down that path unless we can provide some guidance on a sane retry strategy. The catch is that it's hard to picture a strategy that would be right for all circumstances, at best one could invent one that might be harmless. There is of course the alternative of adding a new field to the OPT psuedo-RR that would specify a minimum interval after which it would be ok for the client to retry. If we took that approach, REFUSED without that field present would mean "permanently refused", while presence of that field would mean "refused for now, but if you try again in N seconds you wouldn't be pestering me and it might work". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Sep 15 07:48:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03087 for ; Sun, 15 Sep 2002 07:48:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qXcj-000IDq-00 for namedroppers-data@psg.com; Sun, 15 Sep 2002 04:31:33 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17qXce-000ID4-00 for namedroppers@ops.ietf.org; Sun, 15 Sep 2002 04:31:29 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8FBV9t17727; Sun, 15 Sep 2002 18:31:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8F6K0l06147; Sun, 15 Sep 2002 13:20:00 +0700 (ICT) From: Robert Elz To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: dynamic update zone In-Reply-To: <20020913183732.000211915@thrintun.hactrn.net> References: <20020913183732.000211915@thrintun.hactrn.net> <00cd01c25a91$e5f917e0$b9370681@BARNACLE> <007c01c25b1f$4ac2cf30$b9370681@BARNACLE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Sep 2002 13:20:00 +0700 Message-ID: <6145.1032070800@munnari.OZ.AU> X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_03_06 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 13 Sep 2002 14:37:31 -0400 From: Rob Austein Message-ID: <20020913183732.000211915@thrintun.hactrn.net> | There is of course the alternative of adding a new field to the OPT | psuedo-RR that would specify a minimum interval after which it would | be ok for the client to retry. This is an excellent idea - except that we should generalize it. That is, what we want here, is for the client to cache the REFUSED for some period of time, and then try again. This is exactly what we want when we send other errors - even NXDOMAIN, we want the client to cache the value for some time, and then it can try again. Currently, we're using the SOA record, for that purpose, but that's truly sub-optimal, and totally inapplicable for anything other than NXDOMAIN. So, yes, please let's add a "error cache TTL" field, define 0 as "not specified here, do what you would have otherwise done" (for backward compatibility), "-1" (or ~0 if you prefer) as "don't cache this, try again next time you need to know", and any other value as the TTL that the client can use to cache this particular error, before trying again. I don't think we need "permanent" - any long value is going to exceed the client's patience anyway (clients all set upper bounds on any such information in any case, and discard it, no-one believes in permanent errors). For NXDOMAIN, the SOA record will keep being added, as the authority for the denial, and old clients can keep on using it as the source of the cache TTL (with the same kind of sanity upper bound as currently used). But with this, there'd be an explicit TTL on all errors (it should most likely include "no error no data" as well). To allow this to need fewer bits, it could be defined as being in multiple second units. I think a range of up to 1 day is enough, caching errors longer than that is unlikely to be useful (or believed). That's 86400 seconds. Make the field count in 2 second units, and a 16 bit field would be enough for this. (2^16 * 2 = 128K - a day and a half approx). 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. archive: From owner-namedroppers@ops.ietf.org Sun Sep 15 07:49:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03107 for ; Sun, 15 Sep 2002 07:49:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qXcW-000IDG-00 for namedroppers-data@psg.com; Sun, 15 Sep 2002 04:31:20 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17qXcO-000ID3-00 for namedroppers@ops.ietf.org; Sun, 15 Sep 2002 04:31:12 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8FBV3t17724; Sun, 15 Sep 2002 18:31:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8F6MRl06175; Sun, 15 Sep 2002 13:22:27 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: namedroppers@ops.ietf.org Subject: Re: mDNS/LLMNR and "local.arpa" In-Reply-To: <20020913135833.C489B4B23@coconut.itojun.org> References: <20020913135833.C489B4B23@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Sep 2002 13:22:27 +0700 Message-ID: <6173.1032070947@munnari.OZ.AU> X-Spam-Status: No, hits=-2.7 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_03_06 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 13 Sep 2002 22:58:33 +0900 From: itojun@iijlab.net Message-ID: <20020913135833.C489B4B23@coconut.itojun.org> | then why "local.arpa" was removed from mDNS/LLMNR document? indicators | like "local.arpa" or "local" (used by Apple Rendezvous) is a good | indication of different name space. No, mangling the names is a poor way to indicate different name spaces. And that's for much the same reasons that my suggestion to stick the scope id of IPv6 limited scope addresses (LL & SL) inside the address itself (as part of the API) was rejected (and I agree now, rightly so). 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. archive: From owner-namedroppers@ops.ietf.org Sun Sep 15 10:22:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05073 for ; Sun, 15 Sep 2002 10:22:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qaAz-000LXx-00 for namedroppers-data@psg.com; Sun, 15 Sep 2002 07:15:05 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17qaAu-000LX6-00 for namedroppers@ops.ietf.org; Sun, 15 Sep 2002 07:15:01 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 87CC818A0 for ; Sun, 15 Sep 2002 10:14:28 -0400 (EDT) Date: Sun, 15 Sep 2002 10:14:27 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: dynamic update zone In-Reply-To: <6145.1032070800@munnari.OZ.AU> References: <20020913183732.000211915@thrintun.hactrn.net> <00cd01c25a91$e5f917e0$b9370681@BARNACLE> <007c01c25b1f$4ac2cf30$b9370681@BARNACLE> <6145.1032070800@munnari.OZ.AU> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020915141428.87CC818A0@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think we need to distinguish between server errors and data errors. RCODE=3 is a property of the zone, RCODE=5 is a server error. Server errors seem a good match for an OPT psuedo-RR extension, but I don't think an OPT extension is suitable for errors that reflect properties of the zone. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Sep 15 14:35:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08541 for ; Sun, 15 Sep 2002 14:35:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qe3z-00013i-00 for namedroppers-data@psg.com; Sun, 15 Sep 2002 11:24:07 -0700 Received: from ny-ppp023.iij-us.net ([216.98.99.23] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17qe3v-00013W-00 for namedroppers@ops.ietf.org; Sun, 15 Sep 2002 11:24:04 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 4D0067B9; Mon, 16 Sep 2002 03:23:57 +0900 (JST) To: Robert Elz Cc: namedroppers@ops.ietf.org In-reply-to: kre's message of Sun, 15 Sep 2002 13:22:27 +0700. <6173.1032070947@munnari.OZ.AU> 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 Subject: Re: mDNS/LLMNR and "local.arpa" From: Jun-ichiro itojun Hagino Date: Mon, 16 Sep 2002 03:23:57 +0900 Message-Id: <20020915182357.4D0067B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > | then why "local.arpa" was removed from mDNS/LLMNR document? indicators > | like "local.arpa" or "local" (used by Apple Rendezvous) is a good > | indication of different name space. >No, mangling the names is a poor way to indicate different name spaces. then how can we differentiate mDNS/LLMNR name and DNS name under the same API (getaddrinfo/getnameinfo)? 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. archive: From owner-namedroppers@ops.ietf.org Sun Sep 15 15:10:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09411 for ; Sun, 15 Sep 2002 15:10:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qegs-0002AA-00 for namedroppers-data@psg.com; Sun, 15 Sep 2002 12:04:18 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17qegp-00029s-00 for namedroppers@ops.ietf.org; Sun, 15 Sep 2002 12:04:15 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 162322; Sun, 15 Sep 2002 14:01:50 -0500 Message-ID: <3D84D9AB.9050103@ehsco.com> Date: Sun, 15 Sep 2002 14:04:11 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Robert Elz CC: Rob Austein , namedroppers@ops.ietf.org Subject: Re: dynamic update zone References: <20020913183732.000211915@thrintun.hactrn.net> <00cd01c25a91$e5f917e0$b9370681@BARNACLE> <007c01c25b1f$4ac2cf30$b9370681@BARNACLE> <6145.1032070800@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 9/15/2002 1:20 AM Robert Elz wrote: > So, yes, please let's add a "error cache TTL" field, define 0 as "not > specified here, do what you would have otherwise done" (for backward > compatibility), "-1" (or ~0 if you prefer) as "don't cache this, try again > next time you need to know", and any other value as the TTL that the client > can use to cache this particular error, before trying again. Yeah this would be useful supplemental information. A few comments. One other benefit to the use of such a field is that it makes per-server tracking more feasible. The requester will know that the server supports the reporting feature but not the requested extension (or the operation), which is more granular information than can be obtained without the field. However, it would still be inadequate for corner cases. Each extension would still have to define their own fallback processing and recovery mechanisms, and (more importantly) the specific errors which trigger the different fallback strategies necessary for the extension at hand. This means some kind of default error-cache document would still need to be provided which defined default conditions and which delegated the interpretation and recovery actions to each extension. Also, not all extensions and errors will be related to EDNS extensions (DDNS errors, for example). Also, the presence of this information may have the potential to trigger subsequent errors during requester processing. For these reasons, the generalized caching document would need to treat any EDNS-specific error-TTL field as supplemental, not as core. Also, there are some obscure errors which can show up in weird situations which would not be served by this field. Some servers silently discard errors rather than reporting them, for example. While this can be argued as correct or incorrect forever, it is an example of an error which may need to be trapped and cached by some extension, but with no information being made available to the requester. For all of these reasons, it would be useful as supplemental information but it would not BY ITSELF be sufficient. As to Robert's suggested values above, I would think that omitting the field would be sufficient for "use the default interpretation" while 0 would be appropriate for "don't cache this error" This is especially true since there are several potential scenarios where the data will be ommitted anyway (included unextended servers, obviously). -- 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. archive: From owner-namedroppers@ops.ietf.org Sun Sep 15 15:22:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09558 for ; Sun, 15 Sep 2002 15:22:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qevV-0002bI-00 for namedroppers-data@psg.com; Sun, 15 Sep 2002 12:19:25 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17qevR-0002at-00 for namedroppers@ops.ietf.org; Sun, 15 Sep 2002 12:19:21 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 162325; Sun, 15 Sep 2002 14:16:55 -0500 Message-ID: <3D84DD34.2050907@ehsco.com> Date: Sun, 15 Sep 2002 14:19:16 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Robert Elz , namedroppers@ops.ietf.org Subject: Re: mDNS/LLMNR and "local.arpa" References: <20020915182357.4D0067B9@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 9/15/2002 1:23 PM Jun-ichiro itojun Hagino wrote: >> | then why "local.arpa" was removed from mDNS/LLMNR document? indicators >> | like "local.arpa" or "local" (used by Apple Rendezvous) is a good >> | indication of different name space. >>No, mangling the names is a poor way to indicate different name spaces. > > then how can we differentiate mDNS/LLMNR name and DNS name under > the same API (getaddrinfo/getnameinfo)? LLMNR names are not DNS names. They are not authoritative for the same namespaces, and they shouldn't be mixed. How do you already multiplex DNS/NetBIOS/NIS/etc under a single API? Why should this be different? -- 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 00:44:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16806 for ; Mon, 16 Sep 2002 00:44:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qnTe-000J25-00 for namedroppers-data@psg.com; Sun, 15 Sep 2002 21:27:14 -0700 Received: from [66.81.111.138] (helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17qnTZ-000J1s-00 for namedroppers@ops.ietf.org; Sun, 15 Sep 2002 21:27:10 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 16E817B9; Mon, 16 Sep 2002 13:27:04 +0900 (JST) To: "Eric A. Hall" Cc: Robert Elz , namedroppers@ops.ietf.org In-reply-to: ehall's message of Sun, 15 Sep 2002 14:19:16 EST. <3D84DD34.2050907@ehsco.com> 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 Subject: Re: mDNS/LLMNR and "local.arpa" From: Jun-ichiro itojun Hagino Date: Mon, 16 Sep 2002 13:27:04 +0900 Message-Id: <20020916042704.16E817B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>> | then why "local.arpa" was removed from mDNS/LLMNR document? indicators >>> | like "local.arpa" or "local" (used by Apple Rendezvous) is a good >>> | indication of different name space. >>>No, mangling the names is a poor way to indicate different name spaces. >> >> then how can we differentiate mDNS/LLMNR name and DNS name under >> the same API (getaddrinfo/getnameinfo)? > >LLMNR names are not DNS names. They are not authoritative for the same >namespaces, and they shouldn't be mixed. > >How do you already multiplex DNS/NetBIOS/NIS/etc under a single API? Why >should this be different? i don't quite parse it. are you against the use of local.arpa, or are you for the use of local.arpa? DNS and NIS names (and /etc/hosts) are accessed via single API (gethostby*, getaddrinfo/getnameinfo), so it makes sense to use the same API. 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 09:00:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03219 for ; Mon, 16 Sep 2002 09:00:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qvFH-0008aH-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 05:44:55 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qvF5-0008ZQ-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 05:44:43 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GCilRF036074 for ; Mon, 16 Sep 2002 08:44:47 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA15724 for ; Mon, 16 Sep 2002 08:44:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 08:40:41 -0400 To: namedroppers From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would think [0] that if a signed positive answer is given, there is no reason to show that there was potentially a wildcard (signed or unsigned) available. If there exists an unsigned positive answer, *is* there a need to prove that there is no wildcard? I guess so, but this is getting sticky. At 4:40PM -0700 9/3/02, Brian Wellington wrote: >The positive response with opt-in also needs to contain proof that there's >no secure wildcard, otherwise secure wildcards can be spoofed away. This >will mean another SIG and SIG(NXT) in almost every case. [0] Apologies - I am reviewing the thread while flying back from RIPE, so the reply is delayed and possibly confused. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 09:01:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03260 for ; Mon, 16 Sep 2002 09:01:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qvF5-0008ZR-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 05:44:43 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qvEy-0008Yk-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 05:44:36 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GCidRF036054; Mon, 16 Sep 2002 08:44:39 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA15693; Mon, 16 Sep 2002 08:44:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <007c01c25b1f$4ac2cf30$b9370681@BARNACLE> References: <00cd01c25a91$e5f917e0$b9370681@BARNACLE> <007c01c25b1f$4ac2cf30$b9370681@BARNACLE> Date: Sat, 14 Sep 2002 07:14:49 -0400 To: "Scott Rose" , , "Edward Lewis" From: Edward Lewis Subject: Re: dynamic update zone Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_48_96 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:15AM -0400 9/13/02, Scott Rose wrote: >If I'm thinking correctly about this, the new interpretation of the rcodes >would be: >refused - means that the server will never accept an update from the sender >until some misconfiguration is correct, or policy stuff. > >frozen(whatever) - means that the sender could normally make the update, but >the server has been frozen by an admin for some time period. Try again >later and it might suceed. > >correct? That sounds like what I had in mind. For a manual (interactive) client, I think that the difference between the two would be to print "permanent error" for a REFUSED, and "temporary error" for a FROZEN (or SUSPENDED). For an automated client, I probably wouldn't recommend different treatments - so as to prevent overly persistent broken implementations. (Perhaps the log message is different in the two cases, as suggested for the manual client.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 09:02:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03312 for ; Mon, 16 Sep 2002 09:02:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qvF9-0008Zj-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 05:44:47 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qvF4-0008ZG-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 05:44:42 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GCiiRF036065; Mon, 16 Sep 2002 08:44:44 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA15706; Mon, 16 Sep 2002 08:44:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: References: Date: Sat, 14 Sep 2002 10:43:16 -0400 To: Roy Arends , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_24_48 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:01AM +0200 9/4/02, Roy Arends wrote: >Note that wildcards are in a zone, delegation points are outside a zone, >therefor you can't use wildcard delegations, and thus no proof for >existing wildcard delegation is needed. Question is: does an signed wildcard trump an unsigned delegation name? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 09:03:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03398 for ; Mon, 16 Sep 2002 09:03:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qvFG-0008aC-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 05:44:54 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qvF2-0008Z5-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 05:44:40 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GCiiRF036068; Mon, 16 Sep 2002 08:44:44 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA15708; Mon, 16 Sep 2002 08:44:39 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <20020904142321.4BEF428B6F@as.vix.com> References: <20020904142321.4BEF428B6F@as.vix.com> Date: Sat, 14 Sep 2002 10:44:44 -0400 To: Paul Vixie , namedroppers From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_24_48 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 2:23PM +0000 9/4/02, Paul Vixie wrote: >it's starting to seem to me that answers containing NXT should include an >SOA in the authority section. (even though that means nonauthoritative >servers will have to cache them, which today is illegal.) when new secure >(verified) data arrives with a later SOA.SERIAL, all the older cached data >for that zone becomes invalid. NXT's are already supposed to only be signed by the zone key. Isn't that sufficient to identify the authority - or is there something else needed out of the SOA RR RDATA? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 10:11:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05857 for ; Mon, 16 Sep 2002 10:11:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwUP-000B61-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:04:37 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17qwUJ-000B5c-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:04:31 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GE4MxG023225; Mon, 16 Sep 2002 16:04:22 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GE4LWS023221; Mon, 16 Sep 2002 16:04:21 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 16 Sep 2002 16:04:21 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 14 Sep 2002, Edward Lewis wrote: > At 10:01AM +0200 9/4/02, Roy Arends wrote: > >Note that wildcards are in a zone, delegation points are outside a zone, > >therefor you can't use wildcard delegations, and thus no proof for > >existing wildcard delegation is needed. > > Question is: does an signed wildcard trump an unsigned delegation name? No, I don't think that is the question. The signer of the zone has give proof that there exist no signed material in an interval. All bets are off if you query for a record that is not signed [1]. If the signer of the zone wants to use signed wildcards, she should know that they can be used to spoof within unsigned intervals. [1] Note that the response has a signed statement that the interval is not secure. Proof of wildcards in a response with positive unsigned referals leads to nothing more than ambiguity. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 10:13:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05904 for ; Mon, 16 Sep 2002 10:13:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwW5-000BBM-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:06:21 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17qwVv-000BAw-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:06:12 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA23245; Mon, 16 Sep 2002 10:06:10 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA03004; Mon, 16 Sep 2002 10:06:10 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA05708; Mon, 16 Sep 2002 10:06:09 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA19411; Mon, 16 Sep 2002 10:06:09 -0400 (EDT) To: Edward Lewis Cc: namedroppers From: Derek Atkins Subject: Re: DNSSEXT Yokohama Minutes References: Date: 16 Sep 2002 10:06:09 -0400 In-Reply-To: Message-ID: Lines: 40 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > I would think [0] that if a signed positive answer is given, there is > no reason to show that there was potentially a wildcard (signed or > unsigned) available. If there exists an unsigned positive answer, > *is* there a need to prove that there is no wildcard? I guess so, but > this is getting sticky. Note that the only "unsigned positive response" you could have is an NS record. I didn't think that wildcard NS records were allowed? What it DOES mean is that you need to send twice as much data to prove an NXDOMAIN. It is not sufficient to just show the NXT for the request, but you must also show the NXT for the wildcard. -derek > At 4:40PM -0700 9/3/02, Brian Wellington wrote: > >The positive response with opt-in also needs to contain proof that there's > >no secure wildcard, otherwise secure wildcards can be spoofed away. This > >will mean another SIG and SIG(NXT) in almost every case. > > [0] Apologies - I am reviewing the thread while flying back from RIPE, > so the reply is delayed and possibly confused. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 10:14:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05971 for ; Mon, 16 Sep 2002 10:14:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwS7-000B0C-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:02:15 -0700 Received: from fs3.antd.nist.gov ([129.6.50.151]) by psg.com with esmtp (Exim 3.36 #1) id 17qwS3-000B00-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:02:12 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by fs3.antd.nist.gov (8.11.6/8.11.6) with SMTP id g8GE1vY29047; Mon, 16 Sep 2002 10:01:57 -0400 Message-ID: <00a701c25d88$9f790880$b9370681@BARNACLE> From: "Scott Rose" To: "Roy Arends" , Cc: References: Subject: Re: DNSSEXT Yokohama Minutes Date: Mon, 16 Sep 2002 09:54:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Edward Lewis" > At 10:01AM +0200 9/4/02, Roy Arends wrote: > >Note that wildcards are in a zone, delegation points are outside a zone, > >therefor you can't use wildcard delegations, and thus no proof for > >existing wildcard delegation is needed. > > Question is: does an signed wildcard trump an unsigned delegation name? > -- I think it should - wildcards can be signed, and considered authoritative in a zone. Since delegations aren't, it could be spoof (but hopefully detected later). A resolver can verify a signed wildcard, but not a delegation. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 10:15:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06005 for ; Mon, 16 Sep 2002 10:15:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwZu-000BKw-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:10:18 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17qwZr-000BKf-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:10:15 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA25310; Mon, 16 Sep 2002 10:10:10 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA02557; Mon, 16 Sep 2002 10:10:10 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA14125; Mon, 16 Sep 2002 10:10:09 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA19414; Mon, 16 Sep 2002 10:10:09 -0400 (EDT) To: Edward Lewis Cc: Roy Arends , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSSEXT Yokohama Minutes References: Date: 16 Sep 2002 10:10:09 -0400 In-Reply-To: Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > Question is: does an signed wildcard trump an unsigned delegation name? What do you mean? You cannot have a "*.example IN NS ..." record. The fact that you have a signed "*.example IN MX ..." record has nothing to do with the fact that you've got an unsigned "foo.example IN NS .." record. How would this trumping even happen? The RTYPEs are different. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 10:24:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06235 for ; Mon, 16 Sep 2002 10:24:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwfu-000BcL-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:16:30 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17qwfp-000Bbx-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:16:25 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GEGExG023362; Mon, 16 Sep 2002 16:16:14 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GEGDcR023358; Mon, 16 Sep 2002 16:16:13 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 16 Sep 2002 16:16:13 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Scott Rose cc: namedroppers@ops.ietf.org, Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <00a701c25d88$9f790880$b9370681@BARNACLE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 16 Sep 2002, Scott Rose wrote: > ----- Original Message ----- > From: "Edward Lewis" > > > > At 10:01AM +0200 9/4/02, Roy Arends wrote: > > >Note that wildcards are in a zone, delegation points are outside a zone, > > >therefor you can't use wildcard delegations, and thus no proof for > > >existing wildcard delegation is needed. > > > > Question is: does an signed wildcard trump an unsigned delegation name? > > -- > > I think it should - wildcards can be signed, and considered authoritative in > a zone. Since delegations aren't, it could be spoof (but hopefully detected > later). > > A resolver can verify a signed wildcard, but not a delegation. You treat "authoritative" and "signed" as equal, while one relates to server and the other to source. Delegations can only be spoofed if they are not signed. That is a conscious descision a signer makes. Please inform me what a resolver should do with the ambiguity of both an unsigned referral and a signed wildcard in a response. Spoofing can go both ways, one can spoof a unsigned referral with a signed wildcard, or a signed wildcard with an unsigned referral. Simply proofing the existence of a signed wildcard makes this ambiguity not go away. It is about the descision a resolver has to make: follow an unsigned referral or stick with the signed wildcard. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 10:24:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06279 for ; Mon, 16 Sep 2002 10:24:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwkH-000Bob-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:21:01 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17qwk9-000BoL-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:20:53 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id D886128B01 for ; Mon, 16 Sep 2002 14:20:52 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from Edward Lewis of "Sat, 14 Sep 2002 10:44:44 -0400." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 16 Sep 2002 14:20:52 +0000 Message-Id: <20020916142052.D886128B01@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >it's starting to seem to me that answers containing NXT should include an > >SOA in the authority section. (even though that means nonauthoritative > >servers will have to cache them, which today is illegal.) when new secure > >(verified) data arrives with a later SOA.SERIAL, all the older cached data > >for that zone becomes invalid. > > NXT's are already supposed to only be signed by the zone key. Isn't > that sufficient to identify the authority - or is there something > else needed out of the SOA RR RDATA? if there's enough info in the signature to be able to tell what other cached data you should preexpire, then no. however, i don't think that's the case; all you can know, afaik, is that the records you're holding were signed less recently than the records you're now receiving. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 10:40:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06935 for ; Mon, 16 Sep 2002 10:40:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwwY-000CNw-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:33:42 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qwwQ-000CNX-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:33:34 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GEXaRF039700; Mon, 16 Sep 2002 10:33:36 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA03184; Mon, 16 Sep 2002 10:33:27 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 10:33:20 -0400 To: Roy Arends , Edward Lewis From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:04PM +0200 9/16/02, Roy Arends wrote: >The signer of the zone has give proof that there exist no signed material >in an interval. The problem is that, when considering wildcards, "interval" is not singular but plural. E.g., there must be proof that there exists no signed material in each interval that a name might fit. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 10:41:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07031 for ; Mon, 16 Sep 2002 10:41:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwwv-000CPm-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:34:05 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qwwm-000CPS-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:33:56 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GEXTRF039695; Mon, 16 Sep 2002 10:33:29 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA03146; Mon, 16 Sep 2002 10:33:21 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 10:29:57 -0400 To: Derek Atkins , Edward Lewis From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,OPT_IN,PORN_3 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:06AM -0400 9/16/02, Derek Atkins wrote: >Note that the only "unsigned positive response" you could have is an >NS record. I didn't think that wildcard NS records were allowed? I don't mean to imply that there is a wildcarded NS. E.g.,: In my zone I have: * 900 IN TXT "This is a wildcard match" SIG TXT 900 IN A 10.10.10.10 SIG A 900 IN MX 10 host SIG MX 900 IN NXT alpha TXT A MX SIG NXT and alpha 900 IN NS nameserver SIG NS 900 IN NXT beta NS SIG NXT(or not) SIG NXT alpha1 900 IN NS nameserver alpha2 900 IN NS nameserver beta 900 IN NS nameserver SIG NS 900 IN NXT gamma NS SIG NXT(or not) SIG NXT ... If I ask for (alpha3 A) I get the wildcard. If I ask for (alpha2 NS) I get the unsigned alpha2 NS. If I ask for (alpha NS) I get the signed alpha NS. If I ask for (alpha3 NS) I get no such data per the wildcard. The issue here is that it is easy to spoof away the signed wildcard with opt-in. Let's say I do ask for alpha3 A. Since there's an opt-in-ized NXT saying that alpha3 is not explicitly signed in the zone, all an attacker needs to do is replay this before the answer with the signed * match returns - or - modify a cache to strip away the *-synthesized records from an answer. At first I was surprised by Scott saying that the * trumps opted-out data, but now I agree with him. If you don't assume that there is a signed * name in the zone, then it can be spoofed away. So, if there is an applicable * - then it would hide all the unsecured matched "behind it" which is counter-intuitive to the algorithm in rfc1034/s4.3.3. >What it DOES mean is that you need to send twice as much data to prove >an NXDOMAIN. It is not sufficient to just show the NXT for the >request, but you must also show the NXT for the wildcard. To match an opted-out name (unsecured) you have to prove it isn't secured, and that there isn't a potential wildcard, the latter may require multiple NXT's. Also - does the presence of an opted-out name impact the scope of a wildcard's matches? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 10:56:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07792 for ; Mon, 16 Sep 2002 10:56:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxAn-000CzE-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:48:25 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17qxAj-000Cyz-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:48:21 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA17159; Mon, 16 Sep 2002 10:48:16 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA13337; Mon, 16 Sep 2002 10:48:14 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA16664; Mon, 16 Sep 2002 10:48:14 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA19496; Mon, 16 Sep 2002 10:48:14 -0400 (EDT) To: Edward Lewis Cc: Roy Arends , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSSEXT Yokohama Minutes References: Date: 16 Sep 2002 10:48:13 -0400 In-Reply-To: Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 4:04PM +0200 9/16/02, Roy Arends wrote: > >The signer of the zone has give proof that there exist no signed material > >in an interval. > > The problem is that, when considering wildcards, "interval" is not > singular but plural. E.g., there must be proof that there exists no > signed material in each interval that a name might fit. No, it's singular because the wildcard is applied to each request individually. So you need to show proof-of-nonexistence in the query-interval on each query. This is a seperable problem, as queries are independent. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:03:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08069 for ; Mon, 16 Sep 2002 11:03:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxI7-000DJm-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 07:55:59 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17qxHw-000DJO-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 07:55:49 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA20537; Mon, 16 Sep 2002 10:55:48 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA13660; Mon, 16 Sep 2002 10:52:46 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA16975; Mon, 16 Sep 2002 10:52:45 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA19499; Mon, 16 Sep 2002 10:52:45 -0400 (EDT) To: Edward Lewis Cc: namedroppers From: Derek Atkins Subject: Re: DNSSEXT Yokohama Minutes References: Date: 16 Sep 2002 10:52:45 -0400 In-Reply-To: Message-ID: Lines: 42 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD,PORN_3 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > The issue here is that it is easy to spoof away the signed wildcard > with opt-in. Let's say I do ask for alpha3 A. Since there's an > opt-in-ized NXT saying that alpha3 is not explicitly signed in the > zone, all an attacker needs to do is replay this before the answer > with the signed * match returns - or - modify a cache to strip away > the *-synthesized records from an answer. As I said, an answer of NXDOMAIN is incomplete without _TWO_ signed NXT records, so a client would know they were being attacked if they only received one. Similarly, an attacker could not add an 'A' record to this response, because opt-in only allows unsecured delegations. > So, if there is an applicable * - then it would hide all the unsecured > matched "behind it" which is counter-intuitive to the algorithm in > rfc1034/s4.3.3. Right, but there _are_ no unsecured matches because opt-in only allows unsecured NS, and you cannot have an NS wildcard. > >What it DOES mean is that you need to send twice as much data to prove > >an NXDOMAIN. It is not sufficient to just show the NXT for the > >request, but you must also show the NXT for the wildcard. > > To match an opted-out name (unsecured) you have to prove it isn't > secured, and that there isn't a potential wildcard, the latter may > require multiple NXT's. This is correct, but only in the case where you have a multi-layer zone. > Also - does the presence of an opted-out name impact the scope of a > wildcard's matches? It doesn't. It is no worse than a non-opted-out name. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:10:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08232 for ; Mon, 16 Sep 2002 11:10:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxQM-000Dcz-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:04:30 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17qxQE-000Dck-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:04:22 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02079; Mon, 16 Sep 2002 09:04:19 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8GF4IA07214; Mon, 16 Sep 2002 17:04:18 +0200 (MEST) Date: Mon, 16 Sep 2002 17:01:53 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: mDNS/LLMNR and "local.arpa" To: Jun-ichiro itojun Hagino Cc: Robert Elz , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <20020915182357.4D0067B9@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > then how can we differentiate mDNS/LLMNR name and DNS name under > the same API (getaddrinfo/getnameinfo)? One could envision new flags (such as AI_LLMNR) for lookups in the local name space. 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:12:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08285 for ; Mon, 16 Sep 2002 11:12:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxSF-000DgX-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:06:27 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qxS7-000Dfl-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:06:19 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GF6HRF041049; Mon, 16 Sep 2002 11:06:17 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA08258; Mon, 16 Sep 2002 11:06:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 10:46:18 -0400 To: Roy Arends , Scott Rose From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: namedroppers@ops.ietf.org, Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:16PM +0200 9/16/02, Roy Arends wrote: >Please inform me what a resolver should do with the ambiguity of both an >unsigned referral and a signed wildcard in a response. That's the problem. It's getting harder and harder to tell what should be done. It's clear that a reply should have, barring EDNS1's multiple query proposal, 0 or 1 answering RRsets. (0 means no data/name found.) The rest of the answer should be there to support the answer chosen. The problem is how do you protect answers that should have been synthesized from a signed wildcard answer (which does not have to be a delegation) from being spoofed away by OPT-IN modified NXT records and falsified answers? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:13:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08307 for ; Mon, 16 Sep 2002 11:13:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxSc-000DlQ-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:06:50 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qxSW-000Dk8-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:06:44 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GF6FRF041046; Mon, 16 Sep 2002 11:06:15 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA08254; Mon, 16 Sep 2002 11:06:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 10:40:41 -0400 To: Derek Atkins , Edward Lewis From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: Roy Arends , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:10AM -0400 9/16/02, Derek Atkins wrote: >How would this trumping even happen? The RTYPEs are different. The trumping is whether the algorithm for looking up replies first checks the signed data only (hence finds the wildcard) or looks through all the data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:25:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08542 for ; Mon, 16 Sep 2002 11:25:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxeB-000EIu-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:18:47 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17qxe8-000EIf-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:18:44 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 495BA4B23; Tue, 17 Sep 2002 00:18:36 +0900 (JST) To: Erik Nordmark Cc: namedroppers@ops.ietf.org In-reply-to: Erik.Nordmark's message of Mon, 16 Sep 2002 17:01:53 +0200. 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 Subject: Re: mDNS/LLMNR and "local.arpa" From: itojun@iijlab.net Date: Tue, 17 Sep 2002 00:18:36 +0900 Message-Id: <20020916151838.495BA4B23@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> then how can we differentiate mDNS/LLMNR name and DNS name under >> the same API (getaddrinfo/getnameinfo)? >One could envision new flags (such as AI_LLMNR) for lookups in the local >name space. that is certainly one possibility, but why do we need it when we don't have AI_NIS? AI_LLMNR removes transparency (of LLMNR) to the application. 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:27:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08574 for ; Mon, 16 Sep 2002 11:27:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxgq-000ES8-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:21:32 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17qxgn-000ERv-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:21:29 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA01505; Mon, 16 Sep 2002 11:21:24 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18413; Mon, 16 Sep 2002 11:21:24 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18602; Mon, 16 Sep 2002 11:15:43 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA19545; Mon, 16 Sep 2002 11:15:42 -0400 (EDT) To: Edward Lewis Cc: Roy Arends , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSSEXT Yokohama Minutes References: Date: 16 Sep 2002 11:15:42 -0400 In-Reply-To: Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 10:10AM -0400 9/16/02, Derek Atkins wrote: > >How would this trumping even happen? The RTYPEs are different. > > The trumping is whether the algorithm for looking up replies first > checks the signed data only (hence finds the wildcard) or looks > through all the data. The algorithm at the server or at a cache? An authoritative server still looks at the QNAME first. If it finds an entry for the QTYPE, it uses it. It not, it checks the wildcard. The fact that opt-in is in use doesn't change this. Remember: only NS records can live within an opt-in interval. This means that the potential states you have are: 1) signed RDATA at the QNAME and signed wildcard RDATA wins 2) no RDATA at QNAME and signed wildcard wildcard wins, but must provide the QNAME NXT 3) no RDATA and no wildcard NXDOMAIN; must provide both (all?) NXTs The fact that the NXT is opt-in or not does not matter, because the only record that can live in an opt-int interval is an NS, and you cannot have wildcard NS. If the QTYPE is NS, then you can ignore wildcards completely. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:31:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08654 for ; Mon, 16 Sep 2002 11:31:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxkg-000EfI-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:25:30 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17qxkc-000Ef6-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:25:26 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GFPExG024557; Mon, 16 Sep 2002 17:25:14 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GFPDPW024553; Mon, 16 Sep 2002 17:25:13 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 16 Sep 2002 17:25:13 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: Scott Rose , Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 16 Sep 2002, Edward Lewis wrote: > At 4:16PM +0200 9/16/02, Roy Arends wrote: > >Please inform me what a resolver should do with the ambiguity of both an > >unsigned referral and a signed wildcard in a response. > > That's the problem. It's getting harder and harder to tell what > should be done. > > It's clear that a reply should have, barring EDNS1's multiple query > proposal, 0 or 1 answering RRsets. (0 means no data/name found.) > The rest of the answer should be there to support the answer chosen. > > The problem is how do you protect answers that should have been > synthesized from a signed wildcard answer (which does not have to be > a delegation) cannot be a delegation (wildcard delegations are not legal). > from being spoofed away by OPT-IN modified NXT records > and falsified answers? I'm stumbling over your words now. I do understand the problem. The problem is _not_ what should be in a response, the problem is what a resolver should do with the ambiguity: Follow unsigned delegation, or assume its a spoof, and go with the signed wildcard. Yes, with opt-in as is, you could simply spoof away signed wildcards with unsecure delegations, and simply spoof away unsecure delegations with secure wildcards. How'bout we state in the Opt-In draft that, when using DNSSEC, having both opt-in and wildcards are illegal. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:37:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08801 for ; Mon, 16 Sep 2002 11:37:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxqr-000Ey4-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:31:53 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qxqn-000Exm-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:31:49 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GFVERF042068; Mon, 16 Sep 2002 11:31:14 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA12941; Mon, 16 Sep 2002 11:31:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 11:18:40 -0400 To: Derek Atkins , Edward Lewis From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: Roy Arends , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:48AM -0400 9/16/02, Derek Atkins wrote: >No, it's singular because the wildcard is applied to each request >individually. So you need to show proof-of-nonexistence in the >query-interval on each query. This is a seperable problem, as queries >are independent. When you follow the wildcard algorithm, you need to search through different intervals. First the explicit one followed by all intervals that might hold a wildcard. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:43:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08978 for ; Mon, 16 Sep 2002 11:43:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxqp-000Exz-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:31:51 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qxqk-000ExX-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:31:47 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GFVERF042071; Mon, 16 Sep 2002 11:31:14 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA12945; Mon, 16 Sep 2002 11:31:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 11:30:33 -0400 To: Derek Atkins , Edward Lewis From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD,PORN_3 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:52AM -0400 9/16/02, Derek Atkins wrote: >Edward Lewis writes: > >> The issue here is that it is easy to spoof away the signed wildcard >> with opt-in. Let's say I do ask for alpha3 A. Since there's an >> opt-in-ized NXT saying that alpha3 is not explicitly signed in the >> zone, all an attacker needs to do is replay this before the answer >> with the signed * match returns - or - modify a cache to strip away >> the *-synthesized records from an answer. > >As I said, an answer of NXDOMAIN is incomplete without _TWO_ signed no need to yell ;) >NXT records, so a client would know they were being attacked if they >only received one. Similarly, an attacker could not add an 'A' record >to this response, because opt-in only allows unsecured delegations. Which two NXT's would be sent to prove that alpha3 A does not exist? (Would it be that alpha3 is not a signed name and there is no signed wildcard?) >> So, if there is an applicable * - then it would hide all the unsecured >> matched "behind it" which is counter-intuitive to the algorithm in >> rfc1034/s4.3.3. > >Right, but there _are_ no unsecured matches because opt-in only allows >unsecured NS, and you cannot have an NS wildcard. Remember that wildcards match names, not names&types. If the wildcard has an A record and no NS record, all queries for matching names and (QTYPE=)NS get a NODATA response because the name matched. >> Also - does the presence of an opted-out name impact the scope of a >> wildcard's matches? > >It doesn't. It is no worse than a non-opted-out name. Okay, I see that, because an opted out name is a zone cut. (But what do you mean by "worse?") *.zone TXT "matches names" SIG TXT ... unsec.zone NS ... querying for anything below unsec.zone would result in a referral answer. I guess this cements the rationale to diallow non-zone cuts in the opted-out portion of a zone. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:47:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09151 for ; Mon, 16 Sep 2002 11:47:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qy10-000FTu-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:42:22 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17qy0s-000FTf-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:42:14 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA13505; Mon, 16 Sep 2002 11:42:10 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA22235; Mon, 16 Sep 2002 11:38:26 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA20232; Mon, 16 Sep 2002 11:38:26 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA19590; Mon, 16 Sep 2002 11:38:25 -0400 (EDT) To: Edward Lewis Cc: Roy Arends , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSSEXT Yokohama Minutes References: Date: 16 Sep 2002 11:38:25 -0400 In-Reply-To: Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 10:48AM -0400 9/16/02, Derek Atkins wrote: > >No, it's singular because the wildcard is applied to each request > >individually. So you need to show proof-of-nonexistence in the > >query-interval on each query. This is a seperable problem, as queries > >are independent. > > When you follow the wildcard algorithm, you need to search through > different intervals. First the explicit one followed by all intervals > that might hold a wildcard. Ahh, I see -- to collect multiple NXT records in the case of a multi-level zone. I keep on assuming zones with single levels. My appologies. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:50:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09237 for ; Mon, 16 Sep 2002 11:50:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qy3d-000FcG-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:45:05 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qy3O-000Fau-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:44:51 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GFiBRF042431; Mon, 16 Sep 2002 11:44:11 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA14434; Mon, 16 Sep 2002 11:44:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 11:34:03 -0400 To: Derek Atkins , Edward Lewis From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: Roy Arends , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD,PORN_3 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:15AM -0400 9/16/02, Derek Atkins wrote: >The fact that opt-in is in use doesn't change this. Remember: only NS >records can live within an opt-in interval. This means that the >potential states you have are: > >1) signed RDATA at the QNAME and signed wildcard > RDATA wins >2) no RDATA at QNAME and signed wildcard > wildcard wins, but must provide the QNAME NXT That's wrong - NODATA @ QNAME wins...once the name matches, I stop searching. >3) no RDATA and no wildcard > NXDOMAIN; must provide both (all?) NXTs That should be no explicit QNAME and no wildcard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:50:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09258 for ; Mon, 16 Sep 2002 11:50:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qy3H-000Faj-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:44:43 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qy2v-000FZa-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:44:21 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GFiGRF042440; Mon, 16 Sep 2002 11:44:16 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA14439; Mon, 16 Sep 2002 11:44:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 11:44:09 -0400 To: Roy Arends , Edward Lewis From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: Scott Rose , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:25PM +0200 9/16/02, Roy Arends wrote: >cannot be a delegation (wildcard delegations are not legal). I have never said that there was a wild card NS. A wild card with any (legal) RRset is sufficient to cause heartburn burn because of the way wild cards are processed. >I do understand the problem. The problem is _not_ what should be in a >response, the problem is what a resolver should do with the ambiguity: >Follow unsigned delegation, or assume its a spoof, and go with the signed >wildcard. Not quite. The signed wild card wouldn't be synthesized to the answer, but there is a need to prove it doesn't exist in this case. In other words, you have to prove that the answer has to have come from the unsecured portion of the zone before the consumer can rely on it. This is getting pretty darned confusing. >Yes, with opt-in as is, you could simply spoof away signed wildcards with >unsecure delegations, and simply spoof away unsecure delegations with >secure wildcards. That's my issue. >How'bout we state in the Opt-In draft that, when using DNSSEC, having both >opt-in and wildcards are illegal. No. That's the absolute wrong approach. I don't know where to start to back that up - there are too many reasons. Reducing the problem to meet a solution is suboptimal. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:50:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09281 for ; Mon, 16 Sep 2002 11:50:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qy2a-000FY7-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:44:00 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17qy2X-000FXq-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:43:57 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA16041; Mon, 16 Sep 2002 11:43:56 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA23673; Mon, 16 Sep 2002 11:43:56 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA20610; Mon, 16 Sep 2002 11:43:55 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA19603; Mon, 16 Sep 2002 11:43:55 -0400 (EDT) To: Edward Lewis Cc: namedroppers From: Derek Atkins Subject: Re: DNSSEXT Yokohama Minutes References: Date: 16 Sep 2002 11:43:55 -0400 In-Reply-To: Message-ID: Lines: 47 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > Which two NXT's would be sent to prove that alpha3 A does not exist? > (Would it be that alpha3 is not a signed name and there is no signed > wildcard?) Yes. Two two NXTs are: 1) prove the alpha3 A does not exist 2) prove there is no matching wildcard > Remember that wildcards match names, not names&types. If the wildcard > has an A record and no NS record, all queries for matching names and > (QTYPE=)NS get a NODATA response because the name matched. HUH? If I make a query for foo TXT I could get an MX response because there is a * MX record? Can you show me where in the RFCs that is true? > >> Also - does the presence of an opted-out name impact the scope of a > >> wildcard's matches? > > > >It doesn't. It is no worse than a non-opted-out name. > > Okay, I see that, because an opted out name is a zone cut. (But what > do you mean by "worse?") > > *.zone TXT "matches names" > SIG TXT > ... > unsec.zone NS > ... > > querying for anything below unsec.zone would result in a referral > answer. I guess this cements the rationale to diallow non-zone cuts > in the opted-out portion of a zone. By "no worse" I mean "no different"... The only issue is the one that Roy pointed out.. You could have an unsigned NS and a signed "* A" and you need to figure out which one to believe. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 11:51:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09318 for ; Mon, 16 Sep 2002 11:51:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qy24-000FVe-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:43:28 -0700 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 3.36 #1) id 17qy1v-000FUQ-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:43:19 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 770B244DA; Mon, 16 Sep 2002 17:42:48 +0200 (CEST) Date: Mon, 16 Sep 2002 17:42:48 +0200 From: bert hubert To: Roy Arends Cc: Edward Lewis , Scott Rose , namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes Message-ID: <20020916154248.GA2790@outpost.ds9a.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Sep 16, 2002 at 05:25:13PM +0200, Roy Arends wrote: > > The problem is how do you protect answers that should have been > > synthesized from a signed wildcard answer (which does not have to be > > a delegation) > > cannot be a delegation (wildcard delegations are not legal). Neither are wildcard CNAMEs but you get roasted if you don't offer them. regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 12:00:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09604 for ; Mon, 16 Sep 2002 12:00:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qyCA-000G8M-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:53:54 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17qyC1-000G7X-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:53:45 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GFrZxG024925; Mon, 16 Sep 2002 17:53:35 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GFrZEU024921; Mon, 16 Sep 2002 17:53:35 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 16 Sep 2002 17:53:34 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: Scott Rose , Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 16 Sep 2002, Edward Lewis wrote: > At 5:25PM +0200 9/16/02, Roy Arends wrote: > >cannot be a delegation (wildcard delegations are not legal). > > I have never said that there was a wild card NS. Apologies, I've misread your post. > A wild card with any (legal) RRset is sufficient to cause heartburn burn > because of the way wild cards are processed. I agree. > >I do understand the problem. The problem is _not_ what should be in a > >response, the problem is what a resolver should do with the ambiguity: > >Follow unsigned delegation, or assume its a spoof, and go with the signed > >wildcard. > > Not quite. The signed wild card wouldn't be synthesized to the answer, > but there is a need to prove it doesn't exist in this case. In other > words, you have to prove that the answer has to have come from the > unsecured portion of the zone before the consumer can rely on it. This > is getting pretty darned confusing. yeah. > >Yes, with opt-in as is, you could simply spoof away signed wildcards with > >unsecure delegations, and simply spoof away unsecure delegations with > >secure wildcards. > > That's my issue. Okay, lets focus on that. > >How'bout we state in the Opt-In draft that, when using DNSSEC, having both > >opt-in and wildcards are illegal. > > No. That's the absolute wrong approach. I don't know where to start > to back that up - there are too many reasons. Reducing the problem > to meet a solution is suboptimal. I agree, but I would just call it a pragmatic solution, since it works. (I wasn't seriously proposing it, I just forgot the smiley) Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 12:06:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09723 for ; Mon, 16 Sep 2002 12:06:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qyIT-000GUW-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 09:00:25 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qyIQ-000GUJ-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 09:00:22 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GG0GRF042997; Mon, 16 Sep 2002 12:00:16 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA17001; Mon, 16 Sep 2002 12:00:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 11:59:58 -0400 To: Roy Arends , Edward Lewis From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: Scott Rose , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:53PM +0200 9/16/02, Roy Arends wrote: >(I wasn't seriously proposing it, I just forgot the smiley) Okay - ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 12:10:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09852 for ; Mon, 16 Sep 2002 12:10:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qyHD-000GQD-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 08:59:07 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17qyH8-000GPv-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 08:59:02 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8GFwURF042949; Mon, 16 Sep 2002 11:58:30 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA16643; Mon, 16 Sep 2002 11:58:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 16 Sep 2002 11:58:30 -0400 To: Derek Atkins , Edward Lewis From: Edward Lewis Subject: Re: DNSSEXT Yokohama Minutes Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.2 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,PORN_10,UPPERCASE_25_50 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:43AM -0400 9/16/02, Derek Atkins wrote: >HUH? If I make a query for foo TXT I could get an MX response because >there is a * MX record? Can you show me where in the RFCs that is >true? As I said, if (according to your example) you ask for foo TXT, you do not follow the wild card because foo is a name in the zone. BIND 9.3.3. does this. The algorithm followed is in RFC 1034, 4.3.2, in particular, step 3 a. Here's much more detail on my test. Note that the * has an MX, and beached-whale does explicitly exist without an MX. Hence, asking for beached-whale's MX results in no data: [lead-arin-net:~] edlewis% dig @0 beached-whale.ed.ds.isi.edu. MX ; <<>> DiG 9.3.0s20020722 <<>> @0 beached-whale.ed.ds.isi.edu. MX ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6309 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;beached-whale.ed.ds.isi.edu. IN MX ;; AUTHORITY SECTION: ed.ds.isi.edu. 900 IN SOA beached-whale.ed.ds.isi.edu. edlewis.arin.net. 5 1200 300 3600 900 ;; Query time: 13 msec ;; SERVER: 127.0.0.1#53(0) ;; WHEN: Mon Sep 16 11:57:11 2002 ;; MSG SIZE rcvd: 97 [lead-arin-net:~] edlewis% dig @0 ed.ds.isi.edu axfr +multiline ; <<>> DiG 9.3.0s20020722 <<>> @0 ed.ds.isi.edu axfr +multiline ;; global options: printcmd ed.ds.isi.edu. 900 IN SOA beached-whale.ed.ds.isi.edu. edlewis.arin.net. ( 5 ; serial 1200 ; refresh (20 minutes) 300 ; retry (5 minutes) 3600 ; expire (1 hour) 900 ; minimum (15 minutes) ) ed.ds.isi.edu. 900 IN SIG SOA 1 4 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. UhMiJQArMQyYRxAA8edEI2tynsp1klLDaWolvR+Cq8P0 nXkEYdrAjnvaQ/IwILrYT9hg6z9jar7KeeJ+WrgYZg== ) ed.ds.isi.edu. 900 IN NS beached-whale.ed.ds.isi.edu. ed.ds.isi.edu. 900 IN SIG NS 1 4 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. nrQVW6iteDqIFvsTivQ/nxRlirZYeYyiE+mw/vmkGfE7 tN+a2BWA5xURifBW341j57yNZivcw6RxBOQry88o0A== ) ed.ds.isi.edu. 900 IN KEY 256 3 1 ( AQPJUDzlyI3S2+ea332/86q7AyouGHidz3HeMC86UtVN 68nbuRGhmHfZCSHmCSNmO2WK3mVwbTWNR2MCyGjd2eUj ) ; key id = 55781 ed.ds.isi.edu. 900 IN KEY 256 3 1 ( AQPuFDhGvOx1W1csG9r1TAGEohxqLKJKFohNNDuN3r+9 8EmbxVMa8VCqIwqnr3D05/ehxNJRnIqPlUGJa8EV1xcL VtbI0gV9VQ3UsvXR7w8B34/XcEZFhLB3Tx5QlaE1QbF7 oftosSVQ5DJIzWHy8cnEWoBC+s3Y+yX/Y9epU8Q2eQ== ) ; key id = 50230 ed.ds.isi.edu. 900 IN SIG KEY 1 4 900 20020927193713 ( 20020828193713 50230 ed.ds.isi.edu. VAFn5ZZEwbWO3maEcanM5rjY1vU+m3PGJPZXMLcem8dn ZFeAA/Ve0Y8Vp8lfUGnYHIJMNm438I1LUHoDncsUEWrT pYNKyEGu/poyA5Oo2yPkUpkF3UdvtGBdU737LK8rIpWV ftmewRxC4zvmVJauJZN+xT7YWKcp6h2eg682n6U= ) ed.ds.isi.edu. 900 IN SIG KEY 1 4 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. n8N04exFheDKFo52P0QxZI+xziYXoaEbrtXtgf+Mvkiu yosVsDNT4EJPEZNuuLiAMe7cjacJAN//IQRlcsutbw== ) ed.ds.isi.edu. 900 IN NXT *.ed.ds.isi.edu. NS SOA SIG KEY NXT ed.ds.isi.edu. 900 IN SIG NXT 1 4 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. p7r4ABIIWAOzLkb7MZvR9crQDb4ZbLRruzaMRr9XFWtf PZlv2zidWfNLDG2h0H1lrQ5bBsMd8cx8/e+zkLttew== ) *.ed.ds.isi.edu. 900 IN MX 10 smtp.ed.ds.isi.edu. *.ed.ds.isi.edu. 900 IN MX 20 host.ed.ds.isi.edu. *.ed.ds.isi.edu. 900 IN SIG MX 1 4 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. bzbEWzTp4BoUyspMyudPcbNalVXSY2IsyVSw7/IoUeWL nvz9JJNnbFv8hHAnoDKjqS8J0sQxg97w7omsg2dIeA== ) *.ed.ds.isi.edu. 900 IN NXT beached-whale.ed.ds.isi.edu. MX SIG NXT *.ed.ds.isi.edu. 900 IN SIG NXT 1 4 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. HXSi3DHfN9Fv+IcUD/08YfCNPA9HqLYR0GApgVQmIUjh fv4dZW9a2LZQ202UqOdw5s1BX9bWIkYMXmPtZUoqkw== ) beached-whale.ed.ds.isi.edu. 900 IN A 65.123.202.244 beached-whale.ed.ds.isi.edu. 900 IN SIG A 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. Oo80DkHoXXTBryuwd4plMBm2W2dtdXBuPQFBYSQs909/ N23p/0KLfjOz1MD0XOm1mi1qAFnlP7C+8J2MXDtpOQ== ) beached-whale.ed.ds.isi.edu. 900 IN NXT david.ed.ds.isi.edu. A SIG NXT beached-whale.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. hGtiKOGrHUsWuIkJhZigGF3+U2tzbuCOFHbi/IDQz05G OmEje0Ta1BMi3RPvCS/eilCMwx1IykB+duJeiUQxZg== ) david.ed.ds.isi.edu. 900 IN NS vogon.david.ds.isi.edu. david.ed.ds.isi.edu. 900 IN NXT host.ed.ds.isi.edu. NS SIG NXT DS david.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. AQWxgYrY/UnAIyFUkjNTkoiSmD/iEbaWJhD8VH+MI0Ia tQdIUf927HlKaUF6pMRK9Bv/WmqwAa8SNERF4LnA2w== ) david.ed.ds.isi.edu. 900 IN DS 62959 3 1 ( 4A4BEC280149BFFC8268C70EC81FA9D744178F74 ) david.ed.ds.isi.edu. 900 IN SIG DS 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. Ez1mXR2VKx7MjvM856Y6UIuxCg2KoEXunh0En4cVYGBO /MbKvJPZmigTj52pnvu8+52k9X5eQI0sSbRdhGcJlA== ) host.ed.ds.isi.edu. 900 IN A 65.123.202.244 host.ed.ds.isi.edu. 900 IN SIG A 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. nRY8yYHDR5201t/hA1pX0vVVV7CmuRTTugslcfMkVSbz 5QUVKx9NdBsMpOYNdLQ3mpJdfutRfyFGl5AFf9c/aw== ) host.ed.ds.isi.edu. 900 IN AAAA 2001:5ff::3 host.ed.ds.isi.edu. 900 IN SIG AAAA 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. oqP4p87CVlU03bddJMmLZf5OVnmULuY6fhXodk/bhCw6 aG1Dun7pcoghs+/K3Eb5I+5yXMO/RqlHBVsixBpBKQ== ) host.ed.ds.isi.edu. 900 IN NXT _ftp._tcp.host.ed.ds.isi.edu. A SIG AAAA NXT host.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. DQyvEk4aapa7/HAX/TuASbqezKd19IOZiBvRxVupuWwR agGm+wzrLh1EHmjzBb/TciPFR1Cmvo88ItnyF5gO0A== ) _ftp._tcp.host.ed.ds.isi.edu. 900 IN TXT "ftp server information" _ftp._tcp.host.ed.ds.isi.edu. 900 IN SIG TXT 1 7 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. I2qPmjGY9egHq1WvN04Yu7pmBSLwH+no6RsWosDGKxGk kqFCf0mmm6OXCmP0tbip+PC6jAmKicsEdOoZLMbWFA== ) _ftp._tcp.host.ed.ds.isi.edu. 900 IN NXT localhost.ed.ds.isi.edu. TXT SIG NXT _ftp._tcp.host.ed.ds.isi.edu. 900 IN SIG NXT 1 7 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. LJwFyoc2YBxBKD6jHlatX+wxXxopMPFEPMTt9sWORebQ kcwmEMaDj3jDGXDSAGWtxaccJszxmakMpmFyk2i2gQ== ) localhost.ed.ds.isi.edu. 900 IN A 127.0.0.1 localhost.ed.ds.isi.edu. 900 IN SIG A 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. LAFrBp1lLMLHoaMTrCY+ARtaKx8Oa5JDfwVtScSd5BYX 3x74mtFX1ygim53vjwBx3Lv43DA8ssfLcTNbCL6atQ== ) localhost.ed.ds.isi.edu. 900 IN NXT loghost.ed.ds.isi.edu. A SIG NXT localhost.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. h0Wg8aCFPfjkV4KykZCL7pdOc7GKe/JqcIu5yyVWYB5I vFNlxjXv4n5TCWrdhc4LBxHPV9v/2CakfNUQ2GXLmA== ) loghost.ed.ds.isi.edu. 900 IN CNAME localhost.newzone.ds.isi.edu. loghost.ed.ds.isi.edu. 900 IN SIG CNAME 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. H0jkvprDiuDQ3KFMdEk4rAC+dBVS1L37PXVpQMoDSGkM DFgtUNgQbLg+9A8yyUrP3g2tcceNKPJ5oX1WrxfCbg== ) loghost.ed.ds.isi.edu. 900 IN NXT loopback.ed.ds.isi.edu. CNAME SIG NXT loghost.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. qua6I9c61eMfmU3txLXyXaMflKa0LIDNGHyw0DLr/6lB xDtlse84K1BM7rTLRxsGZHhBuVCI9LCs7dIB1VBp/A== ) loopback.ed.ds.isi.edu. 900 IN CNAME localhost.newzone.ds.isi.edu. loopback.ed.ds.isi.edu. 900 IN SIG CNAME 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. xzRYUs2nk3NqaOqaXaEVp73NuT945B4K5ldCt5Y8hqAa m0OsVDdnLvNpFJauXHnNAFB78VixfE6MPXWHTB+pYQ== ) loopback.ed.ds.isi.edu. 900 IN NXT sec.ed.ds.isi.edu. CNAME SIG NXT loopback.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. XGRJn1f1ALCwcm7D66kC02PLgwOk3GB/O2kaM3+mXM9+ H8ykGLpdiPK1dI4RLG7d9bC9kdWIbwCemBWCO+DqDw== ) sec.ed.ds.isi.edu. 900 IN NS beached-whale.ed.ds.isi.edu. sec.ed.ds.isi.edu. 900 IN NXT smtp.ed.ds.isi.edu. NS SIG NXT DS sec.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. qZdL5M/XGTmPnFWSLrsn5IDLUaWZA64ldymrsuXB+u04 RB3oiH6ofVEAc05PkhIiSFE5e19aj+AO5VUdEG5tCQ== ) sec.ed.ds.isi.edu. 900 IN DS 41704 1 1 ( FC2ADFD12402782BA6BFB4C17C5DC52A32E8DDD8 ) sec.ed.ds.isi.edu. 900 IN SIG DS 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. KXG7YeoQWU6/4GDpQVJPeGT6OJY4HB0OYq7+MvxYLRbd A/zNEuK70cCZ48jesSvXd6CHFPSpOHxpdiqWK0iISA== ) smtp.ed.ds.isi.edu. 900 IN A 65.123.202.244 smtp.ed.ds.isi.edu. 900 IN SIG A 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. EErG7nINF9UFzjHEOetkXY6ogHijhNt13Bw+3196GWgj jw0abt9+JLt9D8B6V9v0dxYIyd5FQbX99C5WPiLDKw== ) smtp.ed.ds.isi.edu. 900 IN AAAA 2001:5ff::2 smtp.ed.ds.isi.edu. 900 IN SIG AAAA 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. FhQsCREVN1YhpvKHqiQBRhQbsPmaWLvPzGYwKFCnMtYB kTZR4R3jqupnXJ8DPCJQlqqMMugmfkLe1Qe73lQ9eg== ) smtp.ed.ds.isi.edu. 900 IN NXT unsec.ed.ds.isi.edu. A SIG AAAA NXT smtp.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. xZZ3MEGo4PiCKwAWBnJi5kwWSTDkXJpT6ILVo8KBKVi3 IvZoGx6OOgE+J7aWcQDD+OtYs+Ujm7PCI+pqj9HriA== ) unsec.ed.ds.isi.edu. 900 IN NS beached-whale.ed.ds.isi.edu. unsec.ed.ds.isi.edu. 900 IN NXT www.ed.ds.isi.edu. NS SIG NXT unsec.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. pjX6if7tDzPuzQknIp5BXdTzrQk5zkqzxN4BksMeeVHS MQA4ATLKgPIjsCIsJN3G84tezCRPVaNGAS4n8OPK6g== ) www.ed.ds.isi.edu. 900 IN CNAME www1.ed.ds.isi.edu. www.ed.ds.isi.edu. 900 IN SIG CNAME 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. Xf8Z+OEKVGdiZlQbati0BEzv00n3Lk1vmzCR0Xjjj13n gyc3tIe97p8irddlrDyTRLUeFMN27xEHzqugKgxbdg== ) www.ed.ds.isi.edu. 900 IN NXT www1.ed.ds.isi.edu. CNAME SIG NXT www.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. f+ECccgy3GPEG4nic8GYMlxip8OgLZYXJveXygS8oaZV TByKn/oNjNkOBCZyhs1GU4IHnt6b2y7IJwtKBizoZA== ) www1.ed.ds.isi.edu. 900 IN MX 10 smtp.ed.ds.isi.edu. www1.ed.ds.isi.edu. 900 IN MX 20 host.ed.ds.isi.edu. www1.ed.ds.isi.edu. 900 IN SIG MX 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. dueZ7jvStmSKn6q3aOBlf1vEJiNMVKNhjrcUiwzZDdvf 16VGQvqimApJgSgJStW+dHXlVyeu+5HHyDHutX2dRQ== ) www1.ed.ds.isi.edu. 900 IN TXT "no stinkin' http here" www1.ed.ds.isi.edu. 900 IN SIG TXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. or3rujTTdX+Cuv02HFintNte6H//YLsonUGdAFSasEzT Px14yBADTC2n+7vvpFiauGbeKy8QCWR1j3fGYZb1AQ== ) www1.ed.ds.isi.edu. 900 IN AAAA 2001:5ff::1 www1.ed.ds.isi.edu. 900 IN SIG AAAA 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. dTmx3oVmTlotq8MRifZ/HfMHg8aAPEK8axOlRl1shdW8 7n3Lo/w2BOEeHufImMuHFFu4DSZBj5CeZPco9DT1SQ== ) www1.ed.ds.isi.edu. 900 IN NXT ed.ds.isi.edu. MX TXT SIG AAAA NXT www1.ed.ds.isi.edu. 900 IN SIG NXT 1 5 900 20020927193713 ( 20020828193713 55781 ed.ds.isi.edu. FKYpsF89LpA+MpxpZr/cnlgU0dwV7t6Lw5J12YzoLcca uv2m2X2sL9qBVy6+yty5kT6dMxrwgKZIxTrgbt+05A== ) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 12:30:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10224 for ; Mon, 16 Sep 2002 12:30:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qygt-000HkT-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 09:25:39 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17qygq-000HkA-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 09:25:36 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA06612; Mon, 16 Sep 2002 12:25:15 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA02917; Mon, 16 Sep 2002 12:25:14 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA17377; Mon, 16 Sep 2002 12:25:13 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA19680; Mon, 16 Sep 2002 12:25:13 -0400 (EDT) To: itojun@iijlab.net Cc: Erik Nordmark , namedroppers@ops.ietf.org Subject: Re: mDNS/LLMNR and "local.arpa" References: <20020916151838.495BA4B23@coconut.itojun.org> From: Derek Atkins Date: 16 Sep 2002 12:25:13 -0400 In-Reply-To: <20020916151838.495BA4B23@coconut.itojun.org> Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Note that applications try the various naming services until it finds a match (using some locally-defined ordering). The fact that there may be name overlaps is irrelevant. If I'm searching NIS before DNS and there is a NIS-MAP that provides a response for host.foo.com, my application will use that response rather than searching DNS. I don't see why LLMNR should behave any differently. -derek itojun@iijlab.net writes: > >> then how can we differentiate mDNS/LLMNR name and DNS name under > >> the same API (getaddrinfo/getnameinfo)? > >One could envision new flags (such as AI_LLMNR) for lookups in the local > >name space. > > that is certainly one possibility, but why do we need it when we don't > have AI_NIS? AI_LLMNR removes transparency (of LLMNR) to the > application. > > 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. > archive: -- 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 12:30:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10242 for ; Mon, 16 Sep 2002 12:30:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qya9-000HQ3-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 09:18:41 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17qya6-000HPj-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 09:18:38 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GGIRxG025401; Mon, 16 Sep 2002 18:18:28 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GGIR0t025397; Mon, 16 Sep 2002 18:18:27 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 16 Sep 2002 18:18:27 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: bert hubert cc: Edward Lewis , Scott Rose , Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <20020916154248.GA2790@outpost.ds9a.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 16 Sep 2002, bert hubert wrote: > On Mon, Sep 16, 2002 at 05:25:13PM +0200, Roy Arends wrote: > > > > The problem is how do you protect answers that should have been > > > synthesized from a signed wildcard answer (which does not have to be > > > a delegation) > > > > cannot be a delegation (wildcard delegations are not legal). > > Neither are wildcard CNAMEs but you get roasted if you don't offer them. Apples and oranges, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 12:53:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11007 for ; Mon, 16 Sep 2002 12:53:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qyzq-000IgF-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 09:45:14 -0700 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 17qyzn-000Ifz-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 09:45:11 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with SMTP id g8GGj9v28584; Mon, 16 Sep 2002 18:45:09 +0200 (MEST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id SAA04757; Mon, 16 Sep 2002 18:45:08 +0200 Message-Id: <200209161645.SAA04757@grimsvotn.TechFak.Uni-Bielefeld.DE> To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-reply-to: Your message of "Mon, 16 Sep 2002 17:42:48 +0200." <20020916154248.GA2790@outpost.ds9a.nl> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Mon, 16 Sep 2002 18:45:05 +0200 From: Peter Koch X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bert hubert wrote: > > cannot be a delegation (wildcard delegations are not legal). > > Neither are wildcard CNAMEs but you get roasted if you don't offer them. while deviating from the thread a bit, may I ask you for a reference which supports either of these statements? Maybe there's plenty of work to be done to make '*'-NS-RRs actually work correctly as delegations (you'd have to generate the SOA RRs etc. and multi level '*' expansions will turn out to be hard), and maybe they don't make sense at all, but I wonder why they should be "not legal", i.e. not conforming to the DNS spec. And since '*'-PTR-RRs and '*'-A-RRs have been in use, what's so special about '*'-CNAME-RRs? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 13:31:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11877 for ; Mon, 16 Sep 2002 13:31:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qzWj-000K9f-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 10:19:13 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17qzWX-000K91-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 10:19:01 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 15A7228B01 for ; Mon, 16 Sep 2002 17:19:01 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from Edward Lewis of "Mon, 16 Sep 2002 10:33:20 -0400." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 16 Sep 2002 17:19:01 +0000 Message-Id: <20020916171901.15A7228B01@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The problem is that, when considering wildcards, ... ...DNSSEC ought not be used. C'mon, folks. We're already seven years into this. Let's cut the things that don't work and run with what's left. I posted my analysis of various uses for wildcards and showed why, imho, none of them intersect with a strong need for DNSSEC. I'm here today renewing my proposal: Signed zones shall not include RR's with wildcard names. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 14:22:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13286 for ; Mon, 16 Sep 2002 14:22:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r0O1-000Mt4-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 11:14:17 -0700 Received: from h140.s251.netsol.com ([216.168.251.140] helo=borg.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17r0Ny-000Mss-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 11:14:14 -0700 Received: (from markk@localhost) by borg.admin.cto.netsol.com (8.11.6/8.11.6) id g8GIA2S31276; Mon, 16 Sep 2002 14:10:02 -0400 Date: Mon, 16 Sep 2002 14:10:02 -0400 From: Mark Kosters To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes Message-ID: <20020916181002.GI5726@slam.admin.cto.netsol.com> References: <20020916171901.15A7228B01@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020916171901.15A7228B01@as.vix.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Sep 16, 2002 at 05:19:01PM +0000, Paul Vixie wrote: > ...DNSSEC ought not be used. > > C'mon, folks. We're already seven years into this. Let's cut the things > that don't work and run with what's left. I posted my analysis of various > uses for wildcards and showed why, imho, none of them intersect with a strong > need for DNSSEC. I'm here today renewing my proposal: > > Signed zones shall not include RR's with wildcard names. I agree with this. I hear what Olafur is saying about supporting wildcards but that can be done by synthesizing the response based off a wildcard defined in a configuration file. Mark -- Mark Kosters markk@verisignlabs.com Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 14:40:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13874 for ; Mon, 16 Sep 2002 14:40:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r0gJ-000NoQ-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 11:33:11 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17r0gB-000NoF-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 11:33:03 -0700 Received: from [128.177.194.102] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id ECA8B137F05; Mon, 16 Sep 2002 11:33:02 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 16 Sep 2002 11:34:05 -0700 Subject: Re: DNSSEXT Yokohama Minutes From: David Conrad To: Paul Vixie , namedroppers Message-ID: In-Reply-To: <20020916171901.15A7228B01@as.vix.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This will, I'm told by folks who run large zones (other than .COM), will result in DNSSEC not being deployed in those zones. Doesn't seem to be an optimal approach if we want DNSSEC deployed. Rgds, -drc On 9/16/02 10:19 AM, "Paul Vixie" wrote: >> The problem is that, when considering wildcards, ... > > ...DNSSEC ought not be used. > > C'mon, folks. We're already seven years into this. Let's cut the things > that don't work and run with what's left. I posted my analysis of various > uses for wildcards and showed why, imho, none of them intersect with a strong > need for DNSSEC. I'm here today renewing my proposal: > > Signed zones shall not include RR's with wildcard names. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 16:13:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16190 for ; Mon, 16 Sep 2002 16:13:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r257-0002Iz-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 13:02:53 -0700 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 3.36 #1) id 17r252-0002I1-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 13:02:48 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 6E45D3FC4; Mon, 16 Sep 2002 22:02:17 +0200 (CEST) Date: Mon, 16 Sep 2002 22:02:17 +0200 From: bert hubert To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes Message-ID: <20020916200217.GB4249@outpost.ds9a.nl> References: <20020916154248.GA2790@outpost.ds9a.nl> <200209161645.SAA04757@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209161645.SAA04757@grimsvotn.TechFak.Uni-Bielefeld.DE> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Sep 16, 2002 at 06:45:05PM +0200, Peter Koch wrote: > And since '*'-PTR-RRs and '*'-A-RRs have been in use, what's so special about > '*'-CNAME-RRs? A CNAME is not a normal RR and requires special attention. See the 'Algorithm' in RFC1034 and how it does not mention checking for wildcard CNAMEs. It may be interesting to document the actual algorithm used by PowerDNS and BIND. PowerDNS internally does a * ANY lookup when it hits the 'check for a wildcard' stage and retargets if the ANY record turned up a CNAME. This step is not present in RFC1034. Regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 18:10:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18655 for ; Mon, 16 Sep 2002 18:10:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r3vE-0008O3-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 15:00:48 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17r3v7-0008Nb-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 15:00:41 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GM0axG029157; Tue, 17 Sep 2002 00:00:36 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GM0Z6f029153; Tue, 17 Sep 2002 00:00:35 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 17 Sep 2002 00:00:34 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: David Conrad cc: Paul Vixie , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 16 Sep 2002, David Conrad wrote: > This will, I'm told by folks who run large zones (other than .COM), will > result in DNSSEC not being deployed in those zones. Could you phrase their concerns ? Or do you know if there are alternatives to their wildcard needs ? I'm looking for the case where wildcards are vital, and for which there is no alternative present. I can't think of any. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 18:40:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19279 for ; Mon, 16 Sep 2002 18:40:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r4T1-000AOK-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 15:35:43 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17r4Sy-000AO9-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 15:35:40 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id CF6B828B02 for ; Mon, 16 Sep 2002 22:35:37 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from David Conrad of "Mon, 16 Sep 2002 11:34:05 MST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 16 Sep 2002 22:35:37 +0000 Message-Id: <20020916223537.CF6B828B02@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> ... I'm here today renewing my proposal: >> >> Signed zones shall not include RR's with wildcard names. > > This will, I'm told by folks who run large zones (other than .COM), will > result in DNSSEC not being deployed in those zones. i either disagree or disbelieve, depending. > Doesn't seem to be an optimal approach if we want DNSSEC deployed. imho, wildcards will not change dnssec's deployment curve even a little bit. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 18:54:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19532 for ; Mon, 16 Sep 2002 18:54:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r4gP-000BAl-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 15:49:33 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17r4gM-000BAa-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 15:49:30 -0700 Received: from [128.177.194.102] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A5184137F05; Mon, 16 Sep 2002 15:49:29 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 16 Sep 2002 15:50:32 -0700 Subject: Re: DNSSEXT Yokohama Minutes From: David Conrad To: Roy Arends Cc: Paul Vixie , namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy, On 9/16/02 3:00 PM, "Roy Arends" wrote: > Could you phrase their concerns ? "We use wildards. Removing them would be annoying." -- a direct quote from someone at a RIPE meeting a while back. > I'm looking for the case where wildcards are vital, and for which there is > no alternative present. I can't think of any. Nor can I. However, does that matter? 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 19:04:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19666 for ; Mon, 16 Sep 2002 19:04:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r4l5-000BTW-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 15:54:23 -0700 Received: from mclmx.mail.saic.com ([149.8.64.10]) by psg.com with esmtp (Exim 3.36 #1) id 17r4l2-000BTK-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 15:54:20 -0700 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 18:54:09 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002091618540826076 ; Mon, 16 Sep 2002 18:54:08 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Mon, 16 Sep 2002 18:53:57 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2E3A@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Roy Arends'" Cc: namedroppers Subject: RE: DNSSEXT Yokohama Minutes Date: Mon, 16 Sep 2002 18:54:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > This will, I'm told by folks who run large zones (other > > than .COM), will result in DNSSEC not being deployed in > > those zones. > > Could you phrase their concerns ? Or do you know if there are > alternatives to their wildcard needs ? > > I'm looking for the case where wildcards are vital, and for > which there is no alternative present. I can't think of any. Roy-- I agree that I can't think of any case where there is no alternative available. However, from what little I know there are some folks who run very large numbers of "small" zones, and a few folks who run small numbers of "medium large" zones, who currently do use wildcards. The existence of an alternative to wildcards does not mean that the alternative will be used, unless those folks can in some way be convinced that wildcards are broken and must in fact be fixed. Since I don't see such convincing happening (it hasn't to date), if we tell them that they can't sign a zone with wildcards then they're quite likely to reply, "Okay we won't sign it." Then again, many of those folks are unlikely to sign those zones in the next five years regardless (IMHO), so I'm not sure we should let them tie things in knots. Perhaps David has a more complete and concrete answer. -- Rip Loomis Senior Systems Security Engineer SAIC Secure Business Solutions Group www.saic.com/securebiz Center for Information Security Technology www.cist-east.saic.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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 19:17:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19777 for ; Mon, 16 Sep 2002 19:17:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r4yw-000CIu-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 16:08:42 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17r4ys-000CIh-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 16:08:39 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GN8QxG032124; Tue, 17 Sep 2002 01:08:26 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GN8JPk032109; Tue, 17 Sep 2002 01:08:20 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 17 Sep 2002 01:08:18 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: David Conrad cc: Paul Vixie , namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 16 Sep 2002, David Conrad wrote: > Roy, > > On 9/16/02 3:00 PM, "Roy Arends" wrote: > > Could you phrase their concerns ? > > "We use wildards. Removing them would be annoying." -- a direct quote from > someone at a RIPE meeting a while back. Okay, I can imagine its annoying. But I don't think "annoying" is a strong case for keeping wildcards in DNSSEC. > > I'm looking for the case where wildcards are vital, and for which there is > > no alternative present. I can't think of any. > > Nor can I. However, does that matter? No, who cares what you or I can't think of. I just want to assess compelling and real arguments for keeping wildcards in DNSSEC ("annoying" is not one of them), since I don't have any right now. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 19:17:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19791 for ; Mon, 16 Sep 2002 19:17:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r54B-000Cbl-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 16:14:07 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17r548-000CbW-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 16:14:04 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 56D5028B01 for ; Mon, 16 Sep 2002 23:14:04 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from David Conrad of "Mon, 16 Sep 2002 15:50:32 MST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 16 Sep 2002 23:14:04 +0000 Message-Id: <20020916231404.56D5028B01@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I'm looking for the case where wildcards are vital, and for which > > there is no alternative present. I can't think of any. > > Nor can I. However, does that matter? yes, it does. "design" is a process involving both creativity and tradeoffs. in order to decide whether our seven year dnssec effort should be turned into an eight or nine year dnssec effort, we need to know exactly how important wildcards are and to whom. several of us here have asserted that there are workarounds for all common cases and that we can cut wildcards out of the dnssec specification with no actual loss of functionality. one of us has even enumerated the common cases. the onus is now on the other side of the argument. if there's a common case we've missed, or an uncommon case that's vital, then enumerate it. if our analysis of the common cases was faulty, then correct us. but don't just say "if we don't have wildcards, dnssec is not worth doing" because the argument has since moved to more detailed ground where actual facts are going to be required to keep it from ending in the "no wildcards in dnssec" mode. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 19:25:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19855 for ; Mon, 16 Sep 2002 19:25:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r59o-000D0i-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 16:19:56 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17r59k-000D0E-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 16:19:52 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 6DD2D28B01 for ; Mon, 16 Sep 2002 23:19:52 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from "Loomis, Rip" of "Mon, 16 Sep 2002 18:54:20 -0400." <3C1E3607B37295439F7C409EFBA08E680E2E3A@US-Columbia-CIST.mail.saic.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 16 Sep 2002 23:19:52 +0000 Message-Id: <20020916231952.6DD2D28B01@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I agree that I can't think of any case where there is no > alternative available. However, from what little I know there > are some folks who run very large numbers of "small" zones, > and a few folks who run small numbers of "medium large" zones, > who currently do use wildcards. The existence of an alternative > to wildcards does not mean that the alternative will be used, > unless those folks can in some way be convinced that wildcards > are broken and must in fact be fixed. for the case i think you're referring to, an apex DNAME is a better solution in any case. i volunteer to edit an i-d on the subject of "alternatives to wildcarding" if you (and everyone else here) will send me detailed cases to study. > Since I don't see such convincing happening (it hasn't to date), > if we tell them that they can't sign a zone with wildcards then > they're quite likely to reply, "Okay we won't sign it." Then > again, many of those folks are unlikely to sign those zones in > the next five years regardless (IMHO), so I'm not sure we should > let them tie things in knots. the quality (including simplicity if any) of the specification, and its timeliness, and the availability of good tools, are all going to have a much greater impact on the deployment curve than wildcarding. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 19:31:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19903 for ; Mon, 16 Sep 2002 19:31:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r5DV-000DDz-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 16:23:45 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17r5DR-000DDm-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 16:23:42 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GNNdxG001120; Tue, 17 Sep 2002 01:23:39 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8GNNcUj001116; Tue, 17 Sep 2002 01:23:38 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 17 Sep 2002 01:23:38 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: "Loomis, Rip" cc: namedroppers Subject: RE: DNSSEXT Yokohama Minutes In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E2E3A@US-Columbia-CIST.mail.saic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 16 Sep 2002, Loomis, Rip wrote: > > > This will, I'm told by folks who run large zones (other > > > than .COM), will result in DNSSEC not being deployed in > > > those zones. > > > > Could you phrase their concerns ? Or do you know if there are > > alternatives to their wildcard needs ? > > > > I'm looking for the case where wildcards are vital, and for > > which there is no alternative present. I can't think of any. > > Roy-- > I agree that I can't think of any case where there is no > alternative available. However, from what little I know there > are some folks who run very large numbers of "small" zones, > and a few folks who run small numbers of "medium large" zones, > who currently do use wildcards. The existence of an alternative > to wildcards does not mean that the alternative will be used, > unless those folks can in some way be convinced that wildcards > are broken and must in fact be fixed. > > Since I don't see such convincing happening (it hasn't to date), > if we tell them that they can't sign a zone with wildcards then > they're quite likely to reply, "Okay we won't sign it." Then > again, many of those folks are unlikely to sign those zones in > the next five years regardless (IMHO), so I'm not sure we should > let them tie things in knots. I'm not saying wildcards should be killed. I'm convinced that wildcard support makes the system more complex, but not impossible. I'm simply assessing arguments for and against it. Thanks, Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 21:37:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22169 for ; Mon, 16 Sep 2002 21:37:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r79o-000KIT-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 18:28:04 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17r79l-000KIH-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 18:28:01 -0700 Received: from [128.177.194.102] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 72FA7137F03; Mon, 16 Sep 2002 18:27:58 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 16 Sep 2002 18:29:02 -0700 Subject: Re: DNSSEXT Yokohama Minutes From: David Conrad To: Paul Vixie , namedroppers Message-ID: In-Reply-To: <20020916231404.56D5028B01@as.vix.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9/16/02 4:14 PM, "Paul Vixie" wrote: > several of us here have asserted that there are workarounds for all common > cases and that we can cut wildcards out of the dnssec specification with no > actual loss of functionality. one of us has even enumerated the common cases. > > the onus is now on the other side of the argument. Hmmm. Way back in a previous life when I was trying to encourage people to use DNSSEC and I mentioned BIND didn't support signing zones with wildcards in them, the vast majority of responses were along the lines of "too much of a hassle to redo the way we're doing business, particularly as we haven't seen any attacks that DNSSEC would have helped against, so I guess we won't be signing our zones". Perhaps times have changed and the folks who host zones with wildcards in them might consider taking the onus upon themselves to argue as you assert they must. Or perhaps not. Particularly given those folks are not likely to found on namedroppers. Seems to me if you want to keep DNSSEC from ever getting deployed, then creating yet another barrier to entry by removing wildcards is a step in the right direction. 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. archive: From owner-namedroppers@ops.ietf.org Mon Sep 16 23:16:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23783 for ; Mon, 16 Sep 2002 23:16:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r8hq-0000GN-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 20:07:18 -0700 Received: from [2002:4051:3012:1fff::dead:beef] (helo=pianosa.catch22.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 17r8hn-0000GC-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 20:07:15 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 2230D12; Mon, 16 Sep 2002 20:07:13 -0700 (PDT) Date: Mon, 16 Sep 2002 20:07:13 -0700 From: David Terrell To: namedroppers Subject: Re: DNSSEXT Yokohama Minutes Message-ID: <20020917030712.GA22251@pianosa.catch22.org> Reply-To: David Terrell References: <20020916231404.56D5028B01@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020916231404.56D5028B01@as.vix.com> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 4:29PM up 7 days, 4:30, 51 users, load averages: 1.31, 0.89, 0.68 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Sep 16, 2002 at 11:14:04PM +0000, Paul Vixie wrote: > the onus is now on the other side of the argument. if there's a common case > we've missed, or an uncommon case that's vital, then enumerate it. if our > analysis of the common cases was faulty, then correct us. but don't just > say "if we don't have wildcards, dnssec is not worth doing" because the > argument has since moved to more detailed ground where actual facts are > going to be required to keep it from ending in the "no wildcards in dnssec" > mode. If I'm a major website that puts different content under different DNS names, it sure would be nice to catch misspellings and try to redirect them to an appropriate page without turning an 8 name zone into a 500 name zone. Cuts down on the NXT record generation, for one thing. I would, however, like to be able to secure the records in this zone, so that my server addresses can't be spoofed. How about this: "A signed zone with a signed wildcard SHOULD NOT have any unsecured labels." That eliminates any funny business. You're not going to put a * record in .com anyway. I thought that partially secured zones were mostly a "only use this if you have a real reason to" thing anyway. -- David Terrell | If a crypto algorithm is cracked in a forest Nebcorp Prime Minister | and a tree falls on a mime, does microsoft dbt@meat.net | need to publish an advisory on it? http://wwn.nebcorp.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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 00:18:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24626 for ; Tue, 17 Sep 2002 00:18:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r9fC-000425-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 21:08:38 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17r9f8-00041u-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 21:08:34 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id D789E28B01 for ; Tue, 17 Sep 2002 04:08:31 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from David Conrad of "Mon, 16 Sep 2002 18:29:02 MST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 17 Sep 2002 04:08:31 +0000 Message-Id: <20020917040831.D789E28B01@as.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Way back in a previous life when I was trying to encourage people to use > DNSSEC and I mentioned BIND didn't support signing zones with wildcards in > them, the vast majority of responses were along the lines of "too much of a > hassle to redo the way we're doing business, particularly as we haven't seen > any attacks that DNSSEC would have helped against, so I guess we won't be > signing our zones". that turned out to be a good thing, too. those folks might've ended up using pre-DS, or using RSA keys, or any of the other things that dnsext/dnssec has sent to the IESG even though we clearly weren't done baking them yet. but more fundamentally, i dispute that lack of wildcarding has ever stopped anyone, even one user, from signing a zone that they would otherwise have signed. and also, a continued lack of wildcarding will not stop anyone from signing a zone that they otherwise want to sign. whether they otherwise want to sign or not is the important question, and that will have to do with factors like a stable specification, decent tools, useful documentation, and a sense that other people are actually using this stuff. > Perhaps times have changed and the folks who host zones with wildcards in > them might consider taking the onus upon themselves to argue as you assert > they must. > > Or perhaps not. Particularly given those folks are not likely to found on > namedroppers. i think name service providers (such as nominum, ultradns, and lots of others) have employees on this list who know what their customers are using DNS for, and that this is a fine place to do "feature research" of this kind. but if you know of another place, please suggest it. > Seems to me if you want to keep DNSSEC from ever getting deployed, > then creating yet another barrier to entry by removing wildcards is a > step in the right direction. in december, in salt lake city, the DS plan was hatched and campaigned for, and my support for it (as well as for opt-in) was contingent on a quick close. that hasn't happened. best case, it'll be december -- a full year later -- before we're done arguing about how to prove the unknown (sign wildcards) and are ready to ask IESG for a last call on some form of dnssec, with or without opt-in but probably with DS. unless someone comes forward and says "here is a case of wildcard usage for which there is no workaround, and here's why the kind of zone or user who needs it is critical to the success of a dnssec rollout" then there is just no basis for continuing the argument. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 01:35:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25936 for ; Tue, 17 Sep 2002 01:35:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rAr9-0008ox-00 for namedroppers-data@psg.com; Mon, 16 Sep 2002 22:25:03 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17rAr3-0008nr-00 for namedroppers@ops.ietf.org; Mon, 16 Sep 2002 22:24:58 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8H5OsB5051357; Tue, 17 Sep 2002 15:24:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200209170524.g8H5OsB5051357@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers From: Mark.Andrews@isc.org Subject: Re: DNSSEXT Yokohama Minutes In-reply-to: Your message of "Tue, 17 Sep 2002 04:08:31 GMT." <20020917040831.D789E28B01@as.vix.com> Date: Tue, 17 Sep 2002 15:24:54 +1000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,PORN_10 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > unless someone comes forward and says "here is a case of wildcard usage for > which there is no workaround, and here's why the kind of zone or user who > needs it is critical to the success of a dnssec rollout" then there is just > no basis for continuing the argument. Well gatewaying of ACSNet mail (*.oz.au) would have been such a case. No node in ACSNet knew all the other nodes so it was impossible to enumerate the space. However not being able to spoof the wild card MX's would have prevented mail being intercepted. To mail to foo.bar.xxx.oz.au you only needed to know how to reach a machine in xxx.oz.au. You had to ensure that one of you machines was visible but not all of your machines. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 04:25:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07449 for ; Tue, 17 Sep 2002 04:25:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rDTt-000JDh-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 01:13:13 -0700 Received: from dhcp11.freenet.ams.attingo.nl ([212.123.202.101] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rDTM-000JC4-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 01:12:41 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rDTI-0003pU-00; Tue, 17 Sep 2002 11:12:36 +0300 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes References: <20020916171901.15A7228B01@as.vix.com> Message-Id: Date: Tue, 17 Sep 2002 11:12:36 +0300 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Signed zones shall not include RR's with wildcard names. unfortunately this won't fly. enum alone has a serious need for it. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 05:17:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08259 for ; Tue, 17 Sep 2002 05:17:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rEJb-000MTc-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 02:06:39 -0700 Received: from [202.28.97.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17rEJ4-000MPl-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 02:06:06 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8H957t08623; Tue, 17 Sep 2002 16:05:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8H94HK13458; Tue, 17 Sep 2002 16:04:32 +0700 (ICT) From: Robert Elz To: bert hubert cc: Roy Arends , Edward Lewis , Scott Rose , namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <20020916154248.GA2790@outpost.ds9a.nl> References: <20020916154248.GA2790@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Sep 2002 16:04:17 +0700 Message-ID: <13456.1032253457@munnari.OZ.AU> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 16 Sep 2002 17:42:48 +0200 From: bert hubert Message-ID: <20020916154248.GA2790@outpost.ds9a.nl> | | > cannot be a delegation (wildcard delegations are not legal). | Neither are wildcard CNAMEs but you get roasted if you don't offer them. From exactly where do people dream up these restrictions? There's absolutely nothing wrong with a wildcard CNAME, nor is there any reason for there to be. Having one would mean that you couldn't have any other wildcard RR in the zone, because the owner of a CNAME can't have any other data, but a wildcard CNAME is a perfectly sensible thing to have (its the cheap way to direct all (not otherwise defined) sub-domains of a domain to the same target, for all uses). Nor is there anything illegal about a wildcard NS. Actually making it work is tricky (which might be an understatement) - that is, in making sure the servers named actually implement the zone in question, but there's nothing illegal as such about delegations to servers that have never head of the zone, that (lame delegations) - happens all the time - and one could construct a server that would generate a zone on the fly when queried about it - provided the rules by which that was done were consistent between all servers for a zone, that would make wildcard NS records perfectly feasible (if most likely not very useful). The only RR type that cannot possibly be matched by a wildcard, is SOA. (Or at least the only one in 1034/5 vintage DNS, what happens to the dnssec RR's, and the even odder ones like OPT aren't important here). That's because wildcards never apply to names that are known to exist, whereas the only place SOA is permitted is at the head of a zone, which by definition is known to exist. Any of the rest of the "normal" RRs can be attached to a wildcard however. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 05:51:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08773 for ; Tue, 17 Sep 2002 05:51:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rErb-000OaD-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 02:41:47 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17rEr4-000OZr-00; Tue, 17 Sep 2002 02:41:14 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8H9fBR8009431; Tue, 17 Sep 2002 11:41:11 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8H9fB2Y009427; Tue, 17 Sep 2002 11:41:11 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 17 Sep 2002 11:41:10 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Randy Bush cc: Paul Vixie , Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 17 Sep 2002, Randy Bush wrote: > > Signed zones shall not include RR's with wildcard names. > > > > unfortunately this won't fly. enum alone has a serious need > for it. The enum WG is well aware that the use of wildcard NAPTR RRs are A Bad Thing. They seriously advice against it, and advice to simply enumerate every number that is in the repository of the zone. Regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 06:07:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09167 for ; Tue, 17 Sep 2002 06:07:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rF8b-000Pi7-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 02:59:21 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17rF85-000PeY-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 02:58:49 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8H9wJR8009626; Tue, 17 Sep 2002 11:58:20 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8H9wJBG009622; Tue, 17 Sep 2002 11:58:19 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 17 Sep 2002 11:58:19 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Robert Elz cc: bert hubert , Edward Lewis , Scott Rose , Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <13456.1032253457@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 17 Sep 2002, Robert Elz wrote: > Date: Mon, 16 Sep 2002 17:42:48 +0200 > From: bert hubert > Message-ID: <20020916154248.GA2790@outpost.ds9a.nl> > > | | > cannot be a delegation (wildcard delegations are not legal). > | Neither are wildcard CNAMEs but you get roasted if you don't offer them. > > >From exactly where do people dream up these restrictions? .... > Nor is there anything illegal about a wildcard NS. Actually making it > work is tricky (which might be an understatement) - that is, in making > sure the servers named actually implement the zone in question, but there's > nothing illegal as such about delegations to servers that have never head of > the zone, that (lame delegations) - happens all the time - and one could > construct a server that would generate a zone on the fly when queried about > it - provided the rules by which that was done were consistent between > all servers for a zone, that would make wildcard NS records perfectly > feasible (if most likely not very useful). I find this highly unlikely. An NS record is not authoritative in a parent zone, i.e. they point outside the zone (they are authoritative elsewhere). Wildcards are _within_ a zone, (they are within the authoritative part). I quote: The owner name of the wildcard RRs is of the form "*.", where is any domain name. should not contain other * labels, and should be in the authoritative data of the zone. Wildcard RRs do not apply: - When the query is in another zone. That is, delegation cancels the wildcard defaults. Sure, this is all theoretical, and you could hack up a server which allows you to do this. That does not make it legal. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 06:44:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09767 for ; Tue, 17 Sep 2002 06:44:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rFfK-0001pe-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 03:33:10 -0700 Received: from [202.28.97.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17rFch-0001aT-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 03:31:03 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8H8iHt22625; Tue, 17 Sep 2002 15:44:33 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8H8hXK13406; Tue, 17 Sep 2002 15:43:52 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Erik Nordmark , namedroppers@ops.ietf.org Subject: Re: mDNS/LLMNR and "local.arpa" In-Reply-To: <20020916151838.495BA4B23@coconut.itojun.org> References: <20020916151838.495BA4B23@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Sep 2002 15:43:33 +0700 Message-ID: <13404.1032252213@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 17 Sep 2002 00:18:36 +0900 From: itojun@iijlab.net Message-ID: <20020916151838.495BA4B23@coconut.itojun.org> | that is certainly one possibility, but why do we need it when we don't | have AI_NIS? AI_LLMNR removes transparency (of LLMNR) to the | application. We don't really. We also don't need .local.arpa (or .local or whatever) just as we don't have .nis.arpa or .nis (or whatever) (nor do we have a hosts.arpa or a .hosts or anything else for any other kind of hostname lookup that might exist). We already have disjointed namespaces, all considered equal, where a name lookup gets satisfied by one (seemingly at random, but actually as configured for the node's lookup order). Adding one more name lookup mechanism changes nothing. Most nodes are going to do DNS lookups first (or attempt them), and then if there is no DNS server, or it fails, fall back to whatever lookup mechanism suits (some sites prefer to insert some locally configured names ahead of the DNS - I doubt doing that for a local multicast lookup would ever make sense). 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 08:43:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12547 for ; Tue, 17 Sep 2002 08:43:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rHTi-00095H-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 05:29:18 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17rHTB-00091a-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 05:28:45 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8HCSlRF067193 for ; Tue, 17 Sep 2002 08:28:47 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA12365; Tue, 17 Sep 2002 08:28:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Tue, 17 Sep 2002 08:28:42 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wildcards, dnssec, and opt-in Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=3.2 required=5.0 tests=OPT_IN,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As far as whether wild cards stay or go, I think it is up to the users of DNS to determine, not the protocol designers. Whether they are a pain or not, if the use of wild cards is deemed necessary, it is up to the engineers to answer the requirement. Pre-BIND 8, when a small group of us were struggling to write the first DNSSEC code we came upon a feature that made validating answers problematic. Round robining of answers was a stumbling block - because it meant having to reorder the RR's for validation. There was an internal proposal then to make users of DNSSEC turn off round robining so that the DNSSEC code wouldn't have to copy and sort before validating. Eventually, it was determined that round robining is a requirement and DNSSEC will just have to deal with it. I think the same applies to wild cards. If opt-in is to be adopted, it too will have to deal with wild cards. If there's a choice between wild cards and opt-in, I'd have to lean in favor of wild cards as I see that wild cards as a requirement. Yes, some feel that opt-in is a requirement for deployment in large zones. Although I'm pressing for DNSSEC to succeed, if in doing so it causes harm to the legacy of DNS, perhaps DNSSEC is better off not being deployed. (If that's the case, we better start on DNS2010.) Keep in mind that the issues being bickered about here are unusual cases. Most zones are one label deep. Most uses of wild cards are simplistic. Most zones don't even use wild cards. Will any zone that is a candidate for opt-in want to have a wild card? But complicated uses do exist. What we need to keep in mind is that the solution we generate needs to work best for the majority of cases and work in some fashion for all cases. I personally fail to see the difficulty caused by wild cards, especially for DNSSEC. They are tedious perhaps, but the algorithms to process them are deterministic, decidable, and will terminate. With opt-in, I think there's a choice to be made, whether an unsigned (opted-out) domain name is matched before a signed wild card. If we choose one of the options, and no other "corner cases" are found, we should be again in the situation of a decidable algorithm that perhaps takes time - but will terminate. (Worried about amplification as a springboard for a DOS? I don't have an answer to that without looking at the algorithm and the potential for triggering it.) Remember that we can imagine really weird uses of wild cards, CNAMEs, DNSSEC, etc., but for the most part these engineer-dreamed scenarios do not occur in the wild. Cover the odd-ball cases, but let's just optimize on the cases that are actually used in nature. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 09:10:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13707 for ; Tue, 17 Sep 2002 09:10:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rHxj-000B6I-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 06:00:19 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17rHxB-000B4G-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 05:59:47 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8HAJdt07313; Tue, 17 Sep 2002 17:19:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8HAJIK13984; Tue, 17 Sep 2002 17:19:31 +0700 (ICT) From: Robert Elz To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: dynamic update zone In-Reply-To: <20020915141428.87CC818A0@thrintun.hactrn.net> References: <20020915141428.87CC818A0@thrintun.hactrn.net> <20020913183732.000211915@thrintun.hactrn.net> <00cd01c25a91$e5f917e0$b9370681@BARNACLE> <007c01c25b1f$4ac2cf30$b9370681@BARNACLE> <6145.1032070800@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Sep 2002 17:19:18 +0700 Message-ID: <13982.1032257958@munnari.OZ.AU> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sun, 15 Sep 2002 10:14:27 -0400 From: Rob Austein Message-ID: <20020915141428.87CC818A0@thrintun.hactrn.net> | I think we need to distinguish between server errors and data errors. | RCODE=3 is a property of the zone, RCODE=5 is a server error. I think that's too fine a hair to cut. Certainly if you get a 3 from any server, you should get it from all, hence there's no point trying a different server, whereas that isn't true of 2, 4, or 5. But I'm not sure that really matters. The client (resolver) already needs to know to treat the different errors differently, adding an explicit TTL to the error response doesn't really change the nature of anything. It may seem that using the OPT RR, which at first glance, carries only server specific information to carry information which is a property of the zone instead would not be a good fit. Except that it is already specified to be able to carry information that is the property of the zone - the extra bits of the error number (rcode) can be used to convey either kind of error (as defined in the future). So might the flag bits. OPT is best thought of as just a part of the DNS header - and just as the DNS header RCODE can carry server specific, and zone specific, error codes, there's no reason why a error-ttl field in the OPT RR shouldn't be able to hold either server specific, or zone specific, ttls. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 09:18:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13928 for ; Tue, 17 Sep 2002 09:18:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rI8U-000ByI-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 06:11:26 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17rI8Q-000Bxo-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 06:11:22 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8HCS6t16236; Tue, 17 Sep 2002 19:28:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8HCRsK14383; Tue, 17 Sep 2002 19:27:54 +0700 (ICT) From: Robert Elz To: Roy Arends cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Sep 2002 19:27:54 +0700 Message-ID: <14381.1032265674@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 17 Sep 2002 11:58:19 +0200 (CEST) From: Roy Arends Message-ID: | I find this highly unlikely. Yes, of all the possible RR types, wanting to wildcard NS is perhaps the least likely. | An NS record is not authoritative in a parent zone, i.e. they point | outside the zone (they are authoritative elsewhere). Wildcards are | _within_ a zone, (they are within the authoritative part). I quote: Yes, but ... | The owner name of the wildcard RRs is of the form "*.", | where is any domain name. should not contain | other * labels, and should be in the authoritative data of the zone. Note it is that has to be in the authoritative data for the zone, not the foo.anydomain that is being looked up. That restriction has no relevance at all. | Wildcard RRs do not apply: | | - When the query is in another zone. That is, delegation cancels | the wildcard defaults. This one is more borderline, but I certainly can't convince myself that it actually means that wildcard NS is illegal. I'm not actually sure what that one is for, especially if wildcard NS were illegal, as then the delegation would create a "known" name, and it is clear that wildcards never match known names, or their sub-domains, so if wildcard NS was illegal, that rule wouldn't be needed at all. The only situation that I can imagine where that restriction would apply, would be if we had $ORIGIN example.com. * IN NS server.whatever. IN NS other.thing. and a lookup came for a.b.example.com. Then the paragraph above would indicate that the '*' there matches b.example.com, and that making a delegation, cancels the wildcard defaults, so the correct response is a referral to server.whatever and other.thing, rather than to return a.b.example.com. IN NS server.whatever. (etc). as one would normally do if it were a wildcard MX, or A, or something. I'm not about to fault any servers that don't implement wildcard NS records, but I really don't think they're illegal according to the specs (just useless for most practical purposes). kre ps: I really did go and re-check 1034 before I replied the first time... pps: I have no direct opinion on the question of whether or not wildcards should be declared incompatible with signed zones. I do know that I see no merit at all in the line of argument that goes "we cannot do X, as person or group Y won't like it". If you suspect that to be true, tell Y about the proposal, and ask for reasoned responses to the namedroppers list. That way we get first hand responses, from the people it (perhaps) actually matters to, rather than someone's perhaps misinformed opinion of what some 3rd party's needs are. [Roy: this ps is not aimed at 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 09:18:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13945 for ; Tue, 17 Sep 2002 09:18:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rI5Q-000BkF-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 06:08:16 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17rI5L-000Bj4-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 06:08:12 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8HD7lt14732; Tue, 17 Sep 2002 20:07:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8HD7PK14699; Tue, 17 Sep 2002 20:07:30 +0700 (ICT) From: Robert Elz To: Aidan Williams cc: itojun@iijlab.net, Erik Nordmark , namedroppers@ops.ietf.org Subject: Re: mDNS/LLMNR and "local.arpa" In-Reply-To: <3D871D36.1060805@motorola.com> References: <3D871D36.1060805@motorola.com> <20020916151838.495BA4B23@coconut.itojun.org> <13404.1032252213@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Sep 2002 20:07:25 +0700 Message-ID: <14697.1032268045@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 17 Sep 2002 22:16:54 +1000 From: Aidan Williams Message-ID: <3D871D36.1060805@motorola.com> | So you would be happy with a LLMNR lookup succeeding | for "www.ietf.org"? Yes, of course, in fact, that might often be exactly what I'd want to happen, any time it actually succeeded. Note, that unless I'm insane (in which case you probably should ignore this opinion), that won't even get a chance to succeed unless the DNS isn't available at all. If there's no DNS, and I'm expecting www.ietf.org to work, then I think I would want it to... And where that might be useful, is where I make a local mirror of the IETF site, then if my net connection is missing, or similar, and the DNS isn't working, I'd want to get to my local mirror, and being able to find it using LLMNR (or something) sounds like a win to me. That also has the advantage that I use the real site when it is available, avoid possible staleness with my slow update mirror (which is still better than nothing if necessary). Yes, there are security issues to be handled, but if we assume that we start using dnssec sometime this century, then multicast lookups will likely be distinguished as not being properly signed. Sticking a funny domain on the end won't solve anything - I'd configure my search list to include it anyway (so I can refer to "foo") and that means that (unless I happen to do "www.ietf.org.") the resolver is eventually likely to try www.ietf.org.local.arpa. as the lookup for me, and then it would go find the multicast version anyway (a hacker would just be pretending to be that, instead of www.oetf.org - the A record that comes back to my browser works the same either way). If we had to have a restriction, "names with no dots" would be the only reasonable one - but I really believe that's unnecessarily limiting, for no real gain that 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 10:18:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16249 for ; Tue, 17 Sep 2002 10:18:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rIx0-000FfB-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 07:03:38 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17rIwt-000Feu-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 07:03:31 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08613; Tue, 17 Sep 2002 08:03:29 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8HE3SA07562; Tue, 17 Sep 2002 16:03:28 +0200 (MEST) Date: Tue, 17 Sep 2002 13:27:51 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: mDNS/LLMNR and "local.arpa" To: itojun@iijlab.net Cc: Erik Nordmark , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <20020916151838.495BA4B23@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > that is certainly one possibility, but why do we need it when we don't > have AI_NIS? AI_LLMNR removes transparency (of LLMNR) to the > application. That is a different question than the one I chose to answer. You seemed to initially be concerned that there wasn't an easy way to add such support to the getaddrinfo/getnameinfo APIs, and hopefully I managed to dispell that concern. The reason I think AI_NIS (or AI_LDAP, etc) is that the intent is that they all be managed with the intent of providing a consistent appearance. So if a name exists in NIS and the same name exists in DNS, the intent of the common adminstration is that those name refer to the same device. This is very different than the LLMNR vs. DNS case, where the intent is that nodes be able to create there own names in the LLMNR name space. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 10:56:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17741 for ; Tue, 17 Sep 2002 10:56:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rJhg-000Is2-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 07:51:52 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17rJhd-000Irr-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 07:51:49 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g8HEpjQl016204; Tue, 17 Sep 2002 07:51:45 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Tue, 17 Sep 2002 07:53:41 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869BB8@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Edward Lewis'" , namedroppers@ops.ietf.org Subject: RE: wildcards, dnssec, and opt-in Date: Tue, 17 Sep 2002 07:53:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If opt-in is to be adopted, it too will have to deal with wild cards. > If there's a choice between wild cards and opt-in, I'd have to lean > in favor of wild cards as I see that wild cards as a requirement. I believe that the ability to deploy in .com, .net and .org is a requirement. Unless the protocol is fixed there is no way that DNSSEC should go to the IESG. DNSSEC in its current form is BROKEN. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 11:58:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19986 for ; Tue, 17 Sep 2002 11:58:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rKZu-000M0j-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 08:47:54 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17rKZq-000M0V-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 08:47:50 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA28693; Tue, 17 Sep 2002 11:47:46 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA09531; Tue, 17 Sep 2002 11:47:46 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18550; Tue, 17 Sep 2002 11:47:45 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id LAA04052; Tue, 17 Sep 2002 11:47:45 -0400 Subject: Re: wildcards, dnssec, and opt-in From: Greg Hudson To: Edward Lewis Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 17 Sep 2002 11:47:45 -0400 Message-Id: <1032277665.3850.15.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,OPT_IN,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2002-09-17 at 08:28, Edward Lewis wrote: > As far as whether wild cards stay or go, I think it is up to the > users of DNS to determine, not the protocol designers. Whether they > are a pain or not, if the use of wild cards is deemed necessary, it > is up to the engineers to answer the requirement. When security is on the line, it is reasonable for engineers to draw the line at a feature which provides nothing of substance. I would rather have 30% deployment of a DNSSEC which is simple enough to actually be secure than 100% deployment of a DNSSEC which is too complicated to evaluate. (Not that I think wildcards would account for a 70% swing.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 12:40:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21115 for ; Tue, 17 Sep 2002 12:40:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rLHx-000Oeb-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 09:33:25 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17rLHu-000OeQ-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 09:33:22 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g8HGXLJ07785; Tue, 17 Sep 2002 09:33:21 -0700 (PDT) From: Bill Manning Message-Id: <200209171633.g8HGXLJ07785@boreas.isi.edu> Subject: DS and the deployed base To: namedroppers@ops.ietf.org, dnssec@cafax.se Date: Tue, 17 Sep 2002 09:33:21 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning) X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Something for the DNS cabal to ruminate on.... In the little testbed we are running, the following behaviour popped up. Feel free to interpret as you will. --------------------------------------------- From a testbed user: --- Here are my observations: Appearently the problem is in the recursive bind (i.e. mine). A tcpdump shows that all the roots return the correct data, butt bind 9.2.1 seems to get confused by the presence of a NXT and/or SIG Record and then ignoring the NS-Records. And it is not a problem of my dig, since the OS Resolver shows the same behaviour. So i will fetch a Snapshot of the bind release and then see if that changes anything. ... Hello, So, my problem appears to be a bug when querying the Root with a bind 9.2.1 Recursive DNS Server. I now upgraded to 9.3.0s20020722 and I get the proper answers: --- Does this indicate that the "flag-day" may have much broader impact that one might have originally thought? --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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 13:40:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23089 for ; Tue, 17 Sep 2002 13:40:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rMBH-00020p-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 10:30:35 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17rMBE-00020d-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 10:30:32 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 6A75228B01; Tue, 17 Sep 2002 17:30:31 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org, dnssec@cafax.se Subject: Re: DS and the deployed base In-Reply-To: Message from Bill Manning of "Tue, 17 Sep 2002 09:33:21 MST." <200209171633.g8HGXLJ07785@boreas.isi.edu> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 17 Sep 2002 17:30:31 +0000 Message-Id: <20020917173031.6A75228B01@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So, my problem appears to be a bug when querying the Root with a bind > 9.2.1 Recursive DNS Server. > > I now upgraded to 9.3.0s20020722 and I get the proper answers: > > Does this indicate that the "flag-day" may have much > broader impact that one might have originally thought? according to published reports, bind8 is the most popular dns implementation now in use, followed by bind4, followed by microsoft. the fact that an interrim bind9 release didn't handle NXT RR's correctly is of very little significance, since people who run bind9 at all are very susceptible to upgrading it when they hear that a new release is available. now, if you've got data concerning bad behaviour from bind8, bind4, or microsoft, then we should be considering that in light of flag days et al. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 13:59:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23972 for ; Tue, 17 Sep 2002 13:59:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rMUH-0003E8-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 10:50:13 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17rMUB-0003DZ-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 10:50:07 -0700 Received: from [128.177.194.102] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E282B137F05; Tue, 17 Sep 2002 10:50:06 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 17 Sep 2002 10:51:09 -0700 Subject: Re: DNSSEXT Yokohama Minutes From: David Conrad To: Paul Vixie , namedroppers Message-ID: In-Reply-To: <20020917040831.D789E28B01@as.vix.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, On 9/16/02 9:08 PM, "Paul Vixie" wrote: > but more fundamentally, i dispute that lack of wildcarding has ever stopped > anyone, even one user, from signing a zone that they would otherwise have > signed. I am not saying it has. What I am saying is that removal of functionality from the DNS that people use today is going to impede the deployment of DNSSEC in the future. > in december, in salt lake city, the DS plan was hatched and campaigned for, > and my support for it (as well as for opt-in) was contingent on a quick close. > that hasn't happened. best case, it'll be december -- a full year later -- > before we're done arguing about how to prove the unknown (sign wildcards) It is not unknown. There is at least one implementation that fully supports wildcards in DNSSEC. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 14:03:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24099 for ; Tue, 17 Sep 2002 14:03:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rMYr-0003UU-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 10:54:57 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17rMYo-0003U8-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 10:54:54 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g8HHsqd15635; Tue, 17 Sep 2002 10:54:52 -0700 (PDT) From: Bill Manning Message-Id: <200209171754.g8HHsqd15635@boreas.isi.edu> Subject: Re: DS and the deployed base In-Reply-To: <20020917173031.6A75228B01@as.vix.com> from Paul Vixie at "Sep 17, 2 05:30:31 pm" To: paul@vix.com (Paul Vixie) Date: Tue, 17 Sep 2002 10:54:52 -0700 (PDT) Cc: namedroppers@ops.ietf.org, dnssec@cafax.se X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % > So, my problem appears to be a bug when querying the Root with a bind % > 9.2.1 Recursive DNS Server. % > % > I now upgraded to 9.3.0s20020722 and I get the proper answers: % > % > Does this indicate that the "flag-day" may have much % > broader impact that one might have originally thought? % % according to published reports, bind8 is the most popular dns implementation % now in use, followed by bind4, followed by microsoft. the fact that an % interrim bind9 release didn't handle NXT RR's correctly is of very little % significance, since people who run bind9 at all are very susceptible to % upgrading it when they hear that a new release is available. % % now, if you've got data concerning bad behaviour from bind8, bind4, or % microsoft, then we should be considering that in light of flag days et al. % % -- % to unsubscribe send a message to namedroppers-request@ops.ietf.org with % the word 'unsubscribe' in a single line as the message text body. % archive: % Investigating. --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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 14:53:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26033 for ; Tue, 17 Sep 2002 14:53:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNJF-0006dg-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 11:42:53 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17rNJB-0006dU-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 11:42:49 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8HIgnRF092228 for ; Tue, 17 Sep 2002 14:42:49 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA06449 for ; Tue, 17 Sep 2002 14:42:48 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <1032277665.3850.15.camel@error-messages.mit.edu> References: <1032277665.3850.15.camel@error-messages.mit.edu> Date: Tue, 17 Sep 2002 14:42:47 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wildcards, dnssec, and opt-in Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Looking at "wild cards vs. dnssec" it seems to me that the issue is that wild cards makes achieving the service of authenticated denial a bit harder than the non wild card case. Wild cards do not complicate the security of explicitly-there data. What I would like to know is how widely practiced is the use of multi-label depth wild cards? If these are not that widely deployed, then using a clunky, non-scaleable solution to the issue is acceptable. I'd like to see completeness of the security coverage, and if this means that multi-label depth wild cards suffer - so much more the incentive to limit their use. I don't believe that we will come down to having to make a hard choice between wild cards and dnssec. I fail to see how wild cards, even with the complexity of multi-label depth situations, create a situation that is undecidable. I think that there may be ugly situations for the odd ball cases, but I think that odd ball cases are rare enough that they deserve to bite the bullet in this case. As far as opt-in vs. wild cards, I don't know yet. Is anyone prototyping a server that implements opt-in so that we can take shots at it? I think that would do us a lot more good than continually haggling over words in mail and the specs. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 15:21:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26983 for ; Tue, 17 Sep 2002 15:21:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNeo-0008R9-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 12:05:10 -0700 Received: from [216.155.166.225] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rNef-0008OQ-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 12:05:05 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rNbw-0003uq-00; Tue, 17 Sep 2002 22:02:12 +0300 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Roy Arends Cc: David Conrad , Paul Vixie , namedroppers Subject: Re: DNSSEXT Yokohama Minutes References: Message-Id: Date: Tue, 17 Sep 2002 22:02:12 +0300 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I'm looking for the case where wildcards are vital, and for which there is > no alternative present. I can't think of any. *.3.3.e164.arpa NAPTR ...ldap... 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 15:23:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27065 for ; Tue, 17 Sep 2002 15:23:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNqH-0009K5-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 12:17:01 -0700 Received: from [216.155.166.225] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rNqC-0009Jg-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 12:16:57 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rNlX-0003xK-00; Tue, 17 Sep 2002 22:12:07 +0300 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Roy Arends Cc: Paul Vixie , Subject: Re: DNSSEXT Yokohama Minutes References: Message-Id: Date: Tue, 17 Sep 2002 22:12:07 +0300 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The enum WG is well aware that the use of wildcard NAPTR RRs are A Bad > Thing. They seriously advice against it, and advice to simply enumerate > every number that is in the repository of the zone. that's really gonna work great for anything larger then andora 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 15:24:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27146 for ; Tue, 17 Sep 2002 15:24:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNrO-0009QJ-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 12:18:10 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17rNrC-0009O6-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 12:17:58 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 28ED328B02 for ; Tue, 17 Sep 2002 19:17:58 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: Message from Randy Bush of "Tue, 17 Sep 2002 22:12:07 +0300." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 17 Sep 2002 19:17:58 +0000 Message-Id: <20020917191758.28ED328B02@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > The enum WG is well aware that the use of wildcard NAPTR RRs are A Bad > > Thing. They seriously advice against it, and advice to simply enumerate > > every number that is in the repository of the zone. > > that's really gonna work great for anything larger then andora that's off-topic for us. anyone who wants to change the way enum works should issue their opinions over on the enum wg's list. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 15:24:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27181 for ; Tue, 17 Sep 2002 15:24:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNqO-0009Lc-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 12:17:08 -0700 Received: from [216.155.166.225] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rNqF-0009Jg-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 12:17:02 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rNnn-0003yn-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 22:14:27 +0300 Message-ID: <3D871D36.1060805@motorola.com> MIME-Version: 1.0 References: <20020916151838.495BA4B23@coconut.itojun.org> <13404.1032252213@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 17 Sep 2002 22:16:54 +1000 From: Aidan Williams To: Robert Elz CC: itojun@iijlab.net, Erik Nordmark , namedroppers@ops.ietf.org Subject: Re: mDNS/LLMNR and "local.arpa" X-Spam-Status: No, hits=0.5 required=5.0 tests=SIGNATURE_DELIM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] > We already have disjointed namespaces, all considered equal, where a > name lookup gets satisfied by one (seemingly at random, but actually as > configured for the node's lookup order). Adding one more name lookup > mechanism changes nothing. Most nodes are going to do DNS lookups first > (or attempt them), and then if there is no DNS server, or it fails, fall > back to whatever lookup mechanism suits (some sites prefer to insert some > locally configured names ahead of the DNS - I doubt doing that for > a local multicast lookup would ever make sense). > So far so good. So you would be happy with a LLMNR lookup succeeding for "www.ietf.org"? Should what is returned bear any relationship at all to what might be returned by a DNS lookup of the same name? (without some magic, I can't see how) Should an application be able to tell the difference between something answered by the DNS and something answered by LLMNR? (unless there a different API, or something like a well known domain suffix, I can't see how) One of the differences between the DNS/NIS/whatever name service examples and LLMNR is that there is a server that is "more trusted" than "just any old host that happens to be within earshot of the requester". The use of a well known suffix could prevent www.ietf.org from being resolved using an LLMNR-like protocol (by ensuring that only things that are in a particular domain suffix get resolved). Another approach may be to stipulate that things looked up using LLMNR don't have any dots in them (that would match the kind of behaviour that is seen currently with NetBIOS naming today). Personally, I think it would be prudent to do something to prevent security problems that may result from looking up what are supposed to be DNS names in LLMNR. It is true that unicast DNS responses to requests could be forged, but the multicast nature of LLMNR makes the task a whole lot easier. -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://marc.labs.mot.com/snrl/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 15:36:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27604 for ; Tue, 17 Sep 2002 15:36:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rO3l-000ATP-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 12:30:57 -0700 Received: from [2001:610:ff:1::2] (helo=bartok.sidn.nl) by psg.com with esmtp (Exim 3.36 #1) id 17rO3i-000AT3-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 12:30:54 -0700 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g8HJUgpZ059482; Tue, 17 Sep 2002 21:30:43 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200209171930.g8HJUgpZ059482@bartok.sidn.nl> To: "Hallam-Baker, Phillip" cc: "'Edward Lewis'" , namedroppers@ops.ietf.org Subject: Re: wildcards, dnssec, and opt-in In-reply-to: Your message of Tue, 17 Sep 2002 07:53:27 -0700. <2F3EC696EAEED311BB2D009027C3F4F405869BB8@vhqpostal.verisign.com> Date: Tue, 17 Sep 2002 21:30:42 +0200 From: Jaap Akkerhuis X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If opt-in is to be adopted, it too will have to deal with wild cards. > If there's a choice between wild cards and opt-in, I'd have to lean > in favor of wild cards as I see that wild cards as a requirement. I believe that the ability to deploy in .com, .net and .org is a requirement. State your believes. Citate the requirements. What makes you think that these domains are different then the ones you don't mention? Unless the protocol is fixed there is no way that DNSSEC should go to the IESG. Why? DNSSEC in its current form is BROKEN. Because of what? jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 16:48:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29966 for ; Tue, 17 Sep 2002 16:48:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rP8h-000Fmn-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 13:40:07 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17rP8c-000FmF-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 13:40:02 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8HKdv9M004332; Tue, 17 Sep 2002 13:39:58 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 13:41:52 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40E1FC662@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Jaap Akkerhuis , "Hallam-Baker, Phillip" Cc: "'Edward Lewis'" , namedroppers@ops.ietf.org Subject: RE: wildcards, dnssec, and opt-in Date: Tue, 17 Sep 2002 13:41:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I believe that the ability to deploy in .com, .net and .org is > a requirement. > > State your believes. Citate the requirements. What makes you think > that these domains are different then the ones you don't mention? We have been over this many, many times as you are undoubtedly aware. Without OPTIN the cost of creating unnecessary NXT records is prohibitive. It is a scale issue that becomes apparent when you have over a million records. I find it bizare that we are talking about hypothetical applications of enum in Andora when it has already been established that without a change to the processing of NXT, the DNSSEC protocol is undeployable for the vast majority of current users. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 16:48:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29994 for ; Tue, 17 Sep 2002 16:48:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rP9D-000Fo1-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 13:40:39 -0700 Received: from dsl092-066-068.bos1.dsl.speakeasy.net ([66.92.66.68] helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17rP9A-000Fnp-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 13:40:36 -0700 Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 9EC5A33A for ; Tue, 17 Sep 2002 16:40:34 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [127.0.0.1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 4816876B for ; Tue, 17 Sep 2002 16:46:19 +0000 (GMT) Date: Tue, 17 Sep 2002 09:46:18 -0700 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <200209161645.SAA04757@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <20020916154248.GA2790@outpost.ds9a.nl> <200209161645.SAA04757@grimsvotn.TechFak.Uni-Bielefeld.DE> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingþ-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020917164619.4816876B@thangorodrim.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As far as I know there is nothing in the specs to rule out either NS or CNAME RRs with wildcard owner names (ie, I think Peter's right). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 17:11:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00936 for ; Tue, 17 Sep 2002 17:11:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPWx-000HtH-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 14:05:11 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17rPWs-000Ht4-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 14:05:06 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g8HL50W18551; Tue, 17 Sep 2002 14:05:00 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Tue, 17 Sep 2002 14:05:00 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Paul Vixie cc: namedroppers@ops.ietf.org, Subject: Re: DS and the deployed base In-Reply-To: <20020917173031.6A75228B01@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 17 Sep 2002, Paul Vixie wrote: > > So, my problem appears to be a bug when querying the Root with a bind > > 9.2.1 Recursive DNS Server. > > > > I now upgraded to 9.3.0s20020722 and I get the proper answers: > > > > Does this indicate that the "flag-day" may have much > > broader impact that one might have originally thought? > > according to published reports, bind8 is the most popular dns implementation > now in use, followed by bind4, followed by microsoft. the fact that an > interrim bind9 release didn't handle NXT RR's correctly is of very little > significance, since people who run bind9 at all are very susceptible to > upgrading it when they hear that a new release is available. This isn't a problem of not handling NXT records correctly. The problem is that with DS, referrals to unsigned delegations contain NXT records. A response with an empty answer section and NXT records in the authority section looks a lot more like a negative response than a referral to a server that doesn't speak DS. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 17:14:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00989 for ; Tue, 17 Sep 2002 17:14:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPZS-000Hzr-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 14:07:46 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17rPZO-000Hyt-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 14:07:42 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 162593; Tue, 17 Sep 2002 16:05:18 -0500 Message-ID: <3D879999.40200@ehsco.com> Date: Tue, 17 Sep 2002 16:07:37 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Aidan Williams CC: Robert Elz , itojun@iijlab.net, Erik Nordmark , namedroppers@ops.ietf.org Subject: Re: mDNS/LLMNR and "local.arpa" References: <20020916151838.495BA4B23@coconut.itojun.org> <13404.1032252213@munnari.OZ.AU> <3D871D36.1060805@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 9/17/2002 7:16 AM Aidan Williams wrote: > So you would be happy with a LLMNR lookup succeeding > for "www.ietf.org"? An LLMNR response for that name would be authoritative. An LLMNR response for www.ietf.org.local.arpa would also be authoritative. Both of them would be non-authoritative for the DNS names, however, for multiple reasons (RRs have expired and/or changed, for example). Ergo, applying the LLMNR names, data, and authority to the DNS namespace would be dangerous in all cases. Therefore, LLMNR data MUST BE HANDLED SEPARATELY from DNS data in those cases where the data will be reused. Note that once the minimum responsible effort is taken, then the presence or lack of any specific label is moot. In those cases where it is not reused beyond the context of a single application, who cares? -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 17:14:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01139 for ; Tue, 17 Sep 2002 17:14:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPZL-000HyR-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 14:07:39 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17rPZG-000HxI-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 14:07:34 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g8HL7AO18555; Tue, 17 Sep 2002 14:07:10 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Tue, 17 Sep 2002 14:07:10 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: "Hallam-Baker, Phillip" cc: Jaap Akkerhuis , "'Edward Lewis'" , Subject: RE: wildcards, dnssec, and opt-in In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40E1FC662@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 17 Sep 2002, Hallam-Baker, Phillip wrote: > > I believe that the ability to deploy in .com, .net and .org is > > a requirement. > > > > State your believes. Citate the requirements. What makes you think > > that these domains are different then the ones you don't mention? > > We have been over this many, many times as you are undoubtedly aware. Far too often, yes. > Without OPTIN the cost of creating unnecessary NXT records is > prohibitive. > > It is a scale issue that becomes apparent when you have over a > million records. I don't think it's ever been shown to be prohibitive. Given modern hardware, why? > I find it bizare that we are talking about hypothetical applications > of enum in Andora when it has already been established that without > a change to the processing of NXT, the DNSSEC protocol is undeployable > for the vast majority of current users. The vast majority of current users don't have zones the size of .com, so this is irrelevant. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 17:16:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01170 for ; Tue, 17 Sep 2002 17:16:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPcL-000IR2-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 14:10:45 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17rPcF-000IQj-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 14:10:39 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id EA34F28B01; Tue, 17 Sep 2002 21:10:38 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org, dnssec@cafax.se Subject: Re: DS and the deployed base In-Reply-To: Message from Brian Wellington of "Tue, 17 Sep 2002 14:05:00 MST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 17 Sep 2002 21:10:38 +0000 Message-Id: <20020917211038.EA34F28B01@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This isn't a problem of not handling NXT records correctly. The problem > is that with DS, referrals to unsigned delegations contain NXT records. A > response with an empty answer section and NXT records in the authority > section looks a lot more like a negative response than a referral to a > server that doesn't speak DS. i know it "looks a lot more like" and is a problem for at least one server we know about (BIND 9.2.1). however, before we call this a showstopper and choose a different encoding for this condition, can we survey the other, more popular server implementations and see if there aren't any? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 17:37:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01494 for ; Tue, 17 Sep 2002 17:37:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPwp-000KL5-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 14:31:55 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17rPwj-000KKq-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 14:31:50 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8HLVk9M015675; Tue, 17 Sep 2002 14:31:46 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 14:33:41 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40E1FC678@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Brian Wellington , "Hallam-Baker, Phillip" Cc: Jaap Akkerhuis , "'Edward Lewis'" , namedroppers@ops.ietf.org Subject: RE: wildcards, dnssec, and opt-in Date: Tue, 17 Sep 2002 14:33:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I find it bizare that we are talking about hypothetical applications > > of enum in Andora when it has already been established that without > > a change to the processing of NXT, the DNSSEC protocol is > undeployable > > for the vast majority of current users. > > The vast majority of current users don't have zones the size > of .com, so > this is irrelevant. The vast majority of users have zones that are IN .com so for them the issue is pretty damn important. The .com hardware supports 7 billion transactions per day. There is simply no way that anyone is going to allow deployment of any protocol modification that does not take account of the fact that DNS is a critical infrastructure for the Internet and take every step possible to minimize impact on those systems. Call these issues 'irrelevant' if you like, but in every successful standards group I have been involved in the group has taken great pains to gain the active endorsement of the principal stakeholders rather than dismissing their needs as 'irrelevant'. Since I first attended a DNSEXT meeting in San Diego I have started two open standards groups, one of which has its specs in final vote and the other is just about to go to last call. Both specifications have a very broad base of support amongst industry and developers. I don't expect anyone to use XKMS or SAML or even WS-Security because they are told to by a standards body, I expect them to use the specifications because they meet their needs. If a working group goes out of its way to tell a group that their requirements are considered 'irrelevant' they are effectively saying that they do not intend to service that groups needs and consequently cannot expect that group to adopt any resulting proposal. Standards groups are a two way street, don't tell me my requirements are irrelevant one day and then go and complain later if I do something you don't like. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 18:02:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00990 for ; Tue, 17 Sep 2002 17:14:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPYj-000HvC-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 14:07:01 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17rPYf-000HuX-00; Tue, 17 Sep 2002 14:06:57 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8HL6S9M009419; Tue, 17 Sep 2002 14:06:28 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 14:08:23 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40E1FC66E@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Randy Bush , Roy Arends Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Bohemian NAPTR Date: Tue, 17 Sep 2002 14:08:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk OK, Andora is not in Bohemia, but its close. Let us look at this issue by case analysis, I cannot see where the ambiguity arises with or without OPTIN. In the first place let us look at the enum domain, one of the curious facts about an enum domain is that it can have a maximum of 10 sub domains - 12 if you want to include # and *. So one is most unlikely to be using OPTIN in those domains in the first place. So the best argument that can be made from the example is that wildcards be allowed for non opt-in domains. So now let us look at the wildcard, what does it really mean here? The * could match: 0. Immediate subdomain, 0.0. nested subdomain The first case is clearly not a compelling reason to require wildcard support since the subdomains are easily enumerated. The second case is the one that causes large numbers to be introduced. I think the problem stems from a basic confusion over what the wildcard indicates and the application area. In an enum application it is very likely that there would be a lot of ldap directories up and down the tree: +44 [national] 0121 [local] 29292932 [Line] In the example above we have three separate ldap directories that might be queried. I do not believe that a wildcard would be appropriate in any of those cases. A wildcard would indicate that the ldap repository was authoritative for all information concerning all sub trees while in any practical design the national, local and line directories are going to be very different with very different purposes. The fact that BT runs a national LDAP directory should not pre-empt my ability to run a local directory for my personal line. In other words, Paul and the enum group are right. You certainly do not want to use wildcards in the enum context. Phill > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Tuesday, September 17, 2002 3:12 PM > To: Roy Arends > Cc: Paul Vixie; namedroppers@ops.ietf.org > Subject: Re: DNSSEXT Yokohama Minutes > > > > The enum WG is well aware that the use of wildcard NAPTR > RRs are A Bad > > Thing. They seriously advice against it, and advice to > simply enumerate > > every number that is in the repository of the zone. > > that's really gonna work great for anything larger then andora > > 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. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 18:06:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02130 for ; Tue, 17 Sep 2002 18:06:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rQFx-000Lwd-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 14:51:41 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17rQFu-000LwM-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 14:51:38 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g8HLpGF18916; Tue, 17 Sep 2002 14:51:16 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Tue, 17 Sep 2002 14:51:15 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: "Hallam-Baker, Phillip" cc: Jaap Akkerhuis , "'Edward Lewis'" , Subject: RE: wildcards, dnssec, and opt-in In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40E1FC678@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 17 Sep 2002, Hallam-Baker, Phillip wrote: > > > > I find it bizare that we are talking about hypothetical applications > > > of enum in Andora when it has already been established that without > > > a change to the processing of NXT, the DNSSEC protocol is > > undeployable > > > for the vast majority of current users. > > > > The vast majority of current users don't have zones the size > > of .com, so > > this is irrelevant. > > The vast majority of users have zones that are IN .com so for them the > issue is pretty damn important. It's important for you, not for them. Do you really think the users care how long it takes to sign .com? > The .com hardware supports 7 billion transactions per day. There is > simply no way that anyone is going to allow deployment of any protocol > modification that does not take account of the fact that DNS is a > critical infrastructure for the Internet and take every step possible > to minimize impact on those systems. 7 billion transactions? Presumably you're referring to queries, and opt-in doesn't make query responses any shorter. > Call these issues 'irrelevant' if you like, but in every successful > standards group I have been involved in the group has taken great > pains to gain the active endorsement of the principal stakeholders > rather than dismissing their needs as 'irrelevant'. They're irrelevant to most users, and important to large registries. You work at a large registry. Of course you think it's important. You should. > Since I first attended a DNSEXT meeting in San Diego I have started > two open standards groups, one of which has its specs in final vote > and the other is just about to go to last call. Both specifications > have a very broad base of support amongst industry and developers. > > I don't expect anyone to use XKMS or SAML or even WS-Security because > they are told to by a standards body, I expect them to use the > specifications because they meet their needs. If a working group goes > out of its way to tell a group that their requirements are considered > 'irrelevant' they are effectively saying that they do not intend to > service that groups needs and consequently cannot expect that group > to adopt any resulting proposal. > > Standards groups are a two way street, don't tell me my requirements > are irrelevant one day and then go and complain later if I do something > you don't like. This seems pretty off-topic. I didn't intend to dismiss your claims; merely that they don't apply to most users. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 18:39:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02862 for ; Tue, 17 Sep 2002 18:39:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rQmb-000Ooo-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 15:25:25 -0700 Received: from gusto.araneus.fi ([204.152.186.164]) by psg.com with esmtp (Exim 3.36 #1) id 17rQmX-000OoA-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 15:25:21 -0700 Received: from guam.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.11.6/8.11.6) with ESMTP id g8HMPKt18892; Tue, 17 Sep 2002 15:25:20 -0700 (PDT) Received: (from gson@localhost) by guam.araneus.fi (8.11.6/8.11.6) id g8HMPGr27955; Tue, 17 Sep 2002 15:25:16 -0700 (PDT) Date: Tue, 17 Sep 2002 15:25:16 -0700 (PDT) Message-Id: <200209172225.g8HMPGr27955@guam.araneus.fi> To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <20020917164619.4816876B@thangorodrim.hactrn.net> References: <20020916154248.GA2790@outpost.ds9a.nl> <200209161645.SAA04757@grimsvotn.TechFak.Uni-Bielefeld.DE> <20020917164619.4816876B@thangorodrim.hactrn.net> X-Mailer: VM 7.07 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: > As far as I know there is nothing in the specs to rule out either NS > or CNAME RRs with wildcard owner names (ie, I think Peter's right). There are two sides to this. On the one hand, nothing forbids publishing an NS or CNAME record with an owner name of "*", and if you explicitly query for type NS or type CNAME, the wildcard expansion will be returned. In this sense, wildcard NS and CNAME records "work" just like any other record type. On the other hand, a server that implements the name server algorithm in RFC1034 section 4.3.2 will not issue a referral response due to a wildcard NS, nor will it follow a wildcard CNAME, because the logic that makes NS and CNAME records special is in the part of the algorithm dealing with existing names (steps 3a - 3b) but not in the part dealing with nonexistent names (step 3c). Therefore, a wildcard CNAME record will not create a working alias, nor will a wildcard NS record create a working delegation. -- 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 21:18:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05326 for ; Tue, 17 Sep 2002 21:18:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rTDx-000CJO-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 18:01:49 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17rTDu-000CJD-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 18:01:46 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g8I11VLm000869; Tue, 17 Sep 2002 18:01:33 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Tue, 17 Sep 2002 18:01:29 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40E1FC6B2@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Brian Wellington , "Hallam-Baker, Phillip" Cc: Jaap Akkerhuis , "'Edward Lewis'" , namedroppers@ops.ietf.org Subject: RE: wildcards, dnssec, and opt-in Date: Tue, 17 Sep 2002 18:01:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > The vast majority of users have zones that are IN .com so > for them the > > issue is pretty damn important. > > It's important for you, not for them. Do you really think > the users care > how long it takes to sign .com? They care if the impact of DNSSEC on .com is such that we do not deploy. The time issue is far less important than the data volume issue. No extension that causes an immediate and sudden increase in the data volumes will be deployed. > > Standards groups are a two way street, don't tell me my requirements > > are irrelevant one day and then go and complain later if I > do something > > you don't like. > > This seems pretty off-topic. I didn't intend to dismiss your claims; > merely that they don't apply to most users. On the contrary, they apply to the vast majority of users whose domains are in .com and .net. I do not believe it is off topic to point out that rejection of a set of requirements has consequences that will render the entire group irrelevant. If you tell me that you are not going to address people's requirements you have absolutely no reason to complain if they do not accept the decisions made here. We already reached consensus here, but for Katherine Harris II and her supreme cabal the drafts could have been RFCs by now. So don't complain if people choose the original group consensus over the cabal, or go form their own cabal somewhere else. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 21:28:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05479 for ; Tue, 17 Sep 2002 21:28:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rTSr-000DmL-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 18:17:13 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17rTSm-000Dke-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 18:17:09 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8I1GrB5055040; Wed, 18 Sep 2002 11:16:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200209180116.g8I1GrB5055040@drugs.dv.isc.org> To: Rob Austein Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSSEXT Yokohama Minutes In-reply-to: Your message of "Tue, 17 Sep 2002 09:46:18 MST." <20020917164619.4816876B@thangorodrim.hactrn.net> Date: Wed, 18 Sep 2002 11:16:53 +1000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > As far as I know there is nothing in the specs to rule out either NS > or CNAME RRs with wildcard owner names (ie, I think Peter's right). > CNAME are not illegal but if you follow the steps in RFC 1034 you won't see the wildcard CNAME unless you ask for a CNAME. * is internal to a zone, i.e. not the apex. NS records for delegation are supposed to be copies of the NS records in the child zone. Since * cannot be at the apex of the zone, you cannot have wilcard NS records in the parent. 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. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 21:29:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05495 for ; Tue, 17 Sep 2002 21:29:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rTU2-000DpE-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 18:18:26 -0700 Received: from ftpbox.mot.com ([129.188.136.101]) by psg.com with esmtp (Exim 3.36 #1) id 17rTTz-000Dp3-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 18:18:23 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id SAA00604; Tue, 17 Sep 2002 18:16:17 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA17905; Tue, 17 Sep 2002 18:16:14 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8I1G67C007932; Wed, 18 Sep 2002 11:16:07 +1000 (EST) Message-ID: <3D87D3D6.7010405@motorola.com> Date: Wed, 18 Sep 2002 11:16:06 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz CC: itojun@iijlab.net, Erik Nordmark , namedroppers@ops.ietf.org Subject: Re: mDNS/LLMNR and "local.arpa" References: <3D871D36.1060805@motorola.com> <20020916151838.495BA4B23@coconut.itojun.org> <13404.1032252213@munnari.OZ.AU> <14697.1032268045@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: Tue, 17 Sep 2002 22:16:54 +1000 > From: Aidan Williams > Message-ID: <3D871D36.1060805@motorola.com> > > | So you would be happy with a LLMNR lookup succeeding > | for "www.ietf.org"? > > Yes, of course, in fact, that might often be exactly what I'd want > to happen, any time it actually succeeded. > > Note, that unless I'm insane (in which case you probably should ignore > this opinion), that won't even get a chance to succeed unless the DNS > isn't available at all. > > If there's no DNS, and I'm expecting www.ietf.org to work, then I think > I would want it to... > OK. I understand your position. > Yes, there are security issues to be handled, but if we assume that we > start using dnssec sometime this century, then multicast lookups will likely > be distinguished as not being properly signed. > That is not an "if" I would use to justify not bothering to differentiate LLMNR and DNS names in some other way. > Sticking a funny domain on the end won't solve anything - I'd configure my > search list to include it anyway (so I can refer to "foo") and that means > that (unless I happen to do "www.ietf.org.") the resolver is eventually > likely to try www.ietf.org.local.arpa. as the lookup for me, and then it > would go find the multicast version anyway (a hacker would just be pretending > to be that, instead of www.oetf.org - the A record that comes back to my > browser works the same either way). > That would be what a *DNS* resolver would do with the name, and is beside the point. Some resolvers count the number of dots too. [ I'm assuming in all this that the DNS resolver and the LLMNR resolver software are two seperate pieces of code (ie that the DNS resolver isn't going to try multicast for DNS request it is passed, or use a "funny suffix" as a trigger for doing multicast lookups. I though we had decided that overloading the search list as a trigger for mDNS lookups was a bad idea..) ] There seems to be a confusion here between how something like nsswitch.conf operates and how a DNS resolver library operates. My understanding is that code dealing with different name systems (eg code for nsswitch.conf) will pass just the name through to each underlying name service. For an /etc/nsswitch.conf hosts entry like hosts: files dns llmnr 1) www.ietf.org gets looked up in /etc/hosts 2) www.ietf.org gets passed to the DNS resolver library, which may subsequently try the name with various domain suffixes tacked on the end 3) www.ietf.org gets passed to the LLMNR resolver code which could choose not to do a multicast request because the name has dots in it, or because the name does not have the local.arpa suffix So a known suffix and/or no-dots would be a simple prescription that could work to ensure that DNS names like www.ietf.org are not resolved using LLMNR. One could even put llmnr before DNS with this approach. I understand that you are saying that would would like to be able to resolve "www.ietf.org" via LLMNR. I have an open mind on that. > If we had to have a restriction, "names with no dots" would be the only > reasonable one - but I really believe that's unnecessarily limiting, for > no real gain that matters. > The gain is perceived to be a guarantee that LLMNR won't have any negative security implications for applications that think they are looking up DNS-like names. If the DNS mostly always gets to resolve the name first, then you are pretty unlikely to use LLMNR to resolve www.ietf.org anyway, so there is no great loss in imposing the restriction? -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://marc.labs.mot.com/snrl/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 17 22:35:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06968 for ; Tue, 17 Sep 2002 22:35:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rURY-000JJc-00 for namedroppers-data@psg.com; Tue, 17 Sep 2002 19:19:56 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17rURU-000JJQ-00 for namedroppers@ops.ietf.org; Tue, 17 Sep 2002 19:19:53 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8I2JqRF019812 for ; Tue, 17 Sep 2002 22:19:52 -0400 (EDT) Received: from [66.44.62.106] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA09039; Tue, 17 Sep 2002 22:19:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Tue, 17 Sep 2002 22:19:25 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: opt-in and large zones Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The current opt-in thread is really bothersome to me - it's too polarized to be helpful. But I just have one question along the lines that I am dying to ask, yet I don't want to be drug into the current conversation. The question is: Do other (not com.) large zone registrars feel that opt-in is necessary? I'm assuming that there are zones other than com. with over a million subdomains. I'd really like to see a working prototype of an opt-in server - so we can play. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 04:51:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06142 for ; Wed, 18 Sep 2002 04:51:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17raGU-0000yu-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 01:32:54 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 17raGR-0000yj-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 01:32:51 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 7DE2E52B2; Wed, 18 Sep 2002 10:32:44 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id B1E9B1DF6; Wed, 18 Sep 2002 10:32:41 +0200 (MEST) Date: Wed, 18 Sep 2002 10:32:26 +0200 (CEST) From: Jakob Schlyter To: "Hallam-Baker, Phillip" Cc: Brian Wellington , Jaap Akkerhuis , "'Edward Lewis'" , Subject: RE: wildcards, dnssec, and opt-in In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40E1FC6B2@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 17 Sep 2002, Hallam-Baker, Phillip wrote: > They care if the impact of DNSSEC on .com is such that we do not deploy. people will deploy dnssec either to increase the security of the dns or to make money. I would guess verisign falls into the second category. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 05:25:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06649 for ; Wed, 18 Sep 2002 05:25:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17raxM-0004Q4-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 02:17:12 -0700 Received: from [2001:610:ff:1::2] (helo=bartok.sidn.nl) by psg.com with esmtp (Exim 3.36 #1) id 17raxI-0004PE-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 02:17:08 -0700 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g8I9H3pZ061808 for ; Wed, 18 Sep 2002 11:17:06 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200209180917.g8I9H3pZ061808@bartok.sidn.nl> To: namedroppers@ops.ietf.org Subject: Re: opt-in and large zones In-reply-to: Your message of Tue, 17 Sep 2002 22:19:25 -0400. Date: Wed, 18 Sep 2002 11:17:02 +0200 From: Jaap Akkerhuis X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The current opt-in thread is really bothersome to me - it's too polarized to be helpful. Yes, I don't think "believes" has a place in a technical discussions. But I just have one question along the lines that I am dying to ask, yet I don't want to be drug into the current conversation. The question is: Do other (not com.) large zone registrars feel that opt-in is necessary? I'm assuming that there are zones other than com. with over a million subdomains. That was my point. There are zones out there which are bigger then .net & .org, and thus far I haven't noticed that folks maintaining these zones want OPT-IN. I'd really like to see a working prototype of an opt-in server - so we can play. That would be a rational thing to do. jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 05:27:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06700 for ; Wed, 18 Sep 2002 05:27:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rb2V-0004lD-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 02:22:31 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17rb2P-0004k9-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 02:22:25 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 3C748137F05; Wed, 18 Sep 2002 02:22:25 -0700 (PDT) To: Brian Wellington Cc: "Hallam-Baker, Phillip" , Jaap Akkerhuis , "'Edward Lewis'" , namedroppers@ops.ietf.org Subject: Re: wildcards, dnssec, and opt-in In-Reply-To: Message from Brian Wellington of "Tue, 17 Sep 2002 14:51:15 PDT." Date: Wed, 18 Sep 2002 02:22:25 -0700 Message-ID: <65892.1032340945@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Brian" == Brian Wellington writes: Brian> It's important for you, not for them. Do you really think Brian> the users care how long it takes to sign .com? Of course not. Though they will care if the signing time has an impact on how quickly new delegations get published. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 06:09:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07390 for ; Wed, 18 Sep 2002 06:09:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rbf4-0007w7-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 03:02:22 -0700 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 17rbf0-0007vf-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 03:02:18 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rbew-0004Al-00; Wed, 18 Sep 2002 13:02:14 +0300 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes References: <20020917191758.28ED328B02@as.vix.com> Message-Id: Date: Wed, 18 Sep 2002 13:02:14 +0300 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> The enum WG is well aware that the use of wildcard NAPTR RRs are A Bad >>> Thing. They seriously advice against it, and advice to simply enumerate >>> every number that is in the repository of the zone. >> that's really gonna work great for anything larger then andora > that's off-topic for us. anyone who wants to change the way enum works > should issue their opinions over on the enum wg's list. i have been on enum since day zero. and enum works *.3.3.e164.arpa NAPTR ...ldap... so i guess we agree. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 07:33:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08622 for ; Wed, 18 Sep 2002 07:33:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rcyk-000F82-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 04:26:46 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17rcyg-000F7p-00; Wed, 18 Sep 2002 04:26:42 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8IBQF318859; Wed, 18 Sep 2002 18:26:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8IBPsK19954; Wed, 18 Sep 2002 18:25:55 +0700 (ICT) From: Robert Elz To: "Hallam-Baker, Phillip" cc: Randy Bush , Roy Arends , Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Bohemian NAPTR In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40E1FC66E@vhqpostal.verisign.com> References: <2F3EC696EAEED311BB2D009027C3F4F40E1FC66E@vhqpostal.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Sep 2002 18:25:54 +0700 Message-ID: <19952.1032348354@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 17 Sep 2002 14:08:11 -0700 From: "Hallam-Baker, Phillip" Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40E1FC66E@vhqpostal.verisign.com> | A wildcard would indicate that the ldap repository was authoritative for all | information concerning all sub trees It is kind of mind blowing to believe that anyone on this list actually believes that wildcards work like 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 07:38:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08682 for ; Wed, 18 Sep 2002 07:38:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rd11-000FIf-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 04:29:07 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17rd0t-000EiR-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 04:29:04 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8IBNn318749; Wed, 18 Sep 2002 18:23:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8IBNLK19943; Wed, 18 Sep 2002 18:23:27 +0700 (ICT) From: Robert Elz To: Mark.Andrews@isc.org cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <200209180116.g8I1GrB5055040@drugs.dv.isc.org> References: <200209180116.g8I1GrB5055040@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Sep 2002 18:23:21 +0700 Message-ID: <19941.1032348201@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 18 Sep 2002 11:16:53 +1000 From: Mark.Andrews@isc.org Message-ID: <200209180116.g8I1GrB5055040@drugs.dv.isc.org> | * is internal to a zone, i.e. not the apex. | NS records for delegation are supposed to be copies of the | NS records in the child zone. They should be the same, yes. | Since * cannot be at the apex of the zone, What has that to do with anything? Eg, say I have on server A $ORIGIN foo.example.com. @ IN SOA ... IN NS A.my.domain. IN NS B.my.domain. www IN A 1.2.3.4 Then on server Q, I have $ORIGIN example.com. [normal stuff] * IN NS A.my.domain. IN NS B.my.domain. and no mention of "foo" anywhere in that zone at all. Then, someone does a lookup of www.foo.example.com The wildcard NS records exactly match the NS records at the apex of the zone delegated. No problem at all. Of course, someone might also do a lookup of www.random.example.com. and you might think, that because A (and B) have never heard of random.example.com this must necessarily be illegal. But first, how can Q possibly tell the difference between these two cases? And second, A might be a "smart" server, that creates the zone upon demand - that is the "$ORIGIN foo.example.com." zone above might have been created by A when the (first) query for www.foo.example.com. appeared. I'm not saying that any of this is useful for anything much, but | you cannot have wilcard NS records in the parent. isn't supportable as an argument. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 08:03:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09402 for ; Wed, 18 Sep 2002 08:03:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rdQr-000HZn-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 04:55:49 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17rdQm-000HZc-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 04:55:44 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8IBtkRF025605 for ; Wed, 18 Sep 2002 07:55:46 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id HAA07865 for ; Wed, 18 Sep 2002 07:55:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <65892.1032340945@shell.nominum.com> References: <65892.1032340945@shell.nominum.com> Date: Wed, 18 Sep 2002 07:55:20 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wildcards, dnssec, and opt-in Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Before we get too far into this rat hole, the DNSSEC performance issue behind opt-in isn't signing time. That's been discussed before. The issue is the memory required to hold the zone in a server (whether primary or secondary storage) and the cpu needed to search through the data. I claim that signing a zone of any size is an easy proposition. My first signer could handle (late-90s) com. from scratch - then at 700K delegations - on a mid-90's Pentium in 40 hours. My second signer (the one distrubuted with BIND 8.2) couldn't sign com. because I didn't include my "memory tricks" simply because it didn't seem important to to do so in experimental code. Signing is the easy part. The "response time" for adding a new signed delegation is more a function of institutional practices than computing power. At 2:22AM -0700 9/18/02, Jim Reid wrote: >>>>>> "Brian" == Brian Wellington writes: > > Brian> It's important for you, not for them. Do you really think > Brian> the users care how long it takes to sign .com? > >Of course not. Though they will care if the signing time has an impact >on how quickly new delegations get published. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 08:23:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10019 for ; Wed, 18 Sep 2002 08:23:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rdks-000J6l-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 05:16:30 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17rdko-000J6a-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 05:16:27 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8ICGURF025793 for ; Wed, 18 Sep 2002 08:16:30 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA09799; Wed, 18 Sep 2002 08:16:25 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Wed, 18 Sep 2002 08:16:17 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: inconsistency between rfc 2136 and rfc 2845 Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk During a Secure Dynamic Update tutorial at RIPE 43 a situation arose that seems to indicate a conflict between RFC 2136 (Dynamic Update) and RFC 2854 (Secret Key Authentication for DNS). The problem isn't major - the labeling of an error condition is the problem. In 2136, we have this: > 2.2 - Message Header ... > RCODE Response code - this four bit field is undefined in requests > and set in responses. The values and meanings of this field > within responses are as follows: > > Mneumonic Value Description > ------------------------------------------------------------ ... > NOTAUTH 9 The server is not authoritative for > the zone named in the Zone Section. (Mnemonic is misspelled in the RFC text.) In RFC 2854, we have this text: >3 - Protocol Operation ... > 3.2. TSIG processing on incoming messages ... > If an incoming message contains a TSIG record, it MUST be the last ... > ........................................................... If the > algorithm name or key name is unknown to the recipient, or if the > message digests do not match, the whole DNS message MUST be > discarded. If the message is a query, a response with RCODE 9 > (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17 > (BADKEY) or TSIG ERROR 16 (BADSIG). .... The issue is that in 2136 "NOTAUTH" seems to mean not authoritative and in 2854 "NOTAUTH" seems to mean not authenticated. The reason this was noticed was in the reply to an update where the key was undefined to the server but the update was to a name & type in the zone. Rightly so, the software determined that the request was not properly authenticated and followed 2854's words. But when I was trying to explain this in the tutorial, I found the 2136 definition to seem to indicate a different error. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 10:45:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15964 for ; Wed, 18 Sep 2002 10:45:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rfoN-0003I1-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 07:28:15 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17rfoK-0003Hl-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 07:28:12 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 9968928B01 for ; Wed, 18 Sep 2002 14:28:09 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: opt-in and large zones In-Reply-To: Message from Edward Lewis of "Tue, 17 Sep 2002 22:19:25 -0400." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 18 Sep 2002 14:28:09 +0000 Message-Id: <20020918142809.9968928B01@as.vix.com> X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... The question is: > > Do other (not com.) large zone registrars feel that opt-in is > necessary? I'm assuming that there are zones other than com. with > over a million subdomains. i don't have such a domain. however, i think opt-in is architecturally right -- something that should have been in the protocol from the get-go. as such, i would use opt-in on all of my zones. delegations to unsigned subzones should not, in my view, require NXT RR's, because the name is not really in the parent, it's the apex of some other zone. if opt-in is available, it's my hope that the "." zone will use it. > I'd really like to see a working prototype of an opt-in server - so > we can play. likewise, hoping for same, soon. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 11:26:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17705 for ; Wed, 18 Sep 2002 11:26:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rgYi-00076y-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 08:16:08 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17rgYd-00075n-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 08:16:04 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8IFFlZB003482; Wed, 18 Sep 2002 17:15:49 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8IFFkQE003478; Wed, 18 Sep 2002 17:15:47 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 18 Sep 2002 17:15:46 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Jakob Schlyter cc: "Hallam-Baker, Phillip" , Brian Wellington , Jaap Akkerhuis , "'Edward Lewis'" , Subject: RE: wildcards, dnssec, and opt-in In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, Jakob Schlyter wrote: > On Tue, 17 Sep 2002, Hallam-Baker, Phillip wrote: > > > They care if the impact of DNSSEC on .com is such that we do not deploy. > > people will deploy dnssec either to increase the security of the dns or to > make money. I would guess verisign falls into the second category. Nonsense. People will deploy dnssec to increase the security of the DNS and (or) not to loose money (because of lack of security). These are effectively the same. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 11:30:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17808 for ; Wed, 18 Sep 2002 11:30:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rgeH-0007dV-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 08:21:53 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17rgeE-0007dJ-00; Wed, 18 Sep 2002 08:21:50 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8IFEf9M007366; Wed, 18 Sep 2002 08:14:41 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Sep 2002 08:16:36 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40E1FC75A@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Robert Elz , "Hallam-Baker, Phillip" Cc: Randy Bush , Roy Arends , Paul Vixie , namedroppers@ops.ietf.org Subject: RE: Bohemian NAPTR Date: Wed, 18 Sep 2002 08:16:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > | A wildcard would indicate that the ldap repository was > authoritative for all > | information concerning all sub trees > > It is kind of mind blowing to believe that anyone on this list > actually believes that wildcards work like that. It was a null hypothesis. My point is that the belief that wildcards cause difficulty appears to stem from confusion as to what they do. Clear up the confusion as to what they do and the difficulty will disappear. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 11:44:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18199 for ; Wed, 18 Sep 2002 11:44:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rgsY-0008tX-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 08:36:38 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 17rgsT-0008tK-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 08:36:33 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 9E60652AF; Wed, 18 Sep 2002 17:36:27 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id B23A91DF6; Wed, 18 Sep 2002 17:36:26 +0200 (MEST) Date: Wed, 18 Sep 2002 17:36:12 +0200 (CEST) From: Jakob Schlyter To: Roy Arends Cc: "Hallam-Baker, Phillip" , Brian Wellington , Jaap Akkerhuis , "'Edward Lewis'" , Subject: RE: wildcards, dnssec, and opt-in In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, Roy Arends wrote: > > people will deploy dnssec either to increase the security of the dns or to > > make money. I would guess verisign falls into the second category. > > Nonsense. > > People will deploy dnssec to increase the security of the DNS and (or) not > to loose money (because of lack of security). These are effectively the > same. yes, that may be true for end-zone administrators - I was talking about the registry. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 11:47:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18280 for ; Wed, 18 Sep 2002 11:47:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rgvi-00095t-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 08:39:54 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17rgvf-00095h-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 08:39:51 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8IFdeZB003701; Wed, 18 Sep 2002 17:39:41 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8IFde4T003697; Wed, 18 Sep 2002 17:39:40 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 18 Sep 2002 17:39:40 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Jakob Schlyter cc: "Hallam-Baker, Phillip" , Brian Wellington , Jaap Akkerhuis , "'Edward Lewis'" , Subject: RE: wildcards, dnssec, and opt-in In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, Jakob Schlyter wrote: > On Wed, 18 Sep 2002, Roy Arends wrote: > > > > people will deploy dnssec either to increase the security of the dns or to > > > make money. I would guess verisign falls into the second category. > > > > Nonsense. > > > > People will deploy dnssec to increase the security of the DNS and (or) not > > to loose money (because of lack of security). These are effectively the > > same. > > yes, that may be true for end-zone administrators - I was talking about > the registry. fud, stop 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 11:50:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18366 for ; Wed, 18 Sep 2002 11:50:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rgzN-0009WG-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 08:43:41 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17rgzJ-0009W1-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 08:43:37 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8IFhZRF034652 for ; Wed, 18 Sep 2002 11:43:35 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA12721; Wed, 18 Sep 2002 11:43:34 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 18 Sep 2002 11:34:02 -0400 To: Edward Lewis , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: inconsistency between rfc 2136 and rfc 2845 Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I should thank Mark Andrews for pointing to the text in 2854... At 8:16AM -0400 9/18/02, Edward Lewis wrote: >During a Secure Dynamic Update tutorial at RIPE 43 a situation arose that >seems to indicate a conflict between RFC 2136 (Dynamic Update) and RFC >2854 (Secret Key Authentication for DNS). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 12:48:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20786 for ; Wed, 18 Sep 2002 12:48:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rhw2-000E5A-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 09:44:18 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17rhvw-000E4M-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 09:44:13 -0700 Received: from [10.0.1.5] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id D732A137F07; Wed, 18 Sep 2002 09:44:07 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 18 Sep 2002 09:45:02 -0700 Subject: Re: wildcards, dnssec, and opt-in From: David Conrad To: "Hallam-Baker, Phillip" , Brian Wellington Cc: Jaap Akkerhuis , "'Edward Lewis'" , namedroppers Message-ID: In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40E1FC6B2@vhqpostal.verisign.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9/17/02 6:01 PM, "Hallam-Baker, Phillip" wrote: > The time issue is far less important than the data volume issue. No > extension that causes an immediate and sudden increase in the > data volumes will be deployed. Just to be clear, this isn't really true. The problem is that DNSSEC without opt-in implies a significant and immediate increase in data volume _without any mechanism by which costs to account for that increase can be recovered_. When you are talking about instantaneously multiplying a 2-3GB memory image by 8-10, I can see how people can get nervous, particularly on a 32 bit architecture. Of course, one might question whether keeping all that data in memory is a good idea in the first place, but changing architecture also costs money. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 12:48:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20808 for ; Wed, 18 Sep 2002 12:48:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rhq0-000DdB-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 09:38:04 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17rhpw-000Dcw-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 09:38:00 -0700 Received: from [10.0.1.5] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 83B9F137F05; Wed, 18 Sep 2002 09:37:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 18 Sep 2002 09:38:41 -0700 Subject: Re: wildcards, dnssec, and opt-in From: David Conrad To: Roy Arends , Jakob Schlyter Cc: "Hallam-Baker, Phillip" , Brian Wellington , Jaap Akkerhuis , "'Edward Lewis'" , namedroppers Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Roy, On 9/18/02 8:39 AM, "Roy Arends" wrote: > On Wed, 18 Sep 2002, Jakob Schlyter wrote: >> On Wed, 18 Sep 2002, Roy Arends wrote: >>>> people will deploy dnssec either to increase the security of the dns or to >>>> make money. I would guess verisign falls into the second category. >>> Nonsense. >>> >>> People will deploy dnssec to increase the security of the DNS and (or) not >>> to loose money (because of lack of security). These are effectively the >>> same. >> >> yes, that may be true for end-zone administrators - I was talking about >> the registry. > > fud, stop it :-) This is not FUD. Whether any registry deploys DNSSEC is a business decision of that registry. The registry, by and large, is not affected by the integrity issues DNSSEC protects against. If the registry's customers really want (that is, be willing to pay for) DNSSEC, it will get deployed, regardless of the implications that deployment might have on the registry's infrastructure. Unfortunately, to date, there has not been significant demand for DNSSEC from customers. As such, any registry that considers deploying it must be willing to assume some risk, believing that in the future customers will want DNSSEC. What I take Phill's comments to mean is that Verisign is not willing to take the risk. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 12:54:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21070 for ; Wed, 18 Sep 2002 12:54:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ri0Y-000EQA-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 09:48:58 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17ri0V-000EPz-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 09:48:55 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8IGmsRF040903 for ; Wed, 18 Sep 2002 12:48:55 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA03883 for ; Wed, 18 Sep 2002 12:48:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 18 Sep 2002 12:48:53 -0400 To: namedroppers From: Edward Lewis Subject: Re: wildcards, dnssec, and opt-in Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:38AM -0700 9/18/02, David Conrad wrote: >want DNSSEC. What I take Phill's comments to mean is that Verisign is not >willing to take the risk. I don't mean to pick on my esteemed colleague quoted above, but let's drop picking on business models and the motivation behind deploying DNSSEC. Let's instead get out hands on code that will let us look at our own personal "corner cases" to see just how (bad/painless/good) opt-in is. I would think this is an action item from the proponents of the change. Besides my FUD over wildcards and DNSSEC (and FUD it is as I can't test it), I have FUD over how an application might interpret the results of an opt-in impacted response. I'm not saying "it ain't gonna work," I'm saying "I can't tell right now." To the proponents of opt-in, don't take my (or others') skepticism as an unwillingness to adopt it. Naturally, any change to a system that is in operation will be looked at suspiciously until it becomes clear the change is beneficial. Scientists and engineers are naturally skeptical - new theories are only immediately adopted by trade rags and supermarket tabloids. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 14:10:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24211 for ; Wed, 18 Sep 2002 14:10:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rj8F-000JyZ-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 11:00:59 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17rj8B-000JyL-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 11:00:56 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8II0j9M013799; Wed, 18 Sep 2002 11:00:45 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Sep 2002 11:02:39 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40E1FC7DF@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: David Conrad , Roy Arends , Jakob Schlyter Cc: "Hallam-Baker, Phillip" , Brian Wellington , Jaap Akkerhuis , "'Edward Lewis'" , namedroppers Subject: RE: wildcards, dnssec, and opt-in Date: Wed, 18 Sep 2002 11:02:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Unfortunately, to date, there has not been significant demand > for DNSSEC > from customers. As such, any registry that considers > deploying it must be > willing to assume some risk, believing that in the future > customers will > want DNSSEC. What I take Phill's comments to mean is that > Verisign is not > willing to take the risk. Well we all speak for ourselves in these mailing lists. However it is clear that we have not been able to persuade the registry to deploy to date on the basis of the non-OPTIN specs. It does absolutely nothing for DNSEXT credibility inside the company to have loonies on this list stating that their intention is to design a protocol that cannot be deployed in .com because they are persuing some personal political campaign against the registry. Nor does it do much for DNSEXT credibility inside the IETF. The 'I am not comfortable with it line' is pure FUD straight out of the textbooks on Agenda Denial. I do not believe the issues being raised are being raised in good faith. 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 15:25:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27199 for ; Wed, 18 Sep 2002 15:25:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rkGE-000PiA-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 12:13:18 -0700 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 17rkG9-000PhS-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 12:13:13 -0700 Received: by sentry.gw.tislabs.com; id PAA28719; Wed, 18 Sep 2002 15:12:58 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma028704; Wed, 18 Sep 02 19:12:33 GMT Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id g8IJCkS02471 for ; Wed, 18 Sep 2002 15:12:46 -0400 (EDT) Date: Wed, 18 Sep 2002 15:12:46 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Subject: Moving DS into the parent (was: How does a sever for child answer a DS query.) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk So far we've found two gothcas[1] from having the DS record looking like it belongs in the child zone, yet declaring the parent to be authoritative for it. We can work around both, but I'm worried that there may be more out there (here, have some more FUD). Perhaps a better answer is to move the DS into the parent zone: in .com: microsoft.com NS ... ;; .com is not authoritative _ds_microsoft.com DS ... ;; .com is authoritative or microsoft._ds_.com DS ... ;; .com is authoritative Yes, this is gross, but it keeps the semantics unchanged, which keeps any similar problems from popping up later when it may be too late to fix them. Issue: the NXT chain. If _ds_microsoft.com gets it's own NXT and SIG(NXT), zones get bigger. If you include it as part of microsoft.com's NXT (and have the DS bit refer to something with a different name), that still leaves both parent and child with NXTs with matching names, which may lead to more problems of the same sort. -- Sam [1] Both gotchas come into play when a legacy (non-DNSSEC-aware) cache is between the DNSSEC-aware authoritative server and client. Last Tuesday, Olafur wrote: > DS is the first real record that can only exist at the parent thus > this issue has never been explored. > > In the early years of DS deployment non DS aware resolvers/caches > will blindly send DS queries to the child servers, thus is it > important that the answer returned have no negative implications for > future queries for records from the child zone. There's also an issue with cache timeouts: if the DS times out before the NS, a legacy cache can't find the DS, which limits child NS TTLs to the DS TTL set by the parent. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 17:01:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29964 for ; Wed, 18 Sep 2002 17:01:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rlp6-0007jA-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 13:53:24 -0700 Received: from h140.s251.netsol.com ([216.168.251.140] helo=borg.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17rlp3-0007iu-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 13:53:21 -0700 Received: (from markk@localhost) by borg.admin.cto.netsol.com (8.11.6/8.11.6) id g8IKn2x06684; Wed, 18 Sep 2002 16:49:02 -0400 Date: Wed, 18 Sep 2002 16:49:02 -0400 From: Mark Kosters To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: opt-in and large zones Message-ID: <20020918204902.GE6566@slam.admin.cto.netsol.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,OPT_IN,SIGNATURE_DELIM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Sep 17, 2002 at 10:19:25PM -0400, Edward Lewis wrote: > Do other (not com.) large zone registrars feel that opt-in is > necessary? I'm assuming that there are zones other than com. with > over a million subdomains. There are a few. Many aspire to get there someday :^). Have you seen any other registries directly participate in any of this? I've had a number of informal conversations with some of them but are relucant to expose their business plans - esp publically on a list (which I understand). > I'd really like to see a working prototype of an opt-in server - so > we can play. look at http://www.dnssec.verisignlabs.com Mark -- Mark Kosters markk@verisignlabs.com Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 17:09:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00137 for ; Wed, 18 Sep 2002 17:09:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rlvz-0008I9-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 14:00:31 -0700 Received: from h140.s251.netsol.com ([216.168.251.140] helo=borg.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17rlvv-0008Hw-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 14:00:27 -0700 Received: (from markk@localhost) by borg.admin.cto.netsol.com (8.11.6/8.11.6) id g8IKu7f06700; Wed, 18 Sep 2002 16:56:07 -0400 Date: Wed, 18 Sep 2002 16:56:07 -0400 From: Mark Kosters To: Jaap Akkerhuis Cc: namedroppers@ops.ietf.org Subject: Re: opt-in and large zones Message-ID: <20020918205607.GF6566@slam.admin.cto.netsol.com> References: <200209180917.g8I9H3pZ061808@bartok.sidn.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209180917.g8I9H3pZ061808@bartok.sidn.nl> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,OPT_IN,SIGNATURE_DELIM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Sep 18, 2002 at 11:17:02AM +0200, Jaap Akkerhuis wrote: > That was my point. There are zones out there which are bigger then > .net & .org, and thus far I haven't noticed that folks > maintaining these zones want OPT-IN. Devil's advocate time. Have these zone maintainers taken the time to understand what it takes to deploy dnssec? I surmise that interest may not be there since there is no immediate demand from their customers to deploy dnssec. I base my assertion on that fact that I have yet to hear any interest either directly or indirectly from any registrar that deals with com/net/org that they want dnssec. Mark -- Mark Kosters markk@verisignlabs.com Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 17:29:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00697 for ; Wed, 18 Sep 2002 17:29:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rmIF-000A3a-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 14:23:31 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17rmIB-000A3N-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 14:23:27 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 18F2144DB; Wed, 18 Sep 2002 23:23:25 +0200 (CEST) Date: Wed, 18 Sep 2002 23:23:24 +0200 From: bert hubert To: Mark Kosters Cc: Jaap Akkerhuis , namedroppers@ops.ietf.org Subject: Re: opt-in and large zones Message-ID: <20020918212324.GA2070@outpost.ds9a.nl> References: <200209180917.g8I9H3pZ061808@bartok.sidn.nl> <20020918205607.GF6566@slam.admin.cto.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020918205607.GF6566@slam.admin.cto.netsol.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Sep 18, 2002 at 04:56:07PM -0400, Mark Kosters wrote: > dnssec. I base my assertion on that fact that I have yet to hear any interest > either directly or indirectly from any registrar that deals with com/net/org > that they want dnssec. While large registrars are part of our customer base, none has requested DNSSEC as a 'must have' feature. So far people have assumed that DNSSEC was deployable, right now it is starting to get known that there are major issues separating DNSSEC from an infrastructure that can be deployed as a money-making service. Kind regards, bert hubert PowerDNS -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 17:33:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00899 for ; Wed, 18 Sep 2002 17:33:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rmMf-000AJv-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 14:28:05 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17rmMc-000AJj-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 14:28:02 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g8ILRqO11002; Wed, 18 Sep 2002 14:27:52 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 18 Sep 2002 14:27:52 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Edward Lewis cc: namedroppers Subject: Re: wildcards, dnssec, and opt-in In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, Edward Lewis wrote: > I don't mean to pick on my esteemed colleague quoted above, but let's > drop picking on business models and the motivation behind deploying > DNSSEC. Let's instead get out hands on code that will let us look at > our own personal "corner cases" to see just how (bad/painless/good) > opt-in is. I would think this is an action item from the proponents > of the change. As soon as there is working code, the argument becomes "There's working code, how bad can it be?". A decision should be made based on the merit of the ideas, and I don't think the existence of an implementation should ever be used to further progress. > Besides my FUD over wildcards and DNSSEC (and FUD it is as I can't > test it), I have FUD over how an application might interpret the > results of an opt-in impacted response. I'm not saying "it ain't > gonna work," I'm saying "I can't tell right now." To my knowledge, no one's ever claimed that opt-in won't work. Only Phill, as far as I can tell, claims that DNSSEC won't work without opt-in. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 18:24:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02146 for ; Wed, 18 Sep 2002 18:24:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rnA6-000DP4-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 15:19:10 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17rnA2-000DOs-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 15:19:06 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02009; Wed, 18 Sep 2002 18:17:17 -0400 (EDT) Message-Id: <200209182217.SAA02009@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: Limiting the Scope of the KEY Resource Record to Proposed Standard Date: Wed, 18 Sep 2002 18:17:17 -0400 X-Spam-Status: No, hits=1.1 required=5.0 tests=TO_MALFORMED version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the Internet-Draft 'Limiting the Scope of the KEY Resource Record' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document limits the Domain Name System KEY resource record to only keys used by the Domain Name System Security Extensions (DNSSEC). The original KEY resource record used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys in one record was a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY Resource Record Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are removed. Three existing application key sub-types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535. Working Group Summary There was WG rough concensus to advance this document; people agree that restricting KEY RR to the DNS keys is the right thing to do. However, some folks see a need to provide a replacement for the application key use of the KEY RR (whether it be APPKEY or something). Since there isn't agreement (see SIKED BoF) what problem something like APPKEY would solve, there isn't a ready replacement for this functionality at this point in time. Thus the WG rough concensus is to restrict-key now and defer the application key discussion. Protocol Quality This specification has been reviewed for the IESG by Erik Nordmark. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 18:25:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02164 for ; Wed, 18 Sep 2002 18:25:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rn9U-000DOe-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 15:18:32 -0700 Received: from bdsl.66.12.174.102.gte.net ([66.12.174.102] helo=mail.digitalmarketplace.com) by psg.com with esmtp (Exim 3.36 #1) id 17rn9Q-000DOT-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 15:18:29 -0700 Received: from win2kdev ([208.3.65.246]) by mail.digitalmarketplace.com with Microsoft SMTPSVC(5.5.1877.197.19); Wed, 18 Sep 2002 15:33:14 -0700 Reply-To: From: "Jason Coombs" To: "Mark Kosters" , "Jaap Akkerhuis" Cc: Subject: RE: opt-in and large zones Date: Wed, 18 Sep 2002 12:19:20 -1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020918205607.GF6566@slam.admin.cto.netsol.com> X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,OPT_IN,FOR_FREE,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Okay, here's my devil's advocate viewpoint. It wouldn't be hard to muster an army of volunteers who would gladly spend many man-years signing zones on behalf of domain registrants who think they don't want/need DNSSEC enough to pay for it if registrars who think they can't afford to deploy DNSSEC agree to let volunteers do all of the work for free that the registrars would otherwise have to do without additional compensation from registrants. Likewise, volunteers would gladly manage all extra burdens placed on TLD zone managers other than hardware, bandwidth, and electricity costs. All manpower costs are irrelevant when it comes to deploying DNSSEC because if the people who read this list really need manpower help to get the job done and really can't afford to pay for it all they need to do is explain the predicament in a public plea for help and give volunteers appropriate access permissions and software tools that enable them to shoulder the burden instead. Even with potential threats of key theft caused by the probable necessity of distributing many copies of the TLD zone signing private key to various volunteer coordinators and the possibility of cryptanalysis by way of chosen plaintext oracle attacks where a lazy volunteer coordinator fails to detect and prevent such a thing, the security improvement provided by signed DNS zones is critically-important to the integrity of Internet infrastructure and less-than-perfect is better than what we've got today with DNS. Considering that deployment and operations are the crux of the issue here, hasn't anyone drafted detailed business scenario and security scenario analysis documents that frame this debate? The technical issues are minor and somewhat philosophical. We're not talking about updating end-user client resolver libraries any time soon, that will always be optional... Either the client node wants DNSSEC and therefore updates its resolver or it is satisfied with IPSec-protected DNS where the DNS server does support DNSSEC otherwise the client node doesn't benefit from signed zones. However, automated DNSSEC crawlers can and should be implemented that verify signatures obtained from authoritative DNSSEC servers and then query every DNS server looking for poisoned RRs. Poisoned DNS servers can quickly be taken offline and daily security alerts could be issued by ICANN or CERT detailing known-poisoned DNS servers. With such a system in place we could deploy a good-enough initial protection simply by coordinating authentic communications from registrants to a single DNSSEC server that never gets queried by anything but the crawler and is managed entirely by volunteer staff. The nameservice protocol would still be DNSSEC and we would still need each TLD to have a key pair but the deployment could actually succeed in the near-term without convincing everyone that they need and want DNSSEC badly enough to invest money in it. And the initial population of the authoritative DNSSEC server would still be complete and automatic based on the current (perceived) contents of the authoritative nameservers for each domain. This way "opt-in" is unnecessary and those domains that are already compromised remain so in the DNSSEC until we receive authentic communications from the domain registrant offering corrections. Sincerely, Jason Coombs jasonc@science.org -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Mark Kosters Sent: Wednesday, September 18, 2002 10:56 AM To: Jaap Akkerhuis Cc: namedroppers@ops.ietf.org Subject: Re: opt-in and large zones On Wed, Sep 18, 2002 at 11:17:02AM +0200, Jaap Akkerhuis wrote: > That was my point. There are zones out there which are bigger then > .net & .org, and thus far I haven't noticed that folks > maintaining these zones want OPT-IN. Devil's advocate time. Have these zone maintainers taken the time to understand what it takes to deploy dnssec? I surmise that interest may not be there since there is no immediate demand from their customers to deploy dnssec. I base my assertion on that fact that I have yet to hear any interest either directly or indirectly from any registrar that deals with com/net/org that they want dnssec. Mark -- Mark Kosters markk@verisignlabs.com Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 19:01:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03023 for ; Wed, 18 Sep 2002 19:01:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rnk2-000FcJ-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 15:56:18 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17rnjy-000Fbt-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 15:56:14 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g8IMu7v12816; Wed, 18 Sep 2002 15:56:07 -0700 (PDT) From: Bill Manning Message-Id: <200209182256.g8IMu7v12816@boreas.isi.edu> Subject: Re: opt-in and large zones In-Reply-To: <20020918212324.GA2070@outpost.ds9a.nl> from bert hubert at "Sep 18, 2 11:23:24 pm" To: ahu@ds9a.nl (bert hubert) Date: Wed, 18 Sep 2002 15:56:07 -0700 (PDT) Cc: markk@verisignlabs.com, jaap@sidn.nl, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % While large registrars are part of our customer base, none has requested % DNSSEC as a 'must have' feature. So far people have assumed that DNSSEC was % deployable, right now it is starting to get known that there are major % issues separating DNSSEC from an infrastructure that can be deployed as a % money-making service. % % bert hubert % PowerDNS % Well, to be fair, modulo Pauls grousing about the 12+months it took to get from DS spec to code, "workable" DNSsec in the form of DS capable systems is pretty fresh. Three BIND snapshots. Roughly early June to present. Hardly time to raise "major issues" in a revenue-generating, production system. -- --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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 19:11:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03155 for ; Wed, 18 Sep 2002 19:11:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rnn5-000Fny-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 15:59:27 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17rnmy-000Fm5-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 15:59:21 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8IMwPB5061141; Thu, 19 Sep 2002 08:58:25 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200209182258.g8IMwPB5061141@drugs.dv.isc.org> To: Robert Elz Cc: Mark_Andrews@isc.org, Rob Austein , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSSEXT Yokohama Minutes In-reply-to: Your message of "Wed, 18 Sep 2002 18:23:21 +0700." <19941.1032348201@munnari.OZ.AU> Date: Thu, 19 Sep 2002 08:58:25 +1000 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Date: Wed, 18 Sep 2002 11:16:53 +1000 > From: Mark.Andrews@isc.org > Message-ID: <200209180116.g8I1GrB5055040@drugs.dv.isc.org> > > | * is internal to a zone, i.e. not the apex. > | NS records for delegation are supposed to be copies of the > | NS records in the child zone. > > They should be the same, yes. > > | Since * cannot be at the apex of the zone, > > What has that to do with anything? It has to do with the fact that you can't have a zone "*.example.com", hence you can't have a NS records in the parent with owner names of "*.example.com". Even if you were to create a server that supported a zone with a name of "*.example.com" that server would also *have* to serve example.com to ensure that the names that are in "example.com" get answered from the "example.com" zone and not "*.example.com". > Eg, say I have on server A > > $ORIGIN foo.example.com. > @ IN SOA ... > IN NS A.my.domain. > IN NS B.my.domain. > www IN A 1.2.3.4 > > Then on server Q, I have > > $ORIGIN example.com. > [normal stuff] > * IN NS A.my.domain. > IN NS B.my.domain. > > and no mention of "foo" anywhere in that zone at all. > > Then, someone does a lookup of www.foo.example.com > > The wildcard NS records exactly match the NS records at the apex of the > zone delegated. No problem at all. No they don't. They generate NS records for "www.foo.example.com" as * matches multiple labels. A.my.domain and B.my.domain serve "foo.example.com" not "www.foo.example.com". They all generate NS record for "sfdlhkljdfsljdsa.ldkshlkds.lljkklkkk.foo.example.com". Answers returned from the child servers will be rejected by todays servers as lame as the generated NS records will not match those returned from the child zone without re-defining * to be a single label for NS. Even then you will get lame delegations unless you have specialised child servers that accept "*.example.com" as a zone name, expand perform a single label expansion and serve the parent zone to ensure that the "*.example.com" "zone" doesn't match name in example.com. The only place I've seen an attempt to use * to "delegate" is in the IN-ADDR.ARPA tree. We created $GENERATE and offered it to dnsind to handle this case. It got rejected so we kept it as a implementation extention. Using a wildcard to "delegate" can provide no benefits over standard delegation and will lead to lame delegations. Mark > Of course, someone might also do a lookup of > > www.random.example.com. > > and you might think, that because A (and B) have never heard of > random.example.com this must necessarily be illegal. But first, > how can Q possibly tell the difference between these two cases? > > And second, A might be a "smart" server, that creates the zone upon > demand - that is the "$ORIGIN foo.example.com." zone above might have > been created by A when the (first) query for www.foo.example.com. appeared. > > I'm not saying that any of this is useful for anything much, but > > | you cannot have wilcard NS records in the parent. > > isn't supportable as an argument. > > 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. > archive: -- 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. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 19:32:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03776 for ; Wed, 18 Sep 2002 19:32:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17roCD-000HRW-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 16:25:25 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17roC9-000HR4-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 16:25:21 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 19B4A28B01; Wed, 18 Sep 2002 23:25:21 +0000 (GMT) From: Paul Vixie To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: inconsistency between rfc 2136 and rfc 2845 In-Reply-To: Message from Edward Lewis of "Wed, 18 Sep 2002 08:16:17 -0400." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 18 Sep 2002 23:25:21 +0000 Message-Id: <20020918232521.19B4A28B01@as.vix.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The issue is that in 2136 "NOTAUTH" seems to mean not authoritative > and in 2854 "NOTAUTH" seems to mean not authenticated. 2845 is tsig. what's 2854? the problem isn't inconsistency. any message type has its own uses for the various fixed header fields including RCODE. that's why EDNS adds more bits to RCODE without saying what they mean -- because EDNS is not opcode-specific other than where it explicitly says so, like the fact that OPT applies to opcode "query". 2845 can be viewed as wrong since it overloads an rcode pattern that means something else to a specific opcode, 2136 "update" in this case. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 18 19:49:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03993 for ; Wed, 18 Sep 2002 19:49:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17roUu-000IZq-00 for namedroppers-data@psg.com; Wed, 18 Sep 2002 16:44:44 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17roUq-000IZf-00 for namedroppers@ops.ietf.org; Wed, 18 Sep 2002 16:44:40 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g8INhpA19102; Wed, 18 Sep 2002 16:43:52 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 18 Sep 2002 16:43:51 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Mark.Andrews@isc.org cc: Robert Elz , Rob Austein , Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <200209182258.g8IMwPB5061141@drugs.dv.isc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 19 Sep 2002 Mark.Andrews@isc.org wrote: > > > Date: Wed, 18 Sep 2002 11:16:53 +1000 > > From: Mark.Andrews@isc.org > > Message-ID: <200209180116.g8I1GrB5055040@drugs.dv.isc.org> > > > > | * is internal to a zone, i.e. not the apex. > > | NS records for delegation are supposed to be copies of the > > | NS records in the child zone. > > > > They should be the same, yes. > > > > | Since * cannot be at the apex of the zone, > > > > What has that to do with anything? > > It has to do with the fact that you can't have a zone > "*.example.com", hence you can't have a NS records in the > parent with owner names of "*.example.com". I don't understand why not. I know that wildcard delegations won't work, but if I want to create a zone called "*.example.com", so that I can look up names like "foo.*.example.com", why can't I? BIND 9 explicitly checks for and rejects this zone, but this has no basis in the standards. You added this code :) > Even if you were to create a server that supported a zone with > a name of "*.example.com" that server would also *have* to serve > example.com to ensure that the names that are in "example.com" > get answered from the "example.com" zone and not "*.example.com". Why? Again, assuming * is used as a literal name, not a wildcard, the *.example.com zone would be the closest. The NS record at *.example.com only creates a delegation at *.example.com, not every name matched by the wildcard (see the name server algorithm in RFC 1034). I have absolutely no clue what the rest of the message means, so I'll stop here. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 05:18:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27617 for ; Thu, 19 Sep 2002 05:18:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rx9o-0002SC-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 01:59:32 -0700 Received: from [2001:610:ff:1::2] (helo=bartok.sidn.nl) by psg.com with esmtp (Exim 3.36 #1) id 17rx9j-0002RG-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 01:59:28 -0700 Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id g8J8xNpZ066183 for ; Thu, 19 Sep 2002 10:59:26 +0200 (CEST) (envelope-from jaap@bartok.sidn.nl) Message-Id: <200209190859.g8J8xNpZ066183@bartok.sidn.nl> To: namedroppers@ops.ietf.org Subject: Re: opt-in and large zones In-reply-to: Your message of Wed, 18 Sep 2002 16:56:07 -0400. <20020918205607.GF6566@slam.admin.cto.netsol.com> Date: Thu, 19 Sep 2002 10:59:23 +0200 From: Jaap Akkerhuis X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Devil's advocate time. Have these zone maintainers taken the time to understand what it takes to deploy dnssec? We, (.nl, 750 K delegations) are serious looking at this. Also, I know that (.de, 5++ M delegationsis looking at this as well. As far I know theyare on this maillists as well. Someother european registries are paying attention as well. I surmise that interest may not be there since there is no immediate demand from their customers to deploy dnssec. I base my assertion on that fact that I have yet to hear any interest either directly or indirectly from any registrar that deals with com/net/org that they want dnssec. We get occasional requests from domain name holders when we are going to do this in production (note when, not if), likewise, I heard the Germans do. Also, (some) registrars are interested. Our standard answer is that we have to wait until the protocol is done. jaap -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 05:47:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28260 for ; Thu, 19 Sep 2002 05:47:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rxdb-00049m-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 02:30:19 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17rxdU-00049O-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 02:30:15 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8J9Tt329670; Thu, 19 Sep 2002 16:29:55 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8J9TJK28775; Thu, 19 Sep 2002 16:29:24 +0700 (ICT) From: Robert Elz To: Mark.Andrews@isc.org cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <200209182258.g8IMwPB5061141@drugs.dv.isc.org> References: <200209182258.g8IMwPB5061141@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Sep 2002 16:29:19 +0700 Message-ID: <28773.1032427759@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 19 Sep 2002 08:58:25 +1000 From: Mark.Andrews@isc.org Message-ID: <200209182258.g8IMwPB5061141@drugs.dv.isc.org> I'll ignore the question of whether it is ever possible to have '*' as a label in the DNS, where it isn't a wildcard, as that isn't relevant to the question of wildcards, clearly. | A.my.domain and B.my.domain serve "foo.example.com" | not "www.foo.example.com". That could trivially be changed, if it was necessary... | They generate NS records for "www.foo.example.com" as * matches | multiple labels. It does usually, but it is possible that it does not for NS records, because of the "delegations stop wildcards" restriction. That is, '*' means everything possible (other than what exists). So, if there is a wildcard NS record, then (using the example from my last mail), there is necessarily a delegation for foo.example.com. Then, we get that clause from 1034 that says that wildcards don't survive delegations. Hence, the existence of the foo.example.com delegation, even without it being explicit, would mean that www.foo.example.com was not matched by the wildcard. Or at least that's the interpretation I was adopting in my last message. | They all generate NS record for | "sfdlhkljdfsljdsa.ldkshlkds.lljkklkkk.foo.example.com". Yes. So ? | Answers returned from the child servers will be rejected by todays | servers as lame as the generated NS records will not match those | returned from the child zone without re-defining * to be a single | label for NS. Huh? Since when does anyone (registries doing delegations excepted, or some of them...) actually go comparing the server names in NS records. Servers (resolvers) that did that would find half the universe as lame, as people keep sticking different names for their servers in their delegations than what's in the zone itself (for reasons I can't even begin to fathom, but they do). | Even then you will get lame delegations unless you | have specialised child servers that accept "*.example.com" as | a zone name, expand perform a single label expansion and serve | the parent zone to ensure that the "*.example.com" "zone" doesn't | match name in example.com. Possibly (without thinking about the details for now). But how to avoid lame servers wasn't the question. Whether it is legal in the first place to have wildcard NS was. | Using a wildcard to "delegate" can provide no benefits over | standard delegation and will lead to lame delegations. I don't disagree with that, in general (though I could probably dream up some exotic scenario where it would help, without causing lame delegations). But what's useful isn't what is being discussed. Wildcard SRV records are unquestionably legal, but they're almost certainly not useful. (that is *.example.com. IN SRV ... I don't mean *._http._tcp.example.com) That something isn't useful for anything doesn't make it illegal. 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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 06:29:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29065 for ; Thu, 19 Sep 2002 06:29:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ryTh-0007Jw-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 03:24:09 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17ryTc-0007JD-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 03:24:04 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id ED8C84505; Thu, 19 Sep 2002 12:24:02 +0200 (CEST) Date: Thu, 19 Sep 2002 12:24:02 +0200 From: bert hubert To: Bill Manning Cc: markk@verisignlabs.com, jaap@sidn.nl, namedroppers@ops.ietf.org Subject: Re: opt-in and large zones Message-ID: <20020919102402.GA14852@outpost.ds9a.nl> References: <20020918212324.GA2070@outpost.ds9a.nl> <200209182256.g8IMu7v12816@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209182256.g8IMu7v12816@boreas.isi.edu> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,OPT_IN,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Sep 18, 2002 at 03:56:07PM -0700, Bill Manning wrote: > Well, to be fair, modulo Pauls grousing about the 12+months it took > to get from DS spec to code, "workable" DNSsec in the form of DS > capable systems is pretty fresh. Three BIND snapshots. Roughly > early June to present. Hardly time to raise "major issues" > in a revenue-generating, production system. The interesting thing to note is that right now time is working against DNSSEC. Originally we received a lot of questions about our DNSSEC commitment because people assumed that because there was an RFC and DNSSEC was mentioned in Bind9 release notes, there would be a deployable protocol. Right now, the perception is growing that DNSSEC is going the way of CORBA, OSI, X.500 and other flightless protocols. Protocols which are fraught with difficulties but were designed to please the computer scientist in us. Even within the DNS community, transparency has not been great. Even we (PowerDNS) assumed that DNSSEC was workable until Olaf educated us at HAL2001 about the problems with key rollover and the need for DS. That conclusion was a long time overdue. Right now I see you claiming that DNSSEC is innocent until proven guilty by results from revenue-generating production systems while Phillip, who is speaking for himself, but important nonetheless, claims that is is fundamentally broken. It looks like that the window of opportunity for DNSSEC is closing. Any initial enthusiasm based on the mistaken perception that the protocol was ready is now vanishing. The protocol is not getting any simpler and ready to deploy, which would help counter the lack of buy-in so far. Perhaps the time has come to reverse some things and design a new DNSSEC that is more aimed at achieving goals people are waiting for. Perhaps DNS need not even be the protocol used - DNS in and of itself is a very simpleminded network API. People wanting security may well want to use a different protocol instead of riding on the coattails of a 1980s one not very well suited for large messages and complicated semantics. Let's not stick to our UDP port 53 packets 'because'. DNSSEC may get a 'boost' because it piggybacks on an existing protocol but the hacks to get DNSSEC to travel existing infrastructure are getting grosser by the hour - DS is a case in point. This perceived boost may well have cost us years. Kind regards, bert hubert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 09:20:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03844 for ; Thu, 19 Sep 2002 09:20:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s13V-000HHl-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 06:09:17 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17s13P-000HHX-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 06:09:11 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g8JD9FRF069366; Thu, 19 Sep 2002 09:09:15 -0400 (EDT) Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA06208; Thu, 19 Sep 2002 09:09:09 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20020918232521.19B4A28B01@as.vix.com> References: <20020918232521.19B4A28B01@as.vix.com> Date: Thu, 19 Sep 2002 09:07:39 -0400 To: Paul Vixie , Edward Lewis From: Edward Lewis Subject: Re: inconsistency between rfc 2136 and rfc 2845 Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:25PM +0000 9/18/02, Paul Vixie wrote: >> The issue is that in 2136 "NOTAUTH" seems to mean not authoritative >> and in 2854 "NOTAUTH" seems to mean not authenticated. > >2845 is tsig. what's 2854? 9 mroe than 2845. Partail cerdit fro at laest gettnig the set of dgiits rihgt? >2845 can be viewed as wrong since it overloads an rcode pattern that >means something else to a specific opcode, 2136 "update" in this case. to-may-to, to-mah-to. I.e., yeah, what you said, too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 09:57:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05620 for ; Thu, 19 Sep 2002 09:57:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s1hU-000Jrs-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 06:50:36 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17s1hR-000Jrg-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 06:50:33 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g8JDoS9M008897 for ; Thu, 19 Sep 2002 06:50:28 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Sep 2002 06:52:23 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869BB9@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: RE: opt-in and large zones Date: Thu, 19 Sep 2002 06:52:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.1 required=5.0 tests=OPT_IN version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Right now I see you claiming that DNSSEC is innocent until > proven guilty by > results from revenue-generating production systems while > Phillip, who is > speaking for himself, but important nonetheless, claims that is is > fundamentally broken. No, I said that it is broken as specified but we know how to fix it. I did not say 'fundamentaly'. Scale is an engineering issue. > It looks like that the window of opportunity for DNSSEC is > closing. I think that the longer people delay agreement on a deployable protocol, the less chance of success we have. 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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 12:36:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13250 for ; Thu, 19 Sep 2002 12:36:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s446-0003ti-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 09:22:06 -0700 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 17s442-0003tX-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 09:22:02 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8JGLnpX024310; Thu, 19 Sep 2002 18:21:49 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.5/8.12.5/Debian-1) with ESMTP id g8JGLkBS024306; Thu, 19 Sep 2002 18:21:48 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Thu, 19 Sep 2002 18:21:46 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: David Conrad cc: Jakob Schlyter , "Hallam-Baker, Phillip" , Brian Wellington , Jaap Akkerhuis , "'Edward Lewis'" , namedroppers Subject: Re: wildcards, dnssec, and opt-in In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,OPT_IN version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, David Conrad wrote: > Roy, > > On 9/18/02 8:39 AM, "Roy Arends" wrote: > > On Wed, 18 Sep 2002, Jakob Schlyter wrote: > >> On Wed, 18 Sep 2002, Roy Arends wrote: > >>>> people will deploy dnssec either to increase the security of the dns or to > >>>> make money. I would guess verisign falls into the second category. > >>> Nonsense. > >>> > >>> People will deploy dnssec to increase the security of the DNS and (or) not > >>> to loose money (because of lack of security). These are effectively the > >>> same. > >> > >> yes, that may be true for end-zone administrators - I was talking about > >> the registry. > > > > fud, stop it :-) > > This is not FUD. > > Whether any registry deploys DNSSEC is a business decision of that registry. > The registry, by and large, is not affected by the integrity issues DNSSEC > protects against. If the registry's customers really want (that is, be > willing to pay for) DNSSEC, it will get deployed, regardless of the > implications that deployment might have on the registry's infrastructure. You just proved my point. Not deploying DNSSEC means loosing money. No commercial entity will be healthy just living by the promise of loosing money. But that might not be the only motivation. > Unfortunately, to date, there has not been significant demand for DNSSEC > from customers. As such, any registry that considers deploying it must be > willing to assume some risk, believing that in the future customers will > want DNSSEC. What I take Phill's comments to mean is that Verisign is not > willing to take the risk. Take Phill's comment for what they are, I was merely responding to the 2 extreme motivations to "deploy dnssec" that were presented by Jakob, as if no other motivations where possible. That, and the fact that his conclusions where based without motivation, and on a technical list like this, lead me to conclude it was FUD. It still is. roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 13:17:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14773 for ; Thu, 19 Sep 2002 13:17:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s4k9-0006qC-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 10:05:33 -0700 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 17s4k4-0006pA-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 10:05:28 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with SMTP id g8JH5Pv21950; Thu, 19 Sep 2002 19:05:25 +0200 (MEST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id TAA11974; Thu, 19 Sep 2002 19:05:25 +0200 Message-Id: <200209191705.TAA11974@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Robert Elz Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-reply-to: Your message of "Thu, 19 Sep 2002 16:29:19 +0700." <28773.1032427759@munnari.OZ.AU> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Thu, 19 Sep 2002 19:05:25 +0200 From: Peter Koch X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk kre wrote: > | Answers returned from the child servers will be rejected by todays > | servers as lame as the generated NS records will not match those > | returned from the child zone without re-defining * to be a single > | label for NS. > > Huh? Since when does anyone (registries doing delegations excepted, or > some of them...) actually go comparing the server names in NS records. the more important part might be the actual owner of that NS RR identifying the zone's apex. For the server names in RDATA, you're right - that would be fun - not. But then, I'd not call delegations failing these validity checks `lame'. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 17:56:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24649 for ; Thu, 19 Sep 2002 17:56:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s8zr-0000ft-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 14:38:03 -0700 Received: from h140.s251.netsol.com ([216.168.251.140] helo=pinion.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17s8zl-0000fS-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 14:37:57 -0700 Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id 8E61E1AF0D; Thu, 19 Sep 2002 17:37:56 -0400 (EDT) To: namedroppers@ops.ietf.org Subject: opt-in and wildcards From: David Blacka Date: Thu, 19 Sep 2002 17:37:56 -0400 Message-ID: Lines: 104 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-mandrake-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=3.2 required=5.0 tests=OPT_IN,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ok, I've been thinking about the interactions between opt-in and wildcards in dnssec. I apologize if this is redundant. I also apologize for the rather long length. So far the following questions have more or less been raised: 1) Do wildcard NXT proofs need to be returned with positive opt-in answers (that is, when an opt-in server is returning a "opted-out" insecure delegation)? 2) Should a signed wildcard record be able to trump an insecure delegation when both are available to the resolver? I am ignoring the thread talking about getting rid of wildcards in DNSSEC altogether. First, suppose the answer to question #1 is yes, wildcard proofs are to be returned. Then we might see a response like: Q: foo.example A ANS: AUTH: foo.example NS <...> e NXT g ... (opt-in) e SIG NXT ... example NXT a ... (no wildcard). example SIG NXT ... ADD: ... which seems fine. But, what happens when a wildcard actually exists? Then maybe we would see a response like this: Q: foo.example A AUTH: foo.example NS <...> e NXT g ... (opt-in) (proof the the wildcard exists) foo.example A 1.1.1.1 foo.example SIG A (labels = 1) The resolver is presented both with a delegation and a wildcard. This leads us to question #2. In this scenario, if the resolver were to believe the wildcard over the delegation, essentially insecure delegations in opt-in zone would simply not work because the wildcard would mask all the insecure delegations. So the answer to question #2 would seem to be No. If the answer was yes, then I think we would be giving new power to wildcard records that was never intended. The reasoning above suggests that the answer to question #1 is also No. However, it is probably not sufficient to go by this reasoning alone. So considering question #1 more directly: With opt-in, insecure delegations may be modified, added, or removed within the insecure spans within the zone. The current draft language is With Opt-In, a malicious entity is able to: insert, modify, or delete insecure delegation RRsets within a secured zone. Because of this, a resolver cannot detect whether or not a particular insecure delegation response was spoofed or not. Since the delegation might actually be real, the resolver really has no choice but to believe that it is real. The presence or absence of a matching wildcard becomes not relevant, because the resolver cannot make a decision based on that fact. Looking at this (yet) another way, we can see that an attacker could replace an insecure delegation with a wildcard expansion, thus effective removing the delegation. Of course, the attacker could already have done that. Also an attacker could replace a wildcard expansion with a spoofed delegation (pointing wherever the attacker wished). This is not really a different security concern from the first form of attack, but it does show that the language in the draft does not go far enough. I will point out that although wildcard records are signed, their expanded names are not. Perhaps the opt-in draft's security consideration language should be more along the lines of: With Opt-In, a malicious entity is able to: insert, modify, or delete insecure delegation RRsets within a secured zone. A malicious entity is also able to replay or delete wildcard expansions within insecure spans in the zone. Or perhaps: With Opt-In, a malicious entity is able to insert, modify or remove RRsets within the insecure spans of a secured zone. The RRsets are limited to insecure delegations and wildcard expansions. So the answer to question #1 is No. Opt-In does not change the fact that negative wildcard proofs are needed in an NXDOMAIN response, just like non-opt-in. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 20:28:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27393 for ; Thu, 19 Sep 2002 20:28:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sBY4-000CIP-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 17:21:32 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17sBXz-000CI6-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 17:21:27 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8K0KeB5065232; Fri, 20 Sep 2002 10:20:42 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200209200020.g8K0KeB5065232@drugs.dv.isc.org> To: Robert Elz Cc: Rob Austein , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSSEXT Yokohama Minutes In-reply-to: Your message of "Thu, 19 Sep 2002 16:29:19 +0700." <28773.1032427759@munnari.OZ.AU> Date: Fri, 20 Sep 2002 10:20:40 +1000 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Date: Thu, 19 Sep 2002 08:58:25 +1000 > From: Mark.Andrews@isc.org > Message-ID: <200209182258.g8IMwPB5061141@drugs.dv.isc.org> > > I'll ignore the question of whether it is ever possible to have > '*' as a label in the DNS, where it isn't a wildcard, as that isn't > relevant to the question of wildcards, clearly. > > | A.my.domain and B.my.domain serve "foo.example.com" > | not "www.foo.example.com". > > That could trivially be changed, if it was necessary... > > | They generate NS records for "www.foo.example.com" as * matches > | multiple labels. > > It does usually, but it is possible that it does not for NS records, > because of the "delegations stop wildcards" restriction. That is, '*' means > everything possible (other than what exists). So, if there is a wildcard > NS record, then (using the example from my last mail), there is > necessarily a delegation for foo.example.com. Then, we get that clause > from 1034 that says that wildcards don't survive delegations. Hence, > the existence of the foo.example.com delegation, even without it being > explicit, would mean that www.foo.example.com was not matched by the wildcard > . Well I've always read "that wildcards don't survive delegations" to mean that wildcards can't apply to delgations as you have delegated "foo.example.com" hence the wildcard can't match "foo.example.com". Mark > > Or at least that's the interpretation I was adopting in my last message. > > | They all generate NS record for > | "sfdlhkljdfsljdsa.ldkshlkds.lljkklkkk.foo.example.com". > > Yes. So ? > > | Answers returned from the child servers will be rejected by todays > | servers as lame as the generated NS records will not match those > | returned from the child zone without re-defining * to be a single > | label for NS. > > Huh? Since when does anyone (registries doing delegations excepted, or > some of them...) actually go comparing the server names in NS records. > Servers (resolvers) that did that would find half the universe as lame, > as people keep sticking different names for their servers in their > delegations than what's in the zone itself (for reasons I can't even > begin to fathom, but they do). > > | Even then you will get lame delegations unless you > | have specialised child servers that accept "*.example.com" as > | a zone name, expand perform a single label expansion and serve > | the parent zone to ensure that the "*.example.com" "zone" doesn't > | match name in example.com. > > Possibly (without thinking about the details for now). But how to > avoid lame servers wasn't the question. Whether it is legal in the > first place to have wildcard NS was. > > | Using a wildcard to "delegate" can provide no benefits over > | standard delegation and will lead to lame delegations. > > I don't disagree with that, in general (though I could probably dream up > some exotic scenario where it would help, without causing lame delegations). > > But what's useful isn't what is being discussed. Wildcard SRV records > are unquestionably legal, but they're almost certainly not useful. > (that is *.example.com. IN SRV ... I don't mean *._http._tcp.example.com) > > That something isn't useful for anything doesn't make it illegal. > > kre > -- 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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 19 21:28:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28809 for ; Thu, 19 Sep 2002 21:28:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sCTC-000GYb-00 for namedroppers-data@psg.com; Thu, 19 Sep 2002 18:20:34 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17sCT7-000GY2-00 for namedroppers@ops.ietf.org; Thu, 19 Sep 2002 18:20:29 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8K1KGB5066392; Fri, 20 Sep 2002 11:20:17 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200209200120.g8K1KGB5066392@drugs.dv.isc.org> To: Peter Koch Cc: Robert Elz , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSSEXT Yokohama Minutes In-reply-to: Your message of "Thu, 19 Sep 2002 19:05:25 +0200." <200209191705.TAA11974@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Fri, 20 Sep 2002 11:20:16 +1000 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > kre wrote: > > > | Answers returned from the child servers will be rejected by tod > ays > > | servers as lame as the generated NS records will not match thos > e > > | returned from the child zone without re-defining * to be a sing > le > > | label for NS. > > > > Huh? Since when does anyone (registries doing delegations excepted, or > > some of them...) actually go comparing the server names in NS records. > > the more important part might be the actual owner of that NS RR identifying > the zone's apex. For the server names in RDATA, you're right - that would > be fun - not. But then, I'd not call delegations failing these validity > checks `lame'. > > -Peter I meant the parent server says that a zone "www.foo.example.com" exists then the child says I serving "foo.example.com" not "www.foo.example.com". This is no different to those sites that are lazy and use a "com" zone for all there delegations under com. It's a lame delegation and a cache poisioning attack so we have to look for it. 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. archive: From owner-namedroppers@ops.ietf.org Fri Sep 20 07:59:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19350 for ; Fri, 20 Sep 2002 07:59:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sMDP-0007aL-00 for namedroppers-data@psg.com; Fri, 20 Sep 2002 04:44:55 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17sMDH-0007Nw-00 for namedroppers@ops.ietf.org; Fri, 20 Sep 2002 04:44:49 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8KBeo305352; Fri, 20 Sep 2002 18:40:50 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8KBdKK04628; Fri, 20 Sep 2002 18:39:27 +0700 (ICT) From: Robert Elz To: Mark.Andrews@isc.org cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: DNSSEXT Yokohama Minutes In-Reply-To: <200209200020.g8K0KeB5065232@drugs.dv.isc.org> References: <200209200020.g8K0KeB5065232@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Sep 2002 18:39:20 +0700 Message-ID: <4626.1032521960@munnari.OZ.AU> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,PORN_10,PORN_3 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 20 Sep 2002 10:20:40 +1000 From: Mark.Andrews@isc.org Message-ID: <200209200020.g8K0KeB5065232@drugs.dv.isc.org> | Well I've always read "that wildcards don't survive delegations" | to mean that wildcards can't apply to delgations as you have | delegated "foo.example.com" hence the wildcard can't match | "foo.example.com". But that would be meaningless, as (at least without wildcard NS records). If foo.example.com exists, then it is a - When the query name or a name between the wildcard domain and the query name is know to exist. [sic] We wold know that foo.example.com exists, if we have explicitly delegated it, obviously, and hence the wildcard could not apply to anything below foo.example.com (just as it could not if foo.example.com merely had an A record, it is still a known name, and hence, the wildcard *.example.com cannot make www.foo.example.com exist). Hence, what is - When the query is in another zone. That is, delegation cancels the wildcard defaults. actually for? Here I'm guessing, not stating the intent of the time, or of the authors. But it might be interpreted as assuming * IN NS xxx delegates every (unknown) sub-domain. Then every query to anything a.b.$ORIGIN would necessarily be to something in another zone, as the wildcard would delegate b.$ORIGIN (should anyone bother to ask). Then, the restriction would mean that this delegation cancels the wildcard. and in particular, www.foo.example.com. would not match the wildcard in my previous message, but foo.example.com. would be delegated, implicitly, and hence a referral would be correct behaviour. I'm not attached to this interpretation in any way, I'm not claiming that it is the correct one (any better knowledge on why this particular restriction is there gratefully accepted - even better if backed by some contemporary evidence, rather than "looking back, it must have meant...) Mark.Andrews@isc.org said in another message: | I meant the parent server says that a zone "www.foo.example.com" | exists then the child says I serving "foo.example.com" not | "www.foo.example.com". Yes, I know, but if the correct interpretation of the wildcard were that www.foo.example.com was delegated, then I would have made the server for the child serve that zone. It was the way it was, only because I was assuming the interpretation above. 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. archive: From owner-namedroppers@ops.ietf.org Fri Sep 20 08:07:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19567 for ; Fri, 20 Sep 2002 08:07:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sMMO-0008CE-00 for namedroppers-data@psg.com; Fri, 20 Sep 2002 04:54:12 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17sMMJ-0008By-00 for namedroppers@ops.ietf.org; Fri, 20 Sep 2002 04:54:07 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18943; Fri, 20 Sep 2002 07:52:18 -0400 (EDT) Message-Id: <200209201152.HAA18943@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-unknown-rrs-04.txt Date: Fri, 20 Sep 2002 07:52:17 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Handling of Unknown DNS RR Types Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-unknown-rrs-04.txt Pages : 7 Date : 2002-9-19 Extending the Domain Name System with new Resource Record types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-dnsext-unknown-rrs-04.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-ietf-dnsext-unknown-rrs-04.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-19154612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-unknown-rrs-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-unknown-rrs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-19154612.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 20 11:59:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27184 for ; Fri, 20 Sep 2002 11:59:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sQ0a-000OA9-00 for namedroppers-data@psg.com; Fri, 20 Sep 2002 08:47:56 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 17sQ0V-000O96-00 for namedroppers@ops.ietf.org; Fri, 20 Sep 2002 08:47:51 -0700 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id g8KFlnKu004098 for ; Fri, 20 Sep 2002 17:47:50 +0200 Date: Fri, 20 Sep 2002 17:47:49 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSSEC wildcard optimization. Message-Id: <20020920174749.66e929e4.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: NONE ; -1000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit L.S. Below is a link to a document describing an optimization to the wildcard algorithm resulting in the need for only 1 NXT/SIG for when there are no wildcards in the zone. Even if there are wildcards in the zone 1 NXT/SIG may be sufficient. http://www.ripe.net/DISI/Notes/draft-olaf-dnsext-dnssec-wildcard-optimization-00.txt --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 23 15:55:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22566 for ; Mon, 23 Sep 2002 15:55:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tYxq-000Cgf-00 for namedroppers-data@psg.com; Mon, 23 Sep 2002 12:33:50 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17tYxn-000CgS-00 for namedroppers@ops.ietf.org; Mon, 23 Sep 2002 12:33:47 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21744; Mon, 23 Sep 2002 15:31:39 -0400 (EDT) Message-Id: <200209231931.PAA21744@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: Obsoleting IQUERY to Proposed Standard Date: Mon, 23 Sep 2002 15:31:39 -0400 X-Spam-Status: No, hits=1.1 required=5.0 tests=TO_MALFORMED version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the Internet-Draft 'Obsoleting IQUERY' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary The IQUERY method of performing inverse DNS lookups, specified in RFC 1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using PTR queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation and updates RFC 1035 to declare it entirely obsolete. Working Group Summary There was concensus in the WG to advance this document. Protocol Quality DNS server implementations have had IQUERY disabled for a very long time without any adverse effects. This document has been reviewed for the IESG by Erik Nordmark. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 24 04:59:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20468 for ; Tue, 24 Sep 2002 04:59:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tlJo-000KMX-00 for namedroppers-data@psg.com; Tue, 24 Sep 2002 01:45:20 -0700 Received: from [217.144.230.27] (helo=lexx.infeline.org) by psg.com with smtp (Exim 3.36 #1) id 17tlJk-000KMM-00 for namedroppers@ops.ietf.org; Tue, 24 Sep 2002 01:45:16 -0700 Received: (qmail 25163 invoked by alias); 24 Sep 2002 08:45:14 -0000 Received: from fw.gnr.datavakten.no (HELO ketil.np) (ketil@195.159.40.105) by lexx.infeline.org with SMTP; 24 Sep 2002 08:45:14 -0000 Date: Tue, 24 Sep 2002 10:46:17 +0200 (CEST) From: Ketil Froyn X-X-Sender: ketil@ketil.np To: "namedroppers@ops.ietf.org" Subject: RFC1996 and IXFR dependency graph loops Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello. Section 2.2 of RFC1996 states: 2.2. The zone's servers must be organized into a dependency graph such that there is a primary master, and all other servers must use AXFR or IXFR either from the primary master or from some slave which is also a master. No loops are permitted in the AXFR dependency graph. I read this to mean that loops in IXFR dependency graphs are legal, but loops in AXFR dependency graphs are not. Does anyone know the reason AXFR loops are not allowed, and then the reason why IXFR loops are ok? Thanks, Ketil -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 24 05:17:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20715 for ; Tue, 24 Sep 2002 05:17:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tleD-000LOb-00 for namedroppers-data@psg.com; Tue, 24 Sep 2002 02:06:25 -0700 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 17tle9-000LOK-00 for namedroppers@ops.ietf.org; Tue, 24 Sep 2002 02:06:21 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.11.6/TechFak/pk+ro20010720) with SMTP id g8O96Iv24709; Tue, 24 Sep 2002 11:06:18 +0200 (MEST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id LAA23359; Tue, 24 Sep 2002 11:06:18 +0200 Message-Id: <200209240906.LAA23359@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Ketil Froyn Cc: "namedroppers@ops.ietf.org" Subject: Re: RFC1996 and IXFR dependency graph loops In-reply-to: Your message of "Tue, 24 Sep 2002 10:46:17 +0200." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Tue, 24 Sep 2002 11:06:18 +0200 From: Peter Koch X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I read this to mean that loops in IXFR dependency graphs are legal, but > loops in AXFR dependency graphs are not. Does anyone know the reason AXFR > loops are not allowed, and then the reason why IXFR loops are ok? There are no two graphs, since the dependencies are intended to be the same whether you use AXFR or IXFR. The graph has just been named after AXFR where *XFR - or something similar - might have been less specific and thus would have avoided the ambiguity you've seen. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 24 05:43:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21010 for ; Tue, 24 Sep 2002 05:43:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tm3Q-000MhN-00 for namedroppers-data@psg.com; Tue, 24 Sep 2002 02:32:28 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17tm3N-000MhA-00 for namedroppers@ops.ietf.org; Tue, 24 Sep 2002 02:32:25 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id F1FCF28B6E; Tue, 24 Sep 2002 09:32:24 +0000 (GMT) From: Paul Vixie To: Ketil Froyn Cc: "namedroppers@ops.ietf.org" Subject: Re: RFC1996 and IXFR dependency graph loops In-Reply-To: Message from Ketil Froyn of "Tue, 24 Sep 2002 10:46:17 +0200." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 24 Sep 2002 09:32:24 +0000 Message-Id: <20020924093224.F1FCF28B6E@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk that's a typo. should say "No loops are permitted in the AXFR/IXFR dependency graph." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 24 05:46:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21050 for ; Tue, 24 Sep 2002 05:46:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tmAd-000N42-00 for namedroppers-data@psg.com; Tue, 24 Sep 2002 02:39:55 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17tmAa-000N3o-00 for namedroppers@ops.ietf.org; Tue, 24 Sep 2002 02:39:52 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g8O9dfB5086392; Tue, 24 Sep 2002 19:39:41 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200209240939.g8O9dfB5086392@drugs.dv.isc.org> To: Ketil Froyn Cc: "namedroppers@ops.ietf.org" From: Mark.Andrews@isc.org Subject: Re: RFC1996 and IXFR dependency graph loops In-reply-to: Your message of "Tue, 24 Sep 2002 10:46:17 +0200." Date: Tue, 24 Sep 2002 19:39:41 +1000 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Hello. > > Section 2.2 of RFC1996 states: > > 2.2. The zone's servers must be organized into a dependency graph > such that there is a primary master, and all other servers must use > AXFR or IXFR either from the primary master or from some slave which > is also a master. No loops are permitted in the AXFR dependency > graph. > > I read this to mean that loops in IXFR dependency graphs are legal, but > loops in AXFR dependency graphs are not. Does anyone know the reason AXFR > loops are not allowed, and then the reason why IXFR loops are ok? They arn't. > > Thanks, > Ketil > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- 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. archive: From owner-namedroppers@ops.ietf.org Thu Sep 26 08:50:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05109 for ; Thu, 26 Sep 2002 08:50:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uXqg-000HBQ-00 for namedroppers-data@psg.com; Thu, 26 Sep 2002 05:34:30 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17uXqc-000HBA-00 for namedroppers@ops.ietf.org; Thu, 26 Sep 2002 05:34:26 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04209; Thu, 26 Sep 2002 08:32:31 -0400 (EDT) Message-Id: <200209261232.IAA04209@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tkey-renewal-mode-02.txt Date: Thu, 26 Sep 2002 08:32:31 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : TKEY Secret Key Renewal Mode Author(s) : Y. Kamite, M. Nakayama Filename : draft-ietf-dnsext-tkey-renewal-mode-02.txt Pages : 21 Date : 2002-9-25 This document defines a new mode in TKEY [RFC2930] and proposes an atomic method for changing secret keys used for TSIG [RFC2845] periodically. Originally, TKEY provides methods of setting up shared secrets other than manual exchange, but it cannot control timing of key renewal very well though it can add or delete shared keys separately. This proposal is a systematical key renewal procedure intended for preventing signing DNS messages with old and non-safe keys permanently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-dnsext-tkey-renewal-mode-02.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-ietf-dnsext-tkey-renewal-mode-02.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-25142139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-renewal-mode-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-25142139.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Sep 28 08:08:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03957 for ; Sat, 28 Sep 2002 08:08:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vG4Q-000I6A-00 for namedroppers-data@psg.com; Sat, 28 Sep 2002 04:47:38 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17vG4M-000I5z-00 for namedroppers@ops.ietf.org; Sat, 28 Sep 2002 04:47:34 -0700 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g8SBkOh56384 for ; Sat, 28 Sep 2002 07:46:26 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020928054614.01f09ff0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sat, 28 Sep 2002 05:47:08 -0400 To: namedroppers From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Agenda items for DNSEXT at IETF-45 in Atlanta Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.5 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Please send them in to me. 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. archive: From owner-namedroppers@ops.ietf.org Sat Sep 28 12:31:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07215 for ; Sat, 28 Sep 2002 12:31:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vKLs-000OJw-00 for namedroppers-data@psg.com; Sat, 28 Sep 2002 09:21:56 -0700 Received: from [195.224.154.146] (helo=strider.u-pol.com) by psg.com with esmtp (Exim 3.36 #1) id 17vKLp-000OJh-00 for namedroppers@ops.ietf.org; Sat, 28 Sep 2002 09:21:53 -0700 Received: from merry.u-pol.com ([192.168.100.30]) by strider.u-pol.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 28 Sep 2002 17:21:51 +0100 thread-index: AcJnCybibJRgpQbsSVmFQEDhg2azGg== Received: from MERRY ([192.168.100.30]) by merry.u-pol.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 28 Sep 2002 17:21:51 +0100 To: Cc: , , , X-From_: owner-dnsop@cafax.se Fri Aug 30 13:40:33 2002 X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869B38@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" Subject: RE: dnssec discussion today at noon Date: Mon, 22 Jul 2002 10:14:46 -0700 Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Internet Mail Service (5.5.2653.19) Importance: normal Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-OriginalArrivalTime: 28 Sep 2002 16:21:51.0181 (UTC) FILETIME=[26B9D7D0:01C2670B] X-Spam-Status: No, hits=0.2 required=5.0 tests=X_AUTH_WARNING,DATE_IN_PAST_96_XX version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07215 > > This assumes perfect implementation of the cryptography and the > > manner in which cryptography is used (and the whole rest of the > > system). Schneier teaches us that this is a highly unlikely > > situation to occur anywhere. > > I'm teching you Schneier (whoever he is) is wrong, then. I am not too sure that Bruce made quite the point originally stated, and if he did make it one should take a look at some other statements Bruce has been known to state before necessarily taking his word as gospel. In fact I would suspect that a more accurate representation of Bruce's position would be 'think about the protocol, don't depend on dogma, including dogma that you might find attributed to me.' 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. archive: From owner-namedroppers@ops.ietf.org Sat Sep 28 13:18:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07214 for ; Sat, 28 Sep 2002 12:31:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vKM1-000OK4-00 for namedroppers-data@psg.com; Sat, 28 Sep 2002 09:22:05 -0700 Received: from [195.224.154.146] (helo=strider.u-pol.com) by psg.com with esmtp (Exim 3.36 #1) id 17vKLq-000OJh-00 for namedroppers@ops.ietf.org; Sat, 28 Sep 2002 09:21:54 -0700 Received: from merry.u-pol.com ([192.168.100.30]) by strider.u-pol.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 28 Sep 2002 17:21:52 +0100 thread-index: AcJnCydBKLmwE5PWR/+JyjSPgLO6cw== Received: from MERRY ([192.168.100.30]) by merry.u-pol.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 28 Sep 2002 17:21:51 +0100 To: Cc: , , X-From_: owner-dnsop@cafax.se Fri Aug 30 13:40:33 2002 X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D1CB2B1@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" Subject: RE: dnssec discussion today at noon Date: Mon, 22 Jul 2002 13:22:06 -0700 Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Internet Mail Service (5.5.2653.19) Importance: normal Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-OriginalArrivalTime: 28 Sep 2002 16:21:51.0838 (UTC) FILETIME=[271E17E0:01C2670B] X-Spam-Status: No, hits=0.2 required=5.0 tests=X_AUTH_WARNING,DATE_IN_PAST_96_XX version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07214 > You have clearly never been to an hotel where their Internet services > intercept all DNS queries regardless of where you send the message... > You cannot trust the infrastructure not to misbehave. Answer, I tend not to pay $10 per night just to surf the Internet from a hotel room and when I have I have been using a VPN which encrypts all the trafic. Question, what do you want the infrastructure to do in this situation? I believe that what a secure DNS infrastructure should do is inform you that you are subject to a DNS MiM attack. If you are going to use secure DNS then you probably want to use IPSEC to protect you trafic from hotel rooms and the like. If the institution blocks IPSEC then you should probably apply Moscow rules and not use the Internet at all. 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. archive: