From owner-namedroppers@ops.ietf.org Tue May 1 04:48:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21796 for ; Tue, 1 May 2001 04:48:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uVPS-000Lh6-00 for namedroppers-data@psg.com; Tue, 01 May 2001 01:21:26 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uVPR-000Lgz-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 01:21:25 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uVPQ-000579-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 10:21:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 30 Apr 2001 19:09:48 -0000 Message-ID: <20010430190948.19724.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010430060710.18274.qmail@cr.yp.to> <200104300916.SAA06619@necom830.hpcl.titech.ac.jp> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohta is wrong. This is a bug in the protocol, not in any particular implementation. All of my comments apply to BIND's A6 implementation; BIND discards out-of-bailiwick records for security, just as djbdns does. Ohta's ``fix'' comments are nonsense. As for non-A6 examples: http://cr.yp.to/djbdns/killa6.html already covers this, and explains why A6 and DNAME make the problem much worse. See the ``DNS reliability problems'' section. ---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 May 1 04:54:11 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21797 for ; Tue, 1 May 2001 04:48:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uVZg-000M4A-00 for namedroppers-data@psg.com; Tue, 01 May 2001 01:32:00 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uVZe-000M40-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 01:31:59 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uVZd-00057m-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 10:31:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <66F66129A77AD411B76200508B65AC694CBA41@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'namedroppers@ops.ietf.org'" , "'ipng@sunroof.eng.sun.com'" Cc: "'dhcp-v6@bucknell.edu'" Subject: A6 and DNAME Date: Mon, 30 Apr 2001 15:58:08 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi: One more item to add to the recent discussion (which I've only partially followed) on A6 and DNAME records is ... how are they created and used in the first place? If one assumes that IPv6 addresses are automatically generated (either using autoconfiguration or DHCPv6), then how does an A6 record with non-0 prefix length ever get added in the first place? There hasn't been any method developed (that I'm aware of) to communicate to a client or DHCPv6 server that it should register these addresses under a given prefix. Also, if it were to do this, what happens if the prefix is multi-homed yet the address allocated to the client isn't (only one of the prefixes is in use)? This would significantly complicate clients and DHCPv6 servers since they may have to pull together several addresses before being able to register under the non-0 prefix? And the failure modes (such as not getting one address because of DAD or other reasons) are difficult to deal with. Same happens with the PTR records and DNAME ... how is the client or DHCPv6 server told to use a particular DNAME to register? Seems to me that most clients and DHCPv6 servers will register with the full 128-bits and therefore this fancy stuff won't be used anyway - since nothing will be in place to set it up. Sure, we could add a DHCPv6 option to communicate these details. But, what about when DHCPv6 isn't used and autoconfiguration is used? Sorry if this has already been raised as an issue and I missed it. - Bernie Volz to unsubscribe send a message to 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 May 1 05:09:20 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21987 for ; Tue, 1 May 2001 05:09:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uVqH-000Mkh-00 for namedroppers-data@psg.com; Tue, 01 May 2001 01:49:09 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uVqG-000MkZ-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 01:49:09 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uVqF-00058u-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 10:49:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: From: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" To: "'David Terrell'" , Masataka Ohta Cc: "D. J. Bernstein" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: RE: AAAA/A6 thing Date: Mon, 30 Apr 2001 17:08:40 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit hi, Is there any alternate solution to A6 record being looked at ? Something which lies somewhere in between AAAA and A6. -ebi > -----Original Message----- > From: David Terrell [mailto:dbt@meat.net] > Sent: Monday, April 30, 2001 9:25 AM > To: Masataka Ohta > Cc: D. J. Bernstein; namedroppers@ops.ietf.org; > ipng@sunroof.eng.sun.com > Subject: Re: AAAA/A6 thing > > > On Mon, Apr 30, 2001 at 06:16:21PM +0859, Masataka Ohta wrote: > > Dan; > > > > It's your problem. > > > > > Paul A Vixie writes: > > > > i have not, yet, heard anything new against A6 in this > round of the debate. > > > > > > http://cr.yp.to/djbdns/killa6.html > > > > How about: > > > > aol.com. NS ns0.aol.net. > > aol.com. NS ns1.aol.net. > > > > aol.net. NS ns0.aol.com. > > aol.net. NS ns1.aol.com. > > > > ? > > In this case, ns[01].aol.{net,com} will be in the {net,com} zones as > glue. > > I think the question that I have yet to see answered that Dan is > not articulating well is "how the hell is DNS glue supposed to work > sanely with A6?" I can't find an answer to that myself. Everybody's > talking about no full IP addresses written anywhere, and DNS > delegation is one place where that just doesn't work. You need the > full 128 bit address in there, and glue registry is the one place > that these addresses can't change frequently, because of the bulk > of TLD zones and complicated, time consuming procedures registrars > use to update those records... > > -- > David Terrell | "I went into Barnes and Noble to > look for a > Prime Minister, Nebcorp | book on A.D.D., but I got bored and left." > dbt@meat.net | - Benjy Feen > http://wwn.nebcorp.com/ | > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > to unsubscribe send a message to 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 May 1 05:09:20 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21989 for ; Tue, 1 May 2001 05:09:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uVqv-000Mlp-00 for namedroppers-data@psg.com; Tue, 01 May 2001 01:49:49 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uVqv-000Mlg-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 01:49:49 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uVqu-00058z-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 10:49:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200105010032.JAA08512@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA08512; Tue, 1 May 2001 09:32:16 +0900 Subject: Re: AAAA/A6 thing In-Reply-To: from "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" at "Apr 30, 2001 05:08:40 pm" To: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" Date: Tue, 1 May 2001 09:32:15 +0859 () CC: "'David Terrell'" , "D. J. Bernstein" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ebi; > hi, > > Is there any alternate solution to A6 record > being looked at ? Something which lies somewhere > in between AAAA and A6. A6 is as good as NS. All you need is an alternative implementation. Dan's one is broken. Paul's one was and may still be broken. 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 May 1 05:11:23 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22049 for ; Tue, 1 May 2001 05:11:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uVvp-000N0l-00 for namedroppers-data@psg.com; Tue, 01 May 2001 01:54:53 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uVvo-000N0P-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 01:54:53 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uVvn-00059a-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 10:54:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 30 Apr 2001 22:14:39 -0400 (EDT) From: Jim Bound To: David Terrell Cc: Masataka Ohta , "D. J. Bernstein" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <20010430092511.A591@pianosa.catch22.org> Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Right or wrong. Paul's comment is valid. A6 will be deployed at least on BIND (well it is now actually) and on Microsofts DNS is my read. As one of the people to fund BIND future development and with others we believe it should not be implemented for greater than 3 levels of hierarchy till more testing and experimentation is done. But A6 will be shipped on the street and its a done deal. Do I like A6 no. Do I think a better solution exists yes. But do I advocate deployment of A6 yes. Why because its time to move forward. I also thought continuing private address space was a bad idea in v6. I still do. KNow what I hope to help build that feature in our products. The Internet is crumbling under to many NAT and VPN peek-a-boo packets and we need to get IPv6 on the street. It is happening now. Will happen a lot by the end of this year. U.S. may be last to do it but thats ok they will do it too eventually. The real work we can do is elsewhere now like Multihoming and MIPv6. regards, /jim On Mon, 30 Apr 2001, David Terrell wrote: > On Mon, Apr 30, 2001 at 06:16:21PM +0859, Masataka Ohta wrote: > > Dan; > > > > It's your problem. > > > > > Paul A Vixie writes: > > > > i have not, yet, heard anything new against A6 in this round of the debate. > > > > > > http://cr.yp.to/djbdns/killa6.html > > > > How about: > > > > aol.com. NS ns0.aol.net. > > aol.com. NS ns1.aol.net. > > > > aol.net. NS ns0.aol.com. > > aol.net. NS ns1.aol.com. > > > > ? > > In this case, ns[01].aol.{net,com} will be in the {net,com} zones as > glue. > > I think the question that I have yet to see answered that Dan is > not articulating well is "how the hell is DNS glue supposed to work > sanely with A6?" I can't find an answer to that myself. Everybody's > talking about no full IP addresses written anywhere, and DNS > delegation is one place where that just doesn't work. You need the > full 128 bit address in there, and glue registry is the one place > that these addresses can't change frequently, because of the bulk > of TLD zones and complicated, time consuming procedures registrars > use to update those records... > > -- > David Terrell | "I went into Barnes and Noble to look for a > Prime Minister, Nebcorp | book on A.D.D., but I got bored and left." > dbt@meat.net | - Benjy Feen > http://wwn.nebcorp.com/ | > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 05:14:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22082 for ; Tue, 1 May 2001 05:14:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uVzK-000NAt-00 for namedroppers-data@psg.com; Tue, 01 May 2001 01:58:30 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uVzK-000NAm-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 01:58:30 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uVzJ-00059w-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 10:58:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 1 May 2001 03:11:12 -0000 Message-ID: <20010501031112.8471.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010430092511.A591@pianosa.catch22.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Bound writes: > But A6 will be shipped on the street and its a done deal. No, it is not. IPNG can terminate the A6/DNAME proposals right now. Users will continue to rely on AAAA, not on A6 and DNAME. > we believe it should not be implemented for greater than 3 levels of > hierarchy Even a single level of A6 indirection is dangerous. See my example of AOL committing suicide at the top of http://cr.yp.to/djbdns/killa6.html. I can't imagine what you think a 3-level limit would accomplish. > As one of the people to fund BIND future development Thank you for disclosing your financial interests. Did you know that United States antitrust law prohibits packing standards committees? ---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 May 1 05:15:03 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22093 for ; Tue, 1 May 2001 05:15:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uVxL-000N5w-00 for namedroppers-data@psg.com; Tue, 01 May 2001 01:56:27 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uVxK-000N5o-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 01:56:26 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uVxB-00059j-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 10:56:17 +0200 Date: Mon, 30 Apr 2001 22:40:06 -0400 (EDT) From: Jim Bound To: itojun@iijlab.net Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <22795.988684401@itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Itojun, My take as implementor and deployer champion is I don't care anymore. No one is going to use it till it works and thats a coding and performance of implementation issue. We are working on the BIND issues of performance now in the deployment community for IPv6. If necessary we will pay the highest bidder to get it done and perform. But until then I tell users to just use AAAA. Cause it works now. /jim On Tue, 1 May 2001 itojun@iijlab.net wrote: > > >Right or wrong. Paul's comment is valid. A6 will be deployed at least on > >BIND (well it is now actually) and on Microsofts DNS is my read. > > > >As one of the people to fund BIND future development and with others we > >believe it should not be implemented for greater than 3 levels of > >hierarchy till more testing and experimentation is done. But A6 will be > >shipped on the street and its a done deal. > > > >Do I like A6 no. > >Do I think a better solution exists yes. > >But do I advocate deployment of A6 yes. > >Why because its time to move forward. > > > >I also thought continuing private address space was a bad idea in v6. I > >still do. KNow what I hope to help build that feature in our products. > > what I am worrying is that A6 is contributing negatively to the > deployment of IPv6, due to less availability in code. it may have a > positive impact if it gets deployed worldwide (less signing cost on > renumber), but i guess the negative impact (to deployment) is bigger > than the benefits from less signing cost. > today there's no commercial/free software OS (i know of) that ships > with A6-chasing resolver. not sure they will ever migrate to BIND9 > resolvers, many of them are still stuck with BIND4 resolver (with > security fixes, of course) because of binary backward compatibility > issues and local changes they have made. > > maybe this feeling is because I'm from very IPv6-deployment-aggressive > region. i really would like to see IPv6 NS records to be available > everywhere, including root, and A6 is one of the obstacles for IPv6 > NS record deployment. > > anyway, i'll shut up and write up a draft. > > itojun > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 05:17:56 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22111 for ; Tue, 1 May 2001 05:17:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uVww-000N4U-00 for namedroppers-data@psg.com; Tue, 01 May 2001 01:56:02 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uVww-000N4G-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 01:56:02 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uVwt-00059f-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 10:55:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jim Bound Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: seamus's message of Mon, 30 Apr 2001 22:14:39 -0400. Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Tue, 01 May 2001 11:33:21 +0900 Message-ID: <22795.988684401@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Right or wrong. Paul's comment is valid. A6 will be deployed at least on >BIND (well it is now actually) and on Microsofts DNS is my read. > >As one of the people to fund BIND future development and with others we >believe it should not be implemented for greater than 3 levels of >hierarchy till more testing and experimentation is done. But A6 will be >shipped on the street and its a done deal. > >Do I like A6 no. >Do I think a better solution exists yes. >But do I advocate deployment of A6 yes. >Why because its time to move forward. > >I also thought continuing private address space was a bad idea in v6. I >still do. KNow what I hope to help build that feature in our products. what I am worrying is that A6 is contributing negatively to the deployment of IPv6, due to less availability in code. it may have a positive impact if it gets deployed worldwide (less signing cost on renumber), but i guess the negative impact (to deployment) is bigger than the benefits from less signing cost. today there's no commercial/free software OS (i know of) that ships with A6-chasing resolver. not sure they will ever migrate to BIND9 resolvers, many of them are still stuck with BIND4 resolver (with security fixes, of course) because of binary backward compatibility issues and local changes they have made. maybe this feeling is because I'm from very IPv6-deployment-aggressive region. i really would like to see IPv6 NS records to be available everywhere, including root, and A6 is one of the obstacles for IPv6 NS record deployment. anyway, i'll shut up and write up a draft. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 05:30:33 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22248 for ; Tue, 1 May 2001 05:30:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uWBq-000NoB-00 for namedroppers-data@psg.com; Tue, 01 May 2001 02:11:26 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uWBp-000Nnr-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 02:11:25 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uWBl-0005C2-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 11:11:21 +0200 From: Robert Elz To: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-reply-to: Your message of "Mon, 30 Apr 2001 17:08:40 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 16:09:47 +0700 Message-ID: <3674.988708187@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 30 Apr 2001 17:08:40 -0700 From: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" Message-ID: | Is there any alternate solution to A6 record | being looked at ? Something which lies somewhere | in between AAAA and A6. The obvious thing there would simply be to add some restrictions to the use of A6. One currently proposed is to only use A6 0,xxx (which makes it isomorphic to AAAA - but at least using the new record format, so upgrading to something a bit more complex later would not be impossible). Another would be to require all of the domains listed to be in the same zone as the A6 record (so the whole chain can always be returned in one DNS reply), and/or perhaps limiting the length of the chain (partly for the same reason). I doubt very much that it makes sense to invent something new - we already have the simplest of all possible results (AAAA) and the most general we can think of at the minute anyway (A6). Something neither simple, nor general doesn't seem likely to be a useful aim. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 05:39:52 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22376 for ; Tue, 1 May 2001 05:39:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uWTr-000OjC-00 for namedroppers-data@psg.com; Tue, 01 May 2001 02:30:03 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uWTr-000Oir-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 02:30:03 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uWTp-0005DE-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 11:30:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: kre's message of Tue, 01 May 2001 16:09:47 +0700. <3674.988708187@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Tue, 01 May 2001 18:22:09 +0900 Message-ID: <27764.988708929@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | Is there any alternate solution to A6 record > | being looked at ? Something which lies somewhere > | in between AAAA and A6. >The obvious thing there would simply be to add some restrictions to the >use of A6. One currently proposed is to only use A6 0,xxx (which makes >it isomorphic to AAAA - but at least using the new record format, so >upgrading to something a bit more complex later would not be impossible). this part i don't really understand. if we advocate "A6 0 <128bit>" there will be resolver implementation that does not chase A6 chains at all (like for cellphones or whatever). if there's no need, there'll be no code. then, there will be no possibility for "A6 ". so I don't really see benefit of "A6 0 <128bit>" than "AAAA". itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 05:52:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22478 for ; Tue, 1 May 2001 05:52:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uWfY-000PLh-00 for namedroppers-data@psg.com; Tue, 01 May 2001 02:42:08 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uWfX-000PLa-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 02:42:07 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uWfT-0005Dz-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 11:42:03 +0200 From: Robert Elz To: itojun@iijlab.net cc: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-reply-to: Your message of "Tue, 01 May 2001 18:22:09 +0900." <27764.988708929@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 16:39:37 +0700 Message-ID: <3804.988709977@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 01 May 2001 18:22:09 +0900 From: itojun@iijlab.net Message-ID: <27764.988708929@itojun.org> | this part i don't really understand. if we advocate "A6 0 <128bit>" | there will be resolver implementation that does not chase A6 chains | at all (like for cellphones or whatever). I had thought of adding to my message (but I wanted to keep it reasonably brief) that the full resolver implementations are still needed now, in the way we decide we need them to operate - which might be via an AAAA recursive query to a back end resolver (I would expect that most baby devices will use back end resolvers to do most of the work for IPv6, just as they have for IPv4 - whether that includes synthesising AAAA from A6 queries though hasn't been decided, but it certainly has been contemplated). The advantage of A6 0 is that it would guarantee operational stability to at least the degree of AAAA - not that it will simplify the implementation effort (which only needs to be done a smallish number of times in the grand scheme of things). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 06:31:05 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22699 for ; Tue, 1 May 2001 06:31:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uWzG-000089-00 for namedroppers-data@psg.com; Tue, 01 May 2001 03:02:30 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uWzF-000081-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 03:02:29 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uWz4-0005Fa-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 12:02:18 +0200 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 May 2001 03:00:00 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 06:35:23 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22730 for ; Tue, 1 May 2001 06:35:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uX6S-0000VN-00 for namedroppers-data@psg.com; Tue, 01 May 2001 03:09:56 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uX6R-0000V8-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 03:09:55 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uX6O-0005Fz-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 12:09:52 +0200 Date: Tue, 1 May 2001 03:06:18 -0700 (PDT) From: Bill Woodcock To: Randy Bush cc: Paul A Vixie , namedroppers@psg.com Subject: Re: dns server discovery using mdns In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Woody's example of why mDNS was needed was if two PDA's want to beam stuff > > to each other but use IP-over-IRDA rather than something proprietary. > Why would two isolated pdas wanting to beam stuff to eachother, > regardless of transport mechanism, need to resolve lcs.mit.edu? Sorry. Like Kibo, I'm ill-advisedly jumping in mid-thread without having gone back and read everything that led up to it, but... Yes, I think that PDA or laptop users need to be able to talk to each other in an ad-hoc environment, their users saying "Hi, my machine is palm.fooco.com, go ahead and ftp to me." What I _really don't like_ is the idea that this should use a substantially _different mechanism_ than looking up lcs.mit.edu. I don't like the idea that a host should have different name resolution mechanisms, and have to be constantly deciding which to use, based on external environmental changes. I'll shut up and read the rest of the thread now. -Bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 06:35:36 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22741 for ; Tue, 1 May 2001 06:35:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uX77-0000Wr-00 for namedroppers-data@psg.com; Tue, 01 May 2001 03:10:37 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uX77-0000Wl-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 03:10:37 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uX75-0005GG-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 12:10:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Bill Woodcock Cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns References: Message-Id: Date: Tue, 01 May 2001 12:09:46 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Yes, I think that PDA or laptop users need to be able to talk to each > other in an ad-hoc environment, their users saying "Hi, my machine is > palm.fooco.com, go ahead and ftp to me." What I _really don't like_ is > the idea that this should use a substantially _different mechanism_ than > looking up lcs.mit.edu. I don't like the idea that a host should have > different name resolution mechanisms, and have to be constantly deciding > which to use, based on external environmental changes. then parallel logic says you should have great sympathy with my not wanting to creatr a substantially different mechanism for finding the dns server than we already have, dhcp. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 08:03:48 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23960 for ; Tue, 1 May 2001 08:03:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uYYX-0004Hp-00 for namedroppers-data@psg.com; Tue, 01 May 2001 04:43:01 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uYYW-0004Gp-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 04:43:00 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uYYS-0005KA-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 13:42:56 +0200 From: Robert Elz To: Randy Bush cc: Bill Woodcock , namedroppers@psg.com Subject: Re: dns server discovery using mdns In-reply-to: Your message of "Tue, 01 May 2001 12:09:46 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 17:32:59 +0700 Message-ID: <4076.988713179@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 01 May 2001 12:09:46 +0200 From: Randy Bush Message-ID: | then parallel logic says you should have great sympathy with my not wanting | to creatr a substantially different mechanism for finding the dns server | than we already have, dhcp. The problem is that we currently have two mechanisms for finding the DNS server. One is DHCP. The other is manual configuration. The first only works if you have a local "number czar" who controls the DHCP configuration, knows everything, and lists all of the correct numbers to hand out to clients. Otherwise you have the problem of how does the DHCP server discover where the DNS server is to be found? So, what is left is just manual configuration, and that one is looking less and less attractive as a configuration mechanism into the future. Whether the scheme proposed is really the right solution to the problem I'm not sure yet, but I am fairly convinced that we do need something new. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 08:53:47 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25160 for ; Tue, 1 May 2001 08:53:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uZL2-0006NH-00 for namedroppers-data@psg.com; Tue, 01 May 2001 05:33:08 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uZL1-0006NB-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 05:33:07 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uZKz-0005Om-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 14:33:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 01 May 2001 14:12:52 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Bill Woodcock , Randy Bush cc: Paul A Vixie , namedroppers@psg.com Subject: Re: dns server discovery using mdns Message-ID: <4541978.988726372@localhost> In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 01-05-01 03.06 -0700 Bill Woodcock wrote: > > Why would two isolated pdas wanting to beam stuff to eachother, > > regardless of transport mechanism, need to resolve lcs.mit.edu? > > Sorry. Like Kibo, I'm ill-advisedly jumping in mid-thread without having > gone back and read everything that led up to it, but... > > Yes, I think that PDA or laptop users need to be able to talk to each > other in an ad-hoc environment, their users saying "Hi, my machine is > palm.fooco.com, go ahead and ftp to me." What I _really don't like_ is > the idea that this should use a substantially _different mechanism_ than > looking up lcs.mit.edu. I don't know if I as a layer 7 person want to jump in and tell people I read things on this list, BUT... I think Bill is having a wish for a client which want to use a service want to find the service on an IP based network without any pre-configuration at all. This has nothing to do with DNS, more than Bill saying that "I don't want this service to be different than looking up foo.example.com". When talking with Bill, it sounded like he want to do an IP-based version of the NBPLookup call in AppleTalk, which could be done over multicast of course, and it doesn't have to be a DNS query, and it doesn't have to be a DNS response. Am I right Bill? What have the zeroconf guys been doing lately? Is querying over multicast for available services a bad thing? I don't think so, but I ask myself whether this is DNS. I don't think it is. paf to unsubscribe send a message to 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 May 1 10:24:37 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28391 for ; Tue, 1 May 2001 10:24:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uama-000AVD-00 for namedroppers-data@psg.com; Tue, 01 May 2001 07:05:40 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uama-000AV7-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 07:05:40 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uamY-0005WI-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 16:05:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105011352.IAA19078@gungnir.fnal.gov> To: "Bernie Volz (EUD)" Cc: "'namedroppers@ops.ietf.org'" , "'ipng@sunroof.eng.sun.com'" , "'dhcp-v6@bucknell.edu'" From: "Matt Crawford" Subject: Re: A6 and DNAME In-reply-to: Your message of Mon, 30 Apr 2001 15:58:08 CDT. <66F66129A77AD411B76200508B65AC694CBA41@eambunt705.ena-east.ericsson.se> Date: Tue, 01 May 2001 08:52:47 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > One more item to add to the recent discussion (which I've only partially > followed) on A6 and DNAME records is ... how are they created and used in > the first place? > > If one assumes that IPv6 addresses are automatically generated (either using > autoconfiguration or DHCPv6), then how does an A6 record with non-0 prefix > length ever get added in the first place? There hasn't been any method > developed (that I'm aware of) to communicate to a client or DHCPv6 server > that it should register these addresses under a given prefix. I don't think draft-ietf-ipngwg-prefix-rr-disc-00.txt has expired yet. Discussion is in order, although under a new "subject" line, please! to unsubscribe send a message to 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 May 1 10:28:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28571 for ; Tue, 1 May 2001 10:27:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uar3-000Alx-00 for namedroppers-data@psg.com; Tue, 01 May 2001 07:10:17 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uar2-000Alb-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 07:10:16 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uar1-0005X1-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 16:10:15 +0200 Date: Tue, 1 May 2001 07:08:36 -0700 (PDT) From: Bill Woodcock To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns In-Reply-To: <4541978.988726372@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > When talking with Bill, it sounded like he want to do an IP-based version > of the NBPLookup call in AppleTalk, which could be done over multicast of > course, and it doesn't have to be a DNS query, and it doesn't have to be a > DNS response. Yes. That idea has been proposed a few times, just reimplementing NBP-over-IP, but that winds up being a whole new protocol, and then you don't pick up the zillion ancillary benefits of using actual DNS. Yes, I want to get rid of AppleTalk. But no, I don't want to get rid of it so badly that I'm willing to give up on being able to use real DNS instead. -Bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 11:24:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01073 for ; Tue, 1 May 2001 11:24:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ubkY-000DOM-00 for namedroppers-data@psg.com; Tue, 01 May 2001 08:07:38 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14ubkY-000DOG-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 08:07:38 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14ubkW-0005b1-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 17:07:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 1 May 2001 07:42:17 -0700 (PDT) From: Bill Woodcock To: Randy Bush cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > then parallel logic says you should have great sympathy with my not wanting > to creatr a substantially different mechanism for finding the dns server > than we already have, dhcp. I see your point, however finding the nameserver has really never been my interest. I'm interest in finding resources generically: laser printers, file-sharing peers, et cetera. I think we'd all agree that DHCP isn't the way to find a laser printer, nor an ad-hoc file-sharing peer. And I think one would be hard-pressed to find a clear justification for not using DNS for that purpose. Given that DNS is the appropriate means of finding resources, the question is whether we want to have divergent versions of DNS, or one way of using DNS, and I'm very much for the latter. -Bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 12:09:01 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02368 for ; Tue, 1 May 2001 12:09:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ucSQ-000FWY-00 for namedroppers-data@psg.com; Tue, 01 May 2001 08:52:58 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14ucSP-000FWE-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 08:52:57 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14ucSO-0005eV-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 17:52:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Bill Woodcock cc: Randy Bush , namedroppers@psg.com Subject: Re: dns server discovery using mdns In-Reply-To: References: Date: Tue, 01 May 2001 22:48:21 +0700 Message-ID: <5201.988732101@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 1 May 2001 07:42:17 -0700 (PDT) From: Bill Woodcock Message-ID: | I think we'd all agree that DHCP isn't the | way to find a laser printer, Probably not, but it does have the impress printer location option... | And I think | one would be hard-pressed to find a clear justification for not using DNS | for that purpose. Actually, not even slightly pressed. That isn't what the DNS is useful for at all. If you know what your printer (or file server) is called, then the DNS is great for translating that into an address so you can reach it. But for the appletalk like "what laserwriters are out there that I might be able to print on? Oh yes, that's the one I should use" it is totally useless. Svrloc is (was?) supposed to be the protocol for that kind of function. | Given that DNS is the appropriate means of finding resources, It isn't. However, that doesn't negate the problem of locating a DNS server given no configuration (anywhere). Or more likely in a case like this (the thing the node is more likely to want to find) - a DNS back end resolver. That is, something that will do DNS lookups for me. Given that, and some way to figure out my own domain name, then I can find the actual DNS servers using the DNS (on the off chance I should happen to need to know them). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 1 13:14:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04348 for ; Tue, 1 May 2001 13:14:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14udO6-000I7Z-00 for namedroppers-data@psg.com; Tue, 01 May 2001 09:52:34 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14udO5-000I7S-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 09:52:33 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14udO4-0005is-00 for namedroppers@ops.ietf.org; Tue, 01 May 2001 18:52:32 +0200 From: "Richard Barr Hibbs" To: Subject: RE: dns server discovery using mdns Date: Tue, 1 May 2001 09:34:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5201.988732101@brandenburg.cs.mu.OZ.AU> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert-- (with tongue firmly planted in cheek) I just knew that someday someone (like yourself) would find a reason to use this option, thus shooting down in flames my proposal to sunset it..... > | I think we'd all agree that DHCP isn't the > | way to find a laser printer, > > Probably not, but it does have the impress printer location option... > ...but I do agree completely that DHCP was not really intended to answer the generic question of what resources are available to a client, while SRVLOC really was.... > | And I think one would be hard-pressed to find > | a clear justification for not using DNS > | for that purpose. > > Actually, not even slightly pressed. That isn't what > the DNS is useful for at all. If you know what your > printer (or file server) is called, then the DNS is > great for translating that into an address so you can > reach it. But for the appletalk like "what > laserwriters are out there that I might be able to > print on? Oh yes, that's the one I should use" > it is totally useless. > > Svrloc is (was?) supposed to be the protocol for that kind of function. > ...this presupposes the existence of several different types of servers (DHCP, DNS, SRVLOC, and maybe some TFTP servers for things like PXE configuration) when what is needed is closer to ZEROCONF. My own bias is to simplify rather than increase the number and types of data stored by different servers to answer client requests, and to develop a robust mechanism for self-configuration in the absence of these servers. --Barr Hibbs UltraDNS Corporation to unsubscribe send a message to 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 May 2 04:18:48 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03638 for ; Wed, 2 May 2001 04:18:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14urMy-0008SH-00 for namedroppers-data@psg.com; Wed, 02 May 2001 00:48:20 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14urMy-0008S1-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 00:48:20 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14urMv-00060C-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 09:48:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105011429.KAA08968@egyptian-gods.MIT.EDU> To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Your message of "30 Apr 2001 19:09:48 -0000." <20010430190948.19724.qmail@cr.yp.to> Date: Tue, 01 May 2001 10:29:44 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Ohta is wrong. This is a bug in the protocol, not in any particular > implementation. All of my comments apply to BIND's A6 > implementation; BIND discards out-of-bailiwick records for security, > just as djbdns does. Ohta's ``fix'' comments are nonsense. I don't understand this argument. How can NS glue work if BIND and djbdns completely discard out-of-bailiwick records during a query? I thought BIND and djbdns would use out-of-bailiwick records to complete the current query (which is not a security problem, since the server who gave you those records could have simply given you a different answer) but wouldn't cache them for future queries. Pardon my slowness. to unsubscribe send a message to 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 May 2 04:19:29 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03650 for ; Wed, 2 May 2001 04:19:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14urV3-0008qk-00 for namedroppers-data@psg.com; Wed, 02 May 2001 00:56:41 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14urV2-0008qe-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 00:56:40 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14urUz-00060m-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 09:56:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Ian Jackson Message-ID: <15087.5796.511511.914135@davenant.relativity.greenend.org.uk> Date: Tue, 1 May 2001 21:03:48 +0100 (BST) To: , Subject: RE: AAAA/A6 thing In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema writes ("RE: AAAA/A6 thing "): > The motivation for A6 is still valid; no new argument there, What motivation for A6 ? Where can I read what the motivations were of the authors of 2874 ? As far as I can tell it was just cooked up in a back room somewhere under the influence of mind-altering substances. Now it may have been properly discussed somewhere in some IETF WG, and it may even have been designed (though clearly not by anyone who understands the DNS). However I have asked several times for someone to point me at these discussions, and I have had no concrete reference. > I believe it will be a great tool for network managers. Please explain. > We definitely need to gather operational experience. No, we do not need to gather operational experience to see that anything useful that can be done with A6 (ie client-side indirection for the prefix) can be done with AAAA just as well if not better - all you need is a half-decent tool to help you construct zone files, which anyone serious has anyway. We have a serious complexity problem with many IETF and related protocols at the moment. There should not be features in any standards track protocol than cannot be clearly and cogently justified. The burden of proof is on A6 proponents to explain how doing the prefix lookup in the client at resolution time, rather than at the server side at data generation or load time, is a benefit. This burden has not even come close to being satisfied as far as I can see; perhaps it was in the past (though I doubt it), but if so no-one seems able to point us at the relevant messages. > Note that RFC 2874 packs together the use of A6 for name to IPv6 address > resolution, and the use of binary labels and DNAME for the IPv6 address > to name translation. When we conduct the evaluation, it may be useful to > separate the three points: A6, discussed above, DNAME, which has its own > set of benefits and issues, and binary labels, which is clearly an > extension to the core DNS name resolution mechanism. DNAME and bitstring are awful too, and should be abolished as well. But at the moment we seem to be arguing about A6. Ian. to unsubscribe send a message to 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 May 2 04:21:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03682 for ; Wed, 2 May 2001 04:21:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14urRz-0008hB-00 for namedroppers-data@psg.com; Wed, 02 May 2001 00:53:31 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14urRy-0008h5-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 00:53:30 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14urRv-00060b-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 09:53:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: AAAA/A6 thing Date: Tue, 1 May 2001 10:25:18 -0700 Message-ID: From: "Christian Huitema" To: , "Robert Elz" Cc: , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > this part i don't really understand. if we advocate "A6 0 <128bit>" > there will be resolver implementation that does not chase A6 chains > at all (like for cellphones or whatever). if there's no need, > there'll be no code. then, there will be no possibility for "A6 > ". so I don't really see > benefit > of "A6 0 <128bit>" than "AAAA". I think we have to delineate the various motivation and arguments: we want A6 to facilitate site renumbering and site multi-homing, while reducing the rate of DNS update; we also want to avoid harmful effects on the DNS resolution. The motivation for A6 is still valid; no new argument there, I believe it will be a great tool for network managers. There have been two questions on its use, the linkage with the address allocation and the depth of the hierarchy. The short answer to address allocation is router advertisement; the short answer to the depth of the hierarchy is that a depth of 1 is probably adequate to show significant benefits. The motivation for using "A6 0 <128bit>" is the use of A6 during the name resolution process, especially at the top level. We don't want root servers spending their time chasing A6 chains, and we also don't want the extra-load on root servers that could be caused by clients chasing A6 chains. This means that the address records of name servers will have to be explicitly updated when a site is renumbered. I believe that this is a reasonable compromise; without A6 one would have to update all the records; with the initial design we aimed at updating exactly one record per site; with the compromise one would update a few records only. We definitely need to gather operational experience. For example, an assumption in the design of A6 is that the higher level of the hierarchy will be very likely to be cached; whether this is true or false is easy to measure after a modicum of deployment. Another assumption is that the nodes can automatically update their addresses, and that the update process can be synchronized with the DNS updates; this can indeed also be tested. And, once we are done testing, we should document the results. Note that RFC 2874 packs together the use of A6 for name to IPv6 address resolution, and the use of binary labels and DNAME for the IPv6 address to name translation. When we conduct the evaluation, it may be useful to separate the three points: A6, discussed above, DNAME, which has its own set of benefits and issues, and binary labels, which is clearly an extension to the core DNS name resolution mechanism. -- Christian Huitema to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 2 05:01:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04089 for ; Wed, 2 May 2001 05:01:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14us6S-000AcM-00 for namedroppers-data@psg.com; Wed, 02 May 2001 01:35:20 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14us6Q-000Abt-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 01:35:19 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14us6P-00064O-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 10:35:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2 May 2001 02:53:29 -0000 Message-ID: <20010502025329.12205.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <200105011426.XAA10792@necom830.hpcl.titech.ac.jp> <20010430190948.19724.qmail@cr.yp.to> <200105011327.WAA10527@necom830.hpcl.titech.ac.jp> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit RFC 1034 does not correctly describe the behavior of real DNS caches, such as BIND and dnscache. In particular: * The RFC 1034 resolution algorithm loops and eventually fails when glue A records expire before NS records. Real caches fall back to the roots and succeed. * The RFC 1034 resolution algorithm saves information from servers that are not authorized to provide the information. Real caches reject the unauthorized information. Yes, these are differences between RFC 1034 and reality. RFC 1034 is clearly wrong in both cases: it creates a reliability problem in the first case and a security problem in the second case. http://cr.yp.to/djbdns/notes.html explains these issues in detail. The section on gluelessness includes the same type of example that Ohta is talking about now, with servers that follow the RFC 1034 rules but that can't be reached by DNS caches: espn.tv NS ns-1.disney.corp espn.tv NS ns-2.disney.corp disney.corp NS zone.espn.tv disney.corp NS night.espn.tv Ohta is wrong when he blames the DNS cache for throwing away the glue here. RFC 1034 _does not_ require glue in this situation. The espn.tv servers don't know the ns-1.disney.corp address. http://cr.yp.to/djbdns/killa6.html explains why A6 and DNAME will make these failures much more common. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 2 05:57:03 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04587 for ; Wed, 2 May 2001 05:57:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ut75-000DXR-00 for namedroppers-data@psg.com; Wed, 02 May 2001 02:40:03 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14ut74-000DXK-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 02:40:03 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14ut73-0006Ac-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 11:40:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <27764.988708929@itojun.org> Date: Wed, 02 May 2001 09:57:49 +0200 (CEST) From: Christian Schild To: itojun@iijlab.net Subject: Re: AAAA/A6 thing Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Itojun, On 01-May-2001 itojun@iijlab.net wrote: > >> | Is there any alternate solution to A6 record >> | being looked at ? Something which lies somewhere >> | in between AAAA and A6. >>The obvious thing there would simply be to add some restrictions to the >>use of A6. One currently proposed is to only use A6 0,xxx (which makes >>it isomorphic to AAAA - but at least using the new record format, so >>upgrading to something a bit more complex later would not be impossible). > > this part i don't really understand. if we advocate "A6 0 <128bit>" > there will be resolver implementation that does not chase A6 chains > at all (like for cellphones or whatever). if there's no need, > there'll be no code. then, there will be no possibility for "A6 > ". so I don't really see benefit > of "A6 0 <128bit>" than "AAAA". one can still 'advocate' A6 0 <128bit> with the chain resolution implemented. In my understanding we should suggest to use 128bit records for _now_. If in the future, with more testing done and more experience at hand, we have developed a good set of rules how to chain A6 records in an unperilous manner, then we could start to _use_ the chaining. Christian to unsubscribe send a message to 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 May 2 06:10:45 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04678 for ; Wed, 2 May 2001 06:10:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14utF7-000Dwp-00 for namedroppers-data@psg.com; Wed, 02 May 2001 02:48:21 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14utF6-000Dwj-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 02:48:20 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14utF5-0006Bl-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 11:48:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20010502111942.A1234@connect.com.au> References: <20010430092511.A591@pianosa.catch22.org> <20010501031112.8471.qmail@cr.yp.to> In-Reply-To: <20010501031112.8471.qmail@cr.yp.to>; from D. J. Bernstein on Tue, May 01, 2001 at 03:11:12AM -0000 Date: Wed, 2 May 2001 11:19:42 +1000 From: Nathan Jones To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: >Jim Bound writes: >> But A6 will be shipped on the street and its a done deal. > >No, it is not. IPNG can terminate the A6/DNAME proposals right now. They can, but are unlikely to. We can spend thread after thread debating whether these new developments should be used: IPv6, A6, DNAME, AAAA, etc. Yet, the feeling I get is that many people would rather implement them and then decide: whether the protocols should advance to Draft Standards; whether further restrictions are required; whether the negative aspects can be avoided with common sense, etc. >> As one of the people to fund BIND future development > >Thank you for disclosing your financial interests. Did you know that >United States antitrust law prohibits packing standards committees? I don't see it as a case of stacking the standards process. Proposed Standards are already available and, whether good or bad, some people want to implement them and gain some operational experience. Jim and others are funding the implementation of existing protocols. -- nathanj to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 2 06:10:56 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04689 for ; Wed, 2 May 2001 06:10:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14utKs-000EAD-00 for namedroppers-data@psg.com; Wed, 02 May 2001 02:54:18 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14utKs-000E9o-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 02:54:18 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14utKr-0006Ci-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 11:54:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 May 2001 02:26:22 -0700 (PDT) From: Erik Guttman To: Patrik Fltstrm cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I think Bill is having a wish for a client which want to use a service want > to find the service on an IP based network without any pre-configuration at > all. > When talking with Bill, it sounded like he want to do an IP-based version > of the NBPLookup call in AppleTalk, which could be done over multicast of > course, and it doesn't have to be a DNS query, and it doesn't have to be a > DNS response. If we have mDNS (as per draft-ietf-dnsext-mdns-00.txt) and it supports arbitrary requests, we can conceivably find local networked printers supporting IPP with the following request - QNAME="_IPP._TCP.local.arpa.", QTYPE=SRV This assumes (1) mdns servers on printers will respond to QTYPE=SRV in addition to QTYPE=A and PTR requests (2) the printer is link-local (3) we do not care about *which* printer we find on the link (we will find them all). SLPv2 (RFC 2608) allows us to find printers that advertise using SLP, using admin-scope multicast. SLP queries are attribute based LDAPv3 search filters - so a client can find *specific* printers which match their requirements and determine what attributes the printer has without using application-specific attribute querying mechanisms. The *real problem* with service discovery on the internet is that one has to add software to do it. There are many ways to do service configuration (DHCP, DNS SRV RRs, SLP, and non-standard stuff from microsoft, salutation, etc.) Which to choose? > What have the zeroconf guys been doing lately? The ZEROCONF WG has been working on completing WG drafts, 2 have gone through WG last call, 1 new one. We have discussed publishing a 'zeroconf host requirements' RFC (BCP?) which would list IETF standards track protocols which satisfy the protocol requirements. In this doc, for service discovery, we could list either SLPv2, mDNS with DNS SRV, or both - we have yet to have that debate. This *could* help to narrow the debilitating choices by saying "A conforming zeroconf host implements the following required/recommended/elective standards..." > Is querying over multicast for available services a bad thing? Definitely not! There are issues, though (scalability, administrability, compatible operation in networks without support for multicast, the service namespace, etc.) We have thought through these issues for SLPv2. I do not think we have done so for mDNS, but for link-local use it is probably OK anyway. mDNS based service discovery is appealing since it maps so well onto the use of administered SRV RR deployment in the wide-area (non-zeroconf) case. mDNS is simple (appletalk-like), while SLP has additional complexity (though not much). > I don't think so, but I ask myself whether this is DNS. I don't > think it is. It is a particular use of DNS formatted messages requiring hosts that support services respond in a new way. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 2 06:28:10 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04876 for ; Wed, 2 May 2001 06:28:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14utcQ-000F32-00 for namedroppers-data@psg.com; Wed, 02 May 2001 03:12:26 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14utcP-000F2g-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 03:12:26 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14utcO-0006FW-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 12:12:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200105021007.f42A7pL20190@zed.isi.edu> Subject: Re: AAAA/A6 thing To: nathanj@optimo.com.au (Nathan Jones) Date: Wed, 2 May 2001 03:07:51 -0700 (PDT) Cc: djb@cr.yp.to (D. J. Bernstein), namedroppers@ops.ietf.org In-Reply-To: <20010502111942.A1234@connect.com.au> from "Nathan Jones" at May 02, 2001 11:19:42 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % D. J. Bernstein wrote: % >Jim Bound writes: % >> But A6 will be shipped on the street and its a done deal. % > % >No, it is not. IPNG can terminate the A6/DNAME proposals right now. % % They can, but are unlikely to. We can spend thread after thread % debating whether these new developments should be used: IPv6, A6, DNAME, % AAAA, etc. Yet, the feeling I get is that many people would rather % implement them and then decide: whether the protocols should advance to % Draft Standards; whether further restrictions are required; whether % the negative aspects can be avoided with common sense, etc. people have implemented them and we are finding significant operational hurdles. Lack of tools to facilitate the use of these quite flexable new RR types only hinders their consideration. It really boils down to whcih tools are easier to construct, tools to ease renumbering w/ AAAA or to make A6 managable. % nathanj % % % % to unsubscribe send a message to namedroppers-request@ops.ietf.org with % the word 'unsubscribe' in a single line as the message text body. % -- --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 May 2 11:15:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14362 for ; Wed, 2 May 2001 11:15:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uxsI-0002AC-00 for namedroppers-data@psg.com; Wed, 02 May 2001 07:45:06 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uxsH-0002A6-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 07:45:05 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uxsG-0006ei-00 for namedroppers@ops.ietf.org; Wed, 02 May 2001 16:45:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Bill Manning cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <200105021007.f42A7pL20190@zed.isi.edu> References: <200105021007.f42A7pL20190@zed.isi.edu> Message-ID: <1010.988813429@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 02 May 2001 07:45:06 -0700 Content-Transfer-Encoding: 7bit Date: Wed, 2 May 2001 03:07:51 -0700 (PDT) From: Bill Manning Message-ID: <200105021007.f42A7pL20190@zed.isi.edu> | people have implemented them and we are finding significant | operational hurdles. There isn't sufficient deployment to have found hurdles in these yet. All it is possible to have found at the minute is teething troubles. | Lack of tools to facilitate the use | of these quite flexable new RR types only hinders their | consideration. for DNAME, yes, sure, but for A6 ??? A6 is easier to use than AAAA from a setup point of view (less chance of getting the number of bits wrong, and especially of doing it systematically). As a justification for A6, that's about as week as it is possible to get (so don't count it that way), but "lack of tools" isn't any kind of detriment either. What's more, once they do really start being used, whatever is missing will appear. (There's already a tool that will convert between different ways of writing IPv6 addresses - including ip6.int forms - extending that a couple more times should not be difficult). 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 May 3 18:54:58 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13048 for ; Thu, 3 May 2001 18:54:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14vRcf-0006k8-00 for namedroppers-data@psg.com; Thu, 03 May 2001 15:30:57 -0700 Received: from [63.112.78.79] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14vRcd-0006jH-00 for namedroppers@ops.ietf.org; Thu, 03 May 2001 15:30:56 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14vRcZ-0000Pw-00 for namedroppers@ops.ietf.org; Thu, 03 May 2001 18:30:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Ian Jackson Message-ID: <15089.38431.917191.847575@davenant.relativity.greenend.org.uk> Date: Thu, 3 May 2001 18:32:15 +0100 (BST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: References: <27764.988708929@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Schild writes ("Re: AAAA/A6 thing"): > one can still 'advocate' A6 0 <128bit> with the chain resolution > implemented. In my understanding we should suggest to use 128bit > records for _now_. If in the future, with more testing done and more > experience at hand, we have developed a good set of rules how to > chain A6 records in an unperilous manner, then we could start to > _use_ the chaining. That's a hopeless idea. We should not add features to standards without a clear idea of what they're good for. We should not put something in the spec and then tell people not to use it. If people shouldn't use it it shouldn't be in the spec. Furthermore, deploying A6 0 will not allow anyone to effectively work the bugs out of prefix-chasing resolvers, so if we were to specify A6 0 now but decided we wanted A6 >0 later we'd have to wait for new implementations anyway. Also, if the spec says A6 but MUST NOT require prefix chasing, many implementors may avoid implementing it altogether. Another way to look at it as a bait-and-switch: we are supposed to agree to A6 now, despite there being no good reason for it, because actually `we'll just use A6 0'. But, everyone still has to implement A6 >0 ! Ian. to unsubscribe send a message to 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 May 5 03:53:20 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11909 for ; Sat, 5 May 2001 03:53:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14vwLH-000IsP-00 for namedroppers-data@psg.com; Sat, 05 May 2001 00:19:03 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14vwLD-000IsA-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:18:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14vwLD-000Gmp-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:18:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 4 May 2001 04:07:49 -0000 Message-ID: <20010504040749.8861.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg Hudson writes: > How can NS glue work if BIND and djbdns completely discard > out-of-bailiwick records during a query? dns-01.ns.aol.com, for example, is in the .com servers' bailiwick, so we can follow a referral from the .com servers to the aol.com servers. See http://cr.yp.to/djbdns/notes.html for further background. As for your suggestion: Yes, we can eliminate the reliability problems caused by gluelessness, without introducing security problems, by (1) having the server provide the A for every NS and (2) having the cache save the A only in the context of that NS. This is (aside from the unnecessarily difficult parsing) functionally identical to putting addresses directly into NS records, which is my suggested fix. Applying the same fix to A6 produces AAAA. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat May 5 03:53:21 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11910 for ; Sat, 5 May 2001 03:53:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14vwKV-000Ipo-00 for namedroppers-data@psg.com; Sat, 05 May 2001 00:18:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14vwKS-000IpY-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:18:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14vwKS-000GlL-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:18:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 May 2001 23:41:09 -0400 (EDT) From: Jim Bound To: Ian Jackson Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <15089.38431.917191.847575@davenant.relativity.greenend.org.uk> Message-Id: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After much good discussion with Davkd Conrad and Paul Vixie, and Christian/Matts view of this I believe we must implement what we have regarding A6 specs from the implementation perspective. I will leave it to others to tell us as we develop this if the specs are to be altered. Assist with renumbering. Reduce routing tables. And make IPv6 more deployable. I will leave it to others to find consensus on this or against this. It needs to be implemented and used. /jim On Thu, 3 May 2001, Ian Jackson wrote: > Christian Schild writes ("Re: AAAA/A6 thing"): > > one can still 'advocate' A6 0 <128bit> with the chain resolution > > implemented. In my understanding we should suggest to use 128bit > > records for _now_. If in the future, with more testing done and more > > experience at hand, we have developed a good set of rules how to > > chain A6 records in an unperilous manner, then we could start to > > _use_ the chaining. > > That's a hopeless idea. > > We should not add features to standards without a clear idea of what > they're good for. We should not put something in the spec and then > tell people not to use it. If people shouldn't use it it shouldn't be > in the spec. > > Furthermore, deploying A6 0 will not allow anyone to effectively work > the bugs out of prefix-chasing resolvers, so if we were to specify > A6 0 now but decided we wanted A6 >0 later we'd have to wait for new > implementations anyway. Also, if the spec says A6 but MUST NOT > require prefix chasing, many implementors may avoid implementing it > altogether. > > Another way to look at it as a bait-and-switch: we are supposed to > agree to A6 now, despite there being no good reason for it, because > actually `we'll just use A6 0'. But, everyone still has to implement > A6 >0 ! > > Ian. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat May 5 04:00:10 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11985 for ; Sat, 5 May 2001 04:00:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14vwSD-000JK3-00 for namedroppers-data@psg.com; Sat, 05 May 2001 00:26:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14vwSB-000JJw-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:26:11 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14vwSB-000H0G-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:26:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <20010504040749.8861.qmail@cr.yp.to> References: <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> Date: Fri, 04 May 2001 13:45:57 +0700 Message-ID: <3347.988958757@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: 4 May 2001 04:07:49 -0000 From: "D. J. Bernstein" Message-ID: <20010504040749.8861.qmail@cr.yp.to> | dns-01.ns.aol.com, for example, is in the .com servers' bailiwick, This is gibberish - a best a rationalisation of broken behaviour. Since we know aol.com is delegated, dns-01.ns.aol.com belongs to either the aol.com zone (and hence the serves authoritative for that), or the ns.aol.zom zone (if it exists). No other servers on the planet have any special relationship with the name, and nothing that any of them might say about is to be trusted or believed any more than any of the others. There might be something about the data retrieved (such as a dnssec signature) which might make some responses able to be trusted more than others, but there's not a thing about the server that it comes from (aside from the authoritative servers for the zone that contains the name - and even then, only if you have some expectation it hasn't been spoofed) that would make an answer from one server any more trustworthy than any other. | so we can follow a referral from the .com servers to the aol.com servers. The .com servers might need glue A records for that name, that's true. So might the .net servers (and given they're the same thing it would be a bit hard for one of them to have the glue and not the other...). Even the .TO servers might need A records for those names as glue (though one might assume that is less likely - it isn't impossible). Glue isn't particularly authoritative (or believable) though. But it is necessary when no other information is available, and of course, usually works. | This is (aside from the unnecessarily difficult parsing) functionally | identical to putting addresses directly into NS records, which is my | suggested fix. It isn't even close to functionally identical. It would be if the requirement was that only the (glue) A record in the NS response could be used to "complete" the NS lookup - but no-one would ever make such a suggestion. If a resolver has a cached A record to match the name in the NS record, or even more, if it happens to be authoritative for that name, it should use the record it has, rather than random glue it receives. And that doesn't even begin to touch on the dnssec issues. We keep seeing this "server side indirection is equivalent and simpler" fiction over and over. It keeps being refuted. I guess you can just keep repeating it over and over, and hope we all get tired of refuting it. That won't make it any more true, even if there are no responses. If you really believe it - implement it in your server for the NS/A case. You have just claimed that other than the parsing issue (a NS/A pair is unquestionably more work to parse than an NS record containing an address would be) the NS/A combination in a response is functionally identical to the server side indirection you aspire to. Changing the specs the way you want (and all the other implementations) isn't going to happen any time soon no matter what was decided here now - so just ignore the parsing issue, and implement the server side indirection using the NS+A method. That is, have your servers *never* send an NS record in a response without the accompanying A record(s). That's actually easier (packet assembly/disassembly aside, which is really pretty trivial anyway) than it would be if you had to put the address into the NS record, as you don't have to deal with any of the dnssec or maintenance issues (depending on whether you were to do it by simply having the human maintain it - no dnssec issue particularly, but a maintenance nightmare, or by having the server go query and maintain the address from a configured server name (and perhaps associated glue A), which makes human maintenance much easier, but the dnssec issues much harder). But let's just leave that part of it aside for now. Come back to us after you have the server which never sends NS records without the associated A records deployed at a significant number of servers (including some which handle "public" domains containing 10K or more delegations). Then we will be able to evaluate whether server side indirection (in the simplest of possible scenarios) is able to work or not. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat May 5 04:06:54 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12082 for ; Sat, 5 May 2001 04:06:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14vwmV-000LAF-00 for namedroppers-data@psg.com; Sat, 05 May 2001 00:47:11 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14vwmU-000LA6-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:47:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14vwmU-000IED-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:47:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Ian Jackson Message-ID: <15090.46302.362557.596189@davenant.relativity.greenend.org.uk> Date: Fri, 4 May 2001 14:55:42 +0100 (BST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: References: <15089.38431.917191.847575@davenant.relativity.greenend.org.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Bound writes ("Re: AAAA/A6 thing"): > After much good discussion with Davkd Conrad and Paul Vixie, and > Christian/Matts view of this I believe we must implement what we have > regarding A6 specs from the implementation perspective. `After much good discussion with various people, I believe we must implement what we have regarding AAAA specs from the implementation perspective'. Just because something is Proposed Standard doesn't mean it should be implemented and/or advanced to Draft Standard. AAAA is Proposed Standard too, has more operational experience, is simpler, and can do everything that A6 can do just as well if not better. > I will leave it to others to tell us as we develop this if the > specs are to be altered. The A6 spec hasn't been finalised yet. It hasn't even been approved as a general way forward ! At the moment there are two proposals on the table. You can't say `I will leave it to others to [alter the spec]', because there is no specification that says you should do A6 rather than AAAA. > Assist with renumbering. Reduce routing tables. And make IPv6 more > deployable. I will leave it to others to find consensus on this or > against this. It needs to be implemented and used. I agree that we should assist with renumbering, reduce routing tables, and make IPv6 more deployable. But A6 does not help with this. In fact, requiring a complex protocol like A6 where AAAA is adequate will *hinder* IPv6 deployment. Just because A6 was introduced to help with renumbering DOES NOT mean that it is a good thing for that purpose. Nor does it mean that A6 opponents are somehow taking sides in some kind of ipngwg politics about renumbering. I couldn't care less about that politics, and if ipngwg say we need easy renumbering, fine. [1] But ipngwg should not define DNS protocols, dnsext should so so. In this case we have an overcomplex protocol which allegedly exists to meet some renumbering requirement, but which is in fact unnecessary. [1] Actually, as a layman when it comes to IPv6, renumbering, etc., I approve of making renumbering easy. But I'm no expert in that field, and I'll leave that to those who are. Likewise, DNS protocol and architecture should be done by the DNS experts. Ian. to unsubscribe send a message to 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 May 5 04:07:38 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12095 for ; Sat, 5 May 2001 04:07:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14vwd6-000K4J-00 for namedroppers-data@psg.com; Sat, 05 May 2001 00:37:28 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14vwd1-000K3x-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:37:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14vwd1-000Hwy-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:37:23 -0700 Date: 4 May 2001 08:51:36 -0000 Message-ID: <20010504085136.15388.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> <20010504040749.8861.qmail@cr.yp.to> <3347.988958757@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The root bailiwick includes all zones. The .com bailiwick includes all zones under .com. And so on. The power of the aol.com servers over www.aol.com exists only by grace of the .com servers. If the .com servers want to change the address of www.aol.com, they can. This power of the .com servers, in turn, exists only by grace of the root servers. These facts are built into the DNS architecture. We implementors didn't invent the DNS hierarchy or the concept of delegation. We give special powers to these central servers because we have no choice. Robert Elz writes: > If a resolver has a cached A record to match the name in the NS record, Sorry, but we can't cache records from outside the server's bailiwick. See http://cr.yp.to/djbdns/notes.html, under Poison, first example. > If you really believe it - implement it in your server for the NS/A case. I already did. The normal way to add an NS record, for example, is add-childns elysium.heaven.af.mil 1.2.3.144 (for the parent) add-ns elysium.heaven.af.mil 1.2.3.144 (for the child) The software automatically creates NS records pointing to in-bailiwick names, and A records for those names. Consequently caches receive glue. The only reason that I allow out-of-bailiwick NS records is for compatibility with certain parents (notably .com) that can't handle two A records pointing to the same IP address. Child servers and parent servers have to agree on NS names, thanks to a widespread BIND bug. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat May 5 04:14:09 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12139 for ; Sat, 5 May 2001 04:14:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14vwq1-000LOo-00 for namedroppers-data@psg.com; Sat, 05 May 2001 00:50:49 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14vwq0-000LOh-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:50:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14vwq0-000IKk-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 00:50:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Ian Jackson Message-ID: <15090.47374.934207.226065@davenant.relativity.greenend.org.uk> Date: Fri, 4 May 2001 15:13:34 +0100 (BST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <15090.46302.362557.596189@davenant.relativity.greenend.org.uk> References: <15089.38431.917191.847575@davenant.relativity.greenend.org.uk> <15090.46302.362557.596189@davenant.relativity.greenend.org.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to ask a procedural question. I'm not sure this is the right place, but this thread will do since this is where the substantive discussion is happening. I looked again at 2026 but it wasn't much help. I think we are now approaching the time to use whatever the formal procedure is to declare RFC2874 Historic. Presumably this will involve getting rough consensus in at least the dnsext wg [1], which I think we might be close to. [1] Some may argue that since 2874 was not really a dnsext document but an ipngwg one, it can't be withdrawn by dnsext. If this is true, then it was probably out of scope for ipng, or at the very least, if dnsext disagree with it then dnsext should be able to obsolete it and require ipngwg to state their requirements so that the protocol design can be done by dnsext. But how should this be initiated ? Should I write an I-D summarising the discussions, with the aim of it eventually becoming an Informational RFC which obsoletes 2874 ? (That would be an IESG standards action, I suppose, despite it being the publication of an Informational document.) Should we start work on polishing up AAAA (RFC1886) to move it to Draft Standard ? I'm not mistaken, am I, about there being at least two interoperable implementations of AAAA and ip6.int ? If we can't get consensus on AAAA going to Draft Standard, can we polish it up a bit and publish it once more as Proposed Standard but obsoleting 2874 ? Are some, all, or none of these the right way to do it ? Ian. to unsubscribe send a message to 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 May 5 04:22:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12217 for ; Sat, 5 May 2001 04:22:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14vx1g-000MDt-00 for namedroppers-data@psg.com; Sat, 05 May 2001 01:02:52 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14vx1f-000MDl-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 01:02:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14vx1e-000Igv-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 01:02:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200105050600.PAA01995@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA01995; Sat, 5 May 2001 15:00:28 +0900 Subject: Re: AAAA/A6 thing In-Reply-To: <20010502025329.12205.qmail@cr.yp.to> from "D. J. Bernstein" at "May 2, 2001 02:53:29 am" To: "D. J. Bernstein" Date: Sat, 5 May 2001 15:00:28 +0859 () CC: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan; First of all, it should be noted that you are not anymore arguing aginst the fact that A6 is as good as NS. > RFC 1034 does not correctly describe the behavior of real DNS caches, > such as BIND and dnscache. In particular: RFC1034 is a specification, not an implementation note. > * The RFC 1034 resolution algorithm loops and eventually fails when > glue A records expire before NS records. Real caches fall back to > the roots and succeed. An implementation may expire a cached NS RR when its glue expires, > * The RFC 1034 resolution algorithm saves information from servers > that are not authorized to provide the information. Real caches > reject the unauthorized information. That is broken part of your implementation. Glue or an additional A of an NS should be cached, though, for security purpose, the cache content may be used only as glue. > Yes, these are differences between RFC 1034 and reality. RFC 1034 is > clearly wrong in both cases: it creates a reliability problem in the > first case and a security problem in the second case. With correct implementation, there is no security problem in the second case. > Ohta is wrong when he blames the DNS cache for throwing away the glue > here. RFC 1034 _does not_ require glue in this situation. The reality is that people have been putting glue to some or all the NSes, even though it does not required by RFC 1034. Then, some of them learned that glue should be there only when it is necessary. My example (with proper glue added) is conformant to RFC 1034 and the real world practice. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat May 5 12:06:51 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16385 for ; Sat, 5 May 2001 12:06:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14w48X-0009br-00 for namedroppers-data@psg.com; Sat, 05 May 2001 08:38:25 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14w48W-0009bl-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 08:38:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14w48W-0005HQ-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 08:38:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <20010504085136.15388.qmail@cr.yp.to> References: <20010504085136.15388.qmail@cr.yp.to> <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> <20010504040749.8861.qmail@cr.yp.to> <3347.988958757@brandenburg.cs.mu.OZ.AU> Date: Sat, 05 May 2001 15:31:06 +0700 Message-ID: <1636.989051466@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: 4 May 2001 08:51:36 -0000 From: "D. J. Bernstein" Message-ID: <20010504085136.15388.qmail@cr.yp.to> | The root bailiwick includes all zones. The .com bailiwick includes all | zones under .com. And so on. Where does this bailiwick notion come from? I see no reference to that anywhere in the DNS specs, etc. This looks to be an invention that you believe rationalises your approach to glue, and your private theories as to how people should name their nameservers. | The power of the aol.com servers over www.aol.com exists only by grace | of the .com servers. That's true, to an extent. They created the aol.com name, and allow it to continue to exist. | If the .com servers want to change the address of | www.aol.com, they can. Only by removing the existing servers and substituting new ones. Otherwise the existing servers rule. They may sometimes be able to interject a bogus A record for a name - but only until clients discover the NS records, after that, queries for names inside aol.com will never go near the com servers (and any data received from the com servers, including the NS records, should be treated as untrustworthy glue, until verified from the authoritative servers) | Sorry, but we can't cache records from outside the server's bailiwick. You can, nothing prohibits it. But nor did anyone ask you to cache anything, I'm not about to require that. You misunderstood my intent. I didn't say anything about "if the resolver has cached an A record from some random source", I just said "if the resolver has a cached A record". The details of under what conditions it would make that cache entry weren't stated - for this purpose you can imagine them to be under however stringent conditions you desire (for example, it may have received the A record directly from the authoritative server for the name - it may in fact be that authoritative server). The point was that the NS name + name A case was not identical to NS address as in the former, the resolver that receives the response is free to ignore the A that accompanied the NS and use the A that it already has from a better source. Hence the two are not functionally equivalent, as claimed. | > If you really believe it - implement it in your server for the NS/A case. | I already did. The normal way to add an NS record, for example, is That isn't what I asked, I don't care what the local admin procedures are. What I asked was for your server to *never* send an NS record without the accompanying A record in the additional info section. Now you may very well do that too - I have no idea, perhaps you can point us at one or more servers that do lots of delegations of unrelated names (ie: one of the public registries somewhere in the world) so I can do some queries of the server and see for myself? | The software automatically creates NS records pointing to in-bailiwick | names, and A records for those names. Consequently caches receive glue. If that's true, as written, then great. And if you're sending that glue (in all cases) then I assume that your resolver will also use it whenever it is needed. If all that is the case, then I can't imagine why we're even discussing the issue. That is assuming "automatically creates NS records pointing to in-bailiwick names" is just saying that you won't allow people to create a child domain out of a domain that they don't control (eg: I don't get to delegate rc.yp.to as I don't run yp.to). But if I did, then I could make that delegation, and the server names could be anything (that has an A record) I want them to be. | The only reason that I allow out-of-bailiwick NS records is for | compatibility with certain parents (notably .com) that can't handle two | A records pointing to the same IP address. The com/net/.. registry service is truly broken there, stupid for reasons difficult to fathom. Never mind, that isn't the issue. But if you're saying that were it not for them you wouldn't allow me (were I to use your implementation) to use whatever names I like for the nameservers, then your implementation would be defective - and I'd be very surprised if you'd ever be able to get such an implementation deployed at any registry (where they have to list the NS records as the client specifies them - registries can't just go inventing new names out of the client's name space and usurping them for their own purposes). | Child servers and parent | servers have to agree on NS names, thanks to a widespread BIND bug. No comment on the bind bug - there have been very many of those over the years. But parent servers have to agree with child servers on NS names to get one of the basic assumptions of the DNS to work. That is, that it doesn't matter who you ask for information, the answers you get (if you get answers) will all be the same. Then, if there are no config errors, implementation errors, and leaving aside the race conditions that occur when information is changing (which the DNS deliberately leaves to be handled other ways) this is easy to achieve, provided there is only ever one source for the information. In this case, the authoritative source is the child's zone file - the parent is supposed to have an identical copy. Certainly in the zones in which I do delegations, I largely ignore the information that people fill in on the form - using what is there (aside from the domain name that specifies what is to have its delegation updated) only to locate the servers - as soon as I have found one of the new servers for the domain, the NS records that go in the parent domain come from that server (glue A records come from the authoritative servers for the names concerned). That is, provided all the servers to be listed agree on the contents of the domain (etc) but the rest of that validation isn't relevant here. I'd like to automate that - have the parent go and continually update its info from the child zones, but the practical issues with doing that are simply astoundingly difficult (for large zones, and especially those that need to deal with delegations to servers that tend not to be very reliable). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat May 5 12:11:41 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16435 for ; Sat, 5 May 2001 12:11:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14w4Dj-0009gW-00 for namedroppers-data@psg.com; Sat, 05 May 2001 08:43:47 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14w4Dh-0009gF-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 08:43:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14w4Dh-0005QG-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 08:43:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 5 May 2001 08:43:22 -0000 Message-ID: <20010505084322.6025.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010502025329.12205.qmail@cr.yp.to> <200105050600.PAA01995@necom830.hpcl.titech.ac.jp> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Masataka Ohta writes: > Glue or an additional A of an NS should be cached, though, for > security purpose, the cache content may be used only as glue. That is not what RFC 1034 says. It is, however, similar to the RFC 1034 algorithm in that it fails to stop the attack. See the Poison section of http://cr.yp.to/djbdns/notes.html. > An implementation may expire a cached NS RR when its glue expires, That isn't the RFC 1034 algorithm either. If you're going to claim that the IETF specifications are right and that all of us cache implementors are wrong, perhaps you should start by reading the specifications. > First of all, it should be noted that you are not anymore arguing > aginst the fact that A6 is as good as NS. On the contrary. http://cr.yp.to/djbdns/killa6.html explicitly covers both situations together, and then explains why A6 and DNAME are worse: DNS reliability problems Out-of-bailiwick pointers destroy DNS lookups in three ways: * Every out-of-bailiwick pointer means more queries and more opportunities for delay: packets are lost and have to be resent. The chance of finding an answer before client timeout decreases exponentially with the number of out-of-bailiwick pointers. * Caches have to limit the number of queries and the amount of memory that they dedicate to a single lookup. When these limits are exceeded, lookups fail. * As illustrated by the AOL suicide example, every out-of-bailiwick pointer is another opportunity to create a loop. When a loop appears, lookups fail. These problems are not new. Lookups occasionally fail because system administrators have used too many out-of-bailiwick NS records, for example. (I tell my users to select in-bailiwick server names. My software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default server names for fqdn. I also tell my users to avoid CNAME records.) What is new with A6 and DNAME is that out-of-bailiwick pointers are _encouraged_. System administrators are _encouraged_ to set up giant A6 chains and giant DNAME chains reflecting their corporate structures and network structures. The result will be a tremendous increase in the frequency of DNS lookup failures. I refuse to implement A6 and DNAME. I cannot bring myself to inflict such a rickety system on future Internet users. As of February 2001, nobody is relying on A6 or DNAME; I recommend that the A6 and DNAME proposals be terminated. http://cr.yp.to/djbdns/notes.html and http://cr.yp.to/djbdns/killa6.html provide all the background you need to understand these points. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat May 5 12:22:02 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16547 for ; Sat, 5 May 2001 12:22:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14w4Kg-0009pK-00 for namedroppers-data@psg.com; Sat, 05 May 2001 08:50:58 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14w4Kf-0009pB-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 08:50:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14w4Kf-0005ce-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 08:50:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <20010505084322.6025.qmail@cr.yp.to> References: <20010505084322.6025.qmail@cr.yp.to> <20010502025329.12205.qmail@cr.yp.to> <200105050600.PAA01995@necom830.hpcl.titech.ac.jp> Date: Sat, 05 May 2001 16:51:50 +0700 Message-ID: <4289.989056310@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: 5 May 2001 08:43:22 -0000 From: "D. J. Bernstein" Message-ID: <20010505084322.6025.qmail@cr.yp.to> | > An implementation may expire a cached NS RR when its glue expires, | | That isn't the RFC 1034 algorithm either. If you're going to claim that | the IETF specifications are right and that all of us cache implementors | are wrong, perhaps you should start by reading the specifications. Huh? That was about records in the cache, right? Implementations are free to expire any cache record any time they like, up to when the TTL expires. Bind used to (maybe still does) wind down the TTL quickly as more queries were made on a name - which sounds exactly backwards, but was very convenient if you noticed some bad data in a cache somewhere and wanted it to go away (just send a lot of queries for the name, the TTL would quickly drop to 0, and the record would be dropped). Of course, bind most likely should never have had the bad record to begin with, but that's beside the point - which is that how or when you expire records in your cache (provided it is done no later than when the TTL expires, or at least immediately before the next query which would have found the entry, which from outside looks the same) is your business - use whatever algorithm you feel best meets performance and reliability aims. | DNS reliability problems | | Out-of-bailiwick pointers destroy DNS lookups in three ways: | | * Every out-of-bailiwick pointer means more queries and more | opportunities for delay: packets are lost and have to be resent. | The chance of finding an answer before client timeout decreases | exponentially with the number of out-of-bailiwick pointers. True. Then we have a balancing act between what is more convenient for me to maintain, and what is going to work well (enough) in practice. There's nothing very unusual about that kind of cost/benefit trade off. The important part is that it is for me, as a zone administrator, to make that decision. And that is the same for NS records and A6 records. | * Caches have to limit the number of queries and the amount of | memory that they dedicate to a single lookup. When these limits | are exceeded, lookups fail. Also true. And that is certainly something that I need to take into account when I am deciding how I will set up my zone. | * As illustrated by the AOL suicide example, every | out-of-bailiwick pointer is another opportunity to create a | loop. When a loop appears, lookups fail. Nonsense. With proper glue, not being improperly ignored, the aol example is just fine. | These problems are not new. Lookups occasionally fail because system | administrators have used too many out-of-bailiwick NS records, for | example. Yes, there can be problems - it is possible for people to break their setups. | (I tell my users to select in-bailiwick server names. My | software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default | server names for fqdn. I also tell my users to avoid CNAME records.) That's fine - if I were setting up my domain(s) now for the first time, I'd be naming my nameservers something like that (I might just use ns1 ns2 instead of a.ns - just to save one byte in each name in the packets - but that's so trivial as to be close to irrelevant). That's for when I am delegating my domain to nameservers I run myself. On the other hand, if I were an ISP with 5000 clients domains delegated to me, then the very last thing I am going to be doing is creating 5000 different names for each of my servers, and then having the absolute maintenance nightmare any time I want to change one of their IP addresses. CNAMES are often best avoided, but when used in the simple case "a CNAME b" (where neither "a" nor "b" contains any dots) they work just fine, and doing this can make maintenance easier. But by all means, continue to give operational advice to people on what works well, and why, and what the costs are both ways. Do that for A6 as well as NS records and CNAMES. | What is new with A6 and DNAME is that out-of-bailiwick pointers are | _encouraged_. System administrators are _encouraged_ to set up giant | A6 chains and giant DNAME chains reflecting their corporate Nonsense - we don't yet know what is to be encouraged. What is in the doc is just some possibilities on how they might be used. Until we get operational experience we don't know what to encourage, and what to discourage. But you would certainly be free to give whatever you consider to be good advice to your users as to how to use the things. By all means tell people that only "A6 0" will ever be reliable enough to use, and that they should only ever use A6 in that format. That may even turn out to be correct, though I doubt it. | I refuse to implement A6 and DNAME. That's fine, except ... | I recommend that the A6 and DNAME proposals be terminated. You will therefore certainly be ignored now. What is relevant at this point is operational experience, how easily they can be implemented, and what effects they have on operations when deployed. If you're not even trying to implement them, then you cannot possibly have anything relevant to say on either issue. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat May 5 12:23:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16558 for ; Sat, 5 May 2001 12:22:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14w4VS-000A6d-00 for namedroppers-data@psg.com; Sat, 05 May 2001 09:02:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14w4VR-000A6Q-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 09:02:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14w4VR-0005wF-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 09:02:05 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bill Woodcock Cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns References: Message-Id: Date: Sat, 05 May 2001 08:16:52 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I think we'd all agree that DHCP isn't the way to find a laser printer i suspect the dhcp wg folk would not agree with thats tatement. > Given that DNS is the appropriate means of finding resources and i thought it was the means to map identifiers to addresses. 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 Sat May 5 12:26:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16582 for ; Sat, 5 May 2001 12:26:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14w4Vl-000A6r-00 for namedroppers-data@psg.com; Sat, 05 May 2001 09:02:25 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14w4Vk-000A6l-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 09:02:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14w4Vk-0005ws-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 09:02:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105051521.LAA15810@egyptian-gods.MIT.EDU> To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Your message of "04 May 2001 04:07:49 -0000." <20010504040749.8861.qmail@cr.yp.to> Date: Sat, 05 May 2001 11:21:18 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm finding it a little hard to follow parts of this argument for lack of knowledge of BIND's behavior with regard to out-of-bailiwick records. For instance, kre has argued that the bailiwick should not give special status to a record, but I believe I've seen Dan claim that BIND applies bailiwick-related logic to prevent malicious cache poisoning. Is kre arguing against BIND behavior as well as djbdns behavior? Anyway: > As for your suggestion: Yes, we can eliminate the reliability > problems caused by gluelessness, without introducing security > problems, by > (1) having the server provide the A for every NS and > (2) having the cache save the A only in the context of that NS. > This is (aside from the unnecessarily difficult parsing) > functionally identical to putting addresses directly into NS > records, which is my suggested fix. Applying the same fix to A6 > produces AAAA. But with that standard, you lose the flexibility of not providing glue records, or (in the case of A6) providing partial glue. For instance, a resolver providing an A6 record with a non-zero prefix could provide glue NS and A6 (with 0-length prefix) records for the name server which knows the prefix, but not the prefix itself, if the prefix changes frequently but the relevant name server addresses do not. I'm not sure whether that's a compelling argument for A6. It does seem, though, that (a) DNS is pretty much built on client-side indirection, even if server-side indirection would have been more robust; (b) A6 provides some kind of quick renumbering support consistent with the client-side indirection model; (c) if caches would accept out-of-bailiwick glue records in the context of the query they came from, then glue could be added to solve reliability problems as they crop up. In a different message on the same topic, Dan wrote: > Robert Elz writes: >> If a resolver has a cached A record to match the name in the NS >> record, > Sorry, but we can't cache records from outside the server's > bailiwick. See http://cr.yp.to/djbdns/notes.html, under Poison, > first example. I believe you misread. kre was saying that a cache might just happen to be holding a cached authoritative record matching the glue record, and could use the cached record instead of the glue record, so that a query might succeed (by chance) even if there is stale glue involved. Doesn't seem like a very big win. to unsubscribe send a message to 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 May 5 16:57:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17973 for ; Sat, 5 May 2001 16:57:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14w8nu-000FM3-00 for namedroppers-data@psg.com; Sat, 05 May 2001 13:37:26 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14w8nt-000FLx-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 13:37:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14w8nt-000DTW-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 13:37:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3AF43B95.28FD5FAA@ehsco.com> Date: Sat, 05 May 2001 10:42:45 -0700 From: "Eric A. Hall" CC: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <15089.38431.917191.847575@davenant.relativity.greenend.org.uk> <15090.46302.362557.596189@davenant.relativity.greenend.org.uk> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Can somebody clarify? I was under the impression that AAAA had already been deprecated. I'm looking through my archives and can't seem to find the message that says this explicitly (so I may be mistaken, which is why I seek clarification). The best I can find is the DNSEXT meeting notes from IETF 50: | Subject: draft IETF-50 DNSEXT meeting notes | Date: Mon, 9 Apr 2001 11:08:57 -0400 (EDT) | From: Olafur Gudmundsson | To: DNSEXT mailing list | IPv6 DNS transition and deployment: Rob Austein | - Problems: two complete IPv6 DNS Address record solutions | - One standard, other deprecated | - Known implementations using deprecated one | - Becoming issue for IPv6 deployment | - Need to have transition plan to get from AAAA to A6. Will require | protocol things, like synthesizing AAAA records. | - Overview of A6 transition plan | - Use A6 in zone files | - Anything that needs AAAA is assumed to be stub resolvers and we | synthesize it | - No AAAA in root or TLD zones Also, wasn't ipv6.int moved to ipv6.arpa? -- 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 Sat May 5 16:57:09 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17974 for ; Sat, 5 May 2001 16:57:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14w8pG-000FOZ-00 for namedroppers-data@psg.com; Sat, 05 May 2001 13:38:50 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14w8pG-000FOT-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 13:38:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14w8pG-000DVu-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 13:38:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Richard Barr Hibbs" To: "Namedroppers" Subject: RE: dns server discovery using mdns Date: Sat, 5 May 2001 11:19:29 -0700 Message-ID: In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I speak just for myself, not the entire DHC Working Group, but I do not support the generic use of DHCP to locate services and resources on the network that are not specific to configuring the DHCP client for communicating with other network elements. Part of my reason is because of the scalability issue, and the general difficulty in an administrator knowing all the resources that might be needed to satisfy client needs. While DHCP can definitely be used to pass a great deal of information from a server to a client, and does provide a mechanism for defining and using vendor-specific options, that still puts too much of a burden on the administrator in my opinion. For example, the vendor-specific options (129-254) could incorporate three printer choices for the client: high-speed, medium resolution letter-size paper for drafts, medium-speed, high-resolution color printer with legal and letter-size paper for most "final" printing, and a high-speed, high-resolution color printer with collator and stapler, multiple paper sizes (8-1/2 x 11 letterhead, 8-1/2 x 11 second sheet, 8-1/2 x 14, 11 x 17) plus envelopes. Consider for a moment, however, what an administrator must do to make this workable. First, she would need a complete inventory of shared printers matched to the subnets under her purview: unless each was the same manufacturer and model, there would likely be some individual configuration information that would be required to be inventoried as well. Then she needs a DHCP client that understands the options chosen to pass configuration data, and that client must be capable of setting all printer configuration parameters in the client system. That probably requires either a custom DHCP client and server, or an extremely knowledgeable administrator with all the resources to gather, maintain, and manage the printers, DHCP clients, and peculiarities of the client's operating system. Seems to me that this is what Services Location was intended to solve. Maybe Erik will wade in here with an opinion? While DNS could be part of the solution to locating resources (for example, mapping a name such as "hp870cse.192.168.244" to the actual IP address of the H-P 870Cse DeskJet printer for the 192.168.244.x subnet) all of the other configuration information necessary to make printing (to use just one example) successful is not handled very well using DNS (again, scaling and administration more than the lack of capability for responding to a query.) --Barr Hibbs UltraDNS Corporation > -----Original Message----- > From: Randy Bush > Sent: Saturday, May 05, 2001 8:17 AM > To: Bill Woodcock > Cc: namedroppers@psg.com > >>> I think we'd all agree that DHCP isn't the way to find a laser printer > > I suspect the dhcp wg folk would not agree with that statement. > >>> Given that DNS is the appropriate means of finding resources > > and i thought it was the means to map identifiers to addresses. > to unsubscribe send a message to 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 May 6 02:30:25 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06801 for ; Sun, 6 May 2001 02:30:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wHXk-000PxV-00 for namedroppers-data@psg.com; Sat, 05 May 2001 22:57:20 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wHXj-000PxP-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 22:57:19 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wHXj-0003BY-00 for namedroppers@ops.ietf.org; Sat, 05 May 2001 22:57:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Greg Hudson cc: "D. J. Bernstein" , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <200105051521.LAA15810@egyptian-gods.MIT.EDU> References: <200105051521.LAA15810@egyptian-gods.MIT.EDU> Date: Sun, 06 May 2001 12:55:04 +0700 Message-ID: <1130.989128504@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Sat, 05 May 2001 11:21:18 -0400 From: Greg Hudson Message-ID: <200105051521.LAA15810@egyptian-gods.MIT.EDU> | For instance, kre has argued that the bailiwick should not | give special status to a record, but I believe I've seen Dan claim | that BIND applies bailiwick-related logic to prevent malicious cache | poisoning. Is kre arguing against BIND behavior as well as djbdns | behavior? Last time I investigated anyway, BIND drops glue A records from zone transfers, where the glue isn't within the domain delegated (which isn't the same as djb's "bailiwick" definition). And yes, that's broken. I don't think that BIND ignores glue A records in NS responses though, whatever the name of the server concerned (which isn't to say that it necessarily caches them, or that it necessarily uses them, just that they will be used if there isn't better info available). | It does | seem, though, that (a) DNS is pretty much built on client-side | indirection, even if server-side indirection would have been more | robust; Yes, it is - but no, it wouldn't, it would be a maintenance nightmare. That is, if one assumes that the people running things always get it right, but that the software is possibly broken, then server side indirection would be a win. On the other hand, if you assume that the humans get things wrong more often than the software implementors do, then client side indirection wins more often (but yes, it is still possible for the humans to screw that one too - they just need to try harder). | (c) if caches would | accept out-of-bailiwick glue records in the context of the query they | came from, then glue could be added to solve reliability problems as | they crop up. Yes, though you don't mean caches, you mean resolvers. There's no requirement that this data be cached (as with all caches, one must weigh the benefits against the costs of adding an entry). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun May 6 09:39:54 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10286 for ; Sun, 6 May 2001 09:39:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wODX-0009IS-00 for namedroppers-data@psg.com; Sun, 06 May 2001 06:04:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wODX-0009IM-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 06:04:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wODX-000FJT-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 06:04:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 6 May 2001 04:04:08 -0700 (PDT) From: Sam Trenholme To: Robert Elz cc: "D. J. Bernstein" , , Subject: Re: AAAA/A6 thing In-Reply-To: <4289.989056310@brandenburg.cs.mu.OZ.AU> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > (I might just use ns1 ns2 instead of a.ns - just to save one byte in > each name in the packets - but that's so trivial as to be close to > irrelevant). Minor point: a.ns.tld and b.ns.tld take up a total of 11 bytes when compressed. ns1.tld and ns2.tld take up 12 bytes when compressed. The savings gets better as you add more name servers, since each instance of c.ns.tld, d.ns.tld, and so on take up four bytes, but ns3.tld, ns4.tld and so on take up six bytes a piece. - Sam to unsubscribe send a message to 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 May 6 10:49:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11220 for ; Sun, 6 May 2001 10:49:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wPZH-000BBh-00 for namedroppers-data@psg.com; Sun, 06 May 2001 07:31:27 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wPZH-000BBb-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 07:31:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wPZH-000HkE-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 07:31:27 -0700 From: Randy Bush Message-Id: <200105061428.f46ESqH03810@zed.isi.edu> Subject: Re: AAAA/A6 thing To: ehall@ehsco.com (Eric A. Hall) Date: Sun, 6 May 2001 07:28:52 -0700 (PDT) Cc: namedroppers@ops.ietf.org In-Reply-To: <3AF43B95.28FD5FAA@ehsco.com> from "Eric A. Hall" at May 05, 2001 10:42:45 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The A6 RFC depricates AAAA, however, the authors did this w/o any A6 support being available. Some is starting to emerge but it is very slow. AAAA clearly has the edge in the installed base, since it has been supported since Bind 4.9.6. The same folks who depricated AAAA w/o any alternative also picked a new place to anchor the delegations with out ensuring it existed. After repeated requests to the IANA to make the delegation, it still has not occured. No IP6.ARPA. % % Can somebody clarify? I was under the impression that AAAA had already % been deprecated. I'm looking through my archives and can't seem to find % the message that says this explicitly (so I may be mistaken, which is why % I seek clarification). The best I can find is the DNSEXT meeting notes % from IETF 50: % % | Subject: draft IETF-50 DNSEXT meeting notes % | Date: Mon, 9 Apr 2001 11:08:57 -0400 (EDT) % | From: Olafur Gudmundsson % | To: DNSEXT mailing list % % | IPv6 DNS transition and deployment: Rob Austein % | - Problems: two complete IPv6 DNS Address record solutions % | - One standard, other deprecated % | - Known implementations using deprecated one % | - Becoming issue for IPv6 deployment % % | - Need to have transition plan to get from AAAA to A6. Will require % | protocol things, like synthesizing AAAA records. % % | - Overview of A6 transition plan % | - Use A6 in zone files % | - Anything that needs AAAA is assumed to be stub resolvers and we % | synthesize it % | - No AAAA in root or TLD zones % % Also, wasn't ipv6.int moved to ipv6.arpa? % % -- % 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. % -- --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 May 6 11:26:07 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11657 for ; Sun, 6 May 2001 11:26:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wQ8n-000Bzh-00 for namedroppers-data@psg.com; Sun, 06 May 2001 08:08:09 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wQ8m-000Bzb-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 08:08:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wQ8m-000Imn-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 08:08:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200105061428.f46ESqH03810@zed.isi.edu> Subject: Re: AAAA/A6 thing To: ehall@ehsco.com (Eric A. Hall) Date: Sun, 6 May 2001 07:28:52 -0700 (PDT) Cc: namedroppers@ops.ietf.org In-Reply-To: <3AF43B95.28FD5FAA@ehsco.com> from "Eric A. Hall" at May 05, 2001 10:42:45 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ an error in elisp here caused a previous posting of this message as if it came From: me. it did not. my apologies. - rb ] The A6 RFC depricates AAAA, however, the authors did this w/o any A6 support being available. Some is starting to emerge but it is very slow. AAAA clearly has the edge in the installed base, since it has been supported since Bind 4.9.6. The same folks who depricated AAAA w/o any alternative also picked a new place to anchor the delegations with out ensuring it existed. After repeated requests to the IANA to make the delegation, it still has not occured. No IP6.ARPA. % % Can somebody clarify? I was under the impression that AAAA had already % been deprecated. I'm looking through my archives and can't seem to find % the message that says this explicitly (so I may be mistaken, which is why % I seek clarification). The best I can find is the DNSEXT meeting notes % from IETF 50: % % | Subject: draft IETF-50 DNSEXT meeting notes % | Date: Mon, 9 Apr 2001 11:08:57 -0400 (EDT) % | From: Olafur Gudmundsson % | To: DNSEXT mailing list % % | IPv6 DNS transition and deployment: Rob Austein % | - Problems: two complete IPv6 DNS Address record solutions % | - One standard, other deprecated % | - Known implementations using deprecated one % | - Becoming issue for IPv6 deployment % % | - Need to have transition plan to get from AAAA to A6. Will require % | protocol things, like synthesizing AAAA records. % % | - Overview of A6 transition plan % | - Use A6 in zone files % | - Anything that needs AAAA is assumed to be stub resolvers and we % | synthesize it % | - No AAAA in root or TLD zones % % Also, wasn't ipv6.int moved to ipv6.arpa? % % -- % 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. % -- --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 May 6 12:16:56 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11978 for ; Sun, 6 May 2001 12:16:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wQyp-000DCZ-00 for namedroppers-data@psg.com; Sun, 06 May 2001 09:01:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wQyp-000DCT-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 09:01:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wQyp-000KIf-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 09:01:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200105061551.AAA04950@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA04950; Mon, 7 May 2001 00:51:25 +0900 Subject: Re: AAAA/A6 thing In-Reply-To: <20010505084322.6025.qmail@cr.yp.to> from "D. J. Bernstein" at "May 5, 2001 08:43:22 am" To: "D. J. Bernstein" Date: Mon, 7 May 2001 00:51:24 +0859 () CC: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan; > Masataka Ohta writes: > > Glue or an additional A of an NS should be cached, though, for > > security purpose, the cache content may be used only as glue. > > That is not what RFC 1034 says. RFC 1034 is a protocol specification, not an implementation note. It does not specify details of cache management. Still, implementations which can not handle cache properly are broken. > It is, however, similar to the RFC 1034 > algorithm in that it fails to stop the attack. See the Poison section of > http://cr.yp.to/djbdns/notes.html. You have been told it several times already. : From mohta Sun Mar 18 07:53:47 2001 : Subject: Re: Extra records in zone transfers : To: djb@cr.yp.to (D. J. Bernstein) : Date: Sun, 18 Mar 1 7:53:47 JST : Cc: namedroppers@ops.ietf.org : Glue information is local to a zone (actually, local to a referral point : that same name server may have different A records referral by referral, : though such information can not be represented by standard zone file or : zone transfer format), that same name server may have different A : records zone by zone. : : That is the reality of the database and the behaviour is not forbidden : by the specification. : : Thus, glue information may be chached not in global cache but in : cache local to a zone (or, better, local to a referral point). : : Then, different A records from different referral points can be cached : independently and replies can choose appropriate chache. : : Note that your server is wrongly implemented in a way not directly : related to AXFR nor IXFR that, if you want to continue this thread : on correct chaching, you should better use a subject like "multiple : chache". : Subject: Re: AAAA/A6 thing : To: "D. J. Bernstein" : Date: Mon, 30 Apr 2001 18:16:21 +0859 () : CC: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com : > Legitimate standards organizations never have any trouble showing people : > the justifications for their decisions. : : As we already discussed with AXFR, you must put glue information in : a separate cache local to a zone (or, better, a referral). RFC 1034 : does not prohibit to do so. : : I thought you had already fixed your broken implementation. > > First of all, it should be noted that you are not anymore arguing > > aginst the fact that A6 is as good as NS. > > On the contrary. http://cr.yp.to/djbdns/killa6.html explicitly covers > both situations together, and then explains why A6 and DNAME are worse: I think you who ignores all the imformation in mails above are not expecting me go all the way to look at your home page. > DNS reliability problems There is none. > Out-of-bailiwick pointers destroy DNS lookups in three ways: > > * Every out-of-bailiwick pointer means more queries and more > opportunities for delay: packets are lost and have to be resent. > The chance of finding an answer before client timeout decreases > exponentially with the number of out-of-bailiwick pointers. > > * Caches have to limit the number of queries and the amount of > memory that they dedicate to a single lookup. When these limits > are exceeded, lookups fail. > > * As illustrated by the AOL suicide example, every > out-of-bailiwick pointer is another opportunity to create a > loop. When a loop appears, lookups fail. It is certainly stupid that people worrying about using up v6 address space hegitated to specify a few fixed address allocation boudaries in A6. However, the stupidity is covered by DNS impelemantations dedicating limited amount of resource to a single look up actual allocation policy considering the DNS implementations. > I refuse to implement A6 and DNAME. For DNAME, that's fine. For A6, your statement is unfounded and you are refusing to implement DNS. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun May 6 13:49:56 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12404 for ; Sun, 6 May 2001 13:49:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wSNm-000FFc-00 for namedroppers-data@psg.com; Sun, 06 May 2001 10:31:46 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wSNl-000FFW-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 10:31:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wSNl-0001lK-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 10:31:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105061719.KAA98139@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Message from Robert Elz of "Sun, 06 May 2001 12:55:04 +0700." <1130.989128504@brandenburg.cs.mu.OZ.AU> Date: Sun, 06 May 2001 10:19:58 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Last time I investigated anyway, BIND drops glue A records from zone > transfers, where the glue isn't within the domain delegated (which isn't > the same as djb's "bailiwick" definition). And yes, that's broken. BIND4 and BIND8 lacked the data structure capability to store out-of-zone glue and use it constructively (which means: pass it on in outbound zone transfers, and include it as additional data for authority sections, and use it when following downward delegations.) BIND9 was built with this kind of capability in mind, though I'm not sure as I type this whether that latent capability has been instantiated or tested. In Ohta's case where the only AOL.COM servers are inside AOL.NET and vice versa, the _appropriate_ place for the glue is: below the bottoms of the NET and COM zones. The AOL.COM zone server should not accept tranfers of AOL.NET RR's, but rather, should seek "upward" when these are needed. This raises an unfortunate chicken-and-egg problem to which all known solutions are as bad as the problem they address. Ick. So, "don't do that." > I don't think that BIND ignores glue A records in NS responses though, > whatever the name of the server concerned (which isn't to say that it > necessarily caches them, or that it necessarily uses them, just that > they will be used if there isn't better info available). Out-of-zone glue is nonauthoritative and likely (from my own operational experiences) to be less accurate (more "stale") than real zone data. to unsubscribe send a message to 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 May 6 13:51:52 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12432 for ; Sun, 6 May 2001 13:51:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wSWq-000FTR-00 for namedroppers-data@psg.com; Sun, 06 May 2001 10:41:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wSWq-000FTL-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 10:41:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wSWq-000224-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 10:41:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105061736.KAA98388@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Message from Randy Bush of "Sun, 06 May 2001 07:28:52 PDT." <200105061428.f46ESqH03810@zed.isi.edu> Date: Sun, 06 May 2001 10:36:46 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The A6 RFC depricates AAAA, however, the authors did this w/o any A6 > support being available. Some is starting to emerge but it is very > slow. AAAA clearly has the edge in the installed base, since it has > been supported since Bind 4.9.6. Boy oh boy is *my* face red. I took RFC 1886 at face value when it said "Standards Track". I remember the DNSIND meeting where Sue presented it and there were a couple of area directors there and the question was "is nybbles the best we can do?" and everybody stared at everybody else and the consensus seemed to be "uh, yeah." I'm not sorry that I implemented RFC 1886, since much operational experience has been gathered as a result. However, I am very sorry that I took a full decade to understand how IETF politics work and to realize that NOTHING is EVER over, even AFTER the fat lady has sung her heart out. > The same folks who depricated AAAA w/o any alternative ... I dunno man, A6 looks like a proposed alternative and it was part of the document where AAAA was deprecated. to unsubscribe send a message to 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 May 6 15:12:51 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12860 for ; Sun, 6 May 2001 15:12:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wTcL-000HHE-00 for namedroppers-data@psg.com; Sun, 06 May 2001 11:50:53 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wTcK-000HH8-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 11:50:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wTcK-0004CF-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 11:50:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Paul A Vixie Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <200105061428.f46ESqH03810@zed.isi.edu> <200105061736.KAA98388@redpaul.mfnx.net> Message-Id: Date: Sun, 06 May 2001 11:44:51 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Boy oh boy is *my* face red. I took RFC 1886 at face value when it said > "Standards Track". I remember the DNSIND meeting where Sue presented it > and there were a couple of area directors there and the question was "is > nybbles the best we can do?" and everybody stared at everybody else and > the consensus seemed to be "uh, yeah." > > I'm not sorry that I implemented RFC 1886, since much operational > experience has been gathered as a result. However, I am very sorry that > I took a full decade to understand how IETF politics work and to realize > that NOTHING is EVER over, even AFTER the fat lady has sung her heart out. what you ran up against was well-dcumented process, not politics [0]. a meeting does not define wg consensus, and a *proposed* standard is just that, i.e. not a standard. specifically, rfc 2418, 3.2. Session venue Each working group will determine the balance of email and face-to- face sessions that is appropriate for achieving its milestones. Electronic mail permits the widest participation; face-to-face meetings often permit better focus and therefore can be more efficient for reaching a consensus among a core of the working group participants. In determining the balance, the WG must ensure that its process does not serve to exclude contribution by email-only participants. Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list. rfc2026, 4.1.1 Proposed Standard ... A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. [ 1602-3, which the above two obsoleted, had similar text ] otoh, the v6/dns (and dnssec) community has often wavered in making our vision and corresponding tactics clear. and this has not always been kind to implementors. thanks for hanging in. randy --- [0] - though i define 'politics' as what happens in life when more than one person is involved. i.e. real life. to unsubscribe send a message to 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 May 6 16:20:30 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13480 for ; Sun, 6 May 2001 16:20:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wUkI-000J8N-00 for namedroppers-data@psg.com; Sun, 06 May 2001 13:03:10 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wUkI-000J8H-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 13:03:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wUkI-0006FE-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 13:03:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200105061927.EAA05371@necom830.hpcl.titech.ac.jp> Subject: Re: AAAA/A6 thing In-Reply-To: <200105061719.KAA98139@redpaul.mfnx.net> from Paul A Vixie at "May 6, 2001 10:19:58 am" To: Paul A Vixie Date: Mon, 7 May 2001 04:26:50 +0859 () CC: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul; > In Ohta's case where the only AOL.COM servers are inside AOL.NET and vice > versa, the _appropriate_ place for the glue is: below the bottoms of the > NET and COM zones. The AOL.COM zone server should not accept tranfers of > AOL.NET RR's, but rather, should seek "upward" when these are needed. This > raises an unfortunate chicken-and-egg problem to which all known solutions > are as bad as the problem they address. Ick. So, "don't do that." You still don't understand what the problem is. > Out-of-zone glue is nonauthoritative and likely (from my own operational > experiences) to be less accurate (more "stale") than real zone data. For seurity, it is meaningless to say "less accurate". You are adding more and more patches to your implemenation to make it give more and more accurate answer. However, something is secure or not secure. A concept of "weak security" may confuse you, but security is security. Glue or additional A for an NS is secure as glue for the referral. It may be cached as glue for the referral but is not secure for other purposes. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon May 7 02:54:11 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04091 for ; Mon, 7 May 2001 02:54:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14weWH-00086h-00 for namedroppers-data@psg.com; Sun, 06 May 2001 23:29:21 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14weWG-00086b-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 23:29:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14weWG-000NvP-00 for namedroppers@ops.ietf.org; Sun, 06 May 2001 23:29:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <200105061428.f46ESqH03810@zed.isi.edu> <200105061736.KAA98388@redpaul.mfnx.net> From: Paul Vixie Date: 06 May 2001 23:26:15 -0700 In-Reply-To: Randy Bush's message of "6 May 2001 12:05:26 -0700" Message-ID: Lines: 49 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > what you ran up against was well-dcumented process, not politics [0]. a > meeting does not define wg consensus, and a *proposed* standard is just > that, i.e. not a standard. if, in 1995, potential ipv6 vendors and users had been told that AAAA was just the current thinking and that it could well be deprecated before ipv6 reached any kind of wide use, the reaction would've been "oh, a research toy -- sounds like fun, we'll check in on you again in a few years to see if you're closer to implementation yet." instead, the words "standards track" were used. no matter that rfc1602 says, the Intended Political Impact of those words is to fool, um, i mean "convince" various people into thinking that the protocol is worth their trouble to implement, productize, or deploy. the Full Truth of this axiom was brought to me by a very interesting messenger. i wasn't convinced by the "must use RSA" then "must use DSA" conflicting mandates out of the dnssec crowd. (angry, yes; despondant, no). rather, it was the day someone crept into an ipngwg meeting and proposed that the packet format be changed to put the destination address first, so as to make cut-through routing happen 6 octets sooner in the frame. oh, sure, the proposal was understandable -- there are ivory tower wannabes in every crowd and ietf has at least its share. no. the Full Truth which led to my current Despondance regarding ietf Politics came from the fact that this was *debated*. *seriously* *debated*. on *technical* grounds. OUCH! after that, A6 vs AAAA is no big deal. for that matter, after everything we've all seen, switching back to AAAA and announcing that ipv6 will have no quick renumbering features after all, would be Merely Par For The Course. the above defense, that the standard was merely proposed, simply seeks to pave over the raw unpleasant truth that it will NEVER be Truly Safe to implement, productize, or deploy dnssec (are we using NXT, or NO, or neither? and is it still DSA this week, or are we back to RSA, or is it something else now?) or ipv6 (what WILL the packet format be, finally (if that word even makes any sense), and will it end up, after 10 years of what will have been transformed into well intentioned lies, giving operators the choice of either carrying 2^64 routes in the core, or insisting that customers be locked in?), or anything else. to be Truly Safe, implementors must simply implement *everything* -- just in case this is the version that the ietf decides to stop dicking with, and operators must make full plans to deploy *anything* -- just in case. > otoh, the v6/dns (and dnssec) community has often wavered in making our > vision and corresponding tactics clear. and this has not always been > kind to implementors. thanks for hanging in. as far as i know, ietf is still the only game in town. there is hope, though. to unsubscribe send a message to 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 May 7 10:49:53 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13419 for ; Mon, 7 May 2001 10:49:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wlpT-000JoA-00 for namedroppers-data@psg.com; Mon, 07 May 2001 07:17:39 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wlpT-000Jo4-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 07:17:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wlpT-000Bu4-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 07:17:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200105070910.f479A3R05050@zed.isi.edu> Subject: Re: AAAA/A6 thing To: vixie@mfnx.net (Paul A Vixie) Date: Mon, 7 May 2001 02:09:57 -0700 (PDT) Cc: namedroppers@ops.ietf.org In-Reply-To: <200105061736.KAA98388@redpaul.mfnx.net> from "Paul A Vixie" at May 06, 2001 10:36:46 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % > The A6 RFC depricates AAAA, however, the authors did this w/o any A6 % > support being available. Some is starting to emerge but it is very % > slow. AAAA clearly has the edge in the installed base, since it has % > been supported since Bind 4.9.6. % % Boy oh boy is *my* face red. I took RFC 1886 at face value when it said % "Standards Track". I remember the DNSIND meeting where Sue presented it % and there were a couple of area directors there and the question was "is % nybbles the best we can do?" and everybody stared at everybody else and % the consensus seemed to be "uh, yeah." % % I'm not sorry that I implemented RFC 1886, since much operational % experience has been gathered as a result. However, I am very sorry that % I took a full decade to understand how IETF politics work and to realize % that NOTHING is EVER over, even AFTER the fat lady has sung her heart out. % % > The same folks who depricated AAAA w/o any alternative ... % % I dunno man, A6 looks like a proposed alternative and it was part of the % document where AAAA was deprecated. This from some private email. Names are elided. My comments are inset. ---------------------------------------------------------------------------- % % so it is deprecated? or was the deprecation deprecated? when the A6 rr type is a full standard, AAAA will be deprecated. until then, things are just claims of what some people think ought to happen. --------------------------------------------------------------------------- that said, I'm still in favor of A6 over the AAAA record, if push comes to shove. --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 May 7 11:24:36 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14185 for ; Mon, 7 May 2001 11:24:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wmY2-000Kva-00 for namedroppers-data@psg.com; Mon, 07 May 2001 08:03:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wmY1-000KvU-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:03:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wmY1-000DFK-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:03:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105071343.IAA07216@gungnir.fnal.gov> To: Randy Bush Cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: AAAA/A6 thing In-reply-to: Your message of Sun, 06 May 2001 07:28:52 PDT. <200105061428.f46ESqH03810@zed.isi.edu> Date: Mon, 07 May 2001 08:43:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ first, it was bill who said it, not i. second, can we move this to some list or newsgroup which is not restricted to protocol topics? much of it looks appropriate for poisson. last approval of this political stuff. -- rb ] Randy, by saying "the authors" and then "the same folks" you give onlookers the impression that the authors of 2874 chose ip6.arpa. You know yourself that this is not the case. > The A6 RFC depricates AAAA, however, the authors did this w/o any A6 > support being available. Some is starting to emerge but it is very > slow. AAAA clearly has the edge in the installed base, since it has > been supported since Bind 4.9.6. > > The same folks who depricated AAAA w/o any alternative also picked > a new place to anchor the delegations with out ensuring it existed. > After repeated requests to the IANA to make the delegation, it still > has not occured. No IP6.ARPA. to unsubscribe send a message to 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 May 7 11:27:29 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14278 for ; Mon, 7 May 2001 11:27:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wmcK-000L0Y-00 for namedroppers-data@psg.com; Mon, 07 May 2001 08:08:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wmcK-000L0S-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:08:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wmcJ-000DNL-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:08:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Ian Jackson Message-ID: <15094.43863.80797.717576@davenant.relativity.greenend.org.uk> Date: Mon, 7 May 2001 15:04:07 +0100 (BST) To: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing Newsgroups: chiark.mail.ietf.namedroppers In-Reply-To: References: <3AF43B95.28FD5FAA@ehsco.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush writes ("Re: AAAA/A6 thing"): > The A6 RFC depricates AAAA, [...] No, it does not. From rfc-index: 1886 DNS Extensions to support IP version 6. S. Thomson, C. Huitema. December 1995. (Format: TXT=6424 bytes) (Status: PROPOSED STANDARD) NB, not HISTORIC. From RFC2874: Network Working Group M. Crawford Request for Comments: 2874 Fermilab Category: Standards Track C. Huitema Microsoft Corporation Note lack of Obsoletes: 1886. Also, in rfc-index: 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering. M. Crawford, C. Huitema. July 2000. (Format: TXT=44204 bytes) (Status: PROPOSED STANDARD) Again, no `(Obsoletes: )'. RFC1886 is not deprecated, is widely implemented and used, works well, supports all the requirements[1] just as well as 2874. Surely it meets all the requirements for advancing to Draft Standard ? [1] *Including* the renumbering requirement as I understand it. This is easy to do server-side. If we need to make it easier eg to make zonefiles with indirection for the prefix more portable between implementations then ipngwg should write a requirement and we can write a MUST implement extension to the zone file format. Ian. to unsubscribe send a message to 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 May 7 11:28:03 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14295 for ; Mon, 7 May 2001 11:28:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wmbC-000KzK-00 for namedroppers-data@psg.com; Mon, 07 May 2001 08:06:58 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wmbB-000KzE-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:06:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wmbB-000DLD-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:06:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Ian Jackson Message-ID: <15094.43269.434847.722184@davenant.relativity.greenend.org.uk> Date: Mon, 7 May 2001 14:54:13 +0100 (BST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing Newsgroups: chiark.mail.ietf.namedroppers In-Reply-To: References: <20010504085136.15388.qmail@cr.yp.to> <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> <3347.988958757@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz writes ("Re: AAAA/A6 thing "): > Where does this bailiwick notion come from? I see no reference to > that anywhere in the DNS specs, etc. This looks to be an invention > that you believe rationalises your approach to glue, and your private > theories as to how people should name their nameservers. It isn't written down in 1034/5. However, it is a necessary concept to avoid cache poisoning. A servers' bailiwick(s) include all the data that that server is listed as a nameserver for (ie, which the cache considering bailiwicks might ask for the data). That includes all zones delegated to that server and all their subzones. Clearly, the security property for the DNS (without DNSSEC) should be that servers' ability to cause answers to be used should be limited to their bailiwick. In order for that to be true then out-of-bailiwick RRsets which appear in answers (eg in the additional section) shouldn't be used (except perhaps as glue - here be dragons). > | If the .com servers want to change the address of > | www.aol.com, they can. > > Only by removing the existing servers and substituting new ones. No, that's not true. Supposing a cache knows nothing about any servers for aol.com. Then if it wants the address of www.aol.com it will ask the servers for .com (ie, it will send them the query `www.aol.com IN A ?'), and if those servers give an answer (www.aol.com A ...) then that answer will be cached and used. This is not an uncommon situation: for example, if a foolish aol.com administrator has listed www.aol.com as a nameserver with the .com servers, then the .com servers *will* return the address of www.aol.com when asked, and the aol.com servers will not be asked in that common case. Indeed, not all subdomains are subzones, and the design of the DNS arranges that caches do not need to know the delegation points unless they actually get a referral. > Otherwise the existing servers rule. They may sometimes be able > to interject a bogus A record for a name - but only until clients > discover the NS records, The .com servers have the ability to make the delegation to aol.com effectively disappear by answering all the queries themselves. That way clients will never discover the NS records, and always ask the .com servers directly. This would even be a trivial configuration change with most server software. Ian. to unsubscribe send a message to 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 May 7 11:33:38 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14460 for ; Mon, 7 May 2001 11:33:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wmkq-000LFE-00 for namedroppers-data@psg.com; Mon, 07 May 2001 08:16:56 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wmkq-000LF8-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:16:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wmkq-000DdG-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:16:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 7 May 2001 16:31:18 +0200 (MET DST) From: Erik Guttman Subject: RE: dns server discovery using mdns To: Richard Barr Hibbs Cc: Namedroppers In-Reply-To: "Your message with ID" Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Richard, It is precisely because of the issues you raise that the service location working group arrived at SLP. I want to briefly contrast the problem statements you make with the solutions provided by SLP. > While DHCP can definitely be used to pass a great deal of information from a > server to a client, and does provide a mechanism for defining and using > vendor-specific options, that still puts too much of a burden on the > administrator in my opinion. For example, the vendor-specific options > (129-254) could incorporate three printer choices for the client: > high-speed, medium resolution letter-size paper for drafts, medium-speed, > high-resolution color printer with legal and letter-size paper for most > "final" printing, and a high-speed, high-resolution color printer with > collator and stapler, multiple paper sizes (8-1/2 x 11 letterhead, 8-1/2 x > 11 second sheet, 8-1/2 x 14, 11 x 17) plus envelopes. SLP allows client systems to request services using attributes - so the client can find the *right* server. Right in individual cases may be determined by speed, color capabilities, resolution, page size, etc. > Consider for a > moment, however, what an administrator must do to make this workable. > First, she would need a complete inventory of shared printers matched to the > subnets under her purview: unless each was the same manufacturer and model, > there would likely be some individual configuration information that would > be required to be inventoried as well. Another possibility: The printer *advertises itself.* The printer can easily provide its model type, capabilities, paper sizes, etc. > Then she needs a DHCP client that > understands the options chosen to pass configuration data, and that client > must be capable of setting all printer configuration parameters in the > client system. That probably requires either a custom DHCP client and > server, or an extremely knowledgeable administrator with all the resources > to gather, maintain, and manage the printers, DHCP clients, and > peculiarities of the client's operating system. SLP client libraries allow LDAPv3 search filter queries to be sent. URLs (the service's location) are retrieved - as well as attributes and configuration information specific to the service. Specific code to support different types of service is not needed. > While DNS could be part of the solution to locating resources (for example, > mapping a name such as "hp870cse.192.168.244" to the actual IP address of > the H-P 870Cse DeskJet printer for the 192.168.244.x subnet) all of the > other configuration information necessary to make printing (to use just one > example) successful is not handled very well using DNS (again, scaling and > administration more than the lack of capability for responding to a query.) For automatic service discovery, we need a default, well known namespace. That is true whether we use DHCP, SLP or DNS. That way, no matter what network a client is present in, it can discover services. Implication: no matter what network the service is advertised in, it has to be advertised the same way (using the same namespace conventions). DHCP has a simple namespace for services: option #s. SLP is richer - services are specified by a service type and a set of attributes associated with each service instance. In DNS SRV RRS, services are specified by a service name, a transport name and a domain name. But what would the 'default DNS name' be, to use for looking up services? One possibility would be to use the 'local.arpa.' domain which is discussed in draft-ietf-dnsext-mdns-00.txt. Clients could request IPP based printers by issuing an mdns request with qname='_ipp._tcp.local.arpa.', qtype=SRV. IPP based printers could respond to these requests. If the client had a configured domain name, the same request could be sent replacing 'local.arpa.' with the client's domain name. If the client had a DNS server address in addition - the same request could be sent using (non- multicast) DNS. I do not think this is a bad idea - for discovering services which are *indistinct*. Unlike printers, described above, many services really are functionally identical. SMTP relays, DNS servers and web proxies, are examples of services for which *any* will do. There are problems with using this approach though: 1. We are considering standardizing mdns for use with link-local multicast. The mechanism will enable discovery of services only on a single link. 2. In the absence of deployed DNS dynamic update, services on the network would be unable to update DNS with SRV RRs. This implies it would be unlikely that clients would get the same result by using mDNS and DNS - as it is difficult (impossible?) to keep DNS zone files up to date with respect to which servers are up or down at any given time. --- My recommendation is to that the DNSEXT WG not consider or further discuss service discovery using mDNS. We can discuss issues surrounding this application of mDNS in the upcoming ZEROCONF WG 'Zeroconf host requirements and recommendations' document. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon May 7 11:34:47 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14491 for ; Mon, 7 May 2001 11:34:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14wmo1-000LOJ-00 for namedroppers-data@psg.com; Mon, 07 May 2001 08:20:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14wmo1-000LOD-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:20:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14wmo1-000Djf-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 08:20:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 7 May 2001 16:37:28 +0200 (CEST) From: Erik Nordmark Subject: Re: AAAA/A6 thing To: "Eric A. Hall" Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <3AF43B95.28FD5FAA@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit > Can somebody clarify? I was under the impression that AAAA had already > been deprecated. I'm looking through my archives and can't seem to find > the message that says this explicitly (so I may be mistaken, which is why > I seek clarification). I think the intent was to have RFC 2874 (A6) obsolete or at least update RFC 1886 (AAAA) but, if that was the intent, the document didn't have the annotations of "Update:" or "Obsoletes:" that would make the rfc-index.txt say anything of that sort. The only hint is the actual text in 2874 This memo proposes a replacement for the specification in RFC 1886 [AAAA] and a departure from current implementation practices. So in effect it looks like we have two proposed standards at the moment, which I don't think was the intent at the time. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From dusty@webbnett.com Mon May 7 11:46:16 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14728 for ; Mon, 7 May 2001 11:46:16 -0400 (EDT) Received: from mailcore2.oh.voyager.net ([207.90.100.13]) by psg.com with esmtp (Exim 3.16 #1) id 14wmls-000LIs-00 for namedroppers-data@psg.com; Mon, 07 May 2001 08:18:00 -0700 Received: from DeskPro ([207.0.228.77]) by mailcore2.oh.voyager.net (8.9.3/8.9.3) with SMTP id LAA98297 for ; Mon, 7 May 2001 11:17:58 -0400 (EDT) Return-Receipt-To: "Dustan Thompson" Reply-To: From: "Dustan Thompson" To: Date: Mon, 7 May 2001 11:17:51 -0400 Message-ID: <000c01c0d708$e2d209e0$4de400cf@DeskPro> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C0D6E7.5BC069E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Disposition-Notification-To: "Dustan Thompson" This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C0D6E7.5BC069E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit unsubscribe ------=_NextPart_000_000D_01C0D6E7.5BC069E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsubscribe
------=_NextPart_000_000D_01C0D6E7.5BC069E0-- From owner-namedroppers@ops.ietf.org Mon May 7 13:43:23 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17915 for ; Mon, 7 May 2001 13:43:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14womi-000P4T-00 for namedroppers-data@psg.com; Mon, 07 May 2001 10:27:00 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14womh-000P4M-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 10:26:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14womh-000HN9-00 for namedroppers@ops.ietf.org; Mon, 07 May 2001 10:26:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: AAAA/A6 thing Date: Mon, 7 May 2001 10:09:36 -0700 Message-ID: From: "Christian Huitema" To: "Randy Bush" Cc: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit For the sake of documentation, here is the history of this matter. It started out from Mike O'Dell's 8+8 proposal, resulted in various proposals to add a "site name" record in the DNS (see minutes of April 97 IETF http://www.ietf.org/proceedings/97apr/97apr-final/xrtftr47.htm#E25E63). The "two part record" proposal was presented in December 1997 (minutes of the Dec 1997 IETF: http://www.ietf.org/proceedings/97dec/index.html; discussion in both ipngwg and dnsind). This was again discussed at the next IETF in April 1997. The idea at the time was to maintain binary compatibility between the existing AAAA and the new format -- the AAAA record would have grown an optional tail describing the prefix information. The binary label were discussed at the same time in the DNSIND WG. The discussion continued throughout 1998; in August, it was decided to merge two drafts, one describing the "new AAAA" and one describing the reverse look-up; the DNAME proposal was discussed at the time in the DNSIND WG (http://www.ietf.org/proceedings/98aug/index.html). In the discussions that ensued, at the request of DNS implementers, it was decided to drop the AAAA compatibility and to go for a new record type. The document went through WG last call, and was submitted to the IESG in October 1998. In short, this was not a flip decision -- the process took a year and a half, spanning 5 IETF meetings. -- Christian Huitema to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 8 06:49:25 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18543 for ; Tue, 8 May 2001 06:49:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14x4bv-0004dk-00 for namedroppers-data@psg.com; Tue, 08 May 2001 03:20:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14x4bv-0004de-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 03:20:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14x4bv-000L29-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 03:20:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Ian Jackson cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <15094.43269.434847.722184@davenant.relativity.greenend.org.uk> References: <15094.43269.434847.722184@davenant.relativity.greenend.org.uk> <20010504085136.15388.qmail@cr.yp.to> <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> <3347.988958757@brandenburg.cs.mu.OZ.AU> Date: Tue, 08 May 2001 16:01:32 +0700 Message-ID: <4651.989312492@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 7 May 2001 14:54:13 +0100 (BST) From: Ian Jackson Message-ID: <15094.43269.434847.722184@davenant.relativity.greenend.org.uk> | It isn't written down in 1034/5. However, it is a necessary concept | to avoid cache poisoning. Rubbish. It is one broken theory of a technique that might help. It doesn't actually avoid cache poisoning (I don't think anyone would claim that - though there is this silly argument that it was really all mine to alter as I see fit anyway ... by that argument, I get to change anything about cr.yp.to as I'm one of the servers for TO... That's ludicrous). | In order for that to be true then out-of-bailiwick | RRsets which appear in answers (eg in the additional section) | shouldn't be used (except perhaps as glue - here be dragons). Forget the "out of bailiwick" nonsense - you really mean answers that don't come from the authoritative servers for the data. And "except as glue" which is exactly what this discussion has been about. The "here be dragons" is just FUD, which carries no weight at all. | No, that's not true. Supposing a cache knows nothing about any | servers for aol.com. Then if it wants the address of www.aol.com it | will ask the servers for .com (ie, it will send them the query | `www.aol.com IN A ?'), and if those servers give an answer | (www.aol.com A ...) then that answer will be cached and used. It might be - but the com server cannot guarantee that. It cannot even guarantee that a client seeking www.aol.com will ask the com servers for the A records for www.aol.com. All it can expect is a request for the NS records for aol.com, which is all that some clients might request. And even if the client did request the A record, all it will get is a non-auth answer - which might be enough to cause the answer to be ignored and for it to go seen answers from the auth server. Hence, the only way that a com server can reliably redirect www.aol.com is to alter the servers for aol.com. It might sometimes be able to direct traffic to a different address, but it can't do that reliably enough to make the change permanent. | Indeed, not all subdomains are subzones, and the design of the DNS | arranges that caches do not need to know the delegation points unless | they actually get a referral. Of course, and if there are no NS records for aol.com, then www.aol.com would be in the COM zone, and the com servers would be entitled to hand out whatever address they like - authoritatively. Also, note that none of this is ever going to be any protection against someone deliberately setting out to maliciously alter data - only dnssec type techniques can achieve that. In the non-signed cases, all we're really interested in is inadvertent data errors (mistakes). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 8 13:18:10 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02154 for ; Tue, 8 May 2001 13:18:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xAgf-000Civ-00 for namedroppers-data@psg.com; Tue, 08 May 2001 09:50:13 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14xAgf-000Cio-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 09:50:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14xAgf-0006F8-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 09:50:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105081407.JAA12499@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: AAAA/A6 thing In-reply-to: Your message of Tue, 08 May 2001 16:01:32 +0700. <4651.989312492@brandenburg.cs.mu.OZ.AU> Date: Tue, 08 May 2001 09:07:15 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Also, note that none of this is ever going to be any protection against > someone deliberately setting out to maliciously alter data - only dnssec > type techniques can achieve that. In the non-signed cases, all we're > really interested in is inadvertent data errors (mistakes). And even then, a subversion that starts from a trusted higher level in the tree will still work (barring the occasional manual configuration of non-hierarchically related keys). to unsubscribe send a message to 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 May 8 13:18:10 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02155 for ; Tue, 8 May 2001 13:18:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xAZZ-000CXf-00 for namedroppers-data@psg.com; Tue, 08 May 2001 09:42:53 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14xAZY-000CXZ-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 09:42:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14xAZY-00061M-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 09:42:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200105081323.WAA14667@necom830.hpcl.titech.ac.jp> Subject: Re: AAAA/A6 thing In-Reply-To: <4651.989312492@brandenburg.cs.mu.OZ.AU> from Robert Elz at "May 8, 2001 04:01:32 pm" To: Robert Elz Date: Tue, 8 May 2001 22:22:53 +0859 () CC: Ian Jackson , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kre; > | In order for that to be true then out-of-bailiwick > | RRsets which appear in answers (eg in the additional section) > | shouldn't be used (except perhaps as glue - here be dragons). > > Forget the "out of bailiwick" nonsense - you really mean answers that > don't come from the authoritative servers for the data. "authoritative" is not a useful concept because anyone can turn on the authoritative bit. We can rely on answers from non-authoritative servers, as long as the servers do not use cached glue information for non-glue reply, The entire system is weakly secure. > Also, note that none of this is ever going to be any protection against > someone deliberately setting out to maliciously alter data - only dnssec > type techniques can achieve that. In the non-signed cases, all we're > really interested in is inadvertent data errors (mistakes). Properly implemented DNS is as secure as telephone network that as long as providers' routing is reliable, the system is secure, which is called weak security. Given that people rarely mind lack of security of telephone network, the Internet without DNSSEC is secure enough. Those wanting even more security can privately exchange shared secret. Anyway, DNSSEC is not secure if parent zones are compromised. 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 May 8 13:33:41 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02625 for ; Tue, 8 May 2001 13:33:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xAyM-000DFs-00 for namedroppers-data@psg.com; Tue, 08 May 2001 10:08:30 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14xAyM-000DFm-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 10:08:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14xAyM-0006ms-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 10:08:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105081426.KAA25440@egyptian-gods.MIT.EDU> To: Robert Elz cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Cache poison (was Re: AAAA/A6 thing) In-Reply-To: Your message of "Tue, 08 May 2001 16:01:32 +0700." <4651.989312492@brandenburg.cs.mu.OZ.AU> Date: Tue, 08 May 2001 10:26:57 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Also, note that none of this is ever going to be any protection > against someone deliberately setting out to maliciously alter data - > only dnssec type techniques can achieve that. In the non-signed > cases, all we're really interested in is inadvertent data errors > (mistakes). I think you're in the margin on this one. Without poison protection similar to the djb variety, it becomes trivial to mass-produce cache poison, and there have been highly publicized events where malicious parties have done so. With bailiwick-related poison protection, maliciously altering data requires (a) forging DNS responses (by sniffing the network path between sender and receiver, or by spamming the sender with replies containing altered IDs), or (b) subverting the DNS hierarchy. (a) is definitely achievable for a targeted attack, but is not practical for most attackers to do on a massive scale, especially if resolvers use unpredictable query IDs and query ports; (b) requires successfully attacking one of a small number of points to subvert a particular domain. (The specific scheme advocated by djb is not the only one which would work. You could, for instance, use all glue records only for the completion of the particular query they come with, and never cache them, thus avoiding the application of "bailiwick" logic. What is required for poison protection is that you never cache an out-of-bailiwick glue record for use with queries other than the one you received it with.) As long as I'm here, some smaller points we don't actually have a reason to care about: > And even if the client did request the A record, all it will get is > a non-auth answer What keeps the .com servers from marking the answer as authoritative? > All it can expect is a request for the NS records for aol.com, which > is all that some clients might request. What resolvers ask the .com servers for aol.com NS without asking for www.aol.com A first? You seem to be assuming that resolvers are aware, a priori, of a zone boundary between com and aol.com. Why would they be, if the .com servers don't want them to be? to unsubscribe send a message to 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 May 8 14:26:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04075 for ; Tue, 8 May 2001 14:26:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xBxY-000EbK-00 for namedroppers-data@psg.com; Tue, 08 May 2001 11:11:44 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14xBxX-000EbE-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 11:11:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14xBxX-0008hr-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 11:11:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200105081800.CAA16573@necom830.hpcl.titech.ac.jp> Subject: Re: Cache poison (was Re: AAAA/A6 thing) In-Reply-To: <200105081426.KAA25440@egyptian-gods.MIT.EDU> from Greg Hudson at "May 8, 2001 10:26:57 am" To: Greg Hudson Date: Wed, 9 May 2001 02:59:52 +0859 () CC: Robert Elz , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Greg: > > Also, note that none of this is ever going to be any protection > > against someone deliberately setting out to maliciously alter data - > > only dnssec type techniques can achieve that. In the non-signed > > cases, all we're really interested in is inadvertent data errors > > (mistakes). > > I think you're in the margin on this one. Without poison protection > similar to the djb variety, As Dan finally understood just recently, poison protection is easy, if one understand the problem correctly. His approach is overkill and broken. > parties have done so. With bailiwick-related poison protection, Could you stop saying "bailiwick"? > maliciously altering data requires (a) forging DNS responses (by > sniffing the network path between sender and receiver, or by spamming It is called weak security. > it becomes trivial to mass-produce cache > poison, Yes. But, Paul ignored it when I said so about 10 years ago and later added wrong fixes. 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 May 8 18:10:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08708 for ; Tue, 8 May 2001 18:09:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xFRO-000J0h-00 for namedroppers-data@psg.com; Tue, 08 May 2001 14:54:46 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14xFRO-000J0b-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 14:54:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14xFRO-000Eys-00 for namedroppers@ops.ietf.org; Tue, 08 May 2001 14:54:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4AEE3169443CDD4796CA8A00B02191CDD1DEDA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Subject: RFC 2782 (SRV RRs) Interop testing report Date: Tue, 8 May 2001 14:44:07 -0700 From: "Levon Esibov" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Here is the update report on the RFC 2782 (SRV RRs) Interop testing. Randy, Olafur, could you, please, take the appropriate actions to advance draft-ietf-dnsext-rfc2782bis-00.txt to draft standard. Thanks, Levon. This is the revised report on the RFC 2782 Interoperability Testing based on the feedback from the IESG. ********************************** What's new in this report: 1. List of ALL sections of the RFC 2782 with explanation on whether every particular section needs to be tested. 2. Explanation of why single record per RRSet was used in the original interoperability testing. Results of the testing with multiple records per RRSet. 1. List of ALL sections of the RFC 2782 with explanation on whether every particular section needs to be tested. Most of the sections of the draft rfc2782bis require no interoperability testing. These sections include: Applicability Statement Introductory example Domain administrator advice The "Weight" field The Port number Fictional example The section "Usage rules" describes how an application SHOULD use SRV resource records to locate the servers providing required service over specified protocol, and how such application should choose a server in case if more than one server is specified in the SRV resource record set. According to rfc2782bis, use of the SRV records in the service location mechanism of a particular application must be specified in the corresponding protocol specification. Interoperability testing of the implementations supporting service location mechanism based on the rules described in the "Usage rules" section should be conducted within the testing of the implementations supporting relevant protocol specification corresponding to a specific application, not the generic specification of the SRV records, rfc2782bis. The only section that required the interoperability section is "The format of the SRV RR". The format of the records was verified by monitoring the network traffic and by performing the tests described below. Note: subsections "Priority" and "Weight" describe how application using SRV records to locate a server should treat Priority and Weight values specified in the SRV records. Interoperability testing of the implementations supporting service location mechanism based on the rules described in the "Priority" and "Weight" sub-sections should be conducted within the testing of the implementations supporting relevant protocol specification corresponding to a specific application, not the generic specification of the SRV records, rfc2782bis. 2. Explanation of why single record per RRSet was used in the original interoperability testing. Results of the testing with multiple records per RRSet. It was sufficient to demonstrate interoperability of the implementations supporting SRV records using a SRV resource record set containing single record because rfc2782bis doesn't specify the order in which multiple SRV record in a record set should be returned to a caller. To eliminate any concerns, the testing was repeated with multiple SRV resource records in a resource record set: Participated implementations A Microsoft Whistler DNS server, Beta 2 (build 2462) (Levon Esibov) B BIND 9.1.1 (Olafur Gudmundsson) Date: April 4, 2001 Place: over the Internet. Server A was physically located in a Microsoft lab and was connected to the Internet. Test zones were srv.ind.test and srv-ogud.ind.test. In addition to the SOA and NS records at the top of the zone, the zone srv.ind.test contained the following records: _ldap._tcp SRV 0 0 389 target.srv.ind.test. _ldap._tcp SRV 1 0 389 target1.srv.ind.test. _ldap._tcp SRV 0 0 389 target2.srv.ind.test. target A 1.2.3.4 target1 A 1.2.3.5 target2 A 1.2.3.6 In addition to the SOA and NS records at the top of the zone, the zone srv-ogud.ind.test contained the following records: kerberos 900 A 127.0.0.1 many 900 TXT ( "Name with SRV larger RRset" ) _ns._tcp.many 900 SRV 0 0 30 ns30.srv-ogud.ind.test. _ns._tcp.many 900 SRV 0 0 40 ns40.srv-ogud.ind.test. _ns._tcp.many 900 SRV 0 2 50 ns250.srv-ogud.ind.test. _ns._tcp.many 900 SRV 0 2 60 ns360.srv-ogud.ind.test. _ns._tcp.many 900 SRV 3 2 50 ns3250.srv-ogud.ind.test. _ns._tcp.many 900 SRV 3 2 60 ns3260.srv-ogud.ind.test. ns250 900 A 127.0.2.50 ns30 900 A 127.0.0.30 ns3250 900 A 127.3.2.50 ns3260 900 A 127.3.2.60 ns360 900 A 127.0.2.60 ns40 900 A 127.0.0.40 one 900 TXT ( "Name with SRV RRset that contains one record" ) _kerberos._tcp.one 900 SRV 0 0 88 kerberos.srv-ogud.ind.test. _ldap._tcp.one 900 SRV 0 0 389 target.srv-ogud.ind.test. target 900 A 1.2.3.4 DNS server A was configured as primary server for the zone srv.ind.test. and as a secondary server for the zone srv-ogud.ind.test. The DNS server B was configured as primary server for the zone srv-ogud.ind.test. and as a secondary server for the zone srv.ind.test. The conducted test ensured proper transmission of resource records of type SRV in a zone transfer from one server to another AND the ability of the DNS servers to properly respond to the queries for the resource records of type SRV. After the primary and secondary zones were created on each of the DNS servers and after zone transfers took place, NSLOOKUP tool installed on the Whistler Server was used to send to the servers A and B queries for the resource records of type SRV for the names _ldap._tcp.srv.ind.test., _ns._tcp.many.srv-ogud.ind.test., _kerberos._tcp.one.many.srv-ogud.ind.test. and _ldap._tcp.one.many.srv-ogud.ind.test. The responses from both servers contained all expected records in both cases: when there is only one record and when there are multiple records in the specified in the query RRSet. The order of the records returned in the query response is irrelevant for the interoperability testing of the RFC 2782 since this document doesn't require any particular order of the returned records. **************************************************************************** Below are the results of the original test conducted in Pittsburgh, PA in August 2000. Tested RFC: RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)" Date: August 1, 2000 Place: Double Tree Hotel, Pittsburgh, PA, USA. Participated implementations A Checkpoint 8.2.3-t6b (Kevin Dunlap) B Cisco CNR (build 353) (Josh Littlefield) C ISC BIND 8.2.3-t6b (Mark Andrews) D Lucent QIP 3.0 (Alexis MacFarlane) E Microsoft Windows 2000 DNS server (Levon Esibov) F Microsoft Whistler DNS server (build 2253) (Stuart Kwan) G Nominum BIND 9.1.0a (Andreas Gustafsson) Running on network 10.0.0.0/8. Test zone was srv.ind.test. In addition to the SOA and NS records at the top of the zone, the zone contained the following records: _kerberos._tcp SRV 0 0 88 . _ldap._tcp SRV 0 0 389 target.srv.ind.test. target A 1.2.3.4 DNS server E was configured as primary server for the zone srv.ind.test. All other DNS servers (i.e. A, B, C, D, F and G) were configured as secondary DNS servers for the zone srv.ind.test. with E DNS server as the Master server for the zone. The first round of tests ensured proper transmission of resource records of type SRV in a zone transfer from one server to another AND the ability of the DNS servers to respond to the queries for the resource records of type SRV: After every secondary DNS server was configured with DNS server E as its Master for the zone srv.ind.test. and after zone transfers took place, NSLOOKUP tool installed on the Windows 2000 Server was used to send to the secondary servers (one at a time) queries for the resource records of type SRV for the names _kerberos._tcp.srv.ind.test. and _ldap._tcp.srv.ind.test. The responses from the secondary servers were verified to match the SRV resource records specified in the primary copy of the srv.ind.test. zone. The second round of tests ensured that the DNS servers properly store and load SRV resource records: Every secondary DNS server reloaded the secondary zone. Presence and correctness of the DNS SRV recourse records was ensured by checking the zone file containing the records and by repeating the set of the SRV queries used in the first series of tests and verifying that the returned in the query response records match the SRV records specified in the primary copy of the zone srv.ind.test. Finally, to ensure that the DNS server E that served as primary DNS server in the interoperability testing (and therefore was not subjected to the same testing as all other secondary servers) also passes the same tests, it was configured as a secondary DNS server for the zone srv.ind.test. with DNS server F being its Master. Then the same set of tests (as described above) was applied to the DNS server E and it passed all the tests. By monitoring network traffic it was verified that none of the DNS server implementations use name compression in the target field of the RDATA of the SRV resource records. The conclusion of the participants of the interoperability testing: The testing demonstrates full compliance of seven implementations of the DNS servers with all requirements of the RFC 2782. to unsubscribe send a message to 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 May 9 10:19:58 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08018 for ; Wed, 9 May 2001 10:19:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xUQj-0009Cf-00 for namedroppers-data@psg.com; Wed, 09 May 2001 06:55:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14xUQj-0009CZ-00 for namedroppers@ops.ietf.org; Wed, 09 May 2001 06:55:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14xUQj-000F1X-00 for namedroppers@ops.ietf.org; Wed, 09 May 2001 06:55:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Masataka Ohta cc: Ian Jackson , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: Cache poison (was Re: AAAA/A6 thing) In-Reply-To: <200105081323.WAA14667@necom830.hpcl.titech.ac.jp> References: <200105081323.WAA14667@necom830.hpcl.titech.ac.jp> Date: Wed, 09 May 2001 18:17:22 +0700 Message-ID: <2545.989407042@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 8 May 2001 22:22:53 +0859 () From: Masataka Ohta Message-ID: <200105081323.WAA14667@necom830.hpcl.titech.ac.jp> | > Forget the "out of bailiwick" nonsense - you really mean answers that | > don't come from the authoritative servers for the data. | | "authoritative" is not a useful concept because anyone can turn | on the authoritative bit. No, I said "from the authoritative servers", not "replies with the AA bit set". I do understand the difference. | Anyway, DNSSEC is not secure if parent zones are compromised. Sure. But all that is relevant here is avoiding trusting bogus data. The world is in a paranoid state now, because of the typical overreaction to the bogosity of earlier versions of BIND (which would trust any random data in an answer in preference to the data loaded out of its own master file). Anyway, this discussion seems to have gone beyond reasonable now, so I think it is time to end it - and particularly to end it with the current subject line. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 9 10:26:43 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08306 for ; Wed, 9 May 2001 10:26:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xURr-0009Dr-00 for namedroppers-data@psg.com; Wed, 09 May 2001 06:56:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14xURr-0009Dl-00 for namedroppers@ops.ietf.org; Wed, 09 May 2001 06:56:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14xURr-000F3f-00 for namedroppers@ops.ietf.org; Wed, 09 May 2001 06:56:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Greg Hudson cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: Cache poison (was Re: AAAA/A6 thing) In-Reply-To: <200105081426.KAA25440@egyptian-gods.MIT.EDU> References: <200105081426.KAA25440@egyptian-gods.MIT.EDU> Date: Wed, 09 May 2001 18:35:04 +0700 Message-ID: <2564.989408104@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 08 May 2001 10:26:57 -0400 From: Greg Hudson Message-ID: <200105081426.KAA25440@egyptian-gods.MIT.EDU> | What keeps the .com servers from marking the answer as authoritative? Nothing. But recall we're not discussing malicious attacks, we're discussing what happens when bad data (stale glue particularly) is floating around. So, postulating what an evil com server administrator might do isn't really relevant. What matters is what happens when the com administrators are generally trying to do the right thing (or even just their definition of that). | What resolvers ask the .com servers for aol.com NS without asking for | www.aol.com A first? No idea. But any can. If you treat me as a resolver, it is what I do when I am looking for problems. | You seem to be assuming that resolvers are aware, a priori, of a zone | boundary between com and aol.com. Why would they be, if the .com | servers don't want them to be? Same as the first answer above. And I'm not assuming any a priori knowledge, just the availability of the information that leads to that knowledge. If the com servers aren't deliberately being manipulated, they will have the NS delegation RRset, and will return that when queried. That's all the resolver needs to see. Bad glue A records floating around won't have any effect. Of course, the com servers can change (or delete) the NS records for any sub-domain - that's part of their function, and nothing we can do can alter that at the technical level (that's just doing what they're designed to do). What is correct there is decided at a higher level - between humans - and typically involves human protocols (contracts and such). But given that a com server has delegated to the correct nameservers, it is *not* within the com server's function to give out any other random information about a sub-domain. And most particularly, resolvers should not be being built which assume that it is within the com server's responsibility to do that, and that is what all this bailiwick nonsense is about. Sure, most resolvers in use on the net today might just blindly assume that what a com server tells it is correct (more accurately, assume that what any server they ask tells it is correct). For many purposes that's even the right thing to do, as Otha-san pointed out. But if a resolver decides not to simply trust what any other server tells it, there is absolutely no basis at all for trusting the information from the .com servers for some random answer about www.aol.com more than there is for trusting any other random server's answer. The two are equivalent. That is, either do things properly, or don't do it at all - don't invent bogus half way measures. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 9 19:12:47 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28828 for ; Wed, 9 May 2001 19:12:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xcih-000HaO-00 for namedroppers-data@psg.com; Wed, 09 May 2001 15:46:11 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14xcig-000HaI-00 for namedroppers@ops.ietf.org; Wed, 09 May 2001 15:46:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14xcig-0003IZ-00 for namedroppers@ops.ietf.org; Wed, 09 May 2001 15:46:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105092117.f49LHIC08418@thunk.east.sun.com> From: Bill Sommerfeld To: Greg Hudson cc: Robert Elz , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: Cache poison (was Re: AAAA/A6 thing) In-reply-to: Your message of "Tue, 08 May 2001 10:26:57 EDT." <200105081426.KAA25440@egyptian-gods.MIT.EDU> Reply-to: sommerfeld@east.sun.com Date: Wed, 09 May 2001 17:17:18 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit An alternate way to avoid cache poisoning which avoids the need to invent a new "b**l*w*ck" concept: - never enter glue into any part of the cache's namespace - attach glue records to the NS records they came with; when a cache resolves an NS record into a set of locations, fall back to the NS record's attached glue records if there isn't a "real" cached entry. - 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 May 10 08:33:35 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24100 for ; Thu, 10 May 2001 08:33:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14xp3o-0002C3-00 for namedroppers-data@psg.com; Thu, 10 May 2001 04:56:48 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14xp3n-0002Bx-00 for namedroppers@ops.ietf.org; Thu, 10 May 2001 04:56:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14xp3n-000Nz3-00 for namedroppers@ops.ietf.org; Thu, 10 May 2001 04:56:47 -0700 Message-Id: <200105101120.HAA22656@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-parent-stores-zone-keys-01.txt Date: Thu, 10 May 2001 07:20:43 -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 : Parent stores the child's zone KEYs Author(s) : R. Gieben, T. Lindgreen Filename : draft-ietf-dnsext-parent-stores-zone-keys-01.txt Pages : 10 Date : 09-May-01 When dealing with large amounts of keys the procedures to update a zone and to sign a zone need to be clearly defined and practically possible. The current idea is to have the zone KEY RR and the parent's SIG to reside in the child's zone and perhaps also in the parent's zone. Operational experiences have prompted us to develop an alternative scheme in which the parent zone stores the parent's signature over the child's key and also the child's key itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-parent-stores-zone-keys-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-parent-stores-zone-keys-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-parent-stores-zone-keys-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010509141113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-parent-stores-zone-keys-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-parent-stores-zone-keys-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010509141113.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 May 11 22:57:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26963 for ; Fri, 11 May 2001 22:57:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14yP43-0009Xn-00 for namedroppers-data@psg.com; Fri, 11 May 2001 19:23:27 -0700 Received: from dhcp3-7.ws.afnog.org ([213.172.133.7] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14yP40-0009Xh-00 for namedroppers@ops.ietf.org; Fri, 11 May 2001 19:23:25 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14yP2G-0000zz-00 for namedroppers@ops.ietf.org; Sat, 12 May 2001 02:21:36 +0000 Message-Id: <200105101120.HAA22656@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-parent-stores-zone-keys-01.txt Date: Thu, 10 May 2001 07:20:43 -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 : Parent stores the child's zone KEYs Author(s) : R. Gieben, T. Lindgreen Filename : draft-ietf-dnsext-parent-stores-zone-keys-01.txt Pages : 10 Date : 09-May-01 When dealing with large amounts of keys the procedures to update a zone and to sign a zone need to be clearly defined and practically possible. The current idea is to have the zone KEY RR and the parent's SIG to reside in the child's zone and perhaps also in the parent's zone. Operational experiences have prompted us to develop an alternative scheme in which the parent zone stores the parent's signature over the child's key and also the child's key itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-parent-stores-zone-keys-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-parent-stores-zone-keys-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-parent-stores-zone-keys-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010509141113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-parent-stores-zone-keys-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-parent-stores-zone-keys-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010509141113.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 Mon May 14 02:07:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04063 for ; Mon, 14 May 2001 02:07:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zB4z-000Fwa-00 for namedroppers-data@psg.com; Sun, 13 May 2001 22:39:37 -0700 Received: from hmm-dca-ap01-d10-018.dial.freesurf.nl ([62.100.43.18] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14zB4x-000FwR-00 for namedroppers@ops.ietf.org; Sun, 13 May 2001 22:39:35 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zEp4-0000HR-00 for namedroppers@ops.ietf.org; Mon, 14 May 2001 05:39:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3AFEDEB8.25C3641E@ehsco.com> Date: Sun, 13 May 2001 12:21:28 -0700 From: "Eric A. Hall" To: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data References: <200104172325.QAA13342@toad.com> <3ADCDB32.597883BD@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit http://www.ehsco.com/misc/draft-hall-dns-data-00.txt is a draft on what I believe to be appropriate guidelines for DNS data. Due to the architectural tradeoffs inherent in the DNS lookup model, some usage models are better suited to DNS than others. In particular, DNS is highly efficient at lookups of compact, public and relatively stable data. Conversely, DNS is unsuitable for value- based queries or searches, restricted-access data, highly-dynamic data, or large records and arrays. Note that this does not include my original arguments, which was that DNS should be used for lookups of distributed data required to establish a connection, nor does it include the subordinate requirements such as "no machine-specific data, no local-only data" and so forth. The reason this restriction is not there is because I have not been able to find enough data to support or refute the position that the DNS hierarchy would be overloaded by some N multiple of current lookups. This doesn't mean that either position is valid, it only means that there is no evidence to support either position. I can't consider this document finished without that evidence so I'm not planning on advancing this document until that data is available. But I wanted to close the argument loop, so here is what is known. Regarding the missing data, there are three potential limiters on query growth: cache size of end-systems, bandwidth of core servers, and query rate of core servers. Evidence suggests that cache availability might as well be infinite and that core bandwidth is not likely to become a limiter anytime soon, which leaves query rate as the only potential bottleneck. I'm still looking for data in all three areas, and if anybody has anything to add here I'd appreciate it. -- 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 Tue May 15 12:41:44 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02545 for ; Tue, 15 May 2001 12:41:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zhWs-000B3l-00 for namedroppers-data@psg.com; Tue, 15 May 2001 09:18:34 -0700 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14zhWs-000B3H-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 09:18:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zhWH-0000Fu-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 12:17:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 15 May 2001 10:07:46 -0400 From: "Nicolae, Dan" Subject: RE: comments on mnds-00 To: namedroppers@psg.com Message-id: <3820E1EF15CCD411B4E600508BAED1F45BC8FA@usa0111ms2.eng.mc.xerox.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The DNS RFCs allow for a parallel, separately managed namespace through the use of the class concept. Is there a reason why mDNS must use the IN class and not a special-purpose one? 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 May 15 12:48:09 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02731 for ; Tue, 15 May 2001 12:48:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zhVy-000B2p-00 for namedroppers-data@psg.com; Tue, 15 May 2001 09:17:38 -0700 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14zhVx-000B2R-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 09:17:37 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zhVL-0000Fl-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 12:16:59 -0400 Date: Mon, 14 May 2001 11:46:33 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: summary/conclusion of discussion on mdns-00 To: Namedroppers Cc: levone@microsoft.com, erik.guttman@sun.com, dthaler@Exchange.Microsoft.com, aboba@internaut.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Levon, folks, I want to try and conclude our mdns-00 discussion. IMO, we have consensus on the following points. [1] Do not limit name in requests to '.local.arpa.' Allow other names. [2] mdns servers MUST NOT send error replies (to multicast requests) [3] Clarify text on what names an mdns server responds to requests for (only for names they are authoritative for, and authority for "a" does not in this case imply authority for "child.a" [4] Responses are never NULL. An mdns server responds only with a positive non-null reply. [5] Recommend resolvers send few retries to and cache no-responses for a short time to suppress useless multicast queries. Remove specific time (5 seconds). [6] Change 'Sender MUST anticipate receiving multiple replies' to MAY. [7] Remove 'search path' configuration text and replace it with text regarding a DHCP option to disable mdns behavior. [8] Change text: 'It is required to verify the uniqueness of the host DNS name when a host boots,...' to 'A host MAY verify...' [9] Change text: 'A gratuitous name resolution query SHOULD be done to check for a name conflict. This is done by having the resolver send a multicast query for a SOA type query for its own name (i.e. for the name it is authoritative for.' s/SHOULD/MAY/ s/SOA/A/ [9] Change text: 'A host that has detected a name conflict MUST NOT use the name.' s/MUST/SHOULD/ [10] Change text 'Name conflict in such situation is detected when a sender receives more than one response to its multicasted DNS query.' To 'It is possible that more than one mdns server will be authoritative for the same name. In some cases it is desirable to assign the same name to more than one host. In this case a sender will receive more than one response to its multicasted DNS query.' [11] Modify the acknowledgements section to recognize the contribution of Bill Manning and Bill Woodcock. We had tangential discussion of two additional points. [12] DNS server discovery We debated whether or not it is a good idea to offer more than one optional mechanism for configuring DNS server locations. Randy doubted whether we need more than DHCP. Bernard noted that when we have a DNS server we can often assume there will be a DHCP server too. All others participating in the discussion found some advantage in being able to use DNS to configure DNS. Note that this potential is present using mdns as defined, after change [1] above. If an mdns query type='NS' is sent, any mdns enabled DNS server that responds has been discovered! Suggestion: Add a note that DNS servers MAY listen for mdns requests of type=NS and respond (if the name corresponds to the domain for which the server is authoritative). Resolvers MAY issue these requests to discover DNS servers. [13] Service discovery We discussed how this might be possible with mdns and SRV RRs. Yes it is. We could debate whether it is the right way to discover services for some time. Trust me on this. Suggestion: Say nothing about service discovery in this draft. If mdns servers support SRV RRs they can respond to queries of type=SRV, but this is already clear in the text: >A sender sends multicast DNS query for any legal Type of resource record >(e.g. A, PTR, etc.) for a name... If there's no further discussion on this required, can the authors please issue mdns-01? I volunteer to coauthor the doc and make the changes myself if you guys are overloaded right now. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 15 12:54:12 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02546 for ; Tue, 15 May 2001 12:41:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zhWQ-000B3N-00 for namedroppers-data@psg.com; Tue, 15 May 2001 09:18:06 -0700 Received: from cbb-sc2.cbbtier3.att.net ([12.0.1.9] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14zhWQ-000B2i-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 09:18:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zhVp-0000Fs-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 12:17:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: summary/conclusion of discussion on mdns-00 Date: Mon, 14 May 2001 15:31:36 -0700 Message-ID: <4AEE3169443CDD4796CA8A00B02191CDBEC200@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> From: "Levon Esibov" To: "Erik Guttman" , "Namedroppers" Cc: "Dave Thaler" , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'll submit the updated draft by 5/25. Thanks, Levon. to unsubscribe send a message to 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 May 15 23:43:30 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14880 for ; Tue, 15 May 2001 23:43:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zrmA-000IFj-00 for namedroppers-data@psg.com; Tue, 15 May 2001 20:15:02 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14zrm8-000IFW-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 20:15:01 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zrTw-0000sn-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 22:56:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B016B62.9BCBA353@ehsco.com> Date: Tue, 15 May 2001 10:46:10 -0700 From: "Eric A. Hall" To: Erik Guttman CC: Namedroppers , levone@microsoft.com, dthaler@Exchange.Microsoft.com, aboba@internaut.com Subject: Re: summary/conclusion of discussion on mdns-00 References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > [1] Do not limit name in requests to '.local.arpa.' Allow other > names. > [12] DNS server discovery > Note that this potential is present using mdns as defined, after > change [1] above. If an mdns query type='NS' is sent, any mdns > enabled DNS server that responds has been discovered! That is not enough information to configure a client. For example, how do you deal with multiple domain name offers? It is a good idea but there is a lot more to it, or "there is a lot of procedural protocol to be defined" at the very least. Probably the use of a new query type would be beneficial to implementions as well. Anyway, there is a lot more to it than this, but it is a good idea and it should be given direct and complete treatment on its merits. -- 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 Tue May 15 23:43:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14882 for ; Tue, 15 May 2001 23:43:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zrmx-000IHe-00 for namedroppers-data@psg.com; Tue, 15 May 2001 20:15:51 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14zrmw-000IH8-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 20:15:50 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zrc1-0000uH-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 23:04:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010515165008.05138d80@localhost> Date: Tue, 15 May 2001 17:01:09 -0400 To: Erik Guttman , Namedroppers From: Olafur Gudmundsson Subject: Re: summary/conclusion of discussion on mdns-00 Cc: levone@microsoft.com, erik.guttman@sun.com, dthaler@Exchange.Microsoft.com, aboba@internaut.com In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 05:46 14-05-2001, Erik Guttman wrote: >Levon, folks, > >I want to try and conclude our mdns-00 discussion. IMO, we have >consensus on the following points. > >[1] Do not limit name in requests to '.local.arpa.' Allow other > names. Not allowed, all queries to discover servers MUST be in domain local.arpa. >[2] mdns servers MUST NOT send error replies (to multicast requests) Yes, >[3] Clarify text on what names an mdns server responds to requests > for (only for names they are authoritative for, and authority for > "a" does not in this case imply authority for "child.a" This needs clarification on if a delegation ? >[4] Responses are never NULL. An mdns server responds only with > a positive non-null reply. Yes MUST. >[5] Recommend resolvers send few retries to and cache no-responses > for a short time to suppress useless multicast queries. Remove > specific time (5 seconds). Why ? Replacing time with upper bound on retries is fine. >[6] Change 'Sender MUST anticipate receiving multiple replies' to > MAY. Why change that, this reduces the robustness of the protocol ? >[7] Remove 'search path' configuration text and replace it with text > regarding a DHCP option to disable mdns behavior. Does such an option exist? I worry that not specifying in this document how to do this people will go different ways. >[8] Change text: 'It is required to verify the uniqueness of the host > DNS name when a host boots,...' to 'A host MAY verify...' Again you want to reduce the robustness of the protocol, I can live with changing the wording from "boot" to "before attempting any name resolution" >[9] Change text: 'A gratuitous name resolution query SHOULD be done > to check for a name conflict. This is done by having the resolver > send a multicast query for a SOA type query for its own name (i.e. > for the name it is authoritative for.' > s/SHOULD/MAY/ > s/SOA/A/ No way this change should be done!!! Read notes from the Adelaide lunch meeting to understand why. >[9] Change text: 'A host that has detected a name conflict MUST NOT > use the name.' > s/MUST/SHOULD/ NO, >[10] Change text 'Name conflict in such situation is detected when > a sender receives more than one response to its multicasted > DNS query.' > To 'It is possible that more than one mdns server will be > authoritative for the same name. In some cases it is desirable > to assign the same name to more than one host. In this case > a sender will receive more than one response to its multicasted > DNS query.' No >[11] Modify the acknowledgements section to recognize the contribution > of Bill Manning and Bill Woodcock. Yes please do. Sorry for not getting involved sooner but I have been preoccupied with DNSSEC over the last few weeks. Olafur (DNSEXT co-chair) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 15 23:43:35 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14904 for ; Tue, 15 May 2001 23:43:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zrmh-000IGa-00 for namedroppers-data@psg.com; Tue, 15 May 2001 20:15:35 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14zrmf-000IGL-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 20:15:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zrfO-0000uq-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 23:08:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 15 May 2001 15:52:59 -0700 (PDT) From: Bernard Aboba To: Erik Guttman cc: Namedroppers , levone@microsoft.com, aboba@internaut.com, dthaler@Exchange.Microsoft.com Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In making conclusions on WG consensus, it is important to take past discussion into account. A number of these changes were extensively discussed in the past and rejected. So we don't start over from scratch in establishing consensus for every posting. On Mon, 14 May 2001, Erik Guttman wrote: > Levon, folks, > > I want to try and conclude our mdns-00 discussion. IMO, we have > consensus on the following points. > > [1] Do not limit name in requests to '.local.arpa.' Allow other > names. This one was extensively discussed already, and WG consensus was to use .local.arpa. So default should be to reject the change unless it can be demonstrated that the WG has changed its mind. > > [2] mdns servers MUST NOT send error replies (to multicast requests) > Think more discussion is needed on the implications of this. Hard to think of any bad effects, but the DNS experts in the WG might think of some ;) > [3] Clarify text on what names an mdns server responds to requests > for (only for names they are authoritative for, and authority for > "a" does not in this case imply authority for "child.a" Think this one is ok. > > [4] Responses are never NULL. An mdns server responds only with > a positive non-null reply. Also looks ok to me. > > [5] Recommend resolvers send few retries to and cache no-responses > for a short time to suppress useless multicast queries. Remove > specific time (5 seconds). Looks ok to me. > > [6] Change 'Sender MUST anticipate receiving multiple replies' to > MAY. If multiple replies are possible, then the sender MUST anticipate them. Recommend to not accept the change. > > [7] Remove 'search path' configuration text and replace it with text > regarding a DHCP option to disable mdns behavior. This was extensively discussed previously. Recommend that we not make the change. > > [8] Change text: 'It is required to verify the uniqueness of the host > DNS name when a host boots,...' to 'A host MAY verify...' Also discussed at length. Name conflicts can be a big problem, so it seems prudent to err on the side of caution. Recommend rejecting the change. > > [9] Change text: 'A gratuitous name resolution query SHOULD be done > to check for a name conflict. This is done by having the resolver > send a multicast query for a SOA type query for its own name (i.e. > for the name it is authoritative for.' > s/SHOULD/MAY/ > s/SOA/A/ Again, I think that name conflicts are a problem and caution is advised. Recommend against the change. > > [9] Change text: 'A host that has detected a name conflict MUST NOT > use the name.' > s/MUST/SHOULD/ For same reasons, recommend against the change. > > [10] Change text 'Name conflict in such situation is detected when > a sender receives more than one response to its multicasted > DNS query.' > To 'It is possible that more than one mdns server will be > authoritative for the same name. In some cases it is desirable > to assign the same name to more than one host. In this case > a sender will receive more than one response to its multicasted > DNS query.' Don't agree that we should allow more than one host with the same name. I think this is a problem. Recommend against the change. > > [11] Modify the acknowledgements section to recognize the contribution > of Bill Manning and Bill Woodcock. No problem with this -- assuming that the Bills agree. > > We had tangential discussion of two additional points. > > [12] DNS server discovery > > We debated whether or not it is a good idea to offer more than > one optional mechanism for configuring DNS server locations. > Randy doubted whether we need more than DHCP. Bernard noted > that when we have a DNS server we can often assume there will > be a DHCP server too. All others participating in the discussion > found some advantage in being able to use DNS to configure DNS. This was extensively discussed previously with consensus against use in this way. So I recommend against taking the change -- unless the original proponents are canvassed and agree to it. > > Note that this potential is present using mdns as defined, after > change [1] above. If an mdns query type='NS' is sent, any mdns > enabled DNS server that responds has been discovered! > > Suggestion: Add a note that DNS servers MAY listen for mdns > requests of type=NS and respond (if the name corresponds to > the domain for which the server is authoritative). Resolvers > MAY issue these requests to discover DNS servers. > > [13] Service discovery > > We discussed how this might be possible with mdns and SRV RRs. > Yes it is. We could debate whether it is the right way to > discover services for some time. Trust me on this. > > Suggestion: Say nothing about service discovery in this draft. > If mdns servers support SRV RRs they can respond to queries of > type=SRV, but this is already clear in the text: > > >A sender sends multicast DNS query for any legal Type of resource record > >(e.g. A, PTR, etc.) for a name... > Agree that the draft should not get into this. Do you have specific text that you want stricken? I was under the impression that we are fairly innocent on this score already. > If there's no further discussion on this required, can the authors > please issue mdns-01? mdns-01 is indeed overdue, but I think we need some more discussion on the points above before we issue 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 Tue May 15 23:43:36 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14903 for ; Tue, 15 May 2001 23:43:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zrmC-000IFx-00 for namedroppers-data@psg.com; Tue, 15 May 2001 20:15:04 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14zrmB-000IFk-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 20:15:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zrVt-0000tL-00 for namedroppers@ops.ietf.org; Tue, 15 May 2001 22:58:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 15 May 2001 14:30:23 -0400 From: "Nicolae, Dan" Subject: RE: summary/conclusion of discussion on mdns-00 To: Namedroppers Message-id: <3820E1EF15CCD411B4E600508BAED1F45BC8FB@usa0111ms2.eng.mc.xerox.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > [12] DNS server discovery > > We debated whether or not it is a good idea to offer more than > one optional mechanism for configuring DNS server locations. > Randy doubted whether we need more than DHCP. Bernard noted > that when we have a DNS server we can often assume there will > be a DHCP server too. All others participating in the discussion > found some advantage in being able to use DNS to configure DNS. > > Note that this potential is present using mdns as defined, after > change [1] above. If an mdns query type='NS' is sent, any mdns > enabled DNS server that responds has been discovered! > > Suggestion: Add a note that DNS servers MAY listen for mdns > requests of type=NS and respond (if the name corresponds to > the domain for which the server is authoritative). Resolvers > MAY issue these requests to discover DNS servers. > This solution only enables discovery of DNS servers that hold authoritative data. Most resolvers need to discover a local DNS server configured as caching-only or slave. The NS records are intended for navigating the DNS name space (finding the servers authoritative for a particular zone). They are mostly useful to servers that provide recursive services to stub resolvers, or resolvers that perform their own recursion. For a stub resolver to discover a local server that provides DNS services the problem is similar to any other service (item 13 below). For example, a query for QNAME="_DNS._TCP.local.arpa.", QTYPE=SRV would be needed. Secondly, a mDNS device itself would respond to a query for a NS record associated with its name (it is authoritative for the DNS zone with only one node: itself). The requestor would then think that the mDNS device is a DNS server. For example, child.host.example.com. could discover host.example.com. and believe that it is a DNS server) > [13] Service discovery > > We discussed how this might be possible with mdns and SRV RRs. > Yes it is. We could debate whether it is the right way to > discover services for some time. Trust me on this. > > Suggestion: Say nothing about service discovery in this draft. > If mdns servers support SRV RRs they can respond to queries of > type=SRV, but this is already clear in the text: > > >A sender sends multicast DNS query for any legal Type of > resource record > >(e.g. A, PTR, etc.) for a name... > to unsubscribe send a message to 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 May 16 07:43:34 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03746 for ; Wed, 16 May 2001 07:43:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zzH4-0001D2-00 for namedroppers-data@psg.com; Wed, 16 May 2001 04:15:26 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14zzH4-0001Cw-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 04:15:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zzH3-0001IY-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 07:15:25 -0400 Date: Wed, 16 May 2001 07:50:49 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: summary/conclusion of discussion on mdns-00 To: Olafur Gudmundsson Cc: Erik Guttman , Namedroppers , levone@microsoft.com, erik.guttman@Sun.COM, dthaler@Exchange.Microsoft.com, aboba@internaut.com In-Reply-To: "Your message with ID" <5.1.0.14.0.20010515165008.05138d80@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olafur, A couple comments I didn't send in my response to Bernard. "Olafur Gudmundsson" wrote: > At 05:46 14-05-2001, Erik Guttman wrote: > >[1] Do not limit name in requests to '.local.arpa.' Allow other > > names. > > Not allowed, all queries to discover servers MUST be in domain local.arpa. Why? Who doesn't allow it? > >[5] Recommend resolvers send few retries to and cache no-responses > > for a short time to suppress useless multicast queries. Remove > > specific time (5 seconds). > > Why ? Replacing time with upper bound on retries is fine. As long as the algorithm is correct (i.e. exponential back off, caching non-response), the specific time bounds are an implementation detail. Different resolvers may be used in different scenarios - some will be designed for responsiveness suitable for human users, others will have no human user and could therefore be more patient. At most we can put a SHOULD here. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 16 07:43:37 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03757 for ; Wed, 16 May 2001 07:43:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14zzH0-0001Cu-00 for namedroppers-data@psg.com; Wed, 16 May 2001 04:15:22 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14zzGy-0001Co-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 04:15:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14zzGx-0001IU-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 07:15:19 -0400 Date: Wed, 16 May 2001 07:46:41 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: summary/conclusion of discussion on mdns-00 To: Bernard Aboba Cc: Erik Guttman , Namedroppers , levone@microsoft.com, dthaler@Exchange.Microsoft.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In making conclusions on WG consensus, it is important to take past > discussion into account. A number of these changes were extensively > discussed in the past and rejected. So we don't start over from scratch in > establishing consensus for every posting. There were presentations made during DNSEXT WG meetings, but no discussion or action on the mailing list. I posted a list of discussion items in March, for which there was discussion. I attempted to reflect the outcome of that discussion, which might be wrong. If we do not establish consensus for this protocol, we will not advance it. So let's try to iron out all the loose wrinkles here. Let's especially try to avoid unnecessary 'MUST's in the protocol specification. > On Mon, 14 May 2001, Erik Guttman wrote: > > [1] Do not limit name in requests to '.local.arpa.' Allow other > > names. > > This one was extensively discussed already, and WG consensus was to use > .local.arpa. So default should be to reject the change unless it can be > demonstrated that the WG has changed its mind. Why not? > > [2] mdns servers MUST NOT send error replies (to multicast requests) > > > > Think more discussion is needed on the implications of this. Hard to think > of any bad effects, but the DNS experts in the WG might think of some ;) This is needed because a malformed request would cause an implosion of errors. If there were many mdns servers this would be a very bad thing! > > [6] Change 'Sender MUST anticipate receiving multiple replies' to > > MAY. > > If multiple replies are possible, then the sender MUST anticipate > them. Recommend to not accept the change. I suggest 'SHOULD' at most. There are applications which require only one reply. There are millions of resolvers deployed today which would only await one reply and could otherwise use mdns. > > [7] Remove 'search path' configuration text and replace it with text > > regarding a DHCP option to disable mdns behavior. > > This was extensively discussed previously. Recommend that we not make the > change. The problem is that search-path and other behavior are not necessarily interdependent. Overloading the interpretation of the search list is a bad idea. Why not have a distinct DHCP option which turns off mdns? > > [8] Change text: 'It is required to verify the uniqueness of the host > > DNS name when a host boots,...' to 'A host MAY verify...' > > Also discussed at length. Name conflicts can be a big problem, so it seems > prudent to err on the side of caution. Recommend rejecting the change. These comments concern [8], [9] and [10] also. Different addresses are often assigned the same name, to provide redundency. These are effectively aliases. Unless we make the change, it would not be possible to support this useful feature with mdns! At most a SHOULD here. There are good reasons for detecting name conflicts, just as there are good reasons, sometimes, for not considering multiple assignments of the same name as a conflict. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 16 14:22:45 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16152 for ; Wed, 16 May 2001 14:22:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1505Sx-0008iM-00 for namedroppers-data@psg.com; Wed, 16 May 2001 10:52:07 -0700 Received: from h-135-207-28-34.research.att.com ([135.207.28.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 1505Sw-0008iE-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 10:52:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 1505Sr-0000LU-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 13:52:01 -0400 Date: Wed, 16 May 2001 17:14:38 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: summary/conclusion of discussion on mdns-00 To: Bernard Aboba Cc: Erik Guttman , Namedroppers , levone@microsoft.com, dthaler@Exchange.Microsoft.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This one was extensively discussed already, and WG consensus was to use > .local.arpa. So default should be to reject the change unless it can be > demonstrated that the WG has changed its mind. When thinking about local.arpa it would be good to take a look at draft-iab-arpa-01.txt. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 16 15:13:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17423 for ; Wed, 16 May 2001 15:13:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1506Rj-0009yQ-00 for namedroppers-data@psg.com; Wed, 16 May 2001 11:54:55 -0700 Received: from h-135-207-28-34.research.att.com ([135.207.28.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 1506Rj-0009yF-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 11:54:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 1506Re-0000gp-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 14:54:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 May 2001 13:26:32 -0400 From: "Nicolae, Dan" Subject: RE: summary/conclusion of discussion on mdns-00 To: "'Olafur Gudmundsson'" , Namedroppers Message-id: <3820E1EF15CCD411B4E600508BAED1F45BC8FE@usa0111ms2.eng.mc.xerox.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >[9] Change text: 'A gratuitous name resolution query SHOULD be done > > to check for a name conflict. This is done by having > the resolver > > send a multicast query for a SOA type query for its own > name (i.e. > > for the name it is authoritative for.' > > s/SHOULD/MAY/ > > s/SOA/A/ > > No way this change should be done!!! Read notes from the > Adelaide lunch > meeting to understand why. > Are these notes available on-line, or were they sent to the namedroppers list? I can't locate them in the archive. 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 Wed May 16 15:14:26 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17448 for ; Wed, 16 May 2001 15:14:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1506Oc-0009tL-00 for namedroppers-data@psg.com; Wed, 16 May 2001 11:51:42 -0700 Received: from h-135-207-28-34.research.att.com ([135.207.28.34] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 1506Ob-0009tF-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 11:51:41 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 1506Oa-0000fg-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 14:51:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bernard Aboba Cc: Erik Guttman , Namedroppers , levone@microsoft.com, dthaler@Exchange.Microsoft.com In-reply-to: aboba's message of Tue, 15 May 2001 15:52:59 MST. Subject: Re: summary/conclusion of discussion on mdns-00 From: Jun-ichiro itojun Hagino Date: Wed, 16 May 2001 23:49:40 +0900 Message-Id: <20010516144940.167DD7E2@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> [6] Change 'Sender MUST anticipate receiving multiple replies' to >> MAY. >If multiple replies are possible, then the sender MUST anticipate >them. Recommend to not accept the change. >> [8] Change text: 'It is required to verify the uniqueness of the host >> DNS name when a host boots,...' to 'A host MAY verify...' >Also discussed at length. Name conflicts can be a big problem, so it seems >prudent to err on the side of caution. Recommend rejecting the change. I'm seeing a little bit of conflict between [6] and [8], if everything works perfectly. mdns responder (server?) will respond to foo.local.arpa, iff the device is called "foo" or "foo.local.arpa" (*). so if [8] is always true, we don't need to care about multiple responses. if there's possibility for [8] to be false, we need to care about multiple responses. in realworld situation, yes, [8] may not be true (even though every devices try to verify the uniqueness of name), and thus we need to consider [6]. i'd like to see some comment/footnote in the draft, to help people understand the background (i don't think we need to change the wording itself). (*) in the past draft proxy replies (bar replies to query to "foo" if bar knows foo) were permitted, but now is dropped. >> [9] Change text: 'A gratuitous name resolution query SHOULD be done >> to check for a name conflict. This is done by having the resolver >> send a multicast query for a SOA type query for its own name (i.e. >> for the name it is authoritative for.' >> s/SHOULD/MAY/ >> s/SOA/A/ >Again, I think that name conflicts are a problem and caution is >advised. Recommend against the change. i strongly object against s/SOA/A/ change. we can't assume that every device has an IPv4 address (think of IPv6 only devices). 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 May 17 03:10:19 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11490 for ; Thu, 17 May 2001 03:10:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 150HVJ-000NK0-00 for namedroppers-data@psg.com; Wed, 16 May 2001 23:43:21 -0700 Received: from roam.psg.com ([147.28.0.10] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 150HVJ-000NJl-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 23:43:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 150GmL-0001v6-00 for namedroppers@ops.ietf.org; Wed, 16 May 2001 22:56:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 May 2001 16:42:56 -0400 From: "Nicolae, Dan" Subject: RE: summary/conclusion of discussion on mdns-00 To: "'Erik Nordmark'" , Bernard Aboba Cc: Erik Guttman , Namedroppers , levone@microsoft.com, dthaler@Exchange.Microsoft.com Message-id: <3820E1EF15CCD411B4E600508BAED1F45BC901@usa0111ms2.eng.mc.xerox.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > This one was extensively discussed already, and WG > consensus was to use > > .local.arpa. So default should be to reject the change > unless it can be > > demonstrated that the WG has changed its mind. > > When thinking about local.arpa it would be good to take a look at > draft-iab-arpa-01.txt. > > Erik > I could not find any indication in draft-iab-arpa-01.txt that the arpa domain is appropriate for mDNS purposes: "This domain is termed an "infrastructure domain", as its role is to support the operating infrastructure of the Internet. In particular, the ARPA domain is not to be used in the same manner (e.g. for naming hosts) as other generic Top Level Domains are commonly used." Any non-existent domain name could be used with the same results. The intents of using local.arpa are not clearly stated in the document. I gather that the rationales are: [a] to avoid the definition of a new DHCP option to enable/disable mDNS [b] to prevent a mDNS host to behave like an authoritative DNS server for a 'real', administratively managed domain name Is that right? Are these the rationales? Dan P.S. As a side note, I can't identify the "single change to the method of use"; it seems like there are quite a few changes: "This document discusses multicast DNS, an extension to the DNS protocol which consists of a single change to the method of use, and no change to the format of DNS packets." to unsubscribe send a message to 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 May 18 17:20:35 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16559 for ; Fri, 18 May 2001 17:20:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 150rFr-0008fy-00 for namedroppers-data@psg.com; Fri, 18 May 2001 13:53:47 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 150rFr-0008fr-00 for namedroppers@ops.ietf.org; Fri, 18 May 2001 13:53:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 150rFr-00070G-00 for namedroppers@ops.ietf.org; Fri, 18 May 2001 13:53:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20010518135131.0514d4a8@127.0.0.1> Date: Fri, 18 May 2001 13:56:34 +0200 To: Olafur Gudmundsson From: Harald Tveit Alvestrand Subject: Re: summary/conclusion of discussion on mdns-00 Cc: Erik Guttman , Namedroppers In-Reply-To: <5.1.0.14.0.20010515165008.05138d80@localhost> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 17:01 15.05.2001 -0400, Olafur Gudmundsson wrote: > >[7] Remove 'search path' configuration text and replace it with text > > regarding a DHCP option to disable mdns behavior. > >Does such an option exist? >I worry that not specifying in this document how to do this people will >go different ways. Is there any reason why a DHCP response containing a DNS server address should NOT disable MDNS behaviour? Seems to me that if an admin bothers to tell you a DNS server to use, it is rather strange behaviour to use the multicast model. Harald, department of wheel non-reinvention to unsubscribe send a message to 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 May 19 03:47:11 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09911 for ; Sat, 19 May 2001 03:47:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1510rg-000IXT-00 for namedroppers-data@psg.com; Sat, 19 May 2001 00:09:28 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1510rf-000IXN-00 for namedroppers@ops.ietf.org; Sat, 19 May 2001 00:09:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1510rf-000Mfm-00 for namedroppers@ops.ietf.org; Sat, 19 May 2001 00:09:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Harald Tveit Alvestrand cc: Olafur Gudmundsson , Erik Guttman , Namedroppers Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: <4.3.2.7.2.20010518135131.0514d4a8@127.0.0.1> References: <4.3.2.7.2.20010518135131.0514d4a8@127.0.0.1> Date: Sat, 19 May 2001 13:09:55 +0700 Message-ID: <1270.990252595@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Fri, 18 May 2001 13:56:34 +0200 From: Harald Tveit Alvestrand Message-ID: <4.3.2.7.2.20010518135131.0514d4a8@127.0.0.1> | Is there any reason why a DHCP response containing a DNS server address | should NOT disable MDNS behaviour? This seems like a much better idea than any of the previous proposals. There is (obviously) no "disable mDNS" option in DHCP currently, but nor is there a "set the search list" option - though there has been a proposal for the latter I believe. But even if completed, it is currently supported by no-one. It almost seems to me that just getting a dhcp response ought be nearly enough to disable mDNS - if there's a configured dhcp server, then whether it tells you about DNS servers or not, it is obviously telling you what the administrator wants you to know. But as I said, "almost" - unfortunately there are dhcp servers around these days that simply turn themselves on, and respond with whatever they believe the clients need to know, with little or no administrator action. Fortunately though they can't start sending out DNS server addresses without knowing there are actually DNS servers at the addresses (back end resolvers really, calling them servers is a mistake) so Harald's suggestion makes a lot of sense. What's more, as soon as that "magic string in the search list" stuff is gone, the whole "local.arpa" nonsense can go with it (which isn't to say that people shouldn't use that necessarily, just that there's no reason at all to compel it). (ie: unlike some others on the list, I agree with proposed change #1). As it is, it isn't at all clear from the draft how it is to be used - if the theory is that it would be used like any other domain in the search list, and then, when doing a lookup inside it, mDNS would be used - then it doesn't work very well as seems has been assumed. In particular, the search list is usually only used for unqualified names "foo" rather than for names containing dots, and is never used for FQDN's. That means only unqualified names can ever be found using mDNS (or that's all you can rely upon). Since unqualified names aren't legal in many places (such as in e-mail) this would rather severely restrict the utility of the approach. A better approach is simply to allow a node which has no DNS back end resolver configured (ie: neither the DNS, nor the local admin/user has set one) to send mDNS queries for any name it wants to look up. Then it either gets a positive response, or it gets nothing (I'm not actually sure that stopping a properly configured resolver back end from sending negative replies is needed - that could save some delays, and I don't see any immediate harm from that - but nor is it essential to allow it, and preventing thousands of replies because everyone thinks they properly know there is no such name is certainly required). I'm also not sure that simply doing a query for the name I want to claim, and grabbing it if there's no response (or the response identifies me) is adequate. I think I'd prefer to have the node send a dynamic DNS "add me if I don't exist" type transaction. Then, if anyone else out there has the name, they'd respond, and return an error (name already exists). If no-one has the name, no response, just as before, and things continue. That seems to be just the same - but this way, if there is a properly configured back end resolver, it could take that "add me" and send it to the server for the domain, and actually cause the node to be registered in the global DNS, if that's what the local site admins want to happen (it isn't mandatory, just an option). No-one can do that merely from a query (or series of queries) for the name. Not only does this add functionality, but it also allows a test "does the name exist" which (other than sending a query type ANY, which has other potential problems) otherwise doesn't exist in the DNS. Certainly mandating that the query be A is wrong, as Itojun pointed out - but doing an SOA query seems to totally misunderstand where SOA records actually exist (unless mDNS "responders" aren't to interpret such a query the same way that any normal DNS server would). kre ps: please change all uses of "multicasted" in the doc to just "multicast". to unsubscribe send a message to 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 May 21 14:16:53 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15610 for ; Mon, 21 May 2001 14:16:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 151tkY-000L5d-00 for namedroppers-data@psg.com; Mon, 21 May 2001 10:45:46 -0700 Received: from h166s103a81n47.user.nortelnetworks.com ([47.81.103.166] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 151tkY-000L2B-00 for namedroppers@ops.ietf.org; Mon, 21 May 2001 10:45:46 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 151tjx-0002nM-00 for namedroppers@ops.ietf.org; Mon, 21 May 2001 10:45:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: summary/conclusion of discussion on mdns-00 Date: Mon, 21 May 2001 09:05:26 -0700 Message-ID: From: "Christian Huitema" To: "Robert Elz" , "Harald Tveit Alvestrand" Cc: "Namedroppers" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > From: Robert Elz [mailto:kre@munnari.OZ.AU] > From: Harald Tveit Alvestrand > Message-ID: <4.3.2.7.2.20010518135131.0514d4a8@127.0.0.1> > > | Is there any reason why a DHCP response containing a DNS server address > | should NOT disable MDNS behaviour? > > This seems like a much better idea than any of the previous proposals. Well, it boils down to "if the node has unicast access to a DNS server, it should not initiate mDNS queries." In fact, it does not matter much how the DNS server has been found -- DHCP or explicit configuration would do. > It almost seems to me that just getting a dhcp response ought be nearly > enough to disable mDNS - if there's a configured dhcp server, then whether > it tells you about DNS servers or not, it is obviously telling you what > the administrator wants you to know. Nope. One thing is to heed explicit DHCP advice, "the dns server is there", and another is to extrapolate that if there is a DHCP server, an administrator might have used it to configure a dns server option. In fact, we have to also consider transient states. For example, is it OK to use mDNS if the node has lost contact with the configured DNS server ? -- Christian Huitema to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon May 21 15:23:21 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16815 for ; Mon, 21 May 2001 15:23:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 151utd-0001lM-00 for namedroppers-data@psg.com; Mon, 21 May 2001 11:59:13 -0700 Received: from h166s103a81n47.user.nortelnetworks.com ([47.81.103.166] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 151utc-0001kM-00 for namedroppers@ops.ietf.org; Mon, 21 May 2001 11:59:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 151ut7-0002u9-00 for namedroppers@ops.ietf.org; Mon, 21 May 2001 11:58:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.1.0.14.0.20010521143607.0503a5f0@localhost> Date: Mon, 21 May 2001 14:42:46 -0400 To: Harald Tveit Alvestrand , Olafur Gudmundsson From: Olafur Gudmundsson Subject: Re: summary/conclusion of discussion on mdns-00 Cc: Erik Guttman , Namedroppers In-Reply-To: <4.3.2.7.2.20010518135131.0514d4a8@127.0.0.1> References: <5.1.0.14.0.20010515165008.05138d80@localhost> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 07:56 18-05-2001, Harald Tveit Alvestrand wrote: > At 17:01 15.05.2001 -0400, Olafur Gudmundsson wrote: >>> [7] Remove 'search path' configuration text and replace it with text >>> regarding a DHCP option to disable mdns behavior. >> >> Does such an option exist? >> I worry that not specifying in this document how to do this people will >> go different ways. > > Is there any reason why a DHCP response containing a DNS server address > should NOT disable MDNS behaviour? > Seems to me that if an admin bothers to tell you a DNS server to use, it is > rather strange behaviour to use the multicast model. The text in the MDNS document is supposed to explain the following: if a host gets configured by DHCP, it can ONLY use MDNS when the DHCP server includes the string "local.arpa." in the search path. This avoids reserving a special DHC option, but still allows turning MDNS on in DHCP configured environment. > Harald, department of wheel non-reinvention Olafur, department of constant changes. to unsubscribe send a message to 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 May 21 19:54:33 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20822 for ; Mon, 21 May 2001 19:54:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 151z7G-0005Oh-00 for namedroppers-data@psg.com; Mon, 21 May 2001 16:29:34 -0700 Received: from h166s103a81n47.user.nortelnetworks.com ([47.81.103.166] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 151z7F-0005OU-00 for namedroppers@ops.ietf.org; Mon, 21 May 2001 16:29:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 151z6k-0003Bc-00 for namedroppers@ops.ietf.org; Mon, 21 May 2001 16:29:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 21 May 2001 16:12:30 -0700 (PDT) From: Bernard Aboba To: Christian Huitema cc: Robert Elz , Harald Tveit Alvestrand , Namedroppers Subject: RE: summary/conclusion of discussion on mdns-00 In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Well, it boils down to "if the node has unicast access to a DNS server, > it should not initiate mDNS queries." In fact, it does not matter much > how the DNS server has been found -- DHCP or explicit configuration > would do. > Assuming that mDNS usage is controlled by the searchlist, then if ".local.arpa" is not in the searchlist, mDNS will not be used, whether there is a DNS server or not. If ".local.arpa" is last in the searchlist, then if a DNS server is available and answers, then mDNS will not be used (modulo use of intelligent DNS resolver timers). > > It almost seems to me that just getting a dhcp response ought be nearly > > enough to disable mDNS - if there's a configured dhcp server, then whether > > it tells you about DNS servers or not, it is obviously telling you what > > the administrator wants you to know. If the DHCP server returns the searchlist option, then the DNS resolver is controlled by the contents of the option. If the DHCP server returns neither a DNS server option nor a searchlist option, then the default searchlist (with no ".local.arpa" included) is assumed, and mDNS will not be used. If the DHCP server returns a DNS server option and no searchlist option, that unicast DNS server will be used and there will be no mDNS usage. If the DHCP server returns a DNS server option and a searchlist option with ".local.arpa" last in the searchlist, then mDNS will be used, but only as a last resort. > Nope. One thing is to heed explicit DHCP advice, "the dns server is > there", and another is to extrapolate that if there is a DHCP server, an > administrator might have used it to configure a dns server option. Indeed. This is why the behavior with no searchlist option is *not* to use mDNS. You don't want an upgraded client to change its behavior from the current default. So to turn mDNS on, you either need no DHCP server at all, or you need to return the searchlist option with ".local.arpa" somehwere in the searchlist. > In fact, we have to also consider transient states. For example, is it > OK to use mDNS if the node has lost contact with the configured DNS > server ? > The current answer is that if ".local.arpa" is last in the searchlist, then mDNS will be used after unicast attempts have failed. This can cause use of mDNS after transient DNS server failures. Back in the days when mDNS used site scope multicast, this was a substantial cause for concern. However, now that mDNS is purely linklocal, the effects have been diminished. I'd note that the usage of mDNS in this scenario will still depend on the resolver's failover behavior, which is currently undefined. In some cases, mDNS might end up being used even when the unicast server is up, just responding slowly. Many resolvers don't adjust their sending behavior to the DNS RTT, and some premature mDNS usage is conceivable (or even likely). to unsubscribe send a message to 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 May 22 10:39:05 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20382 for ; Tue, 22 May 2001 10:39:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152Cw9-000Ex8-00 for namedroppers-data@psg.com; Tue, 22 May 2001 07:15:01 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152Cw7-000Ewx-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 07:14:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152Cw6-0003ld-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 07:14:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "Christian Huitema" cc: "Harald Tveit Alvestrand" , "Namedroppers" Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: References: Date: Tue, 22 May 2001 17:23:05 +0700 Message-ID: <3163.990526985@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 21 May 2001 09:05:26 -0700 From: "Christian Huitema" Message-ID: | Nope. One thing is to heed explicit DHCP advice, Yes, that's what I said in the rest of my paragraph... | In fact, we have to also consider transient states. For example, is it | OK to use mDNS if the node has lost contact with the configured DNS | server ? Probably it isn't. If the node isn't doing mDNS, then it won't have done an mDNS name check either (however that ends up being defined to be done). Nor will other nodes, most of which will have been configured the same way (assuming this is coming from DHCP advice, or similar - if there's none of that, then all nodes able will be doing mDNS all the time, and others never will, so that isn't an issue). The effect of allowing transient access would be that a short reachability outage of the configured DNS servers would result in mDNS queries on the local cable, looking for names that are quite probably not unique there, and hence getting multiple responses, with no way of determining which one is the "correct" one. I think having communications just fail (as they do now) in that scenario is better. I suppose a "solution" there would be to require that any mDNS aware device always do a mDNS name query when it is assigned its name, to check it for uniqueness, regardless of whether it will use mDNS for queries later on. That then requires all (mDNS aware) nodes to always listen for mDNS queries, and reply when appropriate, even when they're not making mDNS queries themselves. All this also leaves aside the question of how a resolver determines that there is a transient failure - your typical resolver starts fresh with every new application that is run, with no history at all of what was done just milliseconds before, and no way to leave advice for queries to be made milliseconds later. Get in fast, get an answer, use it, and go away is a common approach. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 22 10:39:15 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20387 for ; Tue, 22 May 2001 10:39:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152Cvu-000Ews-00 for namedroppers-data@psg.com; Tue, 22 May 2001 07:14:46 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152Cvs-000Ewm-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 07:14:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152Cvp-0003lZ-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 07:14:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Bernard Aboba cc: Christian Huitema , Harald Tveit Alvestrand , Namedroppers Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: References: Date: Tue, 22 May 2001 17:08:50 +0700 Message-ID: <3141.990526130@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 21 May 2001 16:12:30 -0700 (PDT) From: Bernard Aboba Message-ID: | If the DHCP server returns the searchlist option, What DHCP searchlist option??? Even assuming that such a thing eventually gets defined by the IETF, and that sometime in the future, DHCP servers support it, using a magic string in it to control something other than the domains to search seems terribly wrong. What if I want my DNS lookups to search the local.arpa domain, but I don't want to use mDNS ? If you really have to pervert the value of a DHCP option to control this behaviour (for the cases where DHCP is used) - and you don't want to wait for a new DHCP option to be defined, it seems that it would be just as good to designate a "magic" IP address, and say that mDNS is to be used only if the DHCP server returns that IP address as (one of) the DNS servers to be queried. (The magic address could be 127.127.127.127 or something like that, that is going to do no harm to anyone who receives it and doesn't understand that it is meant to signal use of mDNS - unlike local.arpa which will have queries from old resolvers (if any that implement the non-existent DHSP searchlist option can be found) banging on the root servers looking for an NS list for local.arpa ...) You could keep the order dependence - query servers in the order they're given, doing mDNS instead of a query of the magic address in its turn. Of course, here there's some cause for problems caused by the general decoupling of the DHCP client, and of the DNS resolver. I suspect that you anticipate that most resolvers will do mDNS if the local.arpa domain is in the searchlist that they're using. DHCP clients (ones I know anyway) tend to build the searchlist out of the DHCP "domain name" option. DHCP doesn't care that spaces occur in that option - resolvers treat the spaces as separating domains, and most code treats the first element of the search list as the "default domain". But an implementation that worked like this couldn't conform to your current spec - as passing "local.arpa" in the "domain name" string isn't specified as enabling mDNS, only passing it in the "searchlist" option (whatever it turns out to be). So, implementations would actually need to pass a new flag from the dhcp client to the resolver, indicating whether the search list handed to the resolver came from the domain name option, or from the search list option. This all gets very messy. Not at all clean. In fact, down right ugly. | I'd note that the usage of mDNS in this scenario will still | depend on the resolver's failover behavior, which is currently undefined. Since current resolvers won't do mDNS at all, this is irrelevant. If you need failover behaviour defined for use with mDNS, define it - then the resolvers bahaviour (mDNS implementing reslvers) won't be undefined. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 22 11:05:57 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21587 for ; Tue, 22 May 2001 11:05:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152DPo-000FI5-00 for namedroppers-data@psg.com; Tue, 22 May 2001 07:45:40 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152DPm-000FHq-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 07:45:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152DPl-0003oW-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 07:45:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105221443.QAA13384@ehdb03-home.Germany.Sun.COM> Date: Tue, 22 May 2001 16:43:02 +0200 (MEST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: summary/conclusion of discussion on mdns-00 To: kre@munnari.OZ.AU Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > Is there any reason why a DHCP response containing a DNS server > address should NOT disable MDNS behaviour? What if the DNS servers the DHCP response indicates are not available? It would be a shame not to disallow mDNS in this case. The goal of ZEROCONF name resolution is to allow local resolution of names even if DNS servers fail, DHCP servers supply incorrect information, etc. Robert Elz wrote: > "Christian Huitema" wrote: > | In fact, we have to also consider transient states. For example, is > | it OK to use mDNS if the node has lost contact with the configured > | DNS server ? > > Probably it isn't. If the node isn't doing mDNS, then it won't have > done an mDNS name check either (however that ends up being defined to > be done). Nor will other nodes, most of which will have been > configured the same way (assuming this is coming from DHCP advice, or > similar - if there's none of that, then all nodes able will be doing > mDNS all the time, and others never will, so that isn't an issue). If all DNS servers known to a resolver are not responding, why shouldn't a resolver use mDNS to attempt to resolve a name? If the resolver has been told not to (by some DHCP configuration, say) it shouldn't. But otherwise, why not? > All this also leaves aside the question of how a resolver determines > that there is a transient failure - your typical resolver starts fresh > with every new application that is run, with no history at all of what > was done just milliseconds before, and no way to leave advice for queries > to be made milliseconds later. Get in fast, get an answer, use it, and > go away is a common approach. I agree. And does it need to be more complicated than that? As long as the resolvers check if their configured DNS servers are available, what's the harm falling back to mDNS as a last resort? Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 22 12:29:13 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24500 for ; Tue, 22 May 2001 12:29:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152Ehm-000Ge6-00 for namedroppers-data@psg.com; Tue, 22 May 2001 09:08:18 -0700 Received: from h166s103a81n47.user.nortelnetworks.com ([47.81.103.166] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 152Ehm-000Gds-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 09:08:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152EhI-0003qw-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 09:07:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Erik Guttman cc: namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: <200105221443.QAA13384@ehdb03-home.Germany.Sun.COM> References: <200105221443.QAA13384@ehdb03-home.Germany.Sun.COM> Date: Tue, 22 May 2001 22:18:58 +0700 Message-ID: <7972.990544738@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 22 May 2001 16:43:02 +0200 (MEST) From: Erik Guttman Message-ID: <200105221443.QAA13384@ehdb03-home.Germany.Sun.COM> | What if the DNS servers the DHCP response indicates are not available? | It would be a shame not to disallow mDNS in this case. I think you mean allow... | The goal of | ZEROCONF name resolution is to allow local resolution of names even if | DNS servers fail, DHCP servers supply incorrect information, etc. Part of this is who is to be in charge of the network. If it is my network, and I don't want any mDNS on it, for whatever reason, you're saying that it is none of my business, and that nodes should go ahead and use mDNS whenever they think things aren't working? Even the draft doesn't suggest that. And if you agree that it should be possible to disable mDNS, all that is left is the question of exactly how that is done. | If all DNS servers known to a resolver are not responding, why shouldn't | a resolver use mDNS to attempt to resolve a name? If the resolver has | been told not to (by some DHCP configuration, say) it shouldn't. But | otherwise, why not? The assumption has been here that the resolver has been told not to - the question then was what happens if even then the configured DNS servers that it has been using become unreachable, can the node ignore the instruction and go ahead and use mDNS anyway. It seems that you agree. "no". If the node has been told it can use mDNS, but only after it has tried (whatever) and it has tried whatever, and that failed, then of course, it should use mDNS. (In some cases "whatever" might be "nothing" and mDNS is all that is used). | I agree. And does it need to be more complicated than that? As long | as the resolvers check if their configured DNS servers are available, | what's the harm falling back to mDNS as a last resort? Again, what's the context. And in any case, how does the resolver know the DNS server is available, but slow, as compared with unavailable. If it had waited just one more half second, the answer would have come the normal way.... kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue May 22 13:08:27 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25845 for ; Tue, 22 May 2001 13:08:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152FLi-000Gz2-00 for namedroppers-data@psg.com; Tue, 22 May 2001 09:49:34 -0700 Received: from h166s103a81n47.user.nortelnetworks.com ([47.81.103.166] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 152FLi-000Gyo-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 09:49:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152FLE-0003sT-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 09:49:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B0A971C.FC9FD38C@ehsco.com> Date: Tue, 22 May 2001 09:43:08 -0700 From: "Eric A. Hall" CC: namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 References: <200105221443.QAA13384@ehdb03-home.Germany.Sun.COM> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with the complaint that the use of search lists is the wrong place to implement protocol. Stuffing the search list for a host does not ensure that the host is able to conform to the needs of the protocol, and will only obscure things. For example, a pre-mDNS host may have its search list stuffed with local.arpa but not be mDNS-aware, and in that case the resolver is likely to use local.arpa for local completion of relative names, and then attempt to resolve those names. That could be bad. With this in mind, it would seem that the best place to implement mDNS is just before local failure. Considering that there are several ways for any given host to be configured for DNS activity, mDNS should be the last loop before a lookup fails. If the host is configured for anything, then the mDNS function wouldn't be called. That gives the desired results and doesn't stuff interpretation. It also means we don't need a DHCP option or a search list extension or anything else. -- 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 Tue May 22 16:21:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03381 for ; Tue, 22 May 2001 16:21:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152HoG-000KjW-00 for namedroppers-data@psg.com; Tue, 22 May 2001 12:27:12 -0700 Received: from h166s103a81n47.user.nortelnetworks.com ([47.81.103.166] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 152HoG-000KjH-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 12:27:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152Hnm-0004m3-00 for namedroppers@ops.ietf.org; Tue, 22 May 2001 12:26:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 22 May 2001 12:13:39 -0700 (PDT) From: Bernard Aboba To: Erik Guttman cc: namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: <200105221443.QAA13384@ehdb03-home.Germany.Sun.COM> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > What's the harm in falling back to mDNS? I think there was originally some concern back when mDNS was using site scope multicast that a DNS outage could result in an enterprise wide flood of queries. Now that mDNS is linklocal only, the harm seems minimal. to unsubscribe send a message to 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 May 23 12:35:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09169 for ; Wed, 23 May 2001 12:35:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152bEX-000EDc-00 for namedroppers-data@psg.com; Wed, 23 May 2001 09:11:37 -0700 Received: from 120-59.nanog22.centergate.com ([204.74.120.59] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152bEW-000EDW-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:11:37 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152bEW-00053p-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:11:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Erik Guttman cc: namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: References: Date: Wed, 23 May 2001 16:42:15 +0700 Message-ID: <1941.990610935@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 23 May 2001 09:53:32 +0200 (MET DST) From: Erik Guttman Message-ID: | I believe the default (no configuration) and common use case (DHCP DNS | server configuration) should be to allow use of mDNS. This is really | the only place I think I am disagreeing with some folks posting to the | list. For no config, yes, I agree. Where there is config, then it matters much less, as the config can be be done anyway, if the default needs to be altered (and whatever the method, it won't be hard) - but I think the default should be that mDNS needs to be enabled explicitly, so the behaviour of current nets doesn't suddenly alter just by new (mDNS aware) clients starting to appear. That's the way the draft has it now, and I think that's the right way. Where I disagree is with the method by which the config info is passed to the clients (whichever was turns out to be the default). | No - I'm just saying mDNS should be permitted unless forbidden. | Obtaining DNS configuration from DHCP shouldn't be the same as | forbidding mDNS. As I just said, whichever way is the default doesn't matter all that much - some set of admins are going to have to change their config to get their desired behaviour. I'd just prefer that my net not just start behaving differently because I didn't change something. I'd prefer to have to do the config to get that to happen. | Receiving a DHCP DNS server option shouldn't turn off mDNS as a last | resort. This would mean that in the common case, where DHCP is used | and DNS servers fail (even for a while), one could not use mDNS. Yes. That's I think the right default, and it just leaves us exactly where we are today (where there is no mDNS). If on your net you would prefer to have people be able to use mDNS when the DNS servers (back end resolvers, I wish we could stop calling them servers) are not responding, all you need to do is set the option in your dhcp config. Whatever that option turns out to be. | There may be operational reasons, in some cases, to disable mDNS. I want | to distinguish this mode from other modes - such as a host being configured | to use certain DNS servers or being configured to use a particular set of | domains in its search list. Sure, I'd prefer that too. I actually believe that a new DHCP option is the right way to go, rather than trying to overload an existing one with a new meaning. The "magic address" proposal in the last message was just intended to show a different way that an existing option could be overloaded, which I think would work better. I don't think that is the right solution. But I think that option should enable mDNS (as should most probably not getting any DNS "server" list from DHCP at all - that's essentially returning the net to "no DNS configured" state). Without the option, and assuming that the DNS is configured, I'd leave mDNS off. | Isn't that an implementation decision? Any value we specify in seconds | to wait or adaptive timeout based on RTT will in some cases not be enough. | The real question is one of policy - is mDNS allowed or disallowed? Yes. But another policy question for a network might be "what constitutes failure". Implementation decision is fine - but if the implementations decide that "0.1 of a second, no DNS response, I'm using mDNS" then I'm really not going to like it. In "distant" parts of the (global) net it simply takes much longer than that to obtain most answers. But for some people, that might be exactly right - if most of your lookups are local, and mDNS will find them, and you don't want delays, 0.1s might be too long to be waiting for a regular DNS response (but you might still want to try it first, so there's a better chance that some local rogue mDNS responder won't claim to be your mail server's name, and intercept all your mail). So, this probably needs to be able to be configured (where the net is being configured) as well as the on/off switch. Another reason for simply using a new DHCP option to config mDNS, all of this data could be included in it. You said "Please see my argument below" for why you believe that mDNS should default to on, even in a configured net - but I didn't ever find the argument in the message (or nothing more than "one could not use mDNS" which is just a fact, and a desireable outcome...) kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 23 12:35:40 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09168 for ; Wed, 23 May 2001 12:35:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152bDh-000ECB-00 for namedroppers-data@psg.com; Wed, 23 May 2001 09:10:45 -0700 Received: from 120-59.nanog22.centergate.com ([204.74.120.59] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152bDg-000EC5-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:10:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152bDf-00053l-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:10:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Bernard Aboba cc: Erik Guttman , namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: References: Date: Wed, 23 May 2001 16:03:12 +0700 Message-ID: <1739.990608592@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Tue, 22 May 2001 12:13:39 -0700 (PDT) From: Bernard Aboba Message-ID: | > What's the harm in falling back to mDNS? | | I think there was originally some concern back when mDNS was using site | scope multicast that a DNS outage could result in an enterprise wide flood | of queries. Now that mDNS is linklocal only, the harm seems minimal. It can still result in a lot of queries - with big switched nets being created sometimes, a "link" can reach a lot of systems. It would help if the link local multicast address created was an address that depends upon the name to be located (some kind of hash as is done in IPv6 ND) but that's still doing to only be a smallish power of two divisor (and isn't how it is now spec'd, and certainly complicates implementations). Whether mDNS should be used when normal DNS resolution has failed is another thing that needs to be able to be configured (in environments where things get configured), as distinct from when it should be used when regular DNS has succeeded, but failed to locate the name (which is what putting "local.arpa" at the end of the search list is currently defined to do). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 23 12:35:42 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09193 for ; Wed, 23 May 2001 12:35:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152bHY-000EIx-00 for namedroppers-data@psg.com; Wed, 23 May 2001 09:14:44 -0700 Received: from 120-59.nanog22.centergate.com ([204.74.120.59] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152bHX-000EIr-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:14:43 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152bHW-000548-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:14:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Erik Guttman cc: namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: <200105231033.MAA01845@ehdb03-home.Germany.Sun.COM> References: <200105231033.MAA01845@ehdb03-home.Germany.Sun.COM> Date: Wed, 23 May 2001 18:29:42 +0700 Message-ID: <2218.990617382@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 23 May 2001 12:33:47 +0200 (MEST) From: Erik Guttman Message-ID: <200105231033.MAA01845@ehdb03-home.Germany.Sun.COM> | The only problem with this suggestion I see is that there're many DHCP | servers which don't support this option Of course, as there are also many which don't support the currently not yet defined search list option. No big difference there. If we wanted something which works with current DHCP servers, then something like the "magic address in the DNS server list option" would be needed - but that really is pretty ugly. | A *better* outcome would be to allow mDNS in configured networks. Sure, I have no problem with that. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 23 12:35:43 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09188 for ; Wed, 23 May 2001 12:35:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152bFW-000EFQ-00 for namedroppers-data@psg.com; Wed, 23 May 2001 09:12:38 -0700 Received: from 120-59.nanog22.centergate.com ([204.74.120.59] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152bFW-000EFJ-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:12:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152bFW-00053y-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:12:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105231033.MAA01845@ehdb03-home.Germany.Sun.COM> Date: Wed, 23 May 2001 12:33:47 +0200 (MEST) From: Erik Guttman Subject: Re: summary/conclusion of discussion on mdns-00 To: kre@munnari.OZ.AU Cc: Erik Guttman , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I'd prefer to have to do the config to get that to happen. > > | There may be operational reasons, in some cases, to disable mDNS. > | I want to distinguish this mode from other modes - such as a host > | being configured to use certain DNS servers or being configured > | to use a particular set of domains in its search list. > > Sure, I'd prefer that too. I actually believe that a new DHCP option > is the right way to go, rather than trying to overload an existing one > with a new meaning. > But I think that option should enable mDNS (as should most probably not > getting any DNS "server" list from DHCP at all - that's essentially > returning the net to "no DNS configured" state). Without the option, > and assuming that the DNS is configured, I'd leave mDNS off. A DHCP option to turn on mDNS explicitely makes good sense. The only problem with this suggestion I see is that there're many DHCP servers which don't support this option - so enabling mDNS in configured networks could require DHCP server upgrades. But following your very reasonable principal, this is not so bad: > I'd just prefer that my net not just start behaving differently > because I didn't change something. > | Isn't that an implementation decision? Any value we specify in > | seconds to wait or adaptive timeout based on RTT will in some > | cases not be enough. The real question is one of policy - is > | mDNS allowed or disallowed? > > Yes. But another policy question for a network might be "what constitutes > failure". > Another reason for simply using a new DHCP option to config mDNS, all of > this data could be included in it. I think this is a great idea. > You said "Please see my argument below" for why you believe that mDNS should > default to on, even in a configured net - but I didn't ever find the > argument in the message (or nothing more than "one could not use mDNS" > which is just a fact, and a desireable outcome...) Sorry I wasn't clear. Consider: The common configured case is to receive DHCP DNS server configuration. This configuration may not provide the location of any *currently* available DNS back end resolvers (which may be down, or so slow in responding the resolver considers it to be down). If this (same) DNS server configuration disables mDNS, one cannot use it in precisely the situation where it would be valuable - as a last resort. Harald's suggestion allows mDNS in only unconfigured networks. This certainly achieves your desire that 'my net not just start behaving differently because I didn't change something.' A *better* outcome would be to allow mDNS in configured networks. OK, not by default, but by configuration. Let's pursue the DHCP mDNS-Enable option. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 23 12:35:45 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09204 for ; Wed, 23 May 2001 12:35:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152b5U-000E1I-00 for namedroppers-data@psg.com; Wed, 23 May 2001 09:02:16 -0700 Received: from 120-59.nanog22.centergate.com ([204.74.120.59] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152b5T-000E15-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:02:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152b5R-00053V-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:02:13 -0700 Date: Wed, 23 May 2001 09:53:32 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: summary/conclusion of discussion on mdns-00 To: Robert Elz Cc: Erik Guttman , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <7972.990544738@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I believe the default (no configuration) and common use case (DHCP DNS server configuration) should be to allow use of mDNS. This is really the only place I think I am disagreeing with some folks posting to the list. > | What if the DNS servers the DHCP response indicates are not available? > | It would be a shame not to disallow mDNS in this case. > I think you mean allow... Yes - oops. > | The goal of > | ZEROCONF name resolution is to allow local resolution of names even if > | DNS servers fail, DHCP servers supply incorrect information, etc. > > Part of this is who is to be in charge of the network. If it is > my network, and I don't want any mDNS on it, for whatever reason, > you're saying that it is none of my business, and that nodes should > go ahead and use mDNS whenever they think things aren't working? No - I'm just saying mDNS should be permitted unless forbidden. Obtaining DNS configuration from DHCP shouldn't be the same as forbidding mDNS. Please see my argument below. > Even the draft doesn't suggest that. And if you agree that it should > be possible to disable mDNS, all that is left is the question of exactly > how that is done. Receiving a DHCP DNS server option shouldn't turn off mDNS as a last resort. This would mean that in the common case, where DHCP is used and DNS servers fail (even for a while), one could not use mDNS. There may be operational reasons, in some cases, to disable mDNS. I want to distinguish this mode from other modes - such as a host being configured to use certain DNS servers or being configured to use a particular set of domains in its search list. > | I agree. And does it need to be more complicated than that? As long > | as the resolvers check if their configured DNS servers are available, > | what's the harm falling back to mDNS as a last resort? > > Again, what's the context. And in any case, how does the resolver know > the DNS server is available, but slow, as compared with unavailable. If > it had waited just one more half second, the answer would have come the > normal way.... Isn't that an implementation decision? Any value we specify in seconds to wait or adaptive timeout based on RTT will in some cases not be enough. The real question is one of policy - is mDNS allowed or disallowed? Thanks for working through these issues carefully. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 23 12:43:01 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09343 for ; Wed, 23 May 2001 12:42:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152bCW-000EAD-00 for namedroppers-data@psg.com; Wed, 23 May 2001 09:09:32 -0700 Received: from 120-59.nanog22.centergate.com ([204.74.120.59] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152bCV-000EA7-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:09:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152bCT-00053h-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 09:09:29 -0700 To: namedroppers@ops.ietf.org Subject: A6 TTL timeout From: itojun@iijlab.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <24505.990606822.0@itojun.org> Date: Wed, 23 May 2001 17:36:19 +0900 Message-ID: <24518.990606979@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24505.990606822.1@itojun.org> while I'm working on A6/AAAA thing, I found an interesting complication in A6 and timeout management. I could not find any relevant notes in RFC2874. for example, I have the following zone definition. a.deadbeef.itojun.org. has 16 A6 fragments. when I configure another recursive-lookup nameserver (BIND 9.2.0 beta, feb2001, marked as "resolver" in tcpdump output) for AAAA synthesis, I guess BIND 9.2.0 violates TTL in cache management. it consults already-expired A6 fragments for the lower bits. by the time "resolver" machine gets the A6 fragments for the higher bits (like a0.deadbeef.itojun.org.), lower bits (like a120.deadbeef.itojun.org.) has already been expired (as TTL = 0 and nearly 1 second has passed). it will get serious if we have more delays between "resovler" machine and "nameserver" machine. if we implement cache management in "resolver" machine naively, AAAA synthesis can be used as DoS attack - native implementation may try to query A6 forever. luckily BIND 9.2.0 was okay. also, I have no idea the following timeout parameter should interact. - the original querier, waiting for full 128bit IPv6 address - AAAA query from the original querier - each query for A6 fragment - TTL management for A6 fragments in the cache even without AAAA synthesis, timeout parameter management bothers me a lot. i can say that AAAA synthesis is not that simple. after I get some clarification on this, I will submit my take on AAAA/A6 thing as the draft (before redmond ipngwg interim). btw: BIND9 resolver limits # of A6 fragments to 16 (NOTE: it is not the protocol parameter, but implementation choice), so it won't resolve d.deadbeef.itojun.org. is it a reasonable limitation? itojun ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24505.990606822.2@itojun.org> 17:21:08.281899 resolver.53 > nameserver.53: [udp sum ok] 28363 [1au] A6? a.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (50) (len 58, hlim 64) 17:21:08.347821 nameserver.53 > resolver.53: [udp sum ok] 28363* q: A6? a.deadbeef.itojun.org. 2/1/18 a.deadbeef.itojun.org. CNAME a120.deadbeef.itojun.org., a120.deadbeef.itojun.org. A6 120 ::1 a112.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a112.deadbeef.itojun.org. A6 112 :: a104.deadbeef.itojun.org., a104.deadbeef.itojun.org. A6 104 :: a96.deadbeef.itojun.org., a96.deadbeef.itojun.org. A6 96 :: a88.deadbeef.itojun.org., a88.deadbeef.itojun.org. A6 88 :: a80.deadbeef.itojun.org., a80.deadbeef.itojun.org. A6 80 :: a72.deadbeef.itojun.org., a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org., a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (855) (len 863, hlim 61) 17:21:08.353121 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:507:1:1:2ae:d0ff:fe00:3b.53: [udp sum ok] 18724 [1au] A6? a120.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (53) (len 61, hlim 64) 17:21:08.397794 3ffe:507:1:1:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 18724* q: A6? a120.deadbeef.itojun.org. 1/1/18 a120.deadbeef.itojun.org. A6 120 ::1 a112.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a112.deadbeef.itojun.org. A6 112 :: a104.deadbeef.itojun.org., a104.deadbeef.itojun.org. A6 104 :: a96.deadbeef.itojun.org., a96.deadbeef.itojun.org. A6 96 :: a88.deadbeef.itojun.org., a88.deadbeef.itojun.org. A6 88 :: a80.deadbeef.itojun.org., a80.deadbeef.itojun.org. A6 80 :: a72.deadbeef.itojun.org., a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org., a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (839) (len 847, hlim 61) 17:21:13.583570 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:501:410:0:2ae:d0ff:fe00:3b.53: [udp sum ok] 9362 [1au] ANY? a.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (50) (len 58, hlim 64) 17:21:13.630058 3ffe:501:410:0:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 9362* q: ANY? a.deadbeef.itojun.org. 1/1/3 a.deadbeef.itojun.org. CNAME a120.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (136) (len 144, hlim 61) 17:21:17.444923 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:507:1:1:2ae:d0ff:fe00:3b.53: [udp sum ok] 37449 [1au] A6? a.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (50) (len 58, hlim 64) 17:21:17.500412 3ffe:507:1:1:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 37449* q: A6? a.deadbeef.itojun.org. 2/1/18 a.deadbeef.itojun.org. CNAME a120.deadbeef.itojun.org., a120.deadbeef.itojun.org. A6 120 ::1 a112.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a112.deadbeef.itojun.org. A6 112 :: a104.deadbeef.itojun.org., a104.deadbeef.itojun.org. A6 104 :: a96.deadbeef.itojun.org., a96.deadbeef.itojun.org. A6 96 :: a88.deadbeef.itojun.org., a88.deadbeef.itojun.org. A6 88 :: a80.deadbeef.itojun.org., a80.deadbeef.itojun.org. A6 80 :: a72.deadbeef.itojun.org., a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org., a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (855) (len 863, hlim 61) 17:21:17.507019 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:501:410:0:2ae:d0ff:fe00:3b.53: [udp sum ok] 30375 [1au] A6? a120.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (53) (len 61, hlim 64) 17:21:17.551798 3ffe:501:410:0:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 30375* q: A6? a120.deadbeef.itojun.org. 1/1/18 a120.deadbeef.itojun.org. A6 120 ::1 a112.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a112.deadbeef.itojun.org. A6 112 :: a104.deadbeef.itojun.org., a104.deadbeef.itojun.org. A6 104 :: a96.deadbeef.itojun.org., a96.deadbeef.itojun.org. A6 96 :: a88.deadbeef.itojun.org., a88.deadbeef.itojun.org. A6 88 :: a80.deadbeef.itojun.org., a80.deadbeef.itojun.org. A6 80 :: a72.deadbeef.itojun.org., a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org., a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (839) (len 847, hlim 61) 17:21:17.554481 resolver.53 > nameserver.53: [udp sum ok] 21729 [1au] A6? a112.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (53) (len 61, hlim 64) 17:21:17.599453 nameserver.53 > resolver.53: [udp sum ok] 21729* q: A6? a112.deadbeef.itojun.org. 1/1/17 a112.deadbeef.itojun.org. A6 112 :: a104.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a104.deadbeef.itojun.org. A6 104 :: a96.deadbeef.itojun.org., a96.deadbeef.itojun.org. A6 96 :: a88.deadbeef.itojun.org., a88.deadbeef.itojun.org. A6 88 :: a80.deadbeef.itojun.org., a80.deadbeef.itojun.org. A6 80 :: a72.deadbeef.itojun.org., a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org., a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (799) (len 807, hlim 61) 17:21:17.601010 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:501:410:0:2ae:d0ff:fe00:3b.53: [udp sum ok] 61936 [1au] A6? a104.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (53) (len 61, hlim 64) 17:21:17.643383 3ffe:501:410:0:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 61936* q: A6? a104.deadbeef.itojun.org. 1/1/16 a104.deadbeef.itojun.org. A6 104 :: a96.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a96.deadbeef.itojun.org. A6 96 :: a88.deadbeef.itojun.org., a88.deadbeef.itojun.org. A6 88 :: a80.deadbeef.itojun.org., a80.deadbeef.itojun.org. A6 80 :: a72.deadbeef.itojun.org., a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org., a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (758) (len 766, hlim 61) 17:21:17.646330 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:507:1:1:2ae:d0ff:fe00:3b.53: [udp sum ok] 15449 [1au] A6? a96.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:17.688201 3ffe:507:1:1:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 15449* q: A6? a96.deadbeef.itojun.org. 1/1/15 a96.deadbeef.itojun.org. A6 96 :: a88.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a88.deadbeef.itojun.org. A6 88 :: a80.deadbeef.itojun.org., a80.deadbeef.itojun.org. A6 80 :: a72.deadbeef.itojun.org., a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org., a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (716) (len 724, hlim 61) 17:21:17.689837 resolver.53 > nameserver.53: [udp sum ok] 50135 [1au] A6? a88.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:17.733389 nameserver.53 > resolver.53: [udp sum ok] 50135* q: A6? a88.deadbeef.itojun.org. 1/1/14 a88.deadbeef.itojun.org. A6 88 :: a80.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a80.deadbeef.itojun.org. A6 80 :: a72.deadbeef.itojun.org., a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org., a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (674) (len 682, hlim 61) 17:21:17.737314 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:501:410:0:2ae:d0ff:fe00:3b.53: [udp sum ok] 51117 [1au] A6? a80.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:17.778118 3ffe:501:410:0:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 51117* q: A6? a80.deadbeef.itojun.org. 1/1/13 a80.deadbeef.itojun.org. A6 80 :: a72.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org., a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (631) (len 639, hlim 61) 17:21:17.779700 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:507:1:1:2ae:d0ff:fe00:3b.53: [udp sum ok] 55354 [1au] A6? a72.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:17.820038 3ffe:507:1:1:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 55354* q: A6? a72.deadbeef.itojun.org. 1/1/12 a72.deadbeef.itojun.org. A6 72 :: a64.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org., a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (587) (len 595, hlim 61) 17:21:17.823451 resolver.53 > nameserver.53: [udp sum ok] 27677 [1au] A6? a64.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:17.862526 nameserver.53 > resolver.53: [udp sum ok] 27677* q: A6? a64.deadbeef.itojun.org. 1/1/11 a64.deadbeef.itojun.org. A6 64 :: a56.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org., a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (542) (len 550, hlim 61) 17:21:17.864428 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:501:410:0:2ae:d0ff:fe00:3b.53: [udp sum ok] 23606 [1au] A6? a56.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:17.903329 3ffe:501:410:0:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 23606* q: A6? a56.deadbeef.itojun.org. 1/1/10 a56.deadbeef.itojun.org. A6 56 :: a48.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org., a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (496) (len 504, hlim 61) 17:21:17.905337 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:507:1:1:2ae:d0ff:fe00:3b.53: [udp sum ok] 44571 [1au] A6? a48.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:17.943294 3ffe:507:1:1:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 44571* q: A6? a48.deadbeef.itojun.org. 1/1/9 a48.deadbeef.itojun.org. A6 48 :: a40.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org., a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (449) (len 457, hlim 61) 17:21:17.946513 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:501:410:0:2ae:d0ff:fe00:3b.53: [udp sum ok] 27260 [1au] A6? a40.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:17.983868 3ffe:501:410:0:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 27260* q: A6? a40.deadbeef.itojun.org. 1/1/8 a40.deadbeef.itojun.org. A6 40 :: a32.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org., a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (401) (len 409, hlim 61) 17:21:17.986522 resolver.53 > nameserver.53: [udp sum ok] 46398 [1au] A6? a32.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:18.024515 nameserver.53 > resolver.53: [udp sum ok] 46398* q: A6? a32.deadbeef.itojun.org. 1/1/7 a32.deadbeef.itojun.org. A6 32 :: a24.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org., a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (352) (len 360, hlim 61) 17:21:18.026435 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:507:1:1:2ae:d0ff:fe00:3b.53: [udp sum ok] 60737 [1au] A6? a24.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:18.062738 3ffe:507:1:1:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 60737* q: A6? a24.deadbeef.itojun.org. 1/1/6 a24.deadbeef.itojun.org. A6 24 :: a16.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org., a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (302) (len 310, hlim 61) 17:21:18.065764 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:507:1:1:2ae:d0ff:fe00:3b.53: [udp sum ok] 60180 [1au] A6? a16.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (52) (len 60, hlim 64) 17:21:18.100412 3ffe:507:1:1:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 60180* q: A6? a16.deadbeef.itojun.org. 1/1/5 a16.deadbeef.itojun.org. A6 16 :: a8.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org., a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (251) (len 259, hlim 61) 17:21:18.101777 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:507:1:1:2ae:d0ff:fe00:3b.53: [udp sum ok] 30090 [1au] A6? a8.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (51) (len 59, hlim 64) 17:21:18.135728 3ffe:507:1:1:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 30090* q: A6? a8.deadbeef.itojun.org. 1/1/4 a8.deadbeef.itojun.org. A6 8 :: a0.deadbeef.itojun.org. ns: deadbeef.itojun.org. NS localhost. ar: a0.deadbeef.itojun.org. A6 0 ::, localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (199) (len 207, hlim 61) 17:21:18.139242 3ffe:507:0:1:290:27ff:fe96:1ce1.53 > 3ffe:507:1:1:2ae:d0ff:fe00:3b.53: [udp sum ok] 15045 [1au] A6? a0.deadbeef.itojun.org. ar: . OPT UDPsize=2048 (51) (len 59, hlim 64) 17:21:18.172713 3ffe:507:1:1:2ae:d0ff:fe00:3b.53 > 3ffe:507:0:1:290:27ff:fe96:1ce1.53: [udp sum ok] 15045* q: A6? a0.deadbeef.itojun.org. 1/1/3 a0.deadbeef.itojun.org. A6 0 :: ns: deadbeef.itojun.org. NS localhost. ar: localhost. A 127.0.0.1, localhost. AAAA ::1, . OPT UDPsize=4096 (147) (len 155, hlim 61) ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24505.990606822.3@itojun.org> ; $NetBSD$ $TTL 0 @ IN SOA netbsd.org. hostmaster.netbsd.org. ( 2001052300 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ) ; Minimum IN NS localhost. $ORIGIN deadbeef.itojun.org. a IN CNAME a120.deadbeef.itojun.org. a120 IN A6 120 ::1 a112.deadbeef.itojun.org. a112 IN A6 112 :: a104.deadbeef.itojun.org. a104 IN A6 104 :: a96.deadbeef.itojun.org. a96 IN A6 96 :: a88.deadbeef.itojun.org. a88 IN A6 88 :: a80.deadbeef.itojun.org. a80 IN A6 80 :: a72.deadbeef.itojun.org. a72 IN A6 72 :: a64.deadbeef.itojun.org. a64 IN A6 64 :: a56.deadbeef.itojun.org. a56 IN A6 56 :: a48.deadbeef.itojun.org. a48 IN A6 48 :: a40.deadbeef.itojun.org. a40 IN A6 40 :: a32.deadbeef.itojun.org. a32 IN A6 32 :: a24.deadbeef.itojun.org. a24 IN A6 24 :: a16.deadbeef.itojun.org. a16 IN A6 16 :: a8.deadbeef.itojun.org. a8 IN A6 8 :: a0.deadbeef.itojun.org. a0 IN A6 0 :: d IN CNAME d127.deadbeef.itojun.org. d127 IN A6 127 ::1 d126.deadbeef.itojun.org. d126 IN A6 126 :: d125.deadbeef.itojun.org. d125 IN A6 125 :: d124.deadbeef.itojun.org. d124 IN A6 124 :: d123.deadbeef.itojun.org. d123 IN A6 123 :: d122.deadbeef.itojun.org. d122 IN A6 122 :: d121.deadbeef.itojun.org. d121 IN A6 121 :: d120.deadbeef.itojun.org. d120 IN A6 120 :: d119.deadbeef.itojun.org. d119 IN A6 119 :: d118.deadbeef.itojun.org. d118 IN A6 118 :: d117.deadbeef.itojun.org. d117 IN A6 117 :: d116.deadbeef.itojun.org. d116 IN A6 116 :: d115.deadbeef.itojun.org. d115 IN A6 115 :: d114.deadbeef.itojun.org. d114 IN A6 114 :: d113.deadbeef.itojun.org. d113 IN A6 113 :: d112.deadbeef.itojun.org. d112 IN A6 112 :: d111.deadbeef.itojun.org. d111 IN A6 111 :: d110.deadbeef.itojun.org. d110 IN A6 110 :: d109.deadbeef.itojun.org. d109 IN A6 109 :: d108.deadbeef.itojun.org. d108 IN A6 108 :: d107.deadbeef.itojun.org. d107 IN A6 107 :: d106.deadbeef.itojun.org. d106 IN A6 106 :: d105.deadbeef.itojun.org. d105 IN A6 105 :: d104.deadbeef.itojun.org. d104 IN A6 104 :: d103.deadbeef.itojun.org. d103 IN A6 103 :: d102.deadbeef.itojun.org. d102 IN A6 102 :: d101.deadbeef.itojun.org. d101 IN A6 101 :: d100.deadbeef.itojun.org. d100 IN A6 100 :: d99.deadbeef.itojun.org. d99 IN A6 99 :: d98.deadbeef.itojun.org. d98 IN A6 98 :: d97.deadbeef.itojun.org. d97 IN A6 97 :: d96.deadbeef.itojun.org. d96 IN A6 96 :: d95.deadbeef.itojun.org. d95 IN A6 95 :: d94.deadbeef.itojun.org. d94 IN A6 94 :: d93.deadbeef.itojun.org. d93 IN A6 93 :: d92.deadbeef.itojun.org. d92 IN A6 92 :: d91.deadbeef.itojun.org. d91 IN A6 91 :: d90.deadbeef.itojun.org. d90 IN A6 90 :: d89.deadbeef.itojun.org. d89 IN A6 89 :: d88.deadbeef.itojun.org. d88 IN A6 88 :: d87.deadbeef.itojun.org. d87 IN A6 87 :: d86.deadbeef.itojun.org. d86 IN A6 86 :: d85.deadbeef.itojun.org. d85 IN A6 85 :: d84.deadbeef.itojun.org. d84 IN A6 84 :: d83.deadbeef.itojun.org. d83 IN A6 83 :: d82.deadbeef.itojun.org. d82 IN A6 82 :: d81.deadbeef.itojun.org. d81 IN A6 81 :: d80.deadbeef.itojun.org. d80 IN A6 80 :: d79.deadbeef.itojun.org. d79 IN A6 79 :: d78.deadbeef.itojun.org. d78 IN A6 78 :: d77.deadbeef.itojun.org. d77 IN A6 77 :: d76.deadbeef.itojun.org. d76 IN A6 76 :: d75.deadbeef.itojun.org. d75 IN A6 75 :: d74.deadbeef.itojun.org. d74 IN A6 74 :: d73.deadbeef.itojun.org. d73 IN A6 73 :: d72.deadbeef.itojun.org. d72 IN A6 72 :: d71.deadbeef.itojun.org. d71 IN A6 71 :: d70.deadbeef.itojun.org. d70 IN A6 70 :: d69.deadbeef.itojun.org. d69 IN A6 69 :: d68.deadbeef.itojun.org. d68 IN A6 68 :: d67.deadbeef.itojun.org. d67 IN A6 67 :: d66.deadbeef.itojun.org. d66 IN A6 66 :: d65.deadbeef.itojun.org. d65 IN A6 65 :: d64.deadbeef.itojun.org. d64 IN A6 64 :: d63.deadbeef.itojun.org. d63 IN A6 63 :: d62.deadbeef.itojun.org. d62 IN A6 62 :: d61.deadbeef.itojun.org. d61 IN A6 61 :: d60.deadbeef.itojun.org. d60 IN A6 60 :: d59.deadbeef.itojun.org. d59 IN A6 59 :: d58.deadbeef.itojun.org. d58 IN A6 58 :: d57.deadbeef.itojun.org. d57 IN A6 57 :: d56.deadbeef.itojun.org. d56 IN A6 56 :: d55.deadbeef.itojun.org. d55 IN A6 55 :: d54.deadbeef.itojun.org. d54 IN A6 54 :: d53.deadbeef.itojun.org. d53 IN A6 53 :: d52.deadbeef.itojun.org. d52 IN A6 52 :: d51.deadbeef.itojun.org. d51 IN A6 51 :: d50.deadbeef.itojun.org. d50 IN A6 50 :: d49.deadbeef.itojun.org. d49 IN A6 49 :: d48.deadbeef.itojun.org. d48 IN A6 48 :: d47.deadbeef.itojun.org. d47 IN A6 47 :: d46.deadbeef.itojun.org. d46 IN A6 46 :: d45.deadbeef.itojun.org. d45 IN A6 45 :: d44.deadbeef.itojun.org. d44 IN A6 44 :: d43.deadbeef.itojun.org. d43 IN A6 43 :: d42.deadbeef.itojun.org. d42 IN A6 42 :: d41.deadbeef.itojun.org. d41 IN A6 41 :: d40.deadbeef.itojun.org. d40 IN A6 40 :: d39.deadbeef.itojun.org. d39 IN A6 39 :: d38.deadbeef.itojun.org. d38 IN A6 38 :: d37.deadbeef.itojun.org. d37 IN A6 37 :: d36.deadbeef.itojun.org. d36 IN A6 36 :: d35.deadbeef.itojun.org. d35 IN A6 35 :: d34.deadbeef.itojun.org. d34 IN A6 34 :: d33.deadbeef.itojun.org. d33 IN A6 33 :: d32.deadbeef.itojun.org. d32 IN A6 32 :: d31.deadbeef.itojun.org. d31 IN A6 31 :: d30.deadbeef.itojun.org. d30 IN A6 30 :: d29.deadbeef.itojun.org. d29 IN A6 29 :: d28.deadbeef.itojun.org. d28 IN A6 28 :: d27.deadbeef.itojun.org. d27 IN A6 27 :: d26.deadbeef.itojun.org. d26 IN A6 26 :: d25.deadbeef.itojun.org. d25 IN A6 25 :: d24.deadbeef.itojun.org. d24 IN A6 24 :: d23.deadbeef.itojun.org. d23 IN A6 23 :: d22.deadbeef.itojun.org. d22 IN A6 22 :: d21.deadbeef.itojun.org. d21 IN A6 21 :: d20.deadbeef.itojun.org. d20 IN A6 20 :: d19.deadbeef.itojun.org. d19 IN A6 19 :: d18.deadbeef.itojun.org. d18 IN A6 18 :: d17.deadbeef.itojun.org. d17 IN A6 17 :: d16.deadbeef.itojun.org. d16 IN A6 16 :: d15.deadbeef.itojun.org. d15 IN A6 15 :: d14.deadbeef.itojun.org. d14 IN A6 14 :: d13.deadbeef.itojun.org. d13 IN A6 13 :: d12.deadbeef.itojun.org. d12 IN A6 12 :: d11.deadbeef.itojun.org. d11 IN A6 11 :: d10.deadbeef.itojun.org. d10 IN A6 10 :: d9.deadbeef.itojun.org. d9 IN A6 9 :: d8.deadbeef.itojun.org. d8 IN A6 8 :: d7.deadbeef.itojun.org. d7 IN A6 7 :: d6.deadbeef.itojun.org. d6 IN A6 6 :: d5.deadbeef.itojun.org. d5 IN A6 5 :: d4.deadbeef.itojun.org. d4 IN A6 4 :: d3.deadbeef.itojun.org. d3 IN A6 3 :: d2.deadbeef.itojun.org. d2 IN A6 2 :: d1.deadbeef.itojun.org. d1 IN A6 1 :: d0.deadbeef.itojun.org. d0 IN A6 0 :: ------- =_aaaaaaaaaa0-- to unsubscribe send a message to 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 May 23 14:25:01 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11636 for ; Wed, 23 May 2001 14:25:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152d6V-000GqD-00 for namedroppers-data@psg.com; Wed, 23 May 2001 11:11:27 -0700 Received: from 120-59.nanog22.centergate.com ([204.74.120.59] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152d6U-000Gq7-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 11:11:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152d6U-00058n-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 11:11:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 23 May 2001 10:34:00 -0700 (PDT) From: Bernard Aboba To: Robert Elz cc: Erik Guttman , namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: <2218.990617382@brandenburg.cs.mu.OZ.AU> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | A *better* outcome would be to allow mDNS in configured networks. That's already allowed. There's nothing in the drafts that says that mDNS is only for zero config networks. to unsubscribe send a message to 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 May 24 01:59:34 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26859 for ; Thu, 24 May 2001 01:59:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 152nkp-0003wE-00 for namedroppers-data@psg.com; Wed, 23 May 2001 22:33:47 -0700 Received: from mg130-024.ricochet.net ([204.179.130.24] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 152nkm-0003vz-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 22:33:47 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 152nkh-0005RF-00 for namedroppers@ops.ietf.org; Wed, 23 May 2001 22:33:39 -0700 Message-Id: <200105232232.f4NMWwG10769@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3110 on RSA SIGs and KEYs in the DNS Cc: rfc-ed@ISI.EDU, namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 23 May 2001 15:32:58 -0700 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3110 Title: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) Author(s): D. Eastlake 3rd Status: Standards Track Date: May 2001 Mailbox: Donald.Eastlake@motorola.com Pages: 7 Characters: 14587 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-rsa-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3110.txt This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. Since the adoption of a Proposed Standard for RSA signatures in the DNS (Domain Name Space), advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG 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. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010523153100.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3110 --OtherAccess Content-Type: Message/External-body; name="rfc3110.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010523153100.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu May 24 16:00:41 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20044 for ; Thu, 24 May 2001 16:00:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1530v1-0000uH-00 for namedroppers-data@psg.com; Thu, 24 May 2001 12:37:11 -0700 Received: from [65.105.173.130] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 1530v1-0000uB-00 for namedroppers@ops.ietf.org; Thu, 24 May 2001 12:37:11 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 1530v1-0006QN-00 for namedroppers@ops.ietf.org; Thu, 24 May 2001 12:37:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 24 May 2001 14:59:02 -0400 From: "Nicolae, Dan" Subject: RE: summary/conclusion of discussion on mdns-00 To: "'Robert Elz'" Cc: namedroppers@ops.ietf.org Message-id: <3820E1EF15CCD411B4E600508BAED1F45BC914@usa0111ms2.eng.mc.xerox.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > From: Robert Elz [mailto:kre@munnari.OZ.AU] >| There may be operational reasons, in some cases, to disable mDNS. I want >| to distinguish this mode from other modes - such as a host being configured >| to use certain DNS servers or being configured to use a particular set of >| domains in its search list. > > Sure, I'd prefer that too. I actually believe that a new DHCP option is > the right way to go, rather than trying to overload an existing one with a > new meaning. The "magic address" proposal in the last message was just > intended to show a different way that an existing option could be > overloaded, which I think would work better. I don't think that is the > right solution. > > But I think that option should enable mDNS (as should most probably not > getting any DNS "server" list from DHCP at all - that's essentially > returning the net to "no DNS configured" state). Without the option, and > assuming that the DNS is configured, I'd leave mDNS off. I don't think that the "magic address" idea is that bad. It doesn't have to be "magic" though. Why can't it be the actual mDNS multicast address (e.g. 239.255.255.251)? It wouldn't even be a matter of overloading the existing DHCP option. The DHCP option returns a *ordered* list of DNS servers (or back end resolvers if you wish) to be used by a stub resolver. The mDNS multicast address is just another DNS server to try. The draft states the intent that mDNS is "an extension to the DNS protocol which consists of a single change to the method of use ...". I have noticed quite a few changes and the usage of local.arpa does not seem to be a justified one. I don't mean that we won't need a new DHCP option. I agree that most likely one will be needed to address any configuration issues that go beyond simply enabling/disabling mDNS, but those issues are still TBD. dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri May 25 02:12:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09316 for ; Fri, 25 May 2001 02:12:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 153ANH-000EAw-00 for namedroppers-data@psg.com; Thu, 24 May 2001 22:42:59 -0700 Received: from mg-206253202-23.ricochet.net ([206.253.202.23] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 153ANC-000EAX-00 for namedroppers@ops.ietf.org; Thu, 24 May 2001 22:42:58 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 153AMr-0007KM-00 for namedroppers@ops.ietf.org; Thu, 24 May 2001 22:42:33 -0700 Date: Thu, 24 May 2001 19:09:26 -0700 (PDT) From: Bernard Aboba To: "Nicolae, Dan" cc: "'Robert Elz'" , namedroppers@ops.ietf.org Subject: RE: summary/conclusion of discussion on mdns-00 In-Reply-To: <3820E1EF15CCD411B4E600508BAED1F45BC914@usa0111ms2.eng.mc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I don't think that the "magic address" idea is that bad. It doesn't have to > be "magic" though. Why can't it be the actual mDNS multicast address (e.g. > 239.255.255.251)? Well, there are pros and cons to this. It does give you considerable flexiblity long term. However, one effect is to require admins to set the address correctly. If they make a mistake, either mDNS won't be used at all (if the resolver checks for the "correct" address), or mDNS might be used on the wrong scope, which could be disasterous given that it is only engineered for use on the linklocal scope today. > I don't mean that we won't need a new DHCP option. I agree that most likely > one will be needed to address any configuration issues that go beyond simply > enabling/disabling mDNS, but those issues are still TBD. > As noted earlier, there is the issue of usage order as well as enable/disable, and potentially the scope issue longer term. to unsubscribe send a message to 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 May 25 09:54:57 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18156 for ; Fri, 25 May 2001 09:54:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 153Hcd-0002LN-00 for namedroppers-data@psg.com; Fri, 25 May 2001 06:27:19 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 153Hcd-0002LH-00 for namedroppers@ops.ietf.org; Fri, 25 May 2001 06:27:19 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 153Hcd-0002yB-00 for namedroppers@ops.ietf.org; Fri, 25 May 2001 06:27:19 -0700 From: Robert Elz To: "Nicolae, Dan" cc: namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: <3820E1EF15CCD411B4E600508BAED1F45BC914@usa0111ms2.eng.mc.xerox.com> References: <3820E1EF15CCD411B4E600508BAED1F45BC914@usa0111ms2.eng.mc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 May 2001 16:06:52 +0700 Message-ID: <1691.990781612@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 24 May 2001 14:59:02 -0400 From: "Nicolae, Dan" Message-ID: <3820E1EF15CCD411B4E600508BAED1F45BC914@usa0111ms2.eng.mc.xerox.com> | I don't think that the "magic address" idea is that bad. I don't think it is that good either... | Why can't it be the actual mDNS multicast address (e.g.239.255.255.251)? I considered that when I suggested it. The real problem is the effect that would have on clients that know nothing about mDNS. If this were to be adopted as an indicator, the address needs to be something that can't cause existing clients to react badly. If an existing resolver managed to send to that address, it would expect replies to return from that as a source addr - and that isn't going to happen. Clients would also use their normal retry algorithms, which probably wouldn't be a good idea either. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri May 25 12:01:28 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20138 for ; Fri, 25 May 2001 12:01:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 153JVF-0006al-00 for namedroppers-data@psg.com; Fri, 25 May 2001 08:27:49 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 153JVF-0006af-00 for namedroppers@ops.ietf.org; Fri, 25 May 2001 08:27:49 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 153JVF-0006HR-00 for namedroppers@ops.ietf.org; Fri, 25 May 2001 08:27:49 -0700 Message-Id: <200105251514.RAA09808@ehdb03-home.Germany.Sun.COM> Date: Fri, 25 May 2001 17:14:42 +0200 (MEST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: summary/conclusion of discussion on mdns-00 To: Dan.Nicolae@usa.xerox.com Cc: erik.guttman@sun.com, namedroppers@ops.ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9/ZQepuEul1EfwqHN4zmcg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4m sparc Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I don't think that the "magic address" idea is that bad. It doesn't have to > be "magic" though. Why can't it be the actual mDNS multicast address (e.g. > 239.255.255.251)? Actually, the mDNS address would be the link-local IPv4 multicast address 224.0.0.251. The admin local scope address you mention is for the mdns protocol, as specified by Bill Woodcock and Bill Manning. The drafts have since expired. A problem with the 'magic number' proposal - if used in conjunction with admin multicast scopes - is that the magic numbers depend on which scope is used. The mdns address is a 'relative assignment.' [RFC 2365] The mDNS address is '4 down from the top of the range,' for Local Scope (239.255.255.0/24) it is 239.255.255.251. For Organization Local Scope (239.192.0.0/14) it would be 239.192.33.251. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri May 25 13:06:23 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21533 for ; Fri, 25 May 2001 13:06:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 153KnV-0009bK-00 for namedroppers-data@psg.com; Fri, 25 May 2001 09:50:45 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 153KnV-0009bD-00 for namedroppers@ops.ietf.org; Fri, 25 May 2001 09:50:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 153KnV-0008aQ-00 for namedroppers@ops.ietf.org; Fri, 25 May 2001 09:50:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3B0E8D3E.9AC8A80B@ehsco.com> Date: Fri, 25 May 2001 09:50:06 -0700 From: "Eric A. Hall" To: Erik Guttman CC: Dan.Nicolae@usa.xerox.com, namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 References: <200105251514.RAA09808@ehdb03-home.Germany.Sun.COM> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > A[nother] problem with the 'magic number' proposal [...] Can the draft get away with just recommending the use of "a local configuration setting" without specifically overloading anything? In that case, an mDNS-aware resolver could just an entry in resolv.conf something like: mDNS where the multicast address can be locally predefined if scope control is an issue for that site. Systems that supported the protocol would use it, systems that didn't support it would ignore the "local configuration setting". This approach doesn't overload any existing functionality, doesn't break anything, and still allows for configuration management. I'm not advocating that we define attribute:value pairs for resolv.conf or the windows registry or anything, just that we say "uses a local configuration setting", which can include an in-memory flag, a resolv.conf entry, or any other form of local configuratin. We can still go and define DHCP options for enabling/disabling this setting of course. -- 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 Sat May 26 08:28:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18567 for ; Sat, 26 May 2001 08:27:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 153cpd-0000Ro-00 for namedroppers-data@psg.com; Sat, 26 May 2001 05:06:09 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 153cpc-0000Ri-00 for namedroppers@ops.ietf.org; Sat, 26 May 2001 05:06:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 153cpc-000EWL-00 for namedroppers@ops.ietf.org; Sat, 26 May 2001 05:06:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "Eric A. Hall" cc: Erik Guttman , Dan.Nicolae@usa.xerox.com, namedroppers@ops.ietf.org Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: <3B0E8D3E.9AC8A80B@ehsco.com> References: <3B0E8D3E.9AC8A80B@ehsco.com> <200105251514.RAA09808@ehdb03-home.Germany.Sun.COM> Date: Sat, 26 May 2001 16:00:45 +0700 Message-ID: <1219.990867645@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Fri, 25 May 2001 09:50:06 -0700 From: "Eric A. Hall" Message-ID: <3B0E8D3E.9AC8A80B@ehsco.com> | Can the draft get away with just recommending the use of "a local | configuration setting" without specifically overloading anything? Good enough for me ... though I'd prefer that it say that if DNS back end resolvers have been configured for the node that this switch default to "off" (no MDNS) and that if none have, it default to "on". Ie: (or maybe I mean eg) if there's a classic resolv.conf (from DHCP or elsewhere) then no mDNS unless the option exists and enables it (which it wouldn't currently). On the other hand, if there's no resolv.conf, or no "nameserver" lines in it, then mDNS just happens. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun May 27 17:01:52 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11934 for ; Sun, 27 May 2001 17:01:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1547Ks-000HBs-00 for namedroppers-data@psg.com; Sun, 27 May 2001 13:40:26 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1547Kr-000HBj-00 for namedroppers@ops.ietf.org; Sun, 27 May 2001 13:40:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1547Kr-0009ui-00 for namedroppers@ops.ietf.org; Sun, 27 May 2001 13:40:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: A6 TTL timeout In-Reply-To: Message from itojun@iijlab.net dated "Wed, 23 May 2001 17:36:19 +0900" <24518.990606979@itojun.org> References: <24518.990606979@itojun.org> Date: Sun, 27 May 2001 16:15:45 -0400 From: Rob Austein Message-Id: <20010527201551Z23537-219+210@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Itojun, Yeah, TTL processing is almost certainly underspecified for all of DNS let alone for AAAA -> A6 synthesis, unless some recent clarification document has changed the landscape from what I think I remember. Background: we've known for a long time (since the late '80s, at least) that TTL handling by a full-service (iterative) resolver during query processing isn't as simple as just comparing RR.time_received + RR.TTL > current_time at least not for any "complex" query that can generate other queries as side effects (eg, for additional section processing). As you stated, the basic problem is that the clock keeps running while the resolver is performing the second (third, ...) query, which can cause nonsensical results with very short TTLs. The implementation technique that seems to work (JEEVES, CHIVES, and at least some versions of BIND, dunno about other implementations) is to do per-query TTL calculations based on the starting time of the original query. That is, one keeps track of the time at which the original query started, and the RR expiration check for RRs retrieved as part of processing that query becomes RR.time_received + RR.TTL > query.start_time One still has to use the current wall time when calculating the TTLs that one hands back to the client that invoked the resolver, to avoid inflating TTLs beyond what was specified in the original zone. The net effect of all of the above is that the client may well get an answer with a zero TTL, but at least the client does get back an answer. This certainly is not the only possible interpretation or implementation choice, it's just the one that (IMHO) comes closest to filling in the blank parts of the spec without making total nonsense of other parts of the spec or violating the robustness principle. I have a strong memory of receiving verbal confirmation from Paul Mockapetris back in the late '80s that the above algorithm is consistant with what he'd intended, but that's just folklore. For AAAA -> A6 synthesis there's the additional issue of which of the A6 TTLs you should use in the synthesized AAAA. If one believes the above handwaving (YMMV), I think there's a straightforward solution: you figure out what the TTLs of all the A6 RRs involved would be if you were going to insert them all into the response, then you take the minimum TTL of that set and use it as the TTL of the synthesized AAAA. --Rob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon May 28 15:23:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06545 for ; Mon, 28 May 2001 15:23:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 154SKo-0006I3-00 for namedroppers-data@psg.com; Mon, 28 May 2001 12:05:46 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 154SKn-0006Hx-00 for namedroppers@ops.ietf.org; Mon, 28 May 2001 12:05:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 154SKn-000Lp0-00 for namedroppers@ops.ietf.org; Mon, 28 May 2001 12:05:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200105281859.LAA21059@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: A6 TTL timeout In-Reply-To: Message from Rob Austein of "Sun, 27 May 2001 16:15:45 EDT." <20010527201551Z23537-219+210@thrintun.hactrn.net> Date: Mon, 28 May 2001 11:59:46 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The implementation technique that seems to work (JEEVES, CHIVES, and > at least some versions of BIND, dunno about other implementations) is > to do per-query TTL calculations based on the starting time of the > original query. That is, one keeps track of the time at which the > original query started, and the RR expiration check for RRs retrieved > as part of processing that query becomes > > RR.time_received + RR.TTL > query.start_time > > One still has to use the current wall time when calculating the TTLs > that one hands back to the client that invoked the resolver, to avoid > inflating TTLs beyond what was specified in the original zone. The > net effect of all of the above is that the client may well get an > answer with a zero TTL, but at least the client does get back an > answer. > > This certainly is not the only possible interpretation or > implementation choice, it's just the one that (IMHO) comes closest to > filling in the blank parts of the spec without making total nonsense > of other parts of the spec or violating the robustness principle. I > have a strong memory of receiving verbal confirmation from Paul > Mockapetris back in the late '80s that the above algorithm is > consistant with what he'd intended, but that's just folklore. rob's got me humming along with this. > For AAAA -> A6 synthesis there's the additional issue of which of the > A6 TTLs you should use in the synthesized AAAA. If one believes the > above handwaving (YMMV), I think there's a straightforward solution: > you figure out what the TTLs of all the A6 RRs involved would be if > you were going to insert them all into the response, then you take the > minimum TTL of that set and use it as the TTL of the synthesized AAAA. and with this. to unsubscribe send a message to 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 May 30 02:32:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00450 for ; Wed, 30 May 2001 02:32:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 154zAs-000KFP-00 for namedroppers-data@psg.com; Tue, 29 May 2001 23:09:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 154zAs-000KFI-00 for namedroppers@ops.ietf.org; Tue, 29 May 2001 23:09:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 154zAs-0009QN-00 for namedroppers@ops.ietf.org; Tue, 29 May 2001 23:09:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Erik Nordmark Cc: namedroppers@ops.ietf.org In-reply-to: Erik.Nordmark's message of Wed, 30 May 2001 07:47:06 +0200. Subject: Re: A6 TTL timeout From: Jun-ichiro itojun Hagino Date: Wed, 30 May 2001 14:57:42 +0900 Message-Id: <20010530055742.81A05782@starfruit.itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> while I'm working on A6/AAAA thing, I found an interesting complication >> in A6 and timeout management. I could not find any relevant notes in >> RFC2874. >Doesn't the same ttl issue appear with DNSsec where, in order to >check an A/AAAA i.e. verify its SIG etc, multiple RRs need to retrieved? CNAME chain may have the same TTL problem, but A6 seems a bit different for me as it advocates higher level of chains than other RR types, and affected directly in the event of renumber. i need to diagnose other RR types and improve this part of the draft. thanks. 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 May 30 02:33:35 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00495 for ; Wed, 30 May 2001 02:33:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 154z9z-000KEl-00 for namedroppers-data@psg.com; Tue, 29 May 2001 23:08:47 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 154z9y-000KEd-00 for namedroppers@ops.ietf.org; Tue, 29 May 2001 23:08:46 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 154z9y-0009Oc-00 for namedroppers@ops.ietf.org; Tue, 29 May 2001 23:08:46 -0700 Date: Wed, 30 May 2001 07:47:06 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: A6 TTL timeout To: itojun@iijlab.net Cc: namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > while I'm working on A6/AAAA thing, I found an interesting complication > in A6 and timeout management. I could not find any relevant notes in > RFC2874. Doesn't the same ttl issue appear with DNSsec where, in order to check an A/AAAA i.e. verify its SIG etc, multiple RRs need to retrieved? Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 30 10:01:50 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11503 for ; Wed, 30 May 2001 10:01:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 1556Dn-000PCr-00 for namedroppers-data@psg.com; Wed, 30 May 2001 06:41:11 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 1556Dm-000PCl-00 for namedroppers@ops.ietf.org; Wed, 30 May 2001 06:41:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1556Dm-000LoZ-00 for namedroppers@ops.ietf.org; Wed, 30 May 2001 06:41:10 -0700 Message-Id: <200105301045.GAA04683@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-aaaa-a6-00.txt Date: Wed, 30 May 2001 06:45:54 -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 : Comparison of AAAA and A6 (do we really need A6?) Author(s) : J. Hagino Filename : draft-ietf-dnsext-aaaa-a6-00.txt Pages : 12 Date : 29-May-01 At this moment, there are two resource record types defined for holding IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6 [Crawford, 2000] . AAAA has been used for IPv6 network operation since 1996. Questions arose whether we really need A6 or not, or whether it is really possible to migrate to A6 or not. Some says AAAA is enough and A6 is not necessary. Some says A6 is necessary and AAAA should get deprecated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aaaa-a6-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-aaaa-a6-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-aaaa-a6-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: <20010529142022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-aaaa-a6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-aaaa-a6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010529142022.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 30 14:59:54 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21603 for ; Wed, 30 May 2001 14:59:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155Ae6-0002fv-00 for namedroppers-data@psg.com; Wed, 30 May 2001 11:24:38 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 155Ae6-0002fp-00 for namedroppers@ops.ietf.org; Wed, 30 May 2001 11:24:38 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 155Ae5-0003mv-00 for namedroppers@ops.ietf.org; Wed, 30 May 2001 11:24:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 May 2001 14:14:19 -0400 From: "Nicolae, Dan" Subject: RE: summary/conclusion of discussion on mdns-00 To: "'Robert Elz'" Cc: Namedroppers Message-id: <3820E1EF15CCD411B4E600508BAED1F45BC91B@usa0111ms2.eng.mc.xerox.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > What's more, as soon as that "magic string in the search list" stuff is > gone, the whole "local.arpa" nonsense can go with it (which isn't to say > that people shouldn't use that necessarily, just that there's no reason at > all to compel it). (ie: unlike some others on the list, I agree with > proposed change #1). Restricting mDNS to names rooted at "local.arpa" has another effect, besides the mDNS configuration. It isolates the mDNS data in the DNS namespace. I am not sure if this was one of the purposes for the "local.arpa" proposal, but I can see a potential value. What is characteristic to mDNS is not only that it uses multicast. A 'normal' DNS server could as well listen on the multicast address and respond from its own zone data or provide recursive services, with no other changes to the DNS protocol. mDNS however goes beyond this simple change and allows for extra, self-configured, authoritative name servers. This effectively changes the partitioning of the DNS namespace in different zones. Rerooting the mDNS data tree at "local.arpa" alleviates these authority conflicts. From a 'normal' DNS admin perspective anything that ends with "local.arpa" doesn't exist in DNS and it should be ignored, or, a response meant to contain the query traffic in the local area should be sent (ideally, a query for such an RR should not even be received). The "default" zones "localhost", "0.0.127.in-addr.arpa", "255.in-addr.arpa" and "0.in-addr.arpa" work like that (RFC1912). I think it makes sense to separate the selfconfigured mDNS data from the managed data in the DNS namespace. Preventing hosts to multicast is different than preventing hosts to act as authoritative name servers and provide (potentially) bogus data. "local.arpa" is a potential solution but I am not sure that it aligns with the original DNS design in RFC1034 (besides the problem that existing DNS servers are not configured to push back queries for ".local.arpa"). I believe that when dealing with parallel, separately managed namespaces the suggested solution is to use different classes. Different "zone cuts" for the same namespace are legal in different classes. I know that classes other than IN have proved unuseful so far (except when used in the QCLASS field. However I am curious what would be the issues with defining a new class for mDNS (it could be e.g. ZC from zero configuration) instead of rerooting the DNS namespace at "local.arpa". > I'm also not sure that simply doing a query for the name I want to claim, > and grabbing it if there's no response (or the response identifies me) is > adequate. I think I'd prefer to have the node send a dynamic DNS "add me > if I don't exist" type transaction. Then, if anyone else out there has > the name, they'd respond, and return an error (name already exists). If > no-one has the name, no response, just as before, and things continue. I think that using DDNS to handle name registration/conflicts is a very good idea. Standard DNS and mDNS should behave the same unless there are compelling reasons not to. The addresses (unicast or multicast) and the namespaces (DNS/mDNS) may differ but the resolver algorithm should be similar. dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed May 30 19:32:41 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27399 for ; Wed, 30 May 2001 19:32:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155EGq-0009aW-00 for namedroppers-data@psg.com; Wed, 30 May 2001 15:16:52 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 155EGq-0009aQ-00 for namedroppers@ops.ietf.org; Wed, 30 May 2001 15:16:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 155EGq-000AJB-00 for namedroppers@ops.ietf.org; Wed, 30 May 2001 15:16:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 30 May 2001 14:09:48 -0700 (PDT) From: Bernard Aboba To: "Nicolae, Dan" cc: "'Robert Elz'" , Namedroppers Subject: RE: summary/conclusion of discussion on mdns-00 In-Reply-To: <3820E1EF15CCD411B4E600508BAED1F45BC91B@usa0111ms2.eng.mc.xerox.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I think that using DDNS to handle name registration/conflicts is a very good > idea. Standard DNS and mDNS should behave the same unless there are > compelling reasons not to. The addresses (unicast or multicast) and the > namespaces (DNS/mDNS) may differ but the resolver algorithm should be > similar. How is DDNS to be secured in an adhoc environment? to unsubscribe send a message to 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 May 31 08:02:13 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21132 for ; Thu, 31 May 2001 08:02:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155Qp3-0005UH-00 for namedroppers-data@psg.com; Thu, 31 May 2001 04:41:01 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 155Qp3-0005UB-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 04:41:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 155Qp3-0006lZ-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 04:41:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Bernard Aboba cc: "Nicolae, Dan" , Namedroppers Subject: Re: summary/conclusion of discussion on mdns-00 In-Reply-To: References: Date: Thu, 31 May 2001 13:34:26 +0700 Message-ID: <1480.991290866@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 30 May 2001 14:09:48 -0700 (PDT) From: Bernard Aboba Message-ID: | How is DDNS to be secured in an adhoc environment? mDNS is all DDNS - any node creates its own name, and then answers about that name are sent to others - that is exactly DDNS. The only difference is that the node creates its name within itself, and answers queries itself, rather than designating some other server to do that (and that's almost an irrelevant difference). Whether this mDNS created DDNS data is ever exported to the global DNS is a separate question, and if so, what kind of authentication is used .. but to keep things rational, when "creating its own name", the node probably should be using DDNS type packet formatting (ie: DDNS opcodes) rather than queries for some data which one hopes might exist, but just as easily might not (DDNS has extra options to make all of those problems vanish). 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 May 31 08:23:26 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21886 for ; Thu, 31 May 2001 08:23:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155RBC-0005dM-00 for namedroppers-data@psg.com; Thu, 31 May 2001 05:03:54 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 155RBC-0005dG-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 05:03:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 155RBC-0007Ng-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 05:03:54 -0700 Message-Id: <200105311058.GAA19563@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-delegation-signer-00.txt Date: Thu, 31 May 2001 06:58:17 -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 : Delegation Signer record in parent Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-00.txt Pages : 10 Date : 30-May-01 One of the biggest problems in DNS occur when records of the same type can appear on both sides of an delegation. If the contents of these sets differs clients can get confused. RFC2535 KEY records follows the same model as for NS records, parent is responsible for the records but the child is responsible for the contents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-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-delegation-signer-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-delegation-signer-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: <20010530130247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010530130247.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 May 31 09:47:21 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24902 for ; Thu, 31 May 2001 09:47:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155SZ3-0006aM-00 for namedroppers-data@psg.com; Thu, 31 May 2001 06:32:37 -0700 Received: from mg-206253202-37.ricochet.net ([206.253.202.37] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 155SYz-0006aF-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 06:32:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155SYk-0000gH-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 06:32:18 -0700 Message-Id: <200105311320.JAA23901@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org, dnsop@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-delegation-signer-00.txt Date: Thu, 31 May 2001 09:20:55 -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 : Delegation Signer record in parent Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-00.txt Pages : 10 Date : 30-May-01 One of the biggest problems in DNS occur when records of the same type can appear on both sides of an delegation. If the contents of these sets differs clients can get confused. RFC2535 KEY records follows the same model as for NS records, parent is responsible for the records but the child is responsible for the contents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-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-delegation-signer-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-delegation-signer-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: <20010531091832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010531091832.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 May 31 14:14:04 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04602 for ; Thu, 31 May 2001 14:14:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155Wcv-000A5d-00 for namedroppers-data@psg.com; Thu, 31 May 2001 10:52:53 -0700 Received: from [131.107.37.68] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 155Wcv-000A5O-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 10:52:53 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155WcO-0000so-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 10:52:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 31 May 2001 12:26:07 -0400 From: "Nicolae, Dan" Subject: RE: summary/conclusion of discussion on mdns-00 To: "'Bernard Aboba'" , "'Robert Elz'" Cc: Namedroppers Message-id: <3820E1EF15CCD411B4E600508BAED1F45BC920@usa0111ms2.eng.mc.xerox.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > How is DDNS to be secured in an adhoc environment? How is DDNS secured in a managed environment? The mechanisms defined in RFC3007/RFC25235 should suffice should any authentication means be needed in an adhoc environment. They don't help with the authorization policy as this is left up to the DNS administrator and there isn't any in a pure peer-to-peer network. And they only provide a means for passing authentication information back and forth. This is a very good question, but I don't see any new security issues introduced by DDNS; using only queries to grab names and handle conflicts is no different. The draft proposes a authorization policy where the first host able to grab the name can keep it (assuming that it is able to defend it). The likelihood to successfully enforce this policy should be the same if DDNS is used instead of gratuitous queries. On the other hand: The proposed gratuitous query mechanism may serve the purpose as is. DDNS is only potentially better because it is more versatile and using it is coherent with the algorithms for managed networks. Also, if we talk security, DNS transaction authentication is more meaningful for DDNS than for standard queries. It is interesting to observe that the proposal to send a gratuitous name query for the SOA record is consistent with DDNS algorithms used by real implementations. This is the first step that an updater takes: it sends a query for a SOA RR associated with its own name. If one exists then that's a problem. But if not, the response will (hopefully) contain both the appropriate zone name and the primary name server to be used for subsequent updates. So, in a way, mDNS already uses DDNS. Or, better said, it gets ready to, should more action be needed. A positive response returned to the SOA query does not necessarily indicate a name (A RR) conflict. It only indicates that some other entity (mDNS host or DNS server perhaps) has assumed the authority for the zone where the update should take place. The updater may still try to send updates for its name to the identified authority but it cannot assume authority (unless the other gives up for some reason)...etc. This can get complicated. I propose to leave the draft as is for now but further investigate DDNS, name conflicts and security later. More opinions would be helpful. dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu May 31 18:10:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09138 for ; Thu, 31 May 2001 18:10:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 155aQN-000Dhy-00 for namedroppers-data@psg.com; Thu, 31 May 2001 14:56:11 -0700 Received: from [131.107.37.68] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 155aQM-000Dho-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 14:56:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 155aPo-00013A-00 for namedroppers@ops.ietf.org; Thu, 31 May 2001 14:55:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: dfriedman@hns.com To: namedroppers@ops.ietf.org Message-ID: <85256A5D.0078071C.00@ngw2.hns.com> Date: Thu, 31 May 2001 17:48:37 -0400 Subject: DNS query lengths Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, I'm working on a specialized communications system in which the length of the a DNS query is a matter of great importance. I've looked at RFCs 1034 and 1035, and understand how long a DNS query is for a given host name. I've also looked a bit at DNSsec. Main question: what extensions/modifications to the DNS query format (described in RFC 1035), described in other RFCs, would affect the length of a query? In particular, what such extensions/modifications are in common use today, or likely will be in use in the next few years? Related matter: if I've addressed this question to the wrong venue, please suggest a better venue, and I'll stop polluting this one. Thanks very much, --daniel to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.