From owner-namedroppers@ops.ietf.org Mon Apr 1 06:21:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18171 for ; Mon, 1 Apr 2002 06:21:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16rzXd-0007kY-00 for namedroppers-data@psg.com; Mon, 01 Apr 2002 03:00:01 -0800 Received: from randy by psg.com with local (Exim 3.35 #1) id 16rzXc-0007kS-00 for namedroppers@ops.ietf.org; Mon, 01 Apr 2002 03:00:00 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Mon, 01 Apr 2002 03:00:00 -0800 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. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. 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 Mon Apr 1 21:16:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21871 for ; Mon, 1 Apr 2002 21:16:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sDZy-000IRB-00 for namedroppers-data@psg.com; Mon, 01 Apr 2002 17:59:22 -0800 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.35 #1) id 16sDZx-000IR2-00 for namedroppers@ops.ietf.org; Mon, 01 Apr 2002 17:59:21 -0800 Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g321xFo86613 for ; Tue, 2 Apr 2002 10:59:15 +0900 (JST) Date: Tue, 02 Apr 2002 10:59:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: <20020329204419.2A23A1C11@thrintun.hactrn.net> References: <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> <20020328094454.A5859@connect.com.au> <20020329204419.2A23A1C11@thrintun.hactrn.net> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 25 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Fri, 29 Mar 2002 15:44:18 -0500, >>>>> Rob Austein said: >> In any case, it would be sure that we need some compromise here. How >> can we make it? > The options that I can see are: > a) Accept the course of action recommended by the draft currently in > last call, and with the understanding that this is and will remain > at best a very rough consensus; or > b) Flip a coin, if everyone involved would be willing to abide by the > result (probability of which left as an exercise for the reader); or > c) Sign the horse up for another year of singing lessons. So we have almost no choice:-) I'd like to know what others think. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 2 02:02:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03495 for ; Tue, 2 Apr 2002 02:02:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sI5G-0000pv-00 for namedroppers-data@psg.com; Mon, 01 Apr 2002 22:47:58 -0800 Received: from nara.off.connect.com.au ([192.94.41.40]) by psg.com with esmtp (Exim 3.35 #1) id 16sI5B-0000p5-00 for namedroppers@ops.ietf.org; Mon, 01 Apr 2002 22:47:57 -0800 Received: (from njones@localhost) by nara.off.connect.com.au id QAA15173 (8.8.8/IDA-1.7); Tue, 2 Apr 2002 16:47:51 +1000 (EST) Message-ID: <20020402164751.E19210@connect.com.au> Date: Tue, 2 Apr 2002 16:47:51 +1000 From: Nathan Jones To: namedroppers@ops.ietf.org Cc: iesg@ietf.org Subject: A6/DNAME usage guidelines and limits Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Standard Reply-To: This is a follow-on from the thread: Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed On Wed, Mar 27, 2002 at 09:27:27PM +1100, Nathan Jones wrote: >Has anyone yet started work on a draft to document guidelines for the >usage of DNS with IPv6? (eg. recommended limits on A6 chains, etc.) I've started writing up some guidelines, which I've included below. They are far from complete, but I wanted to post something before the close of the Last Call for draft-ietf-dnsext-ipv6-addresses-01.txt. In particular: - I need to add guidelines on DNAME. - I need to add info on using DNSSEC in an A6 world. (If you're familiar with DNSSEC, you may have suggestions to send.) - I'm not happy with the wording, but will continue to work on it and flesh it out to be more complete. Let's assume for a moment that A6 and DNAME are left intact. With this assumption in mind, please give me your feedback and suggestions. In response to a call for a compromise between AAAA and A6, I've portrayed fairly conservative use of A6 and also suggested deprecating bit string labels (even though personally I like them). ------------------------ Introduction Extensions to DNS have been made to allow for easier renumbering with IPv6. Few guidelines have been written about the use of these extensions. This document provides suggestions that should assist in the deployment of A6 and DNAME. Overview This section provides an overview of the DNS mechanisms discussed in this document. For full information, the reader should refer to the relevant specification. [Will add information here once the other guidelines are in place.] Recommendations for A6 [RFC2874] gives an example based on the IPv6 aggregatable address format [RFC2374], where a top level aggregate (TLA), next level aggregate (NLA), ISP and site all provide portions of an A6 record chain. In order to support such a configuration, A6 aware DNS resolvers that provide recursion MUST support at least six (6) levels of indirection in an A6 record chain. [Although there are six components to the A6 record chain in the example, only four lookups are required, since three components are held on one server and would be returned in the Additional section. Should the limit here be four levels of indirection (TLA, NLA, ISP, Site)? If so, what if the site's HR department has its own nameservers? A lookup for mail.hr.x.example. would require more than four queries.] While support for six levels of indirection is important for future use, it is suggested that A6 records initially be implemented with fewer fragments. In many cases, a simple configuration with one level of indirection should be sufficient. For example, each node in a site could be referenced by an A6 record that has a common prefix and prefix length. The A6 record for the prefix would generally be maintained by the site, rather than an upstream ISP. As a result, most lookups will only require one query. Example: This example mirrors the one in section 5.1 of [RFC2874]. Site X is represented in the DNS by the domain name X.EXAMPLE and receives transit from two ISPs named A and B. A and B in turn receive transit from providers C, D and E. Address allocation and aggregation is such that site X has inherited three address prefixes: o 2345:00C1:CA11::/48 from A, for routes through C. o 2345:00D2:DA11::/48 from A, for routes through D. o 2345:000E:EB22::/48 from B, for routes through E. Let us suppose that N is a node in the site X, that it is assigned to subnet number 1 in this site, and that it uses the interface identifier '1234:5678:9ABC:DEF0'. In our configuration, this node will have three addresses: o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 Using the basic configuration suggested in this document, site X would include the following records in it's DNS: $ORIGIN X.EXAMPLE. IP6 IN A6 0 2345:00C1:CA11:: IN A6 0 2345:00D2:DA11:: IN A6 0 2345:000E:EB22:: N IN A6 48 ::1:1234:5678:9ABC:DEF0 IP6 In this example, should a site need to renumber, some administration is still required, but only the prefix A6 records would need to be updated. Other A6 records that reference the prefix do not need to be changed. AAAA Synthesis [RFC2874] discusses making a transition from AAAA to A6 by automatically generating AAAA records from A6 records. Such AAAA synthesis should be viewed as an integral part of DNS support for IPv6, rather than purely a transition mechanism. A nameserver that offers recursive DNS resolution SHOULD be able to generate AAAA records in response to AAAA queries. This allows devices and other hosts to use a lightweight stub resolver that does not need to know about A6. Deprecation of Bit String Labels [RFC2874] recommends the use of bit-string labels, as defined in [RFC2673]. The main advantage of bit-string labels is the ability to delegate on arbitrary bit boundaries. The disadvantage is an increase in complexity. To reduce this complexity, this document deprecates bit-string labels. Delegations in the inverse tree (IP6.ARPA.) therefore continue to use the nibble format described in [RFC1886]. In the event that delegation is required on non-nibble boundaries, the method specified in [RFC2317] should be used. -- Nathan Jones nathanj@optimo.com.au -- 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 Apr 2 03:12:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09509 for ; Tue, 2 Apr 2002 03:12:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sJEk-0003BG-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 00:01:50 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16sJEj-0003BA-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 00:01:49 -0800 Received: by as.vix.com (Postfix, from userid 716) id D079D28DC4; Tue, 2 Apr 2002 00:01:48 -0800 (PST) To: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call References: <20020401012215.M7955-100000@padda.telia.net> From: Paul Vixie Date: 02 Apr 2002 00:01:48 -0800 In-Reply-To: <20020401012215.M7955-100000@padda.telia.net> Message-ID: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mats Dufberg writes: > The only arguments in favor of limited opt-in I have seen have been on > some kind of moral ground. Are there any technical arguments that I cannot > see in favor of limiting opt-in? I have seen no such technical arguments. > When administrating DNS you are focused on the zone as a unit. DNSsec has > also focused on that unit. But queries are not based on zone, and they can > happily skip zones when parent and child resides on the same server, or > some server happens to do resolving. Queries are based on names and its > data, and opt-in refocus on names as being secured or not. Agreed. (And: "well put.") > ... until I see good technical grounds for limiting opt-in, I propose > full opt-in. Echoed. The document can recommend an operational practice of only opting in/out one's delegations. But implementations (of either server or client) should not be required to enforce this practice, since at the wire level, it is arbitrary, and only adds complexity without removing any carrying cost. -- 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 Apr 2 04:09:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10336 for ; Tue, 2 Apr 2002 04:09:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sK6I-0005AI-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 00:57:10 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16sK6H-0005AC-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 00:57:09 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2V4uTZ00495 for ; Sun, 31 Mar 2002 11:56:29 +0700 (ICT) From: Robert Elz To: namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: <20020329204419.2A23A1C11@thrintun.hactrn.net> References: <20020329204419.2A23A1C11@thrintun.hactrn.net> <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> <20020328094454.A5859@connect.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 Mar 2002 11:56:29 +0700 Message-ID: <493.1017550589@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 29 Mar 2002 15:44:18 -0500 From: Rob Austein Message-ID: <20020329204419.2A23A1C11@thrintun.hactrn.net> | The options that I can see are: The option I think I'd like to see at the minute is that we require that resolvers capable of receiving replies with RA clear, and acting upon them, send queries for A6 when using IPv6 transport (and regardless of what link layer is under that, including IPv4 tunnels) I can live with continuing to use AAAA over IPv4, as that should eventually fade away (sometime in the future). If it doesn't, then what we do with IPv6 DNS is going to largely be irrelevant. For the users, that means that A6 records should be added to zone files if your server can be reached over IPv6 (if it can only be reached over IPv4 then it doesn't really matter whether A6 records are there or not). While IPv4 connectivity is offered, then AAAA records should be available as well. If the server isn't signing records then it is free to construct A6 0 out of AAAA or AAAA out of A6 records (synthesis) as required - if records are being signed then both will need to be in the zone file before signing, whether by human action or server creation doesn't matter. This way the people who want to move forward as fast as possible can keep on using AAAA, as while there remain no IPv6 root servers, essentially all name resolution has to be done via IPv4 (and who can tell how long it is going to take before that political football obtains a solution). But once we start using native IPv6 for full name resolution (other than from back end to smarter resolver, which quite likely will always be AAAA and synthesis, though individual implementations would be free to use A6 any time they choose over IPv6 transport) A6 will start being used. The time from now until when IPv6 name resolution really starts to be deployed can be used for other implementations to support A6 records properly - as long as the implementors become aware that this is what the solution is to be, there should be plenty of time for users to be able to again have a choice as to which implementation to deploy. 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 Apr 2 05:26:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11427 for ; Tue, 2 Apr 2002 05:26:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sLHk-0007Q9-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 02:13:04 -0800 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.35 #1) id 16sLHj-0007Q3-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 02:13:03 -0800 Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id B487C621B7; Tue, 2 Apr 2002 12:13:01 +0200 (CEST) Date: Tue, 02 Apr 2002 12:13:01 +0200 From: Harald Alvestrand To: Roy Arends Cc: namedroppers Subject: Re: Opt-in wg last call Message-ID: <535230000.1017742381@askvoll.hjemme.alvestrand.no> In-Reply-To: <20020328203913.I52203-100000@node10c4d.a2000.nl> References: <20020328203913.I52203-100000@node10c4d.a2000.nl> X-Mailer: Mulberry/2.2.0b4 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA11427 --On torsdag, mars 28, 2002 20:56:56 +0100 Roy Arends wrote: > A few weeks ago there was a discussion on Opt-In or Non Opt-In. A > compromise (Opt-In for NS only) was posted which seems acceptable to some > without even one (1) technical argument. That compromise was based on a > moral argument. Roy, just clarifying: when you say "full Opt-In", do you mean Opt-In where a node is required to be either secure or insecure? That is - no per-RRset opt-out? draft-ietf-dnsext-dnssec-opt-in-01 appears to say that only secure and insecure nodes exist (no partially secure nodes), but I could not find words that said so explicitly - they are just never mentioned. The reason I wondered is because your argument in favour of full opt-in: > With full Opt-In the road is open to allow: > > o Unsigned synthesized RRsets. > (DNAME>CNAME, A6>AAAA) would seem to require the existence of partially secure nodes. There is an argument against partly secure nodes: if I am sending you email - your MX record is unsigned - your A record is signed where should I send your mail? This may not be a DNS-level "technical" argument, but it is another argument in the class of "this rope seems mostly useful for hangings" - this is a silly state, and I don't want to code for the decision. Note that this is not an argument for or against opt-in at zone boundary vs opt-in at full record set; it is an argument against the ability to opt-in some record types but not others. Harald -- 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 Apr 2 05:58:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11803 for ; Tue, 2 Apr 2002 05:58:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sLrD-0008Vd-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 02:49:43 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16sLrC-0008VX-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 02:49:42 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id E15BB3190C; Tue, 2 Apr 2002 02:49:40 -0800 (PST) Date: Tue, 2 Apr 2002 12:58:15 +0200 (CEST) From: Roy Arends X-X-Sender: To: Harald Alvestrand Cc: Roy Arends , namedroppers Subject: Re: Opt-in wg last call In-Reply-To: <535230000.1017742381@askvoll.hjemme.alvestrand.no> Message-ID: <20020402122333.A301-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id FAA11803 On Tue, 2 Apr 2002, Harald Alvestrand wrote: > --On torsdag, mars 28, 2002 20:56:56 +0100 Roy Arends > wrote: > > > A few weeks ago there was a discussion on Opt-In or Non Opt-In. A > > compromise (Opt-In for NS only) was posted which seems acceptable to some > > without even one (1) technical argument. That compromise was based on a > > moral argument. > > Roy, > > just clarifying: when you say "full Opt-In", do you mean Opt-In where a > node is required to be either secure or insecure? Yes, either ALL RRsets at a particular name are signed, or NO RRsets at a particular name are signed. > That is - no per-RRset opt-out? Exactly. > draft-ietf-dnsext-dnssec-opt-in-01 appears to say that only secure and > insecure nodes exist (no partially secure nodes), but I could not find > words that said so explicitly - they are just never mentioned. Then I'll need to clarify that explicitly. Thanks. > The reason I wondered is because your argument in favour of full opt-in: > > > With full Opt-In the road is open to allow: > > > > o Unsigned synthesized RRsets. > > (DNAME>CNAME, A6>AAAA) > > would seem to require the existence of partially secure nodes. DNAME>CNAME example: alpha.com DNAME beta.com will synthesize into: qname1.alpha.com. CNAME qname1.beta.com. qname2.alpha.com. CNAME qname2.beta.com. Since DNAME>CNAME synthesis will create new and different owner-names, there are no partially secure nodes. With regards to A6>AAAA, there is _already_ (2535) a problem with partially secured names (say 64 bit prefix is signed and 64 bit postfix is not). This introduces a whole new set of problems, yet not fully documented, though the only way to allow them to be synthesized and not signed within a partially secured zone, is with opt-in. > There is an argument against partly secure nodes: > > if I am sending you email > - your MX record is unsigned > - your A record is signed > where should I send your mail? All RRsets with the same owner name are either ALL Signed or NONE Signed. Note that, if you're sending me email, MX not signed, the A record (referred to by MX) is signed, you're facing a situation that already exist with rfc 2535, since my MX might point out of zone. > This may not be a DNS-level "technical" argument, but it is another > argument in the class of "this rope seems mostly useful for hangings" - > this is a silly state, and I don't want to code for the decision. > > Note that this is not an argument for or against opt-in at zone boundary vs > opt-in at full record set; it is an argument against the ability to opt-in > some record types but not others. 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 Apr 2 15:14:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01123 for ; Tue, 2 Apr 2002 15:14:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sUOr-0001t2-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 11:57:01 -0800 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.35 #1) id 16sUOq-0001ss-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 11:57:00 -0800 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g32Jux709440 for ; Tue, 2 Apr 2002 11:56:59 -0800 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Tue, 2 Apr 2002 11:56:59 -0800 (PST) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 2 Apr 2002, Paul Vixie wrote: > Mats Dufberg writes: > > > The only arguments in favor of limited opt-in I have seen have been on > > some kind of moral ground. Are there any technical arguments that I cannot > > see in favor of limiting opt-in? > > I have seen no such technical arguments. Agreed. I have seen no arguments either, and also did not see any indication of consensus either on the list or at the WG meeting. > > ... until I see good technical grounds for limiting opt-in, I propose > > full opt-in. > > Echoed. I agree. Although I'm still not convinced that opt-in is the right solution, I far prefer full opt-in to delegation-only restricted 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 Tue Apr 2 18:31:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07971 for ; Tue, 2 Apr 2002 18:31:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sXXh-000Ase-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 15:18:21 -0800 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.35 #1) id 16sXXf-000As2-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 15:18:19 -0800 Received: from tecotoo.www.gis.net ([216.41.28.10]) by mx03.gis.net; Tue, 02 Apr 2002 18:18:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id sa026720 for ; Tue, 2 Apr 2002 18:13:47 -0500 Message-Id: <4.3.1.2.20020402180848.038a3a70@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 02 Apr 2002 18:13:34 -0500 To: Robert Elz , namedroppers@ops.ietf.org From: Danny Mayer Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: <493.1017550589@brandenburg.cs.mu.OZ.AU> References: <20020329204419.2A23A1C11@thrintun.hactrn.net> <20020329204419.2A23A1C11@thrintun.hactrn.net> <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> <20020328094454.A5859@connect.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:56 PM 3/30/02, Robert Elz wrote: > Date: Fri, 29 Mar 2002 15:44:18 -0500 > From: Rob Austein > Message-ID: <20020329204419.2A23A1C11@thrintun.hactrn.net> > > > | The options that I can see are: > >The option I think I'd like to see at the minute is that we require >that resolvers capable of receiving replies with RA clear, and acting upon >them, send queries for A6 when using IPv6 transport (and regardless of >what link layer is under that, including IPv4 tunnels) > >I can live with continuing to use AAAA over IPv4, as that should eventually >fade away (sometime in the future). If it doesn't, then what we do with >IPv6 DNS is going to largely be irrelevant. > >For the users, that means that A6 records should be added to zone files if >your server can be reached over IPv6 (if it can only be reached over IPv4 >then it doesn't really matter whether A6 records are there or not). While >IPv4 connectivity is offered, then AAAA records should be available as well. >If the server isn't signing records then it is free to construct A6 0 out of >AAAA or AAAA out of A6 records (synthesis) as required - if records are being >signed then both will need to be in the zone file before signing, whether by >human action or server creation doesn't matter. > >This way the people who want to move forward as fast as possible can keep on >using AAAA, as while there remain no IPv6 root servers, essentially all name >resolution has to be done via IPv4 (and who can tell how long it is going >to take before that political football obtains a solution). > >But once we start using native IPv6 for full name resolution (other than from >back end to smarter resolver, which quite likely will always be AAAA and >synthesis, though individual implementations would be free to use A6 any >time they choose over IPv6 transport) A6 will start being used. > >The time from now until when IPv6 name resolution really starts to be deployed >can be used for other implementations to support A6 records properly - as >long as the implementors become aware that this is what the solution is to be, >there should be plenty of time for users to be able to again have a choice >as to which implementation to deploy. I'm confused by this. What has the transport to do with the query? If you use IPv4 or IPv6 or smoke signals to query the nameserver why does the query have to request a specific record type? 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 Tue Apr 2 18:31:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07983 for ; Tue, 2 Apr 2002 18:31:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sXXg-000Asb-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 15:18:20 -0800 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.35 #1) id 16sXXf-000As0-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 15:18:19 -0800 Received: from tecotoo.www.gis.net ([216.41.28.10]) by mx05.gis.net; Tue, 02 Apr 2002 18:18:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id wa026724 for ; Tue, 2 Apr 2002 18:16:41 -0500 Message-Id: <4.3.1.2.20020402181527.0388a220@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 02 Apr 2002 18:16:30 -0500 To: The IESG , IETF-Announce:; From: Danny Mayer Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Cc: RFC Editor , Internet Architecture Board , namedroppers@ops.ietf.org In-Reply-To: <200203272038.PAA21531@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:38 PM 3/27/02, The IESG wrote: >The WG chairs have been informed that there are at least two independent >interoperable implementations. Based on this feedback the WG came to consensus >about advancing this as a proposed standard. Outside of Microsoft and Lucent, the authors of this Proposed Standard, who has implemented this? 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 Tue Apr 2 18:47:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08574 for ; Tue, 2 Apr 2002 18:47:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sXrI-000Brg-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 15:38:36 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.35 #1) id 16sXrH-000BrU-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 15:38:35 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g32NcUx52304 for ; Wed, 3 Apr 2002 09:38:31 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200204022338.g32NcUx52304@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Opt-in wg last call In-reply-to: Your message of "Tue, 02 Apr 2002 11:56:59 PST." Date: Wed, 03 Apr 2002 09:38:30 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I agree. Although I'm still not convinced that opt-in is the right > solution, I far prefer full opt-in to delegation-only restricted opt-in. > > Brian Seconded. -- 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 Apr 2 18:48:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08626 for ; Tue, 2 Apr 2002 18:48:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sXrr-000BuK-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 15:39:11 -0800 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.35 #1) id 16sXrq-000BuD-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 15:39:10 -0800 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g32Nd3m06898; Tue, 2 Apr 2002 15:39:03 -0800 (PST) From: Bill Manning Message-Id: <200204022339.g32Nd3m06898@boreas.isi.edu> Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard In-Reply-To: <4.3.1.2.20020402181527.0388a220@pop.gis.net> from Danny Mayer at "Apr 2, 2 06:16:30 pm" To: mayer@gis.net (Danny Mayer) Date: Tue, 2 Apr 2002 15:39:03 -0800 (PST) Cc: iesg-secretary@ietf.org, IETF-Announce:;;;@gis.net;, rfc-editor@ISI.EDU, iab@ISI.EDU, 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 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % At 03:38 PM 3/27/02, The IESG wrote: % >The WG chairs have been informed that there are at least two independent % >interoperable implementations. Based on this feedback the WG came to consensus % >about advancing this as a proposed standard. % % Outside of Microsoft and Lucent, the authors of this Proposed Standard, who % has implemented this? % % Danny Perhaps more of interest, I seem to remember that there were some IP issues with the Microsoft implementation; e.g. one had to be bound to strict covenents before the specs would be released. For this reason, we do not have an interoperable implementation with an open reference standard, i.e. BIND. Will someone please tell me I'm misunderstanding this issue? -- --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 Apr 3 02:38:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26553 for ; Wed, 3 Apr 2002 02:38:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sf3B-0007Dl-00 for namedroppers-data@psg.com; Tue, 02 Apr 2002 23:19:21 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.35 #1) id 16sf3A-0007De-00 for namedroppers@ops.ietf.org; Tue, 02 Apr 2002 23:19:21 -0800 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 060F852A4 for ; Wed, 3 Apr 2002 09:19:19 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 1C4B31DA4 for ; Wed, 3 Apr 2002 09:19:18 +0200 (MEST) Date: Wed, 3 Apr 2002 09:19:26 +0200 (CEST) From: Jakob Schlyter To: IETF DNSEXT WG Subject: name server without root cache Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk during the testing of nsd (the authorative-only name server developed at nlnetlabs) a protocol question regarding name servers without a root cache has been raised. the basic question: is it required by a name server to provide a referral (to the root or elsewhere)? if it can not provide a referral, what status code should it return? my personal view: if it is required, a name server without a root cache should return SERVFAIL if it can not provide a referral. if it is not required, a nameserver without a root cache may return REFUSED if it choose not to answer the query. 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 Apr 3 03:32:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27176 for ; Wed, 3 Apr 2002 03:32:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sg1r-000AHr-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 00:22:03 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] helo=outpost.powerdns.com) by psg.com with esmtp (Exim 3.35 #1) id 16sg1q-000AHk-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 00:22:02 -0800 Received: by outpost.powerdns.com (Postfix, from userid 1000) id 3F794C60EE; Wed, 3 Apr 2002 10:22:00 +0200 (CEST) Date: Wed, 3 Apr 2002 10:22:00 +0200 From: bert hubert To: Jakob Schlyter Cc: IETF DNSEXT WG Subject: Re: name server without root cache Message-ID: <20020403102200.A550@outpost.ds9a.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jakob@crt.se on Wed, Apr 03, 2002 at 09:19:26AM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Apr 03, 2002 at 09:19:26AM +0200, Jakob Schlyter wrote: > during the testing of nsd (the authorative-only name server developed at > nlnetlabs) a protocol question regarding name servers without a root cache > has been raised. Interesting. The PowerDNS nameserver pdns (http://www.powerdns.com/pdns) also has no 'hints' file. > the basic question: is it required by a name server to provide a referral > (to the root or elsewhere)? if it can not provide a referral, what status > code should it return? I can only add the voice of experience as I am no standards guru. We return a regular unauthoritative answer with an empty answer section which appears to satisfy recursing nameservers visiting us. When I investigated this I found that sending out 'hints' was not mandatory and in fact (imnsho) only confuses matters. > my personal view: if it is required, a name server without a root cache > should return SERVFAIL if it can not provide a referral. if it is not > required, a nameserver without a root cache may return REFUSED if it > choose not to answer the query. Of greater importance is how the vast installed base out there would react to that. 'REFUSED' has different connotations ie 'I would have answered but your IP address doesn't allow me to'. Another interesting case is that of the 'out of bailiwick CNAME'. Bind8 responds with a SERVFAIL if it encounters a CNAME for which it can't/shouldn't resolve the RHS. PDNS doesn't as it considers that it has done all it can and has not failed. Regards, bert -- 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 Apr 3 03:45:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27316 for ; Wed, 3 Apr 2002 03:45:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sgHF-000B1q-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 00:37:57 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.35 #1) id 16sgHF-000B1j-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 00:37:57 -0800 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id E6DF452A5; Wed, 3 Apr 2002 10:37:55 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 994E81DA4; Wed, 3 Apr 2002 10:37:52 +0200 (MEST) Date: Wed, 3 Apr 2002 10:37:59 +0200 (CEST) From: Jakob Schlyter To: bert hubert Cc: IETF DNSEXT WG Subject: Re: name server without root cache In-Reply-To: <20020403102200.A550@outpost.ds9a.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Apr 2002, bert hubert wrote: > Of greater importance is how the vast installed base out there would react > to that. 'REFUSED' has different connotations ie 'I would have answered but > your IP address doesn't allow me to'. REFUSED could mean 'I maybe could have answered but I did not feel like it'. bind8 returns SERVFAIL without any root cache, bind9 returns REFUSED if configured not do recursion and not to supply additional from cache, otherwise it returns it's built-in root cache if I remember correctly. 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 Apr 3 04:10:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27705 for ; Wed, 3 Apr 2002 04:10:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sgh3-000CFW-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 01:04:37 -0800 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16sgh2-000CFQ-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 01:04:36 -0800 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g3394WV29528; Wed, 3 Apr 2002 11:04:32 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Wed, 3 Apr 2002 11:04:32 +0200 (CEST) From: Mats Dufberg To: bert hubert cc: Jakob Schlyter , IETF DNSEXT WG Subject: Re: name server without root cache In-Reply-To: <20020403102200.A550@outpost.ds9a.nl> Message-ID: <20020403105747.T16642-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Apr 3, 2002, 10:22 (+0200) bert hubert wrote: > When I investigated this I found that sending out 'hints' was not mandatory > and in fact (imnsho) only confuses matters. According to my view, the best practice is to have a hint file, and return a referal to the root. > > my personal view: if it is required, a name server without a root cache > > should return SERVFAIL if it can not provide a referral. if it is not > > required, a nameserver without a root cache may return REFUSED if it > > choose not to answer the query. > > Of greater importance is how the vast installed base out there would react > to that. 'REFUSED' has different connotations ie 'I would have answered but > your IP address doesn't allow me to'. I agree. If there is no hint file, SERVFAIL is the correct response. One problem with DNS is that the status NOERROR is overloaded with different meanings. We want the server to say "The name you asked for is not within any of the domains that I handle, and I don't do any recursion (or you asked me not to recurse)" The NS records to root as such are of no importance, but must be there to give a reasonble responce. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- 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 Apr 3 04:34:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27963 for ; Wed, 3 Apr 2002 04:34:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sh1d-000DKw-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 01:25:53 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16sh1c-000DKq-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 01:25:52 -0800 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g339PkK21052 for ; Wed, 3 Apr 2002 11:25:46 +0200 Date: Wed, 3 Apr 2002 11:25:49 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call Message-Id: <20020403112549.6693629d.olaf@ripe.net> In-Reply-To: <20020401012215.M7955-100000@padda.telia.net> References: <20020401012215.M7955-100000@padda.telia.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The only arguments in favor of limited opt-in I have seen have been on > some kind of moral ground. Are there any technical arguments that I > cannot see in favor of limiting opt-in? I'm afraid I have been one of the persons voicing "moral" objections. I will not repeat them here. But I still would like to see the strongest possible recommendation not to use opt-in and sign zones completely. > When administrating DNS you are focused on the zone as a unit. DNSsec > has also focused on that unit. But queries are not based on zone, and > they can happily skip zones when parent and child resides on the same > server, or some server happens to do resolving. Queries are based on > names and its data, and opt-in refocus on names as being secured or not. Detail: It has been mentioned that we loose the concept of secured zones for the resolvers , I do not think that is true. Although the user's application is only interested in a name with associated data the resolvers will need to maintain state as to a zone is secured or not. If the SOA is signed then names in that zone are either signed or opted-out. > I think I'll survive any decision taken in this matter. :-) That goes for me too. We should move forward. I would like to have DNSSEC in production by the end of the year :-). --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 3 06:25:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29582 for ; Wed, 3 Apr 2002 06:25:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sigu-000INU-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 03:12:36 -0800 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16sigt-000INO-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 03:12:35 -0800 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g33BCXx29669; Wed, 3 Apr 2002 13:12:33 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Wed, 3 Apr 2002 13:12:33 +0200 (CEST) From: Mats Dufberg To: "Olaf M. Kolkman" cc: Subject: Re: Opt-in wg last call In-Reply-To: <20020403112549.6693629d.olaf@ripe.net> Message-ID: <20020403130708.V29629-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Apr 3, 2002, 11:25 (+0200) Olaf M. Kolkman wrote: > I'm afraid I have been one of the persons voicing "moral" > objections. I will not repeat them here. But I still would like to see > the strongest possible recommendation not to use opt-in and sign zones > completely. I agree that we should recommend signing of all data. > That goes for me too. We should move forward. I would like to have > DNSSEC in production by the end of the year :-). Yes, I'd like to see DNSsec used and recommended for ENUM. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- 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 Apr 3 08:34:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02737 for ; Wed, 3 Apr 2002 08:34:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16skhn-000OoP-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 05:21:39 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16skhn-000OoH-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 05:21:39 -0800 Received: by sentry.gw.tislabs.com; id IAA03060; Wed, 3 Apr 2002 08:27:20 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma003051; Wed, 3 Apr 02 08:26:46 -0500 X-Sender: lewis@pop.tislabs.com Message-Id: In-Reply-To: <20020403130708.V29629-100000@padda.telia.net> References: <20020403112549.6693629d.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Apr 2002 08:21:45 -0500 To: From: Edward Lewis Subject: Re: Opt-in wg last call Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk During the IETF meetings, I was told about "typo" attacks being a threat. I'm not sure I've seen them in a message yet though. If you know what these attacks are, the only benefit to reading the rest of this is to make sure I've stated the problem accurately. Before I describe them, my stance is that opt-in makes sense from the point of view that it makes transitioning from insecure to secure more natural. Mind you, this is just a "warm and fuzzy" feeling, there isn't a real technical reason for this. The typo attacks consist of someone taking advantage of "similar" names. E.g., If I want to serve monopoly.int and there is a common mispelling of m0n0p0ly.int, someone else could register that name and take advantage of client mistakes. If the alternate spelling is registered and evil is afoot, then there will be authorities available to deal with the evil doer. To find the evil doer, one begins with the registration. If opt-in is in use, then there may be no registration, one less means by which to locate the evil doer. What makes this troublesome is that the victim, in this case monopoly.int, is at risk becuase of a policy decision made by some one else (.int). It is not a matter of .int shooting themselves in tht foot, but .int shooting one of the legitmate delegations in the leg. So, it seems that opt-in allows one organization to put another at risk. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 3 09:56:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04834 for ; Wed, 3 Apr 2002 09:56:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16slz4-0002yQ-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 06:43:34 -0800 Received: from [198.200.138.211] (helo=quadntweb.quadritek.com) by psg.com with esmtp (Exim 3.35 #1) id 16slz4-0002yK-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 06:43:34 -0800 Received: from quadritek.com ([198.200.138.158]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with ESMTP id com; Wed, 3 Apr 2002 09:39:53 -0500 Message-ID: <3CAB152A.19C6E05@quadritek.com> Date: Wed, 03 Apr 2002 09:43:54 -0500 From: rhall@quadritek.com (Randy Hall) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Manning CC: Danny Mayer , iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard References: <200204022339.g32Nd3m06898@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Perhaps more of interest, I seem to remember that there were some > IP issues with the Microsoft implementation; e.g. one had to be > bound to strict covenents before the specs would be released. > Will someone please tell me I'm misunderstanding this issue? I'm not sure what "specs" are being referred to. I just used the draft and windows 2000 kerberos configuration information that is available on publicly accessible web sites or as part of the win2k documentation. I wasn't bound to anything, nor did I have to sign an NDA or anything like that. There were (IMO) bugs in the TKEY, TSIG, and other protocols that needed fixing, and some changes (IMO) were needed (and made) to the protocol, but there were no IP issues relating these issues. It was more a matter of ... I think there's a bug in your [protocol] implementation ... whaddya think ... ok we'll fix it in the next release or try this workaround in the mean time ... In any case, if it cannot be implemented from the draft alone, its only because of bugs in legacy versions of other protocols (or unfixed bugs), and I don't recall any IP issues on these bugs. Furthermore, I'm confident the draft alone can be used to develop an implementation that will interoperate with Lucent's implementation. BTW, our management is considering making the details of our implementation available, but that is not my decision and is out of my hands. Cheers Randy Lucent -- 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 Apr 3 12:37:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10161 for ; Wed, 3 Apr 2002 12:37:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16soLu-0008sY-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 09:15:18 -0800 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by psg.com with esmtp (Exim 3.35 #1) id 16soLt-0008sS-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 09:15:17 -0800 Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g33HExo99765; Thu, 4 Apr 2002 02:15:00 +0900 (JST) Date: Thu, 04 Apr 2002 02:14:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Danny Mayer Cc: Robert Elz , namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: <4.3.1.2.20020402180848.038a3a70@pop.gis.net> References: <20020329204419.2A23A1C11@thrintun.hactrn.net> <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> <20020328094454.A5859@connect.com.au> <493.1017550589@brandenburg.cs.mu.OZ.AU> <4.3.1.2.20020402180848.038a3a70@pop.gis.net> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Tue, 02 Apr 2002 18:13:34 -0500, >>>>> Danny Mayer said: > I'm confused by this. What has the transport to do with the query? If you use > IPv4 or IPv6 or smoke signals to query the nameserver why does the query > have to request a specific record type? I have the same confusion. Even with the fact many DNS servers and resolvers do not support IPv6 transport for DNS, they are still resolving AAAA (and, sometimes, A6). This is in fact how Windows XP and Solaris (as a resolver) and BIND 8 is working in the real world, and, as I said in my previous message, we are now deploying IPv6 in commercial services with these implementations (in some cases, they sometimes use private IPv4 network for name resolution, and it simply works well.) So I don't think the period to deploy DNS IPv6 transport can be a moratorium to deploy A6. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 3 12:39:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10199 for ; Wed, 3 Apr 2002 12:39:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16soK1-0008nV-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 09:13:21 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.35 #1) id 16soK0-0008n0-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 09:13:20 -0800 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id D397752A5; Wed, 3 Apr 2002 19:13:18 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 5C7F81DA4; Wed, 3 Apr 2002 19:13:18 +0200 (MEST) Date: Wed, 3 Apr 2002 19:13:26 +0200 (CEST) From: Jakob Schlyter To: Mats Dufberg Cc: bert hubert , IETF DNSEXT WG Subject: Re: name server without root cache In-Reply-To: <20020403105747.T16642-100000@padda.telia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Apr 2002, Mats Dufberg wrote: > > Of greater importance is how the vast installed base out there would react > > to that. 'REFUSED' has different connotations ie 'I would have answered but > > your IP address doesn't allow me to'. > > I agree. If there is no hint file, SERVFAIL is the correct response. if the hints file was missing unintentionally, I agree that SERVFAIL is the correct response. however, if the file was left out due to policy, REFUSED is better since I did leave it out on purpose. put in other words, I simply choose to refuse to answer queries not in my zones. 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 Apr 3 14:17:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12721 for ; Wed, 3 Apr 2002 14:16:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16spw8-000Crj-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 10:56:48 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16spw7-000Crd-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 10:56:48 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 7D8033190C; Wed, 3 Apr 2002 10:56:46 -0800 (PST) Date: Wed, 3 Apr 2002 21:05:40 +0200 (CEST) From: Roy Arends X-X-Sender: To: "Olaf M. Kolkman" Cc: Subject: Re: Opt-in wg last call In-Reply-To: <20020403112549.6693629d.olaf@ripe.net> Message-ID: <20020403152418.V2582-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Apr 2002, Olaf M. Kolkman wrote: > Detail: It has been mentioned that we loose the concept of secured > zones for the resolvers , I do not think that is true. Although the > user's application is only interested in a name with associated data > the resolvers will need to maintain state as to a zone is secured or > not. If the SOA is signed then names in that zone are either signed > or opted-out. No. A domain indicates that a subdomain is considered signed (DS/KEY). A preconfigured key (in the resolver) indicates a domain is considered signed. Resolver considers world under a domain secured until a "no-ds/key" or an opt-in NXT record states otherwise. SOA has no involvement in indicating something is secured or not. 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 Apr 3 14:36:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13548 for ; Wed, 3 Apr 2002 14:36:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sqFt-000DdM-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 11:17:13 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16sqFs-000Dd9-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 11:17:12 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 6383328E19 for ; Wed, 3 Apr 2002 11:16:57 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: name server without root cache In-Reply-To: Message from Jakob Schlyter of "Wed, 03 Apr 2002 19:13:26 +0200." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 03 Apr 2002 11:16:57 -0800 Message-Id: <20020403191657.6383328E19@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I agree. If there is no hint file, SERVFAIL is the correct response. > > if the hints file was missing unintentionally, I agree that SERVFAIL is > the correct response. however, if the file was left out due to policy, > REFUSED is better since I did leave it out on purpose. put in other words, > I simply choose to refuse to answer queries not in my zones. if REFUSED meant what it sounds like it means, i would agree. |RFC 1035 Domain Implementation and Specification November 1987 |... | 2 Server failure - The name server was | unable to process this query due to a | problem with the name server. |... | 5 Refused - The name server refuses to | perform the specified operation for | policy reasons. For example, a name | server may not wish to provide the | information to the particular requester, | or a name server may not wish to perform | a particular operation (e.g., zone | transfer) for particular data. |... |Mockapetris [Page 27] "configuration" != "policy". not having a hints file is, according to other parts of the standard, a "problem with the name server." it's certainly possible that since "authoritative only" name servers were not contemplated by the standard, that this is an obscure corner case and would have been resolved differently had such contemplation occurred. some here would like to say that "policy" includes such decisions as "i choose to have no hints file." but rfc1035 doesn't give you that choice, and so your choice would equate to a "problem with the name server." but as things stand, "2" (SERVFAIL as BIND calls it) is the right answer. -- 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 Apr 3 15:14:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14420 for ; Wed, 3 Apr 2002 15:14:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16squv-000FLh-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 11:59:37 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16squu-000FLb-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 11:59:36 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 436D41BB2 for ; Wed, 3 Apr 2002 14:59:35 -0500 (EST) Date: Wed, 03 Apr 2002 14:59:35 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Reply-To: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call In-Reply-To: <20020403152418.V2582-100000@node10c4d.a2000.nl> References: <20020403112549.6693629d.olaf@ripe.net> <20020403152418.V2582-100000@node10c4d.a2000.nl> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020403195935.436D41BB2@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Do we have a worked example of opt-in applied to a zone that's more than one label deep? This seems like the place where weakening of the "secure zone" model is most likely to make life confusing for the resolver. Apologies if this has already been discussed and I missed it, but I saw no such example on a quick re-read of the draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 3 15:28:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14769 for ; Wed, 3 Apr 2002 15:28:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sr4F-000Fjs-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 12:09:15 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] helo=outpost.powerdns.com) by psg.com with esmtp (Exim 3.35 #1) id 16sr4E-000FjR-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 12:09:14 -0800 Received: by outpost.powerdns.com (Postfix, from userid 1000) id AA0BAC60EE; Wed, 3 Apr 2002 22:09:12 +0200 (CEST) Date: Wed, 3 Apr 2002 22:09:12 +0200 From: bert hubert To: Paul Vixie Cc: IETF DNSEXT WG Subject: Re: name server without root cache Message-ID: <20020403220912.A11593@outpost.ds9a.nl> References: <20020403191657.6383328E19@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020403191657.6383328E19@as.vix.com>; from paul@vix.com on Wed, Apr 03, 2002 at 11:16:57AM -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Apr 03, 2002 at 11:16:57AM -0800, Paul Vixie wrote: > some here would like to say that "policy" includes such decisions as "i > choose to have no hints file." but rfc1035 doesn't give you that choice, > and so your choice would equate to a "problem with the name server." > > but as things stand, "2" (SERVFAIL as BIND calls it) is the right answer. Noted. PDNS 1.99.8 will send out SERVFAIL. So far we have sometimes seen unexplicable high question rates for domains for which we are not authoritative, which may be related to the fact that currently we send out an unauthoritative 'NOERROR' empty answer. How about a server which has this as its only zone: @ IN SOA ... something IN CNAME something.else.com. And receives a question for 'something', but cannot recurse to find data about something.else.com.? Bind 8 sends SERVFAIL. Thanks for your time. 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 Apr 3 15:33:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15003 for ; Wed, 3 Apr 2002 15:33:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16srHA-000GIa-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 12:22:36 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16srH9-000GIU-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 12:22:35 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 56D3E1BB2 for ; Wed, 3 Apr 2002 15:22:34 -0500 (EST) Date: Wed, 03 Apr 2002 15:22:34 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: <20020403191657.6383328E19@as.vix.com> References: <20020403191657.6383328E19@as.vix.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020403202234.56D3E1BB2@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I don't think that RFC 1035 rules out RCODE=5 in this case, because nothing in the text Paul quoted restricts the subset of all possible requestors to which one is refusing service to being a proper subset. -- 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 Apr 3 15:37:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15096 for ; Wed, 3 Apr 2002 15:37:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16srEv-000GCZ-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 12:20:17 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16srEu-000GCT-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 12:20:16 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 54F3028DC4 for ; Wed, 3 Apr 2002 12:20:16 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: name server without root cache In-Reply-To: Message from bert hubert of "Wed, 03 Apr 2002 22:09:12 +0200." <20020403220912.A11593@outpost.ds9a.nl> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 03 Apr 2002 12:20:16 -0800 Message-Id: <20020403202016.54F3028DC4@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > but as things stand, "2" (SERVFAIL as BIND calls it) is the right answer. > > Noted. PDNS 1.99.8 will send out SERVFAIL. So far we have sometimes seen > unexplicable high question rates for domains for which we are not > authoritative, which may be related to the fact that currently we send out > an unauthoritative 'NOERROR' empty answer. indeed. resolvers don't know what to do with REFUSED, so many of them just treat it as an uncached SERVFAIL, meaning they move on to the next NS RR and don't fail the query until all NS RRs answer with the same error. and when the next similar query comes in from the application layer, they do it all again. a few (very few) implementations will cache the SERVFAIL in this case but none i have seen will cache the REFUSED. > How about a server which has this as its only zone: > > @ IN SOA ... > something IN CNAME something.else.com. > > And receives a question for 'something', but cannot recurse to find data > about something.else.com.? > > Bind 8 sends SERVFAIL. BIND8 uses SERVFAIL too liberally. one truly does wish for the NOTAUTH code standardized in RFC2136 to be available for normal queries. it may even be worth checking existing resolver behaviour in the face of such a code -- it will not be recognized and it's hopeful that it would cause the query to fail rather than the next NS to be tried. sending back an upward delegation is the way nameservers can refer to the root servers to get rid of these pesky clients. which is no doubt why most of the answers sent back by any given root server are repeated NXDOMAINs or repeated delegations. a server which is lame ought to have a way to cause the transaction to just terminate. though that raises robustness issues. a truncated CNAME chain, where the "next hop" is in a zone the current server isn't authoritative for and recursion is disabled IS a "problem with the name server" and in this case "2" (SERVFAIL) is the appropriate answer. a lot of the conceptual damage is done in the forwarding model. authority servers should not see queries for which RD is set -- if recursive servers made their own upstream queries and regenerated the responses back to the requestor, then CNAME chaining would not occur in authority servers at all. -- 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 Apr 3 15:43:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15203 for ; Wed, 3 Apr 2002 15:43:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16srOE-000GaY-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 12:29:54 -0800 Received: from caperry-pc1.isot.com ([208.27.64.66] helo=southern-star-ranch.com) by psg.com with smtp (Exim 3.35 #1) id 16srOD-000GaS-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 12:29:53 -0800 Received: (qmail 20451 invoked by uid 500); 3 Apr 2002 21:59:42 -0000 Date: Wed, 3 Apr 2002 15:59:42 -0600 From: Carl Perry To: namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits Message-ID: <20020403155942.A30198@onramp.southern-star-ranch.com> Reply-To: Carl Perry References: <20020402164751.E19210@connect.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020402164751.E19210@connect.com.au>; from nathanj@optimo.com.au on Tue, Apr 02, 2002 at 04:47:51PM +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 02, 2002 at 04:47:51PM +1000, Nathan Jones wrote: > AAAA Synthesis >=20 > [RFC2874] discusses making a transition from AAAA to A6 by automatical= ly > generating AAAA records from A6 records. Such AAAA synthesis should be > viewed as an integral part of DNS support for IPv6, rather than purely > a transition mechanism.=20 >=20 > A nameserver that offers recursive DNS resolution SHOULD be able to > generate AAAA records in response to AAAA queries. This allows devices > and other hosts to use a lightweight stub resolver that does not need > to know about A6. I think this is the way to go. A6 is a good idea, in general. However, having the resolver on a client have to perform multiple queries to get a single name resolved is not a good idea. End-points in the DNS tree should be able to ask DNS server/cache systems to provide them an AAAA answer to a name. The server/cache should be able to handle AAAA and A6, and convert A6 records to AAAA responses accordingly. This gives the ability for "easy" address renumeration, and a thinner client resolver profile. In short, it's the best of both worlds. --=20 -Carl Perry caperry@edolnx.net "Deliver yesterday, code today, think tomorrow." --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8q3tOUL2zshtaNRYRAuyRAJ4mXR41ZUfk2eEnc4gb3R9tgaHenACfQrPQ Af9CZ1lGYGHtFHSl7YloRBc= =TbN9 -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- -- 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 Apr 3 15:57:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15618 for ; Wed, 3 Apr 2002 15:57:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sran-000H8C-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 12:42:53 -0800 Received: from caperry-pc1.isot.com ([208.27.64.66] helo=southern-star-ranch.com) by psg.com with smtp (Exim 3.35 #1) id 16sral-000H86-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 12:42:52 -0800 Received: (qmail 29242 invoked by uid 500); 3 Apr 2002 22:12:47 -0000 Date: Wed, 3 Apr 2002 16:12:47 -0600 From: Carl Perry To: namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits Message-ID: <20020403161247.C30198@onramp.southern-star-ranch.com> Reply-To: Carl Perry References: <20020402164751.E19210@connect.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020402164751.E19210@connect.com.au>; from nathanj@optimo.com.au on Tue, Apr 02, 2002 at 04:47:51PM +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Apr 02, 2002 at 04:47:51PM +1000, Nathan Jones wrote: > AAAA Synthesis > > [RFC2874] discusses making a transition from AAAA to A6 by automatically > generating AAAA records from A6 records. Such AAAA synthesis should be > viewed as an integral part of DNS support for IPv6, rather than purely > a transition mechanism. > > A nameserver that offers recursive DNS resolution SHOULD be able to > generate AAAA records in response to AAAA queries. This allows devices > and other hosts to use a lightweight stub resolver that does not need > to know about A6. I think this is the way to go. A6 is a good idea, in general. However, having the resolver on a client have to perform multiple queries to get a single name resolved is not a good idea. End-points in the DNS tree should be able to ask DNS server/cache systems to provide them an AAAA answer to a name. The server/cache should be able to handle AAAA and A6, and convert A6 records to AAAA responses accordingly. This gives the ability for "easy" address renumeration, and a thinner client resolver profile. In short, it's the best of both worlds. -- -Carl Perry caperry@edolnx.net "Deliver yesterday, code today, think tomorrow." -- 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 Apr 3 16:17:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15952 for ; Wed, 3 Apr 2002 16:17:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16srts-000HwM-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 13:02:36 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16srtr-000HwG-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 13:02:35 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 1A25028DC4 for ; Wed, 3 Apr 2002 13:02:35 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: Message from Rob Austein of "Wed, 03 Apr 2002 15:22:34 EST." <20020403202234.56D3E1BB2@thrintun.hactrn.net> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 03 Apr 2002 13:02:35 -0800 Message-Id: <20020403210235.1A25028DC4@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I don't think that RFC 1035 rules out RCODE=5 in this case, because > nothing in the text Paul quoted restricts the subset of all possible > requestors to which one is refusing service to being a proper subset. the way i read it, RCODE=2 is "i don't have what you want" whereas RCODE=5 is "i have it but i'm just not going to tell 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 Wed Apr 3 16:21:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16045 for ; Wed, 3 Apr 2002 16:21:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ss1U-000IJ3-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 13:10:28 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16ss1S-000IIw-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 13:10:27 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C5AE53190E; Wed, 3 Apr 2002 13:10:21 -0800 (PST) Date: Wed, 3 Apr 2002 23:19:14 +0200 (CEST) From: Roy Arends X-X-Sender: To: Edward Lewis Cc: Subject: Re: Opt-in wg last call In-Reply-To: Message-ID: <20020403210559.V2582-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 3 Apr 2002, Edward Lewis wrote: > During the IETF meetings, I was told about "typo" attacks being a threat. > I'm not sure I've seen them in a message yet though. If you know what > these attacks are, the only benefit to reading the rest of this is to make > sure I've stated the problem accurately. > > Before I describe them, my stance is that opt-in makes sense from the point > of view that it makes transitioning from insecure to secure more natural. > Mind you, this is just a "warm and fuzzy" feeling, there isn't a real > technical reason for this. > > The typo attacks consist of someone taking advantage of "similar" names. > E.g., If I want to serve monopoly.int and there is a common mispelling of > m0n0p0ly.int, someone else could register that name and take advantage of > client mistakes. > > If the alternate spelling is registered and evil is afoot, then there will > be authorities available to deal with the evil doer. To find the evil > doer, one begins with the registration. > > If opt-in is in use, then there may be no registration, one less means by > which to locate the evil doer. > > What makes this troublesome is that the victim, in this case monopoly.int, > is at risk becuase of a policy decision made by some one else (.int). It > is not a matter of .int shooting themselves in tht foot, but .int shooting > one of the legitmate delegations in the leg. > > So, it seems that opt-in allows one organization to put another at risk. Ed, I've heard about these attacks as well, and it indeed resembles what you wrote, but I don't think they hold sway. Here's my reasoning: How could .int shoot monopoly.int in the leg if they (monopoly.int) do not own m0n0p0ly.int. What right does .int have to deny registering m0n0p0ly.int, if it was not previously registered, even if it does remotely resembles monopoly.int. If I want to register m0n0p0ly.int, there is no legal way stopping me. I can even have it signed, without any interference of monopoly.int. Unless there is going to be some ICANN body in place that decides which possible names remotely resemble a given name, and why, (DNSO.1), the argument you gave does not hold. 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 Apr 3 16:22:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16096 for ; Wed, 3 Apr 2002 16:22:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sryv-000IBq-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 13:07:49 -0800 Received: from fxshpr06.extra.daimlerchrysler.com ([208.154.80.165]) by psg.com with esmtp (Exim 3.35 #1) id 16sryu-000IBk-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 13:07:48 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id g33LACQ19676 for ; Wed, 3 Apr 2002 16:10:12 -0500 (EST) Received: from nodnsquery(129.9.145.48) by fxshpr06.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAQBayBM; Wed, 3 Apr 02 16:10:11 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.61]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g33L7lI19188 for ; Wed, 3 Apr 2002 16:07:47 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.61]) by wokcdts1.is.chrysler.com (8.11.2/8.9.1) with ESMTP id g33L6WW22077 for ; Wed, 3 Apr 2002 16:06:32 -0500 (EST) Message-ID: <3CAB6ED8.FDCDEC8F@daimlerchrysler.com> Date: Wed, 03 Apr 2002 16:06:32 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: IETF DNSEXT WG Subject: Re: name server without root cache References: <20020403191657.6383328E19@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > > > I agree. If there is no hint file, SERVFAIL is the correct response. > > > > if the hints file was missing unintentionally, I agree that SERVFAIL is > > the correct response. however, if the file was left out due to policy, > > REFUSED is better since I did leave it out on purpose. put in other words, > > I simply choose to refuse to answer queries not in my zones. > > if REFUSED meant what it sounds like it means, i would agree. > > |RFC 1035 Domain Implementation and Specification November 1987 > |... > | 2 Server failure - The name server was > | unable to process this query due to a > | problem with the name server. > |... > | 5 Refused - The name server refuses to > | perform the specified operation for > | policy reasons. For example, a name > | server may not wish to provide the > | information to the particular requester, > | or a name server may not wish to perform > | a particular operation (e.g., zone > | transfer) for particular data. > |... > |Mockapetris [Page 27] > > "configuration" != "policy". not having a hints file is, according to > other parts of the standard, a "problem with the name server." it's > certainly possible that since "authoritative only" name servers were > not contemplated by the standard, that this is an obscure corner case > and would have been resolved differently had such contemplation occurred. > > some here would like to say that "policy" includes such decisions as "i > choose to have no hints file." but rfc1035 doesn't give you that choice, > and so your choice would equate to a "problem with the name server." > > but as things stand, "2" (SERVFAIL as BIND calls it) is the right answer. Quoth RFC 1034: If recursive service is not requested or is not available, the non- recursive response will be one of the following: - An authoritative name error indicating that the name does not exist. - A temporary error indication. - Some combination of: RRs that answer the question, together with an indication whether the data comes from a zone or is cached. A referral to name servers which have zones which are closer ancestors to the name than the server sending the reply. - RRs that the name server thinks will prove useful to the requester. According to strict interpretation of this standard, an implementation conforms as long as it provides at least one RRset that it considers "useful to the requester". Under this vague standard, I vote for returning !AA, ANCOUNT=0, and an NS RRset in the Authority Section for one of the nameserver's authoritative zones, chosen at random, or based on some arbitrary measure of predicted "usefulness" to the requestor. :-) Seriously, though, I think the spirit of the standards dictates that REFUSED is only used for deliberate, policy-based denials of access (as Paul implied). SERVFAIL, on the other hand, implies an operational problem with the nameserver. Just because the nameserver is implemented as authoritative-only without any root hints doesn't, in my opinion, warrant a SERVFAIL response. Implementation != operation. As a DNS administrator, first and foremost, I don't want to go on a wild goose chase, looking to find an operational problem with someone's nameserver, only to discover in the final analysis that the implementation simply doesn't support root hints. I think a compelling argument can be made for NOTIMP here: after all, the query, being outside of the server's authoritative zones, is one which the particular server implementation is not equipped to handle... - Kevin P.S. One more thing to put on the TODO list for the inevitable RFC 1034/1035 rewrite... -- 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 Apr 3 16:27:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16227 for ; Wed, 3 Apr 2002 16:27:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sryy-000IBz-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 13:07:52 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16sryx-000IBs-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 13:07:51 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 4FDEC28DC4 for ; Wed, 3 Apr 2002 13:07:51 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits In-Reply-To: Message from Carl Perry of "Wed, 03 Apr 2002 16:12:47 CST." <20020403161247.C30198@onramp.southern-star-ranch.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 03 Apr 2002 13:07:51 -0800 Message-Id: <20020403210751.4FDEC28DC4@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I think this is the way to go. A6 is a good idea, in general. However, > having the resolver on a client have to perform multiple queries to get > a single name resolved is not a good idea. End-points in the DNS tree > should be able to ask DNS server/cache systems to provide them an AAAA > answer to a name. The server/cache should be able to handle AAAA and > A6, and convert A6 records to AAAA responses accordingly. This gives > the ability for "easy" address renumeration, and a thinner client > resolver profile. In short, it's the best of both worlds. what the world is coming to is that applications (by which i include stub resolvers) will have to have available to them a far simpler protocol/API than full DNS. is that what we all really want? what it would look like is "applications make TSIG'd AAAA and A queries of their local recursive name server" and "recursive name servers will use EDNS0, DNSSEC, and A6." that doesn't cover the DNAME/PTR issue but that falls out naturally. that doesn't cover the synthesized AAAA issue but that also falls out naturally. the question is, before we go into detail on it, is: have we really and truly put so much mass into the DNS protocol that most applications (and most stub resolvers) cannot reasonably be expected to speak it? once we know that, we know how to proceed. -- 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 Apr 3 16:47:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16782 for ; Wed, 3 Apr 2002 16:47:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ssNV-000JLu-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 13:33:13 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16ssNV-000JLo-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 13:33:13 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5A9791BB2 for ; Wed, 3 Apr 2002 16:33:12 -0500 (EST) Date: Wed, 03 Apr 2002 16:33:12 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: <20020403210235.1A25028DC4@as.vix.com> References: <20020403202234.56D3E1BB2@thrintun.hactrn.net> <20020403210235.1A25028DC4@as.vix.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020403213312.5A9791BB2@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 03 Apr 2002 13:02:35 -0800, Paul Vixie wrote: > > the way i read it, RCODE=2 is "i don't have what you want" whereas RCODE=5 > is "i have it but i'm just not going to tell you." Whereas I read RCODE=2 as "I'm broken" and RCODE=5 as "Thhhppt!". -- 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 Apr 3 17:02:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17152 for ; Wed, 3 Apr 2002 17:02:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16ssbn-000Jxw-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 13:47:59 -0800 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.35 #1) id 16ssbl-000Jxo-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 13:47:57 -0800 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g33Llot20048; Wed, 3 Apr 2002 23:47:50 +0200 (CEST) (envelope-from alexis) Message-Id: <200204032147.g33Llot20048@open.nlnetlabs.nl> Subject: Re: name server without root cache In-Reply-To: <20020403202016.54F3028DC4@as.vix.com> "from Paul Vixie at Apr 3, 2002 12:20:16 pm" To: Paul Vixie Date: Wed, 3 Apr 2002 23:47:50 +0200 (CEST) CC: IETF DNSEXT WG From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once Paul Vixie wrote: >a truncated CNAME chain, where the "next hop" is in a zone the current >server isn't authoritative for and recursion is disabled IS a "problem with >the name server" and in this case "2" (SERVFAIL) is the appropriate answer. What's wrong with giving the CNAME alone without the data it points to and let the resolver fetch it somewhere else? Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 3 17:12:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17461 for ; Wed, 3 Apr 2002 17:12:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sspd-000Kep-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 14:02:17 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16sspb-000Ke1-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 14:02:16 -0800 Received: by shell.nominum.com (Postfix, from userid 1411) id B5E313190C; Wed, 3 Apr 2002 14:02:12 -0800 (PST) To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: name server without root cache References: <20020403210235.1A25028DC4@as.vix.com> From: Bob Halley Date: 03 Apr 2002 14:02:12 -0800 In-Reply-To: <20020403210235.1A25028DC4@as.vix.com> Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > > I don't think that RFC 1035 rules out RCODE=5 in this case, because > > nothing in the text Paul quoted restricts the subset of all possible > > requestors to which one is refusing service to being a proper subset. > > the way i read it, RCODE=2 is "i don't have what you want" whereas RCODE=5 > is "i have it but i'm just not going to tell you." I agree with Rob. I read RCODE=2 as a combination of "I am broken" and "I could not answer your question due to problems in the DNS system". (It would be nice if there were separate codes for the two concepts, but oh well.) I read RCODE=5 as "I don't want to serve this request for my own reasons". That includes the policy "I only answer questions for which I am authoritative". /Bob -- 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 Apr 3 17:22:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17665 for ; Wed, 3 Apr 2002 17:22:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sst7-000Kof-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 14:05:53 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16sst5-000KoO-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 14:05:52 -0800 Received: from ripe.net (penguin.ripe.net [193.0.1.232]) by birch.ripe.net (8.11.6/8.11.6) with ESMTP id g33M5dK01485; Thu, 4 Apr 2002 00:05:39 +0200 Message-Id: <200204032205.g33M5dK01485@birch.ripe.net> To: Kevin Darcy cc: IETF DNSEXT WG Subject: Re: name server without root cache In-Reply-To: Message from Kevin Darcy of "Wed, 03 Apr 2002 16:06:32 CDT." <3CAB6ED8.FDCDEC8F@daimlerchrysler.com> Date: Thu, 04 Apr 2002 00:05:41 +0200 From: Olaf Kolkman Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * I think a compelling argument can be made for NOTIMP here: after all, the * query, being outside of the server's authoritative zones, is one which the * particular server implementation is not equipped to handle... But in the case of NSD the nameserver has a mechanism for returning 'hints' available but either an error is made or a policy decision. NOTIMP is I would say not the proper return code. We made it a (not so explicit) requirement for NSD that a hints file is to be included if the server is not authoritative for the root. Hence a SERVFAIL if it is not there. Now Jacob argues that one should be able to refuse handing out the hints, as a policy. If that is a requirement for NSD we should return REFUSE. Judging from the RFCs (the bit which says that useful data should be returned in the answer) and the discussion on the list I would say we stick with the requirement that hints MUST be configured. We'll make that requirement more explicit. Thanks for the input. --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 Wed Apr 3 17:30:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17752 for ; Wed, 3 Apr 2002 17:30:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16st4c-000LPU-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 14:17:46 -0800 Received: from fxshpr06.extra.daimlerchrysler.com ([208.154.80.165]) by psg.com with esmtp (Exim 3.35 #1) id 16st4c-000LPM-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 14:17:46 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id g33MK9o28300 for ; Wed, 3 Apr 2002 17:20:09 -0500 (EST) Received: from nodnsquery(129.9.202.19) by fxshpr06.extra.daimlerchrysler.com via csmap (V6.0) id srcAAArpayr3; Wed, 3 Apr 02 17:20:09 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.61]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g33MHiL21887 for ; Wed, 3 Apr 2002 17:17:44 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.61]) by wokcdts1.is.chrysler.com (8.11.2/8.9.1) with ESMTP id g33MGTW22280 for ; Wed, 3 Apr 2002 17:16:30 -0500 (EST) Message-ID: <3CAB7F3D.B77D6A69@daimlerchrysler.com> Date: Wed, 03 Apr 2002 17:16:29 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: IETF DNSEXT WG Subject: Re: name server without root cache References: <200204032205.g33M5dK01485@birch.ripe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf Kolkman wrote: > * I think a compelling argument can be made for NOTIMP here: after all, the > * query, being outside of the server's authoritative zones, is one which the > * particular server implementation is not equipped to handle... > > But in the case of NSD the nameserver has a mechanism for returning > 'hints' available but either an error is made or a policy > decision. Okay, I misunderstood the context. I thought root hints was simply not a capability that the implementation supported. In such a (apparently hypothetical) case, I'd say NOTIMP would be correct. - 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 Wed Apr 3 17:49:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18144 for ; Wed, 3 Apr 2002 17:49:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16stPH-000MNe-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 14:39:07 -0800 Received: from fxshpr06.extra.daimlerchrysler.com ([208.154.80.165]) by psg.com with esmtp (Exim 3.35 #1) id 16stPG-000MNY-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 14:39:06 -0800 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id g33MfUF00042 for ; Wed, 3 Apr 2002 17:41:30 -0500 (EST) Received: from nodnsquery(129.9.202.19) by fxshpr06.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAG4a4ea; Wed, 3 Apr 02 17:41:30 -0500 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.61]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g33Md5L24193 for ; Wed, 3 Apr 2002 17:39:05 -0500 (EST) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.61]) by wokcdts1.is.chrysler.com (8.11.2/8.9.1) with ESMTP id g33MboW22310 for ; Wed, 3 Apr 2002 17:37:50 -0500 (EST) Message-ID: <3CAB843E.13631EAC@daimlerchrysler.com> Date: Wed, 03 Apr 2002 17:37:50 -0500 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: name server without root cache References: <20020403210235.1A25028DC4@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bob Halley wrote: > Paul Vixie writes: > > > > I don't think that RFC 1035 rules out RCODE=5 in this case, because > > > nothing in the text Paul quoted restricts the subset of all possible > > > requestors to which one is refusing service to being a proper subset. > > > > the way i read it, RCODE=2 is "i don't have what you want" whereas RCODE=5 > > is "i have it but i'm just not going to tell you." > > I agree with Rob. > > I read RCODE=2 as a combination of "I am broken" and "I could not > answer your question due to problems in the DNS system". (It would be > nice if there were separate codes for the two concepts, but oh well.) > > I read RCODE=5 as "I don't want to serve this request for my own > reasons". That includes the policy "I only answer questions for which > I am authoritative". Right, but is it a *policy* or a *capability*? In the hypothetical case of a nameserver implementation which only serves authoritative zones and has no provision for root hints, I think NOTIMP is even more appropriate than REFUSED. REFUSED might mislead a resolver into thinking that the query might succeed if it uses a different signing key, for example, or a different query source address (if it has a choice of same) or changing some other attribute or characteristic of the query transaction in order to placate the nameserver's policy-based access controls. NOTIMP is more final/definitive. I guess the antecedent question here is: do the standards *mandate* that nameservers support root hints? I don't think they do (under a strict reading, at least), nor do I think they *should*. - 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 Wed Apr 3 18:27:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18654 for ; Wed, 3 Apr 2002 18:27:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16stx3-000O06-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 15:14:01 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16stx2-000O00-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 15:14:00 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id EC59028E19 for ; Wed, 3 Apr 2002 15:13:59 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: name server without root cache In-Reply-To: Message from Alexis Yushin of "Wed, 03 Apr 2002 23:47:50 +0200." <200204032147.g33Llot20048@open.nlnetlabs.nl> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 03 Apr 2002 15:13:59 -0800 Message-Id: <20020403231359.EC59028E19@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >a truncated CNAME chain, where the "next hop" is in a zone the current > >server isn't authoritative for and recursion is disabled IS a "problem with > >the name server" and in this case "2" (SERVFAIL) is the appropriate answer. > > What's wrong with giving the CNAME alone without the data it points to > and let the resolver fetch it somewhere else? RD=1 means "i can't iterate so don't bother sending me a delegation or anything else i would have to process and follow, i'm sending this one question, and i'm going to act based on the one answer, and that's that." -- 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 Apr 3 18:38:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18994 for ; Wed, 3 Apr 2002 18:38:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16suCd-000Onj-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 15:30:07 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16suCc-000Onb-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 15:30:06 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 318F01BB2 for ; Wed, 3 Apr 2002 18:30:05 -0500 (EST) Date: Wed, 03 Apr 2002 18:30:04 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: <3CAB843E.13631EAC@daimlerchrysler.com> References: <20020403210235.1A25028DC4@as.vix.com> <3CAB843E.13631EAC@daimlerchrysler.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020403233005.318F01BB2@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 03 Apr 2002 17:37:50 -0500, Kevin Darcy wrote: > > Right, but is it a *policy* or a *capability*? In the hypothetical case of a > nameserver implementation which only serves authoritative zones and has no > provision for root hints, I think NOTIMP is even more appropriate than REFUSED. > REFUSED might mislead a resolver into thinking that the query might succeed if > it uses a different signing key, for example, or a different query source > address (if it has a choice of same) or changing some other attribute or > characteristic of the query transaction in order to placate the nameserver's > policy-based access controls. NOTIMP is more final/definitive. That's plausable, iff we believe that everybody either groks NOTIMP or will fail in some sane way without understanding NOTIMP. > I guess the antecedent question here is: do the standards *mandate* that > nameservers support root hints? I don't think they do (under a strict reading, > at least), nor do I think they *should*. I'm pretty sure that there's explicit requirement that a name server know anything at all beyond the (possibly empty) set of zones for which it is authoritative, but I will confess that it's been a few years since I had cause to read that part of the spec carefully. Keep in mind that the "safety belt" information that's sometimes incorrectly referred to as "root hints" is really just a list of IP addresses of name servers for an iterative resolver to ask when it has no better idea of where to send a query. This is most commonly used by an iterative resolver that's trying to find the root during what BIND refers as the priming query, but the protocol allows queries to complete without the resolver ever knowing where the root is, if the resolver just happens by chance to ask the right name server (and choses to believe the answer). It's clear that the resolution process will never complete in the general case unless -somebody- in the query path knows where the root is, but the core protocol doesn't assume either that every name server knows or that every resolver knows. -- 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 Apr 3 19:09:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19551 for ; Wed, 3 Apr 2002 19:09:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sugj-0000Ee-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 16:01:13 -0800 Received: from caperry-pc1.isot.com ([208.27.64.66] helo=southern-star-ranch.com) by psg.com with smtp (Exim 3.35 #1) id 16sugi-0000EX-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 16:01:13 -0800 Received: (qmail 32533 invoked by uid 500); 4 Apr 2002 01:31:08 -0000 Date: Wed, 3 Apr 2002 19:31:08 -0600 From: Carl Perry To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: DNS Complexity (was: A6/DNAME usage guidelines and limits) Message-ID: <20020403193108.E30198@onramp.southern-star-ranch.com> Reply-To: Carl Perry References: <20020403210751.4FDEC28DC4@as.vix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OROCMA9jn6tkzFBc" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020403210751.4FDEC28DC4@as.vix.com>; from paul@vix.com on Wed, Apr 03, 2002 at 01:07:51PM -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --OROCMA9jn6tkzFBc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 03, 2002 at 01:07:51PM -0800, Paul Vixie wrote: > the question is, before we go into detail on it, is: have we really and > truly put so much mass into the DNS protocol that most applications (and > most stub resolvers) cannot reasonably be expected to speak it? I believe so. I don't know about you, but my cell phone has a hard enough time not dropping packets and doing name queries as it is - I would hate to see it do a six-level A6 query with DNSSEC on. I think we at least have to be able to support a "slimmer" subset of the entire DNS system for tree-tip devices. I see technologies like DNSSEC and A6 as server/cache level technologies. Let's face it, if your client resolver supports DNSSEC and your caching server doesn't - you are not making any gains on the anti-spoofing front. Sure, a client _can_ support DNSSEC if it wants to, but I don't think it should be a requirement. On top of the "easier to implement a resolver" front, there is also the improvements to the end user. With any luck, your DNS caching server has a lower latency connection to the Internet than your 56k modem. So, one can hope that if the server with the better connection does the bulk of the network-intensive legwork and then caches the result you are going to have a much better response time than if you did it yourself. You'll have an even faster lookup time if some of the A6 tiers are already cached as well. What do you think? =20 --=20 -Carl Perry caperry@edolnx.net "Deliver yesterday, code today, think tomorrow." --OROCMA9jn6tkzFBc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8q6zcUL2zshtaNRYRAuQCAJ49O+r3MsisqPhfoAtiOuOPj4vj8gCeM3D7 1bArDeLHK0M4X7wkHEEehq0= =454e -----END PGP SIGNATURE----- --OROCMA9jn6tkzFBc-- -- 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 Apr 3 19:20:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19740 for ; Wed, 3 Apr 2002 19:20:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sus1-0000n3-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 16:12:53 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16sus0-0000ms-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 16:12:52 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id B7FF128E19 for ; Wed, 3 Apr 2002 16:12:48 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNS Complexity (was: A6/DNAME usage guidelines and limits) In-Reply-To: Message from Carl Perry of "Wed, 03 Apr 2002 19:31:08 CST." <20020403193108.E30198@onramp.southern-star-ranch.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Wed, 03 Apr 2002 16:12:48 -0800 Message-Id: <20020404001248.B7FF128E19@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > the question is, before we go into detail on it, is: have we really and > > truly put so much mass into the DNS protocol that most applications (and > > most stub resolvers) cannot reasonably be expected to speak it? > > I believe so. I don't know about you, but my cell phone has a hard > enough time not dropping packets and doing name queries as it is - I > would hate to see it do a six-level A6 query with DNSSEC on. does that mean that we as protocol designers have failed somehow? (this was not the anticipated mode when all this technology was planned out.) > Let's face it, if your client resolver supports DNSSEC and your > caching server doesn't - you are not making any gains on the > anti-spoofing front. that, at least, is untrue. a client which fully implements DNSSEC can know whether its forwarders are corrupt -- at least in the case where the data has been signed. > Sure, a client _can_ support DNSSEC if it wants to, but I don't think > it should be a requirement. what this means is the "light weight resolver" protocol we did for BIND9 was a complete waste of time, and simple AAAA and A queries should have been used. (right?) > What do you think? =20 i think it's very late in the game to be holding this conversation. -- 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 Apr 3 19:23:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19788 for ; Wed, 3 Apr 2002 19:23:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16susc-0000pk-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 16:13:30 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.35 #1) id 16susb-0000pc-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 16:13:29 -0800 From: Masataka Ohta Message-Id: <200204032359.IAA24516@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA24516; Thu, 4 Apr 2002 08:59:16 +0900 Subject: Re: name server without root cache In-Reply-To: <20020403233005.318F01BB2@thrintun.hactrn.net> from Rob Austein at "Apr 3, 2002 06:30:04 pm" To: Rob Austein Date: Thu, 4 Apr 2002 08:59:15 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austin; > It's clear that the resolution process will never complete in the > general case unless -somebody- in the query path knows where the root > is, but the core protocol doesn't assume either that every name server > knows or that every resolver knows. RFC 1034: : 5.3.1. Stub resolvers : : One option for implementing a resolver is to move the resolution : function out of the local machine and into a name server which supports : recursive queries. RFC 1035: : In either case, : resolvers are replaced with stub resolvers which act as front ends to : resolvers located in a recursive server in one or more name servers : known to perform that service: : : Local Hosts | Foreign : | : +---------+ | : | | responses | : | Stub |<--------------------+ | : | Resolver| | | : | |----------------+ | | : +---------+ recursive | | | : queries | | | : V | | : +---------+ recursive +----------+ | +--------+ : | | queries | |queries | | | : | Stub |-------------->| Recursive|---------|->|Foreign | : | Resolver| | Server | | | Name | : | |<--------------| |<--------|--| Server | : +---------+ responses | |responses| | | : +----------+ | +--------+ : | Central | | : | cache | | : +----------+ | It's just a malconfiguration at the resolver side that it is not surprising that there can be no proper behaviour at the server side. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 3 21:44:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22743 for ; Wed, 3 Apr 2002 21:44:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sx4q-0007Kw-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 18:34:16 -0800 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.35 #1) id 16sx4p-0007Kq-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 18:34:16 -0800 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g342YBe21429; Thu, 4 Apr 2002 04:34:11 +0200 (CEST) (envelope-from alexis) Message-Id: <200204040234.g342YBe21429@open.nlnetlabs.nl> Subject: Re: name server without root cache In-Reply-To: <20020403231359.EC59028E19@as.vix.com> "from Paul Vixie at Apr 3, 2002 03:13:59 pm" To: Paul Vixie Date: Thu, 4 Apr 2002 04:34:11 +0200 (CEST) CC: IETF DNSEXT WG From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once Paul Vixie wrote: >> What's wrong with giving the CNAME alone without the data it points to >> and let the resolver fetch it somewhere else? > >RD=1 means "i can't iterate so don't bother sending me a delegation or >anything else i would have to process and follow, i'm sending this one >question, and i'm going to act based on the one answer, and that's that." Alright, we've missed that one. I was ignoring RD at all, I'll fix it. Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 3 21:44:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22755 for ; Wed, 3 Apr 2002 21:44:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16sx6Q-0007Rr-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 18:35:54 -0800 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.35 #1) id 16sx6P-0007Rl-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 18:35:53 -0800 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g342Zjr21444; Thu, 4 Apr 2002 04:35:45 +0200 (CEST) (envelope-from alexis) Message-Id: <200204040235.g342Zjr21444@open.nlnetlabs.nl> Subject: Re: name server without root cache In-Reply-To: <20020403233005.318F01BB2@thrintun.hactrn.net> "from Rob Austein at Apr 3, 2002 06:30:04 pm" To: Rob Austein Date: Thu, 4 Apr 2002 04:35:45 +0200 (CEST) CC: namedroppers@ops.ietf.org From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Keep in mind that the "safety belt" information that's sometimes >incorrectly referred to as "root hints" is really just a list of IP >addresses of name servers for an iterative resolver to ask when it has >no better idea of where to send a query. This is most commonly used Worst case scenario is when RA=0 server has outdated .hints file. Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 4 02:23:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05977 for ; Thu, 4 Apr 2002 02:23:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t1NB-000KVC-00 for namedroppers-data@psg.com; Wed, 03 Apr 2002 23:09:29 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16t1NA-000KV0-00 for namedroppers@ops.ietf.org; Wed, 03 Apr 2002 23:09:28 -0800 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g3479EK23026; Thu, 4 Apr 2002 09:09:14 +0200 Date: Thu, 4 Apr 2002 09:09:17 +0200 From: "Olaf M. Kolkman" To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call Message-Id: <20020404090917.61c57321.olaf@ripe.net> In-Reply-To: <20020403152418.V2582-100000@node10c4d.a2000.nl> References: <20020403112549.6693629d.olaf@ripe.net> <20020403152418.V2582-100000@node10c4d.a2000.nl> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 3 Apr 2002 21:05:40 +0200 (CEST) Roy Arends wrote: > No. > > A domain indicates that a subdomain is considered signed (DS/KEY). A > preconfigured key (in the resolver) indicates a domain is considered > signed. Resolver considers world under a domain secured until a > "no-ds/key" or an opt-in NXT record states otherwise. Correct... I was confused, others might think I was on drugs. :-) Time to implement a verifier... that will teach me. --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 Thu Apr 4 07:05:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10888 for ; Thu, 4 Apr 2002 07:05:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t5ki-00049z-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 03:50:04 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16t5kh-00049f-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 03:50:03 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g34BpmF02178; Thu, 4 Apr 2002 18:51:51 +0700 (ICT) From: Robert Elz To: Danny Mayer cc: namedroppers@ops.ietf.org Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed Standard In-Reply-To: <4.3.1.2.20020402180848.038a3a70@pop.gis.net> References: <4.3.1.2.20020402180848.038a3a70@pop.gis.net> <20020329204419.2A23A1C11@thrintun.hactrn.net> <20020329204419.2A23A1C11@thrintun.hactrn.net> <200203141526.KAA19163@ietf.org> <20020327212727.B23106@connect.com.au> <2cu1r1lw8k.fsf@snout.autonomica.net> <20020328094454.A5859@connect.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Apr 2002 18:51:48 +0700 Message-ID: <2176.1017921108@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 02 Apr 2002 18:13:34 -0500 From: Danny Mayer Message-ID: <4.3.1.2.20020402180848.038a3a70@pop.gis.net> | I'm confused by this. What has the transport to do with the query? Nothing at all really. I'd much prefer that we just use A6 records now, regardless of how they're transported. But people seem to not want to wait until servers that support A6 properly are deployed. If we do nothing, and just keep on using AAAA, then A6 has no chance, there's no way to add it later - except just possibly that one - servers need to be upgraded to use IPv6 transport (which is currently useless for name resolution in general, as you there are no IPv6 reachable root servers, and no IPv6 addresses, whatever the RR format, in referrals anywhere that really matters). So, that provides us with perhaps one compromise that will allow people to start deploying more IPv6 in the DNS now, while not completely shutting the door on A6. 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 Apr 4 08:52:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14272 for ; Thu, 4 Apr 2002 08:52:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t7QK-0007iI-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 05:37:08 -0800 Received: from randy.ru.ac.za ([146.231.128.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16t7QJ-0007iB-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 05:37:07 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16t7Qt-000EkF-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 15:37:43 +0200 Message-Id: <200204031556.PAA00844@vacation.karoshi.com> In-Reply-To: from "Edward Lewis" at Apr 03, 2002 08:21:45 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@karoshi.com Subject: Re: Opt-in wg last call To: lewis@tislabs.com (Edward Lewis) Date: Wed, 3 Apr 2002 15:56:52 +0000 (UCT) Cc: namedroppers@ops.ietf.org, lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > What makes this troublesome is that the victim, in this case monopoly.int, > is at risk becuase of a policy decision made by some one else (.int). It > is not a matter of .int shooting themselves in tht foot, but .int shooting > one of the legitmate delegations in the leg. > > So, it seems that opt-in allows one organization to put another at risk. > Twas ever thus. A parent can always mess with direct delegations. Children (these days) generally have no recourse if the parent makes a policy that the child is unable to accomodate. The question might be more interesting if you could claim that opt-in allows one organization to place another at risk when the relationship between the two organizations is not parent/child. --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 Apr 4 09:06:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14889 for ; Thu, 4 Apr 2002 09:06:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t7i1-0008KO-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 05:55:25 -0800 Received: from randy.ru.ac.za ([146.231.128.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16t7i0-0008K5-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 05:55:25 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16t7ia-000Ems-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 15:56:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020403213225.13632.qmail@cr.yp.to> References: <20020403102200.A550@outpost.ds9a.nl> <20020403105747.T16642-100000@padda.telia.net> Date: 3 Apr 2002 21:32:25 -0000 From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: name server without root cache Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit tinydns discards misdirected queries. Mats Dufberg writes: > According to my view, the best practice is to have a hint file, and > return a referal to the root. Root referrals are useless. Caches discard them. (Any cache that doesn't is horribly broken.) Maintaining the root addresses in a non-caching server is a waste of administrative time. There's no reason that the server should know anything about the roots. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- 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 Apr 4 09:41:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16509 for ; Thu, 4 Apr 2002 09:41:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t8J6-0009lz-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 06:33:44 -0800 Received: from mail.jhsoft.com ([206.137.17.85]) by psg.com with esmtp (Exim 3.35 #1) id 16t8J5-0009le-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 06:33:43 -0800 Received: from hp [192.168.200.103] by mail.jhsoft.com [127.0.0.1] with SMTP (MDaemon.PRO.v5.0.4.R) for ; Thu, 04 Apr 2002 09:31:58 -0500 From: "Jesper G. Hoy" To: Subject: RE: name server without root cache Date: Thu, 4 Apr 2002 09:28:40 -0500 Message-ID: <000b01c1dbe5$045fb760$6400a8c0@hp> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020403213225.13632.qmail@cr.yp.to> Importance: Normal X-Lookup-Warning: reverse lookup on original sender failed X-MDRemoteIP: 192.168.200.103 X-Return-Path: jhoy@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > Root referrals are useless. Caches discard them. (Any cache that > doesn't is horribly broken.) > Maintaining the root addresses in a non-caching server is a > waste of administrative time. There's no reason that the server > should know anything about the roots. I second that!! Further - why invent new logic (lines of code to execute) to provide an error code for this situation ? If a server cannot provide a referral (to root servers or otherwise), that's not an error, just a fact. IMHO the appropriate response from such a server would simply be empty - no error code and no answer/referral (following the RFC1034 section 4.3.2 algorithm). Jesper G. Hoy -- 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 Apr 4 10:36:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19033 for ; Thu, 4 Apr 2002 10:36:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t983-000Bll-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 07:26:23 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.35 #1) id 16t982-000Blf-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 07:26:22 -0800 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 KAA28701; Thu, 4 Apr 2002 10:26:20 -0500 (EST) 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 KAA11707; Thu, 4 Apr 2002 10:26:13 -0500 (EST) 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 KAA05796; Thu, 4 Apr 2002 10:26:08 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA16222; Thu, 4 Apr 2002 10:26:08 -0500 (EST) To: bmanning@karoshi.com Cc: lewis@tislabs.com (Edward Lewis), namedroppers@ops.ietf.org Subject: typo attack (was Re: Opt-in wg last call) References: <200204031556.PAA00844@vacation.karoshi.com> From: Derek Atkins Date: 04 Apr 2002 10:26:08 -0500 In-Reply-To: <200204031556.PAA00844@vacation.karoshi.com> 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 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bmanning@karoshi.com writes: > > What makes this troublesome is that the victim, in this case monopoly.int, > > is at risk becuase of a policy decision made by some one else (.int). It > > is not a matter of .int shooting themselves in tht foot, but .int shooting > > one of the legitmate delegations in the leg. > > > > So, it seems that opt-in allows one organization to put another at risk. > > > Twas ever thus. A parent can always mess with direct delegations. > Children (these days) generally have no recourse if the parent > makes a policy that the child is unable to accomodate. > The question might be more interesting if you could claim that > opt-in allows one organization to place another at risk when > the relationship between the two organizations is not > parent/child. > --bill Bill, The issue with the typo attack is that: - Assume that monopoly.int exists, and an attacker is trying to defaud them. - Assume the attacker tries to defraud by registering a "close" domain name. There is nothing illegal with registering a "close" domain name, however there are laws against fraud. If the parent allows m0n0p0ly.int to be registered, but the courts rule of fraud against monopoly.int, then there would be a legal recourse to remove the domain. In other words, there are laws to prevent fraud, and monopoly.int could use them to protect itself. In this case, the remedy could be the removal of m0n0p0ly.int from the domain. - However, if the parent domain used opt-in, then an attacker could poison caches with m0n0p0ly.int in order to defraud, and there is no protection. The only protection against this attack is authenticated denial of the fraudulent domain. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 4 10:42:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19373 for ; Thu, 4 Apr 2002 10:42:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t9FD-000C5P-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 07:33:47 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.35 #1) id 16t9FC-000C52-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 07:33:46 -0800 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 KAA25426; Thu, 4 Apr 2002 10:33:45 -0500 (EST) 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 KAA07931; Thu, 4 Apr 2002 10:30:48 -0500 (EST) 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 KAA08513; Thu, 4 Apr 2002 10:30:47 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA16234; Thu, 4 Apr 2002 10:30:47 -0500 (EST) To: Carl Perry Cc: namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits References: <20020402164751.E19210@connect.com.au> <20020403155942.A30198@onramp.southern-star-ranch.com> From: Derek Atkins Date: 04 Apr 2002 10:30:47 -0500 In-Reply-To: <20020403155942.A30198@onramp.southern-star-ranch.com> Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Carl Perry writes: > I think this is the way to go. A6 is a good idea, in general. However, > having the resolver on a client have to perform multiple queries to get > a single name resolved is not a good idea. End-points in the DNS tree > should be able to ask DNS server/cache systems to provide them an AAAA > answer to a name. The server/cache should be able to handle AAAA and > A6, and convert A6 records to AAAA responses accordingly. This gives > the ability for "easy" address renumeration, and a thinner client > resolver profile. In short, it's the best of both worlds. Note that there is no way to authenticate a AAAA-synthesis. You can require TSIG between the 'lightweight resolver' and the synthesizing resolver, I suppose, and require the synthesizing resolver to verify the DNSSEC response(s). However as an application writer I can envision endpoint applications (users of DNS) that would want access to the DNSSEC responses themselves. How would you do that with AAAA synthesis? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 4 11:08:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20606 for ; Thu, 4 Apr 2002 11:08:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16t9df-000DBl-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 07:59:03 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16t9de-000DBd-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 07:59:02 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g34G0eF03159; Thu, 4 Apr 2002 23:00:41 +0700 (ICT) From: Robert Elz To: Derek Atkins cc: Carl Perry , namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits In-Reply-To: References: <20020402164751.E19210@connect.com.au> <20020403155942.A30198@onramp.southern-star-ranch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Apr 2002 23:00:40 +0700 Message-ID: <3157.1017936040@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 04 Apr 2002 10:30:47 -0500 From: Derek Atkins Message-ID: | However as an application writer I can | envision endpoint applications (users of DNS) that would want access | to the DNSSEC responses themselves. How would you do that with AAAA | synthesis? Clearly you wouldn't. You (the application writer) will just send a query for A6 records instead. Then you'll get the A6 records, and their SIGs, returned to you. AAAA synthesis is an option, one which is liklely to be heavily used - using it will never be a requirement. If your application can handle chasing the SIG/KEY/DS/NXT/... stuff to validate the records, it can certainly also do the extra triviality of chasing the A6 chain, which is much simpler. 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 Apr 4 12:01:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22949 for ; Thu, 4 Apr 2002 12:01:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tAW9-000FaE-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 08:55:21 -0800 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.35 #1) id 16tAW8-000Fa7-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 08:55:20 -0800 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 LAA09198; Thu, 4 Apr 2002 11:55:17 -0500 (EST) 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 LAA00879; Thu, 4 Apr 2002 11:55:15 -0500 (EST) 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 LAA12373; Thu, 4 Apr 2002 11:55:12 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA16397; Thu, 4 Apr 2002 11:55:12 -0500 (EST) To: Robert Elz Cc: Carl Perry , namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits References: <20020402164751.E19210@connect.com.au> <20020403155942.A30198@onramp.southern-star-ranch.com> <3157.1017936040@brandenburg.cs.mu.OZ.AU> From: Derek Atkins Date: 04 Apr 2002 11:55:12 -0500 In-Reply-To: <3157.1017936040@brandenburg.cs.mu.OZ.AU> Message-ID: Lines: 65 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > Clearly you wouldn't. You (the application writer) will just send > a query for A6 records instead. Then you'll get the A6 records, and > their SIGs, returned to you. AAAA synthesis is an option, one which > is liklely to be heavily used - using it will never be a requirement. > > If your application can handle chasing the SIG/KEY/DS/NXT/... stuff to > validate the records, it can certainly also do the extra triviality of > chasing the A6 chain, which is much simpler. > > kre What happens if the A6 chain requires N hops, and I get the first three and then fail? I would like to see a situation where the client makes 1 request and gets a response with the whole A6 chain. This solves the latency issues in low bandwith situations (like cell phones) but still allows you to use A6. Here's an alternative proposal: is there some way to require that a nameserver for an A6 record be able to recurse up the chain and act as a cache for the rest of the chain? Perhaps the nameserver is required to always cache complete A6 chains? That way the client need only make one request and the responding server will follow the chain? Here's my reasoning: A server that is authoritative for the end-host is the one going to answer the _first_ entry in the A6 chain. If that server _always_ has the rest of the chain cached, and can respond with the whole chain in one answer, then the only difference between AAAA and A6 is the packet size (from an application point of view). For example, assume that MIT.EDU deploys A6 records of the form $ORIGIN provider.net. mit A6 0 <> $ORIGIN mit.edu. host A6 48 mit.provider.net. <> When the resolver asks the MIT nameservers for "host.mit.edu. A6" the server can respond with the following in a single packet: host.mit.edu A6 48 mit.provider.net. <> mit.provider.net A6 0 <> Obviously this is an implementation issue, not a protocol issue. But it would solve some of the problems that people have with A6, namely the relatively-unbounded number of round-trips required to resolve an A6 request and the possibility of failing partially through a request. I admit that this proposal does add complexity to the nameserver implementation, because they must be aware of all A6 chains and "keep" them in the cache.. Or, alternately, the nameserver must be required to recurse on their own A6 records, even if they don't necessarily recurse. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 4 12:02:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22990 for ; Thu, 4 Apr 2002 12:02:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tARu-000FOZ-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 08:50:58 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16tARt-000FOT-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 08:50:57 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 7CBE928DC4 for ; Thu, 4 Apr 2002 08:50:48 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits In-Reply-To: Message from Derek Atkins of "04 Apr 2002 10:30:47 EST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Thu, 04 Apr 2002 08:50:48 -0800 Message-Id: <20020404165048.7CBE928DC4@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Note that there is no way to authenticate a AAAA-synthesis. You can > require TSIG between the 'lightweight resolver' and the synthesizing > resolver, I suppose, and require the synthesizing resolver to verify > the DNSSEC response(s). However as an application writer I can > envision endpoint applications (users of DNS) that would want access > to the DNSSEC responses themselves. How would you do that with AAAA > synthesis? in this model, you wouldn't. QTYPE=AAAA && RD=0 would be invalid. -- 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 Apr 4 12:14:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23749 for ; Thu, 4 Apr 2002 12:14:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tAg8-000G5W-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 09:05:40 -0800 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16tAg7-000G5P-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 09:05:39 -0800 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 6D8D028DC4 for ; Thu, 4 Apr 2002 09:05:39 -0800 (PST) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits In-Reply-To: Message from Derek Atkins of "04 Apr 2002 11:55:12 EST." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Thu, 04 Apr 2002 09:05:39 -0800 Message-Id: <20020404170539.6D8D028DC4@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > What happens if the A6 chain requires N hops, and I get the first > three and then fail? then you lose, i guess. the hope is that once this situation is widely known, then improved caching robustness will be seen by network operators as a key way to increase their overall network robustness. > I would like to see a situation where the client makes 1 request and > gets a response with the whole A6 chain. This solves the latency > issues in low bandwith situations (like cell phones) but still allows > you to use A6. > > Here's an alternative proposal: is there some way to require that a > nameserver for an A6 record be able to recurse up the chain and act as > a cache for the rest of the chain? Perhaps the nameserver is required > to always cache complete A6 chains? That way the client need only > make one request and the responding server will follow the chain? in rfc2317 we "solved" this by recommending that servers for intermediate zones also slave the delegated zones. that way iteration would likely not occur beyond the octet boundary. that's probably a wise practice for A6 chain intermediaries, as well. > ... Obviously this is an implementation issue, not a protocol issue. But > it would solve some of the problems that people have with A6, namely > the relatively-unbounded number of round-trips required to resolve an > A6 request and the possibility of failing partially through a request. agreed. and as shown by rfc2317's success, it's not all that hard to do. > I admit that this proposal does add complexity to the nameserver > implementation, because they must be aware of all A6 chains and "keep" > them in the cache.. Or, alternately, the nameserver must be required > to recurse on their own A6 records, even if they don't necessarily > recurse. well, there's no way to require an authority server to fetch glue, though many will. -- 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 Apr 4 12:16:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23832 for ; Thu, 4 Apr 2002 12:16:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tAij-000GDC-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 09:08:21 -0800 Received: from randy.ru.ac.za ([146.231.128.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16tAii-000GD3-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 09:08:21 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16tAif-0000As-00; Thu, 04 Apr 2002 19:08:17 +0200 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: DNS Complexity (was: A6/DNAME usage guidelines and limits) References: <20020403193108.E30198@onramp.southern-star-ranch.com> <20020404001248.B7FF128E19@as.vix.com> Message-Id: Date: Thu, 04 Apr 2002 19:08:17 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I believe so. I don't know about you, but my cell phone has a hard >> enough time not dropping packets and doing name queries as it is - I >> would hate to see it do a six-level A6 query with DNSSEC on. > does that mean that we as protocol designers have failed somehow? yes, we allowed an overly-clever set of proposals from the ipv6 community go to far for too long. >> Sure, a client _can_ support DNSSEC if it wants to, but I don't think >> it should be a requirement. > what this means is the "light weight resolver" protocol we did for BIND9 > was a complete waste of time, and simple AAAA and A queries should have > been used. (right?) right > i think it's very late in the game to be holding this conversation. agree. so let's close this off already. pass the document. but i would add completely ditch dname as well. 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 Thu Apr 4 12:23:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24152 for ; Thu, 4 Apr 2002 12:23:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tAoU-000GUu-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 09:14:18 -0800 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.35 #1) id 16tAoT-000GUm-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 09:14:17 -0800 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 MAA09735; Thu, 4 Apr 2002 12:14:16 -0500 (EST) 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 MAA04691; Thu, 4 Apr 2002 12:14:15 -0500 (EST) 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 MAA13680; Thu, 4 Apr 2002 12:14:15 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA16440; Thu, 4 Apr 2002 12:14:15 -0500 (EST) To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits References: <20020404170539.6D8D028DC4@as.vix.com> From: Derek Atkins Date: 04 Apr 2002 12:14:15 -0500 In-Reply-To: <20020404170539.6D8D028DC4@as.vix.com> Message-ID: Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > > What happens if the A6 chain requires N hops, and I get the first > > three and then fail? > > then you lose, i guess. the hope is that once this situation is widely > known, then improved caching robustness will be seen by network operators > as a key way to increase their overall network robustness. Right. The problem is that the client resolver has _half_ the data and doesn't know when it will complete. With AAAA (or A) you get a response that is either 'yes' or 'no', not 'here is half your answer -- look here for more information'. > > I admit that this proposal does add complexity to the nameserver > > implementation, because they must be aware of all A6 chains and "keep" > > them in the cache.. Or, alternately, the nameserver must be required > > to recurse on their own A6 records, even if they don't necessarily > > recurse. > > well, there's no way to require an authority server to fetch glue, though > many will. Sure there is: "An A6 response MUST include the complete chain, or the response must be SERVFAIL." ;-) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 4 17:05:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10725 for ; Thu, 4 Apr 2002 17:05:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tF05-0000CK-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 13:42:33 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.35 #1) id 16tF03-0000Bd-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 13:42:32 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g34LgHx69102; Fri, 5 Apr 2002 07:42:18 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200204042142.g34LgHx69102@drugs.dv.isc.org> To: "Jesper G. Hoy" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: name server without root cache In-reply-to: Your message of "Thu, 04 Apr 2002 09:28:40 EST." <000b01c1dbe5$045fb760$6400a8c0@hp> Date: Fri, 05 Apr 2002 07:42:17 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > D. J. Bernstein writes: > > Root referrals are useless. Caches discard them. (Any cache that > > doesn't is horribly broken.) > > Maintaining the root addresses in a non-caching server is a > > waste of administrative time. There's no reason that the server > > should know anything about the roots. > > I second that!! > > Further - why invent new logic (lines of code to execute) to provide an > error code for this situation ? > > If a server cannot provide a referral (to root servers or otherwise), > that's not an error, just a fact. > IMHO the appropriate response from such a server would simply be empty - > no error code and no answer/referral (following the RFC1034 section > 4.3.2 algorithm). Do you really want to say that the name exist but there is no data to every query you are not authoritative for? If you can't answer the query you do not give back bogus answers. As for Dan and tinydns not answering. All that does is slow up everything creates additional unnecessary retransmissions and what for? A 12 byte REFUSED/SERVFAIL error message. Error codes were created for a reason. They should be used. As for the claim that a root referral is useless that is bogus. It allows the calling server to determine the the delegation is lame and to take appropriate action. Mark > > > Jesper G. Hoy > > > > > > -- > 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 Apr 4 17:28:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11146 for ; Thu, 4 Apr 2002 17:28:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tFRu-00015J-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 14:11:18 -0800 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16tFRt-00015D-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 14:11:17 -0800 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g34MBCQ32547; Fri, 5 Apr 2002 00:11:12 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Fri, 5 Apr 2002 00:11:12 +0200 (CEST) From: Mats Dufberg To: "Jesper G. Hoy" cc: Subject: RE: name server without root cache In-Reply-To: <000b01c1dbe5$045fb760$6400a8c0@hp> Message-ID: <20020405000024.E7955-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Apr 4, 2002, 09:28 (-0500) Jesper G. Hoy wrote: > D. J. Bernstein writes: > > Root referrals are useless. Caches discard them. (Any cache that > > doesn't is horribly broken.) > > Maintaining the root addresses in a non-caching server is a > > waste of administrative time. There's no reason that the server > > should know anything about the roots. > > I second that!! > > Further - why invent new logic (lines of code to execute) to provide an > error code for this situation ? Because it makes life much easier if we get predictable responses that we can interpret in some meaningful way. If we just get SERVFAIL or NOTIMP we cannot draw the conclusion that the server does not have the zon. Yes, a different status code would be simpler, but we are not there, so let's keep thing transparent until a new status model is in place (the status codes of DNS are unfortunately too overloaded). Some people like me like to be able to analyse broken delegations and come to some reasonable conclusion what is wrong. Knowing that the server is not configured with the zone is a good start for communcating with sometimes "broken" DNS administrators. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- 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 Apr 4 19:43:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14146 for ; Thu, 4 Apr 2002 19:43:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tHeq-0005XD-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 16:32:48 -0800 Received: from mail.jhsoft.com ([206.137.17.85]) by psg.com with esmtp (Exim 3.35 #1) id 16tHeq-0005X6-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 16:32:48 -0800 Received: from hp [192.168.200.104] by mail.jhsoft.com [127.0.0.1] with SMTP (MDaemon.PRO.v5.0.4.R) for ; Thu, 04 Apr 2002 19:30:24 -0500 From: "Jesper G. Hoy" To: , Subject: RE: name server without root cache Date: Thu, 4 Apr 2002 19:26:55 -0500 Message-ID: <000001c1dc38$9ab1d6f0$6400a8c0@hp> 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, Build 10.0.2627 In-Reply-To: <200204042142.g34LgHx69102@drugs.dv.isc.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Lookup-Warning: reverse lookup on original sender failed X-MDRemoteIP: 192.168.200.104 X-Return-Path: jhoy@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Further - why invent new logic (lines of code to execute) to provide an >> error code for this situation ? >> >> If a server cannot provide a referral (to root servers or otherwise), >> that's not an error, just a fact. >> IMHO the appropriate response from such a server would simply be empty - >> no error code and no answer/referral (following the RFC1034 section >> 4.3.2 algorithm). > > Do you really want to say that the name exist but there is no > data to every query you are not authoritative for? If you > can't answer the query you do not give back bogus answers. No - not at all!! would require a SOA-record in the Authority section. That's very different from what I was suggesting: an empty response (nothing in the Answer, Authority and Additional sections). If believe that RFC2308 (Negative caching...) goes into some detail on this. > As for Dan and tinydns not answering. All that does is > slow up everything creates additional unnecessary retransmissions > and what for? A 12 byte REFUSED/SERVFAIL error message. > Error codes were created for a reason. They should be used. I agree that the server should respond. Ignoring the query would probably result in multiple re-transmissions - not desirable. > As for the claim that a root referral is useless that is bogus. > It allows the calling server to determine the the delegation > is lame and to take appropriate action. The calling server should be able to determine the lame situation based on the missing AA flag and no referral to closer servers. Looking specifically for the root servers in the response to determine this situation (lame) could even be dangerous - imagine some server using an "alternate root server list" - like Pacific Root and the like... From a programming standpoint it makes sense to return the root server list because it's the simple thing to do - same logic as any other cache lookup. I suspect this is the only reason why most implementations do it. But I'm still with Dan on this point - I don't see how this response (root server list) can be used for anything by the calling server. Jesper G. Hoy -- 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 Apr 4 19:54:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14268 for ; Thu, 4 Apr 2002 19:54:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tHsT-000606-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 16:46:53 -0800 Received: from mail.jhsoft.com ([206.137.17.85]) by psg.com with esmtp (Exim 3.35 #1) id 16tHsS-000600-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 16:46:52 -0800 Received: from hp [192.168.200.104] by mail.jhsoft.com [127.0.0.1] with SMTP (MDaemon.PRO.v5.0.4.R) for ; Thu, 04 Apr 2002 19:44:38 -0500 From: "Jesper G. Hoy" To: , "'Mats Dufberg'" Subject: RE: name server without root cache Date: Thu, 4 Apr 2002 19:41:12 -0500 Message-ID: <000101c1dc3a$99498270$6400a8c0@hp> 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, Build 10.0.2627 In-Reply-To: <20020405000024.E7955-100000@padda.telia.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Lookup-Warning: reverse lookup on original sender failed X-MDRemoteIP: 192.168.200.104 X-Return-Path: jhoy@jhsoft.com X-MDaemon-Deliver-To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Further - why invent new logic (lines of code to execute) to provide an >> error code for this situation ? > > Because it makes life much easier if we get predictable responses that we > can interpret in some meaningful way. If we just get SERVFAIL or NOTIMP > we cannot draw the conclusion that the server does not have the zon. I agree - SERVFAIL / NOTIMP are not the solutions for this. We already have a well defined way to determine if a server has a zone - the AA-flag in the response. > Yes, a different status code would be simpler, but we are not there, so > let's keep thing transparent until a new status model is in place (the > status codes of DNS are unfortunately too overloaded). > Some people like me like to be able to analyse broken delegations and come > to some reasonable conclusion what is wrong. Knowing that the server is > not configured with the zone is a good start for communcating with > sometimes "broken" DNS administrators. DNS could certainly use more specific status codes. However, for this particular scenario I think it's already pretty well defined (AA-flag / missing closer referral) and unnecessary to invent more... Jesper G. Hoy -- 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 Apr 4 21:25:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15243 for ; Thu, 4 Apr 2002 21:25:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tJDq-0008jf-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 18:13:02 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16tJDp-0008jZ-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 18:13:01 -0800 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 33985 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 20:12:45 -0600 Message-ID: <3CAD0829.2E12A8B7@ehsco.com> Date: Thu, 04 Apr 2002 20:12:57 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers Subject: app-layer acks in DNS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As we all know, DNS doesn't provide any kind of application-layer flow-control or acknwoledgements. Queries either succeed or they fail, and the outcome is only reported when processing either succeeds or fails. However, there will often be multiple intermediate events between the final success or failure. Q: Would notifications about these transitional events be a bad thing? More specifically, consider the following example. A stub resolver issues a query to its local caching server, and as far as the stub is concerned, the query has gone into a black-hole. Meanwhile, the cache is generating bunches of queries, following referrals, chasing down CNAMEs, and so on. While all of this is happening, the stub is twiddling its thumbs, completely oblivious to everything. Given enough time, the stub will just assume failure and then go ask another server, and that server has to go beat up the network all over again. Clearly there would be some benefit to having the cache tell the stub "got some of your data, I'm on the case, hold for N seconds". The question is whether or not the amount of extra processing and messaging load would be a bad thing. Thoughts? -- 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 Apr 4 21:49:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16472 for ; Thu, 4 Apr 2002 21:49:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tJbc-0009aG-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 18:37:36 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.35 #1) id 16tJbb-0009Zg-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 18:37:35 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g352bLx72957; Fri, 5 Apr 2002 12:37:21 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200204050237.g352bLx72957@drugs.dv.isc.org> To: "Jesper G. Hoy" Cc: namedroppers@ops.ietf.org, Mark_Andrews@isc.org From: Mark.Andrews@isc.org Subject: Re: name server without root cache In-reply-to: Your message of "Thu, 04 Apr 2002 19:26:55 EST." <000001c1dc38$9ab1d6f0$6400a8c0@hp> Date: Fri, 05 Apr 2002 12:37:21 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >> Further - why invent new logic (lines of code to execute) to provide > an > >> error code for this situation ? > >> > >> If a server cannot provide a referral (to root servers or otherwise), > >> that's not an error, just a fact. > >> IMHO the appropriate response from such a server would simply be > empty - > >> no error code and no answer/referral (following the RFC1034 section > >> 4.3.2 algorithm). > > > > Do you really want to say that the name exist but there is no > > data to every query you are not authoritative for? If you > > can't answer the query you do not give back bogus answers. > > No - not at all!! > would require a SOA-record in the Authority > section. Not it doesn't. It requires a SOA to be cachable. It doesn't require a SOA to be a valid answer. > That's very different from what I was suggesting: an empty response > (nothing in the Answer, Authority and Additional sections). > If believe that RFC2308 (Negative caching...) goes into some detail on > this. Yes. I wrote RFC 2308. > > As for Dan and tinydns not answering. All that does is > > slow up everything creates additional unnecessary > retransmissions > > and what for? A 12 byte REFUSED/SERVFAIL error message. > > Error codes were created for a reason. They should be used. > > I agree that the server should respond. > Ignoring the query would probably result in multiple re-transmissions - > not desirable. > > > > As for the claim that a root referral is useless that is bogus. > > It allows the calling server to determine the the delegation > > is lame and to take appropriate action. > > The calling server should be able to determine the lame situation based > on the missing AA flag and no referral to closer servers. > > Looking specifically for the root servers in the response to determine > this situation (lame) could even be dangerous - imagine some server > using an "alternate root server list" - like Pacific Root and the > like... > > >From a programming standpoint it makes sense to return the root server > list because it's the simple thing to do - same logic as any other cache > lookup. > I suspect this is the only reason why most implementations do it. > > But I'm still with Dan on this point - I don't see how this response > (root server list) can be used for anything by the calling server. I just told you how it is used. Whether it is cached or not is another matter entirerly. > > > Jesper G. Hoy > > > > -- 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 Apr 4 21:52:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16496 for ; Thu, 4 Apr 2002 21:52:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tJhH-0009my-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 18:43:27 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.35 #1) id 16tJhG-0009ms-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 18:43:26 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g352hHx73000; Fri, 5 Apr 2002 12:43:17 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200204050243.g352hHx73000@drugs.dv.isc.org> To: "Jesper G. Hoy" Cc: namedroppers@ops.ietf.org, "'Mats Dufberg'" From: Mark.Andrews@isc.org Subject: Re: name server without root cache In-reply-to: Your message of "Thu, 04 Apr 2002 19:41:12 EST." <000101c1dc3a$99498270$6400a8c0@hp> Date: Fri, 05 Apr 2002 12:43:17 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >> Further - why invent new logic (lines of code to execute) to provide > an > >> error code for this situation ? > > > > Because it makes life much easier if we get predictable responses that > we > > can interpret in some meaningful way. If we just get SERVFAIL or > NOTIMP > > we cannot draw the conclusion that the server does not have the zon. > > I agree - SERVFAIL / NOTIMP are not the solutions for this. > We already have a well defined way to determine if a server has a zone - > the AA-flag in the response. > > > > Yes, a different status code would be simpler, but we are not there, > so > > let's keep thing transparent until a new status model is in place (the > > status codes of DNS are unfortunately too overloaded). > > Some people like me like to be able to analyse broken delegations and > come > > to some reasonable conclusion what is wrong. Knowing that the server > is > > not configured with the zone is a good start for communcating with > > sometimes "broken" DNS administrators. > > DNS could certainly use more specific status codes. > However, for this particular scenario I think it's already pretty well > defined (AA-flag / missing closer referral) and unnecessary to invent > more... No. You either return a valid answer or a error indication. rcode=noerror, nscount=0 is not a valid answer > > > Jesper G. Hoy > > > > > > -- > 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 Apr 4 22:33:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17778 for ; Thu, 4 Apr 2002 22:33:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tKJ9-000B9U-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 19:22:35 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.35 #1) id 16tKJ8-000B9A-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 19:22:34 -0800 From: Masataka Ohta Message-Id: <200204050307.MAA01435@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA01435; Fri, 5 Apr 2002 12:07:42 +0900 Subject: Re: name server without root cache In-Reply-To: <200204050243.g352hHx73000@drugs.dv.isc.org> from "Mark.Andrews@isc.org" at "Apr 5, 2002 12:43:17 pm" To: Mark.Andrews@isc.org Date: Fri, 5 Apr 2002 12:07:41 +0859 () CC: "Jesper G. Hoy" , namedroppers@ops.ietf.org, "'Mats Dufberg'" X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark; > No. You either return a valid answer or a error indication. The other option is to silently igrore a query and return nothing. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 4 22:50:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18153 for ; Thu, 4 Apr 2002 22:50:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tKYb-000BhS-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 19:38:33 -0800 Received: from smtprelay8.dc2.adelphia.net ([64.8.50.40]) by psg.com with esmtp (Exim 3.35 #1) id 16tKYZ-000Bh8-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 19:38:32 -0800 Received: from ZANNIE ([216.174.55.206]) by smtprelay8.dc2.adelphia.net (Netscape Messaging Server 4.15) with ESMTP id GU2SS201.DGO for ; Thu, 4 Apr 2002 22:38:26 -0500 Date: Thu, 4 Apr 2002 22:40:05 -0500 From: Allan Liska X-Mailer: The Bat! (v1.53d) Personal Reply-To: Allan Liska Organization: http://www.allan.org X-Priority: 3 (Normal) Message-ID: <19621523797.20020404224005@allan.org> To: namedroppers Subject: Re: app-layer acks in DNS In-Reply-To: <3CAD0829.2E12A8B7@ehsco.com> References: <3CAD0829.2E12A8B7@ehsco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Eric, Thursday, April 04, 2002, 9:12:57 PM, you wrote: EAH> Clearly there would be some benefit to having the cache tell the stub "got EAH> some of your data, I'm on the case, hold for N seconds". The question is EAH> whether or not the amount of extra processing and messaging load would be EAH> a bad thing. EAH> Thoughts? Without some sort of session tagging, how would the stub know which record the cache is talking about? I also wonder how often this is a problem? I don't see too many DNS queries that take more than 30 seconds. If this is a problem, I think it would make more sense for the cache to just give the stub the information as soon as it is found during the recursive query, and then continue with the rest of the query. allan btw: I think Internet Core Protocols is a great book. -- allan allan@allan.org http://www.allan.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 Apr 4 22:56:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18229 for ; Thu, 4 Apr 2002 22:56:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tKj1-000C7n-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 19:49:19 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16tKj1-000C7g-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 19:49:19 -0800 Received: from [128.177.195.148] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 9F2333190E; Thu, 4 Apr 2002 19:49:18 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Thu, 04 Apr 2002 19:49:22 -0800 Subject: Re: name server without root cache From: David Conrad To: Masataka Ohta , Cc: "Jesper G. Hoy" , namedroppers , "'Mats Dufberg'" Message-ID: In-Reply-To: <200204050307.MAA01435@necom830.hpcl.titech.ac.jp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 4/4/02 7:08 PM, "Masataka Ohta" wrote: >> No. You either return a valid answer or a error indication. > The other option is to silently igrore a query and return nothing. Which, as has been pointed out, is a bad idea as it triggers retransmission and causes pointless waiting. 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 Thu Apr 4 23:28:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18691 for ; Thu, 4 Apr 2002 23:28:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tLC2-000DB6-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 20:19:18 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16tLC1-000DB0-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 20:19:17 -0800 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 34001 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 22:18:55 -0600 Message-ID: <3CAD25BB.80877E6B@ehsco.com> Date: Thu, 04 Apr 2002 22:19:07 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 CC: namedroppers Subject: Re: app-layer acks in DNS References: <3CAD0829.2E12A8B7@ehsco.com> <19621523797.20020404224005@allan.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Allan Liska wrote: > Without some sort of session tagging, how would the stub know which > record the cache is talking about? Well, I was thinking that the cache would return the Question section, the flags, and an RCODE for "chasing" or whatever. > I also wonder how often this is a problem? I don't think it's much of a problem now, but I am wondering about future issues. In particular, if a cache gets in the habit of validating DNSSEC signatures on all referrals and answers then the overall latency will go up. Also, if a cache has to do multiple conversions between label formats (eg, between UTF-8 and ACE encodings) then latency will go up. If both of those happen plus a remote CNAME plus umpteen levels deep, well, you get the idea. Sooner or later all of this latency is likely to mean that clients will be timing out more often. I also think it is a good design point, although I'm not sure to what degree the cost would be worth the benefit. Clearly returning an update message for every referral would be too much noise. > I don't see too many DNS queries that take more than 30 seconds. RFC 1035 specifies a default timeout of 5 seconds. MS clients use a default timeout of 1 second. Five seconds is too high IMO. If a simple query is going to fail it will fail within a couple of seconds. On the other hand, the 1 second failure threshold is way too low. I think that the timeouts could be made less painful if there was a way to improve feedback. But the real concern I have is with tripping timeouts period. -- 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 Apr 4 23:32:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19180 for ; Thu, 4 Apr 2002 23:32:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tLHl-000DN9-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 20:25:13 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16tLHj-000DN3-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 20:25:12 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id B6E031C11 for ; Thu, 4 Apr 2002 23:25:06 -0500 (EST) Date: Thu, 04 Apr 2002 23:25:06 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Reply-To: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: <200204050243.g352hHx73000@drugs.dv.isc.org> References: <000101c1dc3a$99498270$6400a8c0@hp> <200204050243.g352hHx73000@drugs.dv.isc.org> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020405042506.B6E031C11@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 05 Apr 2002 12:43:17 +1000, Mark Andrews wrote: > > rcode=noerror, nscount=0 is not a valid answer I'm pretty sure that RFC 1035 permits QR=1 RCODE=0 AA=0 ANCOUNT=0 NSCOUNT=0 ADCOUNT=0 To the best of my limited ability to remember the contents of 15 year old packet dumps, this is exactly how the JEEVES nameserver program responded when its resolver program was disabled and it received a query for a QNAME that wasn't in any of the zones for which it had authoritative data loaded. Whether such a response would be -advisable- given what current software might think it means is a separate 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 Apr 4 23:53:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19457 for ; Thu, 4 Apr 2002 23:53:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tLdK-000E7v-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 20:47:30 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.35 #1) id 16tLdJ-000E7p-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 20:47:29 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g354lRx73508 for ; Fri, 5 Apr 2002 14:47:27 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200204050447.g354lRx73508@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: name server without root cache In-reply-to: Your message of "Thu, 04 Apr 2002 23:25:06 EST." <20020405042506.B6E031C11@thrintun.hactrn.net> Date: Fri, 05 Apr 2002 14:47:27 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob. You lost the context when you quoted. > At Fri, 05 Apr 2002 12:43:17 +1000, Mark Andrews wrote: > > > > rcode=noerror, nscount=0 is not a valid answer > > I'm pretty sure that RFC 1035 permits > > QR=1 RCODE=0 AA=0 ANCOUNT=0 NSCOUNT=0 ADCOUNT=0 Sure RFC 1035 permits it. However if your a authoritative only server and the query is above all of the zone you are serving then you are returning a bogus answer. > To the best of my limited ability to remember the contents of 15 year > old packet dumps, this is exactly how the JEEVES nameserver program > responded when its resolver program was disabled and it received a > query for a QNAME that wasn't in any of the zones for which it had > authoritative data loaded. I'd argue that JEEVES was broken if it returned that response. It shouldn't be making up answers about zones that it is not configured to serve. > Whether such a response would be -advisable- given what current > software might think it means is a separate question. Mark > > -- > 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 Fri Apr 5 01:26:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20419 for ; Fri, 5 Apr 2002 01:26:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tMvp-000Gqz-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 22:10:41 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16tMvo-000Gqi-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 22:10:40 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id C44101CA1 for ; Fri, 5 Apr 2002 01:10:39 -0500 (EST) Date: Fri, 05 Apr 2002 01:10:39 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: <200204050447.g354lRx73508@drugs.dv.isc.org> References: <20020405042506.B6E031C11@thrintun.hactrn.net> <200204050447.g354lRx73508@drugs.dv.isc.org> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020405061039.C44101CA1@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 05 Apr 2002 14:47:27 +1000, Mark Andrews wrote: > > Rob. You lost the context when you quoted. At least one of us is confused. :) >> QR=1 RCODE=0 AA=0 ANCOUNT=0 NSCOUNT=0 ADCOUNT=0 > > Sure RFC 1035 permits it. However if your a authoritative only > server and the query is above all of the zone you are serving then > you are returning a bogus answer. I don't see in what way this is a bogus answer, and you didn't elaborate, so I'll assume we're still talking about the topic named in the subject line and the objection you raised several messages back: > Do you really want to say that the name exist but there is no data > to every query you are not authoritative for? If you can't answer > the query you do not give back bogus answers. With AA=0 the name server isn't saying "the name QNAME is valid but no such RRset exists", it's saying "I don't have any such RRset cached, I am not entitled to an opinion as to whether such an RRset or such a QNAME exists because I'm not authoritative, I have no suggestions on where you should look next, and everything's fine, have a nice day." With AA=1, this would be your RFC 2308 "TYPE 3 NODATA", but with AA=0 it's just "not my department". Singularly unhelpful, but not bogus. As I said, at least one of us is confused. Please feel free to demonstrate that it's 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 Fri Apr 5 02:24:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29450 for ; Fri, 5 Apr 2002 02:24:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tNrX-000ItK-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 23:10:19 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.35 #1) id 16tNrW-000ItE-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 23:10:18 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g357A7x74531; Fri, 5 Apr 2002 17:10:09 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200204050710.g357A7x74531@drugs.dv.isc.org> To: Rob Austein Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: name server without root cache In-reply-to: Your message of "Fri, 05 Apr 2002 01:10:39 EST." <20020405061039.C44101CA1@thrintun.hactrn.net> Date: Fri, 05 Apr 2002 17:10:07 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At Fri, 05 Apr 2002 14:47:27 +1000, Mark Andrews wrote: > > > > Rob. You lost the context when you quoted. > > At least one of us is confused. :) > > >> QR=1 RCODE=0 AA=0 ANCOUNT=0 NSCOUNT=0 ADCOUNT=0 > > > > Sure RFC 1035 permits it. However if your a authoritative only > > server and the query is above all of the zone you are serving then > > you are returning a bogus answer. > > I don't see in what way this is a bogus answer, and you didn't > elaborate, so I'll assume we're still talking about the topic named in > the subject line and the objection you raised several messages back: > > > Do you really want to say that the name exist but there is no data > > to every query you are not authoritative for? If you can't answer > > the query you do not give back bogus answers. > > With AA=0 the name server isn't saying "the name QNAME is valid but no > such RRset exists", it's saying "I don't have any such RRset cached, I > am not entitled to an opinion as to whether such an RRset or such a > QNAME exists because I'm not authoritative, I have no suggestions on > where you should look next, and everything's fine, have a nice day." > > With AA=1, this would be your RFC 2308 "TYPE 3 NODATA", but with AA=0 > it's just "not my department". Singularly unhelpful, but not bogus. NODATA is independent of AA. It's the lack of referral and soa that makes the response a NODATA. If we had a NODATA rcode then you could interpret the response the way you want to. > As I said, at least one of us is confused. Please feel free to > demonstrate that it's 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: -- 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 Apr 5 02:57:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29789 for ; Fri, 5 Apr 2002 02:57:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tOUg-000KKp-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 23:50:46 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16tOUf-000KKi-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 23:50:45 -0800 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g357oeW23544; Fri, 5 Apr 2002 09:50:40 +0200 Date: Fri, 5 Apr 2002 09:50:42 +0200 From: "Olaf M. Kolkman" To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call Message-Id: <20020405095042.03c4f2c4.olaf@ripe.net> In-Reply-To: <20020402122333.A301-100000@node10c4d.a2000.nl> References: <535230000.1017742381@askvoll.hjemme.alvestrand.no> <20020402122333.A301-100000@node10c4d.a2000.nl> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Yes, either ALL RRsets at a particular name are signed, or NO RRsets at > a particular name are signed. > I am a still a little confused. It occurs to me that the concept of experimentally secured zones stops to exist with OPT-IN. From the client view there is no such thing as a (experimentally) secure zone with OPT-IN. I have not yet assessed if that is a 'Bad thing (TM)'. The draft does not describe that this obsoletes (parts of) RFC3090. While thinking about this I came up with the following questions. Is one allowed to have SIGs with names that are part of the zone that is marked as unsecure by OPT-IN? If so, does the presence of a SIG require the presence of a NXT record with the same name? e.g. in the example below 'lambda' is opted-out but it does have a signature; Should/must/may lambda also have a NXT record? If it Should/must/may have a NXT record we are in for more questions; how does the nameserver know which NXT to return? Is there a problem if thw wrong one is returned? (Possibly not.) If you allow SIGs without NXTs will that lead to problems? I do not think so, but I might be wrong. The use for having SIGs on names that are marked as insecure by NXT-OPT would be similar to having experimentally signed zones. A resolver with the locally configured key would still be able to check the records while a resolver that follows a chain of trust will consider the names insecure. $ORIGIN greek @ SOA SIG(SOA) greek. 1 KEY 1 SIG(KEY) greek. 1 NXT alpha SIG(NXT) greek. 1 alpha A 10.0.0.1 SIG(A) greek. 1 NXT-OPT omega.greek. (opt in style) SIG (NXT) greek. 1 lambda A 10.0.0.4 SIG(A) greek. 1 omega A 10.0.0.5 SIG(A) greek. 1 NXT greek. --Olaf PS. While going over RFC3090 again I couldn't help but smile: The goal of DNSSEC is to have each zone secured, from the root zone and the top-level domains down the hierarchy to the leaf 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 Fri Apr 5 02:58:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29803 for ; Fri, 5 Apr 2002 02:58:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tOHU-000Joh-00 for namedroppers-data@psg.com; Thu, 04 Apr 2002 23:37:08 -0800 Received: from citadel.cequrux.com ([192.96.22.18]) by psg.com with esmtp (Exim 3.35 #1) id 16tOHS-000JoY-00 for namedroppers@ops.ietf.org; Thu, 04 Apr 2002 23:37:06 -0800 Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id JAA08325 for ; Fri, 5 Apr 2002 09:37:01 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 8323; Fri Apr 5 09:36:15 2002 Date: Fri, 5 Apr 2002 09:36:14 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: name server without root cache Message-ID: <20020405073614.GA15231@apb.cequrux.com> References: <20020405042506.B6E031C11@thrintun.hactrn.net> <200204050447.g354lRx73508@drugs.dv.isc.org> <20020405061039.C44101CA1@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020405061039.C44101CA1@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think that when a server wants to say "I have no idea what the answer is, and I refuse to even give you a referral to the root", it should use RCODE=REFUSED. However, if existing resolvers behave sanely upon receiving then blessing it as a way to say "I have no idea" might be reasonable; perhaps even for the RA=1 case, where the server could have given a referral to the roots, but might want to reduce the packet size. More comments below. On Fri, 05 Apr 2002, Rob Austein wrote: [JEEVES answered like this when it meant "I have no idea":] > >> QR=1 RCODE=0 AA=0 ANCOUNT=0 NSCOUNT=0 ADCOUNT=0 > > > > Sure RFC 1035 permits it. However if your a authoritative only > > server and the query is above all of the zone you are serving then > > you are returning a bogus answer. > > I don't see in what way this is a bogus answer, and you didn't > elaborate, so I'll assume we're still talking about the topic named in > the subject line and the objection you raised several messages back: RCODE=NOERROR combined with ANCOUNT=0 means "The name exists but doesn't have any RRs of the type you asked about". It's a bogus answer because the server has no basis for asserting that the name exists. > With AA=0 the name server isn't saying "the name QNAME is valid but no > such RRset exists", it's saying "I don't have any such RRset cached, > I am not entitled to an opinion as to whether such an RRset or such a > QNAME exists because I'm not authoritative, I have no suggestions on > where you should look next, and everything's fine, have a nice day." No, with AA=0, it's saying, "I don't have any such RRset cached, I am not authoritative for this name, but I nevertheless believe that the QNAME exists (probably because I have other cached RRsets for the same QNAME)". Such a response without any NS records in the authority section might be confusing to existing resolvers. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 5 03:42:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00193 for ; Fri, 5 Apr 2002 03:42:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tP7N-000LwS-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 00:30:45 -0800 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.35 #1) id 16tP7M-000Lw8-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 00:30:45 -0800 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g358UhX26550 for namedroppers@ops.ietf.org; Fri, 5 Apr 2002 10:30:43 +0200 (CEST) (envelope-from alexis) Message-Id: <200204050830.g358UhX26550@open.nlnetlabs.nl> Subject: Re: name server without root cache In-Reply-To: <20020405042506.B6E031C11@thrintun.hactrn.net> "from Rob Austein at Apr 4, 2002 11:25:06 pm" To: namedroppers@ops.ietf.org Date: Fri, 5 Apr 2002 10:30:42 +0200 (CEST) From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once Rob Austein wrote: >At Fri, 05 Apr 2002 12:43:17 +1000, Mark Andrews wrote: >> >> rcode=noerror, nscount=0 is not a valid answer > >I'm pretty sure that RFC 1035 permits > > QR=1 RCODE=0 AA=0 ANCOUNT=0 NSCOUNT=0 ADCOUNT=0 In fact this answer means (according to the RFC's) something else: the name exists but there's no requested RR found. It is advisable to include the SOA as well, but I believe it is still not required. Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 5 03:49:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00239 for ; Fri, 5 Apr 2002 03:49:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tPFf-000MDP-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 00:39:19 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] helo=outpost.powerdns.com) by psg.com with esmtp (Exim 3.35 #1) id 16tPFe-000MDJ-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 00:39:18 -0800 Received: by outpost.powerdns.com (Postfix, from userid 1000) id 3C084C6104; Fri, 5 Apr 2002 10:39:16 +0200 (CEST) Date: Fri, 5 Apr 2002 10:39:16 +0200 From: bert hubert To: Alan Barrett Cc: namedroppers@ops.ietf.org Subject: Re: name server without root cache Message-ID: <20020405103916.B12823@outpost.ds9a.nl> References: <20020405042506.B6E031C11@thrintun.hactrn.net> <200204050447.g354lRx73508@drugs.dv.isc.org> <20020405061039.C44101CA1@thrintun.hactrn.net> <20020405073614.GA15231@apb.cequrux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020405073614.GA15231@apb.cequrux.com>; from apb@cequrux.com on Fri, Apr 05, 2002 at 09:36:14AM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Apr 05, 2002 at 09:36:14AM +0200, Alan Barrett wrote: > I think that when a server wants to say "I have no idea what the > answer is, and I refuse to even give you a referral to the root", it > should use RCODE=REFUSED. > > However, if existing resolvers behave sanely upon receiving > > then blessing it as a way to say "I have no idea" might be > reasonable; perhaps even for the RA=1 case, where the server could > have given a referral to the roots, but might want to reduce the > packet size. Before rushing off to what everybody 'thinks', please be so kind as to determine how recursors react to your thoughts. They are not going to change anytime soon [1]. You do not want to see hammering retransmits but you also don't want a nameserver to declare you 'dead' or 'broken' and not sending other queries to you! The data we have indicate that the world is happy with: We've just switched TK. over to: And that also appears to go down well. I'm not going to try 'REFUSED' though. > > I don't see in what way this is a bogus answer, and you didn't > > elaborate, so I'll assume we're still talking about the topic named in > > the subject line and the objection you raised several messages back: > > RCODE=NOERROR combined with ANCOUNT=0 means "The name exists but doesn't > have any RRs of the type you asked about". It's a bogus answer because > the server has no basis for asserting that the name exists. With AA=1 this is correct. > No, with AA=0, it's saying, "I don't have any such RRset cached, I > am not authoritative for this name, but I nevertheless believe that > the QNAME exists (probably because I have other cached RRsets for the > same QNAME)". Such a response without any NS records in the authority > section might be confusing to existing resolvers. This is getting highly philosophical for what is a *technical* issue. It is in fact not confusing existing resolvers, but I feel with Paul that SERVFAIL is the right answer. Perhaps this should be modulated by the RD flag. Sending back pointers to rootservers for an RD=1 packet is, to say the least, misguided, but might be right for RD=0. But even then I think it complicates matters. Regards. bert [1] Interestingly on a busy authoritative server, we only see ~3000 different remote IP addresses over a time of 15 minutes. Will now measure over 12 hours to see how many there are. I would hate to see that the ISP world has consolidated so much that there are only a few thousand important resolvers left! -- 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 Fri Apr 5 04:04:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00367 for ; Fri, 5 Apr 2002 04:04:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tPUe-000Mou-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 00:54:48 -0800 Received: from randy.ru.ac.za ([146.231.128.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16tPUd-000Mon-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 00:54:47 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16tPUb-00018Q-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 10:54:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Date: Thu, 4 Apr 2002 18:45:29 +0200 (CEST) From: Erik Nordmark Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard To: Randy Hall Cc: Bill Manning , Danny Mayer , iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber ] > There were (IMO) bugs in the TKEY, TSIG, and other protocols > that needed fixing, and some changes (IMO) were needed (and > made) to the protocol, but there were no IP issues relating > these issues. Randy, Where these bugs in the RFCs or bugs in an implementation of those RFCs? Just checking, 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 Fri Apr 5 04:31:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00683 for ; Fri, 5 Apr 2002 04:31:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tPux-000Nh0-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 01:21:59 -0800 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.35 #1) id 16tPuw-000Ngk-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 01:21:58 -0800 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g359Lk926822; Fri, 5 Apr 2002 11:21:46 +0200 (CEST) (envelope-from alexis) Message-Id: <200204050921.g359Lk926822@open.nlnetlabs.nl> Subject: Re: name server without root cache In-Reply-To: <20020405073614.GA15231@apb.cequrux.com> "from Alan Barrett at Apr 5, 2002 09:36:14 am" To: Alan Barrett Date: Fri, 5 Apr 2002 11:21:46 +0200 (CEST) CC: namedroppers@ops.ietf.org From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once Alan Barrett wrote: >I think that when a server wants to say "I have no idea what the >answer is, and I refuse to even give you a referral to the root", it >should use RCODE=REFUSED. > >However, if existing resolvers behave sanely upon receiving > >then blessing it as a way to say "I have no idea" might be >reasonable; perhaps even for the RA=1 case, where the server could >have given a referral to the roots, but might want to reduce the >packet size. I agree with the above and the rest of Alan's comments. Now it seems that nobody really knows how the resolvers would react yet we need to have a clear answer on what authorative only (non-recursive) nameserver should (must) do when it doesnt know anything about the query it has received. Current RFC's are not much of a help since apparently nobody thought back then that there will be name servers who wont do any recursion. Ok, since we dont recurse, we cannot give referrals to the root servers, which definitely would be the right thing to do for a recursive server (and giving servfail if the priming query failed or hints were not available). We cannot do that because such referral would need to be updated every TTL time, in bandwith, with the TTLs clicking down and the nameserver fetching and caching it every time its time to do so. That would mean we'd need to implement caching/recursion and we dont do it by definition. So: no hints, no root referral, no SERVFAIL (I'll give more arguments to no SERVFAIL below). What we want to do is to answer the query with ``I cannot help you on this, I dont have any suggestions either, and this is not a temporary failure''. Now lets see. Technically it is a NOTIMPL since we dont have recursion implemented, but giving a NOTIMPL to a perferctly normal and otherwise most likely very basic query is probably least thing a resolver software engineer expects. This error code will probably fall under ``all other funny error codes'' so I wouldnt expect a consise resolver behaviour after that. It might go away maybe not. So my opinion is that NOTIMPL is a bad idea. If we give SERVFAIL, next to the arguement above, the resolver will be encouraged to come back later thinking somebody might have fixed the nameserver. So no SERVFAIL. Dropping the query on the floor wont help much, we'll only get endless retransmitions. Bad idea. Giving an empty answer with AA bit either on or off according to my understanding of the RFC's is plainly wrong. Even if it is my misinterpritation the chance is rather big that somebody else misinterpreted it in the same way or wasnt very carefull crosschecking the AA bit and we'll give ``name is there, but now particular RR'' and that will break things down. If you're with me this far, I hope we agree that we need to answer such a query and we have to give a error code back. Lets see what error codes we have left. This is definitely not a Format Error. So we have Name Error and Refused. Giving a Name Error with AA=0 is in fact equal (as bad) as giving an empty answer with AA=0. In both cases we're saying that we dont have this information and since we're not authorative for it, but I'm afraid that both will equally lead the resolvers to believe that the name either exists or doesnt exist. So I advocate not to give a Name Error in combination with AA=0 :) So unless we want to really quickly invent a new standard the only error code we have left this far is Refused. To refresh everybody's mind: 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data. We Refuse to do recursion (``a particular operation''). Whether it is a ``policy reason'' is argueable. After all separating authorative only server and caching forwarder in two independant servers is a sort of a policy. If we had a RD=1 in the query, we can RA=0 to make the answer more meaningfull. Or we can even voluntarily set RD=1, RA=0 to indicate the reason, but I guess it is not all that necessary, the result remains the same, you're not getting an aswer from me on this, go away, who cares why? I agree it is not all that pretty (more things with DNS are lately not) but that'll work and I think Refused is the only right way to do it. Thanks to everybody who managed to read it all :) Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 5 04:39:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00744 for ; Fri, 5 Apr 2002 04:39:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tQ4d-000O4b-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 01:31:59 -0800 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.35 #1) id 16tQ4c-000O4V-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 01:31:58 -0800 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g359VnB26847; Fri, 5 Apr 2002 11:31:49 +0200 (CEST) (envelope-from alexis) Message-Id: <200204050931.g359VnB26847@open.nlnetlabs.nl> Subject: Re: name server without root cache In-Reply-To: <20020405103916.B12823@outpost.ds9a.nl> "from bert hubert at Apr 5, 2002 10:39:16 am" To: bert hubert Date: Fri, 5 Apr 2002 11:31:49 +0200 (CEST) CC: Alan Barrett , namedroppers@ops.ietf.org From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once bert hubert wrote: >Before rushing off to what everybody 'thinks', please be so kind as to >determine how recursors react to your thoughts. They are not going to change >anytime soon [1]. > >You do not want to see hammering retransmits but you also don't want a >nameserver to declare you 'dead' or 'broken' and not sending other queries >to you! I agree, however a recursor should not have come to you with the stupid query in first place. If the recursor got referred to you by your parent (as it should be) it will ask you a questing you'd have an answer to. If the recursor asked something silly first and got REFUSED, even though you might get tagged as ``broken'' (why actually broken? rather unfriendly) my best guess is that it will come talk to you again if it got referred to you directly. And if not, well somebody else will do it for him. (Hmm, is recursor really a him or a her, or could it be both? :) >The data we have indicate that the world is happy with: > > >We've just switched TK. over to: > > >And that also appears to go down well. I'm not going to try 'REFUSED' >though. You might want to though (see my previous mail). It would give everybody here a very valuable otherwise unattainable input! Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 5 04:48:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00869 for ; Fri, 5 Apr 2002 04:48:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tQCY-000OM3-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 01:40:10 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] helo=outpost.powerdns.com) by psg.com with esmtp (Exim 3.35 #1) id 16tQCX-000OLv-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 01:40:09 -0800 Received: by outpost.powerdns.com (Postfix, from userid 1000) id 5F941C6104; Fri, 5 Apr 2002 11:40:08 +0200 (CEST) Date: Fri, 5 Apr 2002 11:40:08 +0200 From: bert hubert To: Alexis Yushin Cc: Alan Barrett , namedroppers@ops.ietf.org Subject: Re: name server without root cache Message-ID: <20020405114008.A15106@outpost.ds9a.nl> References: <20020405103916.B12823@outpost.ds9a.nl> <200204050931.g359VnB26847@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200204050931.g359VnB26847@open.nlnetlabs.nl>; from alexis@NLnetLabs.nl on Fri, Apr 05, 2002 at 11:31:49AM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Apr 05, 2002 at 11:31:49AM +0200, Alexis Yushin wrote: > >You do not want to see hammering retransmits but you also don't want a > >nameserver to declare you 'dead' or 'broken' and not sending other queries > >to you! > > I agree, however a recursor should not have come to you with the stupid > query in first place. If the recursor got referred to you by your parent > (as it should be) it will ask you a questing you'd have an answer to. We mostly send out these packets for domains that have been delegated to us but not yet entered in the database. So those queries aren't stupid. > >And that also appears to go down well. I'm not going to try 'REFUSED' > >though. > > You might want to though (see my previous mail). It would give everybody > here a very valuable otherwise unattainable input! I'll see what happens but not on the TK. rootservers. 'Refused' might be interpreted as 'I'm not talking to your IP address'. So who knows what might happen. The world is screaming for RCODE=NotAuth. I'll also try to measure how many of our resolving clients proclaim EDNS0 compliance. Regards, bert -- 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 Fri Apr 5 04:56:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00964 for ; Fri, 5 Apr 2002 04:56:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tQGD-000OUl-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 01:43:57 -0800 Received: from randy.ru.ac.za ([146.231.128.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16tQGC-000OUc-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 01:43:57 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16tQGA-0001DS-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 11:43:54 +0200 In-Reply-To: <20020403210751.4FDEC28DC4@as.vix.com> References: <20020403210751.4FDEC28DC4@as.vix.com> Message-Id: <1017944613.29728.15.camel@error-messages.mit.edu> Mime-Version: 1.0 Subject: Re: A6/DNAME usage guidelines and limits From: Greg Hudson To: Paul Vixie Cc: namedroppers@ops.ietf.org Date: 04 Apr 2002 13:23:33 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber ] On Wed, 2002-04-03 at 16:07, Paul Vixie wrote: > the question is, before we go into detail on it, is: have we really and > truly put so much mass into the DNS protocol that most applications (and > most stub resolvers) cannot reasonably be expected to speak it? It seems to me that we reached that point a long time ago. In particular, Unix stub resolvers won't follow CNAME chains by doing multiple queries; they rely on the recursive resolver to go out and fetch the CNAME chain and the terminating canonical record. If there were no installed base, and having A6 were an external constraint, I would say that we should make recursive resolvers go out and fetch A6 records to make a complete chain, so that stub resolvers can still make only one query. Since there is an installed base of stub resolvers which do AAAA queries, it seems we would have to require the less elegant approach of AAAA synthesis. But it's the functionally the same. (I'm not very fond of A6, but I've made all those arguments in the past.) -- 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 Apr 5 05:01:36 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01055 for ; Fri, 5 Apr 2002 05:01:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tQL8-000OhU-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 01:49:02 -0800 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.35 #1) id 16tQL6-000OhO-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 01:49:01 -0800 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g359mpF26955; Fri, 5 Apr 2002 11:48:51 +0200 (CEST) (envelope-from alexis) Message-Id: <200204050948.g359mpF26955@open.nlnetlabs.nl> Subject: Re: name server without root cache In-Reply-To: <20020405114008.A15106@outpost.ds9a.nl> "from bert hubert at Apr 5, 2002 11:40:08 am" To: bert hubert Date: Fri, 5 Apr 2002 11:48:51 +0200 (CEST) CC: Alexis Yushin , Alan Barrett , namedroppers@ops.ietf.org From: Alexis Yushin Reply-To: alexis@NLnetLabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once bert hubert wrote: >> I agree, however a recursor should not have come to you with the stupid >> query in first place. If the recursor got referred to you by your parent >> (as it should be) it will ask you a questing you'd have an answer to. > >We mostly send out these packets for domains that have been delegated to us >but not yet entered in the database. So those queries aren't stupid. Ooooh, that's not the right way to things mister! The first thing I learned about getting a domain name, was: set up the primary and secondary first, then request delegation. Lateron, being delegator myself, the rule was, check the primary & secondary first (mostly done by an automatic script that process delegation requests) then delegate. >> >And that also appears to go down well. I'm not going to try 'REFUSED' >> >though. >> >> You might want to though (see my previous mail). It would give everybody >> here a very valuable otherwise unattainable input! > >I'll see what happens but not on the TK. rootservers. 'Refused' might be >interpreted as 'I'm not talking to your IP address'. So who knows what might >happen. Well I am getting more and more convinced that Refused is the way to go. It doesnt mean the IP is bad, it only means you dont want to do certain operation for certain reasons. Think of REFUSED to AXFR, it has nothing to do with IP. But I'm afraid I dont really have any new arguements, I'm repeating myself. Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 5 05:14:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01197 for ; Fri, 5 Apr 2002 05:14:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tQaf-000PIS-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 02:05:05 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] helo=outpost.powerdns.com) by psg.com with esmtp (Exim 3.35 #1) id 16tQae-000PIM-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 02:05:04 -0800 Received: by outpost.powerdns.com (Postfix, from userid 1000) id 6DA29C6104; Fri, 5 Apr 2002 12:05:03 +0200 (CEST) Date: Fri, 5 Apr 2002 12:05:03 +0200 From: bert hubert To: Alexis Yushin Cc: Alan Barrett , namedroppers@ops.ietf.org Subject: Re: name server without root cache Message-ID: <20020405120503.A15276@outpost.ds9a.nl> References: <20020405114008.A15106@outpost.ds9a.nl> <200204050948.g359mpF26955@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200204050948.g359mpF26955@open.nlnetlabs.nl>; from alexis@NLnetLabs.nl on Fri, Apr 05, 2002 at 11:48:51AM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Apr 05, 2002 at 11:48:51AM +0200, Alexis Yushin wrote: > >We mostly send out these packets for domains that have been delegated to us > >but not yet entered in the database. So those queries aren't stupid. > > Ooooh, that's not the right way to things mister! The first thing I learned > about getting a domain name, was: set up the primary and secondary first, > then request delegation. Lateron, being delegator myself, the rule was, > check the primary & secondary first (mostly done by an automatic script > that process delegation requests) then delegate. Tell that to Verisign :-) We have no control over what people delegate to us. See http://express.powerdns.com - it is a low cost dns hosting solution. > Well I am getting more and more convinced that Refused is the way to go. It > doesnt mean the IP is bad, it only means you dont want to do certain operation > for certain reasons. Think of REFUSED to AXFR, it has nothing to do with IP. > > But I'm afraid I dont really have any new arguements, I'm repeating myself. I really don't care for the philosophical arguments. We want to send out an answer that indicates 'go ask somewhere else'. SERVFAIL does this nicely. New PDNS behaviour: $ host pietjepuk.nl ns-c.taloha.tk pietjepuk.nl A record not found at ns-c.taloha.tk, server failure Old: $ host pietjepuk.nl dns-eu1.powerdns.net pietjepuk.nl A record currently not present at dns-eu1.powerdns.net With root referral: $ host pietjepuk.nl a.gtld-servers.net pietjepuk.nl A record currently not present at a.gtld-servers.net DJBDNS 'I'm not answering you': $ host pietjepuk.nl a.ns.yp.to Nameserver a.ns.yp.to not responding pietjepuk.nl A record not found at a.ns.yp.to, try again UltraDNS 'Version 2.4.2 Build 131' also gives out a root referral. I don't know of anybody running the microsoft nameserver. DJBDNS is really acting silly in this respect - not answering to queries *at all* means hammering. If I were to delegate a big domain to a.ns.yp.to he would see huge amounts of traffic coming his way. We've seen 500 packets/second for a nameserver normally receiving 10 packets/second in this case. See also: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-bad-dns-res-00.txt 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 Fri Apr 5 05:47:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01430 for ; Fri, 5 Apr 2002 05:47:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tR4V-0000RB-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 02:35:55 -0800 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.35 #1) id 16tR4U-0000R5-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 02:35:54 -0800 Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.6/8.11.6) id g35AZka27151; Fri, 5 Apr 2002 12:35:46 +0200 (CEST) (envelope-from alexis) Message-Id: <200204051035.g35AZka27151@open.nlnetlabs.nl> Subject: Re: name server without root cache In-Reply-To: <20020405120503.A15276@outpost.ds9a.nl> "from bert hubert at Apr 5, 2002 12:05:03 pm" To: bert hubert Date: Fri, 5 Apr 2002 12:35:46 +0200 (CEST) CC: Alexis Yushin , Alan Barrett , namedroppers@ops.ietf.org From: Alexis Yushin Reply-To: alexis@nlnetlabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once bert hubert wrote: >I really don't care for the philosophical arguments. We want to send out an >answer that indicates 'go ask somewhere else'. SERVFAIL does this nicely. We're not talking philosophical arguement, we're talking adhering to the standards. If you forgot why we do it, it is because we have no control or say about existing or future resolver implementations, and the standards are the guidlines and guarantee that if adhered to, there will be interoperability. The standards, not a New PDNS or BIND behaviour, that coninsidently happen to do the trick. > >New PDNS behaviour: > >$ host pietjepuk.nl ns-c.taloha.tk >pietjepuk.nl A record not found at ns-c.taloha.tk, server failure > >Old: > >$ host pietjepuk.nl dns-eu1.powerdns.net >pietjepuk.nl A record currently not present at dns-eu1.powerdns.net > >With root referral: > >$ host pietjepuk.nl a.gtld-servers.net >pietjepuk.nl A record currently not present at a.gtld-servers.net The only thing the above illustrates is how certain implementation of host(1) verbalizes different name server answers. Alexis -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 5 07:32:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02855 for ; Fri, 5 Apr 2002 07:32:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tSfR-0003i4-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 04:18:09 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] helo=outpost.powerdns.com) by psg.com with esmtp (Exim 3.35 #1) id 16tSfQ-0003hy-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 04:18:08 -0800 Received: by outpost.powerdns.com (Postfix, from userid 1000) id 55725C6494; Fri, 5 Apr 2002 14:18:07 +0200 (CEST) Date: Fri, 5 Apr 2002 14:18:07 +0200 From: bert hubert To: Alexis Yushin Cc: Alan Barrett , namedroppers@ops.ietf.org Subject: Re: name server without root cache Message-ID: <20020405141807.A17418@outpost.ds9a.nl> References: <20020405120503.A15276@outpost.ds9a.nl> <200204051035.g35AZka27151@open.nlnetlabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200204051035.g35AZka27151@open.nlnetlabs.nl>; from alexis@NLnetLabs.nl on Fri, Apr 05, 2002 at 12:35:46PM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Apr 05, 2002 at 12:35:46PM +0200, Alexis Yushin wrote: > >I really don't care for the philosophical arguments. We want to send out an > >answer that indicates 'go ask somewhere else'. SERVFAIL does this nicely. > > We're not talking philosophical arguement, we're talking adhering to the > standards. If you forgot why we do it, it is because we have no control or > say about existing or future resolver implementations, and the standards > are the guidlines and guarantee that if adhered to, there will be > interoperability. RFC 1034/1035 are not a viable guideline. Actual practice diverges on many places. Cf the SOA 'ttl_minimum' field. Or the AXFR protocol, which is not even defined in 1034 & 1035! (see http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-04.txt) The DNS rfcs simply are not as precise as, for example, the TCP/IP rfcs. So we argue over parts the RFCs gloss over, like what to do when not sending out the optional root referral. This arguing should partly be 'in the spirit' of the existing RFCs but as there is an important real world installed userbase we should take care not to lose compatibility with it due to the divine inspiration we get from reading Mockapetris et al. Oh, fwiw, the microsoft nameserver implementation agrees with Paul and sends out a SERVFAIL when not authoritative and not giving out a root referral. Regards, bert -- 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 Fri Apr 5 07:44:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03044 for ; Fri, 5 Apr 2002 07:44:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tSvp-0004I4-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 04:35:05 -0800 Received: from randy.ru.ac.za ([146.231.128.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.35 #1) id 16tSvo-0004Hq-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 04:35:04 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16tSvi-0001s8-00; Fri, 05 Apr 2002 14:34:58 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call References: <535230000.1017742381@askvoll.hjemme.alvestrand.no> <20020402122333.A301-100000@node10c4d.a2000.nl> <20020405095042.03c4f2c4.olaf@ripe.net> Message-Id: Date: Fri, 05 Apr 2002 14:34:58 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It occurs to me that the concept of experimentally secured zones > stops to exist with OPT-IN. with opt-in, the concept of "secured zones" would no longer exist, period. zones could have a (possibly improper) subset (possibly) secured. 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 Fri Apr 5 08:14:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03711 for ; Fri, 5 Apr 2002 08:14:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tTKX-0005Bb-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 05:00:37 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16tTKX-0005BV-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 05:00:37 -0800 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 6FFF83190C; Fri, 5 Apr 2002 05:00:35 -0800 (PST) Date: Fri, 5 Apr 2002 15:09:53 +0200 (CEST) From: Roy Arends X-X-Sender: To: "Olaf M. Kolkman" Cc: Roy Arends , Subject: Re: Opt-in wg last call In-Reply-To: <20020405095042.03c4f2c4.olaf@ripe.net> Message-ID: <20020405120303.J4152-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 5 Apr 2002, Olaf M. Kolkman wrote: > > > > > Yes, either ALL RRsets at a particular name are signed, or NO RRsets at > > a particular name are signed. > > > > > I am a still a little confused. > > It occurs to me that the concept of experimentally secured zones stops > to exist with OPT-IN. From the client view there is no such thing as a > (experimentally) secure zone with OPT-IN. I have not yet assessed if > that is a 'Bad thing (TM)'. > > The draft does not describe that this obsoletes (parts of) RFC3090. Experimentally secured status is deprecated, i.e. there is 'No Such Thing (TM)' > While thinking about this I came up with the following questions. > > Is one allowed to have SIGs with names that are part of the zone that > is marked as unsecure by OPT-IN? If so, does the presence of a SIG > require the presence of a NXT record with the same name? e.g. in the > example below 'lambda' is opted-out but it does have a signature; > Should/must/may lambda also have a NXT record? Yes, it must have an associated NXT record. > If it Should/must/may have a NXT record we are in for more questions; > how does the nameserver know which NXT to return? Is there a problem > if thw wrong one is returned? (Possibly not.) Wrong one ? There is only one ! > If you allow SIGs without NXTs will that lead to problems? I do not > think so, but I might be wrong. Yes it would lead to problems. A secure resolver wants a conclusive signed statement. If it does not exist, it expects a signed NXT. A NXDOMAIN with no NXT info is simply marked as BAD. > The use for having SIGs on names that are marked as insecure by > NXT-OPT would be similar to having experimentally signed zones. A > resolver with the locally configured key would still be able to check > the records while a resolver that follows a chain of trust will > consider the names insecure. experimentally secured is a case of "locally secured" $ORIGIN greek @ SOA SIG(SOA) greek. 1 KEY 1 SIG(KEY) greek. 1 NXT alpha SIG(NXT) greek. 1 alpha A 10.0.0.1 SIG(A) greek. 1 NXT-OPT omega.greek. (opt in style) SIG (NXT) greek. 1 lambda A 10.0.0.4 SIG(A) greek. 1 This is wrong. It is required that the existence of a Signed A record and the SIG record is signalled in a NXT record. 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 Fri Apr 5 08:58:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04875 for ; Fri, 5 Apr 2002 08:58:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tU0p-0006iA-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 05:44:19 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16tU0o-0006i4-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 05:44:18 -0800 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 395253190C; Fri, 5 Apr 2002 05:44:18 -0800 (PST) To: bert hubert Cc: Alexis Yushin , Alan Barrett , namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: Message from bert hubert of "Fri, 05 Apr 2002 14:18:07 +0200." <20020405141807.A17418@outpost.ds9a.nl> Date: Fri, 05 Apr 2002 05:44:18 -0800 Message-ID: <46940.1018014258@shell.nominum.com> From: Jim Reid Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "bert" == bert hubert writes: bert> RFC 1034/1035 are not a viable guideline. Actual practice bert> diverges on many places. Cf the SOA 'ttl_minimum' field. Well for this particular example RFC2308 updates 1034/35, so I don't understand the point you're trying to make here. If you are saying that there are holes in 1034/35 that need plugged or further clarification is necessary, feel free to submit an appropriate draft. Until then 1034/35 and the RFCs which update it are the only viable guidelines we have. Now to get back to the original question, my feeling is it probably doesn't matter too much what sort of answer a non-recursive, authoritative only server returns when it's asked for something it's not authoritative for. As long as the server answers. After all the resolver originating the query is broken and deserves all it gets. However the server should give some sort of answer that prevents repeated queries and reduces latency. It would be good manners and common sense to give a referral: it's not as if this is expensive to do or code. Quibbling over the semantics for an error reply instead doesn't seem worth a discussion. Does it matter whether a SERVFAIL -- "I don't know what to tell you" -- or REFUSED -- "I don't want to tell you" -- is returned? For this scenario, both ultimately mean pretty much the same thing: you shouldn't have asked 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 Fri Apr 5 09:07:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05200 for ; Fri, 5 Apr 2002 09:07:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tUGK-0007H0-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 06:00:20 -0800 Received: from 96-1.nat.psu.ac.th ([202.28.96.1] helo=brandenburg.cs.mu.OZ.AU) by psg.com with esmtp (Exim 3.35 #1) id 16tUGJ-0007Gs-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 06:00:19 -0800 Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g35E1s602093; Fri, 5 Apr 2002 21:01:54 +0700 (ICT) From: Robert Elz To: Derek Atkins cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits In-Reply-To: References: <20020404170539.6D8D028DC4@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Apr 2002 21:01:54 +0700 Message-ID: <2091.1018015314@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 04 Apr 2002 12:14:15 -0500 From: Derek Atkins Message-ID: | Right. The problem is that the client resolver has _half_ the data | and doesn't know when it will complete. The fact that it is half the data is irrelevant - if you allow yourself to view it other than that way, then you'll see it is no different than any other query. | With AAAA (or A) you get a | response that is either 'yes' or 'no', not 'here is half your answer | -- look here for more information'. Of course you do - to fetch an answer (except in the case that you already have the answer, and A6 is no different there), you have to go and send queries, usually several queries. To find NS records, to resolve CNAME records, ... All during that the answer is in the process of being accumulated. A6 is just the same - or if you like, just more of the same. During processing, records will be being fetched, eventually the last RR arrives, and you're done. Until then, you're just part way through getting the data. 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 Apr 5 09:45:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06085 for ; Fri, 5 Apr 2002 09:45:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tUqD-0008bl-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 06:37:25 -0800 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16tUqC-0008be-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 06:37:24 -0800 Received: by sentry.gw.tislabs.com; id JAA20597; Fri, 5 Apr 2002 09:43:06 -0500 (EST) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma020583; Fri, 5 Apr 02 09:42:44 -0500 X-Sender: lewis@pop.tislabs.com Message-Id: In-Reply-To: <3CAD25BB.80877E6B@ehsco.com> References: <3CAD0829.2E12A8B7@ehsco.com> <19621523797.20020404224005@allan.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Apr 2002 09:37:32 -0500 To: "Eric A. Hall" From: Edward Lewis Subject: Re: app-layer acks in DNS Cc: namedroppers Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Personally, I think this is off-topic for this mailing list. I don't mean that as a "squelch this discussion" comment, but rather that this subject is a huge paradigm shift away from DNS as we know it. It makes me even think back to X.500 and ldap - a division of labor in the name space service. This also makes me think over the middlebox comment made by Rob a few weeks ago when we were talking about how involved a name server should get when "editing" a zone (e.g. dropping expired signatures). I would hold the thoughts about app-layer acks for a time when we seriously think about a new name service. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 5 11:07:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08347 for ; Fri, 5 Apr 2002 11:07:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tW3T-000BeP-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 07:55:11 -0800 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.35 #1) id 16tW3S-000BeJ-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 07:55:10 -0800 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 40071; Fri, 05 Apr 2002 09:54:54 -0600 Message-ID: <3CADC8DA.F26A7D0A@ehsco.com> Date: Fri, 05 Apr 2002 09:55:06 -0600 From: "Eric A. Hall" X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Edward Lewis CC: namedroppers Subject: Re: app-layer acks in DNS References: <3CAD0829.2E12A8B7@ehsco.com> <19621523797.20020404224005@allan.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > I would hold the thoughts about app-layer acks for a time when we > seriously think about a new name service. Couple of things. First is that the UTF-8/ACE conversions only work when one of the query formats fail, so they use 2 round-trips to succeed. This is the latency equivalent of an extra delegation, so its not an infinite amount of time, but given multiple conversions, it can easily trigger a timeout on the client. From that perspective, some sort of "chasing" RCODE is going to be necessary sooner rather than later. Second is that we can define these RCODEs as EDNS values, which for all practical purposes makes them "new name service" messages as far as legacy systems are concerned. I suppose that I'm really just wondering if these messages should become mainstreamed for other uses. -- 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 Fri Apr 5 12:53:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11496 for ; Fri, 5 Apr 2002 12:53:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tXgr-000FdE-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 09:39:57 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16tXgq-000Fd6-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 09:39:56 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 652B31CA1 for ; Fri, 5 Apr 2002 12:39:55 -0500 (EST) Date: Fri, 05 Apr 2002 12:39:55 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: <200204050710.g357A7x74531@drugs.dv.isc.org> References: <20020405061039.C44101CA1@thrintun.hactrn.net> <200204050710.g357A7x74531@drugs.dv.isc.org> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020405173955.652B31CA1@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 05 Apr 2002 17:10:07 +1000, Mark Andrews wrote: > > NODATA is independent of AA. It's the lack of referral and soa > that makes the response a NODATA. My point is that RFC 1035 doesn't say that. You're reading semantics into that response form that simply aren't in RFC 1035. SOAs in the Authority section are optional in RFC 1035, and, the behavior of certain widely deployed software notwithstanding, there is nothing in RFC 1035 that requires a name server either to know where the root is or to supply a referal if it doesn't know. So I think you're telling me that RFC 2308 changes the semantics. If so, and if the WG agrees with that change, it should be made explicit. -- 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 Apr 5 13:17:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12016 for ; Fri, 5 Apr 2002 13:17:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tY9l-000Gpd-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 10:09:49 -0800 Received: from [198.200.138.211] (helo=quadntweb.quadritek.com) by psg.com with esmtp (Exim 3.35 #1) id 16tY9k-000GpI-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 10:09:49 -0800 Received: from quadritek.com ([198.200.138.158]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with ESMTP id com; Fri, 5 Apr 2002 13:05:56 -0500 Message-ID: <3CADE87F.1C3375BC@quadritek.com> Date: Fri, 05 Apr 2002 13:10:07 -0500 From: rhall@quadritek.com (Randy Hall) X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Bill Manning , Danny Mayer , iesg-secretary@ietf.org, rfc-editor@ISI.EDU, iab@ISI.EDU, namedroppers@ops.ietf.org Subject: Re: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > There were (IMO) bugs in the TKEY, TSIG, and other protocols > > that needed fixing, and some changes (IMO) were needed (and > > made) to the protocol, but there were no IP issues relating > > these issues. > Where these bugs in the RFCs or bugs in an implementation of > those RFCs? Implementation. Cheers 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 Fri Apr 5 17:58:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05359 for ; Fri, 5 Apr 2002 17:58:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tcQw-0001Rr-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 14:43:50 -0800 Received: from porter.east.isi.edu ([65.114.168.20] helo=east.east.isi.edu) by psg.com with esmtp (Exim 3.35 #1) id 16tcQw-0001Rd-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 14:43:50 -0800 Received: from isi.edu (dial170.east.isi.edu [65.114.169.170]) by east.east.isi.edu (8.11.3/8.11.3) with ESMTP id g35Mhgs24710; Fri, 5 Apr 2002 17:43:43 -0500 (EST) Message-ID: <3CAE294C.CDBD4237@isi.edu> Date: Fri, 05 Apr 2002 17:46:36 -0500 From: Daniel Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Roy Arends , namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call References: <535230000.1017742381@askvoll.hjemme.alvestrand.no> <20020402122333.A301-100000@node10c4d.a2000.nl> <20020405095042.03c4f2c4.olaf@ripe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Olaf M. Kolkman" wrote: > > > > > Yes, either ALL RRsets at a particular name are signed, or NO > > RRsets at a particular name are signed. > > > > I am a still a little confused. > I think part of the confusion is terminology. I agree with Randy that we need to drop the term "secure zone" with Opt-in. Thinking in terms of granularity, you can have: 1. Security is applied to the DNS and all records are signed nice idea but this is completely unrealistic 2. Security is applied to zones and all records in a zone are signed here it makes sense to talk about a secure vs. non-secure zone 3. Security is applied to names and all RRsets at the name are signed here it makes sense to talk about a signed name, but it doesn't really make sense to a talk about a secure zone. if I chose to sign only www.nge.isi.edu and ftp.nge.isi.edu, is nge.isi.edu a secure zone? I think the terminology just doesn't fit. 4. Security is applied to RRsets at name and all records in the RRset is covered by the signature this is possible, but no one is suggesting a level of granularity below names. 5. Security is applied to individual RRs. no one is suggesting this and no one should suggest 4 or 5 :) So trying to answer your questions in terms of this "#3 - name based granularity", I get the following answers: > It occurs to me that the concept of experimentally secured zones > stops to exist with OPT-IN. From the client view there is no such > thing as a (experimentally) secure zone with OPT-IN. I have not >yet assessed if that is a 'Bad thing (TM)'. > > The draft does not describe that this obsoletes (parts of) RFC3090. > Experimentally secure zone is gone. So is secure zone and unsecure zone. The granularity is secure names so implicitly anything "zone" is gone. > While thinking about this I came up with the following questions. > > Is one allowed to have SIGs with names that are part of the zone > that is marked as unsecure by OPT-IN? Yes, the granularity is names. You choose to sign or not sign any name. > If so, does the presence of a SIG require the presence of a NXT > record with the same name? Yes. Your level of granularity is names. If you have a secure name, you MUST have a NXT stating the next secure name. > If it Should/must/may have a NXT record we are in for more > questions; how does the nameserver know which NXT to return? Is > there a problem if thw wrong one is returned? (Possibly not.) > For each name, there is only one next secure name so there is only one NXT. (there is some existing confusion with upper and lower NXT at a delegation name but we already deal with that.) > If you allow SIGs without NXTs will that lead to problems? I do not > think so, but I might be wrong. > I think it would be a problem. If the granularity is names, a secure resolver needs to know what is the next secure name. > The use for having SIGs on names that are marked as insecure by > NXT-OPT would be similar to having experimentally signed zones. A > resolver with the locally configured key would still be able to > check the records while a resolver that follows a chain of trust > will consider the names insecure. > I never liked experimentally secure zones and experimentally secure names seem worse. In terms of the granularity, it makes sense that NXT tells you the next secure name. So if you want to sign a name, I think you MUST adjust your NXTs accordingly. Or put another way, is there a compelling reason to allow a SIG without a NXT? I don't see one... Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 5 21:53:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19637 for ; Fri, 5 Apr 2002 21:53:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tgB5-000AB0-00 for namedroppers-data@psg.com; Fri, 05 Apr 2002 18:43:43 -0800 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.35 #1) id 16tgB3-000AAu-00 for namedroppers@ops.ietf.org; Fri, 05 Apr 2002 18:43:41 -0800 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g362hSx79594; Sat, 6 Apr 2002 12:43:29 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200204060243.g362hSx79594@drugs.dv.isc.org> To: Rob Austein Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: name server without root cache In-reply-to: Your message of "Fri, 05 Apr 2002 12:39:55 EST." <20020405173955.652B31CA1@thrintun.hactrn.net> Date: Sat, 06 Apr 2002 12:43:28 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At Fri, 05 Apr 2002 17:10:07 +1000, Mark Andrews wrote: > > > > NODATA is independent of AA. It's the lack of referral and soa > > that makes the response a NODATA. > > My point is that RFC 1035 doesn't say that. You're reading semantics > into that response form that simply aren't in RFC 1035. Explain how a recursive server is supposed to reconstruct a nodata response at the end of a cname chain when the authoritative server doesn't return a SOA in the authority section. aa=0 rd=1 ra=1 qr=1 ancount=1+ nscount=0 rcode=0 and with SOA aa=0 rd=1 ra=1 qr=1 ancount=1+ nscount=1 rcode=0 > SOAs in the > Authority section are optional in RFC 1035, and, the behavior of > certain widely deployed software notwithstanding, there is nothing in > RFC 1035 that requires a name server either to know where the root is > or to supply a referal if it doesn't know. SOA are optional. But you can only tell the difference between a nodata response and a referral by looking at the authority section and interperting the contents there. If you don't know what the root servers are then you can't give a non-error answer. > So I think you're telling me that RFC 2308 changes the semantics. If > so, and if the WG agrees with that change, it should be made explicit. > > -- > 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 Sat Apr 6 14:46:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14656 for ; Sat, 6 Apr 2002 14:46:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16tvoX-000LTJ-00 for namedroppers-data@psg.com; Sat, 06 Apr 2002 11:25:29 -0800 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16tvoW-000LTD-00 for namedroppers@ops.ietf.org; Sat, 06 Apr 2002 11:25:29 -0800 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 61EA61C11 for ; Sat, 6 Apr 2002 14:25:22 -0500 (EST) Date: Sat, 06 Apr 2002 14:25:22 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: <200204060243.g362hSx79594@drugs.dv.isc.org> References: <20020405173955.652B31CA1@thrintun.hactrn.net> <200204060243.g362hSx79594@drugs.dv.isc.org> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020406192522.61EA61C11@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sat, 06 Apr 2002 12:43:28 +1000, Mark Andrews wrote: > > Explain how a recursive server is supposed to reconstruct a > nodata response at the end of a cname chain when the > authoritative server doesn't return a SOA in the authority > section. > > aa=0 rd=1 ra=1 qr=1 ancount=1+ nscount=0 rcode=0 > > and with SOA > > aa=0 rd=1 ra=1 qr=1 ancount=1+ nscount=1 rcode=0 Neither of which is the response form I was talking about, since ANCOUNT is nonzero. In the case you show here, one infers the absence of the desired RRset by the presence of the CNAME RRs (which, I assume, are what "ancount=1+" indicates) combined with RCODE=0, RA=1, RD=1, and the absence of any RRs matching QTYPE at the end of the chain. > SOA are optional. At least we agree on something today. :) > But you can only tell the difference between a nodata response > and a referral by looking at the authority section and > interperting the contents there. You might be able to convince me of that for responses with RD=1 and RA=1, although I'm still skeptical as to the practical value of such a distinction. Responses with RD=1 and RA=1 don't ordinarily contain referrals anyway, so why do you care? But I digress. I don't think your reasoning applies to responses with RA=0 or RD=0. For the nonrecursive cases, you can get back an answer, a referral, an error, or an empty RCODE=0 response indicating that you have asked a server that has nothing useful to tell you about the question you asked. You keep claiming that the last case is "bogus", or an "error", by which I assume you mean a protocol violation. I disagree. > If you don't know what the root servers are then you can't > give a non-error answer. Sorry, I still say that it's a legal response in the non-recursive 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 Sun Apr 7 03:42:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23020 for ; Sun, 7 Apr 2002 03:42:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16u6yt-000Nut-00 for namedroppers-data@psg.com; Sat, 06 Apr 2002 23:20:55 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.35 #1) id 16u6yr-000Num-00 for namedroppers@ops.ietf.org; Sat, 06 Apr 2002 23:20:54 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16u5Aa-00007o-00 for namedroppers@ops.ietf.org; Sun, 07 Apr 2002 07:24:52 +0200 Message-ID: <20020405195520.4362.qmail@cr.yp.to> References: <20020405114008.A15106@outpost.ds9a.nl> <200204050948.g359mpF26955@open.nlnetlabs.nl> <20020405120503.A15276@outpost.ds9a.nl> Mime-Version: 1.0 Date: 5 Apr 2002 19:55:20 -0000 From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: name server without root cache Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber ] bert hubert writes: > DJBDNS is really acting silly in this respect - not answering to > queries *at all* means hammering. Get a grip. The Internet could save more bandwidth by leaving out the P in each HTTP connection. > If I were to delegate a big domain to a.ns.yp.to he > would see huge amounts of traffic coming his way. Try to think about this rationally. If you delegate a domain to my servers without authorization, I could (1) return a root referral, which will reduce the traffic somewhat if all your other servers are lame, but which is more likely to have no effect, or (2) point the unauthorized domain to some offensive site and watch the traffic dwindle to nothing as you lose all your customers. Do you seriously expect me to do #1 instead of #2? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- 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 Apr 7 04:38:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23019 for ; Sun, 7 Apr 2002 03:42:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16u6y3-000NsN-00 for namedroppers-data@psg.com; Sat, 06 Apr 2002 23:20:03 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.35 #1) id 16u6y1-000Nrl-00 for namedroppers@ops.ietf.org; Sat, 06 Apr 2002 23:20:03 -0800 Received: from randy by roam.psg.com with local (Exim 4.00) id 16u5IG-00009V-00 for namedroppers@ops.ietf.org; Sun, 07 Apr 2002 07:32:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020405224737.20234.qmail@cr.yp.to> References: <20020402164751.E19210@connect.com.au> <20020403161247.C30198@onramp.southern-star-ranch.com> Date: 5 Apr 2002 22:47:37 -0000 From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: A6/DNAME usage guidelines and limits Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] Carl Perry writes: > A6 is a good idea, in general. No, it isn't. See http://cr.yp.to/djbdns/killa6.html. The problems with A6 are much bigger than the cost of an extra loop in (stub) clients. The fundamental problem is that A6's cross-server indirection is being performed in the foreground instead of in the background. We already have reliability problems from foreground cross-server indirection in NS and CNAME, even though NS and CNAME don't _encourage_ cross-server indirection the way that A6 does. For people who want separate signatures on chunks of an address: Fine. Put separate signatures on chunks of an address. This is compatible with background indirection. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- 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 Apr 7 04:46:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23567 for ; Sun, 7 Apr 2002 04:46:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16u8Ad-00011R-00 for namedroppers-data@psg.com; Sun, 07 Apr 2002 00:37:07 -0800 Received: from outpost.ds9a.nl ([213.244.168.210] helo=outpost.powerdns.com) by psg.com with esmtp (Exim 3.35 #1) id 16u8Ac-00011E-00 for namedroppers@ops.ietf.org; Sun, 07 Apr 2002 00:37:06 -0800 Received: by outpost.powerdns.com (Postfix, from userid 1000) id B85ADC60EC; Sun, 7 Apr 2002 10:37:03 +0200 (CEST) Date: Sun, 7 Apr 2002 10:37:03 +0200 From: bert hubert To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: name server without root cache Message-ID: <20020407103703.B26872@outpost.ds9a.nl> References: <20020405114008.A15106@outpost.ds9a.nl> <200204050948.g359mpF26955@open.nlnetlabs.nl> <20020405120503.A15276@outpost.ds9a.nl> <20020405195520.4362.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020405195520.4362.qmail@cr.yp.to>; from djb@cr.yp.to on Fri, Apr 05, 2002 at 07:55:20PM -0000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Apr 05, 2002 at 07:55:20PM -0000, D. J. Bernstein wrote: > [ post by non-subscriber ] > > bert hubert writes: > > DJBDNS is really acting silly in this respect - not answering to > > queries *at all* means hammering. > > Get a grip. The Internet could save more bandwidth by leaving out the P > in each HTTP connection. Hammering is never good. Even if it 'only' means saving 500 packets/second. > (1) return a root referral, which will reduce the traffic somewhat if > all your other servers are lame, but which is more likely to have > no effect, or You only have to return a SERVFAIL which will do the trick just fine. And contrary to your opinion, our experiments indicate that it does have effect. For our setups it saves a factor of *10* in traffic for a 5 minute 'no answers' silence on all nameservers. We haven't had the option to measure beyond that but I expect things to get worse. Are there any reasons *not* to send a SERVFAIL? In other words, is there a cost greater than getting hammered. > (2) point the unauthorized domain to some offensive site and watch > the traffic dwindle to nothing as you lose all your customers. > > Do you seriously expect me to do #1 instead of #2? Why not program defensively? It's not that hard. Things get misdelegated by mistake and it would be great if that could be handled gracefully where the operator of djbdns would not be punished for that mistake. But it's your nameserver. Dnscache really rocks. Regards, bert -- 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 Sun Apr 7 08:43:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25913 for ; Sun, 7 Apr 2002 08:43:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uBn2-0009Ms-00 for namedroppers-data@psg.com; Sun, 07 Apr 2002 05:29:00 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16uBn1-0009Mm-00 for namedroppers@ops.ietf.org; Sun, 07 Apr 2002 05:28:59 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 16C2C31919; Sun, 7 Apr 2002 05:28:59 -0700 (PDT) To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: Message from "D. J. Bernstein" of "05 Apr 2002 19:55:20 GMT." <20020405195520.4362.qmail@cr.yp.to> Date: Sun, 07 Apr 2002 05:28:59 -0700 Message-ID: <82470.1018182539@shell.nominum.com> From: Jim Reid Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "djb" == D J Bernstein writes: >> DJBDNS is really acting silly in this respect - not answering >> to queries *at all* means hammering. djb> Get a grip. The Internet could save more bandwidth by leaving djb> out the P in each HTTP connection. Perhaps. But think of the time people could save if they didn't have hang about waiting for their name servers to time out while expecting a from a response from your name server that isn't going to happen. And then there's the second order effect of RTT smoothing by other name servers. Since your server didn't respond, other servers will consider it to be "unavailable" and won't query it as often as they could. By saying nothing, your server is making a DoS attack against itself and the zones it serves. -- 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 Apr 7 17:46:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01142 for ; Sun, 7 Apr 2002 17:46:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uK8R-0006dy-00 for namedroppers-data@psg.com; Sun, 07 Apr 2002 14:23:39 -0700 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16uK8Q-0006ds-00 for namedroppers@ops.ietf.org; Sun, 07 Apr 2002 14:23:38 -0700 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g37LNDq40777; Sun, 7 Apr 2002 23:23:13 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Sun, 7 Apr 2002 23:23:13 +0200 (CEST) From: Mats Dufberg To: Alexis Yushin cc: Alan Barrett , Subject: Re: name server without root cache In-Reply-To: <200204050921.g359Lk926822@open.nlnetlabs.nl> Message-ID: <20020407231350.Y7955-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Apr 5, 2002, 11:21 (+0200) Alexis Yushin wrote: > Ok, since we dont recurse, we cannot give referrals to the root > servers, which definitely would be the right thing to do for a > recursive server (and giving servfail if the priming query failed > or hints were not available). We cannot do that because such referral > would need to be updated every TTL time, in bandwith, with the TTLs > clicking down and the nameserver fetching and caching it every time > its time to do so. That would mean we'd need to implement caching/recursion > and we dont do it by definition. I do not beleive that you save much load on the server by not keeping updated information on the root servers. > To refresh everybody's mind: > > 5 Refused - The name server refuses to > perform the specified operation for > policy reasons. For example, a name > server may not wish to provide the > information to the particular requester, > or a name server may not wish to perform > a particular operation (e.g., zone > transfer) for particular data. > > We Refuse to do recursion (``a particular operation''). Whether it is > a ``policy reason'' is argueable. After all separating authorative > only server and caching forwarder in two independant servers is a sort > of a policy. Technically it is maybe correct, but it makes Internet less transparent. For an administrator is of great importance to be able to deduce from the reply that the server has not been (or is no loger) configured with the zone in question. An non-recursive nameserver SHOULD reply with NOERROR, answer count=0 and the root NS in authority section. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- 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 Apr 7 21:17:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03096 for ; Sun, 7 Apr 2002 21:17:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uNYA-000H9T-00 for namedroppers-data@psg.com; Sun, 07 Apr 2002 18:02:26 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16uNY9-000H9N-00 for namedroppers@ops.ietf.org; Sun, 07 Apr 2002 18:02:25 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id A59E928DC4 for ; Sun, 7 Apr 2002 18:02:24 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: name server without root cache In-Reply-To: Message from Mats Dufberg of "Sun, 07 Apr 2002 23:23:13 +0200." <20020407231350.Y7955-100000@padda.telia.net> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Sun, 07 Apr 2002 18:02:24 -0700 Message-Id: <20020408010224.A59E928DC4@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I do not beleive that you save much load on the server by not keeping > updated information on the root servers. load, no. operational complexity, yes. > Technically it is maybe correct, but it makes Internet less transparent. if you're asking me a question you should not be asking, then you deserve an answer that will do you no good. > For an administrator is of great importance to be able to deduce from the > reply that the server has not been (or is no loger) configured with the > zone in question. that's an argument for REFUSED. however, REFUSED just encourages retries, so it actually hurts server load. > An non-recursive nameserver SHOULD reply with NOERROR, answer count=0 and > the root NS in authority section. that's a very reasonable interpretation of rfc 1034, and also follows the robustness principle. however, this also means there are more servers who have to know who the roots are, and therefore more opportunities for out- of-date or just-plain-wrong data to be stored and transmitted. most of the kashpureff-style delegation responses i've seen are actually from innocent authority-only servers with bad root.cache files. fundamentally though, asking a recursive question of a nonrecursive server is wrong, and the server should choose a response which is best for it, which in my case means discourages retries of the same query. if it's a nonrecursive query then it indicates lameness of a delegation, and the response ought to be servfail. -- 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 Apr 8 03:25:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16856 for ; Mon, 8 Apr 2002 03:25:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uTGa-00027h-00 for namedroppers-data@psg.com; Mon, 08 Apr 2002 00:08:40 -0700 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16uTGZ-00027b-00 for namedroppers@ops.ietf.org; Mon, 08 Apr 2002 00:08:39 -0700 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g3878YN41722; Mon, 8 Apr 2002 09:08:35 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Mon, 8 Apr 2002 09:08:34 +0200 (CEST) From: Mats Dufberg To: Paul Vixie cc: Subject: Re: name server without root cache In-Reply-To: <20020408010224.A59E928DC4@as.vix.com> Message-ID: <20020408085953.I29629-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Apr 7, 2002, 18:02 (-0700) Paul Vixie wrote: > > Technically it is maybe correct, but it makes Internet less transparent. > > if you're asking me a question you should not be asking, then you deserve > an answer that will do you no good. > > > For an administrator is of great importance to be able to deduce from the > > reply that the server has not been (or is no loger) configured with the > > zone in question. > > that's an argument for REFUSED. however, REFUSED just encourages retries, > so it actually hurts server load. The query could be non-recursive, but for a zone delegated to the server in error, or by miss-management the zone has not been added to the server. Or the server is a slave, and AXFR has fail or been refused. Or the server is a master, and has failed loading the zone (rejected), or it is a slave and the zone has expired. I could have all reasons to ask for the data, even though it is not there. And it would help the management to get a uniq answer for that situation. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- 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 Apr 8 09:51:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23660 for ; Mon, 8 Apr 2002 09:51:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uZGJ-000AeQ-00 for namedroppers-data@psg.com; Mon, 08 Apr 2002 06:32:47 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.35 #1) id 16uZGI-000AeK-00 for namedroppers@ops.ietf.org; Mon, 08 Apr 2002 06:32:46 -0700 From: Masataka Ohta Message-Id: <200204081319.WAA13161@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA13161; Mon, 8 Apr 2002 22:19:07 +0900 Subject: Re: name server without root cache In-Reply-To: from David Conrad at "Apr 4, 2002 07:49:22 pm" To: David Conrad Date: Mon, 8 Apr 2002 22:19:06 +0859 () CC: Mark.Andrews@isc.org, "Jesper G. Hoy" , namedroppers , "'Mats Dufberg'" X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David; > On 4/4/02 7:08 PM, "Masataka Ohta" wrote: > >> No. You either return a valid answer or a error indication. > > The other option is to silently igrore a query and return nothing. > > Which, as has been pointed out, is a bad idea as it triggers retransmission > and causes pointless waiting. That is a pointless evaluation. The proper evaluation criteria is how quickly can we let an administrator of a client fix wrong configuration. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 8 10:40:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25488 for ; Mon, 8 Apr 2002 10:40:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uaB4-000CRM-00 for namedroppers-data@psg.com; Mon, 08 Apr 2002 07:31:26 -0700 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16uaB3-000CQr-00 for namedroppers@ops.ietf.org; Mon, 08 Apr 2002 07:31:25 -0700 Received: by sentry.gw.tislabs.com; id KAA28425; Mon, 8 Apr 2002 10:37:09 -0400 (EDT) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma028412; Mon, 8 Apr 02 10:36:54 -0400 X-Sender: lewis@pop.gw.tislabs.com (Unverified) Message-Id: In-Reply-To: <3CAE294C.CDBD4237@isi.edu> References: <535230000.1017742381@askvoll.hjemme.alvestrand.no> <20020402122333.A301-100000@node10c4d.a2000.nl> <20020405095042.03c4f2c4.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 Apr 2002 10:31:57 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Opt-in wg last call Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 6:46 PM -0400 4/5/02, Daniel Massey wrote: >is there a compelling reason to allow a SIG without a NXT? >I don't see one... Immaterial SIG resource records are (or were) a reason to allow SIGs to exist without NXT. There was a time when there was a desire to allow an application to sign data, stick that SIG in DNS, and then have the application's other end validate the data. How the validating key was distributed was not defined and might not have involved the KEY RR (hence restricting KEY RR may not obviate this scenario). As far as "compelling reason to allow" - there isn't any harm in a SIG without NXT to the DNS protocol, so I wouldn't go about restricting it in the specifications. If the specifications restrict it, then you require more code to be written. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 9 05:55:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00612 for ; Tue, 9 Apr 2002 05:55:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16us00-0008IC-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 02:33:12 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16urzz-0008I3-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 02:33:11 -0700 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g399X9V25577 for ; Tue, 9 Apr 2002 11:33:09 +0200 Date: Tue, 9 Apr 2002 11:33:09 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call Message-Id: <20020409113309.10f7159f.olaf@ripe.net> In-Reply-To: <3CAE294C.CDBD4237@isi.edu> References: <535230000.1017742381@askvoll.hjemme.alvestrand.no> <20020402122333.A301-100000@node10c4d.a2000.nl> <20020405095042.03c4f2c4.olaf@ripe.net> <3CAE294C.CDBD4237@isi.edu> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 05 Apr 2002 17:46:36 -0500 Daniel Massey wrote: > "Olaf M. Kolkman" wrote: > > > > > > > > Yes, either ALL RRsets at a particular name are signed, or NO > > > RRsets at a particular name are signed. > > > > > > > I am a still a little confused. > > > > I think part of the confusion is terminology. Correct, I was tought to think in 'zones'. Having to abandon that concept takes a few days:-) But the confusion also came from thinking about what could go wrong. One of the things I considered is having secured records inside a namespace that has been marked as verifiable unsecured by an opt-in style NXT record (we call that opted-out for simplicity). Based on the example of last week, I've added signed lambda an mu inside an opt-out part of the zone. What got me confused is that there are now to NXT records saying something about the security status of a zone and that introduces ambiguity. (Hence my poorly phrased question on handing back the 'wrong' NXT record). This (poorly configured) zone will only lead to problems if one caches the security state of a zone in a similar way one caches the NXDOMAIN state. I do not know if caching verifyer implementations may/should do that. I am not trying to argue against opt-in, just go forward with the thing. But we are about to sell bullets of new caliber and I am trying to find out ways one can shoot oneself in the foot so that we can provide the warning on the packs. --Olaf Example of 'wrong' mixing of opt-in and normal NXT records. $ORIGIN greek. @ SOA SIG(SOA) greek. 1 KEY 1 SIG(KEY) greek. 1 NXT alpha SIG(NXT) greek. 1 alpha A 10.0.0.1 SIG(A) greek. 1 NXT-OPT omega.greek. (opt in style) SIG (NXT) greek. 1 lambda A 10.0.0.4 SIG(A) greek. 1 NXT mu.greek. SIG (NXT) greek. 1 mu A 10.0.0.5 SIG (A) greek. 1 NXT omega.greek. SIG (NXT) greek. 1 omega A 10.0.0.6 SIG(A) greek. 1 NXT greek. SIG (NXT) greek. 1 --------------------------------------------| 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 Tue Apr 9 11:36:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09478 for ; Tue, 9 Apr 2002 11:36:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uxQl-000EFU-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 08:21:11 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.35 #1) id 16uxQk-000EFH-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 08:21:10 -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 LAA00670; Tue, 9 Apr 2002 11:21:07 -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 LAA28092; Tue, 9 Apr 2002 11:21: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 LAA15369; Tue, 9 Apr 2002 11:21:06 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA06438; Tue, 9 Apr 2002 11:21:06 -0400 (EDT) To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call References: <535230000.1017742381@askvoll.hjemme.alvestrand.no> <20020402122333.A301-100000@node10c4d.a2000.nl> <20020405095042.03c4f2c4.olaf@ripe.net> <3CAE294C.CDBD4237@isi.edu> <20020409113309.10f7159f.olaf@ripe.net> From: Derek Atkins Date: 09 Apr 2002 11:21:06 -0400 In-Reply-To: <20020409113309.10f7159f.olaf@ripe.net> Message-ID: Lines: 62 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" writes: > Example of 'wrong' mixing of opt-in and normal NXT records. > > > $ORIGIN greek. > @ SOA > SIG(SOA) greek. 1 > KEY 1 > SIG(KEY) greek. 1 > NXT alpha > SIG(NXT) greek. 1 > > alpha A 10.0.0.1 > SIG(A) greek. 1 > NXT-OPT omega.greek. (opt in style) > SIG (NXT) greek. 1 > > lambda A 10.0.0.4 > SIG(A) greek. 1 > NXT mu.greek. > SIG (NXT) greek. 1 > > mu A 10.0.0.5 > SIG (A) greek. 1 > NXT omega.greek. > SIG (NXT) greek. 1 > > > omega A 10.0.0.6 > SIG(A) greek. 1 > NXT greek. > SIG (NXT) greek. 1 > With this zone data, an attacker do anything they wanted with responses for lambda, mu, or anything else that exists between alpha and omega. Even though lambda is signed, an attacker can still hand you bogus data and supply the "alpha NXT-OPT omega" record to "prove" that their response is ok. Because lambda and mu are _not_ part of the NXT chain, they are unverifiable by a resolver. The only benefit you get from this is that _iff_ there is no attacker, then a resolver can verify that lambda and mu are correct. But due to the NXT-OPT record at alpha, the signatures at lambda and mu are almost useless, and the NXT records are ABSOLUTELY useless. This is some of the rope that I don't think we should be providing to users. The DNS is a critical infrastructure; without it the Internet would fall apart (at least from the usability side -- who can remember all those IP addresses? ;) The more rope you give users, the more chance they have to screw up. Sure, they are probably just screwing themselves over, but still, why give them the chance? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 9 13:24:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12898 for ; Tue, 9 Apr 2002 13:24:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uz7X-000GNZ-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 10:09:27 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16uz7W-000GNH-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 10:09:26 -0700 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8DA2231924; Tue, 9 Apr 2002 10:09:24 -0700 (PDT) Date: Tue, 9 Apr 2002 19:19:46 +0200 (CEST) From: Roy Arends X-X-Sender: To: Edward Lewis Cc: Subject: Re: Opt-in wg last call In-Reply-To: Message-ID: <20020409191605.X19376-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 8 Apr 2002, Edward Lewis wrote: > At 6:46 PM -0400 4/5/02, Daniel Massey wrote: > >is there a compelling reason to allow a SIG without a NXT? > >I don't see one... > > Immaterial SIG resource records are (or were) a reason to allow SIGs to > exist without NXT. There was a time when there was a desire to allow an > application to sign data, stick that SIG in DNS, and then have the > application's other end validate the data. How the validating key was > distributed was not defined and might not have involved the KEY RR (hence > restricting KEY RR may not obviate this scenario). > > As far as "compelling reason to allow" - there isn't any harm in a SIG > without NXT to the DNS protocol, so I wouldn't go about restricting it in > the specifications. There is a compelling reason. If I explicitly sign a record, which does not require to have a NXT associated with it, some malicious entity can falsly prove I don't exist (2535 NXT), or am not signed (opt-in NXT). Therefor: 1) NXT chain covers ALL signed names in a zone. 2) ALL signed names have a NXT record associated with it. 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 Apr 9 15:15:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17722 for ; Tue, 9 Apr 2002 15:15:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v0s2-000Inx-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 12:01:34 -0700 Received: from [128.134.70.10] (helo=daisy.kwangwoon.ac.kr) by psg.com with esmtp (Exim 3.35 #1) id 16v0s0-000Inr-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 12:01:33 -0700 Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by daisy.kwangwoon.ac.kr (8.11.6/8.11.6) with SMTP id g39J9oX02514; Wed, 10 Apr 2002 04:09:53 +0900 (KST) Received: from ([147.28.0.62]) by INCA SMTP Server 2002-04-10 æĄĄü 2:48:15 Received: from lserv by psg.com with local (Exim 3.35 #1) id 16uz7X-000GNZ-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 10:09:27 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16uz7W-000GNH-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 10:09:26 -0700 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8DA2231924; Tue, 9 Apr 2002 10:09:24 -0700 (PDT) Date: Tue, 9 Apr 2002 19:19:46 +0200 (CEST) From: Roy Arends X-X-Sender: To: Edward Lewis Cc: Subject: Re: Opt-in wg last call In-Reply-To: Message-ID: <20020409191605.X19376-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 8 Apr 2002, Edward Lewis wrote: > At 6:46 PM -0400 4/5/02, Daniel Massey wrote: > >is there a compelling reason to allow a SIG without a NXT? > >I don't see one... > > Immaterial SIG resource records are (or were) a reason to allow SIGs to > exist without NXT. There was a time when there was a desire to allow an > application to sign data, stick that SIG in DNS, and then have the > application's other end validate the data. How the validating key was > distributed was not defined and might not have involved the KEY RR (hence > restricting KEY RR may not obviate this scenario). > > As far as "compelling reason to allow" - there isn't any harm in a SIG > without NXT to the DNS protocol, so I wouldn't go about restricting it in > the specifications. There is a compelling reason. If I explicitly sign a record, which does not require to have a NXT associated with it, some malicious entity can falsly prove I don't exist (2535 NXT), or am not signed (opt-in NXT). Therefor: 1) NXT chain covers ALL signed names in a zone. 2) ALL signed names have a NXT record associated with it. 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: -- 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 Apr 9 15:33:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18380 for ; Tue, 9 Apr 2002 15:33:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v1DW-000JKR-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 12:23:46 -0700 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16v1DV-000JKL-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 12:23:45 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g39JJxF15053; Tue, 9 Apr 2002 15:19:59 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Tue, 9 Apr 2002 15:19:59 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call In-Reply-To: <20020409113309.10f7159f.olaf@ripe.net> Message-ID: <20020409112541.I14587-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 9 Apr 2002, Olaf M. Kolkman wrote: > On Fri, 05 Apr 2002 17:46:36 -0500 > Daniel Massey wrote: > > > "Olaf M. Kolkman" wrote: > > > > > > > > > > > Yes, either ALL RRsets at a particular name are signed, or NO > > > > RRsets at a particular name are signed. > > > > > > > > > > I am a still a little confused. > > > > > > > I think part of the confusion is terminology. > > > Correct, I was tought to think in 'zones'. Having to abandon that > concept takes a few days:-) > > But the confusion also came from thinking about what could go wrong. > > One of the things I considered is having secured records inside a > namespace that has been marked as verifiable unsecured by an opt-in > style NXT record (we call that opted-out for simplicity). I agree we need a new terminology to describe DNSSEC zone with opt-in. The indicator whether a zone is secure is the signing of the apex RRsets. Here is my take on the types of zones we may end up with: Unsecure zone: zone apex is not signed. Fully secure zone: KEY set at apex apex is signed by a zone key all names are signed by a zone key and covered by NXT. Partially secure zone: KEY set at apex apex is signed by a zonekey one or more names are omitted from NXT chain and not signed by a zone key. In addition the locally and globally secure definitions from RFC3090 apply. A zone is Globally [Glob|loc]ally secure: KEY set at apex apex is signed all names are signed by a zone key and covered by NXT there exists a chain of KEY and DS records to the root validating the zone KEY set. If zone is not globally secure then it is locally secure. Imaterial signatures do not affect the security status at all. 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 Apr 9 16:35:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21689 for ; Tue, 9 Apr 2002 16:35:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v28b-000KoO-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 13:22:45 -0700 Received: from [128.134.70.10] (helo=daisy.kwangwoon.ac.kr) by psg.com with esmtp (Exim 3.35 #1) id 16v28Z-000Kny-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 13:22:44 -0700 Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by daisy.kwangwoon.ac.kr (8.11.6/8.11.6) with SMTP id g39KV3X05235; Wed, 10 Apr 2002 05:31:05 +0900 (KST) Received: from ([147.28.0.62]) by INCA SMTP Server 2002-04-10 æĄĄü 4:49:17 Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v1DW-000JKR-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 12:23:46 -0700 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16v1DV-000JKL-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 12:23:45 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g39JJxF15053; Tue, 9 Apr 2002 15:19:59 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Tue, 9 Apr 2002 15:19:59 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call In-Reply-To: <20020409113309.10f7159f.olaf@ripe.net> Message-ID: <20020409112541.I14587-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 9 Apr 2002, Olaf M. Kolkman wrote: > On Fri, 05 Apr 2002 17:46:36 -0500 > Daniel Massey wrote: > > > "Olaf M. Kolkman" wrote: > > > > > > > > > > > Yes, either ALL RRsets at a particular name are signed, or NO > > > > RRsets at a particular name are signed. > > > > > > > > > > I am a still a little confused. > > > > > > > I think part of the confusion is terminology. > > > Correct, I was tought to think in 'zones'. Having to abandon that > concept takes a few days:-) > > But the confusion also came from thinking about what could go wrong. > > One of the things I considered is having secured records inside a > namespace that has been marked as verifiable unsecured by an opt-in > style NXT record (we call that opted-out for simplicity). I agree we need a new terminology to describe DNSSEC zone with opt-in. The indicator whether a zone is secure is the signing of the apex RRsets. Here is my take on the types of zones we may end up with: Unsecure zone: zone apex is not signed. Fully secure zone: KEY set at apex apex is signed by a zone key all names are signed by a zone key and covered by NXT. Partially secure zone: KEY set at apex apex is signed by a zonekey one or more names are omitted from NXT chain and not signed by a zone key. In addition the locally and globally secure definitions from RFC3090 apply. A zone is Globally [Glob|loc]ally secure: KEY set at apex apex is signed all names are signed by a zone key and covered by NXT there exists a chain of KEY and DS records to the root validating the zone KEY set. If zone is not globally secure then it is locally secure. Imaterial signatures do not affect the security status at all. 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: -- 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 Apr 9 17:06:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22612 for ; Tue, 9 Apr 2002 17:06:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v2Zj-000LdV-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 13:50:47 -0700 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16v2Zi-000LdP-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 13:50:46 -0700 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g39Koi745996 for ; Tue, 9 Apr 2002 22:50:44 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Tue, 9 Apr 2002 22:50:44 +0200 (CEST) From: Mats Dufberg To: Subject: Re: Opt-in wg last call In-Reply-To: Message-ID: <20020409224436.Y7955-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > with opt-in, the concept of "secured zones" would no longer exist, > period. zones could have a (possibly improper) subset (possibly) > secured. It will still be meaningful to distinguish between regular, unsecured zones, and zones in which at least the apex is secured. I think it would make sense to call the latter type "secured zones" if we recognise that it does not necessarily mean that all names are secured. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- 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 Apr 9 17:45:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24043 for ; Tue, 9 Apr 2002 17:45:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v379-000MZN-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 14:25:19 -0700 Received: from [128.134.70.10] (helo=daisy.kwangwoon.ac.kr) by psg.com with esmtp (Exim 3.35 #1) id 16v377-000MZA-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 14:25:17 -0700 Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by daisy.kwangwoon.ac.kr (8.11.6/8.11.6) with SMTP id g39LXjX07007 for ; Wed, 10 Apr 2002 06:33:46 +0900 (KST) Received: from ([147.28.0.62]) by INCA SMTP Server 2002-04-10 æĄĄü 6:18:13 Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v2Zj-000LdV-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 13:50:47 -0700 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16v2Zi-000LdP-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 13:50:46 -0700 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g39Koi745996 for ; Tue, 9 Apr 2002 22:50:44 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Tue, 9 Apr 2002 22:50:44 +0200 (CEST) From: Mats Dufberg To: Subject: Re: Opt-in wg last call In-Reply-To: Message-ID: <20020409224436.Y7955-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > with opt-in, the concept of "secured zones" would no longer exist, > period. zones could have a (possibly improper) subset (possibly) > secured. It will still be meaningful to distinguish between regular, unsecured zones, and zones in which at least the apex is secured. I think it would make sense to call the latter type "secured zones" if we recognise that it does not necessarily mean that all names are secured. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- 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 Apr 9 19:25:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25587 for ; Tue, 9 Apr 2002 19:25:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v4qB-000PPA-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 16:15:55 -0700 Received: from df-inet1.exchange.microsoft.com ([131.107.8.8]) by psg.com with esmtp (Exim 3.35 #1) id 16v4qB-000PP4-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 16:15:55 -0700 Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.4386); Tue, 9 Apr 2002 16:16:27 -0700 Received: from 10.197.0.60 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Apr 2002 16:15:49 -0700 Received: from DF-DINKY.platinum.corp.microsoft.com ([10.197.1.60]) by DF-YURI.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Apr 2002 16:15:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Opt-in wg last call Date: Tue, 9 Apr 2002 16:15:48 -0700 Message-ID: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> Thread-Topic: Opt-in wg last call Thread-Index: AcHgBPTV7sgt+Y6KTDqt0h6Hc6AQxwAFqLHA From: "Peter Ford" To: "Olafur Gudmundsson" , "Olaf M. Kolkman" Cc: X-OriginalArrivalTime: 09 Apr 2002 23:15:49.0418 (UTC) FILETIME=[7C6B08A0:01C1E01C] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA25587 In place of "fully secure zone" and "partially secure zone" how about: "secure full zone" and "secure partial zone". (or perhaps "secure optional zone") The phrase "partially secure" just does not sound quite right. Regards, peterf -- 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 Apr 9 19:51:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25905 for ; Tue, 9 Apr 2002 19:51:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v5Gt-00007f-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 16:43:31 -0700 Received: from [128.134.70.10] (helo=daisy.kwangwoon.ac.kr) by psg.com with esmtp (Exim 3.35 #1) id 16v5Gr-00007Z-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 16:43:30 -0700 Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by daisy.kwangwoon.ac.kr (8.11.6/8.11.6) with SMTP id g39NpgX10669; Wed, 10 Apr 2002 08:51:43 +0900 (KST) Received: from ([147.28.0.62]) by INCA SMTP Server 2002-04-10 æĄĄü 8:36:05 Received: from lserv by psg.com with local (Exim 3.35 #1) id 16v4qB-000PPA-00 for namedroppers-data@psg.com; Tue, 09 Apr 2002 16:15:55 -0700 Received: from df-inet1.exchange.microsoft.com ([131.107.8.8]) by psg.com with esmtp (Exim 3.35 #1) id 16v4qB-000PP4-00 for namedroppers@ops.ietf.org; Tue, 09 Apr 2002 16:15:55 -0700 Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.4386); Tue, 9 Apr 2002 16:16:27 -0700 Received: from 10.197.0.60 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Apr 2002 16:15:49 -0700 Received: from DF-DINKY.platinum.corp.microsoft.com ([10.197.1.60]) by DF-YURI.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Apr 2002 16:15:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Opt-in wg last call Date: Tue, 9 Apr 2002 16:15:48 -0700 Message-ID: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> Thread-Topic: Opt-in wg last call Thread-Index: AcHgBPTV7sgt+Y6KTDqt0h6Hc6AQxwAFqLHA From: "Peter Ford" To: "Olafur Gudmundsson" , "Olaf M. Kolkman" Cc: X-OriginalArrivalTime: 09 Apr 2002 23:15:49.0418 (UTC) FILETIME=[7C6B08A0:01C1E01C] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA25905 In place of "fully secure zone" and "partially secure zone" how about: "secure full zone" and "secure partial zone". (or perhaps "secure optional zone") The phrase "partially secure" just does not sound quite right. Regards, peterf -- 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 Apr 10 03:34:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13056 for ; Wed, 10 Apr 2002 03:34:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vCQH-000C2D-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 00:21:41 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16vCQF-000C27-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 00:21:40 -0700 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g3A7Lbu31420; Wed, 10 Apr 2002 09:21:37 +0200 Date: Wed, 10 Apr 2002 09:21:36 +0200 From: "Olaf M. Kolkman" To: Derek Atkins Cc: namedroppers@ops.ietf.org Subject: Encapulated NXTs (was Opt-in wg last call) Message-Id: <20020410092136.5376196a.olaf@ripe.net> In-Reply-To: References: <535230000.1017742381@askvoll.hjemme.alvestrand.no> <20020402122333.A301-100000@node10c4d.a2000.nl> <20020405095042.03c4f2c4.olaf@ripe.net> <3CAE294C.CDBD4237@isi.edu> <20020409113309.10f7159f.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Change of subject; this not to delay the last call. On 09 Apr 2002 11:21:06 -0400 Derek Atkins wrote: > Because lambda and mu are _not_ part of the NXT chain, they are > unverifiable by a resolver. The only benefit you get from this is > that _iff_ there is no attacker, then a resolver can verify that > lambda and mu are correct. lambda and my are _not_ part of the NXT chain but the NXT chain is not used for positive verification isn't it? In other words if lambda and mu are signed by a key that is part of the chain of trust then they are securely verified. The NXT can also be used for the denial of existence of types. Maybe the rewrite of the DNSSEC spec should specifically state that these 'encapsulated' NXT records are not allowed. --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 Wed Apr 10 04:29:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13754 for ; Wed, 10 Apr 2002 04:29:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vDHX-000D0K-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 01:16:43 -0700 Received: from [128.134.70.10] (helo=daisy.kwangwoon.ac.kr) by psg.com with esmtp (Exim 3.35 #1) id 16vDHJ-000D09-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 01:16:29 -0700 Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by daisy.kwangwoon.ac.kr (8.11.6/8.11.6) with SMTP id g3A8OqX08782; Wed, 10 Apr 2002 17:24:56 +0900 (KST) Received: from ([147.28.0.62]) by INCA SMTP Server 2002-04-10 æĄČÄ 5:08:38 Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vCQH-000C2D-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 00:21:41 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16vCQF-000C27-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 00:21:40 -0700 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g3A7Lbu31420; Wed, 10 Apr 2002 09:21:37 +0200 Date: Wed, 10 Apr 2002 09:21:36 +0200 From: "Olaf M. Kolkman" To: Derek Atkins Cc: namedroppers@ops.ietf.org Subject: Encapulated NXTs (was Opt-in wg last call) Message-Id: <20020410092136.5376196a.olaf@ripe.net> In-Reply-To: References: <535230000.1017742381@askvoll.hjemme.alvestrand.no> <20020402122333.A301-100000@node10c4d.a2000.nl> <20020405095042.03c4f2c4.olaf@ripe.net> <3CAE294C.CDBD4237@isi.edu> <20020409113309.10f7159f.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Change of subject; this not to delay the last call. On 09 Apr 2002 11:21:06 -0400 Derek Atkins wrote: > Because lambda and mu are _not_ part of the NXT chain, they are > unverifiable by a resolver. The only benefit you get from this is > that _iff_ there is no attacker, then a resolver can verify that > lambda and mu are correct. lambda and my are _not_ part of the NXT chain but the NXT chain is not used for positive verification isn't it? In other words if lambda and mu are signed by a key that is part of the chain of trust then they are securely verified. The NXT can also be used for the denial of existence of types. Maybe the rewrite of the DNSSEC spec should specifically state that these 'encapsulated' NXT records are not allowed. --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: -- 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 Apr 10 09:53:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19342 for ; Wed, 10 Apr 2002 09:53:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vIBt-000ILS-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 06:31:13 -0700 Received: from porter.east.isi.edu ([65.114.168.20] helo=east.east.isi.edu) by psg.com with esmtp (Exim 3.35 #1) id 16vIBs-000ILM-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 06:31:12 -0700 Received: from isi.edu (wireless82.east.isi.edu [65.114.168.82]) by east.east.isi.edu (8.11.3/8.11.3) with ESMTP id g3ADV2s23314; Wed, 10 Apr 2002 09:31:02 -0400 (EDT) Message-ID: <3CB43F46.25DB3237@isi.edu> Date: Wed, 10 Apr 2002 09:33:58 -0400 From: Daniel Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ford CC: Olafur Gudmundsson , "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: zone naming terms (was Opt-in wg last call) References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, This is not meant as argument against opt-in and I don't think this should delay the last call (hence the new subject), but I think we should recognize there is a shift in granularity from zones to names. The DNSSEC terminology should reflect this change. I think Peter's changes below are an improvement, but note that you also need to add a globally or locally in front of that. We would have things like a "globally partially secure zone" and a "locally fully secure zone". If the com zone does get signed, do we really want to see an announcement saying the DNS now has a "locally partially secure com zone" (or "locally secure partial com zone" or "locally secure optional com zone") I think confusion added by a term like "locally partially secure com zone" exceeds the utility of this term. We are now signing names, not zones. Dan Peter Ford wrote: > > In place of "fully secure zone" and "partially secure zone" how about: > "secure full zone" and "secure partial zone". (or perhaps "secure > optional zone") > > The phrase "partially secure" just does not sound quite right. > > Regards, peterf > > -- > 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 Apr 10 10:59:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21446 for ; Wed, 10 Apr 2002 10:59:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vJN6-000Jow-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 07:46:52 -0700 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.35 #1) id 16vJN5-000Joq-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 07:46:51 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id KAA03023 for ; Wed, 10 Apr 2002 10:46:48 -0400 (EDT) Message-ID: <00db01c1e09d$b9301d30$b9370681@BARNACLE> From: "Scott Rose" To: References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB43F46.25DB3237@isi.edu> Subject: Re: zone naming terms (was Opt-in wg last call) Date: Wed, 10 Apr 2002 10:40:55 -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 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with you, but I still think we should keep these terms (and define them) in the specs. That way, the meanings are agreed upon in the text. Whether or not they are used correctly in announcements, other papers, etc, is something we can't control anyway. In other words, I think the definitions should apear in the RFC's so to avoid confusion, but realize not everyone will use them properly. Scott -looking forward to the proud day when I hear ".com is globally partially secure" ;-) ----- Original Message ----- From: "Daniel Massey" To: "Peter Ford" Cc: "Olafur Gudmundsson" ; "Olaf M. Kolkman" ; Sent: Wednesday, April 10, 2002 9:33 AM Subject: zone naming terms (was Opt-in wg last call) > Hi, > > This is not meant as argument against opt-in and I don't think > this should delay the last call (hence the new subject), but I think > we should recognize there is a shift in granularity from zones to > names. The DNSSEC terminology should reflect this change. > > I think Peter's changes below are an improvement, but note that you > also need to add a globally or locally in front of that. We would > have things like a "globally partially secure zone" and a "locally > fully secure zone". If the com zone does get signed, do we really > want to see an announcement saying the DNS now has a "locally > partially secure com zone" (or "locally secure partial com zone" > or "locally secure optional com zone") > > I think confusion added by a term like "locally partially secure > com zone" exceeds the utility of this term. We are now signing > names, not zones. > > Dan > > > Peter Ford wrote: > > > > In place of "fully secure zone" and "partially secure zone" how about: > > "secure full zone" and "secure partial zone". (or perhaps "secure > > optional zone") > > > > The phrase "partially secure" just does not sound quite right. > > > > Regards, peterf > > > > -- > > 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: -- 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 Apr 10 11:32:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22418 for ; Wed, 10 Apr 2002 11:32:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vJxh-000Kbw-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 08:24:41 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.35 #1) id 16vJxg-000Kbq-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 08:24:40 -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 LAA27611; Wed, 10 Apr 2002 11:24:39 -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 LAA28863; Wed, 10 Apr 2002 11:24:38 -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 LAA06853; Wed, 10 Apr 2002 11:24:37 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA04534; Wed, 10 Apr 2002 11:24:37 -0400 (EDT) To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: Encapulated NXTs (was Opt-in wg last call) References: <535230000.1017742381@askvoll.hjemme.alvestrand.no> <20020402122333.A301-100000@node10c4d.a2000.nl> <20020405095042.03c4f2c4.olaf@ripe.net> <3CAE294C.CDBD4237@isi.edu> <20020409113309.10f7159f.olaf@ripe.net> <20020410092136.5376196a.olaf@ripe.net> From: Derek Atkins Date: 10 Apr 2002 11:24:37 -0400 In-Reply-To: <20020410092136.5376196a.olaf@ripe.net> Message-ID: Lines: 43 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Olaf M. Kolkman" writes: > lambda and my are _not_ part of the NXT chain but the NXT chain is not > used for positive verification isn't it? In other words if lambda and mu > are signed by a key that is part of the chain of trust then they are > securely verified. The NXT can also be used for the denial of existence of > types. Of course it is used for positive verification. It was created for that purpose (read: authenticated denial). That's the point of the NXT chain. In 2535 (with or without DS) a response from a 'secure zone' would have _either_ a response with a SIG _or_ a NXT. With opt-in, you sort-of have the same issue, except you can supply other data with the NXT. In the example given there are two overlapping NXT records, the NXT chain and the 'standalone NXT'. This provides an attacker with data to replace one for the other in certain circumstances. The real answer is that no, you SHOULD NOT have signed data outside the NXT chain (even with opt-in). This also means that if you use opt-in then if you sign a new piece of data there is a window of opportunity for an attacker to use this attack until the old NXT/SIG expires. > Maybe the rewrite of the DNSSEC spec should specifically state that these > 'encapsulated' NXT records are not allowed. Agreed. I'd also say that these 'encapsulated' SIG records are not allowed, either. > --Olaf -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 10 11:32:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22430 for ; Wed, 10 Apr 2002 11:32:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vJzZ-000Kfd-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 08:26:37 -0700 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16vJzY-000KfX-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 08:26:36 -0700 Received: by sentry.gw.tislabs.com; id LAA12160; Wed, 10 Apr 2002 11:32:22 -0400 (EDT) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma012146; Wed, 10 Apr 02 11:31:30 -0400 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <00db01c1e09d$b9301d30$b9370681@BARNACLE> References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB43F46.25DB3237@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Apr 2002 11:26:34 -0400 To: "Scott Rose" From: Edward Lewis Subject: Re: zone naming terms (was Opt-in wg last call) Cc: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Labeling a zone as secure, experimental, or insecure was really a mistake in the past. The origin of the need to create the labels was to define how a resolver went about evaluating the security of the data. Prior to opt-in, every set in the zone had the same security status, hence it was convienent to call the zone signed or unsigned. What we should have been concentrating on then was whether the set was signed or unsigned. So, probably the best thing to do is to list the terms "secure zone" and "unsecure zone" as obsolete concepts. A "secure set" or "unsecure set" is more appropriate and more accurate, with or without opt-in. Truthfully, with opt-in we would have security name-by-name, so we'd have "secure names." However, no matter how you slice it, the resolver is working set-by-set, no matter whether the security is zone-by-zone or name-by-name. At 10:40 AM -0400 4/10/02, Scott Rose wrote: >I agree with you, but I still think we should keep these terms (and define >them) in the specs. That way, the meanings are agreed upon in the text. >Whether or not they are used correctly in announcements, other papers, etc, >is something we can't control anyway. > >In other words, I think the definitions should apear in the RFC's so to >avoid confusion, but realize not everyone will use them properly. > >Scott >-looking forward to the proud day when I hear ".com is globally partially >secure" ;-) >----- Original Message ----- >From: "Daniel Massey" >To: "Peter Ford" >Cc: "Olafur Gudmundsson" ; "Olaf M. Kolkman" ; > >Sent: Wednesday, April 10, 2002 9:33 AM >Subject: zone naming terms (was Opt-in wg last call) > > >> Hi, >> >> This is not meant as argument against opt-in and I don't think >> this should delay the last call (hence the new subject), but I think >> we should recognize there is a shift in granularity from zones to >> names. The DNSSEC terminology should reflect this change. >> >> I think Peter's changes below are an improvement, but note that you >> also need to add a globally or locally in front of that. We would >> have things like a "globally partially secure zone" and a "locally >> fully secure zone". If the com zone does get signed, do we really >> want to see an announcement saying the DNS now has a "locally >> partially secure com zone" (or "locally secure partial com zone" >> or "locally secure optional com zone") >> >> I think confusion added by a term like "locally partially secure >> com zone" exceeds the utility of this term. We are now signing >> names, not zones. >> >> Dan >> >> >> Peter Ford wrote: >> > >> > In place of "fully secure zone" and "partially secure zone" how about: >> > "secure full zone" and "secure partial zone". (or perhaps "secure >> > optional zone") >> > >> > The phrase "partially secure" just does not sound quite right. >> > >> > Regards, peterf >> > >> > -- >> > 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: > > >-- >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: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Last day is Wednesday, April 24, 2002... Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 10 12:36:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24829 for ; Wed, 10 Apr 2002 12:35:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vKp9-000LqC-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 09:19:55 -0700 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16vKp8-000Lq5-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 09:19:54 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g3AGG3l16866 for ; Wed, 10 Apr 2002 12:16:03 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Wed, 10 Apr 2002 12:16:03 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: Opt-in Decission day: Postponed Message-ID: <20020410120723.C16672-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At the Minneapolis meeting Randy and I stated that today would be the day that Opt-in fate would be announced. Due to fact that over the last two weeks both chairs have been traveling with limited (or no) email connectivity, we have not able jointly judge consensus of the working group. The new decission date is now April 15'th. Olafur, today's chair withe e-mail connectivity :-) -- 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 Apr 10 12:55:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25127 for ; Wed, 10 Apr 2002 12:55:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vLCQ-000MN6-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 09:43:58 -0700 Received: from is1-50.antd.nist.gov ([129.6.50.251]) by psg.com with esmtp (Exim 3.35 #1) id 16vLCP-000MN0-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 09:43:57 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by is1-50.antd.nist.gov (8.9.3/8.9.3) with SMTP id MAA05755; Wed, 10 Apr 2002 12:43:48 -0400 (EDT) Message-ID: <011701c1e0ae$111d51b0$b9370681@BARNACLE> From: "Scott Rose" To: "Edward Lewis" Cc: References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB43F46.25DB3237@isi.edu> Subject: Re: zone naming terms (was Opt-in wg last call) Date: Wed, 10 Apr 2002 12:37:55 -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 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Well okay. But what does "secure set" mean? Would it mean that there is at least 1 SIG present for the RRset, and the SIG can be traced back to a trusted KEY? Or simply a SIG exists for that RRset? Not associating terms to zone status in the specs is a good thing I guess. It will still be done anyway, I'm afraid: it's easy to say "my zone is secure" than saying "all of the sets in my zone are secure". Scott ----- Original Message ----- From: "Edward Lewis" > Labeling a zone as secure, experimental, or insecure was really a mistake > in the past. The origin of the need to create the labels was to define how > a resolver went about evaluating the security of the data. > > Prior to opt-in, every set in the zone had the same security status, hence > it was convienent to call the zone signed or unsigned. What we should have > been concentrating on then was whether the set was signed or unsigned. > > So, probably the best thing to do is to list the terms "secure zone" and > "unsecure zone" as obsolete concepts. A "secure set" or "unsecure set" is > more appropriate and more accurate, with or without opt-in. Truthfully, > with opt-in we would have security name-by-name, so we'd have "secure > names." However, no matter how you slice it, the resolver is working > set-by-set, no matter whether the security is zone-by-zone or name-by-name. > > At 10:40 AM -0400 4/10/02, Scott Rose wrote: > >I agree with you, but I still think we should keep these terms (and define > >them) in the specs. That way, the meanings are agreed upon in the text. > >Whether or not they are used correctly in announcements, other papers, etc, > >is something we can't control anyway. > > > >In other words, I think the definitions should apear in the RFC's so to > >avoid confusion, but realize not everyone will use them properly. > > > >Scott > >-looking forward to the proud day when I hear ".com is globally partially > >secure" ;-) > >----- Original Message ----- > >From: "Daniel Massey" > >To: "Peter Ford" > >Cc: "Olafur Gudmundsson" ; "Olaf M. Kolkman" ; > > > >Sent: Wednesday, April 10, 2002 9:33 AM > >Subject: zone naming terms (was Opt-in wg last call) > > > > > >> Hi, > >> > >> This is not meant as argument against opt-in and I don't think > >> this should delay the last call (hence the new subject), but I think > >> we should recognize there is a shift in granularity from zones to > >> names. The DNSSEC terminology should reflect this change. > >> > >> I think Peter's changes below are an improvement, but note that you > >> also need to add a globally or locally in front of that. We would > >> have things like a "globally partially secure zone" and a "locally > >> fully secure zone". If the com zone does get signed, do we really > >> want to see an announcement saying the DNS now has a "locally > >> partially secure com zone" (or "locally secure partial com zone" > >> or "locally secure optional com zone") > >> > >> I think confusion added by a term like "locally partially secure > >> com zone" exceeds the utility of this term. We are now signing > >> names, not zones. > >> > >> Dan > >> > >> > >> Peter Ford wrote: > >> > > >> > In place of "fully secure zone" and "partially secure zone" how about: > >> > "secure full zone" and "secure partial zone". (or perhaps "secure > >> > optional zone") > >> > > >> > The phrase "partially secure" just does not sound quite right. > >> > > >> > Regards, peterf > >> > > >> > -- > >> > 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: > > > > > >-- > >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: > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Last day is Wednesday, April 24, 2002... > > Opinions expressed are property of my evil twin, not my employer. > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > 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 Apr 10 13:33:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26127 for ; Wed, 10 Apr 2002 13:33:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vLo5-000NDV-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 10:22:53 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.35 #1) id 16vLo4-000NDL-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 10:22:52 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 10 Apr 2002 17:22:51 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 13:22:34 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002041013223423495 ; Wed, 10 Apr 2002 13:22:34 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Apr 2002 13:23:18 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E29F6@COL-581-EXS01> From: "Loomis, Rip" To: "'Scott Rose'" , Edward Lewis Cc: namedroppers@ops.ietf.org Subject: RE: zone naming terms (was Opt-in wg last call) Date: Wed, 10 Apr 2002 13:22:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (Hello Scott and Ed--) Even the term "secure" set is a misnomer IMHO. "Security" of such things depends on perspective and numerous other factors. If someone signs data and then the zone private key is compromised, then to me any data signed with that key is no longer "secure". It is, however, still signed. Similarly, if _you_ statically configure a key as trusted, but _I_ don't configure that key as trusted, then you might term the data within a specific zone as "secure" while I would state that it is "signed but not secure" (according to the rules I think you're using). I would recommend the following terms: "Signed RR set" (or "signed set") "Unsigned RR set" (or "unsigned set") "Fully signed zone" - signed IAW RFC 2535, or 2535+DS "Opt-in signed zone" (or "partially signed zone") - signed IAW 2535 + Opt-in (w/ or w/o DS) These terms are still perhaps annoying and confusing-- but at least they're consistent with each other and don't depend on one's world view. -- 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 Wed Apr 10 13:41:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26361 for ; Wed, 10 Apr 2002 13:41:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vLwM-000NPV-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 10:31:26 -0700 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16vLwL-000NPP-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 10:31:26 -0700 Received: by sentry.gw.tislabs.com; id NAA14857; Wed, 10 Apr 2002 13:37:12 -0400 (EDT) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma014834; Wed, 10 Apr 02 13:37:09 -0400 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <011701c1e0ae$111d51b0$b9370681@BARNACLE> References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB43F46.25DB3237@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Apr 2002 13:32:13 -0400 To: "Scott Rose" From: Edward Lewis Subject: Re: zone naming terms (was Opt-in wg last call) Cc: "Edward Lewis" , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:37 PM -0400 4/10/02, Scott Rose wrote: >Well okay. But what does "secure set" mean? Would it mean that there is at >least 1 SIG present for the RRset, and the SIG can be traced back to a >trusted KEY? Or simply a SIG exists for that RRset? Whether a set is "secure(d)" or "insecure" depends on the eye of the resolver. Hence, if there is some way within the resolver's policy that it can chain "keys and sigs" from the data in question to a configured secure point, then the set is secured. Otherwise the set is not. (Or, to answer your questions: it's what the resolver thinks, a cautious yes, and absolutely not.) A set being secured is not the same as a set that is verified. A set being secured means just that there is an expectation of a proper SIG. (The reason for this concern is that there are older caches out there that may separate a set from its signature.) What is probably confusing is that the determination of "secured" in this sense is determined by the resolver and not the server. One resolver may determine differently than another resolver for the same data, no matter how careful the server is. It's all up to the resolver. > >Not associating terms to zone status in the specs is a good thing I guess. >It will still be done anyway, I'm afraid: it's easy to say "my zone is >secure" than saying "all of the sets in my zone are secure". No quibble with that... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Last day is Wednesday, April 24, 2002... Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 10 15:42:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00585 for ; Wed, 10 Apr 2002 15:42:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vNdh-000PwA-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 12:20:17 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.35 #1) id 16vNdf-000Pvz-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 12:20:16 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g3AJJix19711; Wed, 10 Apr 2002 12:19:45 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 10 Apr 2002 12:19:43 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Derek Atkins cc: "Olaf M. Kolkman" , Subject: Re: Encapulated NXTs (was Opt-in wg last call) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 10 Apr 2002, Derek Atkins wrote: > "Olaf M. Kolkman" writes: > > > lambda and my are _not_ part of the NXT chain but the NXT chain is not > > used for positive verification isn't it? In other words if lambda and mu > > are signed by a key that is part of the chain of trust then they are > > securely verified. The NXT can also be used for the denial of existence of > > types. > > Of course it is used for positive verification. It was created for > that purpose (read: authenticated denial). That's the point of the > NXT chain. NXTs were designed for authenticated denial, which is negative validation, not positive. In this case, positive or negative refers to the type of response, not the result of the validation - that is, a positive validation would be over existing data, and a negative validation would be over nonexistant data. 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 Apr 10 15:51:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00839 for ; Wed, 10 Apr 2002 15:51:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vNyL-0000Pw-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 12:41:37 -0700 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16vNyK-0000Pq-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 12:41:36 -0700 Received: by sentry.gw.tislabs.com; id PAA17835; Wed, 10 Apr 2002 15:47:18 -0400 (EDT) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma017830; Wed, 10 Apr 02 15:47:06 -0400 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E29F6@COL-581-EXS01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Apr 2002 15:42:11 -0400 To: "Loomis, Rip" From: Edward Lewis Subject: RE: zone naming terms (was Opt-in wg last call) Cc: "'Scott Rose'" , Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 1:22 PM -0400 4/10/02, Loomis, Rip wrote: >(Hello Scott and Ed--) > >Even the term "secure" set is a misnomer IMHO. Yeah, it is. What is needed is a term that captures: "...means that the resolver should expect to get a signature with this data set. Failing to do so means that the data set in hand is to be disposed of and every effort made to retrieve a new one." This says nothing about the validity of the expected SIG, just that the resolver should not proceed with the next step (verification) until there is one. If the set is such that no signature is expected, the resolver is free to use the data set much as it does "today." -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Last day is Wednesday, April 24, 2002... Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 10 16:40:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02191 for ; Wed, 10 Apr 2002 16:40:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vOhY-0001g8-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 13:28:20 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.35 #1) id 16vOhX-0001fz-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 13:28:20 -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 QAA11423; Wed, 10 Apr 2002 16:28:15 -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 QAA20088; Wed, 10 Apr 2002 16:25:31 -0400 (EDT) Received: from gorf.mit.edu (GORF.MIT.EDU [18.18.1.77]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA18208; Wed, 10 Apr 2002 16:25:31 -0400 (EDT) Received: (from warlord@localhost) by gorf.mit.edu (8.9.3) id QAA07515; Wed, 10 Apr 2002 16:25:31 -0400 To: Brian Wellington Cc: "Olaf M. Kolkman" , Subject: Re: Encapulated NXTs (was Opt-in wg last call) References: From: Derek Atkins Date: 10 Apr 2002 16:24:50 -0400 In-Reply-To: Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Brian Wellington writes: > On 10 Apr 2002, Derek Atkins wrote: > > > "Olaf M. Kolkman" writes: > > > > > lambda and my are _not_ part of the NXT chain but the NXT chain is not > > > used for positive verification isn't it? In other words if lambda and mu > > > are signed by a key that is part of the chain of trust then they are > > > securely verified. The NXT can also be used for the denial of existence of > > > types. > > > > Of course it is used for positive verification. It was created for > > that purpose (read: authenticated denial). That's the point of the > > NXT chain. > > NXTs were designed for authenticated denial, which is negative validation, > not positive. In this case, positive or negative refers to the type of True, but you get positive verification of what RR types exist for a particular name at the time the NXT was signed. This is what I was referring to. You get authenticated denial of nodes between the NXTs and you get authenticated existence of RRtypes at a node. > response, not the result of the validation - that is, a positive > validation would be over existing data, and a negative validation would be > over nonexistant data. Correct. The validation of RR data is via the SIG. But if you have a SIG that is outside the NXT chain then an attacker could just not send it to you and you'd not know it was missing. > Brian -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 10 17:48:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03454 for ; Wed, 10 Apr 2002 17:48:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vPkS-0003Ip-00 for namedroppers-data@psg.com; Wed, 10 Apr 2002 14:35:24 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.35 #1) id 16vPkS-0003Ij-00 for namedroppers@ops.ietf.org; Wed, 10 Apr 2002 14:35:24 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g3ALZJC20001; Wed, 10 Apr 2002 14:35:19 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 10 Apr 2002 14:35:19 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Derek Atkins cc: "Olaf M. Kolkman" , Subject: Re: Encapulated NXTs (was Opt-in wg last call) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 10 Apr 2002, Derek Atkins wrote: > > NXTs were designed for authenticated denial, which is negative validation, > > not positive. In this case, positive or negative refers to the type of > > True, but you get positive verification of what RR types exist for a > particular name at the time the NXT was signed. This is what I was > referring to. You get authenticated denial of nodes between the NXTs > and you get authenticated existence of RRtypes at a node. While that is true, it's not really the intended use, and it wouldn't be used that way by any software. Validation software would use the record+SIG as proof of existence, the NXT bit as proof of nonexistence, and anything else as proof of a problem. I think we're violently agreeing here, though. > > response, not the result of the validation - that is, a positive > > validation would be over existing data, and a negative validation would be > > over nonexistant data. > > Correct. The validation of RR data is via the SIG. But if you have a > SIG that is outside the NXT chain then an attacker could just not send > it to you and you'd not know it was missing. True. 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 Apr 11 14:29:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08809 for ; Thu, 11 Apr 2002 14:29:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vj12-0002uF-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 11:09:48 -0700 Received: from outpost.ds9a.nl ([213.244.168.210] helo=outpost.powerdns.com) by psg.com with esmtp (Exim 3.35 #1) id 16vj10-0002u9-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 11:09:47 -0700 Received: by outpost.powerdns.com (Postfix, from userid 1000) id 40E38C6744; Thu, 11 Apr 2002 20:09:36 +0200 (CEST) Date: Thu, 11 Apr 2002 20:09:36 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: ZXFR specification? Message-ID: <20020411200936.A4696@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I was trying to find out more about ZXFR but I can't find anything. Is there more specification than the bind source? Thanks for your time. Regards, bert -- 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 Apr 11 14:57:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09519 for ; Thu, 11 Apr 2002 14:57:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vjZZ-0003ZA-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 11:45:29 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.35 #1) id 16vjZY-0003Z4-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 11:45:28 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id CAAED28E3B for ; Thu, 11 Apr 2002 11:45:27 -0700 (PDT) (envelope-from paul@vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: ZXFR specification? In-Reply-To: Message from bert hubert of "Thu, 11 Apr 2002 20:09:36 +0200." <20020411200936.A4696@outpost.ds9a.nl> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.1 Date: Thu, 11 Apr 2002 11:45:27 -0700 Message-Id: <20020411184527.CAAED28E3B@as.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I was trying to find out more about ZXFR but I can't find anything. Is there > more specification than the bind source? zxfr was a crude hack that doesn't work and isn't standard and will never be. (it predates edns, for one thing; today we'd make compression a negotiable fact about a transfer. in fact, today we'd make incremental differences a negotiable fact about a transfer.) -- 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 Apr 11 16:21:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12743 for ; Thu, 11 Apr 2002 16:21:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vkqY-00055F-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 13:07:06 -0700 Received: from porter.east.isi.edu ([65.114.168.20] helo=east.east.isi.edu) by psg.com with esmtp (Exim 3.35 #1) id 16vkqX-000559-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 13:07:06 -0700 Received: from isi.edu (wireless82.east.isi.edu [65.114.168.82]) by east.east.isi.edu (8.11.3/8.11.3) with ESMTP id g3BK74s19184; Thu, 11 Apr 2002 16:07:04 -0400 (EDT) Message-ID: <3CB5ED92.DA359204@isi.edu> Date: Thu, 11 Apr 2002 16:09:54 -0400 From: Daniel Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call References: <20020403112549.6693629d.olaf@ripe.net> <20020403152418.V2582-100000@node10c4d.a2000.nl> <20020403195935.436D41BB2@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > > Do we have a worked example of opt-in applied to a zone that's more > than one label deep? This seems like the place where weakening of the > "secure zone" model is most likely to make life confusing for the > resolver. > > Apologies if this has already been discussed and I missed it, but I > saw no such example on a quick re-read of the draft. > We just encountered a similar thing in our work and I was scanning for answers, but didn't see anything posted to the list.... In particular, we're looking at what happens if a resolver gets: www.foo.bar.nge.isi.edu A 1.2.3.4 a.nge.isi.edu NXT c.nge.isi.edu SIG(NXT) by nge.isi.edu. I don't think this is a possible response under regular NXT or Opt-In delegation only. But with unrestricted Opt-In, the following nge.isi.edu zone file would produce that response: a.nge.isi.edu. A ..., SIG, NXT-OPT c.nge.isi.edu, SIG(NXT-OPT) www.foo.bar.nge.isi.edu. A d.nge.isi.edu. A ..., SIG, NXT-OPT ..., SIG(NXT-OPT) My question is whether this is a bad thing?? In the example, the resolver can not distinguish between the case where 1) www.foo.bar.nge.isi.edu is in the nge.isi.edu zone file and the case where 2) nge.isi.edu zone file has an NS record for bar.nge.isi.edu but this child did not list a DS record. In the first case, the NXT applies to nge.isi.edu's authoritative data and says nge chose not to sign this name. In the second case, the NXT from nge.isi.edu just proves some the child zone is not providing a DS record. But in both cases, no chain of trust leads from nge.isi.edu to www.foo.bar.nge.isi.edu so should I care if it case 1 or case 2? Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 11 16:57:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14804 for ; Thu, 11 Apr 2002 16:57:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vlUx-0005qi-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 13:48:51 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.35 #1) id 16vlUw-0005qc-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 13:48:50 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 11 Apr 2002 20:48:50 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 16:48:37 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002041116483732599 ; Thu, 11 Apr 2002 16:48:37 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Apr 2002 16:49:22 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> From: "Loomis, Rip" To: "'Edward Lewis'" Cc: "'Scott Rose'" , namedroppers@ops.ietf.org Subject: RE: zone naming terms (*and* Opt-in wg last call) Date: Thu, 11 Apr 2002 16:48:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I guess I just never liked the usage of the term "secure" to describe things in RFC XXXX (and subsequent), and now that we're changing the model significantly I'd love to clean up the terminology. (Up 'til now, I've used the non-standard terminology "DNSSEC signed zones" instead.) Security is *always* a continuum, but labeling a zone as "secure" during the time between a key compromise and the key supersession seems a little...odd. > What is needed is a term that captures: > > "...means that the resolver should expect to get a > signature with this data set. Failing to do so means > that the data set in hand is to be disposed of and > every effort made to retrieve a new one." I'm not sure why--can you give a specific example of why we need such a term (and to whom might it be useful?) In the opt-in New World Order, it seems that every data set has to be handled on a case-by-case basis in most situations. The best phrases I could use to describe the above situation are "possibly signed" or "signature expected" and I'm not sure either has enough semantic content to be useful. As an off-topic tangent, or possibly on-topic for the original topic above: For the record, I still disagree with opt-in since I don't agree that objections previously stated were "moral" in nature. IMHO, adding granularity of security within a zone makes it more difficult to describe and understand security, and therefore makes it more difficult to maintain--and that's a technical problem not a moral one. Have any of the people advocating Opt-In ever tried to explain *basic* DNSSEC to a *basic* DNS administrator? I have, and it's not pretty. Opt-in adds another layer of complexity. I fear complexity. More importantly: We're changing the goal of DNSSEC from what was clearly stated in the past--providing a method so that *all* DNS data could be clearly verified. I can believe that for large zones that primarily consist of delegations, Opt-in is useful and perhaps financially necessary. I *don't* like the "full opt-in" that seems to now be the sense of the WG, because it makes it *less* likely that every node in DNS will ever be signed. I'm normally a libertarian, but as a security weenie I want to force DNSSEC to be available. I don't want security to only be applied to a small subset of DNS data but I think that's where we're heading. I think that ship has already sailed though, along with AAAA -vs- A6. -- 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 Thu Apr 11 17:11:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15126 for ; Thu, 11 Apr 2002 17:11:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vlfy-00066C-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 14:00:14 -0700 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16vlfw-00065y-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 14:00:12 -0700 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g3BL06o49795; Thu, 11 Apr 2002 23:00:06 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Thu, 11 Apr 2002 23:00:06 +0200 (CEST) From: Mats Dufberg To: Daniel Massey cc: Subject: Re: Opt-in wg last call In-Reply-To: <3CB5ED92.DA359204@isi.edu> Message-ID: <20020411225309.H7955-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Apr 11, 2002, 16:09 (-0400) Daniel Massey wrote: > In particular, we're looking at what happens if a resolver gets: > > www.foo.bar.nge.isi.edu A 1.2.3.4 > a.nge.isi.edu NXT c.nge.isi.edu > SIG(NXT) by nge.isi.edu. > > I don't think this is a possible response under regular NXT > or Opt-In delegation only. But with unrestricted Opt-In, the > following nge.isi.edu zone file would produce that response: > > a.nge.isi.edu. A ..., SIG, NXT-OPT c.nge.isi.edu, SIG(NXT-OPT) > www.foo.bar.nge.isi.edu. A > d.nge.isi.edu. A ..., SIG, NXT-OPT ..., SIG(NXT-OPT) > > > My question is whether this is a bad thing?? In the example, > the resolver can not distinguish between the case where > 1) www.foo.bar.nge.isi.edu is in the nge.isi.edu zone file > and the case where > 2) nge.isi.edu zone file has an NS record for bar.nge.isi.edu but > this child did not list a DS record. > > In the first case, the NXT applies to nge.isi.edu's authoritative > data and says nge chose not to sign this name. In the second case, > the NXT from nge.isi.edu just proves some the child zone is not > providing a DS record. > > But in both cases, no chain of trust leads from nge.isi.edu to > www.foo.bar.nge.isi.edu so should I care if it case 1 or case 2? I do not think you should care. In both cases the name www.foo.bar.nge.isi.edu is unsigned, and unsecured. In regular DNS you do not care which zone www.foo.bar.nge.isi.edu belongs to, you just use its data. Data from a node to which we have no chain of trust (and no broken ditto) should be taken as regular DNS. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- 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 Apr 11 17:12:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15149 for ; Thu, 11 Apr 2002 17:12:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vlhV-00068z-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 14:01:49 -0700 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.35 #1) id 16vlhU-00068s-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 14:01:49 -0700 Received: from randy by roam.psg.com with local (Exim 4.00) id 16vTnF-0002Sl-00; Thu, 11 Apr 2002 03:54:33 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Peter Ford" Cc: namedroppers@ops.ietf.org Subject: RE: Opt-in wg last call References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> Message-Id: Date: Thu, 11 Apr 2002 03:54:33 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In place of "fully secure zone" and "partially secure zone" how about: > "secure full zone" and "secure partial zone". (or perhaps "secure > optional zone") > > The phrase "partially secure" just does not sound quite right. perhaps it does not. but, as it precisely describes the situation, perhaps your qualms about the phrasing are misplaced. 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 Thu Apr 11 17:24:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15348 for ; Thu, 11 Apr 2002 17:24:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vlv7-0006SQ-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 14:15:53 -0700 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16vlv6-0006S3-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 14:15:52 -0700 Received: by sentry.gw.tislabs.com; id RAA09379; Thu, 11 Apr 2002 17:21:38 -0400 (EDT) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xmab09319; Thu, 11 Apr 02 17:21:16 -0400 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Apr 2002 17:16:00 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: the topic change RE: ... Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:48 PM -0400 4/11/02, Loomis, Rip wrote: > >Have any of the people advocating Opt-In ever tried to >explain *basic* DNSSEC to a *basic* DNS administrator? >I have, and it's not pretty. Opt-in adds another layer >of complexity. I fear complexity. Opt-In began as an optimization to ease the adoption of DNSSEC into large zones. By their very nature, optimizations are complications. So I think I am seeing the same dilemma that Rip mentions. I like what opt-in does, becuase it does some optimization - making the workload in transitioning from unsigned to signed to be intuitively incremental. But as we delve into the details, the complexity introduced is rapidly becoming evident. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Last day is Wednesday, April 24, 2002... Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 11 17:26:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15402 for ; Thu, 11 Apr 2002 17:26:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vlv7-0006SR-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 14:15:53 -0700 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16vlv6-0006S2-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 14:15:52 -0700 Received: by sentry.gw.tislabs.com; id RAA09370; Thu, 11 Apr 2002 17:21:37 -0400 (EDT) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xmaa09319; Thu, 11 Apr 02 17:21:15 -0400 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Apr 2002 17:16:16 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: RE: zone naming terms (*and* Opt-in wg last call) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:48 PM -0400 4/11/02, Loomis, Rip wrote: >> What is needed is a term that captures: >> >> "...means that the resolver should expect to get a >> signature with this data set. Failing to do so means >> that the data set in hand is to be disposed of and >> every effort made to retrieve a new one." > >I'm not sure why--can you give a specific example of >why we need such a term (and to whom might it be useful?) Given that there are non-DNSSEC aware caches in existence and that DNSSEC does not provide message integrity, it is possible that an answer might contain an RRset but not its associated signature. (I'm assuming there is an associated signature.) In this instance, the resolver should a) reject the unsigned answer, b) request the SIGs at the name, or c) restart the query to avoid the cache in question. Whether a, b, or c is chosen is up to the implementation's requirement for robustness and whether c is even possible (think firewall). Whether or not the resolver gets a signature with the data, the resolver needs to know whether one is expected. If a sig arrives and none is expected, the sig may be ignored. If one arrives and one is to be expected, then the resolver is happy. If no sig arrives, the resolver needs to know whether or not one is to be expected. This "concept" isn't about whether the data is secure, but rather what the resolver should expect to be processing. >In the opt-in New World Order, it seems that every data set >has to be handled on a case-by-case basis in most situations. That has always been the case, but in the Old World Order, the status of a piece of data was the same as anything else in the zone - so I got lazy and just assigned the term to the whole zone. >The best phrases I could use to describe the above >situation are "possibly signed" or "signature expected" >and I'm not sure either has enough semantic content to >be useful. That's on the right track. It's about what the resolver should expect to see. It's not about the validity of the data. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Last day is Wednesday, April 24, 2002... Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 11 17:38:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16007 for ; Thu, 11 Apr 2002 17:38:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vm91-0006qE-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 14:30:15 -0700 Received: from padda.telia.net ([195.198.164.130]) by psg.com with esmtp (Exim 3.35 #1) id 16vm8z-0006po-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 14:30:13 -0700 Received: from localhost (dufberg@localhost) by padda.telia.net (8.11.6/8.11.6) with ESMTP id g3BLU9S49833; Thu, 11 Apr 2002 23:30:09 +0200 (CEST) (envelope-from dufberg@telia.net) X-Authentication-Warning: padda.telia.net: dufberg owned process doing -bs Date: Thu, 11 Apr 2002 23:30:09 +0200 (CEST) From: Mats Dufberg To: "Loomis, Rip" cc: Subject: RE: zone naming terms (*and* Opt-in wg last call) In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> Message-ID: <20020411232217.Q7955-100000@padda.telia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Apr 11, 2002, 16:48 (-0400) Loomis, Rip wrote: > More importantly: We're changing the goal of > DNSSEC from what was clearly stated in the past--providing > a method so that *all* DNS data could be clearly verified. > I can believe that for large zones that primarily consist > of delegations, Opt-in is useful and perhaps financially > necessary. I *don't* like the "full opt-in" that seems to > now be the sense of the WG, because it makes it *less* likely > that every node in DNS will ever be signed. I think that we all agree on the goal, but not on the road to get there. I think it is unlikely that we will get all nodes signed until DNSsec is mandatory (and maybe not even then), but think it is *more* likely that DNSsec will roll out in some quantity if opt-in is accepted. And in ten years time we will have a larger percentage of all nodes signed with opt-in, than without. > I'm normally a libertarian, but as a security weenie I want > to force DNSSEC to be available. I don't want security to > only be applied to a small subset of DNS data (...) Neither do I, but even without opt-in that will happen. If you do not want to sign all the host names of your office work stations you can just move those to a subzone, and let that be unsigned. Mats ---------------------------------------------------------------------- Mats Dufberg Registry TeliaNet dufberg@telia.net Skanova/AO Networks +46 8 456 7274 Box 10707 +46 70 258 2588 SE-121 29 Stockholm ---------------------------------------------------------------------- -- 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 Apr 11 18:42:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17970 for ; Thu, 11 Apr 2002 18:42:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vmv3-0007u5-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 15:19:53 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.35 #1) id 16vmv2-0007tz-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 15:19:52 -0700 Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 31A5B3190D for ; Thu, 11 Apr 2002 15:19:51 -0700 (PDT) Date: Fri, 12 Apr 2002 00:30:46 +0200 (CEST) From: Roy Arends X-X-Sender: To: Subject: Re: the topic change RE: ... In-Reply-To: Message-ID: <20020411234448.T23681-100000@node10c4d.a2000.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 11 Apr 2002, Edward Lewis wrote: > At 4:48 PM -0400 4/11/02, Loomis, Rip wrote: > > > >Have any of the people advocating Opt-In ever tried to > >explain *basic* DNSSEC to a *basic* DNS administrator? > >I have, and it's not pretty. Opt-in adds another layer > >of complexity. I fear complexity. You can explain it as complex as you desire, you govern your own fear. I have explained DNSSEC to several folk with different cluefullness, in the end, opt-in is the easy explanation. > Opt-In began as an optimization to ease the adoption of DNSSEC into large > zones. By their very nature, optimizations are complications. So I think > I am seeing the same dilemma that Rip mentions. I like what opt-in does, > becuase it does some optimization - making the workload in transitioning > from unsigned to signed to be intuitively incremental. But as we delve > into the details, the complexity introduced is rapidly becoming evident. I completely disagree. Opt-In is not an optimization nor a complication. 2535 was too anal to begin with. Opt-In re-focussed the whole "denial" discussion. I strongly disagree with folk who claim "authenticated denial" is the same as "authenticated denial of unsigned material". I still believe strongly in the fact that "authenticated denial of unsigned material" is useless and a total waste of your and my resources, no matter how much you think how little the extra cost to do so might be. You may call that an optimization. I call it a better focussed design spec. There is no way that 2535 will be adopted within the whole tree. Without opt-in, DNS admins will use the ol' pandora's box to achieve the same goal. Delegate unsigned material out of a secured zone. That is what happens already with unsigned delegations. Now _that_ is a big rope. The complexity introduced recently ("encapsulated NXT") is a non-issue. A NXT chain is a chain that covers all signed names in a zone, regardless of opt-in or 2535. This has not changed. If there exist some SIG in the zone, there must be an associated NXT. If there is not, this is simply a protocol violation, just as CNAME and other data. I still see restricted opt-in or no opt-in arguments as _strictly moral_, they bear no technical matter whatso-ever. The rope might be viewed as somewhat longer as it used to, but in a few years, it will simply be a rope. 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 Fri Apr 12 00:51:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20272 for ; Fri, 12 Apr 2002 00:51:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vsnW-000ERY-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 21:36:30 -0700 Received: from roam.psg.com ([147.28.0.10]) by psg.com with esmtp (Exim 3.35 #1) id 16vsnV-000ERE-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 21:36:29 -0700 Received: from randy by roam.psg.com with local (Exim 4.00) id 16vrqw-0004wd-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 20:35:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CB46DBF.4090300@digisle.com> References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> Date: Wed, 10 Apr 2002 09:52:15 -0700 From: "Andy W. Barclay" To: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] Hi, I don't like the the term "secure partial zone". It seems to imply that this zone is incomplete. I agree that partially secure zone sounds a little funky, but I can't think of something better without being wordy. Peter Ford wrote: > In place of "fully secure zone" and "partially secure zone" how about: > "secure full zone" and "secure partial zone". (or perhaps "secure > optional zone") > > The phrase "partially secure" just does not sound quite right. > > Regards, peterf -- Regards, Andy W. Barclay. abarclay@digisle.com fax (415) 738 7271 Always a UNIX Evangelist (and sometimes a system and network architect) Beware the Jabberwock, my son! The jaws that bite, the claws that catch! -- 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 Apr 12 01:31:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24832 for ; Fri, 12 Apr 2002 01:31:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vta7-000FNI-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 22:26:43 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16vta6-000FNB-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 22:26:42 -0700 Received: from randy by rip.psg.com with local (Exim 4.00) id 16vta6-000Izr-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 22:26:42 -0700 References: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> ("Loomis, Rip"'s message of "Thu, 11 Apr 2002 16:48:52 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: namedroppers@ops.ietf.org Subject: Re: zone naming terms (*and* Opt-in wg last call) From: David Blacka Date: Thu, 11 Apr 2002 18:34:50 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber ] >>>>> "Rip" == Rip Loomis writes: Rip> As an off-topic tangent, or possibly on-topic for the original Rip> topic above: For the record, I still disagree with opt-in since Rip> I don't agree that objections previously stated were "moral" in Rip> nature. IMHO, adding granularity of security within a zone Rip> makes it more difficult to describe and understand security, and Rip> therefore makes it more difficult to maintain--and that's a Rip> technical problem not a moral one. We do not know how much harder DNSSEC with opt-in is to explain. Everyone here is coming from a position of being comfortable with 2535, so opt-in seems like a lot of additional complexity. If you were taught DNSSEC with opt-in initially, it might not seem like a big deal. Rip> Have any of the people advocating Opt-In ever tried to explain Rip> *basic* DNSSEC to a *basic* DNS administrator? I have, and it's Rip> not pretty. Opt-in adds another layer of complexity. I fear Rip> complexity. I will agree the DNSSEC is hard to describe to the layman. I have tried and found it difficult. I have not found opt-in significantly more difficult to explain, however. It could be argued that all your basic DNS administrator really needs to know about opt-in is not to use it. Rip> More importantly: We're changing the goal of DNSSEC from what Rip> was clearly stated in the past--providing a method so that *all* Rip> DNS data could be clearly verified. I can believe that for Rip> large zones that primarily consist of delegations, Opt-in is Rip> useful and perhaps financially necessary. I *don't* like the Rip> "full opt-in" that seems to now be the sense of the WG, because Rip> it makes it *less* likely that every node in DNS will ever be Rip> signed. IMO, it was never likely that every node in DNS would be signed. To do that, you would have to make DNSSEC mandatory. However, if, in the distant future, we should wish to make DNSSEC mandatory, opt-in does not make it any harder. Also, opt-in also could be used to solve other tricky problems that DNSSEC poses, like record synthesis or wildcards. -- 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 Fri Apr 12 01:31:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24847 for ; Fri, 12 Apr 2002 01:31:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vtZa-000FMK-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 22:26:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16vtZa-000FME-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 22:26:10 -0700 Received: from randy by rip.psg.com with local (Exim 4.00) id 16vtZZ-000Iyz-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 22:26:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20020403112549.6693629d.olaf@ripe.net> <20020403152418.V2582-100000@node10c4d.a2000.nl> <20020403195935.436D41BB2@thrintun.hactrn.net> <3CB5ED92.DA359204@isi.edu> In-Reply-To: <3CB5ED92.DA359204@isi.edu> (Daniel Massey's message of "Thu, 11 Apr 2002 16:09:54 -0400") Message-ID: To: Daniel Massey Cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call From: David Blacka Date: Thu, 11 Apr 2002 17:41:54 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber ] >>>>> "Daniel" == Daniel Massey writes: Daniel> In particular, we're looking at what happens if a resolver gets: Daniel> www.foo.bar.nge.isi.edu A 1.2.3.4 Daniel> a.nge.isi.edu NXT c.nge.isi.edu Daniel> SIG(NXT) by nge.isi.edu. This response looks totally fine to a opt-in aware verifier: the NXT record proves that www.foo.bar.nge.isi.edu is not supposed to be signed, and it isn't. It doesn't matter that "www", "foo", or "bar" are or are not delegation points. Daniel> In the first case, the NXT applies to nge.isi.edu's Daniel> authoritative data and says nge chose not to sign this name. Daniel> In the second case, the NXT from nge.isi.edu just proves some Daniel> the child zone is not providing a DS record. Daniel> But in both cases, no chain of trust leads from nge.isi.edu Daniel> to www.foo.bar.nge.isi.edu so should I care if it case 1 or Daniel> case 2? No. -- 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 Fri Apr 12 01:39:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20274 for ; Fri, 12 Apr 2002 00:51:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vsnV-000ERF-00 for namedroppers-data@psg.com; Thu, 11 Apr 2002 21:36:29 -0700 Received: from roam.psg.com ([147.28.0.10]) by psg.com with esmtp (Exim 3.35 #1) id 16vsnU-000ER1-00 for namedroppers@ops.ietf.org; Thu, 11 Apr 2002 21:36:28 -0700 Received: from randy by roam.psg.com with local (Exim 4.00) id 16vrvj-0004x3-00; Thu, 11 Apr 2002 20:40:55 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Loomis, Rip" Cc: "'Scott Rose'" , Edward Lewis , namedroppers@ops.ietf.org Subject: RE: zone naming terms (was Opt-in wg last call) References: <3C1E3607B37295439F7C409EFBA08E680E29F6@COL-581-EXS01> Message-Id: Date: Thu, 11 Apr 2002 20:40:55 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > "Signed RR set" (or "signed set") > "Unsigned RR set" (or "unsigned set") RRsets are not what is signed. whole names, consisting of one or more RRsets are. 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 Fri Apr 12 05:12:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24906 for ; Fri, 12 Apr 2002 05:12:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16vwqD-000HvX-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 01:55:33 -0700 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.35 #1) id 16vwqC-000HvR-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 01:55:32 -0700 Received: from x50 (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.11.6/8.11.6) with SMTP id g3C8tTu15008; Fri, 12 Apr 2002 10:55:29 +0200 Date: Fri, 12 Apr 2002 10:55:29 +0200 From: "Olaf M. Kolkman" To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: the topic change RE: ... Message-Id: <20020412105529.5a684375.olaf@ripe.net> In-Reply-To: <20020411234448.T23681-100000@node10c4d.a2000.nl> References: <20020411234448.T23681-100000@node10c4d.a2000.nl> Organization: RIPE NCC X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 12 Apr 2002 00:30:46 +0200 (CEST) Roy Arends wrote: > Opt-In is not an optimization nor a complication. 2535 was too anal to > begin with. Opt-In re-focussed the whole "denial" discussion. I strongly > disagree with folk who claim "authenticated denial" is the same as > "authenticated denial of unsigned material". I still believe strongly in > the fact that "authenticated denial of unsigned material" is useless and > a total waste of your and my resources, no matter how much you think how > little the extra cost to do so might be. You may call that an > optimization. I call it a better focussed design spec. You get me confused again :-) What is the difference between 'authenticated denial of unsigned material' and the 'authenticated denial'? Material that does not exist is by nature unsigned. If unsigned material appears where it is supposed to not exist there is 'a problem'. Authenticated denial of existence is a requirement in a lot of zones. e.g. in the in-addr tree you would like to have authentication on the fact that some delegations do not exist (allocations that have not been made). A number of registries in the forward zones have strict regulations on names that can be registered. For those registries authenticated denial of existence of unregistered names may be a requirement as well. > The complexity introduced recently ("encapsulated NXT") is a non-issue. Ceci n'est pas un pipe. > A NXT chain is a chain that covers all signed names in a zone, regardless of > opt-in or 2535. This has not changed. If there exist some SIG in the zone, > there must be an associated NXT. If there is not, this is simply a > protocol violation, just as CNAME and other data. One suggested clarification, so that it is clear we have a protocol error and encapulated NXTs are forbidden. Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records and RFC 2535 NXT records. At each secure node, the NXT record within that node MUST either be RFC 2535 or Opt-In compliant. If it is not Opt-In, there MUST NOT be any insecure nodes between it and the next node. Remove ambiguity from last line: If it is not Opt-In, there MUST NOT be any insecure nodes between it and the node indicated by the 'next domain name' in the NXT rdata. And add: If it is OPT-IN, there MUST NOT be any signed nodes between it and the next node indicated by the 'next domain name' in the NXT rdata. --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 Fri Apr 12 09:51:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24764 for ; Fri, 12 Apr 2002 09:51:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w1G3-000L7L-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 06:38:31 -0700 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16w1G3-000L7E-00; Fri, 12 Apr 2002 06:38:31 -0700 Received: by sentry.gw.tislabs.com; id JAA20014; Fri, 12 Apr 2002 09:44:16 -0400 (EDT) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma020001; Fri, 12 Apr 02 09:43:48 -0400 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: References: <3C1E3607B37295439F7C409EFBA08E680E29F6@COL-581-EXS01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Apr 2002 09:37:16 -0400 To: Randy Bush From: Edward Lewis Subject: RE: zone naming terms (was Opt-in wg last call) Cc: "Loomis, Rip" , "'Scott Rose'" , Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:40 PM -0400 4/11/02, Randy Bush wrote: >> "Signed RR set" (or "signed set") >> "Unsigned RR set" (or "unsigned set") > >RRsets are not what is signed. whole names, consisting of one or more >RRsets are. > >randy Right - when considering opt-in. However, the resolver is more concerned about set-by-set signage. I can see where why there is a desire for terms defining the server-side, mostly for explaning the concepts and the configuration. I've been thinking of terms to define the resolution process. Although the client-server pair is tied together by a protocol, often times the terms differ because of the system point of view. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Last day is Wednesday, April 24, 2002... Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 12 10:47:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01781 for ; Fri, 12 Apr 2002 10:47:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w2AW-000M04-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 07:36:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16w2AV-000Lzq-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 07:36:51 -0700 Received: from randy by rip.psg.com with local (Exim 4.00) id 16w2AV-0008VE-00; Fri, 12 Apr 2002 07:36:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: the topic change RE: ... References: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> Message-Id: Date: Fri, 12 Apr 2002 07:36:51 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Opt-In began as an optimization to ease the adoption of DNSSEC into large > zones. let's be clear. it bagean as a hack to make a partially signed COM zone smaller. some folk are leery of the complexity and the change in the signing model. others like the change in signing granularity. we have on the table a compromise, to allow the change in granularity, but restricted to delegation points. > If you feel that you can not live with this compromise, then and > only then, please explain why to the list. 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 Fri Apr 12 11:18:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04988 for ; Fri, 12 Apr 2002 11:18:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w2fN-000McK-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 08:08:45 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.35 #1) id 16w2fM-000McE-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 08:08:44 -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 LAA09279; Fri, 12 Apr 2002 11:08:42 -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 LAA29004; Fri, 12 Apr 2002 11:06:40 -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 KAA15673; Fri, 12 Apr 2002 10:49:31 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA28096; Fri, 12 Apr 2002 10:49:31 -0400 (EDT) To: David Blacka Cc: namedroppers@ops.ietf.org Subject: Re: zone naming terms (*and* Opt-in wg last call) References: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> From: Derek Atkins Date: 12 Apr 2002 10:49:31 -0400 In-Reply-To: Message-ID: Lines: 61 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka writes: > I will agree the DNSSEC is hard to describe to the layman. I have > tried and found it difficult. I have not found opt-in significantly > more difficult to explain, however. > > It could be argued that all your basic DNS administrator really needs > to know about opt-in is not to use it. If this is the case, then why make it available to them? My fear of opt-in is that it adds complexity to the protocol, it adds complexity to the resolver, it adds complexity to the server, it adds complexity to the administrator, and IMHO buys little. I'm _NOT_ afraid of an administrator making a subzone and not signing data within that subzone. If an administrator REALLY REALLY REALLY wants to keep some of their data unsigned, fine, but I don't want to make it easy. Opt-in certainly doesn't keep you from this loophole, either, it just makes it easier for an administrator to shoot themselves in the foot. > IMO, it was never likely that every node in DNS would be signed. To > do that, you would have to make DNSSEC mandatory. However, if, in the > distant future, we should wish to make DNSSEC mandatory, opt-in does > not make it any harder. While I would _like_ to see all of DNS signed, I certainly don't expect that will ever happen. I certainly don't expect sexxxxx.com to ever be signed. (Perhaps I'm missing the market? ;) I agree that opt-in helps .com and other large delegation-only zones. I DO NOT agree that opt-in helps the average zone administrator, nor do I believe that it SHOULD be available to the average user. > Also, opt-in also could be used to solve other tricky problems that > DNSSEC poses, like record synthesis or wildcards. I worked with Roy in Minneapolis to try to understand this problem, and what I came away from this was it only really helps if you have a zone with large number of subparts. For example, if a domain foo.com has entries like: a.b.c.d.foo.com. then wildcards become an issue issue due to the lack of delegation points. I agree that synthesis is a problem, but I also feel synthesis is a bad idea unless it is done by a "trusted" server. If there is a TSIG key between a resolver and its trusted nameserver, then that trusted nameserver can perform the request, verification, and synthesis on behalf of the resolver. So I think that synthesis is a red herring. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 12 11:19:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05080 for ; Fri, 12 Apr 2002 11:19:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w2a5-000MVD-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 08:03:17 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16w2a4-000MV6-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 08:03:16 -0700 Received: from randy by rip.psg.com with local (Exim 4.00) id 16w2a4-0009GM-00; Fri, 12 Apr 2002 08:03:16 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Andy W. Barclay" Cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB46DBF.4090300@digisle.com> Message-Id: Date: Fri, 12 Apr 2002 08:03:16 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I don't like the the term "secure partial zone". It seems to imply > that this zone is incomplete. how about "partially signed zone?" 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 Fri Apr 12 11:31:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06168 for ; Fri, 12 Apr 2002 11:31:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w2uV-000Mvy-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 08:24:23 -0700 Received: from h236.s231.netsol.com ([216.168.231.236]) by psg.com with esmtp (Exim 3.35 #1) id 16w2uU-000Mvs-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 08:24:22 -0700 Received: (from markk@localhost) by h236.s231.netsol.com (8.11.0/8.11.0) id g3CFOJU11307; Fri, 12 Apr 2002 11:24:19 -0400 (EDT) Date: Fri, 12 Apr 2002 11:24:19 -0400 From: Mark Kosters To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: the topic change RE: ... Message-ID: <20020412152419.GB10756@slam.admin.cto.netsol.com> References: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Apr 11, 2002 at 05:16:00PM -0400, Edward Lewis wrote: > But as we delve > into the details, the complexity introduced is rapidly becoming evident. I'm not sure what the real complexity is - perhaps you can give us some technical details. IMHO, people seem to be getting wrapped around the axel over the difference of secured nodes (opt-in) vs secured zones (2535). As it has been said before the resolver is not zone-aware. Based off of this, the resolver changes to BIND were not too complex. I think it took Nominum one man month to do this with a developer who never had worked on the BIND code base before. Mark -- Mark Kosters markk@netsol.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 Fri Apr 12 11:43:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07729 for ; Fri, 12 Apr 2002 11:43:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w32z-000N6Q-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 08:33:09 -0700 Received: from h236.s231.netsol.com ([216.168.231.236]) by psg.com with esmtp (Exim 3.35 #1) id 16w32y-000N6I-00; Fri, 12 Apr 2002 08:33:08 -0700 Received: (from markk@localhost) by h236.s231.netsol.com (8.11.0/8.11.0) id g3CFX6g11408; Fri, 12 Apr 2002 11:33:06 -0400 (EDT) Date: Fri, 12 Apr 2002 11:33:06 -0400 From: Mark Kosters To: Randy Bush Cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call Message-ID: <20020412153306.GD10756@slam.admin.cto.netsol.com> References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB46DBF.4090300@digisle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Apr 12, 2002 at 08:03:16AM -0700, Randy Bush wrote: > > I don't like the the term "secure partial zone". It seems to imply > > that this zone is incomplete. > > how about "partially signed zone?" That is fine. Another may be: opt-in -> "secured-node zone" non-opt-in -> "secure zone" Mark -- Mark Kosters markk@netsol.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 Fri Apr 12 11:55:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09750 for ; Fri, 12 Apr 2002 11:55:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w3FA-000NN3-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 08:45:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16w3FA-000NMx-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 08:45:44 -0700 Received: from randy by rip.psg.com with local (Exim 4.00) id 16w3F2-000ATT-00; Fri, 12 Apr 2002 08:45:36 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Edward Lewis Cc: "Loomis, Rip" , "'Scott Rose'" , namedroppers@ops.ietf.org Subject: RE: zone naming terms (was Opt-in wg last call) References: <3C1E3607B37295439F7C409EFBA08E680E29F6@COL-581-EXS01> Message-Id: Date: Fri, 12 Apr 2002 08:45:36 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> "Signed RR set" (or "signed set") >>> "Unsigned RR set" (or "unsigned set") >> RRsets are not what is signed. whole names, consisting of one or more >> RRsets are. > Right - when considering opt-in. However, the resolver is more concerned > about set-by-set signage. we were discussing english descriptions of the security semantics, not some particular code. 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 Fri Apr 12 12:14:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12863 for ; Fri, 12 Apr 2002 12:14:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w3XU-000Nkf-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 09:04:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.35 #1) id 16w3XT-000NkY-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 09:04:39 -0700 Received: from randy by rip.psg.com with local (Exim 4.00) id 16w3XT-000B1x-00; Fri, 12 Apr 2002 09:04:39 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark Kosters Cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB46DBF.4090300@digisle.com> <20020412153306.GD10756@slam.admin.cto.netsol.com> Message-Id: Date: Fri, 12 Apr 2002 09:04:39 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> how about "partially signed zone?" > That is fine. Another may be: > opt-in -> "secured-node zone" > non-opt-in -> "secure zone" how can i tell the difference between the two? and i like someone's differentiation between 'signed' and 'secured'. i.e. we can only sign, not assert security. 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 Fri Apr 12 13:11:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20753 for ; Fri, 12 Apr 2002 13:11:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w4Rs-000OjS-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 10:02:56 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.35 #1) id 16w4Rr-000OjM-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 10:02:55 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id AD2791C30 for ; Fri, 12 Apr 2002 13:02:54 -0400 (EDT) Date: Fri, 12 Apr 2002 13:02:54 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call In-Reply-To: References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB46DBF.4090300@digisle.com> <20020412153306.GD10756@slam.admin.cto.netsol.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020412170254.AD2791C30@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I also prefer the "signed" terminology to the "secured" terminology. -- 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 Apr 12 13:15:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21228 for ; Fri, 12 Apr 2002 13:15:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w4Ud-000Oms-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 10:05:47 -0700 Received: from h236.s231.netsol.com ([216.168.231.236]) by psg.com with esmtp (Exim 3.35 #1) id 16w4Uc-000Omm-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 10:05:46 -0700 Received: (from markk@localhost) by h236.s231.netsol.com (8.11.0/8.11.0) id g3CH5h211799; Fri, 12 Apr 2002 13:05:43 -0400 (EDT) Date: Fri, 12 Apr 2002 13:05:43 -0400 From: Mark Kosters To: Derek Atkins Cc: namedroppers@ops.ietf.org Subject: Re: zone naming terms (*and* Opt-in wg last call) Message-ID: <20020412170543.GE10756@slam.admin.cto.netsol.com> References: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Apr 12, 2002 at 10:49:31AM -0400, Derek Atkins wrote: > I'm _NOT_ afraid of an administrator making a subzone and not signing > data within that subzone. If an administrator REALLY REALLY REALLY > wants to keep some of their data unsigned, fine, but I don't want to > make it easy. Opt-in certainly doesn't keep you from this loophole, > either, it just makes it easier for an administrator to shoot > themselves in the foot. I see this as a tools issue. If the tools are good, then the administrator should not have a problem. With that in mind, I could imagine the same thing be said about dnssec in general if sigs and keys were to be calculated by hand and placed in the zone with vi. > > IMO, it was never likely that every node in DNS would be signed. To > > do that, you would have to make DNSSEC mandatory. However, if, in the > > distant future, we should wish to make DNSSEC mandatory, opt-in does > > not make it any harder. > > While I would _like_ to see all of DNS signed, I certainly don't > expect that will ever happen. I certainly don't expect sexxxxx.com > to ever be signed. (Perhaps I'm missing the market? ;) I agree. > I agree that opt-in helps .com and other large delegation-only zones. > I DO NOT agree that opt-in helps the average zone administrator, nor > do I believe that it SHOULD be available to the average user. Moral argument here that always seems to creep up. On the flip side, why can't an administrator have a choice of what they want to have secured and not secured in-zone? Mark -- Mark Kosters markk@netsol.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 Fri Apr 12 13:25:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22762 for ; Fri, 12 Apr 2002 13:25:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w4d7-000Oxv-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 10:14:33 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.35 #1) id 16w4d6-000Oxp-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 10:14:32 -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 NAA07753; Fri, 12 Apr 2002 13:14:31 -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 NAA25475; Fri, 12 Apr 2002 13:14:30 -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 NAA06670; Fri, 12 Apr 2002 13:14:30 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id NAA06972; Fri, 12 Apr 2002 13:14:30 -0400 (EDT) To: Mark Kosters Cc: namedroppers@ops.ietf.org Subject: Re: zone naming terms (*and* Opt-in wg last call) References: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> <20020412170543.GE10756@slam.admin.cto.netsol.com> From: Derek Atkins Date: 12 Apr 2002 13:14:30 -0400 In-Reply-To: <20020412170543.GE10756@slam.admin.cto.netsol.com> 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 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark Kosters writes: > > I agree that opt-in helps .com and other large delegation-only zones. > > I DO NOT agree that opt-in helps the average zone administrator, nor > > do I believe that it SHOULD be available to the average user. > > Moral argument here that always seems to creep up. On the flip side, > why can't an administrator have a choice of what they want to have > secured and not secured in-zone? Contrary to popular belief, security is NOT a science; it is an art. There is no magic security pixie dust that can be sprinkled on a protocol to magically make it secure. Security is also a very pervasive thing -- the fingers of security get into EVERY part of a system. Process and Procedure are JUST as important to maintain a secure system as cryptography. In fact, I would argue that cryptography is the LEAST important issue, and easiest one to solve. The problem I see with this working group is that many people are unwilling to accept process and procedural security requirements, call them "moral arguments" and dismiss them out of hand. Would you also like to dismiss buffer overruns as not being important? Clearly telling an implementor how to implement the protocol is a moral argument, too! > Mark -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 12 13:53:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25834 for ; Fri, 12 Apr 2002 13:53:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w55U-000PVr-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 10:43:52 -0700 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.35 #1) id 16w55T-000PVi-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 10:43:51 -0700 Received: by sentry.gw.tislabs.com; id NAA25282; Fri, 12 Apr 2002 13:49:37 -0400 (EDT) Received: from dhcp1.netsec.tislabs.com(199.171.39.21) by sentry.gw.tislabs.com via smap (V5.5) id xma025246; Fri, 12 Apr 02 13:48:45 -0400 X-Sender: lewis@pop.gw.tislabs.com Message-Id: In-Reply-To: <20020412152419.GB10756@slam.admin.cto.netsol.com> References: <3C1E3607B37295439F7C409EFBA08E680E2A06@COL-581-EXS01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Apr 2002 13:42:09 -0400 To: Mark Kosters From: Edward Lewis Subject: Re: the topic change RE: ... Cc: Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The complexity I'm sensing is the all the hub-bub trying to sort out the NXT implications. Perhaps it is the axel wrapping that's the problem, not the code. At 11:24 AM -0400 4/12/02, Mark Kosters wrote: >On Thu, Apr 11, 2002 at 05:16:00PM -0400, Edward Lewis wrote: >> But as we delve >> into the details, the complexity introduced is rapidly becoming evident. > >I'm not sure what the real complexity is - perhaps you can give us some >technical details. IMHO, people seem to be getting wrapped around the axel >over the difference of secured nodes (opt-in) vs secured zones (2535). As it >has been said before the resolver is not zone-aware. Based off of this, >the resolver changes to BIND were not too complex. I think it took Nominum >one man month to do this with a developer who never had worked on the >BIND code base before. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Last day is Wednesday, April 24, 2002... Opinions expressed are property of my evil twin, not my employer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 12 14:13:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28659 for ; Fri, 12 Apr 2002 14:13:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w5Nh-000PqN-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 11:02:41 -0700 Received: from buggs.unixpeople.com ([208.177.135.130] helo=buggs.unixpeople.internal) by psg.com with esmtp (Exim 3.35 #1) id 16w5Ng-000PqH-00; Fri, 12 Apr 2002 11:02:40 -0700 Received: from unixpeople.com (woody [208.177.135.130]) by buggs.unixpeople.internal (8.12.2/8.12.2) with ESMTP id g3CI2UY7023916; Fri, 12 Apr 2002 11:02:30 -0700 (PDT) Message-ID: <3CB72122.3080104@unixpeople.com> Date: Fri, 12 Apr 2002 11:02:10 -0700 From: "Andy W. Barclay" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Mark Kosters CC: Randy Bush , namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB46DBF.4090300@digisle.com> <20020412153306.GD10756@slam.admin.cto.netsol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I prefer partially signed zone. Lets avoid the word secure. Mark Kosters wrote: > On Fri, Apr 12, 2002 at 08:03:16AM -0700, Randy Bush wrote: > >>>I don't like the the term "secure partial zone". It seems to imply >>>that this zone is incomplete. >>> >>how about "partially signed zone?" >> > > That is fine. Another may be: > > opt-in -> "secured-node zone" > non-opt-in -> "secure zone" > > Mark > > -- Regards, Andy W. Barclay. abarclay@unixpeople.com fax (781) 823-8276 Always a UNIX Evangelist (and sometimes a system and network architect) The mistake you make is in trying to figure it out. --TENESSEE WILLIAMS -- 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 Apr 12 14:28:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29762 for ; Fri, 12 Apr 2002 14:28:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16w5af-00005w-00 for namedroppers-data@psg.com; Fri, 12 Apr 2002 11:16:05 -0700 Received: from h236.s231.netsol.com ([216.168.231.236]) by psg.com with esmtp (Exim 3.35 #1) id 16w5ae-00005q-00 for namedroppers@ops.ietf.org; Fri, 12 Apr 2002 11:16:04 -0700 Received: (from markk@localhost) by h236.s231.netsol.com (8.11.0/8.11.0) id g3CIFqY12287; Fri, 12 Apr 2002 14:15:52 -0400 (EDT) Date: Fri, 12 Apr 2002 14:15:52 -0400 From: Mark Kosters To: "Andy W. Barclay" Cc: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call Message-ID: <20020412181552.GK10756@slam.admin.cto.netsol.com> References: <01C133474E27D04FABA48D02078CF41D0A0A2F@df-dinky.dogfood> <3CB46DBF.4090300@digisle.com> <20020412153306.GD10756@slam.admin.cto.netsol.com> <3CB72122.3080104@unixpeople.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CB72122.3080104@unixpeople.com> User-Agent: Mutt/1.3.25i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, Apr 12, 2002 at 11:02:10AM -0700, Andy W. Barclay wrote: > I prefer partially signed zone. Lets avoid the word secure. You are quite right about signed vs secure. Using Derek's response of security being an art, perhaps we need to not use the word partial since it does not sound quite right. How about: opt-in -> "signed-node zone" non-opt-in -> "signed zone" (realizing once again how unfortunate it was to call "signed-node" "opt-in" in the first place) Mark -- Mark Kosters markk@netsol.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 Apr 15 11:33:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20570 for ; Mon, 15 Apr 2002 11:33:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16x80V-000JOt-00 for namedroppers-data@psg.com; Mon, 15 Apr 2002 08:03:03 -0700 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16x80U-000JOm-00 for namedroppers@ops.ietf.org; Mon, 15 Apr 2002 08:03:02 -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 g3FEwWe28023; Mon, 15 Apr 2002 10:58:33 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.2.20020415104032.02979e80@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 15 Apr 2002 10:59:04 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Opt-in wg last call Cc: Rob Austein In-Reply-To: <20020403195935.436D41BB2@thrintun.hactrn.net> References: <20020403152418.V2582-100000@node10c4d.a2000.nl> <20020403112549.6693629d.olaf@ripe.net> <20020403152418.V2582-100000@node10c4d.a2000.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 03:59 PM 4/3/2002, Rob Austein wrote: >Do we have a worked example of opt-in applied to a zone that's more >than one label deep? This seems like the place where weakening of the >"secure zone" model is most likely to make life confusing for the >resolver. > >Apologies if this has already been discussed and I missed it, but I >saw no such example on a quick re-read of the draft. Great question Rob, this has not been discussed before. After thinking about this, I have convinced myself that there is an additional problem with opt-in and multi label names. In general with Opt-in attacker can for unsecured name deny existence invent new name invent new RR change RR on the fly. This is acceptable risk those that deploy Opt-in for as the secure names can not be attacked. In multi label names zones in the following case (only relevant names and types shown) example SOA SIG (SOA) NXT b.example ... b.example NXT f.e.d.c.example. c.example. A ... d.c.example. TXT ... f.e.d.c.example A .... SIG(A) Now an attacker can invent a delegation for any label on the way to f.e.d.c.example and answer with bogus data. I think this can be addressed by requiring that c.example must exist and be secured otherwise it is to hard for the resolver to find the correct NXT record that proves that f.e.d.c.example. is the next secured name. 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 Mon Apr 15 13:17:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28577 for ; Mon, 15 Apr 2002 13:17:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16x9c8-000MzE-00 for namedroppers-data@psg.com; Mon, 15 Apr 2002 09:46:00 -0700 Received: from porter.east.isi.edu ([65.114.168.20] helo=east.east.isi.edu) by psg.com with esmtp (Exim 3.35 #1) id 16x9c7-000Mz8-00 for namedroppers@ops.ietf.org; Mon, 15 Apr 2002 09:45:59 -0700 Received: from isi.edu (wireless82.east.isi.edu [65.114.168.82]) by east.east.isi.edu (8.11.3/8.11.3) with ESMTP id g3FGjvh21818; Mon, 15 Apr 2002 12:45:57 -0400 (EDT) Message-ID: <3CBB0473.AC17D5B8@isi.edu> Date: Mon, 15 Apr 2002 12:48:51 -0400 From: Daniel Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?=D3lafur=20Gu=F0mundsson?= CC: namedroppers@ops.ietf.org, Rob Austein Subject: Re: Opt-in wg last call References: <20020403152418.V2582-100000@node10c4d.a2000.nl> <20020403112549.6693629d.olaf@ripe.net> <20020403152418.V2582-100000@node10c4d.a2000.nl> <5.1.0.14.2.20020415104032.02979e80@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Ólafur Gušmundsson wrote: > > At 03:59 PM 4/3/2002, Rob Austein wrote: > >Do we have a worked example of opt-in applied to a zone that's more > >than one label deep? This seems like the place where weakening of the > >"secure zone" model is most likely to make life confusing for the > >resolver. > > > >Apologies if this has already been discussed and I missed it, but I > >saw no such example on a quick re-read of the draft. > > Great question Rob, this has not been discussed before. > > After thinking about this, I have convinced myself that there is an > additional problem with opt-in and multi label names. > In general with Opt-in attacker can for unsecured name > deny existence > invent new name > invent new RR > change RR on the fly. > > This is acceptable risk those that deploy Opt-in for as the secure names > can not be attacked. > > In multi label names zones in the following case (only relevant names and > types shown) > example SOA > SIG (SOA) > NXT b.example ... > > b.example NXT f.e.d.c.example. > > c.example. A ... > d.c.example. TXT ... > > f.e.d.c.example A .... > SIG(A) > > Now an attacker can invent a delegation for any label on the way to > f.e.d.c.example and answer with bogus data. > Yes, at a minimum this is going to add some complexity to the resolver. > I think this can be addressed by requiring that c.example must exist > and be secured otherwise it is to hard for the resolver to find > the correct NXT record that proves that f.e.d.c.example. > is the next secured name. > I'm not sure this fixes it.... would you allow the following: b.example. NXT c.example. c.example. A, SIG(A), NXT f.e.d.c.example, SIG(NXT) d.c.example. TXT ... f.e.d.c.example A, SIG(A), NXT ..., SIG(NXT) In this case, won't you have a still have a problem with an attacker inventing a delegation for d.c.example (or other labels on the way)? If I understand the fix, you change the opt-in NXT from: b.example. NXT f.e.d.c.example to c.example. NXT f.e.d.c.example I'm not seeing how the complexity of the resolver gets improved... Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 15 14:36:41 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02024 for ; Mon, 15 Apr 2002 14:36:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16xB66-0000Yn-00 for namedroppers-data@psg.com; Mon, 15 Apr 2002 11:21:02 -0700 Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.35 #1) id 16xB65-0000Yh-00 for namedroppers@ops.ietf.org; Mon, 15 Apr 2002 11:21:01 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.6/8.11.6) with ESMTP id g3FIGU328388; Mon, 15 Apr 2002 14:16:30 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Mon, 15 Apr 2002 14:16:30 -0400 (EDT) From: Olafur Gudmundsson X-X-Sender: ogud@hlid.dc.ogud.com To: Daniel Massey cc: namedroppers@ops.ietf.org, Rob Austein Subject: Re: Opt-in wg last call In-Reply-To: <3CBB0473.AC17D5B8@isi.edu> Message-ID: <20020415135503.V28349-100000@hlid.dc.ogud.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 15 Apr 2002, Daniel Massey wrote: > > I think this can be addressed by requiring that c.example must exist > > and be secured otherwise it is to hard for the resolver to find > > the correct NXT record that proves that f.e.d.c.example. > > is the next secured name. > > > > I'm not sure this fixes it.... would you allow the following: > > b.example. NXT c.example. > c.example. A, SIG(A), NXT f.e.d.c.example, SIG(NXT) > d.c.example. TXT ... > f.e.d.c.example A, SIG(A), NXT ..., SIG(NXT) > > In this case, won't you have a still have a problem with an > attacker inventing a delegation for d.c.example (or other labels > on the way)? This NXT says there is no secure name between c.example and f.e.d.c.example. AND example has signing authority over f.e.d.c.example. This implies there is no delegation. > > If I understand the fix, you change the opt-in NXT from: > b.example. NXT f.e.d.c.example > to > c.example. NXT f.e.d.c.example The resolver now checks the NXT for example, c.example, and is done. In the other case the resolver had to try to find b.example or what ever the name before c was. Thinking about this further I'm not sure my original fix is enough, does every label needs to be secured ie c.example. NXT d.c.example. d.c.example. NXT e.d.c.example. NXT e.d.c.example NXT f.e.d.c.example. NXT Notice the NXT records with only NXT bit set, these indicate that there is no record and no delegation at this name. (YUCK). > > I'm not seeing how the complexity of the resolver gets > improved... > I'm not at this point interested in decreasing the complexity of the resolver, only that it can answer the question correctly. 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 Mon Apr 15 15:03:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03031 for ; Mon, 15 Apr 2002 15:03:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16xBcw-0001zJ-00 for namedroppers-data@psg.com; Mon, 15 Apr 2002 11:54:58 -0700 Received: from porter.east.isi.edu ([65.114.168.20] helo=east.east.isi.edu) by psg.com with esmtp (Exim 3.35 #1) id 16xBcw-0001zC-00 for namedroppers@ops.ietf.org; Mon, 15 Apr 2002 11:54:58 -0700 Received: from isi.edu (wireless82.east.isi.edu [65.114.168.82]) by east.east.isi.edu (8.11.3/8.11.3) with ESMTP id g3FIsuh23943; Mon, 15 Apr 2002 14:54:56 -0400 (EDT) Message-ID: <3CBB229F.2470D596@isi.edu> Date: Mon, 15 Apr 2002 14:57:35 -0400 From: Daniel Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Olafur Gudmundsson CC: namedroppers@ops.ietf.org, Rob Austein Subject: Re: Opt-in wg last call References: <20020415135503.V28349-100000@hlid.dc.ogud.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur Gudmundsson wrote: > > This NXT says there is no secure name between c.example and > f.e.d.c.example. > AND example has signing authority over f.e.d.c.example. > > This implies there is no delegation. > The "c.example NXT something.example" record proves there is no NS record and hence no delegation for c.example. This prevents the attacker from making up a false delegation for c, but doesn't help prevent the attacker from making up delegations to d.c.example or e.d.c.example. > > > > If I understand the fix, you change the opt-in NXT from: > > b.example. NXT f.e.d.c.example > > to > > c.example. NXT f.e.d.c.example > > The resolver now checks the NXT for example, c.example, and is done. > > In the other case the resolver had to try to find b.example or what ever > the name before c was. Thinking about this further I'm not sure > my original fix is enough, does every label needs to be secured ie > c.example. NXT d.c.example. > d.c.example. NXT e.d.c.example. NXT > e.d.c.example NXT f.e.d.c.example. NXT > Yes, this is a better of way of saying what I was trying to express in the earlier message. I think adding the requirement that c.example be signed isn't enough.... But perhaps the lack of a delegation is implied by the next signed name. Suppose you have: anything.example NXT f.e.d.c.example. Is it correct to say this proves there is no delegation to c.example, d.c.example, and e.d.c.example? Reasoning: if there was a delegation to any of the above, then the signed f.e.d.c.example record should not be in the example.com zone and should not be pointed to be the NXT in example.com. I'm not sure this is right, but if it is right then you should be able to construct resolver rules that work. The drawback is make the resolver code looks more complex... Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 16 01:52:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16105 for ; Tue, 16 Apr 2002 01:52:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16xLhf-000Mdy-00 for namedroppers-data@psg.com; Mon, 15 Apr 2002 22:40:31 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.35 #1) id 16xLhe-000Mds-00 for namedroppers@ops.ietf.org; Mon, 15 Apr 2002 22:40:30 -0700 Received: from isc.org (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.6/8.11.2) with ESMTP id g3G5eBx37571; Tue, 16 Apr 2002 15:40:12 +1000 (EST) (envelope-from marka@isc.org) Message-Id: <200204160540.g3G5eBx37571@drugs.dv.isc.org> To: Daniel Massey Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org, Rob Austein From: Mark.Andrews@isc.org Subject: Re: Opt-in wg last call In-reply-to: Your message of "Mon, 15 Apr 2002 14:57:35 -0400." <3CBB229F.2470D596@isi.edu> Date: Tue, 16 Apr 2002 15:40:11 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > But perhaps the lack of a delegation is implied by the next > signed name. Suppose you have: > > anything.example NXT f.e.d.c.example. > > Is it correct to say this proves there is no delegation > to c.example, d.c.example, and e.d.c.example? Yes. > Reasoning: if there was a delegation to any of the > above, then the signed f.e.d.c.example record should > not be in the example.com zone and should not be pointed > to be the NXT in example.com. Correct. > I'm not sure this is right, but if it is right then you > should be able to construct resolver rules that work. > The drawback is make the resolver code looks more complex... > > Dan > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > 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 Tue Apr 16 09:36:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03371 for ; Tue, 16 Apr 2002 09:36:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16xSrY-00054b-00 for namedroppers-data@psg.com; Tue, 16 Apr 2002 06:19:12 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.35 #1) id 16xSrX-00054N-00 for namedroppers@ops.ietf.org; Tue, 16 Apr 2002 06:19:11 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01728; Tue, 16 Apr 2002 09:19:02 -0400 (EDT) Message-Id: <200204161319.JAA01728@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-dnsext-opcode-discover-00.txt Date: Tue, 16 Apr 2002 09:19:01 -0400 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 : The DISCOVER opcode Author(s) : B. Manning, P. Vixie, E. Guttman Filename : draft-dnsext-opcode-discover-00.txt Pages : Date : 15-Apr-02 The QUERY opcode in the DNS is designed for unicast. With the development of multicast capabilities in the DNS, it is desireable to have a more robust opcode for server interactions since a single request may result in replies from multiple responders. So DISCOVER is defined to deal with replies from multiple responders. As such, this document extend the core DNS specifications to allow clients to have a method for coping with replies from multiple responders. Use of this new opcode may facilitate DNS operations in modern networking topologies. A prototype of the DISCOVER opcode was developed as part of the TBDS project, funded under DARPA grant F30602-99-1-0523. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-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-dnsext-opcode-discover-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-dnsext-opcode-discover-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: <20020415112429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dnsext-opcode-discover-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-dnsext-opcode-discover-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020415112429.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 Tue Apr 16 17:17:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20920 for ; Tue, 16 Apr 2002 17:17:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16xZwE-000FXg-00 for namedroppers-data@psg.com; Tue, 16 Apr 2002 13:52:30 -0700 Received: from h227.s231.netsol.com ([216.168.231.227] helo=pinion.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.35 #1) id 16xZwD-000FXa-00 for namedroppers@ops.ietf.org; Tue, 16 Apr 2002 13:52:29 -0700 Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id C16D52AC42; Tue, 16 Apr 2002 16:52:28 -0400 (EDT) To: namedroppers@ops.ietf.org Subject: Re: Opt-in wg last call References: <20020403152418.V2582-100000@node10c4d.a2000.nl> <20020403112549.6693629d.olaf@ripe.net> <20020403152418.V2582-100000@node10c4d.a2000.nl> <5.1.0.14.2.20020415104032.02979e80@localhost> From: David Blacka In-Reply-To: <5.1.0.14.2.20020415104032.02979e80@localhost> =?iso-8859-1?q?("=D3lafur_Gu=F0mundsson"'s?= message of "Mon, 15 Apr 2002 10:59:04 -0400") Date: Tue, 16 Apr 2002 16:52:28 -0400 Message-ID: Lines: 131 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Common Lisp, i386-mandrake-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit >>>>> "ogud" == lafur Gušmundsson writes: ogud> At 03:59 PM 4/3/2002, Rob Austein wrote: >> Do we have a worked example of opt-in applied to a zone that's more >> than one label deep? This seems like the place where weakening of the >> "secure zone" model is most likely to make life confusing for the >> resolver. >> >> Apologies if this has already been discussed and I missed it, but I >> saw no such example on a quick re-read of the draft. ogud> Great question Rob, this has not been discussed before. ogud> After thinking about this, I have convinced myself that there is an ogud> additional problem with opt-in and multi label names. ogud> In general with Opt-in attacker can for unsecured name ogud> deny existence ogud> invent new name ogud> invent new RR ogud> change RR on the fly. ogud> This is acceptable risk those that deploy Opt-in for as the ogud> secure names can not be attacked. ogud> In multi label names zones in the following case (only relevant names ogud> and types shown) ogud> example. SOA ogud> SIG (SOA) ogud> NXT b.example ... ogud> b.example NXT f.e.d.c.example. (opt-in) ogud> c.example. A ... ogud> d.c.example. TXT ... ogud> f.e.d.c.example. A .... ogud> SIG(A) ogud> Now an attacker can invent a delegation for any label on the ogud> way to f.e.d.c.example and answer with bogus data. But a dnssec-aware resolver would know that this information is bogus, ultimately. Let's look at the "normal" query chain, starting at our fictionally secured root: root: Q: f.e.c.example. A A: ANS AUTH example. NS blah1 example. NS blah2 example. DS example. SIG(DS) ADD blah1 A blah2 A So, we can cryptographically verify that example. is secure (partially, whatever). example: Q: f.e.c.example. A A: ANS f.e.c.example. A f.e.c.example. SIG(A) AUTH example. NS blah1 example. NS blah2 example. SIG(NS) ADD example KEY ... example SIG(KEY) ... ... So, we can cryptographically verify that f.e.c.example A is a valid record. But, some one has forged a bogus delegation at e.c.example, so instead of the normal answer, we get this: example: Q: f.e.c.example. A A: ANS AUTH e.c.example NS bogus1 b.example. NXT f.e.c.example (opt-in) b.example SIG(NXT) ... ADD bogus1 A ... example. KEY example. SIG(KEY)... The NXT RRset may or may not be a part of the answer. The resolver now knows that this is bogus because AT EVERY STEP there MUST be either: (1) a signed RRset (DS, or the answer), or (2) A signed NXT proving either that the RRset doesn't exist (non-opt-in case), or the name is not secure (opt-in case). Since the attacker cannot create valid NXT records, he can only reuse the ones that exist (namely, b.example. NXT f.e.c.example.). This NXT record will not validate. Actually, a particularly astute resolver might be able to determine that "e.c.example NS" should actually not exist at all. But this is probably above and beyond the call of duty for a verifier. ogud> I think this can be addressed by requiring that c.example must ogud> exist and be secured otherwise it is to hard for the resolver ogud> to find the correct NXT record that proves that ogud> f.e.d.c.example. is the next secured name. How so? If a resolver queries the example nameserver for c.example, or e.d.c.example, it will get back the correct NXT record. If an attacker is in a postion to remove this record from the response, then the attacker can make anything in example disappear, regardless of 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 Tue Apr 16 23:42:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00257 for ; Tue, 16 Apr 2002 23:42:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16xg3a-000OGo-00 for namedroppers-data@psg.com; Tue, 16 Apr 2002 20:24:30 -0700 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by psg.com with esmtp (Exim 3.35 #1) id 16xg3Z-000OGh-00 for namedroppers@ops.ietf.org; Tue, 16 Apr 2002 20:24:29 -0700 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Tue, 16 Apr 2002 21:24:26 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Tue, 16 Apr 2002 21:24:09 -0600 From: "dhiraj Dhiraj" To: , Subject: Valid charecter set in DNS Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I have a question regarding the valid character set in DNS. I have seen RFC 1034, 1123, 2181. It seems RFC 2181 removes the restrictions of RFC 1034,1123 which says that only letters, digits, and hyphen are allowed. I wanted to know whether this interpretation is correct or not and if it is, then what are the applications that require other characters? I am aware of that underscores are required bcoz of the SRV RR. RFC 1034 section 3.5: The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. ::= | " " ::=