From owner-namedroppers@ops.ietf.org Tue Aug 1 08:40:21 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24295 for ; Tue, 1 Aug 2000 08:40:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13JabL-000PVf-00 for namedroppers-data@psg.com; Tue, 01 Aug 2000 04:52:51 -0700 Received: from wireless-132-153.ietf.marconi.com ([147.73.132.153] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13JabJ-000PUx-00 for namedroppers@ops.ietf.org; Tue, 01 Aug 2000 04:52:50 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13JabJ-0000CQ-00 for namedroppers@ops.ietf.org; Tue, 01 Aug 2000 07:52:49 -0400 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: Tue, 01 Aug 2000 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 Wed Aug 2 13:54:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12391 for ; Wed, 2 Aug 2000 13:54:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13K1vC-000GH0-00 for namedroppers-data@psg.com; Wed, 02 Aug 2000 10:03:10 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13K1vC-000GGt-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 10:03:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13K1vA-0001Gq-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 13:03:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200008021533.IAA17648@zed.isi.edu> Subject: zones w/ downs syndrom To: namedroppers@internic.net Date: Wed, 2 Aug 2000 08:33:55 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit is it useful to distinguish the existance of zone files that consist of a single SOA record? -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 2 14:39:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25481 for ; Wed, 2 Aug 2000 14:39:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13K2kc-000IGz-00 for namedroppers-data@psg.com; Wed, 02 Aug 2000 10:56:18 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13K2kb-000IGs-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 10:56:17 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13K2kZ-0001K8-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 13:56:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008021754.KAA90724@redpaul.mibh.net> To: namedroppers@internic.net Subject: Re: zones w/ downs syndrom In-reply-to: Your message of "Wed, 02 Aug 2000 08:33:55 PDT." <200008021533.IAA17648@zed.isi.edu> Date: Wed, 02 Aug 2000 10:54:17 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > is it useful to distinguish the existance of zone files that consist > of a single SOA record? no. without at least one NS RR, it's not a valid zone. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 2 14:43:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26782 for ; Wed, 2 Aug 2000 14:43:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13K32y-000Iyw-00 for namedroppers-data@psg.com; Wed, 02 Aug 2000 11:15:16 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13K32x-000Iyp-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 11:15:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13K32t-0001Le-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 14:15:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <005101bffcad$488f0ee0$bc814993@elsie> From: "Cricket Liu" To: "Bill Manning" , References: <200008021533.IAA17648@zed.isi.edu> Subject: Re: zones w/ downs syndrom Date: Wed, 2 Aug 2000 12:12:55 -0600 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > is it useful to distinguish the existance of zone files that consist > of a single SOA record? Distinguish them from what? Where? cricket to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 2 17:09:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20493 for ; Wed, 2 Aug 2000 17:09:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13K5HX-000OM6-00 for namedroppers-data@psg.com; Wed, 02 Aug 2000 13:38:27 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13K5HW-000OLz-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 13:38:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13K5HV-0002AF-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 16:38:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398882D1.F93D8F7A@whistle.com> Date: Wed, 02 Aug 2000 13:21:37 -0700 From: Terry Lambert To: Paul A Vixie CC: namedroppers@internic.net Subject: Re: zones w/ downs syndrom References: <200008021754.KAA90724@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: >> is it useful to distinguish the existance of zone files that consist >> of a single SOA record? > no. without at least one NS RR, it's not a valid zone. I use such a beast to allow DNSUPDAT to create all of the other zone data. This is because DNSUPDAT can't create SOA recors in masters, for no reason prohibited by the RFCs, but disallows it for fear it's a slave, not a master (per the last discussion on DNSEXT on this topic). I think that it's not a valid zone, but it's "mostly harmless", at worst. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 2 17:37:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29997 for ; Wed, 2 Aug 2000 17:37:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13K5lb-000PbT-00 for namedroppers-data@psg.com; Wed, 02 Aug 2000 14:09:31 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13K5lb-000PbN-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 14:09:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13K5jN-0002mM-00 for namedroppers@ops.ietf.org; Wed, 02 Aug 2000 17:07:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: namedroppers@internic.net Subject: Re: zones w/ downs syndrom In-Reply-To: Your message of "Wed, 02 Aug 2000 13:21:37 MST." <398882D1.F93D8F7A@whistle.com> Date: Thu, 03 Aug 2000 07:00:32 +1000 Message-Id: <17922.965250032@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 02 Aug 2000 13:21:37 -0700 From: Terry Lambert Message-ID: <398882D1.F93D8F7A@whistle.com> | I think that it's not a valid zone, but it's "mostly | harmless", at worst. It can't be a valid zone, as zones are created by the NS records that separate them from their parents (and the NS records in the parent should be a copy of the NS records in the child). Something with only an SOA record is conceptually no different than something with only an A record - except that the SOA record makes no sense in that context. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 10:36:27 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24000 for ; Thu, 3 Aug 2000 10:36:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KLTO-0007Xr-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 06:55:46 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KLTO-0007Xk-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 06:55:46 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KLTM-0003EU-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 09:55:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008031351.IAA22822@gungnir.fnal.gov> To: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Comments on draft-ietf-dnsext-message-size-00.txt Date: Thu, 03 Aug 2000 08:51:10 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit First comment: Don't think in terms of DNS "MTU", rather think in terms of DNS "buffer size" while keeping MTU considerations in mind. Second comment: I suggest 2048 as the minimum buffer size which must be advertised by an OPT RR in the cases mentioned in the draft (and the case mentioned by Kazu Yamamoto). This can lead to fragmentation, which in IPv6 must be perfomred by the node originating the packet. Matt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 10:36:53 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24199 for ; Thu, 3 Aug 2000 10:36:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KLTc-0007Zy-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 06:56:00 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KLTb-0007Zs-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 06:55:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KLTa-0003EX-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 09:55:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Aug 2000 22:52:04 +0900 (JST) From: Jun-ichiro itojun Hagino Message-Id: <200008031352.e73Dq4O06864@ starfruit.itojun.org> To: mohta@necom830.hpcl.titech.ac.jp Subject: anycast in DNS queries Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit in IETF48 dnsext session, i made a comment to ohta-san about use of anycast for DNS root servers. i checked ohta-san's draft. the word "anycast" is used differently from RFC2460. i assuemd "anycast" in RFC2460 sense. sorry if i was not clear enough. RFC2460 anycast cannot be used in UDP source address. if you send UDP DNS query to RFC2460 anycast address, source address for the reply will use different address from the destination address of query. query: X -> anycast reply: unicast -> X (anycast != anycast) therefore, normal resolvers will choke. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 11:25:38 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14098 for ; Thu, 3 Aug 2000 11:25:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KMB4-0009ce-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 07:40:54 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KMB3-0009cX-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 07:40:53 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KLy6-0003Gs-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 10:27:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008031412.e73ECsM06999@ starfruit.itojun.org> To: namedroppers@ops.ietf.org cc: kazu@iijlab.net Subject: IPv6 DNS packet size From: Jun-ichiro itojun Hagino Date: Thu, 03 Aug 2000 23:12:54 +0900 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I made some comment at IETF48 dnsext session. i write those out, in case i wasn't clear enough (language issue...) itojun --- - EDNS0 i agree completely with the points raised in the session, like: mandate EDNS0 for servers/clients that support A6 queries/replies mandate EDNS0 support for IPv6 transport-ready servers/clients as commented in session, they do not necessarily contradict. - fragment issues IPv6 mandates path MTU discovery. that means, if you try to transmit UDP packet larger than path MTU, the packet may not go through the path and dropped (icmp6 too big will be returned, and server/client needs to resend smaller fragments based on the new path MTU learnt). For simplicity (avoid retransmit), the following logic should be recommended: if (we know path MTU for sure) send IPv6 UDP DNs query/reply, fragmented to fit into path MTU. else { send IPv6 UDP DNs query/reply, fragmented to fit into 1280 octets. } or, make it even simpler: send IPv6 UDP DNS query/reply, fragmented to fit into 1280 octets. - minimum buffer size in the session, it was proposed to set minimum DNS buffer size to 1280 for IPv6. there are couple of parameters. - RFC2460 section 5 says "IPv6 minimum MTU is 1280 octets". this is to carry 256 octets for header, and 1024 octets for message body. as we have this requirement, even if IPv6 packets are tunneled, we know for sure that we have minimum MTU of 1280 octets. the problem is not in tunnels, but in extension headers (source routing, IPsec, mobile ip6 options, whatever) between IPv6 and UDP headers. - any IPv6 nodes are capable of fragmented packets. the requirement imposes IPv6 nodes to support packets of 1500 octets, after reassembly (RFC2460 page 24) i think it makes more sense to recommend minimum requirement for "IPv6 UDP payload size for DNS queries/replies" 1024, not 1280. if we make it 1280, we are likely to see fragmentation, for packets carrying payload with minimum buffer size. this looks a bit strange for me. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 11:30:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16678 for ; Thu, 3 Aug 2000 11:30:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KMXl-000Acr-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 08:04:21 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KMXl-000AcR-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 08:04:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KMXk-0003KA-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 11:04:20 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008031456.HAA18936@zed.isi.edu> Subject: mdns-06 text To: namedroppers@internic.net Date: Thu, 3 Aug 2000 07:56:44 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur asked that this draft be published online someplace while waiting for the id to be published. ftp.isi.edu:/pub/bill/mdns06 -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 11:46:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22983 for ; Thu, 3 Aug 2000 11:46:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KMk6-000Av1-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 08:17:06 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KMk6-000Auf-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 08:17:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KMjs-0003Ki-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 11:16:52 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008031513.IAA18965@zed.isi.edu> Subject: Re: zones w/ downs syndrom To: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 3 Aug 2000 08:13:13 -0700 (PDT) Cc: namedroppers@internic.net In-Reply-To: <17922.965250032@mundamutti.cs.mu.OZ.AU> from "Robert Elz" at Aug 03, 2000 07:00:32 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % | I think that it's not a valid zone, but it's "mostly % | harmless", at worst. % % It can't be a valid zone, as zones are created by the NS records % that separate them from their parents (and the NS records in the % parent should be a copy of the NS records in the child). the NS records that separate the zone from its parent (in the predominate implementation) are found in the parent. If an SOA record, and only an SOA record exists in the child, it will appear to not be a lame delegation. e.g. a valid delegation. The statements from yourself, Paul and MAP indicate that a valid zone must have at least two RR's, an SOA and an NS. Others (Lars, Andreas, et.al.) think that it might be "useable" and therefore is valid. So, this desolves into three questions: ) what is a valid delegation? ) what is a valid reception of a delegation? ) what is a valid zone? --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 13:53:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10241 for ; Thu, 3 Aug 2000 13:53:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KObZ-000DRp-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 10:16:25 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KObX-000DQu-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 10:16:24 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KObT-0003O5-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 13:16:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008031524.e73FOSM07879@ starfruit.itojun.org> To: namedroppers@ops.ietf.org Subject: IPv6 DNS packet size From: Jun-ichiro itojun Hagino Date: Fri, 04 Aug 2000 00:24:28 +0900 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit it looks to me that the article was From: filtered, so i'd like to resend. sorry if it get through twice. itojun To: namedroppers@ops.ietf.org cc: kazu@iijlab.net Subject: IPv6 DNS packet size From: Jun-ichiro itojun Hagino Date: Thu, 03 Aug 2000 23:12:54 +0900 Sender: itojun@localhost I made some comment at IETF48 dnsext session. i write those out, in case i wasn't clear enough (language issue...) itojun --- - EDNS0 i agree completely with the points raised in the session, like: mandate EDNS0 for servers/clients that support A6 queries/replies mandate EDNS0 support for IPv6 transport-ready servers/clients as commented in session, they do not necessarily contradict. - fragment issues IPv6 mandates path MTU discovery. that means, if you try to transmit UDP packet larger than path MTU, the packet may not go through the path and dropped (icmp6 too big will be returned, and server/client needs to resend smaller fragments based on the new path MTU learnt). For simplicity (avoid retransmit), the following logic should be recommended: if (we know path MTU for sure) send IPv6 UDP DNs query/reply, fragmented to fit into path MTU. else { send IPv6 UDP DNs query/reply, fragmented to fit into 1280 octets. } or, make it even simpler: send IPv6 UDP DNS query/reply, fragmented to fit into 1280 octets. - minimum buffer size in the session, it was proposed to set minimum DNS buffer size to 1280 for IPv6. there are couple of parameters. - RFC2460 section 5 says "IPv6 minimum MTU is 1280 octets". this is to carry 256 octets for header, and 1024 octets for message body. as we have this requirement, even if IPv6 packets are tunneled, we know for sure that we have minimum MTU of 1280 octets. the problem is not in tunnels, but in extension headers (source routing, IPsec, mobile ip6 options, whatever) between IPv6 and UDP headers. - any IPv6 nodes are capable of fragmented packets. the requirement imposes IPv6 nodes to support packets of 1500 octets, after reassembly (RFC2460 page 24) i think it makes more sense to recommend minimum requirement for "IPv6 UDP payload size for DNS queries/replies" 1024, not 1280. if we make it 1280, we are likely to see fragmentation, for packets carrying payload with minimum buffer size. this looks a bit strange for me. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 13:54:42 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10744 for ; Thu, 3 Aug 2000 13:54:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KOiF-000DZa-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 10:23:19 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KOiE-000DZU-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 10:23:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KOiD-0003OQ-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 13:23:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008031536.RAA90245@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: mohta@necom830.hpcl.titech.ac.jp, namedroppers@ops.ietf.org Subject: Re: anycast in DNS queries In-reply-to: Your message of Thu, 03 Aug 2000 22:52:04 +0900. <200008031352.e73Dq4O06864@ starfruit.itojun.org> Date: Thu, 03 Aug 2000 17:36:50 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In your previous mail you wrote: RFC2460 anycast cannot be used in UDP source address. if you send UDP DNS query to RFC2460 anycast address, source address for the reply will use different address from the destination address of query. query: X -> anycast reply: unicast -> X (unicast != anycast) therefore, normal resolvers will choke. => Aboba & all proposal has the same problem, it uses multicast and: query: X -> multicast reply: unicast -> multicast or X (*) unicast != multicast *: the I-D is not very clear, it says "the response is multicast to the LINKLOCAL address" (ie. there is at least a spelling error?). But for the argument this doesn't matter... Francis.Dupont@enst-bretagne.fr PS: for IPv6 there is a tradeoff between multicast/anycast (as query destination) and unicast/multicast (as response destination). In all cases source addresses MUST be unicast (I don't consider yet the strange idea to use an unspecified source: I think this will never be useful). to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 13:55:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10976 for ; Thu, 3 Aug 2000 13:55:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KOqS-000DmP-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 10:31:48 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KOqS-000DmJ-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 10:31:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KOqT-0003P7-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 13:31:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Richard Johnson Message-ID: <14729.49732.410348.224894@kitab.cisco.com> Date: Thu, 3 Aug 2000 12:04:36 -0700 (PDT) To: Randy Bush Cc: namedroppers@internic.net Subject: Re: mdns-06 text In-Reply-To: <200008031456.HAA18936@zed.isi.edu> References: <200008031456.HAA18936@zed.isi.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Olafur asked that this draft be published online someplace while waiting > for the id to be published. > > ftp.isi.edu:/pub/bill/mdns06 It's there but it's not world readable. /raj to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 13:57:19 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11901 for ; Thu, 3 Aug 2000 13:57:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KOli-000Dej-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 10:26:54 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KOlg-000DeV-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 10:26:54 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KOlZ-0003OZ-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 13:26:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Matt Crawford" cc: namedroppers@ops.ietf.org In-reply-to: crawdad's message of Thu, 03 Aug 2000 08:51:10 EST. <200008031351.IAA22822@gungnir.fnal.gov> Subject: Re: Comments on draft-ietf-dnsext-message-size-00.txt From: itojun@itojun.org Date: Fri, 04 Aug 2000 01:00:31 +0900 Message-ID: <9297.965318431@coconut.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Second comment: I suggest 2048 as the minimum buffer size which >must be advertised by an OPT RR in the cases mentioned in the >draft (and the case mentioned by Kazu Yamamoto). This can lead >to fragmentation, which in IPv6 must be perfomred by the node >originating the packet. minimum buffer size of 2048 is too big. it exceeds minimum reassembly packet size requirement (must support packet size <= 1500 octet after reassembly) for IPv6 nodes. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 3 21:02:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20922 for ; Thu, 3 Aug 2000 21:02:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13KV6T-000LRj-00 for namedroppers-data@psg.com; Thu, 03 Aug 2000 17:12:45 -0700 Received: from wireless-132-222.ietf.marconi.com ([147.73.132.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13KV6S-000LRd-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 17:12:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13KV6O-0003gp-00 for namedroppers@ops.ietf.org; Thu, 03 Aug 2000 20:12:40 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008032325.QAA19487@zed.isi.edu> Subject: waylaid notice To: namedroppers@internic.net Date: Thu, 3 Aug 2000 16:25:39 -0700 (PDT) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit mdns-06 permissions have been corrected. (sorry for the delay, the notes were not sent to me directly) -- --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 Mon Aug 7 15:19:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08873 for ; Mon, 7 Aug 2000 15:19:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13LrTq-0008kE-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 11:18:30 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13LrTp-0008k8-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 11:18:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13LrTp-0006JB-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 11:18:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 7 Aug 2000 11:08:55 -0700 (PDT) Message-Id: <200008071808.LAA05935@gulag.araneus.fi> To: namedroppers@internic.net Subject: Re: zones w/ downs syndrom In-Reply-To: <200008021533.IAA17648@zed.isi.edu> References: <200008021533.IAA17648@zed.isi.edu> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill Manning asked: > is it useful to distinguish the existance of zone files that consist > of a single SOA record? Apparently this question is Bill's (somewhat provocative) response to a comment I made at the Pittsburgh interoperability session regarding such zone files. Let me explain the background a bit... I find zones with only a SOA record to be both harmless and quite useful when setting up new zones by means of dynamic update: a zone consisting of only the SOA is first created in the master server using an out-of-band mechanism, and then all the remaining zone data including the NS records are added using the standard dynamic update protocol. Unfortunately, there is an ambiguity in the IXFR protocol that affects zones with only an SOA. An incremental transfer is normally identified by the fact that it begins with two consecutive SOAs, but a nonincremental (AXFR-style) transfer of a zone with only an SOA will consist of two consecutive copies of the SOA and will therefore be misinterpreted as the start of an incremental transfer. This ambiguity can be resolved by examining the serial numbers of the SOAs, and I would like to amend the IXFR specification with a requirement to do exactly that. However, there seems to be some opposition to this, on the grounds that zones consisting of only the SOA supposedly should never exist in the first place. Robert Elz said: > It can't be a valid zone, as zones are created by the NS records > that separate them from their parents (and the NS records in the > parent should be a copy of the NS records in the child). It may not be considered a valid zone by a resolver, but there is nothing wrong with it from the perspective of an authoritative server. I would consider it an operational error to delegate authority to a zone with no NS records, but such a zone should still be allowed to exist transiently in its authoritative servers while those servers are being configured. -- 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 Aug 7 16:25:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14202 for ; Mon, 7 Aug 2000 16:25:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Lsu1-0009tf-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 12:49:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Lsu1-0009tZ-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 12:49:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Lsu0-0006zs-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 12:49:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200008071808.LAA05935@gulag.araneus.fi> References: <200008021533.IAA17648@zed.isi.edu> <200008021533.IAA17648@zed.isi.edu> Date: Mon, 7 Aug 2000 15:39:38 -0400 To: gson@nominum.com (Andreas Gustafsson) From: Edward Lewis Subject: Re: zones w/ downs syndrom Cc: namedroppers@internic.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 2:08 PM -0400 8/7/00, Andreas Gustafsson wrote: >It may not be considered a valid zone by a resolver, but there is >nothing wrong with it from the perspective of an authoritative server. >I would consider it an operational error to delegate authority to a >zone with no NS records, but such a zone should still be allowed to >exist transiently in its authoritative servers while those servers >are being configured. Now, this may be just a beer-fogged memory of mine, but I thought I once read that the MNAME in the SOA could serve as an implicit NS record. I.e., the server in the SOA needn't appear in an NS record. I thought I once saw this, but I recall another time that I tried to find the text and failed finding it. Perhaps this came from RFC 1033: >SOA (Start Of Authority) > > [] [] SOA ( > > > > > ) ... > > is the name of the host on which the master zone file > resides. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 7 17:04:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03575 for ; Mon, 7 Aug 2000 17:04:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Ltc7-000ATS-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 13:35:11 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Ltc7-000ATM-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 13:35:11 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Ltc7-0007JG-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 13:35:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 7 Aug 2000 13:24:20 -0700 (PDT) Message-Id: <200008072024.NAA05998@gulag.araneus.fi> To: Edward Lewis CC: namedroppers@internic.net Subject: Re: zones w/ downs syndrom In-Reply-To: References: <200008021533.IAA17648@zed.isi.edu> <200008071808.LAA05935@gulag.araneus.fi> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis said: > Now, this may be just a beer-fogged memory of mine, but I thought I once > read that the MNAME in the SOA could serve as an implicit NS record. I.e., > the server in the SOA needn't appear in an NS record. It is true that the SOA MNAME need not appear in an NS record, and it often doesn't in the case of "hidden primary" configurations, where all the servers listed in NS records are slaves to an unlisted master. However, this does not mean that the SOA MNAME "serves as an implicit NS". Resolvers only send queries to the NSes, never to the SOA MNAME, and there still has to be at least one NS listed for correct resolution (and more than one for redundance). -- 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 Aug 7 18:31:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16932 for ; Mon, 7 Aug 2000 18:31:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Luue-000BWB-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 14:58:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Luue-000BW5-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 14:58:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Luue-0007tU-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 14:58:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398F307B.7E8C1966@daimlerchrysler.com> Date: Mon, 07 Aug 2000 17:56:11 -0400 From: Kevin Darcy To: namedroppers@internic.net Subject: Re: zones w/ downs syndrom References: <200008021533.IAA17648@zed.isi.edu> <200008071808.LAA05935@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Loosening IXFR is just addressing a symptom. The *cause* is RFC 2136's arbitrary restriction on the dynamic addition or deletion of SOA records. Obsolete that restriction, and you can create the zones entirely through dynamic update, with the NS records popping into existence *simultaneously* with the addition of the SOA record. Then you never get any "down's syndrome" and no IXFR complications. - Kevin gson@nominum.com wrote: > Bill Manning asked: > > is it useful to distinguish the existance of zone files that consist > > of a single SOA record? > > Apparently this question is Bill's (somewhat provocative) response to > a comment I made at the Pittsburgh interoperability session regarding > such zone files. Let me explain the background a bit... > > I find zones with only a SOA record to be both harmless and quite > useful when setting up new zones by means of dynamic update: a zone > consisting of only the SOA is first created in the master server using > an out-of-band mechanism, and then all the remaining zone data > including the NS records are added using the standard dynamic update > protocol. > > Unfortunately, there is an ambiguity in the IXFR protocol that affects > zones with only an SOA. An incremental transfer is normally > identified by the fact that it begins with two consecutive SOAs, but a > nonincremental (AXFR-style) transfer of a zone with only an SOA will > consist of two consecutive copies of the SOA and will therefore be > misinterpreted as the start of an incremental transfer. > > This ambiguity can be resolved by examining the serial numbers of the > SOAs, and I would like to amend the IXFR specification with a > requirement to do exactly that. However, there seems to be some > opposition to this, on the grounds that zones consisting of only the > SOA supposedly should never exist in the first place. > > Robert Elz said: > > It can't be a valid zone, as zones are created by the NS records > > that separate them from their parents (and the NS records in the > > parent should be a copy of the NS records in the child). > > It may not be considered a valid zone by a resolver, but there is > nothing wrong with it from the perspective of an authoritative server. > I would consider it an operational error to delegate authority to a > zone with no NS records, but such a zone should still be allowed to > exist transiently in its authoritative servers while those servers > are being configured. > -- > 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. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 8 08:17:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05602 for ; Tue, 8 Aug 2000 08:17:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13LviK-000CDr-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 15:49:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13LviJ-000CDl-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 15:49:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13LviJ-0008Ed-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 15:49:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008072244.PAA17815@redpaul.mibh.net> To: namedroppers@internic.net Subject: Re: zones w/ downs syndrom In-reply-to: Your message of "Mon, 07 Aug 2000 17:56:11 EDT." <398F307B.7E8C1966@daimlerchrysler.com> Date: Mon, 07 Aug 2000 15:44:00 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Loosening IXFR is just addressing a symptom. The *cause* is RFC 2136's > arbitrary restriction on the dynamic addition or deletion of SOA records. Arbitrary? As the author, let me just say, it's not there arbitrarily. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 8 08:18:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06259 for ; Tue, 8 Aug 2000 08:18:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13LxPb-000Dd4-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 17:38:31 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13LxPb-000Dcy-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 17:38:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13LxPa-0008vm-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 17:38:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398F480A.29D55E19@daimlerchrysler.com> Date: Mon, 07 Aug 2000 19:36:42 -0400 From: Kevin Darcy To: namedroppers@internic.net Subject: Re: zones w/ downs syndrom References: <200008072244.PAA17815@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: > > Loosening IXFR is just addressing a symptom. The *cause* is RFC 2136's > > arbitrary restriction on the dynamic addition or deletion of SOA records. > > Arbitrary? As the author, let me just say, it's not there arbitrarily. Maybe "arbitrary" was a bit strong. I've been known to abuse that term at times. Technically, it's not "arbitrary", since a justification is given for the restriction, namely: "there is no provision for a slave server to be told who its master servers are." To me, this sounds like nothing more than an implementation detail; in truth there are a myriad out-of-band ways to tell a slave server who its masters are, some less convenient, reliable and/or secure than others. Could you please explain why/how this became a *protocol* restriction? It seems I'm overlooking something which is obvious to everyone else. - 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 Aug 8 08:18:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06304 for ; Tue, 8 Aug 2000 08:18:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13M1bn-000GJU-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 22:07:23 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13M1bm-000GJN-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 22:07:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13M1bm-000ATW-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 22:07:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398F85D3.A63C0876@daimlerchrysler.com> Date: Tue, 08 Aug 2000 00:00:19 -0400 From: Kevin Darcy To: namedroppers@internic.net Subject: Re: zones w/ downs syndrom References: <200008072244.PAA17815@redpaul.mibh.net> <398F55B4.C39F4FB5@whistle.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Terry, I don't see that every new feature of DNS needs to enhance security. The point of allowing dynamic zone creation is not to enhance security, but to provide convenience and productivity for administrators. It is sufficient, is it not? that it not *harm* security. I don't see that it does. The security of the Dynamic Updates themselves is, we agree, not the issue, and as for the security of initiating master/slave relationships, people can just keep on using the same presumably-secure out-of-band mechanisms for this as they are using today -- the fact that the zone was created dynamically doesn't impact this much one way or the other. What *new* security challenge does dynamic zone-creation raise? - Kevin P.S. Of course I have searched the archives for these alleged discussions, every which way I could think of. They seem to be missing from the archives, or at least are very well hidden. Pointers or suggestions as to their whereabouts would be greatly appreciated. Terry Lambert wrote: > Paul A Vixie wrote: > > > Loosening IXFR is just addressing a symptom. The > > > *cause* is RFC 2136's arbitrary restriction on the > > > dynamic addition or deletion of SOA records. > > > > Arbitrary? As the author, let me just say, it's not > > there arbitrarily. > > Anyone who disagrees with that needs to go back and > read the list archives. > > It's not arbitrary. We all discussed this before. > It's just not useful in the context of a master; > the protection is a bit over the top, if your updater > has already got a security relationship in place with > the master. > > For a slave, it's a real problem, since there is not > a preexisting security relationship that can be used > as a lever, without adding more complex transactions > or assumptions about the master/slave relationship. > > Creating zones in a slave is a much harder proposition, > and the current restriction makes this not a problem. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 8 08:43:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28607 for ; Tue, 8 Aug 2000 01:46:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Lxa2-000Dm6-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 17:49:18 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Lxa2-000Dm0-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 17:49:18 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Lxa2-00090b-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 17:49:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200008072339.IAA04828@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA04828; Tue, 8 Aug 2000 08:39:16 +0900 Subject: Re: zones w/ downs syndrom In-Reply-To: <114.965688512@mundamutti.cs.mu.OZ.AU> from Robert Elz at "Aug 8, 2000 08:48:32 am" To: Robert Elz Date: Tue, 8 Aug 2000 08:39:15 +0859 () CC: Andreas Gustafsson , namedroppers@internic.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kre; > ps: I am deliberately making no comment on the issues of whether IXFR ought > to be able to deal with a "zone" that contains no more than an SOA record, > nor whether or not it really should be possible to use dynamic update to > add the SOA record to a zone. It is an issue of whether AXFR ought to be able to deal with a "zone" that contains no more than an SOA record. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 8 08:43:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28598 for ; Tue, 8 Aug 2000 01:46:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13LxWE-000Di2-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 17:45:22 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13LxWE-000Dhw-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 17:45:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13LxWE-0008z1-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 17:45:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <398F55B4.C39F4FB5@whistle.com> Date: Mon, 07 Aug 2000 17:35:00 -0700 From: Terry Lambert To: Paul A Vixie CC: namedroppers@internic.net Subject: Re: zones w/ downs syndrom References: <200008072244.PAA17815@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: > > Loosening IXFR is just addressing a symptom. The > > *cause* is RFC 2136's arbitrary restriction on the > > dynamic addition or deletion of SOA records. > > Arbitrary? As the author, let me just say, it's not > there arbitrarily. Anyone who disagrees with that needs to go back and read the list archives. It's not arbitrary. We all discussed this before. It's just not useful in the context of a master; the protection is a bit over the top, if your updater has already got a security relationship in place with the master. For a slave, it's a real problem, since there is not a preexisting security relationship that can be used as a lever, without adding more complex transactions or assumptions about the master/slave relationship. Creating zones in a slave is a much harder proposition, and the current restriction makes this not a problem. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 8 08:43:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28604 for ; Tue, 8 Aug 2000 01:46:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13LviY-000CE3-00 for namedroppers-data@psg.com; Mon, 07 Aug 2000 15:49:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13LviX-000CDx-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 15:49:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13LviX-0008Eo-00 for namedroppers@ops.ietf.org; Mon, 07 Aug 2000 15:49:57 -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: namedroppers@internic.net Subject: Re: zones w/ downs syndrom In-Reply-To: Your message of "Mon, 07 Aug 2000 11:08:55 MST." <200008071808.LAA05935@gulag.araneus.fi> Date: Tue, 08 Aug 2000 08:48:32 +1000 Message-Id: <114.965688512@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 7 Aug 2000 11:08:55 -0700 (PDT) From: gson@nominum.com (Andreas Gustafsson) Message-ID: <200008071808.LAA05935@gulag.araneus.fi> | I find zones with only a SOA record to be both harmless and quite | useful when setting up new zones by means of dynamic update: a zone | consisting of only the SOA is first created in the master server using | an out-of-band mechanism, and then all the remaining zone data | including the NS records are added using the standard dynamic update | protocol. To me, as an operational issue, that just makes no sense. Is the zone with an SOA record installed on some server or not (when it is first created)? If it is, then how much more difficult can it possibly be to create the "null" zone with both the SOA and NS record, instead of with just the SOA record ? On the other hand, if the zone isn't going to be loaded into any server at all, then I don't really care what records it has in it, for all practical purposes it simply doesn't exist. kre ps: I am deliberately making no comment on the issues of whether IXFR ought to be able to deal with a "zone" that contains no more than an SOA record, nor whether or not it really should be possible to use dynamic update to add the SOA record to a zone. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 8 18:53:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09681 for ; Tue, 8 Aug 2000 18:53:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13MHLa-0000KO-00 for namedroppers-data@psg.com; Tue, 08 Aug 2000 14:55:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13MHLZ-0000KI-00 for namedroppers@ops.ietf.org; Tue, 08 Aug 2000 14:55:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13MHLZ-000GlO-00 for namedroppers@ops.ietf.org; Tue, 08 Aug 2000 14:55:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399079BD.176658F7@whistle.com> Date: Tue, 08 Aug 2000 14:21:01 -0700 From: Terry Lambert To: Kevin Darcy CC: namedroppers@internic.net Subject: Re: zones w/ downs syndrom References: <200008072244.PAA17815@redpaul.mibh.net> <398F55B4.C39F4FB5@whistle.com> <398F85D3.A63C0876@daimlerchrysler.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy wrote: > Terry, > I don't see that every new feature of DNS needs > to enhance security. Me neither; however, I do see that it needs to not damage it. Don't get me wrong. I am the person who brought this up as an issue for me, since I didn't like having an out-of-band interface to support. > The point of allowing dynamic zone creation is not to > enhance security, but to provide convenience and productivity > for administrators. It is sufficient, is it not? that it not > *harm* security. I don't see that it does. The problem is the creation of zones in slaves. The main arguments are that this is an operational issue, since the creation of zones over the wire is not specified as part of the protocol; my argument in the original discussions was that _it should be_, and that _the purpose of the wire protocol is to do all operations which can be dones to a DNS server_. This makes it a protocol, not an operational issue. The problem with slaves is that you would permit arbitrary data to be enteres into slaves by outside parties by doing poisining or spoofing of masters, either of which is unacceptable. > The security of the Dynamic Updates themselves is, we > agree, not the issue, and as for the security of > initiating master/slave relationships, people can just > keep on using the same presumably-secure out-of-band > mechanisms for this as they are using today -- the fact > that the zone was created dynamically doesn't impact this > much one way or the other. What *new* security challenge > does dynamic zone-creation raise? Primarily, the problem is that the OOB mechanism exists now. People just don't like it, because it doesn't use the DNS protocol. > P.S. Of course I have searched the archives for these > alleged discussions, every which way I could think of. > They seem to be missing from the archives, or at least > are very well hidden. Pointers or suggestions as to > their whereabouts would be greatly appreciated. The current mailing list is "namedroppers@internic.net", which is the old address. You should look in the archives of the current list, which is actually named "namedroppers@ops.ietf.org", so you are probably looking at the wrong archives (which also explains why this thread is not being filtered to the correct mailbox by my MUA). -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 8 21:04:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13559 for ; Tue, 8 Aug 2000 21:04:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13MJqg-0002B8-00 for namedroppers-data@psg.com; Tue, 08 Aug 2000 17:35:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13MJqg-0002B2-00 for namedroppers@ops.ietf.org; Tue, 08 Aug 2000 17:35:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13MJqf-000Hpr-00 for namedroppers@ops.ietf.org; Tue, 08 Aug 2000 17:35:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3990A6FA.B6AF3A8F@daimlerchrysler.com> Date: Tue, 08 Aug 2000 20:34:02 -0400 From: Kevin Darcy To: namedroppers@internic.net Subject: Re: zones w/ downs syndrom References: <200008072244.PAA17815@redpaul.mibh.net> <398F55B4.C39F4FB5@whistle.com> <398F85D3.A63C0876@daimlerchrysler.com> <399079BD.176658F7@whistle.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Terry Lambert wrote: > Kevin Darcy wrote: > > Terry, > > I don't see that every new feature of DNS needs > > to enhance security. > > Me neither; however, I do see that it needs to not damage it. > > Don't get me wrong. I am the person who brought this up as > an issue for me, since I didn't like having an out-of-band > interface to support. > > > The point of allowing dynamic zone creation is not to > > enhance security, but to provide convenience and productivity > > for administrators. It is sufficient, is it not? that it not > > *harm* security. I don't see that it does. > > The problem is the creation of zones in slaves. > > The main arguments are that this is an operational issue, > since the creation of zones over the wire is not specified > as part of the protocol; my argument in the original > discussions was that _it should be_, and that _the purpose > of the wire protocol is to do all operations which can be > dones to a DNS server_. This makes it a protocol, not an > operational issue. I'd love to see a protocol for DNS server configuration as well, and obviously I'd want it to be secure. But are there any drafts, any designs, any prototypes for such a thing? Allowing dynamic zone creation on masters is something that pays off in the near term. I don't see why a concrete near-term gain should be held hostage to a mere idea or a promise of better things to come. > The problem with slaves is that you would permit arbitrary > data to be enteres into slaves by outside parties by doing > poisining or spoofing of masters, either of which is > unacceptable. Yes, this is a design challenge of the new protocol. Obviously a way would need to be found to prevent abuses. > > The security of the Dynamic Updates themselves is, we > > agree, not the issue, and as for the security of > > initiating master/slave relationships, people can just > > keep on using the same presumably-secure out-of-band > > mechanisms for this as they are using today -- the fact > > that the zone was created dynamically doesn't impact this > > much one way or the other. What *new* security challenge > > does dynamic zone-creation raise? > > Primarily, the problem is that the OOB mechanism exists > now. People just don't like it, because it doesn't use > the DNS protocol. Well, actually, my slaves *do* use the DNS protocol to determine what zones to start slaving or stop slaving: every night they treewalk-query their way through our internal-root namespace, checking delegations. So, technically, I'm not even using an OOB mechanism, yet my slaves always slave the zones I want them to. Perhaps then you can appreciate why your angst about OOB mechanisms doesn't carry much weight with me. The lack of dynamic zone creation is a *much* bigger deal in my particular neck of the woods. I want to move *all* zone maintenance to secured Dynamic Update, but there's this annoying little SOA exception... Even in environments where the tree-walking part of the above approach is not practical, e.g. in exceptionally large namespaces like the Internet DNS, I expect one could use the receipt of a new SOA NOTIFY to trigger a delegation-check and possible subsequent slave zone creation. For added security, change the NOTIFY spec to allow them to be signed -- only a minor extension and probably overdue anyway. > > P.S. Of course I have searched the archives for these > > alleged discussions, every which way I could think of. > > They seem to be missing from the archives, or at least > > are very well hidden. Pointers or suggestions as to > > their whereabouts would be greatly appreciated. > > The current mailing list is "namedroppers@internic.net", > which is the old address. You should look in the > archives of the current list, which is actually named > "namedroppers@ops.ietf.org", so you are probably looking > at the wrong archives (which also explains why this > thread is not being filtered to the correct mailbox by > my MUA). Those are list, i.e. mail addresses, but according to http://www.ietf.org/html.charters/dnsext-charter.html , the archive location for the WG is ftp://ops.ietf.org/pub/lists. From that source, I've been able to download namedroppers archives stretching more-or-less continuously from the present day back to the 80's, yet I can't find the discussions to which you refer using any of the search terms I've tried -- many of them. I also checked the dnssec archives: no success. Any other ideas? -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 Aug 12 14:58:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05007 for ; Sat, 12 Aug 2000 14:58:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13MaEK-000C9H-00 for namedroppers-data@psg.com; Wed, 09 Aug 2000 11:05:28 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13MaEK-000C9B-00 for namedroppers@ops.ietf.org; Wed, 09 Aug 2000 11:05:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13MaEK-000PNW-00 for namedroppers@ops.ietf.org; Wed, 09 Aug 2000 11:05:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Bernard Aboba" To: Subject: Comments on draft-aboba-dnsext-mdns-01.txt? Date: Wed, 9 Aug 2000 11:04:39 -0700 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a request for feedback on draft-aboba-dnsext-mdns-01.txt. Please post comments to the list and/or the authors. Ideally we would like to get a revised version of the draft out by the first week of September. The revised version will be renamed as a WG draft, as decided at IETF 48. Since this is an early draft there are probably a lot of things to be fixed and improved. To speed that process along, if you have specific text you'd like to change, it would be helpful if you could include the suggested replacement text with your comment so that we can incorporate your changes quickly. All suggestions/comments will be acknowledged in the acknowledgments section. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 12 16:03:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05594 for ; Sat, 12 Aug 2000 16:03:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Nh1O-000AVD-00 for namedroppers-data@psg.com; Sat, 12 Aug 2000 12:32:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Nh1N-000AV7-00 for namedroppers@ops.ietf.org; Sat, 12 Aug 2000 12:32:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Nh1N-000Cob-00 for namedroppers@ops.ietf.org; Sat, 12 Aug 2000 12:32:41 -0700 Message-Id: <4.3.2.7.2.20000809161021.00cfc570@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Aug 2000 16:13:02 -0400 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Draft minutes of DNSEXT @ IETF48 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 3 August 2000, DNSEXT WG Meeting run by chairs Olafur Gudmundsson and Randy Bush Minutes by Donald Eastlake and Mark Kosters (thanks to both of you) Edited by Olafur Gudmundsson. Agenda Bashing: three additions, Levon Esibov on A6 dynamic update problem, David Conrad on "Got DNSSEC?", Donald Eastlake on RSA-SHA1. WG Status was given by Olafur Gudmundsson (OG): RFC 2845 "Secret Key Transaction Authentication for DNS (TSIG)" is out. The IANA DNS, TKEY, and Secure Update drafts have all three been approved and should be out as RFCs in not too long. Secure Update and Signing Authority are at IESG, minor text needed to added to Secure Update. APL is pending Area Director action to bring to IESG. The IXFR draft is in WG last call. RFC status: a list of all the RFC's within the WG's charter area was given with their status. New Items: standards track For advancement to Draft Standard SRV Interoperation testing needed Notify needs minor technical changes IXFR interoperation testing needed Neg Caching interoperation report needed Advance AXFR clarify & Msg Size to Proposed Standard Next Items retire SNMP RFC's to historic: Rob Austein to write up continue clarify and simplify off DNSSEC. Advance other lower priority items A few new items New Items Message Size document by Olafur Gudmundsson GSS API Stewart Kwan DNSSEC awareness ENDS option David Conrad EDNS0.5 (Austein & Alvestrand) DNS Server expectation & clarification document: Michael Patton DNS Resolver expectation & clarification document: (needs author, contact Olafur) Knocking on the door DNSSEC Roadmap Glen Rose NO Record (NXT replacement) Multicast DNS New Charter Items Multicast DNS local link scope and/or enterprise wide IDN - being handled in a separate WG, but DNSEXT will handle all DNS protocol changes. Possibilities include: new label types EDNS flags, EDNS options New record types Chair has dropped hints in IDN working group, that teams creating new solutions SHOULD use EDNS and leave DNS header alone. Bill Manning: IETF 48 Interoperabilty Notes (Slides) Cisco, CheckPoint, Lucent, Microsoft, Nominum, NAI Labs, hosted by ISI Items to test: NCACHE & SRV have test suites All other testing was ad-hoc NCACHE - three interoperable versions and may proceed to Draft Standard pending some clarification All SRV implementations passed XFR, RELOAD, and compression Ad-hoc testing EDNS0 worked between two implementations in one direction SIG/KEY/NXT would pass between all implementations but did not share assumptions Two parties tested some TSIG with limited success Three implementations have working client & server code for IXFR We should (1) construct an online testbed, (2) formulate standardized test suites, and (3) have scheduled testing sessions people interested in testing implementations should subscribe to the testing mailing list dns-dynupd-testing@lists.tislabs.com IXFR Last Call Bill Manning: some implementor concerns, to be provided in last call period AXFR Clarify Andreas Gustafsson: (01 draft posted to mailing list because it didn't make it out before the IETF meeting) Draft version 00 provides the long missing specification of AXFR. For example, multiple answer records are permitted, specifies header fields of multiple messages, specifies when a question section is required, states that AXFR begins and ends with just SOA not all apex data. 01 adds security considerations section and definition of glue. Purpose of AXFR is to copy zone including necessary and unnecessary glue as originally loaded from master file. This requires servers to store zones in separate structures so glue in one zone can be distinguished from authoritative data in other zones. (This has actually always been required.) It was noted by observation that one implementation of AXFR advertised its ability to accept multiple answers by appending the two ASCII characters "MS" to the end of its AXFR query. EDNS0.5 Harald Alvestrand (HA): "To Make sure that IDN and other rabid adders of DNS features can get what they want done without damaging the stability of the Internet". Some discussion if this should be renumbered to be EDNS1 rather than ENDS0.5 no consensus. Question on what features should be enumerated, answer was only the ones t added since 1034/1035, and features that might be obsoleted or replaced. Message Size Olafur Gudmundsson: Current DNS restricts UDP answers to 512 bytes, DNSSEC & A6 answers are bigger and frequently need more space resulting in unnecessary TCP transfers, etc. EDNS0 provides a way to indicate readiness to receive a bigger answer. This draft says that if you support DNSSEC or A6 your MUST support EDNS0. Minimum EDNS0 indicated MTU in draft is set at 1280 bytes. Next version will have 1220 or 1240 (IPv6 MTU is 1280 bytes and you need to subtract the UDP header size.) Will revise draft based on comments. Number people voiced opinions on the size, IPv6 people argue for 1024 to avoid fragmentation, DNS people argue for large number to maintain number of nameservers high. Kazu Yamamoto (KY): EDNS0 is needed for IPv6. 512 bytes is too small. The root zone needs NS RRs +A/AAAA/A6 "glue". AAAA/A6 only meaningful for IPv6 transport ready resolvers Mandate EDNS0 for IPv6. No objections to this idea at IPng WG yesterday. This should be put in the IPv6 host requirements. Olafur and Kazu to bring issue on how to address IPv6 requirements up on the IPng mailing list. Masataka Ohta (MO):Number of root servers is a DNSOP matter. Anycast is the answer. Five roots is enough using Anycast. Bill Manning (BM) wants to see the calculations of packet size. GSS TSIG (slides) Levon Esibov (LE): draft-dnsext-gss-tsig-00.txt Original draft submitted three years ago. Authentication between clients and servers as well as between servers. Generate shared secret key using TKEY & GSSAPI. Then authenticate using TSIG & GSSAPI. Draft does NOT cover authorization of DNS requests. GSS-TSIG developer need not develop a security infrastructure, just piggy backs on GSSAPI infrastructure. Security mechanism independence since its accessed via GSSAPI. (diagram) Some questions about performance implications and delays using this, compared to MD5 TSIG, no answers available at this time. Olafur mentioned that two other people are implementing this, in addition to MS, and this document will not leave WG until there are interoperable implementations. Clarification on Zone Status Ed Lewis (EL): Motivation is that RFC 2535 talks about securing a resolver, not about how a server secures itself. The server point of view is not given. If a server uses an obscure algorithm, it has done a bad thing in terms of getting its data securely into the hands of most resolvers. And administrator can leave a zone secured, can secure it as part of the secure DNS tree, or secure it and still not be part of the tree, depending on algorithm used, parental vouching, etc. Changes this draft makes to RFC 2535: (1) Definition if a zone is secured or not secured. RFC 2535 says per algorithm. Changed to per zone. (2) Protocol octet in KEY has to be DNSSEC or ANY. RFC 2535 permits it to be zero in a KEY used for DNSSEC. (3) Dropping the "experimentally secure" status. If desired, it can be achieved in other ways, such as limited public key distribution. An important point of this draft is to define "fully secured" and "privately secured". Probably "Fully" secured should be "Globally" and "Privately" should be "Locally". To be globally secure, it is required that your parent says you are secure. (If your parent isn't secure, then you have to give everyone who will trust you your public key in some secure fashion they will trust.) This draft depends on the Signing Authority draft. Gone from earlier versions of this draft is the NXT hack. That would have gotten rid of NULL keys. But operators indicate that these do not seem to actually be a problem. Draft needs a further revision of the English, due to misunderstandings but non English readers. Draft will go for WG Last Call after these revisions. DHCID: DHCP needs a semaphore RR... Want their own RR so DHCP servers can mark names so others will know who set them. They have tried to specify using TXT, SIG, and KEY to store the data they want in the DNS but those are misuses of RRs intended for other purposes. Lively discussion about the need for this and why DHCP people want this. The final consensus was that this is not a good idea but if DHCP wants to store some information to arbitrate between servers and/or clients this is harmless from DNS perspective. NXT RR -> NO Record Simon Josefson (not here) (Olafur gave a summary) Uses hashes of names. List of integers instead of bit map. Discussion to the list. Question if this is extra work for WG and if it should be allowed in Olafur: This can fit under the fixing of DNSSEC umbrella which is on the charter. Admit document as WG document, DNSSEC Roadmap Scott Rose Purpose of the document is to help inform people about what it's all about and where it is. Similar to IPSEC Roadmap. First part lists documents and what they cover. Second part tries to give a unified overview of what it all means. Document will have to be frequently revised and should stay as a draft for some time. Perhaps become an Informational RFC at some point. Might be extended to include all the DNS extensions... Chairs: take it on, it's useful, keep it small and restrict to DNSSEC only (including TKEY and TSIG). Multicast DNS (MDNS), draft-aboba-dnsext-mdns-01.txt Levon Esibov (LE). Some requirements come out of zeroconf. Will talk about what the draft isn't. Goals: resolve when no DNS server or no DNS server that hosts all the local names. Not service location. Not a substitute for dynamic DNS. Not for use on global Internet or in Enterprise nets. For home/ad-hoc networks and the like. Query under lcl.arpa to link-local scope for IPv4 or IPv6. Number of comments, replace lcl.arpa with local.arpa. Stewart Cheshire of Apple has reserved an multicast Address for this purpose, question if zeroconf people are happy with link local only scope? Anycast DNS, draft-manning-dnsext-mdns-06.txt Bill x: Draft has been cut down to three pages. Study shows that traffic impact is not a problem. Comment that this is a problem in global networks with slow links, as scope off local is not restricted by many organizations. Number of questions on why an organization would want to do this as if it has infrastructure it most likely has DNS servers configured. Add Multicast DNS to WG items ? (Olafur) Comments included "Against taking this on because we get rat holed on multicast issues, not DNS.", "limit to link local", consensus was to accept both at this point for future work and be careful how these proposals grow. A6 Dynamic update problem: (Levon) Need technique for clients to find out prefix info for non-zero prefixes for A6 updates. No standardized way to find this out. Matt Crawford will take this issue up with IPNG wg. David Conrad, Got DNSSEC? Non-DNSSEC aware client can't say it doesn't want DNSSEC additional RRs including SIG and spontaneous KEYs. So server will always send big packets which may result in unnecessary truncation and TCP transfers. Solutions: Everyone does ENDS0. Client can indicate it doesn't want DNSSEC. Forget DNSSEC? BIND v9 uses the AD bit in the query for this purpose. Pro: Does not require EDNS0, really simple. Con: Uses a scarce bit, doesn't promote EDNS0 Con: May screw up caches/forwarders Use a bit in the EDNS0 header Pro: Doesn't use a scare bit, simple, encourage EDNS0 Con: Disadvantage of requiring EDNS0 Use EDNS0.5 Pro: Doesn't use a scarce bit, encourages EDNS0, finer grained Con: Requires EDNS0 New Denial of Service Bad guy spoofs a response indicating the server does not support DNSSEC?? What to do? It is late to make much change in BIND v9.0.0 Consensus was to add this to the working group tasks. Donald Eastlake, RSA-SHA1. If you are using RSA, most of the data in the DNS is probably adequately protected by the RSA-MD5 of algorithm 1 specified in RFC 2537. But MD5 is showing its age and the most sensitive root/TLD/etc. data deserves the protection of SHA1 and any better padding techniques that have been deployed for a while. The additional computation for SHA1 versus MD5, etc., is trivial compared with the main RSA modular exponentiation. Mark Andrews and others: Not only should RSA-SHA1 be added, it should be MANDATORY to implement, and RSA-MD5 should be obsoleted. RSA SHA1 draft (to be submitted by Donald Eastlake) approved as a work item. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 12 16:05:40 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05614 for ; Sat, 12 Aug 2000 16:05:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Nh1J-000AUz-00 for namedroppers-data@psg.com; Sat, 12 Aug 2000 12:32:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Nh1I-000AUt-00 for namedroppers@ops.ietf.org; Sat, 12 Aug 2000 12:32:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Nh1I-000CoL-00 for namedroppers@ops.ietf.org; Sat, 12 Aug 2000 12:32:36 -0700 Message-Id: <4.3.2.7.2.20000803144629.00d147a0@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Aug 2000 14:59:21 -0400 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: WG Last Call: RFC2137 to Historic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As we have a new specification that obsoletes RFC2137 (Secure Dynamic Update). This last call is to solicit opinion of the WG if RFC2137 status should be changed from "Obsoleted by RFC2xxx" to "Historic". The reason for doing this is to make it real clear to anyone that RFC2137 is NOT to be implemented. This WG last call ends on August 25'th. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 12 18:55:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06723 for ; Sat, 12 Aug 2000 18:55:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Njk4-000E5l-00 for namedroppers-data@psg.com; Sat, 12 Aug 2000 15:27:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Njk4-000E5f-00 for namedroppers@ops.ietf.org; Sat, 12 Aug 2000 15:27:00 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Njk4-000GPV-00 for namedroppers@ops.ietf.org; Sat, 12 Aug 2000 15:27:00 -0700 From: "Bernard Aboba" To: Subject: Comments on draft-aboba-dnsext-mdns-01.txt? Date: Thu, 10 Aug 2000 10:02:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a request for feedback on draft-aboba-dnsext-mdns-01.txt. Please post comments to the list and/or the authors. Ideally we would like to get a revised version of the draft out by the first week of September. The revised version will be renamed as a WG draft, as decided at IETF 48. Since this is an early draft there are probably a lot of things to be fixed and improved. To speed that process along, if you have specific text you'd like to change, it would be helpful if you could include the suggested replacement text with your comment so that we can incorporate your changes quickly. All suggestions/comments will be acknowledged in the acknowledgments section. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 14 10:12:00 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09142 for ; Mon, 14 Aug 2000 10:11:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13OKEm-0003aN-00 for namedroppers-data@psg.com; Mon, 14 Aug 2000 06:25:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13OKEm-0003aH-00 for namedroppers@ops.ietf.org; Mon, 14 Aug 2000 06:25:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13OKEl-000MYR-00 for namedroppers@ops.ietf.org; Mon, 14 Aug 2000 06:25:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008140647.e7E6lA402820@valinor.malmo.trab.se> Date: Mon, 14 Aug 2000 08:47:10 +0200 (MEST) From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: Flagging non-ASCII in domain names To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To be able to support non-ASCII in domain names in a non-disruptive way, the DNS server need to identify if a query is from the "old world" assuming ASCII only or the "new world" that can handle non-ASCII. Some think that EDNS is the way to do it, but that has one major difficulty: a very big overhead! The "old world" servers will return a failure when queried using EDNS resulting in the client to have to retry the query without EDNS. And the client have to use EDNS in every query, so this overhead will occur for every query. The overhead can be reduced somewhat by using recusive queries and having servers caching that state on other servers, but we can still expect a lot of extra traffic. In my draft I have several possibilities (ordered from best to worst): 1) The best way is to use the last unused flag bit in the header. 2) Another way is to use one of the flags bits that only have a meaning in a response (in the old world). Like the RA, AA or TC bit. 3) Using the RCODE bits (they are only used in responses in the old world). 4) Using parts of QTYPE or EDNS. (will give error responses from old world). The need to handle non-ASCII has existed since DNS was introduced and it is very important for a lot of people. It must be possible to use immediately without any large overhead compared to using ASCII only. While DNSSEC will take many years before it really is used, using non-ASCII in domain names will take off immedately (and is already being tried live in DNS). Therefore I do not think 4) above is no acceptible due to the overhead. What do you think? I have included some more comments about the above possibilities in my draft: draft-ietf-idn-udns-00.txt Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 14 13:54:01 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16035 for ; Mon, 14 Aug 2000 13:54:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13ONoc-0005nW-00 for namedroppers-data@psg.com; Mon, 14 Aug 2000 10:14:22 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13ONoc-0005nQ-00 for namedroppers@ops.ietf.org; Mon, 14 Aug 2000 10:14:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13ONoc-000OSQ-00 for namedroppers@ops.ietf.org; Mon, 14 Aug 2000 10:14:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Barr Hibbs" To: "DNSEXT WG Mailing list" Subject: RE: WG Last Call: RFC2137 to Historic Date: Mon, 14 Aug 2000 10:13:59 -0700 Message-ID: In-Reply-To: <4.3.2.7.2.20000803144629.00d147a0@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > Sent: Wednesday, August 09, 2000 11:59 AM > > This last call is to solicit opinion of the WG if RFC2137 status > should be changed from "Obsoleted by RFC2xxx" to "Historic". > > The reason for doing this is to make it real clear to anyone that RFC2137 > is NOT to be implemented. ...no disagreement with the change, but... [I almost hate to ask this!] human nature being what it is, will the designation as "Historic" actually dissuade anyone from implementing? After all, if the status is now Historic, then it must have once been valid, and thus implementations based on 2137 "ought to be" upward compatible with its successors.... Is there any standardized text that could be added to the introduction which would make clear that 2137 is not to be implemented? --Barr Hibbs UltraDNS Corp. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 14 15:32:01 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17700 for ; Mon, 14 Aug 2000 15:32:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13OP6x-0006Sl-00 for namedroppers-data@psg.com; Mon, 14 Aug 2000 11:37:23 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13OP6w-0006Sf-00 for namedroppers@ops.ietf.org; Mon, 14 Aug 2000 11:37:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13OP6w-000P2g-00 for namedroppers@ops.ietf.org; Mon, 14 Aug 2000 11:37:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008141825.OAA28262@torque.pothole.com> To: "DNSEXT WG Mailing list" Subject: Re: WG Last Call: RFC2137 to Historic In-reply-to: Your message of "Mon, 14 Aug 2000 10:13:59 PDT." Date: Mon, 14 Aug 2000 14:25:54 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since I'm not aware of any successful implementation of RFC2137, I'm not sure that it matters one way or the other. Donald From: "Barr Hibbs" To: "DNSEXT WG Mailing list" Date: Mon, 14 Aug 2000 10:13:59 -0700 Message-ID: In-Reply-To: <4.3.2.7.2.20000803144629.00d147a0@localhost> >> -----Original Message----- >> From: owner-namedroppers@ops.ietf.org >> Sent: Wednesday, August 09, 2000 11:59 AM >> >> This last call is to solicit opinion of the WG if RFC2137 status >> should be changed from "Obsoleted by RFC2xxx" to "Historic". >> >> The reason for doing this is to make it real clear to anyone that RFC2137 >> is NOT to be implemented. > >...no disagreement with the change, but... [I almost hate to ask this!] >human nature being what it is, will the designation as "Historic" actually >dissuade anyone from implementing? After all, if the status is now >Historic, then it must have once been valid, and thus implementations based >on 2137 "ought to be" upward compatible with its successors.... > >Is there any standardized text that could be added to the introduction which >would make clear that 2137 is not to be implemented? > >--Barr Hibbs > UltraDNS Corp. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 15 20:08:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00969 for ; Tue, 15 Aug 2000 20:08:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Opva-000IAN-00 for namedroppers-data@psg.com; Tue, 15 Aug 2000 16:15:26 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13OpvZ-000IAH-00 for namedroppers@ops.ietf.org; Tue, 15 Aug 2000 16:15:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13OpvZ-000A5y-00 for namedroppers@ops.ietf.org; Tue, 15 Aug 2000 16:15:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 15 Aug 2000 19:12:46 -0400 From: "Nicolae, Dan" Subject: Multicast DNS clarification needed To: namedroppers@ops.ietf.org Message-id: <3654E69400ADD211A3A400805FA7CE24022A6300@USA0111MS2> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit First of all, before commenting over the MDNS drafts draft it would be good to know if draft-aboba-dnsext-mdns-01.txt and Bill Manning's draft, both with similar names, are being seen as competing specifications or they are supposed to coexist. I am assuming here that, despite the identical name, the two drafts complement each other and commenting on one involves keeping the other in mind. I remember seeing remark about the practical impossibility to have two separate processes listening on the same IP port but different IP addresses (unicast and multicast). I am not sure how true that is, but if it is, it is important to consider it when talking about three mechanisms (DNS and two MDNS) that plan to share the same port (53). This issue was mentioned in the SSDP draft (now defunct). Here is the relevant paragraph: " 8.3.2. Why does SSDP need to use a port other than 80? The result is that if we used port 80 on the SSDP multicast scope then we would require that the SSDP software also grab port 80 for the local machine. This would mean that SSDP could only be implemented on machines which either didn't have HTTP servers or whose HTTP servers had been enhanced to support SSDP. We felt this was a unnecessary restriction. Therefore we are choosing to use a port other than 80 on the SSDP multicast channel. " Assuming that all three DNS protocols may have to be implemented in a single process, and the DNS server behavior is dependent on what IP address a DNS packet is received from (unicast or the two multicast groups), I see potential implementation problems. I hope some sockets gurus will pick this one up and validate it for various flavors of OSes and sockets. Then we'll know if the two drafts can be treated separately or all three (add standard DNS) must be judged together from a single process perspective. Thanks, /dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Aug 15 21:29:06 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02400 for ; Tue, 15 Aug 2000 21:29:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13OrOg-000IrP-00 for namedroppers-data@psg.com; Tue, 15 Aug 2000 17:49:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13OrOf-000IrJ-00 for namedroppers@ops.ietf.org; Tue, 15 Aug 2000 17:49:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13OrOf-000AeM-00 for namedroppers@ops.ietf.org; Tue, 15 Aug 2000 17:49:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Nicolae, Dan" Cc: namedroppers@ops.ietf.org Subject: Re: Multicast DNS clarification needed References: <3654E69400ADD211A3A400805FA7CE24022A6300@USA0111MS2> Message-Id: Date: Tue, 15 Aug 2000 17:44:04 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit it is possibly relevant that the iesg asked the dnsext wg for help with the link local autoconf issue. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 16 02:10:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19349 for ; Wed, 16 Aug 2000 02:10:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Ovb8-000Kcb-00 for namedroppers-data@psg.com; Tue, 15 Aug 2000 22:18:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Ovb8-000KcV-00 for namedroppers@ops.ietf.org; Tue, 15 Aug 2000 22:18:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Ovb8-000C44-00 for namedroppers@ops.ietf.org; Tue, 15 Aug 2000 22:18:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <399A23A3.4ECA560D@nominum.com> Date: Tue, 15 Aug 2000 22:16:19 -0700 From: "David R. Conrad" To: Dan Oscarsson Cc: namedroppers@ops.ietf.org Subject: Re: Flagging non-ASCII in domain names References: <200008140647.e7E6lA402820@valinor.malmo.trab.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan, > Some think that EDNS is the way to do it, but that has one major > difficulty: a very big overhead! Yes, but... So far, the IPNG and DNSEXT working groups look like they'll be making the use of EDNS mandatory for IPv6 and DNSSEC (respectively). As such, it would appear that in order to work and play well in the future support for EDNS is necessary. > The "old world" servers will > return a failure when queried using EDNS resulting in the client > to have to retry the query without EDNS. As I believe I mentioned previously, the only EDNS-using resolver that I'm aware of (the one in BINDv9) maintains state about the servers that it has talked to regarding that server's support for EDNS. That implementation is openly available with a BSD-like license encouraging use / modification / copying / etc. with essentially no restriction. Assuming history repeats itself and the Unix vendors (who in part paid for the development of BINDv9) ship BIND as their default name server and that the folks at Microsoft implement similar state-keeping, it is likely that the number of retransmits due to lack of EDNS support will be minimized. > The need to handle non-ASCII has existed since DNS was introduced and > it is very important for a lot of people. It must be possible to use > immediately without any large overhead compared to using ASCII only. Well, as per the spec, the BINDv9 client tries EDNS0 requests first, then falls back to non-EDNS0 if it receives a FORMERR (or lack of response), so for those that use BINDv9 or other EDNS supporting clients, using a server that does not support EDNS will result in worse overhead than using a server that does support EDNS. Rgds, -drc to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 16 10:35:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26163 for ; Wed, 16 Aug 2000 10:35:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13P3bj-000NhA-00 for namedroppers-data@psg.com; Wed, 16 Aug 2000 06:51:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13P3bi-000Nh3-00 for namedroppers@ops.ietf.org; Wed, 16 Aug 2000 06:51:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13P3bi-000Efi-00 for namedroppers@ops.ietf.org; Wed, 16 Aug 2000 06:51:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Nicolae, Dan" cc: namedroppers@ops.ietf.org In-reply-to: Dan.Nicolae's message of Tue, 15 Aug 2000 19:12:46 -0400. <3654E69400ADD211A3A400805FA7CE24022A6300@USA0111MS2> Subject: Re: Multicast DNS clarification needed From: itojun@iijlab.net Date: Wed, 16 Aug 2000 17:16:23 +0900 Message-ID: <23728.966413783@coconut.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >First of all, before commenting over the MDNS drafts draft it would be good >to know if draft-aboba-dnsext-mdns-01.txt and Bill Manning's draft, both >with similar names, are being seen as competing specifications or they are >supposed to coexist. > >I am assuming here that, despite the identical name, the two drafts >complement each other and commenting on one involves keeping the other in >mind. > > >I remember seeing remark about the practical impossibility to have two >separate processes listening on the same IP port but different IP addresses >(unicast and multicast). I am not sure how true that is, but if it is, it is >important to consider it when talking about three mechanisms (DNS and two >MDNS) that plan to share the same port (53). I'm not sure if it is at all relevant to the topic... We (KAME team, www.kame.net) have fairly stable aboba-mDNS implementation, based on 00 draft. Our implementation works as a tiny DNS server daemon. application programs will contact the mDNS daemon using unicast UDP, and the mDNS server daemon relays it to link-local multicast on the wire, and that would reach the adjacent node. We only have single daemon listening to UDP port 53 (which is mDNS daemon). if it is necessary for mDNS daemon to contact normal unicast DNS servers, it can also relay traffic to normal DNS servers using unicast UDP. application programs libc resolver | unicast UDP port 53 v unicast mDNS daemon -----------------------------> normal DNS servers | multicast, UDP port 53 v mDNS daemon on adjacent node as aboba-mDNS is a zeroconf solution, I do not really expect to run aboba-mDNS daemon on the same machine as we run normal DNS server. i'm not sure if the above example is relevant to manning-mDNS at all. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 16 12:46:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29857 for ; Wed, 16 Aug 2000 12:46:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13P5gL-000OuQ-00 for namedroppers-data@psg.com; Wed, 16 Aug 2000 09:04:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13P5gL-000OuK-00 for namedroppers@ops.ietf.org; Wed, 16 Aug 2000 09:04:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13P5gL-000Fd2-00 for namedroppers@ops.ietf.org; Wed, 16 Aug 2000 09:04:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008161554.LAA15783@ludwigia.raleigh.ibm.com> To: namedroppers Subject: draft-ietf-dnsext-apl-rr-01.txt Date: Wed, 16 Aug 2000 11:54:44 -0400 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG discussed this ID recently and a meta issue was discussed that I think the WG should think about. In particular: > The specification of particular application scenarios is out of the > scope of this document. I.e, this ID defines an RR for which no usage has been specified, and for which in the future, multiple incompatable usages might be specified. It seems to me that the semantics of an RR should be well-defined and uniformly interpreted by clients. If they are not, one runs the risk that different clients will query for the same RR (but for different reasons) and get unexpected results. This is particularly true if two logically different uses make use of the same RR. An administrator might define RRs with one usage in mind, but those RRs are then also queried by other applications that interpret the meaning of that RR differently than intended by the owner. Wrong things can happen as a result. Thus, even in cases where the raw format of an RR might be correct for multiple different uses, it might be better to define multiple different RRs each having the same syntax, but (possibly) different semantics and (possibly) different uses. I note that semantics/usage of the Negation Flag is explicitely not defined in this document, so the RR seems underspecified. As an example, consider TXT records. You can put lots of things in them, but many consider it bad form to do so precisely because the TXT RR one gets back may have nothing to do with the usage the client is expecting. To summarize, I wonder if: 1) This document should be published at all, without a specific usage associated with it for the reasons discussed above. 2) Even if the document is published, making it a PS seems wrong, without a specific usage documented along with it that clearly defines the semantics and intended usage. What does the WG think about this? Minor comments: > 4. APL RDATA format > > The RDATA section consists of zero or more strings () of > the form Is the "string" description correct? The RDATA actually consists if fixed length fields such as a prefix, a bit, etc. > ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers. The IANA requests that all references to numbers be via: http://www.iana.org/numbers.html 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 Aug 18 15:11:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05274 for ; Fri, 18 Aug 2000 15:11:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Pqrb-000L6L-00 for namedroppers-data@psg.com; Fri, 18 Aug 2000 11:27:31 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Pqrb-000L6F-00 for namedroppers@ops.ietf.org; Fri, 18 Aug 2000 11:27:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Pqrb-0009G8-00 for namedroppers@ops.ietf.org; Fri, 18 Aug 2000 11:27:31 -0700 Message-Id: <200008181821.OAA04179@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-roadmap-00.txt Date: Fri, 18 Aug 2000 14:21:58 -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 Security Document Roadmap Author(s) : S. Rose Filename : draft-ietf-dnsext-dnssec-roadmap-00.txt Pages : 11 Date : 17-Aug-00 DNS Security (DNSSEC)technology is composed of extensions to the Domain Name System (DNS) protocol that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Several documents exist to describe these extensions and the implementation specific details regarding specific digital signing schemes. The interrelationship between these different documents is discussed here. A brief overview of what to find in which document and author guidelines for what to include in new DNS Security documents, or revisions to existing documents, is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-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-roadmap-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-roadmap-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: <20000817105126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-roadmap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-roadmap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000817105126.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 Aug 18 18:47:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09857 for ; Fri, 18 Aug 2000 18:47:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13PuVt-000N1F-00 for namedroppers-data@psg.com; Fri, 18 Aug 2000 15:21:21 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13PuVs-000N19-00 for namedroppers@ops.ietf.org; Fri, 18 Aug 2000 15:21:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13PuVs-000Adr-00 for namedroppers@ops.ietf.org; Fri, 18 Aug 2000 15:21:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39909B68.5B7CAE96@isi.edu> Date: Tue, 08 Aug 2000 19:44:40 -0400 From: bill To: Ted.Lindgreen@tednet.nl CC: Olafur Gudmundsson , Roy Arends , DNS Extensions WG Subject: Re: Is this a possible DoS scenario within DNSSEC ? References: <200007252222.AAA30381@open.nlnetlabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Lindgreen responds to Ogud: > > servers will increase significantly. And DNSSEC may not work well if > > resolvers are stuck behind a non DNSSEC capable forwarder. > > Absolutely, and the real lessons are therefore clear: > - Secure aware resolvers should not use non secure aware > caching servers as forwarder. So, how do secure aware resolvers identify a non-secure aware caching server? Once they can id the suspect cache how are they to "remember" that the cache is suspect? And perhaps more importantly, is this on a machine or zone basis? If per zone, then there is the temporal issue, i.e. when does the zone "flip" between secure and not and how does the caching server "keep" up? --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 20 12:01:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08691 for ; Sun, 20 Aug 2000 12:01:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13QWyz-000ARz-00 for namedroppers-data@psg.com; Sun, 20 Aug 2000 08:25:57 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13QWyy-000ARt-00 for namedroppers@ops.ietf.org; Sun, 20 Aug 2000 08:25:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13QWyy-000PBx-00 for namedroppers@ops.ietf.org; Sun, 20 Aug 2000 08:25:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008201042.e7KAgn114253@malmo.trab.se> Date: Sun, 20 Aug 2000 12:42:15 +0200 (MET DST) From: Dan Reply-To: Dan Subject: Re: Flagging non-ASCII in domain names To: David.Conrad@nominum.com Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So far, the IPNG and DNSEXT working groups look like they'll be making > the use of EDNS mandatory for IPv6 and DNSSEC (respectively). As such, > it would appear that in order to work and play well in the future > support for EDNS is necessary. Very good, when? If all TLD servers and most of the next level down can support EDNS by summer 2001, then I see no problems. Otherwise there will be because I expect non-ASCII domain names will be started to be used a lot by then. Long before DNSSEC will be used generally. > > > The "old world" servers will > > return a failure when queried using EDNS resulting in the client > > to have to retry the query without EDNS. > > As I believe I mentioned previously, the only EDNS-using resolver that > I'm aware of (the one in BINDv9) maintains state about the servers that > it has talked to regarding that server's support for EDNS. I can see that a DNS server can maintain state about it, but not client resolver libraries (except within one instance of a running software). So every client doing a lookup will start fresh without any state and will have the overhead. This can quite well be fixed, if you control the DNS server the client do recusive lookups through. In that case you can upgrade it to an EDNS aware server and the server can do the caching. If you cannot change the DNS server, you will have a big overhead. While things like DNSSEC would only need ENDS if DNSSEC was used, for non-ASCII names every query must use EDNS to flag that the client can handle non-ASCII. Does anyone have a feeling how quickly all TLD servers and most of the ones one level down will handle EDNS? If if will happen quickly, I see no problem in using ENDS. Does anybody have any comments on using the last free bit or using for example the AA bit as an incoming flag bit? Are there really any problems with this, or is it just that everybody want to go EDNS? Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Aug 20 21:26:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11928 for ; Sun, 20 Aug 2000 21:26:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Qfnx-000DWw-00 for namedroppers-data@psg.com; Sun, 20 Aug 2000 17:51:09 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Qfnw-000DWq-00 for namedroppers@ops.ietf.org; Sun, 20 Aug 2000 17:51:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Qfnw-0002Km-00 for namedroppers@ops.ietf.org; Sun, 20 Aug 2000 17:51:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200008201042.e7KAgn114253@malmo.trab.se> Date: Sun, 20 Aug 2000 18:36:49 -0400 To: Dan From: Edward Lewis Subject: Re: Flagging non-ASCII in domain names Cc: namedroppers@ops.ietf.org, lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 6:42 AM -0400 8/20/00, Dan wrote: >Does anybody have any comments on using the last free bit or using for example >the AA bit as an incoming flag bit? Are there really any problems with this, >or is it just that everybody want to go EDNS? If we are to do something in a short amount of time, we should do it in a way that is most amenable to being backed out. Therefore, I'd urge any work towards iDNS to make use of EDNS and not (re)use the bits of the aboriginal header. Also, EDNS is designed to allow enhancements to DNS, so it seems like extending towards iDNS would naturally use EDNS. >I can see that a DNS server can maintain state about it, but not client >resolver libraries (except within one instance of a running software). >So every client doing a lookup will start fresh without any state and >will have the overhead. This can quite well be fixed, if you control the >DNS server the client do[es] recusive lookups through. In that case you >can upgrade it to an EDNS aware server and the server can do the caching. >If you cannot change the DNS server, you will have a big overhead. A stub resolver does not necessarily have to contact one and only one recursive name server. If you are concerned that your organization's name server(s) are not iDNS aware, you can run your own non-authoritative server that is and use it to answer your own questions. However, you are out-of-luck if you have a device (e.g., a firewall) that prevents the transfer of DNS traffic between you and the Internet. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert 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 Sun Aug 20 23:49:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14863 for ; Sun, 20 Aug 2000 23:49:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Qi9k-000ERk-00 for namedroppers-data@psg.com; Sun, 20 Aug 2000 20:21:48 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Qi9k-000ERe-00 for namedroppers@ops.ietf.org; Sun, 20 Aug 2000 20:21:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Qi9j-00039k-00 for namedroppers@ops.ietf.org; Sun, 20 Aug 2000 20:21:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A09608.B84EA508@ehsco.com> Date: Sun, 20 Aug 2000 19:38:01 -0700 From: "Eric A. Hall" To: Edward Lewis CC: Dan , namedroppers@ops.ietf.org Subject: Re: Flagging non-ASCII in domain names References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > > At 6:42 AM -0400 8/20/00, Dan wrote: > >Does anybody have any comments on using the last free bit or using > >for example the AA bit as an incoming flag bit? Are there really any > >problems with this, or is it just that everybody want to go EDNS? > > If we are to do something in a short amount of time, we should do it > in a way that is most amenable to being backed out. Therefore, I'd > urge any work towards iDNS to make use of EDNS and not (re)use the > bits of the aboriginal header. One other possibility is using the bits from the length field of the domain name label data type. Currently the two defined uses of the first two bits from this field are 00 for data and 11 for compression. Neither 01 or 10 are used for anything to my knowledge. It may be workable to define one of those bit patterns so that they indicate some sort of international encoding. The upside to this approach is that it is pretty simple to code support for. The downside is that it would have to be a fixed character set, so it probably wouldn't be an exceptionally robust solution, but instead would be "less limited". If full encoding of double-byte data is required/desired, I would think EDNS would be the most viable option. -- 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 Mon Aug 21 03:15:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27964 for ; Mon, 21 Aug 2000 03:15:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13QlAy-000FSS-00 for namedroppers-data@psg.com; Sun, 20 Aug 2000 23:35:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13QlAx-000FSM-00 for namedroppers@ops.ietf.org; Sun, 20 Aug 2000 23:35:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13QlAx-0004K4-00 for namedroppers@ops.ietf.org; Sun, 20 Aug 2000 23:35:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008210633.e7L6XUX11856@valinor.malmo.trab.se> Date: Mon, 21 Aug 2000 08:33:30 +0200 (MEST) From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: Re: Flagging non-ASCII in domain names To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit kre@munnari.OZ.AU said: > | People have been worried that getting > | a host name containing non-ASCII will break some applications. > > It might. If that's going to be a problem, the place to fix it is > in the resolver interface, not in the server. The current versions of > BIND that do syntax checking on names coming back in the resolver before > handing them off to clients would simply make all such names vanish. > If someone absolutely needs this "protection" they should be doing it that > way. While some code today check it, I do not know how many do not. I know that some gethostbyaddr also do not return a host name if DNS returns one that contains non-ASCII. But this will also break some applications! For example, some e-mail servers do not accept incoming e-mail if the sending e-mail server cannot be reverse lookup in DNS. So by returning no name some e-mail will no longer be possible to deliver because the receiving end cannot identify you through DNS. It will also break programs needing to do a reverse lookup to find out host or domain name of an IP-address. That is one reason why several is suggesting that we have a way do encode a normal name into an ASCII compatible encoded name to fit the old host name syntax, just like quoted-printable/base64 is doing for e-mail. This would allow a name to be returned in reverse lookups to old software that do not understand non-ASCII. Also it will help protocols that have to do a downgrading from 8-bit to 7-bit. For example when sending e-mail to xxx@non-ascii-name.com an 8-bit aware e-mail MTA can downgrade the non-ascii-name into an ASCII compatible name by encoding the name and then send it onwards (looking like: xxx@encoded.com). As the DNS server recognises the encoded format, it can still answer DNS lookups for the encoded form and e-mail will still work. > > | If the client > | cannot handle non_ASCII, the DNS server can return an ASCII compatible > | encoded version of the name to avoid breaking the client. > > That's horrible. Having DNS servers making arbitrary changes to the > data they have been given is about as evil as I care to contemplate. Not arbitrary. As I describe above, it is an encoded form of the name into ASCII. It is fully reversible. DNS can recognise both the normal and the encoded form allowing lookups to work for both of them. I think it is still quite horrible, but none have come up with a better way to allow non-ASCII names to be used without disrupting a lot of services. If somebody can show that we can just use non-ASCII names and still have most things to work normally whith all old software, I would be very happy. But I think the examples I give above about e-mail and reverse lookups are just the top of an iceberg of problems. There must be many more ways things can break when non-ASCII occurs in a name for older software. Does anybody have som more thoughts about this? Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 21 09:02:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00265 for ; Mon, 21 Aug 2000 09:02:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13QqXN-000HL6-00 for namedroppers-data@psg.com; Mon, 21 Aug 2000 05:18:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13QqXN-000HKy-00 for namedroppers@ops.ietf.org; Mon, 21 Aug 2000 05:18:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13QqXN-0006NS-00 for namedroppers@ops.ietf.org; Mon, 21 Aug 2000 05:18:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <4.3.2.7.2.20000821070733.0255adf0@mail.viagenie.qc.ca> Date: Mon, 21 Aug 2000 07:11:08 -0400 To: "Eric A. Hall" , Edward Lewis From: Marc Blanchet Subject: Re: Flagging non-ASCII in domain names Cc: Dan , namedroppers@ops.ietf.org In-Reply-To: <39A09608.B84EA508@ehsco.com> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At/À 19:38 2000-08-20 -0700, Eric A. Hall you wrote/vous écriviez: >Edward Lewis wrote: > > > > At 6:42 AM -0400 8/20/00, Dan wrote: > > >Does anybody have any comments on using the last free bit or using > > >for example the AA bit as an incoming flag bit? Are there really any > > >problems with this, or is it just that everybody want to go EDNS? > > > > If we are to do something in a short amount of time, we should do it > > in a way that is most amenable to being backed out. Therefore, I'd > > urge any work towards iDNS to make use of EDNS and not (re)use the > > bits of the aboriginal header. > >One other possibility is using the bits from the length field of the >domain name label data type. Currently the two defined uses of the first >two bits from this field are 00 for data and 11 for compression. Neither >01 or 10 are used for anything to my knowledge. 01 is used for edns. From RFC2671: 3 - Extended Label Types 3.1. The "0 1" label type will now indicate an extended label type, whose value is encoded in the lower six bits of the first octet of a label. All subsequently developed label types should be encoded using an extended label type. >It may be workable to define one of those bit patterns so that they >indicate some sort of international encoding. 10 has been proposed by one group (http://www.ietf.org/internet-drafts/draft-ietf-idn-dnsii-mdnp-00.txt) >The upside to this approach >is that it is pretty simple to code support for. The downside is that it >would have to be a fixed character set, so it probably wouldn't be an >exceptionally robust solution, but instead would be "less limited". > >If full encoding of double-byte data is required/desired, I would think >EDNS would be the most viable option. one draft talks about using edns (http://www.ietf.org/internet-drafts/draft-ietf-idn-idne-01.txt) Marc. >-- >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. Marc Blanchet Viagénie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 21 14:43:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06786 for ; Mon, 21 Aug 2000 14:43:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13QvsG-000JlM-00 for namedroppers-data@psg.com; Mon, 21 Aug 2000 11:00:40 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13QvsF-000Jl9-00 for namedroppers@ops.ietf.org; Mon, 21 Aug 2000 11:00:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13QrW0-0000nw-00 for namedroppers@ops.ietf.org; Mon, 21 Aug 2000 06:21:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <000701c00b6b$206d15c0$44ef0618@union1.nj.home.com> Reply-To: "Al Costanzo" From: "Al Costanzo" To: "Dan Oscarsson" , References: <200008210633.e7L6XUX11856@valinor.malmo.trab.se> Subject: Re: Flagging non-ASCII in domain names Date: Mon, 21 Aug 2000 08:27:07 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan Writes: For example, some e-mail servers do not accept incoming e-mail if the sending e-mail server cannot be reverse lookup in DNS. So by returning no name some e-mail will no longer be possible to deliver because the receiving end cannot identify you through DNS. ------ Al Replies: Not only is this true but in many cases 'designed' into anti-spam filters. We had to turn this feature on, along with other to slow down the spam through our servers. Its a shame, I remember when the Internet was like a happy family or group working together :( -al to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 21 14:47:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06862 for ; Mon, 21 Aug 2000 14:47:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Qvs9-000Jkn-00 for namedroppers-data@psg.com; Mon, 21 Aug 2000 11:00:33 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13Qvs8-000Jkg-00 for namedroppers@ops.ietf.org; Mon, 21 Aug 2000 11:00:32 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Qvpb-0000t1-00 for namedroppers@ops.ietf.org; Mon, 21 Aug 2000 10:57:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008211533.IAA91359@redpaul.mibh.net> To: Marc Blanchet cc: "Eric A. Hall" , Edward Lewis , Dan , namedroppers@ops.ietf.org Subject: Re: Flagging non-ASCII in domain names In-reply-to: Your message of "Mon, 21 Aug 2000 07:11:08 EDT." <4.3.2.7.2.20000821070733.0255adf0@mail.viagenie.qc.ca> Date: Mon, 21 Aug 2000 08:33:23 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >One other possibility is using the bits from the length field of the > >domain name label data type. Currently the two defined uses of the first > >two bits from this field are 00 for data and 11 for compression. Neither > >01 or 10 are used for anything to my knowledge. > > 01 is used for edns. From RFC2671: and 10 was used by peter koch's local compression, which was killed in nov99. > >It may be workable to define one of those bit patterns so that they > >indicate some sort of international encoding. it's unlikely that 10 will be assigned now that edns is a proposed standard. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Aug 21 19:54:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11201 for ; Mon, 21 Aug 2000 19:54:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13R0o8-000MNT-00 for namedroppers-data@psg.com; Mon, 21 Aug 2000 16:16:44 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13R0o7-000MNN-00 for namedroppers@ops.ietf.org; Mon, 21 Aug 2000 16:16:43 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13R0o5-00013m-00 for namedroppers@ops.ietf.org; Mon, 21 Aug 2000 19:16:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000821142233.07e2d1e0@localhost> Date: Mon, 21 Aug 2000 14:23:32 -0400 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Re: Draft minutes of DNSEXT @ IETF48 In-Reply-To: <4.3.2.7.2.20000809161021.00cfc570@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 04:13 PM 8/9/00, Olafur Gudmundsson wrote: >3 August 2000, DNSEXT WG >Meeting run by chairs Olafur Gudmundsson and Randy Bush >Minutes by Donald Eastlake and Mark Kosters (thanks to both of you) >Edited by Olafur Gudmundsson. As there have not been any comments on the Draft minutes consider them now the OFFICIAL minutes. 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 Aug 22 23:23:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21574 for ; Tue, 22 Aug 2000 23:23:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13RQM5-0006Zh-00 for namedroppers-data@psg.com; Tue, 22 Aug 2000 19:33:29 -0700 Received: from [63.161.207.84] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13RQM4-0006ZM-00 for namedroppers@ops.ietf.org; Tue, 22 Aug 2000 19:33:28 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13RQLb-0000Ga-00 for namedroppers@ops.ietf.org; Tue, 22 Aug 2000 22:32:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000822145520.00d33100@localhost> Date: Tue, 22 Aug 2000 14:59:12 -0400 To: bill , Ted.Lindgreen@tednet.nl From: Olafur Gudmundsson Subject: Re: Is this a possible DoS scenario within DNSSEC ? Cc: Olafur Gudmundsson , Roy Arends , DNS Extensions WG In-Reply-To: <39909B68.5B7CAE96@isi.edu> References: <200007252222.AAA30381@open.nlnetlabs.nl> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 07:44 PM 8/8/00, bill wrote: >Ted Lindgreen responds to Ogud: > > > > servers will increase significantly. And DNSSEC may not work well if > > > resolvers are stuck behind a non DNSSEC capable forwarder. > > > > Absolutely, and the real lessons are therefore clear: > > - Secure aware resolvers should not use non secure aware > > caching servers as forwarder. > > So, how do secure aware resolvers identify a non-secure > aware caching server? Once they can id the suspect cache > how are they to "remember" that the cache is suspect? > > And perhaps more importantly, is this on a machine or > zone basis? If per zone, then there is the temporal issue, > i.e. when does the zone "flip" between secure and not and > how does the caching server "keep" up? The answer is in the draft that David Conrad is writing on and EDNS0 flag. David where is the draft ? Olafur >--bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Aug 23 08:25:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10206 for ; Wed, 23 Aug 2000 08:25:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13RYtg-0009Wt-00 for namedroppers-data@psg.com; Wed, 23 Aug 2000 04:40:44 -0700 Received: from [63.161.207.84] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13RYtg-0009Wi-00 for namedroppers@ops.ietf.org; Wed, 23 Aug 2000 04:40:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13RYtB-0000ah-00 for namedroppers@ops.ietf.org; Wed, 23 Aug 2000 07:40:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.2.0.58.J.20000823154247.0318ae70@sh.w3.mag.keio.ac.jp> Date: Wed, 23 Aug 2000 15:44:30 +0900 To: "Eric A. Hall" , Edward Lewis From: "Martin J. Duerst" Subject: Re: Flagging non-ASCII in domain names Cc: Dan , namedroppers@ops.ietf.org In-Reply-To: <39A09608.B84EA508@ehsco.com> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 00/08/20 19:38 -0700, Eric A. Hall wrote: >One other possibility is using the bits from the length field of the >domain name label data type. Currently the two defined uses of the first >two bits from this field are 00 for data and 11 for compression. Neither >01 or 10 are used for anything to my knowledge. > >It may be workable to define one of those bit patterns so that they >indicate some sort of international encoding. The upside to this approach >is that it is pretty simple to code support for. The downside is that it >would have to be a fixed character set, so it probably wouldn't be an >exceptionally robust solution, but instead would be "less limited". Using more than a single character set, while still not fully ruled out, would create many different problems and would decrease, not increase, robustness. So using just a flag is okay, the question is mainly which one. 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 Thu Aug 24 11:25:48 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19102 for ; Thu, 24 Aug 2000 11:25:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13RyE4-000JCe-00 for namedroppers-data@psg.com; Thu, 24 Aug 2000 07:43:28 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13RyE3-000JCY-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 07:43:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13RyE3-000OUl-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 07:43:27 -0700 Message-Id: <200008181821.OAA04179@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-roadmap-00.txt Date: Fri, 18 Aug 2000 14:21:58 -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 Security Document Roadmap Author(s) : S. Rose Filename : draft-ietf-dnsext-dnssec-roadmap-00.txt Pages : 11 Date : 17-Aug-00 DNS Security (DNSSEC)technology is composed of extensions to the Domain Name System (DNS) protocol that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Several documents exist to describe these extensions and the implementation specific details regarding specific digital signing schemes. The interrelationship between these different documents is discussed here. A brief overview of what to find in which document and author guidelines for what to include in new DNS Security documents, or revisions to existing documents, is described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-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-roadmap-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-roadmap-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: <20000817105126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-roadmap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-roadmap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000817105126.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 Thu Aug 24 11:26:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19114 for ; Thu, 24 Aug 2000 11:26:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13RyBP-000JBQ-00 for namedroppers-data@psg.com; Thu, 24 Aug 2000 07:40:43 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13RyBP-000JBK-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 07:40:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13RyBP-000OT9-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 07:40:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 23 Aug 2000 21:19:13 -0400 Message-Id: <200008240119.VAA05833@egyptian-gods.MIT.EDU> From: Greg Hudson To: namedroppers@ops.ietf.org Subject: DNS usage in application protocols Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi. The following text appears in section 5 of draft-ietf-drums-smtpupd-12.txt, regarding MX hostnames with multiple A records: The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and SMTP MUST try them in the order presented. My DNS background suggests that this "MUST try them in the order presented" requirement is misguided; order of DNS records is not supposed to be important. The text has been copied (with s/MX/SRV/) by a draft relevant to the IMPP group, so I'm concerned about a faulty meme propagating. Can people in this group comment on whether I'm off my rocker? I can't imagine a client wanting to tamper with the order of records returned by a resolver, but if for some odd reason it does want to (say, it happens to have some network map information, or a cached indication of which A record worked last time), I don't see why it should be a violation the standard. Thanks. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 24 12:01:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19676 for ; Thu, 24 Aug 2000 12:01:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13RyqD-000JWr-00 for namedroppers-data@psg.com; Thu, 24 Aug 2000 08:22:53 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13RyqC-000JWl-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 08:22:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13RyqC-000OmV-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 08:22:52 -0700 From: Robert Elz To: Greg Hudson Cc: namedroppers@ops.ietf.org Subject: Re: DNS usage in application protocols In-Reply-To: Your message of "Wed, 23 Aug 2000 21:19:13 -0400." <200008240119.VAA05833@egyptian-gods.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Aug 2000 01:16:06 +1000 Message-Id: <2945.967130166@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 23 Aug 2000 21:19:13 -0400 From: Greg Hudson Message-ID: <200008240119.VAA05833@egyptian-gods.MIT.EDU> | Can people in this group comment on whether I'm off my rocker? I | can't imagine a client wanting to tamper with the order of records | returned by a resolver, but if for some odd reason it does want to | (say, it happens to have some network map information, or a cached | indication of which A record worked last time), I don't see why it | should be a violation the standard. No, the MUST seems overboard. It should probably say "unless other information available suggests that a different order is to be preferred". That is, by default, lacking any knowledge about the addresses, it should be assuming that the resolver has been configured to return them in a rational order, but if it knows that one is down, and another works, I think it might be possible to skip the known down one (provided it gets tried again from time to time). I have used this kind of thing when the first address is a local one, that is cheap to access, and the second is an alternate one, accessed via external paths - I'd actually prefer the cheap one to be tried first every time, no matter how often it was down before, before using the other (ie: agreeing with the MUST) but there are other situations when that wouldn't be needed (eg: someone from a remote site sending - to them either address looks just the same, it makes no difference which they use). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 24 13:13:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20761 for ; Thu, 24 Aug 2000 13:13:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13S06Q-000KGJ-00 for namedroppers-data@psg.com; Thu, 24 Aug 2000 09:43:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13S06Q-000KGD-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 09:43:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13S06Q-000POK-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 09:43:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A54FB0.ECA2C7F1@whistle.com> Date: Thu, 24 Aug 2000 09:39:12 -0700 From: Terry Lambert To: Greg Hudson CC: namedroppers@ops.ietf.org Subject: Re: DNS usage in application protocols References: <200008240119.VAA05833@egyptian-gods.MIT.EDU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Hudson wrote: > Hi. The following text appears in section 5 of > draft-ietf-drums-smtpupd-12.txt, regarding MX hostnames with multiple > A records: > > The destination host (perhaps taken from the preferred MX > record) may be multihomed, in which case the domain name > resolver will return a list of alternative IP addresses. It > is the responsibility of the domain name resolver interface to > have ordered this list by decreasing preference if necessary, > and SMTP MUST try them in the order presented. > > My DNS background suggests that this "MUST try them in the order > presented" requirement is misguided; order of DNS records is not > supposed to be important. Do not confuse the resolver interface with the DNS itself. The intent of this, from my reading, is to insure that lower MX weights MUST be used in preference to higher MX weights. In sendmail, for example, the "resolver interface" that does this is technically part of the code that comes with sendmail. Perhaps it is the intent of the authors to specify that, rather than putting MX weight sorting in every application implementing the SMTP protocol, that the code be implemented once in the system resolver library. I'd actually argue in favor of this, since I could see a day when SMTP could switch from MX to SRV records by trying SRV first, and only trying MX for backward compatability with legacy DNS systems (i.e. I can see MX being deprecated but not disallowed). The switchover would be accomplished by replacing the resolver out from under the applciations. As far as this being onerous on DNS, again, we need to avoid confusing the resolver interface with the DNS. I think that it is reasonable that, if the DNS group perpetuates MX's that lookups on MX's be ordered, as returned from the resolver interface. What do SRV records do? It's been a while since I've looked (sorry, I should be more up on SRV records, but I've got a lot vying for my attention right now). -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 24 13:16:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20810 for ; Thu, 24 Aug 2000 13:16:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13S0AH-000KIS-00 for namedroppers-data@psg.com; Thu, 24 Aug 2000 09:47:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13S0AG-000KIM-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 09:47:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13S0AG-000PQG-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 09:47:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008241644.MAA06403@egyptian-gods.MIT.EDU> To: Terry Lambert cc: namedroppers@ops.ietf.org Subject: Re: DNS usage in application protocols In-Reply-To: Your message of "Thu, 24 Aug 2000 09:39:12 PDT." <39A54FB0.ECA2C7F1@whistle.com> Date: Thu, 24 Aug 2000 12:44:10 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Do not confuse the resolver interface with the DNS itself. Understood, but the resolver has no information from the DNS with which to order A records. > The intent of this, from my reading, is to insure that lower MX > weights MUST be used in preference to higher MX weights. No, that would be the intent of the previous paragraph. When I said the paragraph was about MX hosts with multiple A records, I really meant it. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 24 14:17:40 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21787 for ; Thu, 24 Aug 2000 14:17:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13S12I-000Kob-00 for namedroppers-data@psg.com; Thu, 24 Aug 2000 10:43:30 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13S12H-000KoU-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 10:43:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13S12H-000PoF-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 10:43:29 -0700 Message-ID: <39A55D16.38975E7C@whistle.com> Date: Thu, 24 Aug 2000 10:36:22 -0700 From: Terry Lambert X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: Greg Hudson CC: namedroppers@ops.ietf.org Subject: Re: DNS usage in application protocols References: <200008241644.MAA06403@egyptian-gods.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Hudson wrote: > > Do not confuse the resolver interface with the DNS itself. > > Understood, but the resolver has no information from the DNS with > which to order A records. > > > The intent of this, from my reading, is to insure that lower MX > > weights MUST be used in preference to higher MX weights. > > No, that would be the intent of the previous paragraph. When I said > the paragraph was about MX hosts with multiple A records, I really > meant it. Mea culpa. I think I can defend that position even better, though. I think the idea is that the resolver might have preferences based on information not available to the MTA. For example, the resolver may know the BGP hop distance to each of these hosts, and order them in that order. I think that we can restate this as saying that the SMTP MTA MUST attempt them in the order presented by the resolver. Again, I think there's some leeway as to where the resolver interface is located. On the other hand, I would not object to some clarifying language, such as: The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and SMTP MUST try them in the order presented [when attempting to make a conection]. Does this make more sense? Alternately, one could predicate the "...and SMTP MUST..." on the "...if necessary,...", but I don't see how that information could be communicated across the interfaces without a lot of work. I agree that there's an ambiguity that could result in people believing that this could prohibit connection caching. Maybe the intent was to provide for a resolver based software version of a net rediretor -- if so, the idea is ill-advised. PS: I still believe the MX weight based sorting should take place in the resolver, based on the duplication of code argument, and that the resolver should be resonsible for presenting the data this way for the MX/SRV migration argument. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Aug 24 21:54:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27449 for ; Thu, 24 Aug 2000 21:54:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13S87j-000NoV-00 for namedroppers-data@psg.com; Thu, 24 Aug 2000 18:17:35 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13S87i-000NoP-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 18:17:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13S87i-0002ri-00 for namedroppers@ops.ietf.org; Thu, 24 Aug 2000 18:17:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39A5532F.4A4B35A@nominum.com> Date: Thu, 24 Aug 2000 09:54:07 -0700 From: "David R. Conrad" To: Olafur Gudmundsson Cc: bill , Ted.Lindgreen@tednet.nl, Roy Arends , DNS Extensions WG Subject: Re: Is this a possible DoS scenario within DNSSEC ? References: <200007252222.AAA30381@open.nlnetlabs.nl> <4.3.2.7.2.20000822145520.00d33100@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olafur, >> So, how do secure aware resolvers identify a non-secure >> aware caching server? > The answer is in the draft that David Conrad is writing on and EDNS0 flag. Err, no. The draft I'm writing addresses the question of how a server knows it is worthwhile to send DNSSEC data back to a client. If I understand the question, one answer could be that it is the responsibility of the user (system admin) to insure that the cache the resolver points to is DNSSEC aware. But I probably don't understand the question. > David where is the draft ? Like BINDv9, coming RSN... :-). More seriously, hope to get it out on Monday. Rgds, -drc to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 25 12:12:43 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23721 for ; Fri, 25 Aug 2000 12:12:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13SLJy-0002nV-00 for namedroppers-data@psg.com; Fri, 25 Aug 2000 08:23:06 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13SLJy-0002nP-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 08:23:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13SLJx-0008LU-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 08:23:05 -0700 Message-Id: <200008251043.GAA15269@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-rsa-00.txt Date: Fri, 25 Aug 2000 06:43:20 -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 : RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-rsa-00.txt Pages : 8 Date : 24-Aug-00 Since the adoption of a Proposed Standard for RSA signatures in the DNS [RFC 2537], advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG resource records (RRs). The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-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-rsa-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-rsa-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: <20000824100338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rsa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rsa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000824100338.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 Aug 25 12:12:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23732 for ; Fri, 25 Aug 2000 12:12:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13SLQM-0002qs-00 for namedroppers-data@psg.com; Fri, 25 Aug 2000 08:29:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13SLQL-0002qm-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 08:29:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13SLQL-0008PJ-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 08:29:41 -0700 To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-not-existing-rr-00.txt From: Simon Josefsson Date: 25 Aug 2000 14:14:37 +0200 Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=-=-= Hi, the "NO" draft have been updated (announcement inlined below). Among other things, it includes more detailed examples. As always, comments solicited. /Simon --=-=-= Title : Authenticating denial of existence in DNS with minimum disclosure (or; An alternative to DNSSEC NXT records) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-not-existing-rr-00.txt Pages : 15 Date : 24-Aug-00 This draft present an alternative to NXT records, used to achieve authenticated denial of existence of a domain name, class and type. Problems with NXT records, as specified in RFC 2535, are identified. One solution, the NO record, is presented. The NO record differ from the NXT record by using a cryptographic hash value instead of the domain name. This prevent an adversery from collecting information by 'chaining' through a zone. It also remove delegation point concerns in NXT records. The document also describe hash truncation and record merging that reduces storage/network load. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr-00.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 Aug 25 12:12:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23743 for ; Fri, 25 Aug 2000 12:12:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13SLK5-0002ne-00 for namedroppers-data@psg.com; Fri, 25 Aug 2000 08:23:13 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13SLK5-0002nY-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 08:23:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13SLK5-0008Le-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 08:23:13 -0700 Message-Id: <200008251043.GAA15339@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-not-existing-rr-00.txt Date: Fri, 25 Aug 2000 06:43:41 -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 : Authenticating denial of existence in DNS with minimum disclosure (or; An alternative to DNSSEC NXT records) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-not-existing-rr-00.txt Pages : 15 Date : 24-Aug-00 This draft present an alternative to NXT records, used to achieve authenticated denial of existence of a domain name, class and type. Problems with NXT records, as specified in RFC 2535, are identified. One solution, the NO record, is presented. The NO record differ from the NXT record by using a cryptographic hash value instead of the domain name. This prevent an adversery from collecting information by 'chaining' through a zone. It also remove delegation point concerns in NXT records. The document also describe hash truncation and record merging that reduces storage/network load. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr-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-not-existing-rr-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-not-existing-rr-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: <20000824145752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-not-existing-rr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-not-existing-rr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000824145752.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 Aug 25 12:13:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23759 for ; Fri, 25 Aug 2000 12:13:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13SLQo-0002rU-00 for namedroppers-data@psg.com; Fri, 25 Aug 2000 08:30:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13SLQn-0002rO-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 08:30:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13SLQn-0008Ph-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 08:30:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008251234.IAA28182@torque.pothole.com> X-Authentication-Warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol To: namedroppers@ops.ietf.org cc: Donald.Eastlake@motorola.com Subject: RSA/SHA1 Date: Fri, 25 Aug 2000 08:34:28 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The initial RSA/SHA-1 draft is out. I welcome comments. As presently drafted it completely obsoletes RFC 2537 which blows away the RSA/MD5 stuff. I think what we are pretty much saying here is that we don't trust MD5 enough into the future for sensitive security like high level DNS zones. I think this applies even to non-DNS uses. For example, if someone is using DNS keys for email security, while MD5 is probably fine for most mail, for sensitive messages, you would want to use SHA1. And since the computation required is not much more and you want to avoid the possibiity of downgrade attacks, you might as well always use SHA1. Pretty much the same considerations as for DNSSEC... Thanks, Donald Message-Id: <200008251043.GAA15269@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rsa-00.txt Date: Fri, 25 Aug 2000 06:43:20 -0400 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 : RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-rsa-00.txt Pages : 8 Date : 24-Aug-00 Since the adoption of a Proposed Standard for RSA signatures in the DNS [RFC 2537], advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG resource records (RRs). The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-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-rsa-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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Aug 25 14:30:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26792 for ; Fri, 25 Aug 2000 14:30:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13SNfu-00047N-00 for namedroppers-data@psg.com; Fri, 25 Aug 2000 10:53:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13SNft-00047H-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 10:53:53 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13SNft-0009Ok-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 10:53:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200008251754.NAA30544@torque.pothole.com> To: namedroppers@ops.ietf.org Subject: MD5 Date: Fri, 25 Aug 2000 13:54:28 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've gotten two private messages saying, in effect, "what's wrong with MD5"? It's one of those judgement things. Script kiddies are not routinely breaking MD5 on their PCs. But over three years ago in 1997, RFC 2104 which defines HMAC, said the following: "Note: To the date of writing of this document MD5 and SHA-1 are the most widely used cryptographic hash functions. MD5 has been recently shown to be vulnerable to collision search attacks [Dobb]. This attack and other currently known weaknesses of MD5 do not compromise the use of MD5 within HMAC as specified in this document (see [Dobb]); however, SHA-1 appears to be a cryptographically stronger function. To this date, MD5 can be considered for use in HMAC for applications where the superior performance of MD5 is critical. In any case, implementers and users need to be aware of possible cryptanalytic developments regarding any of these cryptographic hash functions, and the eventual need to replace the underlying hash function." RSA/MD5 signatures do not use HMAC but use direct MD5 under the RSA encryption. Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 140 Forest Avenue +1 978-562-2827(h) Hudson, MA 01749 USA +1 508-261-5434(w) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Aug 26 01:49:24 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12766 for ; Sat, 26 Aug 2000 01:49:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13SY5y-000813-00 for namedroppers-data@psg.com; Fri, 25 Aug 2000 22:01:30 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13SY5x-00080x-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 22:01:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13SY5x-000Dlh-00 for namedroppers@ops.ietf.org; Fri, 25 Aug 2000 22:01:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <2F3EC696EAEED311BB2D009027C3F4F408EBED@vhqpostal.verisign.com> From: Philip Hallam-Baker To: "'Donald E. Eastlake 3rd'" , namedroppers@ops.ietf.org Subject: RE: MD5 Date: Fri, 25 Aug 2000 13:42:56 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It's one of those judgement things. Script kiddies are not routinely > breaking MD5 on their PCs. But over three years ago in 1997, RFC 2104 > which defines HMAC, said the following: It is important to note that the specific attack developed by Dobbertin is such that the use of HMAC-MD5 is considerably less worrying than use of RSA-MD5. The attack itself does not represent a break of MD5 but it is close enough for use of MD5 to be depreicated in conjunction with signature since the attack is very close to a complete compromise and certainly suggests that the difficulty of a complete compromise is nowhere near O(2^128) complexity as we would like. The HMAC construction does not actually rely on the specific digest property that the Dobbertin attack compromises. It does not provide a means or discovering the key, nor does it allow an integrity attack. Since we are talking about RSA/MD5 here the argument for moving to SHA-1 is compelling. There is simply not enough confidence in the crypto community to use MD5 for a new application with no legacy base to support. We can guarantee that some people will make SHA-1 a requirement, I do not think it likely that anyone will argue passionately for RSA-MD5. Absent a deployed base we should nix RSA-MD5 entirely. [Theoretical premises in the RFCs concerning Heisod, DECNET etc. asside] DNS is a global infrastructure and I would have difficulty with the idea that there is room for any more than one sig alg that everyone uses and a backup. Phill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.