From owner-namedroppers@ops.ietf.org Fri Jun 1 00:04:56 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16030 for ; Fri, 1 Jun 2001 00:04:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155fuH-000HjT-00 for namedroppers-data@psg.com; Thu, 31 May 2001 20:47:25 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 155fuH-000HjN-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 20:47:25 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155fuE-0001A6-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 20:47:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106010155.f511tBv06581@drugs.dv.isc.org> To: dfriedman@hns.com Cc: namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: DNS query lengths In-reply-to: Your message of "Thu, 31 May 2001 17:48:37 -0400." <85256A5D.0078071C.00@ngw2.hns.com> Date: Fri, 01 Jun 2001 11:55:11 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit See: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-04.txt > Hello All, > > I'm working on a specialized communications system in which the length of > the a DNS query is a matter of great importance. I've looked at RFCs 1034 > and 1035, and understand how long a DNS query is for a given host name. > I've also looked a bit at DNSsec. > > Main question: what extensions/modifications to the DNS query format > (described in RFC 1035), described in other RFCs, would affect the length of > a query? In particular, what such extensions/modifications are in common > use today, or likely will be in use in the next few years? > > Related matter: if I've addressed this question to the wrong venue, please > suggest a better venue, and I'll stop polluting this one. > > Thanks very much, > --daniel > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 1 00:05:26 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16066 for ; Fri, 1 Jun 2001 00:05:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155fww-000HlN-00 for namedroppers-data@psg.com; Thu, 31 May 2001 20:50:10 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 155fww-000HlG-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 20:50:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155fwt-0001As-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 20:50:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 31 May 2001 20:04:22 -0700 (PDT) From: Brian Wellington To: Cc: Subject: Re: DNS query lengths In-Reply-To: <85256A5D.0078071C.00@ngw2.hns.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 31 May 2001 dfriedman@hns.com wrote: > Hello All, > > I'm working on a specialized communications system in which the length of > the a DNS query is a matter of great importance. I've looked at RFCs 1034 > and 1035, and understand how long a DNS query is for a given host name. > I've also looked a bit at DNSsec. > > Main question: what extensions/modifications to the DNS query format > (described in RFC 1035), described in other RFCs, would affect the length of > a query? In particular, what such extensions/modifications are in common > use today, or likely will be in use in the next few years? EDNS (Extension Mechanisms for DNS, RFC 2671) capable clients send requests with an OPT record, The OPT record, in the normal case, is 11 bytes. EDNS also specifies a mechanism for adding additional fields in the OPT record. None are in common use right now, and the proposed ones are not likely to be in widespread use. 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. From owner-namedroppers@ops.ietf.org Fri Jun 1 00:09:38 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16028 for ; Fri, 1 Jun 2001 00:04:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155fqc-000Hho-00 for namedroppers-data@psg.com; Thu, 31 May 2001 20:43:38 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 155fqc-000Hhi-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 20:43:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155fqZ-00019v-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 20:43:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B16CF8B.AE58F8EB@daimlerchrysler.com> Date: Thu, 31 May 2001 19:11:07 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: DNS query lengths References: <85256A5D.0078071C.00@ngw2.hns.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Did you mean just *query* length, or query and response lengths? The SIG and NXT records of DNSSEC will lengthen queries and responses (although SIG records are typically seen in responses, a SIG(0) can be included in a query as a "transaction signature", see RFC 2931). Similarly, a TSIG record (see RFC 2845) may appear in a query or response as a transaction signature. Moreover, the OPT record of EDNS0 (see RFC 2671) may appear in a query or response. I seem to recall there were recent moves afoot for EDNS0 to be made *mandatory* for all DNSSEC-aware clients and/or servers, since one of the primary functions of EDNS0 is to advertise message buffer sizes larger than 512 bytes, which is likely to be necessary with DNSSEC in order to prevent TCP retransmission. The size of an OPT record can be highly variable, since in a sense it's a container for an indeterminate number of option "sub-records". Lastly, it may come to pass that SRV records (see RFC 2782) will largely supplant the use of A records, at least for "common" client/server interactions such as web browsing. locating local authentication and/or directory services, etc.. Since SRV records are larger than A records, this will tend to increase response size. Offhand, those are the only post-RFC-103[45] extensions I can think of that would increase query and/or response size. But maybe others on this list can think of more.... I think you have your work cut out for you. - Kevin dfriedman@hns.com wrote: > Hello All, > > I'm working on a specialized communications system in which the length of > the a DNS query is a matter of great importance. I've looked at RFCs 1034 > and 1035, and understand how long a DNS query is for a given host name. > I've also looked a bit at DNSsec. > > Main question: what extensions/modifications to the DNS query format > (described in RFC 1035), described in other RFCs, would affect the length of > a query? In particular, what such extensions/modifications are in common > use today, or likely will be in use in the next few years? > > Related matter: if I've addressed this question to the wrong venue, please > suggest a better venue, and I'll stop polluting this one. > > Thanks very much, > --daniel > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 1 09:14:16 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07580 for ; Fri, 1 Jun 2001 09:14:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155oKN-00014I-00 for namedroppers-data@psg.com; Fri, 01 Jun 2001 05:46:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 155oKN-00014C-00 for namedroppers@ops.ietf.org; Fri, 01 Jun 2001 05:46:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 155oKN-000DGQ-00 for namedroppers@ops.ietf.org; Fri, 01 Jun 2001 05:46:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Miek Gieben Date: Fri, 1 Jun 2001 11:13:01 +0200 To: Olafur Gudmundsson Cc: dnssec@cafax.se, namedroppers@ops.ietf.org Subject: Re: Fwd: I-D ACTION:draft-ietf-dnsext-delegation-signer-00.txt Message-ID: <20010601111301.A11824@open.nlnetlabs.nl> References: <5.1.0.14.0.20010531093041.02372d20@localhost> In-Reply-To: <5.1.0.14.0.20010531093041.02372d20@localhost>; from ogud@ogud.com on Thu, May 31, 2001 at 09:33:58AM -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [On 31 May, 2001, Olafur Gudmundsson wrote in " Fwd: I-D ACTION:draft-ietf-dnsext-delegation-signer-00.txt ] > > Just in case anyone did not see this one, here are my .02 SKR solution to > the problem of keysets at apex. > Please read and comment as I would like do figure out real soon > if this is better or worse than Sigs at parent. > If there is no consensus on either this or Sigs at parent then sigs at > child wins. We at NLnet Labs see it like this: Nobody (at least the DNSSEC people) want sig@child, because of all the operational issues involved. That leaves us with 2 options: 1) sig@parent 2) delegation-signer 1) solves the operational issues but introduces complications in the resolver implementation. 2) also solves the operational issues , but doesn't introduce new problems in a secure aware resolver. grtz Miek to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 1 09:16:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07619 for ; Fri, 1 Jun 2001 09:16:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155oKg-00014V-00 for namedroppers-data@psg.com; Fri, 01 Jun 2001 05:47:14 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 155oKg-00014P-00 for namedroppers@ops.ietf.org; Fri, 01 Jun 2001 05:47:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 155oKg-000DHQ-00 for namedroppers@ops.ietf.org; Fri, 01 Jun 2001 05:47:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Fri, 01 Jun 2001 03:00:00 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 1 13:02:17 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12636 for ; Fri, 1 Jun 2001 13:02:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155s3y-0005A3-00 for namedroppers-data@psg.com; Fri, 01 Jun 2001 09:46:14 -0700 Received: from [131.107.37.68] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 155s3x-00059s-00 for namedroppers@ops.ietf.org; Fri, 01 Jun 2001 09:46:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155s3P-0001rc-00 for namedroppers@ops.ietf.org; Fri, 01 Jun 2001 09:45:39 -0700 Date: Fri, 1 Jun 2001 18:00:33 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC 2782 (SRV RRs) Interop testing report To: Levon Esibov , ogud@ogud.com Cc: namedroppers@ops.ietf.org, narten@raleigh.ibm.com In-Reply-To: "Your message with ID" <4AEE3169443CDD4796CA8A00B02191CDD1DEDA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The only section that required the interoperability section is "The format of > the SRV RR". The format of the records was verified by monitoring the network > traffic and by performing the tests described below. Note: subsections > "Priority" and "Weight" describe how application using SRV records to locate > a server should treat Priority and Weight values specified in the SRV > records. Interoperability testing of the implementations supporting service > location mechanism based on the rules described in the "Priority" and > "Weight" sub-sections should be conducted within the testing of the > implementations supporting relevant protocol specification corresponding to a > specific application, not the generic specification of the SRV records, > rfc2782bis. The comment about the priority and weight subsections seems a bit odd given that the specification has MUST and SHOULD laguage for those two fields in question. Thus I think there needs to be enough interoperatbility testing to verify that the language in those subsections is clear enough for implementors. So the tests need to take into account the actual software on the clients which honor the priority and weight fields in the RR - if this isn't done we have no idea whether the description in the specification is clear enough. This means testing with different priority and weight fields. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 2 01:14:30 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25487 for ; Sat, 2 Jun 2001 01:14:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1563HE-000KNi-00 for namedroppers-data@psg.com; Fri, 01 Jun 2001 21:44:40 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1563HE-000KNc-00 for namedroppers@ops.ietf.org; Fri, 01 Jun 2001 21:44:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1563HE-000Lew-00 for namedroppers@ops.ietf.org; Fri, 01 Jun 2001 21:44:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010602002339.022e87c0@localhost> Date: Sat, 02 Jun 2001 00:27:38 -0400 To: "Nicolae, Dan" From: Olafur Gudmundsson Subject: RE: summary/conclusion of discussion on mdns-00 Cc: Namedroppers In-Reply-To: <3820E1EF15CCD411B4E600508BAED1F45BC91B@usa0111ms2.eng.mc.x erox.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 02:14 PM 5/30/2001, Nicolae, Dan wrote: > > What's more, as soon as that "magic string in the search list" stuff is > > gone, the whole "local.arpa" nonsense can go with it (which isn't to say > > that people shouldn't use that necessarily, just that there's no reason at > > all to compel it). (ie: unlike some others on the list, I agree with > > proposed change #1). >Restricting mDNS to names rooted at "local.arpa" has another effect, besides >the mDNS configuration. It isolates the mDNS data in the DNS namespace. I am >not sure if this was one of the purposes for the "local.arpa" proposal, but >I can see a potential value. There are two reasons for local.arpa. , one is to make sure all devices are playing in the same name space and thus see each other. The second reason is to have an easy way to filter these names. The original suggestion was to use some top level domain, which does not fly in current ICANN environment. >"local.arpa" is a potential solution but I am not sure that it aligns with >the original DNS design in RFC1034 (besides the problem that existing DNS >servers are not configured to push back queries for ".local.arpa"). I >believe that when dealing with parallel, separately managed namespaces the >suggested solution is to use different classes. Different "zone cuts" for >the same namespace are legal in different classes. Yes a separate class is one way to go, but in April 2000 some company wanted solution that could be shipped before the end of 2000. IMHO this solution is well within the design in RFC1034, if there had been more time a better discovery mechanism could have been built in [Bill^2 where is the new draft ?] >I know that classes other than IN have proved unuseful so far (except when >used in the QCLASS field. However I am curious what would be the issues with >defining a new class for mDNS (it could be e.g. ZC from zero configuration) >instead of rerooting the DNS namespace at "local.arpa". How can I say this politely, "local.arpa." gives implementors with little clue all the flexibility they need, why give them more ? I fought hard for requiring that every node that answers mDNS query acts like a real DNS server for a real DNS zone, eg it must have SOA, NS records. There where people that wanted only to be able to answer for single type. As for issues with new class, - how do you populate the type space, inherit from IN or create new - how long before tools become available, - does ICANN control the namespace of all classes or only IN ? Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 2 17:59:17 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13873 for ; Sat, 2 Jun 2001 17:59:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156Iuq-0003yc-00 for namedroppers-data@psg.com; Sat, 02 Jun 2001 14:26:36 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 156Iup-0003yW-00 for namedroppers@ops.ietf.org; Sat, 02 Jun 2001 14:26:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156Iup-000N4f-00 for namedroppers@ops.ietf.org; Sat, 02 Jun 2001 14:26:35 -0700 From: Bill Manning Message-Id: <200106021954.f52Js1x32047@zed.isi.edu> Subject: Re: summary/conclusion of discussion on mdns-00 To: ogud@ogud.com (Olafur Gudmundsson) Date: Sat, 2 Jun 2001 12:54:01 -0700 (PDT) Cc: Dan.Nicolae@usa.xerox.com (Nicolae Dan), namedroppers@ops.ietf.org (Namedroppers) In-Reply-To: <5.1.0.14.0.20010602002339.022e87c0@localhost> from "Olafur Gudmundsson" at Jun 02, 2001 12:27:38 AM X-Mailer: ELM [version 2.5 PL3] 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 since my posts to namedroppers are rejected by the moderator, and the current wg trhust seesm to be toward the microsoft approach, I have less interest in active participation. The idea is sound, even if it evolves on the way. I do have a draft; "Discover" that needs to be revisted as well. hopefully I'll have some time this week to work on them. -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jun 3 11:43:21 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09971 for ; Sun, 3 Jun 2001 11:43:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156ZcA-000D8W-00 for namedroppers-data@psg.com; Sun, 03 Jun 2001 08:16:26 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 156ZcA-000D8Q-00 for namedroppers@ops.ietf.org; Sun, 03 Jun 2001 08:16:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156Zc9-000P10-00 for namedroppers@ops.ietf.org; Sun, 03 Jun 2001 08:16:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Olafur Gudmundsson cc: "Nicolae, Dan" , Namedroppers Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: <5.1.0.14.0.20010602002339.022e87c0@localhost> References: <5.1.0.14.0.20010602002339.022e87c0@localhost> Date: Sun, 03 Jun 2001 16:53:05 +0700 Message-ID: <2348.991561985@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Sat, 02 Jun 2001 00:27:38 -0400 From: Olafur Gudmundsson Message-ID: <5.1.0.14.0.20010602002339.022e87c0@localhost> | There are two reasons for local.arpa. , one is to make sure all devices are | playing in the same name space and thus see each other. I am confused. What was this protocol supposed to be about again? I thought it was to be the DNS for when there is no DNS server available. That is, to be able to do just what the DNS would do, if only it was in an environment where there was a configured DNS server available. That is, the applications (users, whatever) need to know (or be able to discover some other way - even guess) what the name to be found is, and then the DNS is used (or mDNS in this environment) to obtain the data that the DNS has available about that name. How does "see each other" come into that at all? There's no "give me a list of all the names so I can pick one" type functionality here at all, and as long as some kind of DNS emulation is being done, there cannot be. Nor is this "service location done a different way". What does local.arpa possibly have to offer that makes a difference here? (That is, excluding any possible use of the name as a switch for when mDNS type name resolution should be done - just concentrating on the name itself). | The second reason is to have an easy way to filter these names. This is even more confusing. Filter the names from what? By what? I'm doing a lookup, if I am doing a lookup for olafur.local.arpa then that's the name I want to find, and I doubt I am going to filter it. On the other hand, if I am doing a lookup for munnari.oz.au then I am not going to see olafur.local.arpa or anything-else.local.arpa at all, to filter... If you mean that some applications might not want to see any results from mDNS lookups at all (real DNS for me or nothing) then this crude abuse of the namespace seems like exactly the wrong way to achieve it. Much more sane would be for the API to simply have a "no mDNS" switch that the application can turn on (like it is possible to disable use of domain name searching and other stuff in most APIs now). | The original suggestion was to use some top level domain, which does not | fly in current ICANN environment. The value of the name isn't the issue - it is simply that it looks to be using the namespace to provide some functionality that has nothing whatever to do with the DNS name tree. | Yes a separate class is one way to go, ... I'm not sure why separate anything is needed? Maybe I am just very confused, but there are two orthogonal issues here - one is the name to be found, and the other is the method by which that is done. I thought that the intent here was all about the 2nd of those - providing a method that can be used without lots of expert configuration, one that will simply work out of the box. That's a fine objective to want to achieve. Anything more than that seems bogus to me. | I fought hard for requiring that every node that answers mDNS query acts | like a real DNS server for a real DNS zone, eg it must have SOA, NS records. I can see some justification for that, but for how this is likely to be used, it seems like overkill. That is, I certainly wouldn't object to a mDNS "server" that actually did all of that, but I also wouldn't require everything to implement all of that - especially given that the records would all be very predictable anyway ... I am my own NS ("@ NS @"). My SOA is "@ IN SOA @ root.@ 0 0 0 1 0". The only part likely to ever vary is the "root" part, but exactly what an implementation (without configuration) would put there I'd hesitate to guess. | There where people that wanted only to be able to answer for single type. I can understand that .. I have a name, I have an address, I know nothing else at all, so that is all I am going to say. This is why I also believe that DDNS type queries should be what is used to "bind" my name to myself (check for duplicates). Handling that would complicate implementations a little, but not all that much - especially if it is made clear just what DDNS transaction should be used (ie: don't just allow everyone to do whatever seems OK to them - specify it). Because there's no record type that a SERVER necessarily has available (simple implementations won't be bothering with SOA, nor NS, and some nodes will have A records only, while others A6 (or AAAA) only, so those queries don't work either). That is, it is entirely possible for any regular query that is made to be quite correctly met with absolute silence, even though the name being queried exists (with the possible exception of ANY which has other potential problems). On the other hand, a "add me (A, A6, whatever the node wants, the record being added isn't important, it will be ignored mostly) if name doesn't exist" DDNS type query will result in a YXDOMAIN error response from the node that currently claims the name, if the name being sought actually exists somewhere. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jun 3 11:44:50 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09990 for ; Sun, 3 Jun 2001 11:44:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156ZgR-000DBw-00 for namedroppers-data@psg.com; Sun, 03 Jun 2001 08:20:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 156ZgR-000DBq-00 for namedroppers@ops.ietf.org; Sun, 03 Jun 2001 08:20:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156ZgR-000P8F-00 for namedroppers@ops.ietf.org; Sun, 03 Jun 2001 08:20:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200106031304.f53D4qI09383@zed.isi.edu> Subject: mDNS needs something like this To: namedroppers@ops.ietf.org Date: Sun, 3 Jun 2001 06:04:52 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit With thanks to the moderator for correcting an old problem, here is something for the current mDNS crowd to consider. It was useful in the first iteration of mDNS from a couple years ago. ------------------------------------------------------------- Individual Submission Bill Manning draft-opcode-discover-01.txt ISI 03 Jun 2001 The DISCOVER opcode This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. This document is a submission to the domain name system extentions (DNSEXT) working group of the Internet Engineering Task Force (IETF). Comments may be submitted to the working group mailing list at "namedroppers@ops.ietf.org" or the author. Distribution of this memo is unlimited. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This work was funded under DARPA grant: F30602-99-1-0523 0. Abstract 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. 1. DISCOVER works like QUERY except: 1. it can be sent to a broadcast or multicast destination (QUERY isn't defined for non-unicast, and arguably shouldn't be.) 2. the Question section, if present, has tuples. Future work could augment this structure as follows: 3. if QDCOUNT==0 then only servers willing to do recursion should answer. Other servers must silently discard the DISCOVER request. 4. if QDCOUNT!=0 then only servers who are authoritative for the zones named by some QNAME should answer. 5. responses may echo the request's Question section or leave it blank. 6. responses have "normal" Answer, Authority, and Additional sections. e.g. the response is the same as that to a QUERY. Usage for gethostby{name,addr}-style requestors: Compute the zone name of the enclosing in-addr.arpa or ip6.int domain. DISCOVER whether anyone in-scope is authoritative for this zone. If so, query these authoritative servers for local in-addr/ip6 names. If not, DISCOVER whether there are recursive servers available. If so, query these recursive servers for local in-addr/ip6 names. So, a node will issue a multicast request with the DISCOVER opcode at some particular multicast scope. Then determine, from the replies, whether there are any DNS servers which are authoritative (or support recursion) for the zone. Once one learns a host's FQDN by the above means, repeat the process for discovering the closest enclosing authoritative server of such local name. Cache all NS and A data learned in this process, respecting TTL's. Usage for SRV requestors: Do the gethostbyaddr() and gethostbyname() on one's own LAN-local address, using the above process. Assume that the closest enclosing zone for which an authority server answers an in-scope DISCOVER packet is "this host's parent domain". Compute the SRV name as _service._transport.*.parentdomain. This is a change to the definition as defined in RFC 1034. A wildcard label ("*") in the QNAME used in a DNS message with opcode DISCOVER SHOULD be evaluated with special rules. The wildcard matches any label for which the DNS server data is authoritative. For example 'x.*.example.com.' would match 'x.y.example.com.' and 'x.yy.example.com.' provided that the server was authoritative for 'example.com.' In this particular case, we suggest the follwing considerations be made: getservbyname() can be satisfied by issuing a request with this computed SRV name. The servent structure can be populated by values returned from a request as follows: s_name The name of the service, "_service" without the preceding underscore. s_aliases The names returned in the SRV RRs in replies to the query. s_port The port number in the SRV RRs replies to the query. If these port numbers disagree - one of the port numbers is chosen, and only those names which correspond are returned. s_proto The transport protocol from named by the "_transport" label, without the preceding underscore. Send SRV query for this name to discovered local authority servers. Usage for disconnected networks with no authority servers: Hosts should run a "stub server" which acts as though its FQDN is a zone name. Computed SOA gives the host's FQDN as MNAME, "." as the ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE and the other timers. Computed NS gives the host's FQDN. Computed glue gives the host's LAN-local address. Or Hosts may run a "DNS stub server" which acts as though its FQDN is a zone name. The rules governing the behavior of this stub server are given elsewhere [1] [2]. Such stub servers should answer DISCOVER packets for its zone, and will be found by the iterative "discover closest enclosing authority server" by DISCOVER clients, either in the gethostbyname() or SRV cases described above. Note that stub servers only answer with zone names which match QNAME's, not with zone names which are owned by QNAME's. The only deviation from the DNS model is that a host (like, say, a printer offering LPD services) has a DNS server which answers authoritatively for something which hasn't been delegated to it. However, the only way that such DNS servers can be discovered is with a new opcode, DISCOVER, which is explicitly defined to discover undelegated zones for tightly scoped purposes. Therefore this isn't officially a violation of DNS's coherency principles. The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 3. IANA Considerations As a new opcode, the IANA will need to assign a numeric value for the memnonic. Test implementations have used the numeric value 6, being the next one available after 5, for update. 4. Security Considerations No new security considerations are known to be introduced. Using multicast for service discovery has the potential for denial of service. 5. Attribution: This material was generated in discussions on the mdns mailing list hosted by Zocalo in March 2000. Paul Vixie crystalized the concepts... Stuart Cheshire, Bill Woodcock, Erik Guttman and were active contributors. 6. Author's Address Bill Manning PO 12317 Marina del Rey, CA. 90295 +1.310.322.8102 bmanning@karoshi.com 7. References [1] draft-ietf-dnsext-mdns-00.txt [2] draft-manning-dnsext-mdns-00.txt ------------------------------------------------------------------------------- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jun 3 12:59:51 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10306 for ; Sun, 3 Jun 2001 12:59:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 156azE-000EOf-00 for namedroppers-data@psg.com; Sun, 03 Jun 2001 09:44:20 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 156azD-000EOZ-00 for namedroppers@ops.ietf.org; Sun, 03 Jun 2001 09:44:19 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156azD-0001LD-00 for namedroppers@ops.ietf.org; Sun, 03 Jun 2001 09:44:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106031642.JAA30859@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: mDNS needs something like this In-Reply-To: Message from Bill Manning of "Sun, 03 Jun 2001 06:04:52 PDT." <200106031304.f53D4qI09383@zed.isi.edu> Date: Sun, 03 Jun 2001 09:42:04 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Subject: mDNS needs something like this agreed. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 5 12:20:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25077 for ; Tue, 5 Jun 2001 12:20:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157Iwk-000Af6-00 for namedroppers-data@psg.com; Tue, 05 Jun 2001 08:40:42 -0700 Received: from h-135-207-28-168.research.att.com ([135.207.28.168] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157Iwj-000Aez-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 08:40:41 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157Ivo-0000gP-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 11:39:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <001801c0edc8$2bb1f960$b9370681@antd.nist.gov> From: "Scott Rose" To: "DNSEXT WG Mailing list" Subject: null DK records at the parent Date: Tue, 5 Jun 2001 10:02:34 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I haven't seen much discussion about the DK record draft on this or = cafax.se lists, so I'd thought I'd get the ball rolling: I'm in favor of requiring null DK records at the parent to signify that = the delegated child zone is unsecure (or experimentally secure if a KEY = record is present). Both the DK record and the SIG@parent solutions = require the delegating parent to store more information about the child = zones, but the benefits outweigh the downside of zone database growth. = SIG@child is the only solution that doesn't lead to a larger parent = zone, but there are other drawbacks that make it unpopular. The reason for needing null DK (or KEYs) in the parent, as I see it, is = that a security aware resolver knows to expect a DK or KEY in the glue = data when getting a delegation. If it doesn't, it knows to query for = them to determine the security status of the child. If it gets a null = DK/KEY record, then receives a self-signed KEY from the child, the = resolver knows the child is experimentally secure. In these two = schemes, the parent is responsible for stating the security status of = the delegated child. =20 If a null DK/KEY record is not required, and a resolver does not find a = DK/KEY record from a delegation, but find a KEY record in the child = zone, the resolver does not know if the zone is experimental, or secure = (and an attacker may have intercepted the delegation message). One thing that might be helpful to add to the DK draft (or the key = rollover draft) is how DK records should be used when performing a key = rollover. It might be helpful when learning how to perform a secure key = rollover. Scott to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 5 15:06:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28339 for ; Tue, 5 Jun 2001 15:06:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157LtH-000DY9-00 for namedroppers-data@psg.com; Tue, 05 Jun 2001 11:49:19 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157LtG-000DY3-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 11:49:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157LsO-0000za-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 14:48:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010605140034.04d33d30@localhost> Date: Tue, 05 Jun 2001 14:05:57 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Does anyone have application(s) that uses SRV records ? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We need implementation reports on how good the text in RFC2782 is. And we need to perform interoperabilty tests that show that applications follow the specification. Any help in getting this done is greatly appreciated. thanks Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 5 21:54:25 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03781 for ; Tue, 5 Jun 2001 21:54:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157S6M-000IiE-00 for namedroppers-data@psg.com; Tue, 05 Jun 2001 18:27:14 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157S6M-000Ii8-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 18:27:14 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157S5R-0002EQ-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 21:26:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 6 Jun 2001 03:21:26 +0200 (CEST) From: Roy Arends To: Scott Rose Cc: DNSEXT WG Mailing list , dnssec@cafax.se Subject: Re: null DK records at the parent In-Reply-To: <001801c0edc8$2bb1f960$b9370681@antd.nist.gov> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [cross-posted reply to dnssec@cafax.se] On Tue, 5 Jun 2001, Scott Rose wrote: > I haven't seen much discussion about the DK record draft on this or = > cafax.se lists, so I'd thought I'd get the ball rolling: > > I'm in favor of requiring null DK records at the parent to signify that = > the delegated child zone is unsecure (or experimentally secure if a KEY = > record is present). Both the DK record and the SIG@parent solutions = > require the delegating parent to store more information about the child = > zones, but the benefits outweigh the downside of zone database growth. = > SIG@child is the only solution that doesn't lead to a larger parent = > zone, but there are other drawbacks that make it unpopular. > > The reason for needing null DK (or KEYs) in the parent, as I see it, is = > that a security aware resolver knows to expect a DK or KEY in the glue = > data when getting a delegation. If it doesn't, it knows to query for = > them to determine the security status of the child. If it gets a null = > DK/KEY record, then receives a self-signed KEY from the child, the = > resolver knows the child is experimentally secure. In these two = > schemes, the parent is responsible for stating the security status of = > the delegated child. =20 > > If a null DK/KEY record is not required, and a resolver does not find a = > DK/KEY record from a delegation, but find a KEY record in the child = > zone, the resolver does not know if the zone is experimental, or secure = > (and an attacker may have intercepted the delegation message). > > One thing that might be helpful to add to the DK draft (or the key = > rollover draft) is how DK records should be used when performing a key = > rollover. It might be helpful when learning how to perform a secure key = > rollover. > > Scott When using the sig@parent/DK schemes, there is no fundamental difference between obsoleting the NULL-key qualification and requiring a NULL-key at the parent (it is unnecessary redundant). IIRC RFC 2535 stated that sig@parent is optional, and therefore the parent needed to specify some info when it wants to specify that the parent regards the child as not secured. With the new drafts, the parent is required to give information on the childs security status, in the case that the child is secured by the parent. If the parent does not consider the child to be secure, obsoleting sig/key/DK@parent is sufficient. ie, no information is in this case also information. When a dnssec-aware-resolver stumbles upon a child which claims to be secure, I see 3 different options. 1) the child key is self-signed and the resolver has this key preconfigured: It can easily verify the signatures. (but then, why would this resolver go top down from the root) 2) the child key is self-signed and the resolver has no knowledge of this key: unsecure zone. 3) The child key is signed by some key other then their own or its parent: The resolver needs to securely resolve this key (or could have it preconfigured). In any case, important is when a child is bad: only if the parent states that a child is secure, and the child can not offer valid signatures. Defining valid in this case: No sigs or corrupt sigs. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 5 22:32:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05409 for ; Tue, 5 Jun 2001 22:32:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157Soz-000JDj-00 for namedroppers-data@psg.com; Tue, 05 Jun 2001 19:13:21 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157Soz-000JDd-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 19:13:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157So4-0002Gg-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 22:12:24 -0400 Date: Wed, 6 Jun 2001 04:03:09 +0200 (CEST) From: Roy Arends To: Scott Rose Cc: DNSEXT WG Mailing list , dnssec@cafax.se Subject: Re: null DK records at the parent 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 Wed, 6 Jun 2001, Roy Arends wrote: > [cross-posted reply to dnssec@cafax.se] > > On Tue, 5 Jun 2001, Scott Rose wrote: > > > I haven't seen much discussion about the DK record draft on this or = [snip] > In any case, important is when a child is bad: > only if the parent states that a child is secure, and the child can > not offer valid signatures. Defining valid in this case: No sigs or > corrupt sigs. Eh, skip that, this should read: In any case, important is when a child is considered bad by a secure-resolver : only if the parent states that a child is secure, and the child can not offer valid keys or signatures. Defining invalid in this case: No sigs/keys or corrupt sigs/keys. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 5 23:17:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06222 for ; Tue, 5 Jun 2001 23:17:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157TaA-000JX5-00 for namedroppers-data@psg.com; Tue, 05 Jun 2001 20:02:06 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157TaA-000JWz-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 20:02:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157TZF-0002Jl-00 for namedroppers@ops.ietf.org; Tue, 05 Jun 2001 23:01:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010605222710.00affa40@localhost> Date: Tue, 05 Jun 2001 22:35:02 -0400 To: Bill Manning , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: mDNS needs something like this In-Reply-To: <200106031304.f53D4qI09383@zed.isi.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ ack -- rb ] At 09:04 AM 6/3/2001, Bill Manning wrote:- > The DISCOVER opcode > >This document is an Internet-Draft and is NOT offered in accordance with >Section 10 of RFC2026, and the author does not provide the IETF with any >rights other than to publish as an Internet-Draft. This document is a >submission to the domain name system extentions (DNSEXT) working group >of the Internet Engineering Task Force (IETF). Comments may be submitted >to the working group mailing list at "namedroppers@ops.ietf.org" or the >author. Distribution of this memo is unlimited. It has been pointed out to me that the above copyright is not in compliance with section 10 in RFC2026 thus no IETF working groups can consider this document. Moderators, please do not approve any messages related to this draft on namedroppers until the draft has been reissued with a copyright permitted under section 10 in RFC2026. This note does not reflect in any way on any technical merits of the document. thanks Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 6 08:46:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28571 for ; Wed, 6 Jun 2001 08:46:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157cCz-000OTI-00 for namedroppers-data@psg.com; Wed, 06 Jun 2001 05:14:45 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157cCx-000OTC-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 05:14:43 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157cC3-0002f5-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 08:13:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010605221149.00af1d70@localhost> Date: Tue, 05 Jun 2001 23:34:29 -0400 To: Roy Arends , Scott Rose From: Olafur Gudmundsson Subject: Re: null DK records at the parent Cc: DNSEXT WG Mailing list , dnssec@cafax.se In-Reply-To: References: <001801c0edc8$2bb1f960$b9370681@antd.nist.gov> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 09:21 PM 6/5/2001, Roy Arends wrote: >[cross-posted reply to dnssec@cafax.se] > >On Tue, 5 Jun 2001, Scott Rose wrote: > > > I haven't seen much discussion about the DK record draft on this or = > > cafax.se lists, so I'd thought I'd get the ball rolling: > > > > The reason for needing null DK (or KEYs) in the parent, as I see it, is = > > that a security aware resolver knows to expect a DK or KEY in the glue = > > data when getting a delegation. If it doesn't, it knows to query for = > > them to determine the security status of the child. If it gets a null = > > DK/KEY record, then receives a self-signed KEY from the child, the = > > resolver knows the child is experimentally secure. In these two = > > schemes, the parent is responsible for stating the security status of = > > the delegated child. =20 The main argument for NULL DK is to avoid having to look for the parents NXT and look inside it. Background: in order to get the upper/parent NXT a query to an authoritative server is required. If server is authoritative for both parent and child it may not give out both NXTs. (The ENDS0 ZONE option addresses this). > > One thing that might be helpful to add to the DK draft (or the key = > > rollover draft) is how DK records should be used when performing a key = > > rollover. It might be helpful when learning how to perform a secure key = > > rollover. I debated putting that in, but decided against that in order to keep the draft focused on the core idea (not using KEY record in parent). There are two main key rollover strategies for DK 3 step (old key, old +new key, new key) Master key that does not rollover and only signs the child KEY set. The master key idea comes from the discussion on how to maintain the same root key for a long time. >When using the sig@parent/DK schemes, there is no fundamental difference >between obsoleting the NULL-key qualification and requiring a NULL-key at >the parent (it is unnecessary redundant). IIRC RFC 2535 stated that >sig@parent is optional, and therefore the parent needed to specify some >info when it wants to specify that the parent regards the child as >not secured. See above discussion, but if NXT/NO is tossed out then this is not redundant. >With the new drafts, the parent is required to give information on the >childs security status, in the case that the child is secured by the >parent. If the parent does not consider the child to be secure, obsoleting >sig/key/DK@parent is sufficient. ie, no information is in this case also >information. Correct, if your resolver can talk directly to the authoritative server (preferably using TSIG or SIG(0)). Explicit records can be cached for a while but negative answers can not. >When a dnssec-aware-resolver stumbles upon a child which claims to be >secure, I see 3 different options. >1) the child key is self-signed and the resolver has this key > preconfigured: > It can easily verify the signatures. (but then, why would this resolver > go top down from the root) > >2) the child key is self-signed and the resolver has no knowledge of this > key: unsecure zone. > >3) The child key is signed by some key other then their own or its parent: > The resolver needs to securely resolve this key (or could have it > preconfigured). No one is talking about off tree validation so this case does not apply. RFC3090 does cover the different cases in more gory details. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 6 09:11:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29473 for ; Wed, 6 Jun 2001 09:11:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157cl8-000OrP-00 for namedroppers-data@psg.com; Wed, 06 Jun 2001 05:50:02 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157cl8-000OrI-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 05:50:02 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157cl7-0002gj-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 08:50:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106060902.LAA29046@omval.tednet.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 6 Jun 2001 11:02:53 +0200 In-Reply-To: "Roy Arends's message as of Jun 6, 2:20" Reply-To: Ted.Lindgreen@tednet.nl To: Roy Arends , Scott Rose Subject: Re: null DK records at the parent Cc: DNSEXT WG Mailing list , dnssec@cafax.se Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Roy Arends, on Jun 6, 2:20, in "Re: null DK records ..."] > When a dnssec-aware-resolver stumbles upon a child which claims to be > secure, I see 3 different options. I think this sentense reviels two general misunderstandings: 1. A resolver does not "stumble" onto childs. 2. A child can not claim to be secure. ad 1. DNS is designed for, and used to, lookup specific information. It is not a search mechanisme. ad 2. If anyone uses claims from a certain zone itself, this zone is by definition hijackable. To be secure aware, a resolver must establish the security of a particular zone independendly of that zone. And then, if the zone is indeed supposed to be secured, it must check the chain from a known (i.e. preconfigured) KEY towards the SIG of the RRset that it had asked for. The chain can be followed forwards or backwards, but that is an implementation issue (I guess that a wisely written implementation caches KEYs after verification, so it does not have to go down and up all the time for every lookup). So, how does that impact on your statements: > 1) the child key is self-signed and the resolver has this key > preconfigured: > It can easily verify the signatures. (but then, why would this resolver > go top down from the root) This is correct, we are talking about a secured entrypoint here, with the info directly available. > 2) the child key is self-signed and the resolver has no knowledge of this > key: unsecure zone. This statement is incorrect. There are 2 possibilities: A. The resolver has established that this child is secured, but the key used is unknown, then it follows that the child is BAD and certainly not unsecured. B. The resolver has established that this child is not secured, then childs KEY RRs (if any) are irrelevant. > 3) The child key is signed by some key other then their own or its parent: > The resolver needs to securely resolve this key (or could have it > preconfigured). Again incorrect, see f.i. B above. > In any case, important is when a child is bad: > only if the parent states that a child is secure, and the child can > not offer valid signatures. Defining valid in this case: No sigs or > corrupt sigs. Yes, indeed this is the important question, however, the answer given is incompleet, I'm affraid: - If the parent states that a child is secured, then not only must the child have valid sigs, but also the KEY that the child has used must be checked. Usually (on-tree validation) by checking the parental SIG over that KEY. The real questions are: 1. How does a (secured) parent state that a child is secure, and how if it is not secured? Important is, that this is done in a manner that can be implemented and maintained in real-life situations (think of large TLDs). 2. How does a resolver find this out in a predictible manner from possible second- and third-hand cached information? I don't have all the answers, but for now, I have concluded: - Following RFC2535, with NULL-KEYs @ parent and real KEYs @ child makes 1 very difficult. - Using the SIG@parent idea solves the problems in 1, but introduces problems in 2. - The idea of the DELS RR seems to solve the problems in 1, without introducing problems in 2. Regards, -- ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 6 09:27:36 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00030 for ; Wed, 6 Jun 2001 09:27:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157d0M-000PBs-00 for namedroppers-data@psg.com; Wed, 06 Jun 2001 06:05:46 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157d0M-000PBm-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 06:05:46 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157d0L-000314-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 09:05:45 -0400 Date: Wed, 6 Jun 2001 14:53:02 +0200 (CEST) From: Roy Arends To: Olafur Gudmundsson Cc: Roy Arends , Scott Rose , DNSEXT WG Mailing list , dnssec@cafax.se Subject: Re: null DK records at the parent In-Reply-To: <5.1.0.14.0.20010605221149.00af1d70@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 5 Jun 2001, Olafur Gudmundsson wrote: > At 09:21 PM 6/5/2001, Roy Arends wrote: > >[cross-posted reply to dnssec@cafax.se] > > > >On Tue, 5 Jun 2001, Scott Rose wrote: > > > > > I haven't seen much discussion about the DK record draft on this or = > > > cafax.se lists, so I'd thought I'd get the ball rolling: > > > > > > The reason for needing null DK (or KEYs) in the parent, as I see it, is = > > > that a security aware resolver knows to expect a DK or KEY in the glue = > > > data when getting a delegation. If it doesn't, it knows to query for = > > > them to determine the security status of the child. If it gets a null = > > > DK/KEY record, then receives a self-signed KEY from the child, the = > > > resolver knows the child is experimentally secure. In these two = > > > schemes, the parent is responsible for stating the security status of = > > > the delegated child. =20 > > The main argument for NULL DK is to avoid having to look for the > parents NXT and look inside it. Looking at DK RR type in the nxt@parent for the child or looking for a NULL-DK@parent for the child is to me the same. The secure resolver has to do 1 lookup in both cases. This is ofcourse when NXT/NO are not tossed out. > Background: in order to get the upper/parent NXT a query to an authoritative > server is required. If server is authoritative for both parent and child it may > not give out both NXTs. (The ENDS0 ZONE option addresses this). This I had overlooked. Is it valid though to require huge amounts of information (ie. null-DK RRs) for the rare case that parent and child are both secure and are served by the same server ? Looks to me like a paradox. Especially those servers that serve both secured parents and secure childs do not have the burden of serving null-DK RRs. If this is assumed to be valid I see no alternative then requiring null-DK. > > > One thing that might be helpful to add to the DK draft (or the key = > > > rollover draft) is how DK records should be used when performing a key = > > > rollover. It might be helpful when learning how to perform a secure key = > > > rollover. > > I debated putting that in, but decided against that in order to keep the > draft focused on the core idea (not using KEY record in parent). > There are two main key rollover strategies for DK > 3 step (old key, old +new key, new key) > Master key that does not rollover and only signs the child KEY set. > The master key idea comes from the discussion on how to maintain the same root > key for a long time. > > >When using the sig@parent/DK schemes, there is no fundamental difference > >between obsoleting the NULL-key qualification and requiring a NULL-key at > >the parent (it is unnecessary redundant). IIRC RFC 2535 stated that > >sig@parent is optional, and therefore the parent needed to specify some > >info when it wants to specify that the parent regards the child as > >not secured. > > See above discussion, but if NXT/NO is tossed out then this is not redundant. True, but this discussion was on obsoleting NULL-DK RR, not on obsoleting NXT/NO records. > >With the new drafts, the parent is required to give information on the > >childs security status, in the case that the child is secured by the > >parent. If the parent does not consider the child to be secure, obsoleting > >sig/key/DK@parent is sufficient. ie, no information is in this case also > >information. > > Correct, if your resolver can talk directly to the authoritative server > (preferably using TSIG or SIG(0)). Explicit records can be cached for a while > but negative answers can not. Thats true, especially when NXT/NO records are tossed out. My reply was written with a requirement for NXT/NO records in mind. Regards Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 6 09:27:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00041 for ; Wed, 6 Jun 2001 09:27:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157ctZ-000P1x-00 for namedroppers-data@psg.com; Wed, 06 Jun 2001 05:58:45 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157ctY-000P1r-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 05:58:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157ctY-00030N-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 08:58:44 -0400 Date: Wed, 6 Jun 2001 14:14:39 +0200 (CEST) From: Roy Arends To: Ted Lindgreen Cc: Roy Arends , DNSEXT WG Mailing list , dnssec@cafax.se Subject: Re: null DK records at the parent In-Reply-To: <200106060902.LAA29046@omval.tednet.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 6 Jun 2001, Ted Lindgreen wrote: > [Quoting Roy Arends, on Jun 6, 2:20, in "Re: null DK records ..."] > > > In any case, important is when a child is bad: > > only if the parent states that a child is secure, and the child can > > not offer valid signatures. Defining valid in this case: No sigs or > > corrupt sigs. > > Yes, indeed this is the important question, however, the answer > given is incompleet, I'm affraid: > - If the parent states that a child is secured, then not only must > the child have valid sigs, but also the KEY that the child has > used must be checked. Usually (on-tree validation) by checking > the parental SIG over that KEY. Yes, I fixed this in my second posting. > The real questions are: > 1. How does a (secured) parent state that a child is secure, and > how if it is not secured? Important is, that this is done in > a manner that can be implemented and maintained in real-life > situations (think of large TLDs). > 2. How does a resolver find this out in a predictible manner from > possible second- and third-hand cached information? > > I don't have all the answers, but for now, I have concluded: > - Following RFC2535, with NULL-KEYs @ parent and real KEYs @ child > makes 1 very difficult. > - Using the SIG@parent idea solves the problems in 1, but > introduces problems in 2. > - The idea of the DELS RR seems to solve the problems in 1, > without introducing problems in 2. This doesn't state anything new or clearifies your opinion on null-DK records at the parent. I assume DELS RRs and DK RRs are similar ? Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 6 12:28:47 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04661 for ; Wed, 6 Jun 2001 12:28:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157fn8-0001z2-00 for namedroppers-data@psg.com; Wed, 06 Jun 2001 09:04:18 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157fn7-0001yv-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 09:04:17 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157fn6-00038q-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 12:04:16 -0400 Date: Wed, 6 Jun 2001 15:53:31 +0200 (CEST) From: Roy Arends To: Ted.Lindgreen@tednet.nl Cc: Roy Arends , DNSEXT WG Mailing list , dnssec@cafax.se Subject: Re: null DK records at the parent In-Reply-To: <200106060902.LAA29046@omval.tednet.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 6 Jun 2001, Ted Lindgreen wrote: > [Quoting Roy Arends, on Jun 6, 2:20, in "Re: null DK records ..."] > > > When a dnssec-aware-resolver stumbles upon a child which claims to be > > secure, I see 3 different options. > > I think this sentense reviels two general misunderstandings: > > 1. A resolver does not "stumble" onto childs. > 2. A child can not claim to be secure. > > ad 1. > DNS is designed for, and used to, lookup specific information. It is > not a search mechanisme. > > ad 2. > If anyone uses claims from a certain zone itself, this zone > is by definition hijackable. Let me ellaborate a little on my comments: I meant to say, if the parent holds no information on the childs security status (with sig@parent/DK in mind, not with RFC 2535 in mind on this issue) and a secure aware resolver gets a query-response which holds dnssec RR records (DK,SIG,KEY or NXT/NO) "it stumbles" on this info, because it did not expect this info. You might want to check that I mentioned in the line before the one you quoted: "If the parent does not consider the child to be secure... " In this case, "a child claims to be secure" means, it has all the information it can to be secure, and is therefore dependend on the parents information on the childs secure status. If the parent does not specify this info, the child "claims" to be secure. This is not the same as "the child is secure". ** Its all in the eye of the resolver ** My apologies if this had somewhat confused the reader. > To be secure aware, a resolver must establish the security of a > particular zone independendly of that zone. > And then, if the zone is indeed supposed to be secured, it must > check the chain from a known (i.e. preconfigured) KEY towards the > SIG of the RRset that it had asked for. > The chain can be followed forwards or backwards, but that is an > implementation issue (I guess that a wisely written implementation > caches KEYs after verification, so it does not have to go down and > up all the time for every lookup). > > So, how does that impact on your statements: > > > 1) the child key is self-signed and the resolver has this key > > preconfigured: > > It can easily verify the signatures. (but then, why would this resolver > > go top down from the root) > > This is correct, we are talking about a secured entrypoint here, > with the info directly available. > > > 2) the child key is self-signed and the resolver has no knowledge of this > > key: unsecure zone. > > This statement is incorrect. > There are 2 possibilities: > A. The resolver has established that this child is secured, but the > key used is unknown, then it follows that the child is BAD and > certainly not unsecured. > > B. The resolver has established that this child is not secured, > then childs KEY RRs (if any) are irrelevant. See my statements above. Only B is relevant here, and therefore identical to my statement. > > 3) The child key is signed by some key other then their own or its parent: > > The resolver needs to securely resolve this key (or could have it > > preconfigured). > > Again incorrect, see f.i. B above. See my statements above, and Olafurs statement on this pointing at RFC3090. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 6 22:07:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12831 for ; Wed, 6 Jun 2001 22:07:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 157okC-000CaI-00 for namedroppers-data@psg.com; Wed, 06 Jun 2001 18:37:52 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 157okB-000CaC-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 18:37:51 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 157okB-0004Bw-00 for namedroppers@ops.ietf.org; Wed, 06 Jun 2001 21:37:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106061514.LAA13725@rotala.raleigh.ibm.com> In-Reply-To: Message from Olafur Gudmundsson of "Tue, 05 Jun 2001 22:35:02 EDT." <5.1.0.14.0.20010605222710.00affa40@localhost> To: Olafur Gudmundsson cc: Bill Manning , namedroppers@ops.ietf.org, poised@lists.tislabs.com Subject: Re: mDNS needs something like this Date: Wed, 06 Jun 2001 11:14:58 -0400 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit draft-ymbk-opcode-discover-01.txt contains the wording: > >This document is an Internet-Draft and is NOT offered in accordance with > >Section 10 of RFC2026, and the author does not provide the IETF with any > >rights other than to publish as an Internet-Draft. This document is a > >submission to the domain name system extentions (DNSEXT) working group > >of the Internet Engineering Task Force (IETF). Comments may be submitted > >to the working group mailing list at "namedroppers@ops.ietf.org" or the > >author. Distribution of this memo is unlimited. > It has been pointed out to me that the above copyright is not in > compliance with section 10 in RFC2026 thus no IETF working groups > can consider this document. To clarify a bit. The above boilerplate is contradictory. On the one hand, the submitter does not grant the IETF/WG any rights to excerpt text, modify it, etc., as is the norm in IETF WGs. The only right granted is to publish as an ID. On the other hand, the above text says this document is a submission to the WG. The WG shouldn't be accepting submissions that it has no change control over. That is not the IETF way. Note that it is possible (and appropriate) to submit IDs with a "only publish as an ID" type clause in limited circumstances. For example, there may be times when an outside standards body wishes to make available one of its internal documents for the IETF to look at, but there is no intention that the document will be published as an RFC or modified in any way by the IETF, and the originating standards body wishes to retain full control over the text. However, draft-ymbk-opcode-discover-01.txt would not appear to be one of those types of documents. Finally, the above boilerplate also (by design) sidesteps the question of whether all the rules in Section 10 of RFC 2026 are applicable and are being followed. Again, avoiding that question is not appropriate for a document intended to be a WG contribution. If this document is really intended as a legitimate submission to a WG, it should be resubmitted with appropriate boilerplate. Comments/disagreements on this would best be taken to poisson, as the issues have nothing at all to do with the content of the document. Thomas to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 8 11:24:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14331 for ; Fri, 8 Jun 2001 11:24:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158Nda-000MYI-00 for namedroppers-data@psg.com; Fri, 08 Jun 2001 07:53:22 -0700 Received: from h-135-207-10-176.research.att.com ([135.207.10.176] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 158Nda-000MYC-00 for namedroppers@ops.ietf.org; Fri, 08 Jun 2001 07:53:22 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 158NdZ-00043A-00 for namedroppers@ops.ietf.org; Fri, 08 Jun 2001 10:53:21 -0400 Date: Fri, 8 Jun 2001 10:15:30 -0400 From: Michael Mealling To: namedroppers@ops.ietf.org Subject: Has anyone reviewed draft-josefsson-dns-url-00.txt? Message-ID: <20010608101530.B23711@bailey.dscga.com> Reply-To: Michael Mealling Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Has DNSEXT reviewed the draft draft-josefsson-dns-url-00.txt? I'm going to suggest the author request it be published and put on the standards track. Thanks! -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net | | go:Michael Mealling to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 9 03:30:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11831 for ; Sat, 9 Jun 2001 03:30:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158cio-0000At-00 for namedroppers-data@psg.com; Fri, 08 Jun 2001 23:59:46 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 158cin-0000An-00 for namedroppers@ops.ietf.org; Fri, 08 Jun 2001 23:59:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 158cim-0006aM-00 for namedroppers@ops.ietf.org; Fri, 08 Jun 2001 23:59:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.2.0.58.J.20010609124839.037eccb0@sh.w3.mag.keio.ac.jp> Date: Sat, 09 Jun 2001 12:53:28 +0900 To: Michael Mealling , namedroppers@ops.ietf.org From: Martin Duerst Subject: Re: Has anyone reviewed draft-josefsson-dns-url-00.txt? In-Reply-To: <20010608101530.B23711@bailey.dscga.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 10:15 01/06/08 -0400, Michael Mealling wrote: >Has DNSEXT reviewed the draft draft-josefsson-dns-url-00.txt? I'm going >to suggest the author request it be published and put on the standards >track. Thanks! It looks like something very valuable to do. But it needs quite a bit more work before publication. For example: >>>> This memo is known to be incomplete and perhaps lack some of the background research required to properly define a new URL scheme. Especially the BNF should not be regarded as cast in stone. >>>> >>>> 3. Character encoding considerations Since 8-bit characters are not permitted in URLs, they must be encoded as per the "URI Generic Syntax" RFC. The character set issue should be dealt with in this section, but awaits the outcome of the IDN work group. >>>> Encoding of characters in URIs should be generic, which means that it should be independent of IDN. Please see http://search.ietf.org/internet-drafts/draft-ietf-idn-uri-00.txt for details. Regards, Martin. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 9 17:48:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19468 for ; Sat, 9 Jun 2001 17:48:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 158q8x-00027L-00 for namedroppers-data@psg.com; Sat, 09 Jun 2001 14:19:39 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 158q8x-00027F-00 for namedroppers@ops.ietf.org; Sat, 09 Jun 2001 14:19:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 158q8x-0003Oh-00 for namedroppers@ops.ietf.org; Sat, 09 Jun 2001 14:19:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 9 Jun 2001 23:12:49 +0200 (CEST) From: Roy Arends To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org, dnssec@cafax.se Subject: DK RR & Child's secure status Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, When the DK record is used to indicate the KEY which the child uses to sign its apex KEY RRset, a child _zone_ might or might not be signed. This breaks the secure delegation scheme as the parent has no way of indicating if it considers a child zone secure or not. At least, if I understood the draft right. Regards Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jun 10 12:08:57 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11716 for ; Sun, 10 Jun 2001 12:08:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1597Q2-000BTh-00 for namedroppers-data@psg.com; Sun, 10 Jun 2001 08:46:26 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1597Q1-000BTb-00 for namedroppers@ops.ietf.org; Sun, 10 Jun 2001 08:46:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1597Q1-0008vo-00 for namedroppers@ops.ietf.org; Sun, 10 Jun 2001 08:46:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 10 Jun 2001 14:15:47 +0200 (CEST) From: Roy Arends To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org, dnssec@cafax.se Subject: Re: DK RR & Child's secure status In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 9 Jun 2001, Roy Arends wrote: > Hi, > > When the DK record is used to indicate the KEY which the child uses to > sign its apex KEY RRset, a child _zone_ might or might not be signed. > > This breaks the secure delegation scheme as the parent has no way of > indicating if it considers a child zone secure or not. No, it doesn't break anything. My comments just show a little lack of sleep. My apologies to the lists. 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. From owner-namedroppers@ops.ietf.org Mon Jun 11 13:43:29 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15746 for ; Mon, 11 Jun 2001 13:43:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159Ukw-00033P-00 for namedroppers-data@psg.com; Mon, 11 Jun 2001 09:41:34 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 159Ukw-00033J-00 for namedroppers@ops.ietf.org; Mon, 11 Jun 2001 09:41:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 159Ukw-000M0X-00 for namedroppers@ops.ietf.org; Mon, 11 Jun 2001 09:41:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106111639.MAA14355@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: Indicating Resolver Support of DNSSEC to Proposed Standard Date: Mon, 11 Jun 2001 12:39:56 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'Indicating Resolver Support of DNSSEC' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary In order to deploy DNSSEC operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and the necessary protocol changes to implement that notification. Working Group Summary There was WG concensus to advance this document. Protocol Quality The specification has been reviewed for the IESG by Erik Nordmark. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 12 12:56:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19378 for ; Tue, 12 Jun 2001 12:56:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 159qxE-000KMT-00 for namedroppers-data@psg.com; Tue, 12 Jun 2001 09:23:44 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 159qxE-000KMN-00 for namedroppers@ops.ietf.org; Tue, 12 Jun 2001 09:23:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 159qxE-0008eO-00 for namedroppers@ops.ietf.org; Tue, 12 Jun 2001 09:23:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010612120012.00b28e50@localhost> Date: Tue, 12 Jun 2001 12:11:15 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: 50'th IETF DNSEXT agenda items Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It looks like we will have 1 and 1/2 meeting in London. One DNSEXT meeting and one joint DNSEXT and NGTRANS to discuss IPv6 and DNS issues. If you have items that you want discussed in the DNSEXT meeting please send them to me before July 23. There will be a separate message about the joint meeting agenda items. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 15 11:39:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12162 for ; Fri, 15 Jun 2001 11:39:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15AvCu-00014V-00 for namedroppers-data@psg.com; Fri, 15 Jun 2001 08:08:20 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15AvCt-00014P-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 08:08:19 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15AvCs-000M8o-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 08:08:18 -0700 Message-Id: <200106151045.GAA02651@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2782bis-01.txt Date: Fri, 15 Jun 2001 06:45:39 -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 : A DNS RR for specifying the location of services (DNS SRV) Author(s) : A. Gulbrandsen, P. Vixie, L. Esibov Filename : draft-ietf-dnsext-rfc2782bis-01.txt Pages : 12 Date : 14-Jun-01 This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2782bis-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2782bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-rfc2782bis-01.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: <20010614112258.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2782bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2782bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010614112258.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. From owner-namedroppers@ops.ietf.org Fri Jun 15 14:57:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23306 for ; Fri, 15 Jun 2001 14:57:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15AyYd-000HLB-00 for namedroppers-data@psg.com; Fri, 15 Jun 2001 11:42:59 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15AyYX-000HL3-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 11:42:53 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15AyYW-0001tl-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 11:42:52 -0700 Message-Id: <200106151841.f5FIf4G19755@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3123 on DNS APL RR Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 15 Jun 2001 11:41:04 -0700 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3123 Title: A DNS RR Type for Lists of Address Prefixes (APL RR) Author(s): P. Koch Status: Experimental Date: June 2001 Mailbox: pk@TechFak.Uni-Bielefeld.DE Pages: 8 Characters: 14648 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-apl-rr-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3123.txt The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists. This document is a product of the DNS Extensions Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010615113933.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3123 --OtherAccess Content-Type: Message/External-body; name="rfc3123.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010615113933.RFC@RFC-EDITOR.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. From owner-namedroppers@ops.ietf.org Fri Jun 15 21:25:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02586 for ; Fri, 15 Jun 2001 21:25:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15B4Xn-0002fS-00 for namedroppers-data@psg.com; Fri, 15 Jun 2001 18:06:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15B4Xm-0002fM-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 18:06:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15B4Xm-000HAM-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 18:06:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106160104.SAA18144@scv1.apple.com> Subject: Re: Does anyone have application(s) that uses SRV records ? Date: Fri, 15 Jun 2001 18:04:54 -0700 From: Stuart Cheshire To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >We need implementation reports on how good the text in RFC2782 is. >And we need to perform interoperabilty tests that show that >applications follow the specification. > >Any help in getting this done is greatly appreciated. > > thanks > Olafur We at Apple are working on software that uses SRV. I have some comments about RFC 2782. A couple I have made before, some are new. I will send comments in separate mail messages, to keep the subject threads logical. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 15 21:47:16 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03642 for ; Fri, 15 Jun 2001 21:47:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15B4vn-00033I-00 for namedroppers-data@psg.com; Fri, 15 Jun 2001 18:31:19 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15B4vn-00033C-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 18:31:19 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15B4vn-000Hom-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 18:31:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106160123.SAA03176@scv3.apple.com> Subject: RFC 2782: "The SRV RR is unique" Date: Fri, 15 Jun 2001 18:23:01 -0700 From: Stuart Cheshire To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > _Service._Proto.Name TTL Class SRV Priority Weight Port Target > Name > The domain this RR refers to. The SRV RR is unique in that the > name one searches for is not this name; the example near the end > shows this clearly. I understand that this text is intended to be helpful, but I feel it risks confusing the reader more than it helps. As far as a name server implementation is concerned, an SRV record is simply a record type attached to a domain name (the word domain is used here in the strict RFC 1034 sense). The fact that this RFC recommends a certain naming convention, that the domain name to which the SRV record is attached should take the form "_Service._Proto.parentdomain.TLD", is of no special concern to a name server implementer. To a name server implementer a query for an SRV record is merely a query specifying a given domain name, and record type "SRV". Any special naming conventions for that domain name are a contract between the client making the request, and the entity that placed the SRV record into the server. The server software itself need not know any of that; it need just obey normal DNS protocol rules. Indeed, neither BIND nor "nslookup" take any steps to reject SRV names that fail to follow this naming convention, as well they should not. I suggest the following text: > _Service._Proto.Domain TTL Class SRV Priority Weight Port Target > Domain > The domain this RR refers to. The SRV RR is unique in that the > names of all the SRV RRs for a domain appear logically as > children (subdomains) of that domain, with names constructed > programmatically according to the following convention: > SrvDomainName = _Service._Proto.ParentDomainName > The example near the end shows this clearly. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 15 21:48:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03653 for ; Fri, 15 Jun 2001 21:48:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15B4zJ-000371-00 for namedroppers-data@psg.com; Fri, 15 Jun 2001 18:34:57 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15B4zJ-00036v-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 18:34:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15B4zJ-000Hum-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 18:34:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106160133.SAA22707@scv1.apple.com> Subject: RFC 2782: SRV naming convention Date: Fri, 15 Jun 2001 18:33:13 -0700 From: Stuart Cheshire To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Proto > The symbolic name of the desired protocol, with an underscore > (_) prepended to prevent collisions with DNS labels that occur > in nature. _TCP and _UDP are at present the most useful values > for this field, though any name defined by Assigned Numbers or > locally may be used (as for Service). The Proto is case > insensitive. Does this really mean ANY name? How about "_smtp._http.example.com"? (Mail tunnelled over http) Along those lines, can the protocol or service be further decomposed into layers? What about "_smtp._http._tcp.example.com" (Mail tunnelled over http which runs over tcp)? What about "_telnet.example.com" (telnet only runs over tcp, so it is redundant and unnecessary to specify that in the SRV)? Paul Vixie pointed out to me in private conversation over lunch one day that I was putting far too much importance on this naming convention. (Though I'm not the only one to make that mistake). Paul pointed out to me that this naming convention is merely that -- a convention. It is not a strict requirement of the SRV record type. In fact it's not a requirement of the SRV record type at all, merely an associated recommendation. This RFC recommends that future standards using SRV records follow this naming convention, and that's a good recommendation, but not an absolute rule. It is certainly wise to follow this convention, because if there is ambiguity about what name a client of a particular service should be looking for, then things aren't going to interoperate very well. However, if some future standard clearly defines how to name an SRV record for some specific use, then that future standard is not bound to follow this specific naming convention. I suggest adding the following text: >This naming convention is not a strict requirement of the SRV >record type. It is strongly recommended, but not required, that >future standards using SRV records follow this naming convention >where appropriate, because interoperability is improved when there >is no ambiguity about what name a client should be looking up. >However, if some future standard clearly defines how to name an SRV >record for some specific use, then that future standard is not >bound to follow this specific naming convention. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 16 01:53:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09546 for ; Sat, 16 Jun 2001 01:53:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15B8k9-0006dX-00 for namedroppers-data@psg.com; Fri, 15 Jun 2001 22:35:33 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15B8k8-0006dP-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 22:35:32 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15B8k8-000Oe5-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 22:35:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106160149.SAA06778@scv3.apple.com> Subject: RFC 2782: "Unless and until permitted by future standards" Date: Fri, 15 Jun 2001 18:49:28 -0700 From: Stuart Cheshire To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Unless and until permitted by future standards > action, name compression is not to be used... Are we at that point yet? How many name servers still don't understand SRV? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 16 01:53:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09557 for ; Sat, 16 Jun 2001 01:53:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15B8kI-0006eH-00 for namedroppers-data@psg.com; Fri, 15 Jun 2001 22:35:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15B8kI-0006eB-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 22:35:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15B8kI-000OeX-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 22:35:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106160150.SAA25548@scv1.apple.com> Subject: Re: RFC 2782 (SRV RRs) Interop testing report Date: Fri, 15 Jun 2001 18:50:47 -0700 From: Stuart Cheshire cc: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >The comment about the priority and weight subsections seems a bit >odd given that the specification has MUST and SHOULD laguage for >those two fields in question. > >Thus I think there needs to be enough interoperatbility testing to >verify that the language in those subsections is clear enough for >implementors. > >So the tests need to take into account the actual software on the >clients which honor the priority and weight fields in the RR - if >this isn't done we have no idea whether the description in the >specification is clear enough. > >This means testing with different priority and weight fields. I agree with Erik's comments here. In addition, I'd prefer that the priority and weight fields have precisely defined semantics for all SRV records, without the escape clause the RFC currently has, "In the absence of a protocol whose specification calls for the use of other weighting information...". It has previously been noted that, "some programs only try the first address they get back from e.g. gethostbyname() and we don't know how widespread this behavior is." For this reason, the "Open Transport" networking APIs on Mac OS provide a connect-by-name capability, where the application just calls "Connect("hostname") and it is the OS responsibility to handle multiple addresses, if present, and to try them all in order. This makes it much easier for a Mac application to "do the right thing" even when the application programmer is not necessarily a networking expert. By the same token, we'd like to make the OS handle SRV records and weighted server selection automatically on behalf of the application, and that's much easier if the priority and weight fields always have the same meanings. I'd like to remove the escape clause. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 16 01:53:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09569 for ; Sat, 16 Jun 2001 01:53:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15B8jk-0006d3-00 for namedroppers-data@psg.com; Fri, 15 Jun 2001 22:35:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15B8jj-0006cx-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 22:35:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15B8jj-000OdD-00 for namedroppers@ops.ietf.org; Fri, 15 Jun 2001 22:35:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106160145.SAA24755@scv1.apple.com> Subject: RFC 2782: SRV weight evaluation Date: Fri, 15 Jun 2001 18:45:19 -0700 From: Stuart Cheshire To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In the presence of records containing weights greater > than 0, records with weight 0 should have a very small chance of > being selected. I think we can improve on this. If weights are to have a sensible intuitive meaning, then (in the presence of records containing weights greater than 0) records with weight 0 should *never* be selected. It should make no sense to mix zero and nonzero weights in one RRSet. SRV already supports 16-bit weights, so one server can be preferred 65535 times as much as another -- i.e. one server used for 99.998% of all queries and the other used for less than 0.002%. If we really need a way to indicate resolution below 0.002%, SRV should use 32-bit weight values. I suggest the following wording: > In the presence of records containing weights greater > than 0, records with weight 0 should never be selected. --- > To select a target to be contacted next, arrange all SRV RRs > (that have not been ordered yet) in any order, except that all > those with weight 0 are placed at the beginning of the list. > > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. Then choose a > uniform random number between 0 and the sum computed > (inclusive), and select the RR whose running sum value is the > first in the selected order which is greater than or equal to > the random number selected. The target host specified in the > selected SRV RR is the next one to be contacted by the client. > Remove this SRV RR from the set of the unordered SRV RRs and > apply the described algorithm to the unordered SRV RRs to select > the next target host. Continue the ordering process until there > are no unordered SRV RRs. This process is repeated for each > Priority. Is a "uniform random number between 0 and the sum computed (inclusive)" intended to imply a uniform random integer, or a uniform random real (aka floating point)? If it is a real number, then saying "inclusive" makes no difference, and the probability of an SRV record with weight zero being chosen (while other SRV records remain at the same priority) is strictly zero, which is fine, and logical. However, floating point calculation is sometimes less efficient to implement, and many implementers are likely to select a random *integer* (which is also suggested by the use of the word "inclusive"). This leads to the following off-by-one bug: Suppose you have two SRV records, one with weight zero and one with weight one: _smtp._tcp.apple.com 0 IN SRV 0 0 25 dontuse.apple.com _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer.apple.com Sorted List: dontuse.apple.com Weight 0 Running Sum 0 mailer.apple.com Weight 1 Running Sum 1 If you now "choose a uniform random integer between 0 and 1 (inclusive)", the values 0 and 1 are equally likely: Value 0 selects dontuse.apple.com (Running Sum 0 is >= Random Integer 0) Value 1 selects mailer.apple.com (Running Sum 1 is >= Random Integer 1) In this example, "mailer" and "dontuse" are equally likely to be selected (and hence get half the mail load each) which was probably not what the sysadmin had in mind when he or she set up relative weights of zero and one. (I realize the desired effect here could have been achieved using different priorities, but the point I'm making is that the weights, as given in this example, do not yield the intuitive result.) To give another example, consider this, where each SRV has the same weight: _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer1.apple.com _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer2.apple.com Sorted List: mailer1.apple.com Weight 1 Running Sum 1 mailer2.apple.com Weight 1 Running Sum 2 If you now "choose a uniform random integer between 0 and 2 (inclusive)", the values 0, 1 and 2 are all equally likely: Value 0 selects mailer1.apple.com (Running Sum 1 is >= Random Integer 0) Value 1 selects mailer1.apple.com (Running Sum 1 is >= Random Integer 1) Value 2 selects mailer2.apple.com (Running Sum 2 is >= Random Integer 2) Here, "mailer1" gets twice as much load as "mailer2" -- again, probably not what the sysadmin had in mind when he or she set up equal relative weights. The problem is the off-by-one bug: If the weights sum to n, then the RFC currently says to select one of (n+1) possible different random integers, and it is the extra "+1" that is skewing the results. The text can be fixed by changing it to say: > To select a target to be contacted next, arrange all SRV RRs (that > have not been ordered yet) in any order. > > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. If all RRs have > weight zero (i.e. the sum is zero), then select any of the RRs at > random. Otherwise, choose a uniform random integer between 0 and the > sum computed minus one (inclusive), and select the RR whose running > sum value is the first in the selected order which is greater than > the random integer selected. The target host specified in the > selected SRV RR is the next one to be contacted by the client. Remove > this SRV RR from the set of the unordered SRV RRs and apply the > described algorithm to the unordered SRV RRs to select the next > target host. Continue the ordering process until there are no > unordered SRV RRs. This process is repeated for each Priority. Note that the only changes here are: 1. A random integer is selected, instead of a random real 2. The sum is from "zero to n-1", instead of "zero to n" 3. The comparison is "greater than" instead of "greater than or equal" This modified text produces the mathematically correct result without resorting to floating point arithmetic. In fact it is better, because all floating point arithmetic is an imprecise approximation of real numbers, and usually produces a slightly imprecise result. This integer algorithm produces mathematically perfect results, with no rounding errors. To repeat the above examples again: First Example _smtp._tcp.apple.com 0 IN SRV 0 0 25 dontuse.apple.com _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer.apple.com Sorted List: dontuse.apple.com Weight 0 Running Sum 0 mailer.apple.com Weight 1 Running Sum 1 Choose a uniform random integer between 0 and n-1 inclusive: The only answer is zero. Value 0 does not select dontuse (Running Sum 0 not > Random Integer 0) Value 0 selects mailer.apple.com (Running Sum 1 is > Random Integer 0) In this example, "mailer" is used all the time, and dontuse is never used. (Correct -- don't mix zero and nonzero weights in one RRSet!) Second Example _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer1.apple.com _smtp._tcp.apple.com 0 IN SRV 0 1 25 mailer2.apple.com Sorted List: mailer1.apple.com Weight 1 Running Sum 1 mailer2.apple.com Weight 1 Running Sum 2 If you now "choose a uniform random integer between 0 and 1", the values 0 and 1 are all equally likely: Value 0 selects mailer1.apple.com (Running Sum 1 is > Random Integer 0) Value 1 selects mailer2.apple.com (Running Sum 2 is > Random Integer 1) Here, "mailer1" and "mailer2" get equal load. This is correct. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 18 03:28:58 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01669 for ; Mon, 18 Jun 2001 03:28:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15BsvK-000CHU-00 for namedroppers-data@psg.com; Sun, 17 Jun 2001 23:54:10 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15BsvJ-000CHO-00 for namedroppers@ops.ietf.org; Sun, 17 Jun 2001 23:54:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15BsvJ-0002dM-00 for namedroppers@ops.ietf.org; Sun, 17 Jun 2001 23:54:09 -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.16 #1) id 15BgUu-000Lls-00 for namedroppers@ops.ietf.org; Sun, 17 Jun 2001 10:38:04 -0700 Received: from oemcomputer.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.3/8.11.2) with ESMTP id f5HHc4V02192 for ; Sun, 17 Jun 2001 13:38:05 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.0.14.0.20010617110416.00b39710@wheresmymailserver.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Jun 2001 11:05:50 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson/DNSEXT co-chair Subject: Working group ID submission before IETF-51 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Cutoff for 00 drafts is July 13'th, due to chair travel approvals may take few days. Last time I discovered that pre approvals worked wonders so please send me an early draft by the 9'th and I will send in pre approval. Cutoff for other drafts is July 20. Olafur (DNSEXT co-chair). to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 18 13:32:20 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14299 for ; Mon, 18 Jun 2001 13:32:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15C2Pj-000PsG-00 for namedroppers-data@psg.com; Mon, 18 Jun 2001 10:02:11 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15C2Pi-000Ps7-00 for namedroppers@ops.ietf.org; Mon, 18 Jun 2001 10:02:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15C2Pi-000JLa-00 for namedroppers@ops.ietf.org; Mon, 18 Jun 2001 10:02:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: RFC 2782: SRV naming convention Date: Mon, 18 Jun 2001 09:55:57 -0700 Message-ID: From: "Christian Huitema" To: "Stuart Cheshire" , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > How about "_smtp._http.example.com"? (Mail tunnelled over http) Along > those lines, can the protocol or service be further decomposed into > layers? What about "_smtp._http._tcp.example.com" (Mail tunnelled over > http which runs over tcp)? Something like that might limitations of the SRV format perceived by several WG -- notably SIP and IMPP. The problem occurs when a service can run on several protocols. For example, SIP can run over UDP, TCP and possibly SCTP or TLS; IMPP services can be provided through SIMPLE, APEX, PRIM and possibly others. How can we discover not just a server name and a port, but also a transport protocol and possibly an application protocol? If a given client only supports some of the options, how do we restrict the discovery to the server that support common options? Another extension that has been suggested is to take account some form of locality, as in "I am in subnet number X, in domain example.com, and I want to find an LDAP server; which is the most appropriate one?" -- Christian Huitema=20 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 18 14:34:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16200 for ; Mon, 18 Jun 2001 14:34:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15C3c9-0001nK-00 for namedroppers-data@psg.com; Mon, 18 Jun 2001 11:19:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15C3c8-0001nE-00 for namedroppers@ops.ietf.org; Mon, 18 Jun 2001 11:19:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15C3c8-000LRx-00 for namedroppers@ops.ietf.org; Mon, 18 Jun 2001 11:19:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 18 Jun 2001 14:11:16 EDT From: Jeffrey Altman To: "Christian Huitema" Cc: "Stuart Cheshire" , Subject: RE: RFC 2782: SRV naming convention In-Reply-To: Your message of Mon, 18 Jun 2001 09:55:57 -0700 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > How about "_smtp._http.example.com"? (Mail tunnelled over http) Along > > those lines, can the protocol or service be further decomposed into > > layers? What about "_smtp._http._tcp.example.com" (Mail tunnelled over > > http which runs over tcp)? > > Something like that might limitations of the SRV format perceived by > several WG -- notably SIP and IMPP. The problem occurs when a service > can run on several protocols. For example, SIP can run over UDP, TCP and > possibly SCTP or TLS; IMPP services can be provided through SIMPLE, > APEX, PRIM and possibly others. How can we discover not just a server > name and a port, but also a transport protocol and possibly an > application protocol? If a given client only supports some of the > options, how do we restrict the discovery to the server that support > common options? > > Another extension that has been suggested is to take account some form > of locality, as in "I am in subnet number X, in domain example.com, and > I want to find an LDAP server; which is the most appropriate one?" Use a TXT record to query the protocol types and then use a SRV query to determine where that service/protocol is located. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 18 15:19:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17629 for ; Mon, 18 Jun 2001 15:19:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15C4Lc-00035I-00 for namedroppers-data@psg.com; Mon, 18 Jun 2001 12:06:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15C4Lb-00035C-00 for namedroppers@ops.ietf.org; Mon, 18 Jun 2001 12:06:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15C4Lb-000MrR-00 for namedroppers@ops.ietf.org; Mon, 18 Jun 2001 12:06:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Richard Barr Hibbs" To: Subject: RE: RFC 2782: "The SRV RR is unique" Date: Mon, 18 Jun 2001 12:00:25 -0700 Message-ID: In-Reply-To: <200106160123.SAA03176@scv3.apple.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The DHC working group "suggested" a way to construct the Client Identifier, used to uniquely identify a client host to the server, and that has been misused, abused, misinterpreted, misunderstood, and the source of many rounds of discussion (argument??) about how to identify DHCP clients ever since, with many users and some implementers believing that the text required or demanded certain form and functionality that was not clearly specified. The lesson from the DHC working group is to be *very* careful about "suggestions" for the content of items (in this case, the domain name for an SRV record) because suggestions are often poorly implemented. --Barr Hibbs > -----Original Message----- > From: Stuart Cheshire > Sent: Friday, June 15, 2001 18:23 > > As far as a name server implementation is concerned, an SRV record is > simply a record type attached to a domain name (the word domain is used > here in the strict RFC 1034 sense). The fact that this RFC recommends a > certain naming convention, that the domain name to which the SRV record > is attached should take the form "_Service._Proto.parentdomain.TLD", is > of no special concern to a name server implementer. > > To a name server implementer a query for an SRV record is merely a query > specifying a given domain name, and record type "SRV". Any special naming > conventions for that domain name are a contract between the client making > the request, and the entity that placed the SRV record into the server. > The server software itself need not know any of that; it need just obey > normal DNS protocol rules. Indeed, neither BIND nor "nslookup" take any > steps to reject SRV names that fail to follow this naming convention, as > well they should not. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 19 19:10:23 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07332 for ; Tue, 19 Jun 2001 19:10:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CUCu-0003Jh-00 for namedroppers-data@psg.com; Tue, 19 Jun 2001 15:42:48 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15CUCu-0003Jb-00 for namedroppers@ops.ietf.org; Tue, 19 Jun 2001 15:42:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CUCt-000GWk-00 for namedroppers@ops.ietf.org; Tue, 19 Jun 2001 15:42:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B2FD478.74DF935C@daimlerchrysler.com> Date: Tue, 19 Jun 2001 18:38:48 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Another extension that has been suggested is to take account some form > of locality, as in "I am in subnet number X, in domain example.com, and > I want to find an LDAP server; which is the most appropriate one?" Does the SRV protocol prohibit a nameserver from manipulating priorities and/or weights in its answers depending on the source address of the requesting client? Perhaps this "localization" can be done within the implementation and there's no need to burden the protocol with it. This would just be a more sophisticated version of the A-record sorting mechanisms in use today. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 19 20:31:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08897 for ; Tue, 19 Jun 2001 20:31:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CVZF-00067W-00 for namedroppers-data@psg.com; Tue, 19 Jun 2001 17:09:57 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15CVZF-00067Q-00 for namedroppers@ops.ietf.org; Tue, 19 Jun 2001 17:09:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CVZF-000LrQ-00 for namedroppers@ops.ietf.org; Tue, 19 Jun 2001 17:09:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106200009.RAA18518@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention In-Reply-To: Message from Kevin Darcy of "Tue, 19 Jun 2001 18:38:48 EDT." <3B2FD478.74DF935C@daimlerchrysler.com> Date: Tue, 19 Jun 2001 17:09:05 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Does the SRV protocol prohibit a nameserver from manipulating priorities > and/or weights in its answers depending on the source address of the > requesting client? No. DNS itself does that. It has nothing to do with SRV. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 20 01:40:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16693 for ; Wed, 20 Jun 2001 01:40:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15CaQ7-000Gg3-00 for namedroppers-data@psg.com; Tue, 19 Jun 2001 22:20:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15CaQ7-000Gfx-00 for namedroppers@ops.ietf.org; Tue, 19 Jun 2001 22:20:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15CaQ7-000GyM-00 for namedroppers@ops.ietf.org; Tue, 19 Jun 2001 22:20:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B301261.D494A25D@daimlerchrysler.com> Date: Tue, 19 Jun 2001 23:02:57 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention References: <200106200009.RAA18518@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: >> Does the SRV protocol prohibit a nameserver from manipulating priorities >> and/or weights in its answers depending on the source address of the >> requesting client? > > No. > > DNS itself does that. I disagree. It's just a volatile RRset that happens to change in accordance with the requesting client's source address. Surely this violates no DNS specs. Alternatively, each client is being answered from a different DNS namespace (like BIND 9's "view"s). I see answer-differentiation being legal under either formulation. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 20 06:31:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01569 for ; Wed, 20 Jun 2001 06:31:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cf1G-0005cn-00 for namedroppers-data@psg.com; Wed, 20 Jun 2001 03:15:30 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15Cf1G-0005ch-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 03:15:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15Cf1F-000Je9-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 03:15:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106200859.BAA25002@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention In-Reply-To: Message from Kevin Darcy of "Tue, 19 Jun 2001 23:02:57 EDT." <3B301261.D494A25D@daimlerchrysler.com> Date: Wed, 20 Jun 2001 01:59:14 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ... It's just a volatile RRset that happens to change in accordance > with the requesting client's source address. Surely this violates no > DNS specs. It wouldn't be DNS at all if it were "volatile" in that way. DNS, on the other hand, is coherent. If you want to synthesize responses in that way, be sure to write a draft and be sure to specify that TTL is always zero. > Alternatively, each client is being answered from a different DNS > namespace (like BIND 9's "view"s). I see answer-differentiation being > legal under either formulation. BIND's "view" mechanism is intended for use by disparite reachability domains. Sending multiple incoherent answers into a single reachability domain would be a protocol (the DNS protocol, that is) violation. People who do it with A RR's to try to get naively modelled clients to come to a "closer" web server are just fooling themselves (and irritating the rest of us). But with an RFC that specified TTL 0 (among other things) this could become part of the protocol. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 20 12:01:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12025 for ; Wed, 20 Jun 2001 12:01:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ck4R-000Gie-00 for namedroppers-data@psg.com; Wed, 20 Jun 2001 08:39:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15Ck4Q-000GiX-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 08:39:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15Ck4Q-000EwZ-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 08:39:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106201153.f5KBrUm04017@hygro.adsl.duke.edu> To: Robert Elz cc: iesg@ietf.org, poised@lists.tislabs.com, namedroppers , Randy Bush , Olafur Gudmundsson Subject: Re: Inactivity appeal In-Reply-To: Message from Robert Elz of "Tue, 19 Jun 2001 02:10:52 +0700." <4805.992891452@brandenburg.cs.mu.OZ.AU> Date: Wed, 20 Jun 2001 07:53:30 -0400 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The Internet ADs have reviewed the set of events related to the posting of draft-ymbk-opcode-discover-01.txt to the namedroppers mailing list and the subsequent decision to block discussion of the ID on the namedroppers list. This note requests that discussion of the draft resume on the WG mailing list and notes that one significant issue with the document has apparently been rectified in the just-submitted -02 ID. Background: On June 3, 2001, Bill Manning posted a message to the namedroppers mailing list that included the entire contents of draft-opcode-discover-01.txt. That ID contains boilerplate text that includes the words: > This document is an Internet-Draft and is NOT offered in accordance > with Section 10 of RFC2026, and the author does not provide the IETF > with any rights other than to publish as an Internet-Draft. This > document is a submission to the domain name system extentions > (DNSEXT) working group of the Internet Engineering Task Force > (IETF). At that time, the Internet and other ADs noted and discussed the boilerplate text, and then pointed out to the WG chairs that a document with such boilerplate was not appropriate for discussion on an IETF WG mailing list. There main reason for this is: - The above boilerplate indicates that the contribution is not subject to all the rules in Section 10 of RFC 2026. WGs should not spend significant cycles on documents with such risks, lest they invest cycles working on a technology for which IPR issues are discovered at a later time that should have been disclosed earlier. Furthermore, allowing significant WG discussion of such documents raises serious issues as to whether the IETF is following its own rules for openness. Such an issue could, for example, adversly impact the IETF's insurance coverage. Consequently, the WG chairs were asked to limit discussion on the document. In retrospect, the decision to prohibit all discussion of the draft (e.g., including whether it was relevant to the WG) was too strong. With this note, we request that that WG chairs allow discussion of the draft on the WG mailing list, with the following caveats. The document cannot become a WG document until/unless it is submitted with boilerplate statement 1. Statement 2 & 3 boilerplates do not grant the IETF/WG any rights to produce a followup ID, excerpt text, modify text, etc., as is necessary for IETF WGs to do their work. Note that there have been cases in the past where a document author has included a restricted copyright clause in a document, had the WG invest cycles in the ID, and then subsequently refused to make specific changes requested by the WG, forcing the WG to rewrite a document from scratch in order to avoid copyright infringement issues. This can waste significant time and WG resources and should be avoided. The Chairs and the WG should keep this in mind as discussion takes place. The WG & WG chairs should note that with a statement 3 boilerplate, the author is specifically disclaiming the need to adhere to the IPR portions of section 10 of 2026. This is at odds with the IETF's own stated rules for a WG contribution and is unacceptable for a document for which there is a reasonable expectation that its contents might be incorporated into a WG document. Discussion of such documents on IETF mailing lists should be undertaken carefully and limited to a context that takes into considerations the reasons why statement 3 boilerplate was used and the limitations that implies. Note that the recent submission of a -02 version of the document (posted 6/19/01) contains a statement 2 boilerplate, apparently making the issue moot in this particular case. Thomas & Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 20 12:52:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13794 for ; Wed, 20 Jun 2001 12:52:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Cktj-000Ie8-00 for namedroppers-data@psg.com; Wed, 20 Jun 2001 09:32:07 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15Cktj-000Ie2-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 09:32:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15Cktj-000GNN-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 09:32:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 20 Jun 2001 11:00:55 -0400 (EDT) From: Olafur Gudmundsson To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention In-Reply-To: <3B301261.D494A25D@daimlerchrysler.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 19 Jun 2001, Kevin Darcy wrote: > Paul A Vixie wrote: > > >> Does the SRV protocol prohibit a nameserver from manipulating priorities > >> and/or weights in its answers depending on the source address of the > >> requesting client? > > > > No. > > > > DNS itself does that. > > I disagree. It's just a volatile RRset that happens to change in accordance > with the requesting client's source address. Surely this violates no > DNS specs. Alternatively, each client is being answered from a different > DNS namespace (like BIND 9's "view"s). I see answer-differentiation being > legal under either formulation. > You are confused, view is two different sets offered based on some selection ciriteria, but the set is unchanged in each view for a "long" time. DNS protocol does not allow DNS servers to update zone contents on the fly, but someone may claim that the protocol does not outlaw it either. I know that some load balancers give out different answers (not just reorded) at different times, if that is a subset of and RRset that is fine, as this is same as trunction even if the TC bit is not on. DNSSEC is going to make life hard for these boxes :-) Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 20 13:15:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14622 for ; Wed, 20 Jun 2001 13:15:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15ClJ4-000JCA-00 for namedroppers-data@psg.com; Wed, 20 Jun 2001 09:58:18 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15ClJ3-000JC4-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 09:58:17 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15ClJ3-000H5l-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 09:58:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B30CEC3.FD6675A2@daimlerchrysler.com> Date: Wed, 20 Jun 2001 12:26:43 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur Gudmundsson wrote: > On Tue, 19 Jun 2001, Kevin Darcy wrote: > > > Paul A Vixie wrote: > > > > >> Does the SRV protocol prohibit a nameserver from manipulating priorities > > >> and/or weights in its answers depending on the source address of the > > >> requesting client? > > > > > > No. > > > > > > DNS itself does that. > > > > I disagree. It's just a volatile RRset that happens to change in accordance > > with the requesting client's source address. Surely this violates no > > DNS specs. Alternatively, each client is being answered from a different > > DNS namespace (like BIND 9's "view"s). I see answer-differentiation being > > legal under either formulation. > > > > You are confused, view is two different sets offered based on some > selection ciriteria, but the set is unchanged in each view for a > "long" time. With all due respect, I think you're the one who is confusing the two different potential justifications I gave for why a nameserver might give out different answers, to different clients, to the same question, in quick succession. I apologize if I wasn't clear enough. The first justification is "it's volatile, and happened to change in between queries". The second justification is "I was answering the first client from one namespace, and the second client from another namespace". The second justification has nothing to do with volatility -- it might *always* answer the same way to any given client -- and is indistinguishable from "view"s unless one agrees with Paul's "disparate reachability domains" explanation/exception. > DNS protocol does not allow DNS servers to update zone contents on the > fly, but someone may claim that the protocol does not outlaw it either. Depends on what your definition is of "on the fly". Volatile data has always been accommodated in DNS, and with Dynamic Update, there is no longer a requirement for a nameserver to reload a whole zone just to pick up the change of one RRset. So I think we've arguably already crossed the "on the fly" threshold. Data is changing "on the fly" in nameservers all over the place. The only new issue that is being raised here is: is it permissible to change DNS data on a query-by-query basis? Is that perhaps what you meant by "on the fly"? > I know that some load balancers give out different answers (not just > reorded) at different times, if that is a subset of and RRset that is > fine, as this is same as trunction even if the TC bit is not on. Actually, if for the sake of argument, answer-differentiation is indeed forbidden, doesn't that load-balancer behavior qualify as giving out a partial RRset and isn't it therefore forbidden by RFC 2181? I don't think the fact that the different answers are subsets of some larger "definitive" RRset really saves the behavior from this (alleged) illegality. > DNSSEC is going to make life hard for these boxes :-) Among others... - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 20 13:15:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14639 for ; Wed, 20 Jun 2001 13:15:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15ClIr-000JBx-00 for namedroppers-data@psg.com; Wed, 20 Jun 2001 09:58:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15ClIq-000JBr-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 09:58:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15ClIq-000H5K-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 09:58:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B30CEED.145E3A96@daimlerchrysler.com> Date: Wed, 20 Jun 2001 12:27:25 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention References: <200106200859.BAA25002@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: > > ... It's just a volatile RRset that happens to change in accordance > > with the requesting client's source address. Surely this violates no > > DNS specs. > > It wouldn't be DNS at all if it were "volatile" in that way. RFC 1034, Section 2.3, Assumptions about usage: > - Most of the data in the system will change very slowly (e.g., > mailbox bindings, host addresses), but that the system should > be able to deal with subsets that change more rapidly (on the > order of seconds or minutes). > Sounds like a description of volatile data to me. Or is the emphasis in your sentence on the phrase "in that way", i.e. it's OK for data to be volatile in general, you just can't change it in accordance with something as volatile and/or incoherent as the requesting client's source address? I don't think protocol specifications should be in the business of trying to outlaw evil intent. The reasons *why* a piece of data is changed to a certain (legal) value, or why it changes often, is of no concern to the protocol. > DNS, on the > other hand, is coherent. If you want to synthesize responses in that way, > be sure to write a draft and be sure to specify that TTL is always zero. I think TTL=0 is a red herring. There is nothing in the DNS specs that says resource-record data can't change more frequently than the TTL interval, in practice this happens all of the time, and I'm not aware of any DNS implementation that attempts to enforce any such restriction on change-frequency. It is simply understood that if you change data more frequently than TTL, caching servers and the clients which rely on them, may have "stale" data more often than otherwise. This is a downside that an implementor may be more than happy to live with. > > Alternatively, each client is being answered from a different DNS > > namespace (like BIND 9's "view"s). I see answer-differentiation being > > legal under either formulation. > > BIND's "view" mechanism is intended for use by disparite reachability domains. > Sending multiple incoherent answers into a single reachability domain would > be a protocol (the DNS protocol, that is) violation. What specific part of the protocol is being violated? I don't remember seeing any references to "reachability domains" in any of the main DNS RFCs. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 20 14:36:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17531 for ; Wed, 20 Jun 2001 14:36:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Clqz-000K1V-00 for namedroppers-data@psg.com; Wed, 20 Jun 2001 10:33:21 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15Clqz-000K1N-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 10:33:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15Clqz-000I3g-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 10:33:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: <3B301261.D494A25D@daimlerchrysler.com> Date: Wed, 20 Jun 2001 13:11:19 -0400 To: Olafur Gudmundsson From: Edward Lewis Subject: Re: RFC 2782: SRV naming convention Cc: Kevin Darcy , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:00 AM -0400 6/20/01, Olafur Gudmundsson wrote: >I know that some load balancers give out different answers (not just >reorded) at different times, if that is a subset of and RRset that is >fine, as this is same as trunction even if the TC bit is not on. > >DNSSEC is going to make life hard for these boxes :-) Not necessarily. Just sign all the combinations you want to send out ahead of time. The signature chain only improves the likelyhood that the answer you got is honest, the chain does not speak to its uniqueness. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com You fly too often when ... the airport taxi is on speed-dial. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 20 16:12:50 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20914 for ; Wed, 20 Jun 2001 16:12:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Co1b-000Mab-00 for namedroppers-data@psg.com; Wed, 20 Jun 2001 12:52:27 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15Co1b-000MaV-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 12:52:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15Co1b-000Lor-00 for namedroppers@ops.ietf.org; Wed, 20 Jun 2001 12:52:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 20 Jun 2001 15:19:47 -0400 From: Andrew Brown To: Stuart Cheshire Cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV weight evaluation Message-ID: <20010620151947.A23928@noc.untraceable.net> In-Reply-To: <200106160145.SAA24755@scv1.apple.com>; from cheshire@apple.com on Fri, Jun 15, 2001 at 06:45:19PM -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> In the presence of records containing weights greater >> than 0, records with weight 0 should have a very small chance of >> being selected. > >I think we can improve on this. If weights are to have a sensible >intuitive meaning, then (in the presence of records containing weights >greater than 0) records with weight 0 should *never* be selected. It >should make no sense to mix zero and nonzero weights in one RRSet. SRV >already supports 16-bit weights, so one server can be preferred 65535 >times as much as another -- i.e. one server used for 99.998% of all >queries and the other used for less than 0.002%. If we really need a way >to indicate resolution below 0.002%, SRV should use 32-bit weight values. as a guess, i'd say that "records with a weight of zero in a record set with some non-zero weights will end up being selected last in no particular order". that is to say, all non-zero weighted records will be picked first, and then the zero weight ones will be picked. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth." to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 22 14:39:22 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03968 for ; Fri, 22 Jun 2001 14:39:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DSiE-000EUR-00 for namedroppers-data@psg.com; Fri, 22 Jun 2001 08:19:10 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DSiC-000EUK-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 08:19:09 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15DSCq-0000wu-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 07:46:44 -0700 Message-Id: <200106221114.HAA16182@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-obsolete-iquery-01.txt Date: Fri, 22 Jun 2001 07:14:00 -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 : Obsoleting IQUERY Author(s) : D. Lawrence Filename : draft-ietf-dnsext-obsolete-iquery-01.txt Pages : 4 Date : 21-Jun-01 Based on a lack of working implementations of the IQUERY method of performing inverse DNS lookups, and because an alternative mechanism for doing inverse queries of address records has been successfully used operationally for well over a decade, this draft proposes that the IQUERY operation be entirely obsoleted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-obsolete-iquery-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-obsolete-iquery-01.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: <20010621142211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-obsolete-iquery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-obsolete-iquery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621142211.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. From owner-namedroppers@ops.ietf.org Fri Jun 22 14:40:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04078 for ; Fri, 22 Jun 2001 14:40:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DSiR-000EUm-00 for namedroppers-data@psg.com; Fri, 22 Jun 2001 08:19:23 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DSiQ-000EUg-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 08:19:22 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15DSCJ-0000wq-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 07:46:11 -0700 Message-Id: <200106221111.HAA15785@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-axfr-clarify-02.txt Date: Fri, 22 Jun 2001 07:11:39 -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 : DNS Zone Transfer Protocol Clarifications Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-axfr-clarify-02.txt Pages : 6 Date : 21-Jun-01 In the Domain Name System, zone data is replicated among authoritative DNS servers by means of the 'zone transfer' protocol, also known as the 'AXFR' protocol. This memo clarifies, updates, and adds missing detail to the original AXFR protocol specification in RFC1034. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-axfr-clarify-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010621134303.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-axfr-clarify-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-axfr-clarify-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134303.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. From owner-namedroppers@ops.ietf.org Fri Jun 22 14:44:59 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04247 for ; Fri, 22 Jun 2001 14:44:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DSiW-000EUv-00 for namedroppers-data@psg.com; Fri, 22 Jun 2001 08:19:28 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DSiV-000EUp-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 08:19:27 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15DSNs-0000yV-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 07:58:08 -0700 Date: 22 Jun 2001 14:16:52 -0000 Message-ID: <20010622141652.25108.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: "Unless and until permitted by future standards" References: <200106160149.SAA06778@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Stuart Cheshire writes: > Are we at that point yet? How many name servers still don't understand > SRV? My widely deployed DNS cache has no special SRV-handling code. The required DNS standards do not require special SRV-handling code. The BIND company has recently issued a draft that, among other things, demands that I add SRV-decompression code. All my users are supposed to change their software so that you can save a few bytes in SRV records? I strongly object to the ludicrous notion that every DNS cache should be upgraded for every new DNS record type that contains a domain name. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 22 14:45:08 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04270 for ; Fri, 22 Jun 2001 14:45:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DSic-000EV6-00 for namedroppers-data@psg.com; Fri, 22 Jun 2001 08:19:34 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DSib-000EUy-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 08:19:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15DSiT-00012E-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 08:19:25 -0700 Date: Fri, 22 Jun 2001 10:27:29 -0400 (EDT) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: DNSEXT WGLC AXFR-02 SHORT last call Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document formalizes the definition of Zone transfer protocol that was unspecified in RFC1035. This document formalizes the zone transfer protocol in accordance with the fielded DNS server software. This version is based on the feedback from the last round of WGLC and subsequent comments. The major changes reported by Andreas are: Note that some masters simply close the TCP connection to indicate that they refuse zone transfers, and recommend that this MAY be treated like a REFUSED response, based on suggestions by Sam Trenholme and Robert Elz. Allow responses with RD set unconditionally to 0, as suggested by Dan Bernstein. In a similar vein, allow RA to be unconditionally set to 0. Rewrote section 4 "Glue", changing its title to "Zone data" and incorporating text from Peter Koch. Added the requirement that RRs other than the SOA be transmitted exactly once (Peter Koch suggested a SHOULD, but I think a MUST is warranted) and the recommendation that duplicate RRs be silently ignored when received. Added an Acknowledgments section. Miscellaneous minor editorial changes. As the working group has discussed this document in great detail this is a short WG last call that ends June 30'th 2001. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-02.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 22 15:11:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05365 for ; Fri, 22 Jun 2001 15:11:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DSiG-000EUb-00 for namedroppers-data@psg.com; Fri, 22 Jun 2001 08:19:12 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DSiF-000EUT-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 08:19:11 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15DSCP-0000ws-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 07:46:17 -0700 Message-Id: <200106221111.HAA15809@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ad-is-secure-02.txt Date: Fri, 22 Jun 2001 07:11:44 -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 : Redefinition of DNS AD bit Author(s) : B. Wellington, O. Gudmundsson Filename : draft-ietf-dnsext-ad-is-secure-02.txt Pages : 4 Date : 21-Jun-01 Based on implementation experience, the current definition of the AD bit in the DNS header is not useful. This draft changes the specification so that the AD bit is only set on answers where signatures have been cryptographically verified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ad-is-secure-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010621134312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ad-is-secure-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ad-is-secure-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134312.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. From owner-namedroppers@ops.ietf.org Fri Jun 22 18:27:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13605 for ; Fri, 22 Jun 2001 18:27:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DYGO-000KJO-00 for namedroppers-data@psg.com; Fri, 22 Jun 2001 14:14:48 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DYGN-000KJI-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 14:14:47 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15DYGI-0001Ed-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 14:14:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 22 Jun 2001 11:47:29 -0700 (PDT) Message-Id: <200106221847.LAA12168@gulag.araneus.fi> To: "D. J. Bernstein" CC: namedroppers@ops.ietf.org Subject: Re: RFC 2782: "Unless and until permitted by future standards" In-Reply-To: <20010622141652.25108.qmail@cr.yp.to> References: <200106160149.SAA06778@scv3.apple.com> <20010622141652.25108.qmail@cr.yp.to> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > Stuart Cheshire writes: > > Are we at that point yet? How many name servers still don't understand > > SRV? > > My widely deployed DNS cache has no special SRV-handling code. The > required DNS standards do not require special SRV-handling code. > > The BIND company has recently issued a draft that, among other things, > demands that I add SRV-decompression code. If you are referring to draft-ietf-dnsext-unknown-rrs-00, this is not true. That draft merely *recommends* that you add such code, so that your implementation will interoperate with broken servers that are known to exist in the field. The "SHOULD" in the draft does allow you to omit the code after "carefully weighing" its implications, which I'm sure you have done. With regards to draft-ietf-dnsext-rfc2782bis-00, I think the "unless and until" wording is unfortunate. I can see it being interpreted in two significantly different ways: a) Future standards action may introduce a negotiation mechanism whereby a client can specifically request that a server send it SRV records in compressed form or b) Future standards action may allow servers to compress SRV records in responses by default, without prior negotiation I suspect interpretation a) is the intended one, written with the now-dead EDNS1 protocol in mind as a possible negotiation mechanism. Under this interpretation, the wording is harmless, but it is also unnecessary as such a negotiation mechanism can be introduced (if deemed to be a good idea) without specifically allowing for it in the specification of each RR type. Under interpretation b) it would be unsafe for any DNS implementation to treat SRV records transparently, since compressed names could appear in them at any time after the implementation has been deployed due to "future standards action". This would effectively burden every implementation with having to specifically support SRV decompression, without deriving any benefit from this added effort. It would also directly contradict draft-ietf-dnsext-unknown-rrs-00. Therefore, I propose removing the text "Unless and until permitted by future standards action", leaving just the unambiguous "Name compression is not to be used for this field.". > I strongly object to the ludicrous notion that every DNS cache should be > upgraded for every new DNS record type that contains a domain name. I agree completely. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 22 18:37:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13819 for ; Fri, 22 Jun 2001 18:37:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DYKn-000KOI-00 for namedroppers-data@psg.com; Fri, 22 Jun 2001 14:19:21 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DYKl-000KOB-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 14:19:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15DYKk-0001Ev-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 14:19:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B339C03.1741AE6A@cisco.com> Date: Fri, 22 Jun 2001 15:26:59 -0400 From: Josh Littlefield To: Olafur Gudmundsson CC: DNSEXT mailing list , gson@nominum.com Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur Gudmundsson wrote: > > This version is based on the feedback from the last round of WGLC and > subsequent comments. The major changes reported by Andreas are: > [...] > > Added the requirement that RRs other than the SOA be transmitted > exactly once (Peter Koch suggested a SHOULD, but I think a > MUST is warranted) and the recommendation that duplicate RRs be > silently ignored when received. I would prefer this be a SHOULD rather than a MUST, as Peter Koch suggested. That is, I don't feel its significant to *require* that the server transmit each RR exactly once, though I think it should be recommended. Perhaps this also means that the slave MUST ignore duplicate RRs, by permitting their transmission. Additional comments: In section 3.2, saying that the slave SHOULD ignore the ID in subsequent messages seems incongruous with saying that the master MUST copy the ID from the request into each response packet. I would think the slave MAY ignore the ID in subsequent messages unless the slave has sent multiple requests to the master, in which case the slave MUST NOT ignore the ID in subsequent messages, since they are needed to differentiate the response packets. At the end of section 3.6, I think we should explicitly say that the slave MUST NOT treat additional section RRs as zone data. I think this would help clarify what an "unexpected" RR is, or is not. In section 5, while I appreciate the clarification of the first/last record being an SOA, I think it would be helpful to explicitly state that the transfer is completed by the packet containing the final SOA record. And while we've defined the server behavior as sending the SOA as the last record of the transfer, we haven't specified the client's behavior regarding any answer records which follow this final SOA. I think we are implicitly saying that a client MAY ignore any answer records which follow the final SOA. I'd prefer we say this explicitly. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 23 09:56:39 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11253 for ; Sat, 23 Jun 2001 09:56:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15DgjQ-0003z2-00 for namedroppers-data@psg.com; Fri, 22 Jun 2001 23:17:20 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 15DgjP-0003yw-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 23:17:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15DgjN-0001I0-00 for namedroppers@ops.ietf.org; Fri, 22 Jun 2001 23:17:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B33DEFA.2563993B@daimlerchrysler.com> Date: Fri, 22 Jun 2001 20:12:42 -0400 From: Kevin Darcy To: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The draft is still ambiguous as to how a nameserver should respond -- assuming that it *does* respond, as opposed to just closing the connection -- when it's not authoritative for the requested zone. In the last Last Call, I proposed that RCODE=NOTAUTH and/or AA=0 be explicitly mandated in that situation, but that proposal apparently got buried alive under the whole "is it or is it not OK to just close the connection?" discussion/argument. An unambiguous indication of non-authoritativeness would I think facilitate troubleshooting of AXFR problems/failures. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 25 16:43:07 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26526 for ; Mon, 25 Jun 2001 16:43:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Eclw-0006Uf-00 for namedroppers-data@psg.com; Mon, 25 Jun 2001 13:15:48 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 15Eclw-0006UU-00 for namedroppers@ops.ietf.org; Mon, 25 Jun 2001 13:15:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15EclG-0000oR-00 for namedroppers@ops.ietf.org; Mon, 25 Jun 2001 13:15:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 25 Jun 2001 12:57:49 -0700 (PDT) Message-Id: <200106251957.MAA14666@gulag.araneus.fi> To: Josh Littlefield Cc: Olafur Gudmundsson , DNSEXT mailing list , Andreas.Gustafsson@nominum.com Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <3B339C03.1741AE6A@cisco.com> References: <3B339C03.1741AE6A@cisco.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Josh Littlefield writes: > > Added the requirement that RRs other than the SOA be transmitted > > exactly once (Peter Koch suggested a SHOULD, but I think a > > MUST is warranted) and the recommendation that duplicate RRs be > > silently ignored when received. > > I would prefer this be a SHOULD rather than a MUST, as Peter Koch > suggested. That is, I don't feel its significant to *require* that the > server transmit each RR exactly once, though I think it should be > recommended. I did seriously consider making it a SHOULD, but I couldn't think of any legitimate reason for a server to ever send a RR multiple times. Old BIND servers do send RRs multiple times as a result of the way they handle glue, but that behavior already conflicts with section 4. I don't see how a server could conform to section 4 but still have a reason to transmit a RR multiple times. Allowing the multiplicity would just complicate the protocol without bringing any advantages. > Perhaps this also means that the slave MUST ignore duplicate > RRs, by permitting their transmission. Yes, if we were to just say that the master SHOULD transmit each RR only once, then we would have to make ignoring duplicates a MUST. > In section 3.2, saying that the slave SHOULD ignore the ID in subsequent > messages seems incongruous with saying that the master MUST copy the ID from > the request into each response packet. I don't think this is incongruous - it just mandates being conservative in what you send and recommends being liberal in what you accept. > I would think the slave MAY ignore the ID in subsequent messages I still think a SHOULD is warranted given the large number of deployed masters that fail to copy the ID. > unless the slave has sent multiple requests to > the master, in which case the slave MUST NOT ignore the ID in subsequent > messages, since they are needed to differentiate the response packets. I think this is fairly obvious implementation constraint rather than a protocol issue. As such, I don't think it needs to be stated explicitly in the protocol specification, but if it were, I would prefer to express it a bit differently: "A slave that ignores ID fields cannot have multiple simultaneous outstanding requests on the same TCP connection, since the ID would be needed to differentiate the response messages." > At the end of section 3.6, I think we should explicitly say that the slave > MUST NOT treat additional section RRs as zone data. I think this would help > clarify what an "unexpected" RR is, or is not. OK, I'll add the sentence "It MUST NOT treat additional section RRs as zone data." at the end of 3.6. > In section 5, while I appreciate the clarification of the first/last record > being an SOA, I think it would be helpful to explicitly state that the > transfer is completed by the packet containing the final SOA record. OK, I'll add the text "The slave MUST consider the transfer to be complete when, and only when, it has received the message containing the second SOA record." at the end of the third paragraph of section 5. > And > while we've defined the server behavior as sending the SOA as the last > record of the transfer, we haven't specified the client's behavior regarding > any answer records which follow this final SOA. I think we are implicitly > saying that a client MAY ignore any answer records which follow the final > SOA. I'd prefer we say this explicitly. Are you concerned with the case where other messages follow the one with the final SOA, or the case where other RRs follow the SOA in the answer section of the final message? The first case is outside the scope of the draft since the transfer has already ended (per the definition above). The second case is of course an error on the part of the master, but I don't see why saying the slave "MAY ignore" the extra data would be preferable to simply leaving the slave behavior undefined. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 25 17:43:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27875 for ; Mon, 25 Jun 2001 17:43:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EduM-000929-00 for namedroppers-data@psg.com; Mon, 25 Jun 2001 14:28:34 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 15EduL-00091i-00 for namedroppers@ops.ietf.org; Mon, 25 Jun 2001 14:28:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15Edtb-0000qL-00 for namedroppers@ops.ietf.org; Mon, 25 Jun 2001 14:27:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 25 Jun 2001 14:06:01 -0700 (PDT) Message-Id: <200106252106.OAA14699@gulag.araneus.fi> To: Kevin Darcy Cc: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <3B33DEFA.2563993B@daimlerchrysler.com> References: <3B33DEFA.2563993B@daimlerchrysler.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy writes: > The draft is still ambiguous as to how a nameserver should respond -- assuming > that it *does* respond, as opposed to just closing the connection -- when it's > not authoritative for the requested zone. In the last Last Call, I proposed > that RCODE=NOTAUTH and/or AA=0 be explicitly mandated in that situation, but > that proposal apparently got buried alive under the whole "is it or is it not > OK to just close the connection?" discussion/argument. > > An unambiguous indication of non-authoritativeness would I think facilitate > troubleshooting of AXFR problems/failures. I agree that an unambiguous indication of non-authoritativeness would be a good thing, but I think mandating RCODE=NOTAUTH and/or AA=0 (as in making them REQUIRED) would be contrary to the draft's stated purpose of clarifying rather than changing the protocol defined in RFC103[45]. In particular, the NOTAUTH result code had not yet been defined RFC1034/1035 were written, making it hard to argue that mandating its use is a mere clarification of the original intent of the protocol designers. I don't want to declare an otherwise fully conforming implementation non-conforming just because its implementers did not foresee the future introduction of RCODE 9. I don't have a problem with a SHOULD, as in: "If the master is not authoritative for the requested zone, the RCODE SHOULD be 9 (NOTAUTH)." -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 25 18:33:30 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28668 for ; Mon, 25 Jun 2001 18:33:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15EedW-000Aqo-00 for namedroppers-data@psg.com; Mon, 25 Jun 2001 15:15:14 -0700 Received: from mpfg.attlabs.net ([12.106.35.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 15EedV-000Aob-00 for namedroppers@ops.ietf.org; Mon, 25 Jun 2001 15:15:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 15Eecm-0000rO-00 for namedroppers@ops.ietf.org; Mon, 25 Jun 2001 15:14:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B37B60D.1E2A85C0@daimlerchrysler.com> Date: Mon, 25 Jun 2001 18:07:09 -0400 From: Kevin Darcy To: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: <3B33DEFA.2563993B@daimlerchrysler.com> <200106252106.OAA14699@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit gson@nominum.com wrote: > Kevin Darcy writes: > > The draft is still ambiguous as to how a nameserver should respond -- assuming > > that it *does* respond, as opposed to just closing the connection -- when it's > > not authoritative for the requested zone. In the last Last Call, I proposed > > that RCODE=NOTAUTH and/or AA=0 be explicitly mandated in that situation, but > > that proposal apparently got buried alive under the whole "is it or is it not > > OK to just close the connection?" discussion/argument. > > > > An unambiguous indication of non-authoritativeness would I think facilitate > > troubleshooting of AXFR problems/failures. > > I agree that an unambiguous indication of non-authoritativeness would > be a good thing, but I think mandating RCODE=NOTAUTH and/or AA=0 (as > in making them REQUIRED) would be contrary to the draft's stated > purpose of clarifying rather than changing the protocol defined in > RFC103[45]. In particular, the NOTAUTH result code had not yet been > defined RFC1034/1035 were written, making it hard to argue that > mandating its use is a mere clarification of the original intent of > the protocol designers. I don't want to declare an otherwise fully > conforming implementation non-conforming just because its implementers > did not foresee the future introduction of RCODE 9. > > I don't have a problem with a SHOULD, as in: > > "If the master is not authoritative for the requested zone, the RCODE > SHOULD be 9 (NOTAUTH)." I see your point about NOTAUTH, being that this is a clarification rather than an update of RFCs 1034/1035. But what about the other alternative, i.e. mandatory AA=0? RCODE=NOTAUTH was a nice thought, but upon further consideration, I guess my core concern is that this draft's "1, but MAY be 0 when RCODE is not NOERROR" language appears to loosen the RFC 1034/1035 requirements with respect to the setting of AA, i.e. it can be read as "if RCODE is not NOERROR, you're free to set AA any way you want". That's the dangerous thing about a "MAY" keyword -- it can give the appearance of allowing something that was previously forbidden, even if that is not the case. Perhaps something more along the lines of: 1 if authoritative for QNAME, 0 otherwise. Note that on responses with RCODE set to NOERROR, it logically follows that AA MUST be set to 1. would emphasize that the original RFC 1034/1035 rules vis-a-vis AA still need to be observed. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 26 04:17:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25041 for ; Tue, 26 Jun 2001 04:17:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15En4u-0002Ni-00 for namedroppers-data@psg.com; Tue, 26 Jun 2001 00:16:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15En4u-0002Nc-00 for namedroppers@ops.ietf.org; Tue, 26 Jun 2001 00:16:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15En4u-0006dK-00 for namedroppers@ops.ietf.org; Tue, 26 Jun 2001 00:16:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: gson@nominum.com (Andreas Gustafsson) cc: Josh Littlefield , Olafur Gudmundsson , DNSEXT mailing list , Andreas.Gustafsson@nominum.com Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <200106251957.MAA14666@gulag.araneus.fi> References: <200106251957.MAA14666@gulag.araneus.fi> <3B339C03.1741AE6A@cisco.com> Date: Tue, 26 Jun 2001 13:56:50 +0700 Message-ID: <2568.993538610@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 25 Jun 2001 12:57:49 -0700 (PDT) From: gson@nominum.com (Andreas Gustafsson) Message-ID: <200106251957.MAA14666@gulag.araneus.fi> | > unless the slave has sent multiple requests to | > the master, in which case the slave MUST NOT ignore the ID in subsequent | > messages, since they are needed to differentiate the response packets. | | I think this is fairly obvious implementation constraint rather than a | protocol issue. As such, I don't think it needs to be stated | explicitly in the protocol specification, but if it were, I would | prefer to express it a bit differently: | | "A slave that ignores ID fields cannot have multiple simultaneous | outstanding requests on the same TCP connection, since the ID would | be needed to differentiate the response messages." This is not actually required. A client shouldn't ever really need to know (if it doesn't want to) which queries generated which responses. Of course, it might like to know that, to optimise its handling of the replies - but there's nothing in the DNS that mandates it. That is, the purpose of a query in the DNS is to cause a server to send you some information. You do that only if you don't have the information already. What causes the information to be sent to you is really pretty much irrelevant - as long as you have it, you can answer (or continue with) any query that depends upon that information. Eg: consider that I am attempting to discover the A records for two different names - www.example.com and smtp-server.example.com. Currently all I know are the NS records for COM. The traditional way to handle this is to send a A query for www.example.com to the COM nameservers, and get back a referral for the example.com nameservers. The same thing is done for smtp-server.example.com. But when I get back the NS list for example.com that satisfies both current requirements - and I can proceed with the A queries for the two names at the example.com nameservers, whichever query it was that was actually answered. The point of this is that regardless of whether or not clients should ever ignore the ID in a response because of old broken servers, there's never an operational requirement for them to verify the ID just because they happen to be sending multiple simultaneous queries out over the same connection. Maybe that's what a client would do - but the final quoted paragraph above is certainly wrong, the ID isn't needed, the client doesn't (necessarily) need to know. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 26 14:57:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03086 for ; Tue, 26 Jun 2001 14:57:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Exom-000Otu-00 for namedroppers-data@psg.com; Tue, 26 Jun 2001 11:44:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15Exol-000Otm-00 for namedroppers@ops.ietf.org; Tue, 26 Jun 2001 11:44:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15Exol-000Ov7-00 for namedroppers@ops.ietf.org; Tue, 26 Jun 2001 11:44:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Jun 2001 11:15:03 -0700 (PDT) Message-Id: <200106261815.LAA15276@gulag.araneus.fi> To: Robert Elz Cc: Andreas.Gustafsson@nominum.com (Andreas Gustafsson), Josh Littlefield , Olafur Gudmundsson , DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <2568.993538610@brandenburg.cs.mu.OZ.AU> References: <200106251957.MAA14666@gulag.araneus.fi> <3B339C03.1741AE6A@cisco.com> <2568.993538610@brandenburg.cs.mu.OZ.AU> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | "A slave that ignores ID fields cannot have multiple simultaneous > | outstanding requests on the same TCP connection, since the ID would > | be needed to differentiate the response messages." > > This is not actually required. A client shouldn't ever really need > to know (if it doesn't want to) which queries generated which responses. > Of course, it might like to know that, to optimise its handling of the > replies - but there's nothing in the DNS that mandates it. > > That is, the purpose of a query in the DNS is to cause a server to send > you some information. You do that only if you don't have the information > already. What causes the information to be sent to you is really pretty > much irrelevant - as long as you have it, you can answer (or continue with) > any query that depends upon that information. > > Eg: consider that I am attempting to discover the A records for two different > names - www.example.com and smtp-server.example.com. Currently all I know > are the NS records for COM. The traditional way to handle this is to send > a A query for www.example.com to the COM nameservers, and get back a > referral for the example.com nameservers. The same thing is done for > smtp-server.example.com. But when I get back the NS list for example.com > that satisfies both current requirements - and I can proceed with the A > queries for the two names at the example.com nameservers, whichever query > it was that was actually answered. What you describe may work for ordinary queries sent for resolution purposes, though for security reasons I certainly wouldn't recommend doing it. It most certainly will not work for AXFR, which is the case being discussed. For example, if you are simultaneously transferring the zones example.com. and sub.example.com. over the same TCP connection, and receive a message containing some NS records for sub.example.com, there is no way of knowing which of the zones they are associated with without examining the ID. My main point, however, is that no existing slave implementations attempt to do multiple simultaneous AXFRs over the same TCP connection, and that there is no real reason why an implementation would ever want to do that in preference to doing the transfers serially or over separate TCP connections, and I would like to avoid discussing this case in the draft in a way that could mislead slave implementers into thinking that multiplexing of multiple simultaneous AXFRs over the same TCP connection is a desireable feature. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 26 14:57:34 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03096 for ; Tue, 26 Jun 2001 14:57:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15Ewzx-000Mno-00 for namedroppers-data@psg.com; Tue, 26 Jun 2001 10:51:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15Ewzx-000Mni-00 for namedroppers@ops.ietf.org; Tue, 26 Jun 2001 10:51:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15Ewzx-000NTw-00 for namedroppers@ops.ietf.org; Tue, 26 Jun 2001 10:51:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Jun 2001 10:47:39 -0700 (PDT) Message-Id: <200106261747.KAA15259@gulag.araneus.fi> To: Kevin Darcy Cc: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <3B37B60D.1E2A85C0@daimlerchrysler.com> References: <3B33DEFA.2563993B@daimlerchrysler.com> <200106252106.OAA14699@gulag.araneus.fi> <3B37B60D.1E2A85C0@daimlerchrysler.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy writes: > But what about the other alternative, i.e. mandatory AA=0? RCODE=NOTAUTH > was a nice thought, but upon further consideration, I guess my core > concern is that this draft's "1, but MAY be 0 when RCODE is not NOERROR" > language appears to loosen the RFC 1034/1035 requirements with respect to > the setting of AA, i.e. it can be read as "if RCODE is not NOERROR, you're > free to set AA any way you want". That's the dangerous thing about a "MAY" > keyword -- it can give the appearance of allowing something that was > previously forbidden, even if that is not the case. Perhaps something more > along the lines of: > 1 if authoritative for QNAME, 0 otherwise. Note that on responses with > RCODE set to NOERROR, it logically follows that AA MUST be set to 1. > > would emphasize that the original RFC 1034/1035 rules vis-a-vis AA still > need to be observed. One problem with this is that there are error cases where the server cannot determine a meaningful value for AA (e.g., FORMERR), or may not want to disclose whether or not it is authoritative (REFUSED). Rather than try to enumerate all possible error cases, I decided to leave the setting of AA in error responses to the discretion of the implementer. The language in the draft regarding header flags may be looser than RFC1035, but it is still considerably stricter than historical AXFR implementation practice. I don't think any of this really matters much, because in practice slaves will discover that the master is non-authoritative when they do an SOA query and get a referral response, and will not even attempt the AXFR. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 27 13:09:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24662 for ; Wed, 27 Jun 2001 13:09:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FHXn-0008Cp-00 for namedroppers-data@psg.com; Wed, 27 Jun 2001 08:47:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15FHXj-0008Ch-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 08:47:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15FHXj-0006bR-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 08:47:51 -0700 Message-Id: <200106271101.HAA25179@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt Date: Wed, 27 Jun 2001 07:01:51 -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 : DNSSEC Opt-in for Large Zones Author(s) : M. Kosters Filename : draft-ietf-dnsext-dnssec-opt-in-00.txt Pages : 9 Date : 26-Jun-01 In order for DNSSEC to be deployed operationally with large zones and little operational impact, there needs to be included a mechanism that allows for the separation of secure versus unsecure views of zones. This needs to be done in a transparent fashion that allows DNSSEC to be deployed in an incremental manner. This document proposes a method using views to allow for incremental growth of delegations that are registered as secure. This is accomplished by extending the use of the NXT record to deal with non-secure delegations as well as for non-existence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-opt-in-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-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: <20010626132029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-opt-in-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-opt-in-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010626132029.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. From owner-namedroppers@ops.ietf.org Wed Jun 27 14:09:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27445 for ; Wed, 27 Jun 2001 14:09:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FIeu-000Akz-00 for namedroppers-data@psg.com; Wed, 27 Jun 2001 09:59:20 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15FIeu-000Aks-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 09:59:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15FIeu-0008c8-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 09:59:20 -0700 Date: Wed, 27 Jun 2001 17:44:44 +0200 (MEST) From: Jakob Schlyter To: DNSEXT Subject: draft-ietf-dnsext-delegation-signer-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk to begin with I'd like to say that I like this draft. separating the security delegation and the key itself is a good thing. as we no longer keep the same information in the parent and the child, the question on who is authoriative for what is clearer - i.e. you will know that the delegation signer record came from the parent and the KEY from the zone itself. delegation signer simplifies interaction between the parent and the child which will make deployment less painful. it also eliminates the problem with key at apex. regarding selection of format I prefer the compact format as it will keep zone size down and is also easier to handle for administrators. the justifications for the verbose format is only to simplify implementation and I believe should accept the extra code and few CPU cycles that the compact format might generate. there have been some discussion about the naming of the record type. it is DK in the draft but some people like DKEY. after some discussions I think I like DS, Delegation Signer, best. after all, it is not a key - it's a hash of a key (when using the compact format). also DKEY is very close to TKEY and DK sounds almost like DKEY when pronouced. jakob -- Jakob Schlyter Network Analyst Phone: +46 31 701 42 13, +46 70 595 07 94 Carlstedt Research & Technology to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 27 14:23:41 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06434 for ; Wed, 27 Jun 2001 14:23:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 15FIgh-000Aqv-00 for namedroppers-data@psg.com; Wed, 27 Jun 2001 10:01:11 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 15FIgg-000Aqp-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 10:01:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15FIgg-0008fJ-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 10:01:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B39FFDA.2CA66E43@cisco.com> Date: Wed, 27 Jun 2001 11:46:34 -0400 From: Josh Littlefield To: Andreas Gustafsson CC: Olafur Gudmundsson , DNSEXT mailing list , Andreas.Gustafsson@nominum.com Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: <3B339C03.1741AE6A@cisco.com> <200106251957.MAA14666@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andreas Gustafsson wrote: > > Josh Littlefield writes: > > > Added the requirement that RRs other than the SOA be transmitted > > > exactly once (Peter Koch suggested a SHOULD, but I think a > > > MUST is warranted) and the recommendation that duplicate RRs be > > > silently ignored when received. > > > > I would prefer this be a SHOULD rather than a MUST, as Peter Koch > > suggested. That is, I don't feel its significant to *require* that > > the server transmit each RR exactly once, though I think it should > > be recommended. > > I did seriously consider making it a SHOULD, but I couldn't think of > any legitimate reason for a server to ever send a RR multiple times. > Old BIND servers do send RRs multiple times as a result of the way > they handle glue, but that behavior already conflicts with section 4. > I don't see how a server could conform to section 4 but still have a > reason to transmit a RR multiple times. Allowing the multiplicity > would just complicate the protocol without bringing any advantages. > > > Perhaps this also means that the slave MUST ignore duplicate > > RRs, by permitting their transmission. > > Yes, if we were to just say that the master SHOULD transmit each RR > only once, then we would have to make ignoring duplicates a MUST. > Well, I can imagine a server implementation which occassionally transmits a duplicate. I cannot imagine implementing a client which blindly assumed that duplicates would not be transmitted, or which refused a transfer containing them. If you assume they won't be transmitted, then you risk screwing up your own data. Once you add checking for duplicates, its easier to ignore them and serve the zone than to refuse the entire transfer (being liberal in what you accept). I'm not adamant on this point, but I hadn't seen discussion on this server restriction. > > And > > while we've defined the server behavior as sending the SOA as the > > last record of the transfer, we haven't specified the client's > > behavior regarding any answer records which follow this final SOA. I > > think we are implicitly saying that a client MAY ignore any answer > > records which follow the final SOA. I'd prefer we say this explicitly. > > Are you concerned with the case where other messages follow the > one with the final SOA, or the case where other RRs follow the SOA > in the answer section of the final message? > > The first case is outside the scope of the draft since the transfer > has already ended (per the definition above). > > The second case is of course an error on the part of the master, but I > don't see why saying the slave "MAY ignore" the extra data would be > preferable to simply leaving the slave behavior undefined. I'm concerned with the second case. Perhaps it can be undefined. Looking at what we (Cisco) implemented a few years ago, with the poor AXFR specification in 1035, I see that we use the presence of the second SOA in a packet to mark it as the last packet, but we read ALL answer RRs in that packet, regardless of whether they follow the SOA. I suppose as long as we're specific about the SOA being the last answer record in the final packet sent, it doesn't matter what the client is prepared to do with a non-conforming packet. -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 27 14:37:38 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11238 for ; Wed, 27 Jun 2001 14:37:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FJui-000DLs-00 for namedroppers-data@psg.com; Wed, 27 Jun 2001 11:19:44 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FJui-000DLm-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 11:19:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15FJui-000ArQ-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 11:19:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106271811.LAA62046@redpaul.mfnx.net> To: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: Message from Josh Littlefield of "Wed, 27 Jun 2001 11:46:34 EDT." <3B39FFDA.2CA66E43@cisco.com> Date: Wed, 27 Jun 2001 11:11:55 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Well, I can imagine a server implementation which occassionally transmits a > duplicate. I cannot imagine implementing a client which blindly assumed > that duplicates would not be transmitted, or which refused a transfer > containing them. If you assume they won't be transmitted, then you risk > screwing up your own data. Once you add checking for duplicates, its easier > to ignore them and serve the zone than to refuse the entire transfer (being > liberal in what you accept). > > I'm not adamant on this point, but I hadn't seen discussion on this server > restriction. The entity being transferred is a DNS Zone, which has a specific identity. A DNS Zone cannot include duplicate RR's in some cases (WKS, SOA) yet it can in others (TXT). If there is any confusion or disagreement about whether a given RR can be duplicated, then this has to be resolved at the zone identity level, that is, it applies to loads of master zones, not just transfers and loads of transferred zones. Once a zone has an identity, that identity has to be transferred. It cannot be left up to a transferrer to decide which parts of a transferred zone are unnecessary duplicates. In order that identity be transferred, nothing can be left out, nothing can be added. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 27 15:26:44 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13959 for ; Wed, 27 Jun 2001 15:26:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKYt-000EW1-00 for namedroppers-data@psg.com; Wed, 27 Jun 2001 12:01:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FKYs-000EVv-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 12:01:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15FKYs-000Bza-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 12:01:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 27 Jun 2001 20:57:20 +0200 (CEST) From: Roy Arends To: Jakob Schlyter Cc: DNSEXT Subject: Re: draft-ietf-dnsext-delegation-signer-00 In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 27 Jun 2001, Jakob Schlyter wrote: > to begin with I'd like to say that I like this draft. separating the > security delegation and the key itself is a good thing. as we no longer > keep the same information in the parent and the child, the question on who > is authoriative for what is clearer - i.e. you will know that the > delegation signer record came from the parent and the KEY from the zone > itself. delegation signer simplifies interaction between the parent and > the child which will make deployment less painful. it also eliminates the > problem with key at apex. > > regarding selection of format I prefer the compact format as it will keep > zone size down and is also easier to handle for administrators. the > justifications for the verbose format is only to simplify implementation > and I believe should accept the extra code and few CPU cycles that the > compact format might generate. > > there have been some discussion about the naming of the record type. it is > DK in the draft but some people like DKEY. after some discussions I think > I like DS, Delegation Signer, best. after all, it is not a key - it's a > hash of a key (when using the compact format). also DKEY is very close to > TKEY and DK sounds almost like DKEY when pronouced. Hear Hear (I agree). Another argument for using the short format is that a secure resolver is not going to use the DKEY/DK/DS to verify Sig's (the verbose format permits this) but uses the DKEY/DK/DS as a pointer to the proper KEY. I would like to see some discussion on the idea of having a key-authentication-key (a master-key signs several production keys), this in light of "DS points to key that signs the keyset" vs "DS points to key that signs the child zone". In general there are 3 proposals now. DS, SIG@parent and the current SIG@child. As I see it, DS is an alternative to SIG@parent, with less of the operational problems SIG@parent has. Next to that, the proposed master/production key scheme is interesting. Regards, Roy Arends to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 27 16:11:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26379 for ; Wed, 27 Jun 2001 16:11:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FKlD-000F69-00 for namedroppers-data@psg.com; Wed, 27 Jun 2001 12:13:59 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FKlD-000F63-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 12:13:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15FKlD-000CLq-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 12:13:59 -0700 From: Robert Elz To: Paul A Vixie cc: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <200106271811.LAA62046@redpaul.mfnx.net> References: <200106271811.LAA62046@redpaul.mfnx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 28 Jun 2001 02:08:20 +0700 Message-ID: <4118.993668900@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA26379 Date: Wed, 27 Jun 2001 11:11:55 -0700 From: Paul A Vixie Message-ID: <200106271811.LAA62046@redpaul.mfnx.net> | The entity being transferred is a DNS Zone, which has a specific identity. yes, for data that is in the zone, that's true. But zone transfers also have to transfer glue, and glue, not actually being a part of the zone, doesn't have all the same rules, or problems (it has a whole different set). If you take the (incorrect) view that glue is only ever included in a zone transfer when it is an A record for an NS that delegates into its own domain (forget the terminology, you know what I mean) then you'll never get duplicate glue, as the A record will only ever appear near the domain it lives inside, hence only ever once. However, as soon as you admit that glue is sometimes required more often than that (it certainly is), then you can have the same glue A records associated with more than one domain's delegation, and a naïve implementation might just send them multiple times. The question here is whether that is acceptable or not - it certainly isn't necessary, and by doing the extra bookkeeping it is avoidable. However, it tends to be much easier to do that at the receiver - you just need to check if you already have the data, if so, then you don't need it again. Checking if you have it is easier than checking if you sent it - for that you need to retain history. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 27 16:19:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02069 for ; Wed, 27 Jun 2001 16:19:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FLCi-000GPS-00 for namedroppers-data@psg.com; Wed, 27 Jun 2001 12:42:24 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FLCi-000GPM-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 12:42:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 15FLCi-000D7S-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 12:42:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <200106271934.MAA63174@redpaul.mfnx.net> To: Robert Elz cc: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: Message from Robert Elz of "Thu, 28 Jun 2001 02:08:20 +0700." <4118.993668900@brandenburg.cs.mu.OZ.AU> Date: Wed, 27 Jun 2001 12:34:15 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > However, as soon as you admit that glue is sometimes required more often > than that (it certainly is), then you can have the same glue A records > associated with more than one domain's delegation, and a naïve implementation > might just send them multiple times. BIND4 does that. > The question here is whether that is acceptable or not - it certainly > isn't necessary, and by doing the extra bookkeeping it is avoidable. > However, it tends to be much easier to do that at the receiver - you just > need to check if you already have the data, if so, then you don't need it > again. Checking if you have it is easier than checking if you sent it - > for that you need to retain history. I sure wish that glue were sent in additional data sections. Right now you have to fully receive a transfer before you know where the zone's bottom is, and thus before you know which RR's are part of the zone and which are not. But if it's out-of-zone data then I expect that liberal receiving rules ought to apply. Interestingly, this opens the possibility of multiple A RR's of different addresses for the same name being aggregated into a single RRset by a receiver even though they might have been held/used separately by the sender (when the sender is answering queries). Glue is just sticky. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 27 17:31:31 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20278 for ; Wed, 27 Jun 2001 17:31:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FMa2-000Jh0-00 for namedroppers-data@psg.com; Wed, 27 Jun 2001 14:10:34 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FMa2-000Jgu-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 14:10:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15FMa2-000H89-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 14:10:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 27 Jun 2001 14:00:43 -0700 (PDT) Message-Id: <200106272100.OAA16025@gulag.araneus.fi> To: Robert Elz Cc: Paul A Vixie , DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <4118.993668900@brandenburg.cs.mu.OZ.AU> References: <200106271811.LAA62046@redpaul.mfnx.net> <4118.993668900@brandenburg.cs.mu.OZ.AU> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Robert Elz writes: > | The entity being transferred is a DNS Zone, which has a specific identity. > > yes, for data that is in the zone, that's true. > > But zone transfers also have to transfer glue, and glue, not actually being > a part of the zone, doesn't have all the same rules, or problems The whole point of section 4 in the draft is to explain that for the purpose of zone transfers, glue *does* have all the same rules and problems as the authoritative zone data. To summarize, the data transferred is exactly the data that the master loaded from the master file of the zone being transferred. Nothing more and nothing less, and "nothing more" should be taken to include additional copies of data that is already there (except the SOA end marker, of course). > However, as soon as you admit that glue is sometimes required more often > than that (it certainly is), then you can have the same glue A records > associated with more than one domain's delegation, and a naïve implementation > might just send them multiple times. Section 4 specifically points out that such A records are *not* sent because they are associated with a delegation, they are sent because (and only if) they occurred in the master file. Naive implementations that send random glue that is not in the master file are deliberately outlawed by the draft. The reason for this strict specification is to ensure that AXFR can coexist with IXFR. The IXFR protocol assumes that the zone data are consistent among all the authoritative servers. Inserting random glue breaks this assumption and will cause IXFRs to fail. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 28 07:19:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11551 for ; Thu, 28 Jun 2001 07:19:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FUF0-000G8Y-00 for namedroppers-data@psg.com; Wed, 27 Jun 2001 22:21:22 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FUF0-000G8R-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 22:21:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15FUF0-0007iw-00 for namedroppers@ops.ietf.org; Wed, 27 Jun 2001 22:21:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B3A6F8A.634AFC0@daimlerchrysler.com> Date: Wed, 27 Jun 2001 19:43:06 -0400 From: Kevin Darcy To: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: <200106271811.LAA62046@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: > > Well, I can imagine a server implementation which occassionally transmits a > > duplicate. I cannot imagine implementing a client which blindly assumed > > that duplicates would not be transmitted, or which refused a transfer > > containing them. If you assume they won't be transmitted, then you risk > > screwing up your own data. Once you add checking for duplicates, its easier > > to ignore them and serve the zone than to refuse the entire transfer (being > > liberal in what you accept). > > > > I'm not adamant on this point, but I hadn't seen discussion on this server > > restriction. > > The entity being transferred is a DNS Zone, which has a specific identity. > A DNS Zone cannot include duplicate RR's in some cases (WKS, SOA) yet it can > in others (TXT). Is that really the case? RFC 2181 would appear to forbid even duplicate TXT records: "It is meaningless for two records to ever have label, class, type and data all equal - servers should suppress such duplicates if encountered" (Section 5, "Resource Record Sets"). Why would TXT records be an exception? - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 28 08:26:54 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13535 for ; Thu, 28 Jun 2001 08:26:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FZjV-0006v4-00 for namedroppers-data@psg.com; Thu, 28 Jun 2001 04:13:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FZjV-0006uy-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 04:13:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15FZjV-000F3R-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 04:13:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: gson@nominum.com (Andreas Gustafsson) cc: Paul A Vixie , DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <200106272100.OAA16025@gulag.araneus.fi> References: <200106272100.OAA16025@gulag.araneus.fi> <200106271811.LAA62046@redpaul.mfnx.net> <4118.993668900@brandenburg.cs.mu.OZ.AU> Date: Thu, 28 Jun 2001 12:43:53 +0700 Message-ID: <1390.993707033@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 27 Jun 2001 14:00:43 -0700 (PDT) From: gson@nominum.com (Andreas Gustafsson) Message-ID: <200106272100.OAA16025@gulag.araneus.fi> | To summarize, the data | transferred is exactly the data that the master loaded from the maste= r | file of the zone being transferred. Nothing more and nothing less, | and "nothing more" should be taken to include additional copies of | data that is already there (except the SOA end marker, of course). Ok, then in that case section 5 is inconsistent, as it says ... The transmission order of all other RRs in the zone is undefined. Each of them MUST be transmitted exactly once. As some older masters do not comply with this requirement, slaves SHOULD silently ignore duplicate RRs for interoperability. None of that can be correct given the above interpretation. That is, if I write in a master file foo IN NS ns13.example.com. ns13.example.com. IN A 10.11.12.13 bar IN NS ns13.example.com. foobar IN NS ns13.example.com. ns13.example.com. IN A 10.11.12.13 then to transfer that zone to the secondary, the primary would have to retain the RR order (so the order of all other RR's (other than the SOA which is discussed just above) can not be undefined). Also, the primary would have to transfer the RR for ns13.example.com. twice, not once, so the "MUST be transmitted exactly once" is not correct= either. And lastly, to receive the same zone information, secondary servers "MUST NOT" ignore duplicates, but would have to retain them. Of course, none of this is really required for IXFR compatability, nor should anything really be caring anything at all about the format of mast= er files (other than for the cases when they need to be transported around by means other than [AI]XFR and then loaded into different servers). | Section 4 specifically points out that such A records are *not* sent | because they are associated with a delegation, they are sent because | (and only if) they occurred in the master file. Yes, of course. That's fine. It still doesn't handle all the possibili= ties. | Naive implementations | that send random glue that is not in the master file are deliberately= | outlawed by the draft. Yes, I know, and that's fine. But in the example above are you really trying to tell me that it is important that there is a glue A record associated with exactly 2 of the delegations, but not with the third? In that situation, my na=EFve implementation might send 6RRs (3 NS record= s, and 3 records), or it might send 4 (3 NS records, and one A record), or it could even send 5 (3 NS records and 2 A records). Does it matter? I kind of doubt it. Further, if you're really intending to be able to duplicate the master fi= le, rather than just the zone data that was built from the master file, then I'm not sure how some of my master files would work - some of my zone fil= es are built like A IN NS ns1 B IN NS ns2 C IN NS ns1 D IN NS ns1 E IN NS ns2 ; glue follows ns1 IN A 10.11.12.13 ns2 IN A 10.22.33.44 where the glue A records aren't "attached" to any particular delegation at all, but simply exist in the zone. Internally however, it makes sense for the zone data structures to have links directly from delegation (NS) to glue A record if glue exists, so when a query for the NS arrives, the glue can easily be attached. Then when transferring that zone, the easy way is to send NS, if glue poi= nter is set, send A record. Doing that with this recent example and you'd send the A record for ns1 3 times, and the A record for ns2 twice. To avoid that, extra bookkeeping is required in the primary. On the othe= r hand, it is almost trivial to ignore the duplicate at the secondary. | The reason for this strict specification is to ensure that AXFR can | coexist with IXFR. The IXFR protocol assumes that the zone data are | consistent among all the authoritative servers. Inserting random glue= | breaks this assumption and will cause IXFRs to fail. Absolutely, none of this has been about adding glue that isn't in the zon= e file, only about how many times the RRs that are in the zone file are allowed to be sent. Or, take another example, unrelated to glue at all... domain IN SOA x y 0 0 0 0 0 ; soa contents uninportant IN NS ns1 IN NS ns2 host IN A 10.11.12.13 IN A 10.11.12.13 There, in the master file is a duplicate A record. That is supposed to be compressed into a single RR when the zone is loaded (ie: there's only one RR there). Now an implementation that loads the zone, and later transfers it, will transfer only the one RR that it has loaded (duplicate supressed). On the other hand, an implementation that implements AXFR by "there is the master file, encode and send it" is quite possibly going to send the RR twice (most likely the two instances won't be adjacent as they appear above, there will be lots of other RRs between). Is the simple "load, encode, transmit" of the master file implementation to be outlawed, so that AXFR requires the whole zone to be loaded so duplicates can be supressed, before anything can be sent? On large zone= files on my main server, loading and parsing the zone file data can take 10 minutes or so - that would be a 10 minute penalty between the arrival of the AXFR request and when the first RR could be sent. I see no reason for that at all. I think the right thing to do is simply to delete the "MUST be transmitted exactly once" and make it a "MUST" ignore duplicates for the secondary. kre ps: everything Paul said in his most recent message (Message-Id: <200106271934.MAA63174@redpaul.mfnx.net>) I agree with... to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 28 09:13:28 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21269 for ; Thu, 28 Jun 2001 09:13:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fadw-00099f-00 for namedroppers-data@psg.com; Thu, 28 Jun 2001 05:11:32 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15Fadv-00099X-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 05:11:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Fadv-000Hr4-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 05:11:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Miek Gieben Date: Thu, 28 Jun 2001 13:26:30 +0200 To: Roy Arends Cc: Jakob Schlyter , DNSEXT Subject: Re: draft-ietf-dnsext-delegation-signer-00 Message-ID: <20010628132630.A14552@atoom.net> References: In-Reply-To: ; from Roy.Arends@nominum.com on Wed, Jun 27, 2001 at 08:57:20PM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [On 27 Jun, 2001, Roy Arends wrote in " Re: draft-ietf-dnsext-delegation-signer-00 "] > I would like to see some discussion on the idea of having a > key-authentication-key (a master-key signs several production keys), this > in light of "DS points to key that signs the keyset" vs "DS points to key > that signs the child zone". > > In general there are 3 proposals now. DS, SIG@parent and the current > SIG@child. As I see it, DS is an alternative to SIG@parent, with less of as the author of sig@parent i must say, i like the idea of DS (let's stick with that name) > the operational problems SIG@parent has. Next to that, the proposed > master/production key scheme is interesting. agreed interesting, but it adds another level of complexity, do we want that? grtz Miek to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 28 14:45:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12207 for ; Thu, 28 Jun 2001 14:45:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FfjH-000N1N-00 for namedroppers-data@psg.com; Thu, 28 Jun 2001 10:37:23 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FfjG-000N1H-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 10:37:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15FfjG-0007oC-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 10:37:22 -0700 Date: Thu, 28 Jun 2001 13:35:13 -0400 From: Dan Massey To: Jakob Schlyter Cc: DNSEXT Subject: Re: draft-ietf-dnsext-delegation-signer-00 Message-ID: <20010628133513.A17870@snarl.east.isi.edu> Mail-Followup-To: Jakob Schlyter , DNSEXT 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, Jun 27, 2001 at 05:44:44PM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wednesday, June 27, 2001 at 05:44PM, Jakob Schlyter wrote: | to begin with I'd like to say that I like this draft. separating the | security delegation and the key itself is a good thing. as we no longer | keep the same information in the parent and the child, the question on who | is authoriative for what is clearer - i.e. you will know that the | delegation signer record came from the parent and the KEY from the zone | itself. delegation signer simplifies interaction between the parent and | the child which will make deployment less painful. it also eliminates the | problem with key at apex. | I agree with this and think the last two points are particularly important. We found that the interaction between parent and child has been a problem. SIG@parent helps a lot in this regard, but I think this draft improves on SIG@parent. Keys at the apex has also been a problem for us and this draft fixes that as well. Also, the compact format in section 2.2.1 seems preferable to the verbose format in section 2.2.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. From owner-namedroppers@ops.ietf.org Thu Jun 28 15:45:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24525 for ; Thu, 28 Jun 2001 15:45:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15Fgq0-0000UD-00 for namedroppers-data@psg.com; Thu, 28 Jun 2001 11:48:24 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15Fgpz-0000U7-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 11:48:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Fgpz-000BGM-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 11:48:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Jun 2001 11:15:39 -0700 (PDT) Message-Id: <200106281815.LAA16656@gulag.araneus.fi> To: Kevin Darcy Cc: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <3B3A6F8A.634AFC0@daimlerchrysler.com> References: <200106271811.LAA62046@redpaul.mfnx.net> <3B3A6F8A.634AFC0@daimlerchrysler.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy writes: > Paul A Vixie wrote: > > A DNS Zone cannot include duplicate RR's in some cases (WKS, SOA) yet it can > > in others (TXT). > > Is that really the case? RFC 2181 would appear to forbid even duplicate > TXT records: "It is meaningless for two records to ever have label, class, type > and data all equal - servers should suppress such duplicates if encountered" > (Section 5, "Resource Record Sets"). Why would TXT records be an exception? I agree with Kevin. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 28 17:50:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09733 for ; Thu, 28 Jun 2001 17:50:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FiwJ-0006IL-00 for namedroppers-data@psg.com; Thu, 28 Jun 2001 14:03:03 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FiwJ-0006IF-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 14:03:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15FiwJ-000Hsj-00 for namedroppers@ops.ietf.org; Thu, 28 Jun 2001 14:03:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Jun 2001 13:56:03 -0700 (PDT) Message-Id: <200106282056.NAA16721@gulag.araneus.fi> To: Robert Elz Cc: Paul A Vixie , DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <1390.993707033@brandenburg.cs.mu.OZ.AU> References: <200106272100.OAA16025@gulag.araneus.fi> <200106271811.LAA62046@redpaul.mfnx.net> <4118.993668900@brandenburg.cs.mu.OZ.AU> <1390.993707033@brandenburg.cs.mu.OZ.AU> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz writes: > | To summarize, the data > | transferred is exactly the data that the master loaded from the master > | file of the zone being transferred. Nothing more and nothing less, > | and "nothing more" should be taken to include additional copies of > | data that is already there (except the SOA end marker, of course). > > Ok, then in that case section 5 is inconsistent, as it says ... > > The transmission order of all other RRs in the zone is undefined. > Each of them MUST be transmitted exactly once. As some older masters > do not comply with this requirement, slaves SHOULD silently ignore > duplicate RRs for interoperability. > > None of that can be correct given the above interpretation. > > That is, if I write in a master file > > foo IN NS ns13.example.com. > ns13.example.com. IN A 10.11.12.13 > > bar IN NS ns13.example.com. > > foobar IN NS ns13.example.com. > ns13.example.com. IN A 10.11.12.13 > > then to transfer that zone to the secondary, the primary would have to > retain the RR order (so the order of all other RR's (other than the SOA > which is discussed just above) can not be undefined). The order of the records in a master file is meaningless. The above does not express three delegations of which only two have glue - it simply expresses three NS records and two copies of an A record, one of which will be suppressed by the master per RFC2181 section 5. When the draft refers to RRs "loaded from the master file", that means exactly those four records (3 NS + 1 A), in no particular order. > Also, the primary would have to transfer the RR for ns13.example.com. > twice, not once, so the "MUST be transmitted exactly once" is not correct No. Only one A record is loaded, therefore only one A record is transferred. > Of course, none of this is really required for IXFR compatability, nor > should anything really be caring anything at all about the format of master > files (other than for the cases when they need to be transported around > by means other than [AI]XFR and then loaded into different servers). The AXFR protocol does not care about the format of master files. It only cares about an unordered collection of unique RRs which is customarily defined using a master file. > | Naive implementations > | that send random glue that is not in the master file are deliberately > | outlawed by the draft. > > Yes, I know, and that's fine. But in the example above are you really > trying to tell me that it is important that there is a glue A record > associated with exactly 2 of the delegations, but not with the third? No - quite the contrary. I'm saying "there is one A record". Whether it is glue is irrelevant to the zone transfer protocol. > In that situation, my naive implementation might send 6RRs > (3 NS records, and 3 records), or it might send 4 (3 NS records, > and one A record), or it could even send 5 (3 NS records and 2 A records). > Does it matter? I kind of doubt it. The draft currently says the master MUST send 4, and that the slave SHOULD also accept 5 or 6 (which it should then internally reduce to 4 per RFC2181 section 5). > Further, if you're really intending to be able to duplicate the master file, > rather than just the zone data that was built from the master file, I *am* intending to duplicate the zone data that was built from the master file. > Internally however, it makes sense for the zone data structures to have > links directly from delegation (NS) to glue A record if glue exists, > so when a query for the NS arrives, the glue can easily be attached. > Then when transferring that zone, the easy way is to send NS, if glue > pointer is set, send A record. Doing that with this recent example and you'd > send the A record for ns1 3 times, and the A record for ns2 twice. > To avoid that, extra bookkeeping is required in the primary. On the other > hand, it is almost trivial to ignore the duplicate at the secondary. Yes, this would work, although it would of course waste a bit of bandwidth. > Or, take another example, unrelated to glue at all... > > domain IN SOA x y 0 0 0 0 0 ; soa contents uninportant > IN NS ns1 > IN NS ns2 > host IN A 10.11.12.13 > IN A 10.11.12.13 > > There, in the master file is a duplicate A record. That is supposed to > be compressed into a single RR when the zone is loaded (ie: there's only > one RR there). > > Now an implementation that loads the zone, and later transfers it, will > transfer only the one RR that it has loaded (duplicate supressed). > On the other hand, an implementation that implements AXFR by "there is > the master file, encode and send it" is quite possibly going to send the > RR twice (most likely the two instances won't be adjacent as they appear > above, there will be lots of other RRs between). > > Is the simple "load, encode, transmit" of the master file implementation > to be outlawed, so that AXFR requires the whole zone to be loaded so > duplicates can be supressed, before anything can be sent? On large zone > files on my main server, loading and parsing the zone file data can take > 10 minutes or so - that would be a 10 minute penalty between the > arrival of the AXFR request and when the first RR could be sent. I see > no reason for that at all. I think the right thing to do is simply > to delete the "MUST be transmitted exactly once" and make it a "MUST" > ignore duplicates for the secondary. This makes sense. I don't have any major problems with allowing duplicates in order to support implementations like this one and the "glue pointer" based implementation above (and I third one I was told about in private email), though I still think they should be discouraged. That is, I can change the text to say that the master SHOULD NOT send duplicates, and the slave MUST ignore duplicates. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 07:32:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16162 for ; Fri, 29 Jun 2001 07:32:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FsIB-0003Cj-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 00:02:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FsIA-0003CP-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 00:02:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15FsI9-000EYg-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 00:02:13 -0700 From: Robert Elz To: gson@nominum.com (Andreas Gustafsson) cc: Paul A Vixie , DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <200106282056.NAA16721@gulag.araneus.fi> References: <200106282056.NAA16721@gulag.araneus.fi> <200106272100.OAA16025@gulag.araneus.fi> <200106271811.LAA62046@redpaul.mfnx.net> <4118.993668900@brandenburg.cs.mu.OZ.AU> <1390.993707033@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Jun 2001 12:12:35 +0700 Message-ID: <2028.993791555@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 28 Jun 2001 13:56:03 -0700 (PDT) From: gson@nominum.com (Andreas Gustafsson) Message-ID: <200106282056.NAA16721@gulag.araneus.fi> | That is, I can change the text to say that the master | SHOULD NOT send duplicates, and the slave MUST ignore duplicates. Fine. As was pointed out by Josh Littlefield, secondaries have to ignore duplicates to end up with a valid zone anyway, they simply have no choice, so whether it says MUST ignore or not, that is what the secondaries are going to do. kre ps: one more time on an almost irrelevant aside ... there is no such thing as a slave server - there are primary servers, secondary servers, and master zone files. Grep for "slave" in 1034/1035 (etc) and you won't find it at all - it would really be nice if the term didn't start appearing in the DNS lexicon, it isn't needed, and just creates confusion. Perhaps worse, using "primary master" is just redundant, while 103[45] do occasionally use the term "master server" where "primary server" would have been better (except a couple of cases where it really means server of the master zone file), but "master server" or better "primary server" is all that is ever needed. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 07:38:14 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20478 for ; Fri, 29 Jun 2001 07:38:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FsNp-0003Xy-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 00:08:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FsNn-0003Xs-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 00:08:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15FsNm-000Epc-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 00:08:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200106290607.XAA89376@redpaul.mfnx.net> To: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: Message from Robert Elz of "Fri, 29 Jun 2001 12:12:35 +0700." <2028.993791555@brandenburg.cs.mu.OZ.AU> Date: Thu, 28 Jun 2001 23:07:51 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ps: one more time on an almost irrelevant aside ... there is no such > thing as a slave server - there are primary servers, secondary servers, > and master zone files. Grep for "slave" in 1034/1035 (etc) and you > won't find it at all - it would really be nice if the term didn't start > appearing in the DNS lexicon, it isn't needed, and just creates confusion. > Perhaps worse, using "primary master" is just redundant, while 103[45] > do occasionally use the term "master server" where "primary server" would > have been better (except a couple of cases where it really means server of > the master zone file), but "master server" or better "primary server" is > all that is ever needed. i disagree. 103[45] was ambiguous to a fault on this matter. master and slave are roles taken during an AXFR (and now during IXFR as well). while the term "transfer initiator" and "transfer responder" would perhaps be as accurate, they don't roll off the keyboard as well as "slave" and "master". an authoritative zone server can be a master, or a slave, or neither (if there are no AXFR's or IXFR's involved, and the zone maintainance is being done out of band), or both (if the transfer graph is deep). see RFC 1996 2.1. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 08:03:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08569 for ; Fri, 29 Jun 2001 08:03:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15FsIr-0003EE-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 00:02:57 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15FsIq-0003E7-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 00:02:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15FsIq-000EZw-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 00:02:56 -0700 Date: Fri, 29 Jun 2001 07:30:48 +0200 (CEST) From: Roy Arends To: Mark Kosters Cc: namedroppers@ops.ietf.org, dnssec@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: <200106271101.HAA25179@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 27 Jun 2001 Internet-Drafts@ietf.org wrote: > 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 : DNSSEC Opt-in for Large Zones > Author(s) : M. Kosters > Filename : draft-ietf-dnsext-dnssec-opt-in-00.txt > Pages : 9 > Date : 26-Jun-01 > Mark, I'm convinced this is a good idea, though a few first thoughts after reading the draft: 1) wrt opt-in, a NXT record indicates that a delegation is not secured by specifying the signed owner name before and after the unsecured owner name. Thus it indicates "authenticated denial of security" instead of "authenticated denial of existence". Should the type bit map interpreted as "type does not exist" or "type is not signed" ? 2) To indicate opt-in, a bit is set in the flag-field of the zone KEY. When I decide to sign the zone with an "opt-in" zone KEY and I sign the zone with a vanilla zone KEY (I can sign the zone with more than 1 KEY), there is no way of indicating how to create NXT RR. Would there be two NXT RR, one for opt-in view, one for rfc2535-style ? This is in my opinion very difficult to realise and probably breaks the scheme. Temporarily signing with both keys might be necessary when I'm moving from a rfc2535-style to opt-in-style or vice versa. 3) Should we extend "authenticated denial of security" for unsecure delegations (as specified in the draft) to any RRset ? 4) If opt-in is generally conceived as a good idea, should backwards compatibility be enforced by also permitting rfc2535-style zones ? We are already searching for an alternative to sig@child, which is not backward compatible (though of a different level) with rfc2535, next to that, rfc2535 style zone's are not widely deployed. To my knowledge there are some testbeds (cairn, tislabs, sigz, nl.nl, etc) though I've not seen a full deployment of DNSSEC. My .02 Euro, Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 13:17:09 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19588 for ; Fri, 29 Jun 2001 13:17:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G1Xr-000Oli-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 09:55:03 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G1Xr-000Olc-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 09:55:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G1Xr-0004tO-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 09:55:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 29 Jun 2001 18:39:23 +0200 (MEST) From: Jakob Schlyter To: DNSEXT Cc: Mark Kosters , Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: <200106271101.HAA25179@ietf.org> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think the opt-in flag should be moved to a separate RR, a modified version of Ed Lewis SEC RR would probably we a good choice (although I would perhaps like to call it ZSS for Zone Security Status instead). the opt-in flag is a per zone flag. as there could be multiple zone keys and if KEY would include this flag, all zone keys has to have the same flag (for that bit). also, as the zone key are signed by the parent, the child can not change from/to opt-in without having the parent sign the child's key. jakob -- Jakob Schlyter Network Analyst Phone: +46 31 701 42 13, +46 70 595 07 94 Carlstedt Research & Technology to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 13:36:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20282 for ; Fri, 29 Jun 2001 13:36:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G17h-000NkD-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 09:28:01 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G17h-000Nk7-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 09:28:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G17h-00048n-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 09:28:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B3C93B2.2197661A@ehsco.com> Date: Fri, 29 Jun 2001 09:41:55 -0500 From: "Eric A. Hall" To: Robert Elz CC: DNSEXT mailing list Subject: terminology (was: DNSEXT WGLC AXFR-02 SHORT last call) References: <200106282056.NAA16721@gulag.araneus.fi> <200106272100.OAA16025@gulag.araneus.fi> <200106271811.LAA62046@redpaul.mfnx.net> <4118.993668900@brandenburg.cs.mu.OZ.AU> <1390.993707033@brandenburg.cs.mu.OZ.AU> <2028.993791555@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ps: one more time on an almost irrelevant aside ... there is no such > thing as a slave server - there are primary servers, secondary servers, > and master zone files. > Perhaps worse, using "primary master" is just redundant, while 103[45] > do occasionally use the term "master server" where "primary server" > would have been better (except a couple of cases where it really means > server of the master zone file), but "master server" or better "primary > server" is all that is ever needed. master/slave is unfortunate but it is better than primary/secondary. The latter implies that the secondary servers will pick up where the primary fails, which is not the case at all. There are also multiple occurrances of each phrase pair in various documents, making it worse. DNS is unique in many regards, and the frequent colliding metaphors is one of the less fortunate unique elements. Personally I prefer "replication master" and "replication slave" but could easily live with "zone master" and "zone backup server" or any other terminology which clearly described the functional roles of the authoritative servers for a zone. Maybe a draft on terminology is in order. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 13:37:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20328 for ; Fri, 29 Jun 2001 13:37:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G0Fi-000LSv-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 08:32:14 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G0Fh-000LSo-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 08:32:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G0Fh-0002fV-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 08:32:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <00dc01c10097$e64619a0$b9370681@antd.nist.gov> From: "Scott Rose" To: "DNSEXT" References: <20010628133513.A17870@snarl.east.isi.edu> Subject: Re: draft-ietf-dnsext-delegation-signer-00 Date: Fri, 29 Jun 2001 08:34:54 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm starting to prefer the Delegated Signer RR over sig@parent as well. I know it adds yet another RR to the security extensions, but the RR solves a lot of the protocol questions of sig@parent and operational problems of sig@child. A bunch of us were talking yesterday at Verisign with Mark Kosters (Jakob, Roy, Mats, and myself). There was some discussion of adding a field in the delegated signer record (DS RR?) to list other security conventions used with the child in addition to the key hash. This would be similar to the RDATA field (in some ways) of the SEC record from Ed's old draft. I'm having my doubts about adding that. Not that it wouldn't be helpful, but I don't think the resolver can always assume that information is correct in the real world. The resolver should assume nothing, and be able to verify a child's security status when talking to the child and not have to rely on information from the parent. But the details of the delegated signer can be worked out later. The main point of the DS record - to contain the hash of the child's zone signing key - is a good one. Scott =============================================================== Scott Rose Advanced Network Technologies Division NIST ph: 301-975-8439 fax: 301-590-0932 http://www.nist.gov =============================================================== ----- Original Message ----- From: "Dan Massey" To: "Jakob Schlyter" Cc: "DNSEXT" Sent: Thursday, June 28, 2001 1:35 PM Subject: Re: draft-ietf-dnsext-delegation-signer-00 > On Wednesday, June 27, 2001 at 05:44PM, Jakob Schlyter wrote: > | to begin with I'd like to say that I like this draft. separating the > | security delegation and the key itself is a good thing. as we no longer > | keep the same information in the parent and the child, the question on who > | is authoriative for what is clearer - i.e. you will know that the > | delegation signer record came from the parent and the KEY from the zone > | itself. delegation signer simplifies interaction between the parent and > | the child which will make deployment less painful. it also eliminates the > | problem with key at apex. > | > > I agree with this and think the last two points are particularly important. > We found that the interaction between parent and child has been > a problem. SIG@parent helps a lot in this regard, but I think this > draft improves on SIG@parent. Keys at the apex has also been a problem > for us and this draft fixes that as well. > > Also, the compact format in section 2.2.1 seems preferable to the verbose > format in section 2.2.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. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 13:43:56 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20523 for ; Fri, 29 Jun 2001 13:43:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G18t-000NmW-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 09:29:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G18t-000NmQ-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 09:29:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G18t-0004As-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 09:29:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention In-Reply-To: Message from Kevin Darcy dated "Tue, 19 Jun 2001 18:38:48 EDT" <3B2FD478.74DF935C@daimlerchrysler.com> References: <3B2FD478.74DF935C@daimlerchrysler.com> Date: Fri, 29 Jun 2001 10:52:38 -0400 From: Rob Austein Message-Id: <20010629145246Z23616-9152+45@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin, Going back to your original question: Date: Tue, 19 Jun 2001 18:38:48 -0400 From: Kevin Darcy Does the SRV protocol prohibit a nameserver from manipulating priorities and/or weights in its answers depending on the source address of the requesting client? Perhaps this "localization" can be done within the implementation and there's no need to burden the protocol with it. This would just be a more sophisticated version of the A-record sorting mechanisms in use today. As Paul Vixie pointed out, this is a DNS protocol issue, not specific to SRV. The entity acting as a name server can perform this kind of manipulation if and only if it can update the serial field of the SOA RR in the authoritative zone. Name servers don't do that except when acting as the master server in the dynamic update protocol. Changing zone content without changing the SOA serial field is a protocol violation. More precisely, given the following four queries, performed in order, and assuming no zone cuts below miskatonic.edu: #1 QNAME=miskatonic.edu. QTYPE=SOA QCLASS=IN #2 QNAME=_foo._bar.cthulhu.miskatonic.edu. QTYPE=SRV QCLASS=IN #3 QNAME=_foo._bar.cthulhu.miskatonic.edu. QTYPE=SRV QCLASS=IN #4 QNAME=miskatonic.edu. QTYPE=SOA QCLASS=IN If the answers to queries #1 and #4 are the same, the answers to queries #2 and #3 must also be the same. Of course, there's nothing to stop you from writing a program which is both a name server and a dynamic update client. In theory you could also write a program which acts as an authoritative name server and which generates new zone content on the fly at whim, but be sure to generate a new SOA serial value to go with each new whim, and have fun making sure that the other authoritative name servers for this zone return precisely same whimsical zone content as this name server does for a given SOA serial value.... But for a conventional name server operating with zones that come from boring old files generated by some outside source, the answer to your question is "no". Sorting A RRs is fundamentally different from changing zone content: DNS itself makes no promises at all about ordering of RRs within an RRset, so a name server can present the RRs in any order it likes. Hope this clarifies things a bit. --Rob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 15:14:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23442 for ; Fri, 29 Jun 2001 15:14:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G2VN-000182-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 10:56:33 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G2VM-00017w-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 10:56:32 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G2VM-0006ZL-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 10:56:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 29 Jun 2001 19:52:29 +0200 (CEST) From: Mats Dufberg To: Roy Arends cc: Mark Kosters , , Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 29 Jun 2001, Roy Arends wrote: > 4) If opt-in is generally conceived as a good idea, should backwards > compatibility be enforced by also permitting rfc2535-style zones ? We are > already searching for an alternative to sig@child, which is not backward > compatible (though of a different level) with rfc2535, next to that, > rfc2535 style zone's are not widely deployed. To my knowledge there are > some testbeds (cairn, tislabs, sigz, nl.nl, etc) though I've not seen a > full deployment of DNSSEC. I find the opt-in alternative a goot suggestion, which will ease the deployment of DNSsec. But it would be a bad idea not to have the full NXT (as defined in RFC 2535). During the transition period we will have zone with mixed data (both signed and unsigned), but eventually there will be fully signed (secured) subtrees. If you have a fully signed tree there is not much (if any) gained from the opt-in alternative, but you will not have the fully authenticated denial of existence, which means that a fake non-secured subdomain can be spoofed. Opt-in is good only if full NXT is kept. Mats ----------------------------------------------------------------- Mats Dufberg +46-8-545 857 06 dufberg@nic-se.se fax: +46-8-545 857 29 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 19:24:42 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27174 for ; Fri, 29 Jun 2001 19:24:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G6m5-000BTi-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 15:30:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G6m4-000BTc-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 15:30:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G6m4-000Dyu-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 15:30:04 -0700 Date: Fri, 29 Jun 2001 22:02:46 +0200 (MEST) From: Jakob Schlyter To: DNSEXT Cc: Mark Kosters , Subject: Re: I-D ACTION:draft-ietf-dnsext-dnssec-opt-in-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have more comments after some more out-of-band discussions with roy, dan & mats. at first, a opt-in zone is perhaps a somewhat bad name. what we really mean is "a zone that may contain unsigned data". to achive this we have at least two options. we either have a flag somewhere (in KEY, SEC or what have we) that toggles the semantics of the NXT records for a zone to change from "authenticated denial of existance" into "authenticated denial of security". an alternative solution would be to add another RR for authenticated denial. the rfc 2535 semantics for NXT remain. the new RR would include a flag that specifies if it denies existance of everything or denies existance of security. this could be a RR similar to NXT or NO but with a flag field added. jakob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 19:24:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27185 for ; Fri, 29 Jun 2001 19:24:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G6zc-000C62-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 15:44:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G6zb-000C5w-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 15:44:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G6zb-000ENx-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 15:44:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Steven M. Bellovin" Cc: Rob Austein , dns directorate Subject: Re: Draft I-D on AAAA vs A6 References: <20010629183037.35C377B5F@berkshire.research.att.com> Message-Id: Date: Fri, 29 Jun 2001 15:24:06 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I've heard Deering state -- repeatedly -- that rapid, frequent renumbering > isn't going to happen, and was never supposed to... my experience is that he is the least self-deluding of the lot. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 20:25:03 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28451 for ; Fri, 29 Jun 2001 20:25:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G8Nb-000Fqd-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 17:12:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G8Na-000FqX-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 17:12:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G8Na-000Iea-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 17:12:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B3D183D.568D8E6@daimlerchrysler.com> Date: Fri, 29 Jun 2001 20:07:25 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention References: <3B2FD478.74DF935C@daimlerchrysler.com> <20010629145246Z23616-9152+45@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Use of AXFR/IXFR for zone-data replication is an optional part of the protocol, as is Dynamic Update, so how can SOA serial increment, which is only defined in the context of AXFR/IXFR and Dynamic Update, be mandatory? Note that, as usual, I'm not challenging the common understanding here. Obviously we all understand -- or at least assume -- that SOA serial should be incremented to reflect zone-data changes. I'm challenging only the *specification* of the behavior, which, like many things in the older DNS RFCs, seems riddled with loopholes. (And I've heard second-hand that one increasingly-popular DNS implementation, which does not use AXFR/IXFR for replication, doesn't bother with consistently incrementing its serials. If true, then perhaps this issue isn't quite as academic as it may seem...) - Kevin Rob Austein wrote: > Kevin, > > Going back to your original question: > > Date: Tue, 19 Jun 2001 18:38:48 -0400 > From: Kevin Darcy > > Does the SRV protocol prohibit a nameserver from manipulating priorities > and/or weights in its answers depending on the source address of the > requesting client? Perhaps this "localization" can be done within the > implementation and there's no need to burden the protocol with it. This > would just be a more sophisticated version of the A-record sorting > mechanisms in use today. > > As Paul Vixie pointed out, this is a DNS protocol issue, not specific > to SRV. > > The entity acting as a name server can perform this kind of > manipulation if and only if it can update the serial field of the SOA > RR in the authoritative zone. Name servers don't do that except when > acting as the master server in the dynamic update protocol. Changing > zone content without changing the SOA serial field is a protocol > violation. > > More precisely, given the following four queries, performed in order, > and assuming no zone cuts below miskatonic.edu: > > #1 QNAME=miskatonic.edu. QTYPE=SOA QCLASS=IN > #2 QNAME=_foo._bar.cthulhu.miskatonic.edu. QTYPE=SRV QCLASS=IN > #3 QNAME=_foo._bar.cthulhu.miskatonic.edu. QTYPE=SRV QCLASS=IN > #4 QNAME=miskatonic.edu. QTYPE=SOA QCLASS=IN > > If the answers to queries #1 and #4 are the same, the answers to > queries #2 and #3 must also be the same. > > Of course, there's nothing to stop you from writing a program which is > both a name server and a dynamic update client. In theory you could > also write a program which acts as an authoritative name server and > which generates new zone content on the fly at whim, but be sure to > generate a new SOA serial value to go with each new whim, and have fun > making sure that the other authoritative name servers for this zone > return precisely same whimsical zone content as this name server does > for a given SOA serial value.... But for a conventional name server > operating with zones that come from boring old files generated by some > outside source, the answer to your question is "no". > > Sorting A RRs is fundamentally different from changing zone content: > DNS itself makes no promises at all about ordering of RRs within an > RRset, so a name server can present the RRs in any order it likes. > > Hope this clarifies things a bit. > > --Rob > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 29 22:21:49 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00962 for ; Fri, 29 Jun 2001 22:21:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15G9vT-000IwL-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 18:51:59 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15G9vS-000Iw7-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 18:51:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15G9vS-000NG3-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 18:51:58 -0700 To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention In-Reply-To: Message from Kevin Darcy dated "Fri, 29 Jun 2001 20:07:25 EDT" <3B3D183D.568D8E6@daimlerchrysler.com> References: <3B3D183D.568D8E6@daimlerchrysler.com> <3B2FD478.74DF935C@daimlerchrysler.com> <20010629145246Z23616-9152+45@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Fri, 29 Jun 2001 21:48:07 -0400 From: Rob Austein Message-Id: <20010630014813Z23616-9152+61@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 29 Jun 2001 20:07:25 -0400 From: Kevin Darcy Use of AXFR/IXFR for zone-data replication is an optional part of the protocol, as is Dynamic Update, so how can SOA serial increment, which is only defined in the context of AXFR/IXFR and Dynamic Update, be mandatory? See RFC 1034, page 27, last paragraph. While the specific "usage" described in that paragraph has never been recommended, the context makes it clear that the author of RFC 1034 believed that SOA serial numbers were relevant to normal queries, not just to zone transfer. (And I've heard second-hand that one increasingly-popular DNS implementation, which does not use AXFR/IXFR for replication, doesn't bother with consistently incrementing its serials. If true, then perhaps this issue isn't quite as academic as it may seem...) If the implementation in question acts as the master server in the DNS dynamic update protocol and does not increment SOA serial numbers when doing so, that's a bug. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 30 01:18:11 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05080 for ; Sat, 30 Jun 2001 01:18:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GBq9-000P0b-00 for namedroppers-data@psg.com; Fri, 29 Jun 2001 20:54:37 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15GBq5-000P0V-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 20:54:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15GBq5-0003AX-00 for namedroppers@ops.ietf.org; Fri, 29 Jun 2001 20:54:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention References: <3B3D183D.568D8E6@daimlerchrysler.com> <3B2FD478.74DF935C@daimlerchrysler.com> <20010629145246Z23616-9152+45@thrintun.hactrn.net> <20010630014813Z23616-9152+61@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 29 Jun 2001 20:54:37 -0700 Content-Transfer-Encoding: 7bit Rob Austein wrote: > Date: Fri, 29 Jun 2001 20:07:25 -0400 > From: Kevin Darcy > > Use of AXFR/IXFR for zone-data replication is an optional part of the > protocol, as is Dynamic Update, so how can SOA serial increment, which is > only defined in the context of AXFR/IXFR and Dynamic Update, be > mandatory? > > See RFC 1034, page 27, last paragraph. While the specific "usage" > described in that paragraph has never been recommended, the context > makes it clear that the author of RFC 1034 believed that SOA serial > numbers were relevant to normal queries, not just to zone transfer. That paragraph may use mandatory-sounding language, but the section as a whole is prefaced by language which quite unequivocally states that the use of the AXFR "part" of the protocol is optional, albeit preferred. As a matter of strict interpretation, it's far from clear that the mandatory-sounding language has relevance to anything outside of the AXFR "part" of the protocol, i.e. "if you want to use AXFR to replicate zone data, you must do X, Y and Z". Reasonable people can, of course, disagree as to what the *intent* of the specification was. As it happens, I think we probably agree on what the intent was. But loopholes are by definition _unintended_ lacunae in a rule or set of rules. As a practical matter, does anyone know of any DNS software which actually cares about serial numbers in any context besides AXFR/IXFR and/or Dynamic Update? I mean, for example, is there any paranoid caching resolver out there that would invalidate cache entries based on seeing a higher serial number for the containing zone? In the absence of a cut-and-dried rules-conformance argument, I'm just questioning what the practical value is of imposing a burdensome serial-increment requirement on an implementation that wants to "customize" its responses to different clients. Is it merely because such behavior challenges our long-cherished assumptions about how DNS is "supposed" to work? - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 30 14:00:24 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24209 for ; Sat, 30 Jun 2001 14:00:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GMM9-0003wQ-00 for namedroppers-data@psg.com; Sat, 30 Jun 2001 08:08:21 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15GMM9-0003wJ-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 08:08:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15GMM9-000DDv-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 08:08:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: RFC 2782: SRV naming convention In-Reply-To: References: <3B3D183D.568D8E6@daimlerchrysler.com> <3B2FD478.74DF935C@daimlerchrysler.com> <20010629145246Z23616-9152+45@thrintun.hactrn.net> <20010630014813Z23616-9152+61@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 30 Jun 2001 08:08:21 -0700 Content-Transfer-Encoding: 7bit Date: Fri, 29 Jun 2001 20:54:37 -0700 From: Kevin Darcy Message-ID: | That paragraph may use mandatory-sounding language, but the section | as a whole is prefaced by language which quite unequivocally states | that the use of the AXFR "part" of the protocol is optional, AXFR is optional, no doubt about it. That a serial number identifies zone contents isn't even in doubt. | As a practical matter, does anyone know of any DNS software which actually | cares about serial numbers in any context besides AXFR/IXFR and/or Dynamic | Update? I'm not aware of one, but the possibility has often been postulated. | I mean, for example, is there any paranoid caching resolver out there | that would invalidate cache entries based on seeing a higher serial number | for the containing zone? That would be wrong. The TTL specifies how long the data is allowed to be cached. "wrong" in the sense that nothing about the SOA specifies that should happen - the server is free to invalidate its cache any time it likes of course. But what the server could do, upon seeing a SOA that is the same as an earlier one it saw, is revert all TTLs for records from the zone since the earlier SOA was received to the values they had when the RR was initially learned. That is, undo any decrementing that has been done to the TTL, as receiving the same SOA tells the server that if it asked again, it would get the same data returned - along with the same (or perhaps higher if the RR wasn't received directly) TTL. What makes this hard to actually implement, is that it is quite difficult to determine whether a name is actually in a particular zone or not. Doing that is likely to be as much, or more, work than simply refreshing the RR separately. Dynamic DNS requires this question be answered anyway, so nodes doing that will have the answer, and might start adding the optimisation (though with DynDNS the serial number is perhaps likely to change so often that the benefits won't be there). It is also possible that some side effect of dnssec might provide similar benefits (I haven't looked at that closely enough to be sure). | In the absence of a cut-and-dried rules-conformance | argument, I'm just questioning what the practical value is of imposing a | burdensome serial-increment requirement on an implementation that wants to | "customize" its responses to different clients. The DNS provides a single global database. If you want a protocol that provides different answers to different clients, then you should be inventing a new protocol. Rob's messages were 100% correct. For what its worth, I don't like the bind9 "view" stuff, for just the same reason - however, something is only broken if you can demonstrate that it is broken. As long as it is possible to guarantee that clients always see the same data (no matter which server they query, no matter which method they use to fetch the data) for one instance of the zone, then everything appears to be working. | Is it merely because such behavior challenges our long-cherished | assumptions about how DNS is "supposed" to work? Our assumptions about how the DNS is supposed to work is actually the definition of the DNS. The RFCs etc are an attempt to capture that, which are not always perfect. That's why we attempt to fix them where needed. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 30 14:00:32 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24219 for ; Sat, 30 Jun 2001 14:00:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GODC-0008xF-00 for namedroppers-data@psg.com; Sat, 30 Jun 2001 10:07:14 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15GODA-0008x8-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 10:07:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15GODA-000Ivk-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 10:07:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: Robert Elz's message of "30 Jun 2001 08:22:05 -0700" References: <200106290607.XAA89376@redpaul.mfnx.net> X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 30 Jun 2001 10:07:14 -0700 Content-Transfer-Encoding: 7bit > Yes, I know - you've had this master/slave fixation for some time (which is > why bind got changed from calling itself a primary or secondary for a zone > into a master or a slave as well). That doesn't make it correct. Robert, you were involved in the RFC 1996 discussions, both in the meetings and here on the mailing list. You ought to remember that what was determined (proposed by me and consensed by others) is that there is no such thing as a "primary" vs "secondary" server. Servers are authoritative for zero or more zones. Servers either behave recursively or they won't. A server which is authoritative for some zone either uses AXFR (and now maybe IXFR) or it doesn't. If it doesn't use AXFR/IXFR then it still has to obey the SOA rules. The shorthand of "primary" used to mean "loads the zone content from outside the DNS" but that's a meaningless distinction if DNS isn't used to copy zones between the various authoritative servers for the zone. All of them would be primary in that case. (I think Microsoft says they do this, though I'm unsure whether they've got it right.) That and only that is why late model BIND calls zones "master" and "slave". "Master" means load from disk. "Slave" means load via AXFR/IXFR (and disk). I now wish I'd just called them "authority" zones and let the presence or absence of a "masters { };" clause determine the masterness/slaveness type. "Master" and "slave" survived the terminology evaluation because they refer to a useful distinction -- "which role do you take in AXFR/IXFR?" Whereas "Primary" and "secondary" did not survive because they refer to no useful distinction. (You are, by the way, the last person in the IETF whom I would have expected an argument ad hominem from. Please realize that for 20 years or more you have set an example of high grade personal behaviour that the rest of us have treated as the "gold standard." Please do not abandon that course now.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 30 14:00:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24229 for ; Sat, 30 Jun 2001 14:00:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GMLu-0003un-00 for namedroppers-data@psg.com; Sat, 30 Jun 2001 08:08:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15GMLt-0003uh-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 08:08:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15GMLt-000DD9-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 08:08:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Paul A Vixie cc: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-Reply-To: <200106290607.XAA89376@redpaul.mfnx.net> References: <200106290607.XAA89376@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 30 Jun 2001 08:08:06 -0700 Content-Transfer-Encoding: 7bit Date: Thu, 28 Jun 2001 23:07:51 -0700 From: Paul A Vixie Message-ID: <200106290607.XAA89376@redpaul.mfnx.net> | i disagree. I thought that you might. | 103[45] was ambiguous to a fault on this matter. It is true that it confuses primary server with master server a few times, but in general, it is fairly clear, and it certainly is clear that "slave" occurs never. 1034/5 doesn't provide a lot of good information on AXFR it is true (which is why this new doc should help) but it is mostly clear in its use of terminology. | master and slave are roles taken during an AXFR If we need names for that, which is probably not a bad idea, client and server is the more traditional terminology - further it avoids adding to the already slightly confused use of "master" in 103[45]. | the term "transfer initiator" and "transfer responder" would perhaps be as | accurate, they don't roll off the keyboard as well as "slave" and "master". Which is why we mostly (in other protocols) just use "client" and "server" for those roles... | an authoritative zone server can be a master, or a slave, or neither (if | there are no AXFR's or IXFR's involved, and the zone maintainance is being | done out of band), or both (if the transfer graph is deep). It can be all of those things whatever the labels applied are. | see RFC 1996 2.1. Yes, I know - you've had this master/slave fixation for some time (which is why bind got changed from calling itself a primary or secondary for a zone into a master or a slave as well). That doesn't make it correct. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 30 14:01:33 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24263 for ; Sat, 30 Jun 2001 14:01:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GMOn-00045h-00 for namedroppers-data@psg.com; Sat, 30 Jun 2001 08:11:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15GMOn-00045X-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 08:11:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15GMOn-000DMB-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 08:11:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Peter Koch To: gson@nominum.com (Andreas Gustafsson) Cc: DNSEXT mailing list Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call In-reply-to: Your message of "Thu, 28 Jun 2001 13:56:03 PDT." <200106282056.NAA16721@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 30 Jun 2001 08:11:05 -0700 Content-Transfer-Encoding: 7bit citing gson@nominum.com (Andreas Gustafsson): > "glue pointer" based implementation above (and I third one I was told > about in private email), though I still think they should be > discouraged. That is, I can change the text to say that the master > SHOULD NOT send duplicates, and the slave MUST ignore duplicates. One reason for suggesting to discourage duplicates was AXFR efficiency. With very large (TLD) zones currently a non-negligible part of the transfer is redundant ``glue''. While the result after an AXFR will be the same iff the slave is to ignore the duplicates, transmitting them will cost resources. So will suppressing them, and one may argue that with SIG RRs everything will increase in volume anyway, but I do not see why that should prevent us from saving as much as can be achieved reasonably. I agree with Andreas' proposed text above. -Peter to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 30 22:47:05 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29658 for ; Sat, 30 Jun 2001 22:47:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.30 #1) id 15GWo7-0000bB-00 for namedroppers-data@psg.com; Sat, 30 Jun 2001 19:17:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.30 #1) id 15GWo6-0000b4-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 19:17:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15GWo6-000J4f-00 for namedroppers@ops.ietf.org; Sat, 30 Jun 2001 19:17:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Date: Sat, 30 Jun 2001 19:17:55 -0700 Content-Transfer-Encoding: 7bit Where did the WG chairs get this ``SHORT last call'' idea from? This draft was announced on 22 June. The WG chairs, without giving us any extra time to review the draft, announced a ``SHORT last call'' ending on 30 June. I've just returned from vacation. I haven't seen the draft yet. I object to this absurd last-call schedule. I have glanced at the summary of changes provided in the last call. It seems that several of my objections have been ignored. I object to the new draft for all the same reasons. I also question the judgment of the WG chairs in putting a biased vendor draft, admitted by the author to be out of line with existing practice, up for last call. ---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.