From owner-namedroppers@ops.ietf.org Thu Jun 1 00:43:01 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04429 for ; Thu, 1 Jun 2000 00:43:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xLzn-0008Tx-00 for namedroppers-data@psg.com; Wed, 31 May 2000 20:50:11 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12xLzl-0008Tk-00 for namedroppers@ops.ietf.org; Wed, 31 May 2000 20:50:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xLzl-0000VT-00 for namedroppers@ops.ietf.org; Wed, 31 May 2000 23:50:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Jesper G. Hoy" To: Subject: draft-costanzo-dns-gl-02.txt Date: Wed, 31 May 2000 20:15:31 -0400 Message-ID: In-Reply-To: <000801bfca70$7500d540$0401a8c0@comcastwork.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Sirs, I am writing in support of the draft "draft-costanzo-dns-gl-02.txt". We publish a popular Windows DNS server and have corresponded with Mr. = Costanzo (the draft author) about implementing the new DNS RR type = suggested by his draft as soon as it reaches RFC status. In my opinion this new "GL" DNS RR type would enjoy a much wider = acceptance compared to previous "location" RR types "GPOS" and "LOC". The suggested "GL" RR type uses actual street addresses instead of = longitudes, latitudes and altitudes, making it much more useful and = accessible. I feel that DNS administrators rarely establish "LOC" records, simply = because they (as most people) have no idea where they are in terms of = longitudes, latitudes or altitude. We are quite anxious to implement this in our software, and would like = to know if there is anything we can do to help the process of promoting = this draft to an RFC. Please let me know if we can supply any additional information. Sincerely, Jesper G. Hoy JH Software 2603 Sugar Maple Ct Monmouth Jct, NJ 08852 Tel/Fax: 732-821-5738 http://www.jhsoft.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 09:34:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22987 for ; Thu, 1 Jun 2000 09:34:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xUL6-000JJg-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 05:44:44 -0700 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.13 #1) id 12xUL5-000JJa-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 05:44:44 -0700 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA22481 for ; Thu, 1 Jun 2000 08:44:06 -0400 (EDT) Received: from roam.psg.com (h135-114-73-159.lucent.com [135.114.73.159]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA22450 for ; Thu, 1 Jun 2000 08:44:05 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xUKY-0000f5-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 08:44:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006010503.BAA29466@cs.utk.edu> To: namedroppers@ops.ietf.org From: Mike Davison Subject: draft-costanzo-dns-gl-02.txt Date: Wed, 31 May 2000 22:04:36 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The idea of using DNS to determine the geographic location of a host or router has merit, but can we expect administrators to use this feature? It seems like a significant configuration task. Opinions? Thanks, Mike to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 10:11:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23838 for ; Thu, 1 Jun 2000 10:11:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xUyg-000KJ3-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 06:25:38 -0700 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemlsrv.firewall.lucent.com) by psg.com with esmtp (Exim 3.13 #1) id 12xUyf-000KIw-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 06:25:37 -0700 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA19277 for ; Thu, 1 Jun 2000 09:25:35 -0400 (EDT) Received: from roam.psg.com (h135-114-73-159.lucent.com [135.114.73.159]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA19270 for ; Thu, 1 Jun 2000 09:25:34 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xUyh-0000gX-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 09:25:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006011307.GAA04253@zed.isi.edu> Subject: Re: draft-costanzo-dns-gl-02.txt To: davison@cs.utk.edu (Mike Davison) Date: Thu, 1 Jun 2000 06:07:54 -0700 (PDT) Cc: namedroppers@ops.ietf.org In-Reply-To: <200006010503.BAA29466@cs.utk.edu> from "Mike Davison" at May 31, 2000 10:04:36 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % The idea of using DNS to determine the geographic location of a host % or router has merit, but can we expect administrators to use this % feature? It seems like a significant configuration task. Opinions? % % Thanks, % Mike % % to unsubscribe send a message to namedroppers-request@ops.ietf.org with % the word 'unsubscribe' in a single line as the message text body. Given a choice, LOC better meets the needs of several applications that I am aware of. I see little direct value in the GL proposal. --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 Jun 1 10:14:27 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23960 for ; Thu, 1 Jun 2000 10:14:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xVAL-000Kc8-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 06:37:41 -0700 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.13 #1) id 12xVAK-000Kc2-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 06:37:40 -0700 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA09339 for ; Thu, 1 Jun 2000 09:37:38 -0400 (EDT) Received: from roam.psg.com (h135-114-73-159.lucent.com [135.114.73.159]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA09321 for ; Thu, 1 Jun 2000 09:37:38 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xVAM-0000hE-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 09:37:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Donnovan Wint" To: "Jesper G. Hoy" , Subject: RE: draft-costanzo-dns-gl-02.txt Date: Thu, 1 Jun 2000 10:20:04 -0400 Message-ID: <000301bfcbd4$7af0a600$0e9610ac@dwint-nt.quadritek.com> In-Reply-To: Importance: Normal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Great idea, but this could be an administration nightmare. Think about "the roving" user for starters. In my opinion, in order for this to work effectively, there needs to be a system outside of DNS that has management *authority* for the *data*. Regards, to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 10:46:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24658 for ; Thu, 1 Jun 2000 10:46:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xVif-000LbV-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 07:13:09 -0700 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemlsrv.firewall.lucent.com) by psg.com with esmtp (Exim 3.13 #1) id 12xVie-000Lav-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 07:13:08 -0700 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA02883 for ; Thu, 1 Jun 2000 10:13:02 -0400 (EDT) Received: from roam.psg.com (h135-114-73-159.lucent.com [135.114.73.159]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA02873 for ; Thu, 1 Jun 2000 10:13:02 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xVid-0000if-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 10:13:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006011407.JAA01917@gungnir.fnal.gov> To: Mike Davison Cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: draft-costanzo-dns-gl-02.txt In-reply-to: Your message of Wed, 31 May 2000 22:04:36 PDT. <200006010503.BAA29466@cs.utk.edu> Date: Thu, 01 Jun 2000 09:07:05 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The idea of using DNS to determine the geographic location of a host > or router has merit, but can we expect administrators to use this > feature? It seems like a significant configuration task. Opinions? I think that it Has no obvious value, Is unlikely to be widely used -- for privacy and other reasons, Could be done as well in a TXT record, Could be done better with the RP record of RFC 1183, Is just plain silly with the "S3". to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 12:37:04 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27082 for ; Thu, 1 Jun 2000 12:37:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xXQu-000OOE-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 09:02:56 -0700 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.13 #1) id 12xXQt-000OO8-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 09:02:55 -0700 Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA21780 for ; Thu, 1 Jun 2000 12:02:54 -0400 (EDT) Received: from roam.psg.com (h135-114-73-159.lucent.com [135.114.73.159]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA21768 for ; Thu, 1 Jun 2000 12:02:53 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xXQw-0000pK-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 12:02:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006011555.LAA21852@world.std.com> To: Mike Davison cc: namedroppers@ops.ietf.org, brunner@world.std.com Subject: Re: draft-costanzo-dns-gl-02.txt In-reply-to: Your message of "Wed, 31 May 2000 22:04:36 EDT." <200006010503.BAA29466@cs.utk.edu> Date: Thu, 01 Jun 2000 11:55:29 -0400 From: Eric Brunner Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Last fall Haitao Tang (Nokia) and I (then Nokia) discussed the issues. This lead to an I-D (I didn't co-author it) and the SPATIAL BoF at Adelaid (busy leaving Nokia, didn't attend). I don't see why an interesting collection of problems and solutions has to get jammed into some variation of the kitchen sink. Not (yet) reflected in the *-locality-* draft (Haitao's or mine) are the discussion between myself and Dave Mills, which I'll get around to after Pittsburg. -E to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 13:43:11 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28344 for ; Thu, 1 Jun 2000 13:43:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xYSs-00002z-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 10:09:02 -0700 Received: from alemail1.lucent.com ([192.11.221.161] helo=alemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.13 #1) id 12xYSr-00002s-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 10:09:01 -0700 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA07824 for ; Thu, 1 Jun 2000 13:08:59 -0400 (EDT) Received: from roam.psg.com (h135-114-73-159.lucent.com [135.114.73.159]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA07810 for ; Thu, 1 Jun 2000 13:08:58 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xYSt-0000r9-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 13:09:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <01DEEFD8F29AD31190BF00105ACE68F403A088@ns2.infinityglobal.com> From: Davis Sylvester III To: "'Bill Manning '" , Cc: "'namedroppers@ops.ietf.org '" Subject: RE: draft-costanzo-dns-gl-02.txt Date: Thu, 1 Jun 2000 11:55:11 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think that the geographic location would be a great addition. Reasons... --- E-Commerce how many Companies are trying to pin-point where there users are coming from I agree with the others, Administration of this feature would be hard to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 13:57:10 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28543 for ; Thu, 1 Jun 2000 13:57:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xYlz-0000XZ-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 10:28:47 -0700 Received: from alemail1.lucent.com ([192.11.221.161] helo=alemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.13 #1) id 12xYly-0000XS-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 10:28:46 -0700 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA23816 for ; Thu, 1 Jun 2000 13:28:44 -0400 (EDT) Received: from roam.psg.com (h135-114-73-159.lucent.com [135.114.73.159]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA23803 for ; Thu, 1 Jun 2000 13:28:44 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xYm1-0000sI-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 13:28:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <002301bfcb24$d81fff20$0401a8c0@comcastwork.com> From: "Al Costanzo" To: "Matt Crawford" , References: <200006011407.JAA01917@gungnir.fnal.gov> Subject: Re: draft-costanzo-dns-gl-02.txt Date: Wed, 31 May 2000 13:22:48 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Matt writes: > Could be done better with the RP record of RFC 1183, Al replies: Matt, How does this: RP louie.trantor.umd.edu. LAM1.people.umd.edu. show a physical geograpic location?!?!? This record is deisigned to be easy to use and two dimensional.... come on... do you read this stuff first :-) -al to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 14:05:24 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28710 for ; Thu, 1 Jun 2000 14:05:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xYx3-0000u7-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 10:40:13 -0700 Received: from alemail1.lucent.com ([192.11.221.161] helo=alemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.13 #1) id 12xYx2-0000tq-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 10:40:12 -0700 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA04221 for ; Thu, 1 Jun 2000 13:40:10 -0400 (EDT) Received: from roam.psg.com (h135-114-73-159.lucent.com [135.114.73.159]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA04211 for ; Thu, 1 Jun 2000 13:40:10 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xYx5-0000sz-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 13:40:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006011735.KAA27341@redpaul.mibh.net> To: "'namedroppers@ops.ietf.org '" Subject: Re: draft-costanzo-dns-gl-02.txt In-reply-to: Your message of "Thu, 01 Jun 2000 11:55:11 CDT." <01DEEFD8F29AD31190BF00105ACE68F403A088@ns2.infinityglobal.com> Date: Thu, 01 Jun 2000 10:35:48 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > --- E-Commerce how many Companies are trying to pin-point where there > users are coming from LOC already handles that case. > I agree with the others, Administration of this feature would be hard to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 15:20:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01284 for ; Thu, 1 Jun 2000 15:20:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xZu1-0002e0-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 11:41:09 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12xZu0-0002dn-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 11:41:09 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xZu6-0000tv-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 14:41:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006011750.MAA03646@gungnir.fnal.gov> To: Al Costanzo Cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: draft-costanzo-dns-gl-02.txt In-reply-to: Your message of Wed, 31 May 2000 13:22:48 EDT. <002301bfcb24$d81fff20$0401a8c0@comcastwork.com> Date: Thu, 01 Jun 2000 12:50:48 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > come on... do you read this stuff first :-) Absolutely. > Matt writes: > > Could be done better with the RP record of RFC 1183, > > Al replies: > RP louie.trantor.umd.edu. LAM1.people.umd.edu. > show a physical geograpic location?!?!? When coupled with one or more records at the LAM1 label, perfectly. Furthermore, multiple thingies at the same location (which in your location scheme will be extremely common) can share the location records. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 15:29:37 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01673 for ; Thu, 1 Jun 2000 15:29:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xa2g-0002sV-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 11:50:06 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12xa2e-0002sK-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 11:50:05 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xa2m-0000uY-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 14:50:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3936AE89.6D919E59@ehsco.com> Date: Thu, 01 Jun 2000 11:42:17 -0700 From: "Eric A. Hall" To: Al Costanzo CC: Matt Crawford , namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt References: <200006011407.JAA01917@gungnir.fnal.gov> <002301bfcb24$d81fff20$0401a8c0@comcastwork.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > How does this: > > RP louie.trantor.umd.edu. LAM1.people.umd.edu. > > show a physical geograpic location?!?!? In your example, the RP TXT field is pointing to a TXT record for that person, which is not a requirement. The TXT record can point to anything, including data about the specific host that's being RP'd, or can be a common record for a zone, or whatever. . RP admins.ehsco.com. admins.ehsco.com. admins TXT ("please send problem reports to:" "e-mail: admins@ehsco.com" "phone: +1-650-555-1212" "fax: +1-650-555-1212" "postal address")* Given that street addresses are entirely free-form and have absolutely zero consistency across national lines, they can only be accurately represented with TXT records. It might be nice to have a record that explicitly defines a mailing/physical address, but there's no way that it can be structured with any form of universal meaning. As such, its only value would be faster searching ("ls -t GL"). However, given that DNS is not a very good kitchen-sink directory service (the lack of authenticated vs anonymous answers for the same resource on the same server limits it tremendously), we probably should not be encouraging people trying to use it as a repository for every piece of data that is imaginable. Getting back to the specific GL RR, more-precise versions of this RR already exist. If you want to provide additional types of free-form data, use TXT records. If you want to link this data to RP, you're free to do so. I don't believe that we should develop a specific RR for this particular purpose however. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com * this formatting doesn't work, and is for illustration purposes only to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 1 15:37:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01910 for ; Thu, 1 Jun 2000 15:37:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xa3O-0002uA-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 11:50:50 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12xa3N-0002u4-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 11:50:50 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xa3U-0000ub-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 14:50:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006011846.LAA22559@sh.lh.vix.com> To: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt Date: Thu, 01 Jun 2000 11:46:56 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, here we are recycling the same discussion that happened on this a year ago. We once again have the same arguements: This record has an information collection that no other record has There are other records that have parts of the information All this information could be represented in other records The real world deployment schedule for this is 3-10+ years (resolvers and nameservers needs to be revved) The ability of people to maintain this is suspect Now the meta issue. I think most all of the old-timers see DNS as very different than MIME, where anything goes and there is little cost to adding new types. It is clear that some people do not see it this way and want their data forms in new RR types. Unless we agree to a specific direction out of this area, this discussion will happen repeatedly from now on. I thought that KS was supposed to get us out of this mess, but in the discussion last time almost everyone agreed that KS was not the solution. So we need to find some other way out of this swamp, or allow the swamp to continue to grow. Since LDAP is designed specifically around extensable schemas, maybe the right answer is to come up with an LDAP referral RR that contains a server and a base query string. Then all these functions become a standardized form of asking LDAP queries with a standardized form of extending the base query string. This may not be a work of art, but at least it gives a clear direction for people who want to add extensible information about hosts to go. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 00:16:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12212 for ; Fri, 2 Jun 2000 00:16:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xiBO-000J1e-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 20:31:38 -0700 Received: from mg-206191146-84.ricochet.net ([206.191.146.84] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12xiBM-000J1Y-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 20:31:37 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xiBW-0000J6-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 20:31:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 1 Jun 2000 16:21:08 -0400 From: Andrew Brown To: Davis Sylvester III Cc: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt Message-ID: <20000601162108.A14530@noc.untraceable.net> Reply-To: Andrew Brown References: <01DEEFD8F29AD31190BF00105ACE68F403A088@ns2.infinityglobal.com> In-Reply-To: <01DEEFD8F29AD31190BF00105ACE68F403A088@ns2.infinityglobal.com>; from davis@infinityglobal.com on Thu, Jun 01, 2000 at 11:55:11AM -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >I think that the geographic location would be a great addition. > >Reasons... > > --- E-Commerce how many Companies are trying to pin-point where there >users are coming from as if they can tell where i am if i dial into a nationwide 800 dialup service? do they expect the provider to update the record to agree with my present location? i doubt it. what if i choose to pay long distance charges and dial in to a pop in another part of the country? besides, if they person actually buys something, they can get the information they want that way. perhaps the e-commerce sites should be selling stuff i actually want... >I agree with the others, Administration of this feature would be hard not hard as such, but just almost completely pointless. if you want one, you can put it in, but if you want them from others...there's very little you can do. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth." to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 00:20:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12230 for ; Fri, 2 Jun 2000 00:20:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xiMv-000JSN-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 20:43:33 -0700 Received: from mg-206191146-84.ricochet.net ([206.191.146.84] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12xiMm-000JQH-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 20:43:27 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12xiMN-0000Jm-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 20:42:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3936E514.EC995FDD@whistle.com> Date: Thu, 01 Jun 2000 15:35:00 -0700 From: Terry Lambert To: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt References: <200006011846.LAA22559@sh.lh.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let me first say that I won't personally configure geographic information, and so long as there are ISPs that have multiple POPs in potentially multiple geographic localities, I don't think you will be able to get accurate information for anything but things with static IP addresses anyway, and sometimes not even then. Jerry Scharf wrote: ... > Since LDAP is designed specifically around extensable schemas, > maybe the right answer is to come up with an LDAP referral RR > that contains a server and a base query string. Then all these > functions become a standardized form of asking LDAP queries > with a standardized form of extending the base query > string. > > This may not be a work of art, but at least it gives a clear > direction for people who want to add extensible information > about hosts to go. I think this misses the implied point, which is what no one seems to be willing to do other than skirt around: It is not for you to want or to not want to provide this information; in theory, your ISP will provide it. People want to know the geographic location of a machine so that when someone comes in to their web site from a machine, they can gauge the locality of the advertising that caused the customer contact to take place, even if the customer chooses to not buy anything or procide other information. Someone who wants to bury you in targetted advertising can't tell on which radio station you heard their advertisement without some geographic clue. Likewise, they can not judge the effectiveness of the junk mail they sent to a given geographic region without some way of correlating the locality of the responding machine with the set of localities to which they sent the junk mail. Imagine radio or print ads that are paid for based not on size of market or times run, but on "click through". Sort of "Nielson ratings" with involuntary participation. Or imagine someone accumulating a database of a geographic locality vs. machine. Do you really want your local grocer sending you targetted SPAM because you happen to be in the neighborhood? Can someone give a _legitimate_ reason for wanting geographic information about machines? Example: Are we finally going to design a transport protocol where you ask a service (a _service_, not a _server_) for data, and we don't care where the answer comes from, so long as it comes from some acceptable source, and comes before we need it to have arrived? Is it necessary to the design to have the physical location of the servers to do this? The only use I can think of is marginal cost reduction on targetted marketing... hardly a reason to do it, and mostly a reason to _not_ do it. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 02:17:21 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25059 for ; Fri, 2 Jun 2000 02:17:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xkLc-000O2M-00 for namedroppers-data@psg.com; Thu, 01 Jun 2000 22:50:20 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xkLc-000O2G-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 22:50:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xkLc-000H3b-00 for namedroppers@ops.ietf.org; Thu, 01 Jun 2000 22:50:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006020537.BAA07619@cs.utk.edu> Received: from cs.utk.edu (171.69.150.228 -> lytle.cisco.com) by cs.utk.edu (smtpshim v1.0); Fri, 2 Jun 2000 01:37:39 -0400 To: Terry Lambert cc: namedroppers@ops.ietf.org From: Mike Davison Subject: Re: draft-costanzo-dns-gl-02.txt In-reply-to: Your message of Thu, 01 Jun 2000 15:35:00 -0700. <3936E514.EC995FDD@whistle.com> Date: Thu, 01 Jun 2000 22:38:29 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Can someone give a _legitimate_ reason for wanting geographic > information about machines? I'm not claiming that DNS is the best method, but there is at least one good reason for wanting the geographic location of a client machine. Language. It is nice if content providers can provide their content in German, French, English, etc. as appropriate. Some content providers already do this based on other factors with about 70% accuracy. The proposal outlined in draft-costanzo-dns-gl-02.txt probably wouldn't do any better than 70%, but that does not mean that DNS-based approaches could not address this issue. Nor does it mean that there is no valid reason to learn the geographic location of the client. Of course, it might actually be more useful to have a 'services preferences' DNS record rather than a geographic location. This record could indicate what sort of localization the client wishes. But again, DNS may not be the right tool. > Example: Are we finally going to design a transport protocol > where you ask a service (a _service_, not a _server_) for > data, and we don't care where the answer comes from, so long > as it comes from some acceptable source, and comes before we > need it to have arrived? Is it necessary to the design to > have the physical location of the servers to do this? HTTP redirect is a reasonable, although clunky, example of this. Client connects to www.content-r-us.com. Server makes guess about location of client based on client's address and routing data. Server redirects the client to a localized/closer/less-loaded/etc server. Mike to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:00:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03701 for ; Fri, 2 Jun 2000 11:00:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsE8-000AZL-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:15:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsE8-000AZF-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:15:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsE8-000Jmk-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:15:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.1.2.20000602092525.054e0ac0@dokka.kvatro.no> Date: Fri, 02 Jun 2000 09:29:20 +0200 To: Jerry Scharf , namedroppers@ops.ietf.org From: Harald Tveit Alvestrand Subject: Re: draft-costanzo-dns-gl-02.txt In-Reply-To: <200006011846.LAA22559@sh.lh.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:46 01.06.2000 -0700, Jerry Scharf wrote: >Since LDAP is designed specifically around extensable schemas, maybe the >right >answer is to come up with an LDAP referral RR that contains a server and a >base query string. Then all these functions become a standardized form of >asking LDAP queries with a standardized form of extending the base query >string. Given that LDAP has gone down every single one of the ratholes dealing with names and addresses already, and is far more geared towards creating more ratholes without taking down the system, AND has a defined URL format, I think that creating a "see-also" record that can contain an URI is a sensible way to go. It doesn't even have to be an LDAP uri. "microsoft.com SEE www.microsoft.com" might make sense (to Microsoft), while "mymachine.alvestrand.no SEE ldap://ldap.alvestrand.no/CN=mymachine,O=alvestrand,C=no??" might make sense for one of my computers (if I could be bothered to register info on them). Wasn't something like this a proposal some time back? Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:00:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03713 for ; Fri, 2 Jun 2000 11:00:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsEc-000AaK-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:15:38 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsEc-000AaE-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:15:38 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsEc-000Jmw-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:15:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006020757.AAA05609@sh.lh.vix.com> To: Harald Tveit Alvestrand cc: Jerry Scharf , namedroppers@ops.ietf.org, scharf@vix.com Subject: Re: draft-costanzo-dns-gl-02.txt In-reply-to: Your message of "Fri, 02 Jun 2000 09:29:20 +0200." <4.3.1.2.20000602092525.054e0ac0@dokka.kvatro.no> Date: Fri, 02 Jun 2000 00:57:29 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It might make sense to have an RR that has a URL and a service name. That way I can have a few different URLs at the same point. My idea would be that service names are opaque to DNS, unconstrained and not IANA allocated. You would certainly need to allow a "*" service, and you could even think of allowing a regexp to be interpreted by the application. When you ask for the type, you get the entire RRset just like everything else. If someone wants to manage service names in some way, I would see that as beyond the scope of the WG. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:01:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03801 for ; Fri, 2 Jun 2000 11:01:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsJT-000AhF-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:20:39 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsJT-000Ah9-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:20:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsJT-000Job-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:20:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <07cf01bfcc86$73c77a40$2d101c10@ucx.lkg.dec.com> From: "M. T. Hollinger" To: "Terry Lambert" , "Mike Davison" Cc: References: <200006020537.BAA07619@cs.utk.edu> Subject: Re: draft-costanzo-dns-gl-02.txt Date: Fri, 2 Jun 2000 07:33:55 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Can someone give a _legitimate_ reason for wanting geographic >> information about machines? > > I'm not claiming that DNS is the best method, but there is at least > one good reason for wanting the geographic location of a client machine. > Language. It is nice if content providers can provide their content in > German, French, English, etc. as appropriate. Sure, that's an example. Within a country, this information could also be used as a default to display weather forecasts, sports scores, local news, TV schedules, telephone listings, or links to local chapter information relating to the organization running the website. Of course, the user should be able to access other geographic areas (like Yahoo's "change location" link), but getting a default that's appropriate even 50% of the time would be a real convenience for users. This stuff all came up last year, when we previously discussed location RR proposals. However, the most popular use for this information, I think -- and the reason to consider providing it in the DNS, rather than in an HTTP-specific way -- is simply to allow server operators (FTP server, web server, chat server, or the-next-big-thing server) to keep statistics. At IETF plenary meetings, we often see a list of how many attendees are there from each country. Why? Can anyone give a _legitimate_ reason for wanting to know how many people from Sweden attended the Danvers IETF? (If not, would that mean the information shouldn't be collected or shared?) When travelling on vacation, I often pass the time by looking at people's bumper stickers or baseball caps just to see where they're from. In Vermont, during ski season, it sometimes seems like 20% of the license plates are from New York, and 25% from Massachusetts. Now, privacy advocates may point out that I have no right to know where that stranger in front of me is from. Those who insist on complete accuracy may complain that the parked car I just saw with Connecticut plates may actually be rented by a German family. While driving a rented car at the Munich IETF, one of the locals warned me that people there might see its Frankfurt plates, incorrectly conclude that I was from Frankfurt, and be more likely to cut me off, as residents of those regions have something of a rivalry. Similarly, while travelling in Canada, I may make a long-distance dial-up connection to my home server in the US and be incorrectly counted as a US visitor when I access the website of the local science museum to find their hours of operation. Still, imperfect as the information is, it's interesting to see where your visitors are from. A Save the Whales website operator may wonder how many people from Norway are reading his homepage. Somebody running an FTP archive of Beatles lyrics might find it interesting if most of his users are from China and Taiwan. Perhaps he can, over time, tailor the content of his archive to those users. But even if he takes no action, he might just like to know, because it's interesting information. The Internet is all about collecting, organizing, and sharing knowledge. In general, I think that's good. Privacy concerns dictate certain limits or controls on the automated sharing of personal information (such as your name and street address), but for demographic information (such as what country, province, prefecture, or state you may be from), I don't see much of a threat. If some people want to know, and other people want to tell them, our role as Internet engineers is to provide a mechanism to facilitate that communication. - Mark to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:04:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03874 for ; Fri, 2 Jun 2000 11:04:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsPR-000ArQ-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:26:49 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsPQ-000ArK-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:26:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsPQ-000JrA-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:26:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006021234.IAA00573@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 02 Jun 2000 08:34:25 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has received a request from the DNS Extensions Working Group to consider Simple Secure Domain Name System (DNS) Dynamic Update as a Proposed Standard. This will replace/obsolete RFC2137, currently a Proposed Standard. The IESG will also consider Domain Name System Security (DNSSEC) Signing Authority as a Proposed Standard, updating RFC2535 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 16, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-01.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:05:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03929 for ; Fri, 2 Jun 2000 11:05:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsB0-000AVi-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:11:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsB0-000AVc-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:11:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsB0-000Jlf-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:11:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006020653.XAA04569@sh.lh.vix.com> To: Terry Lambert cc: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt In-reply-to: Your message of "Thu, 01 Jun 2000 15:35:00 PDT." <3936E514.EC995FDD@whistle.com> Date: Thu, 01 Jun 2000 23:53:25 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Terry, I don't disagre in any way with anythign you say. My point was that much of this discussion happened when GL was first discussed about how useful the data really is. I think you define a specific use model, then reason why it doesn't work. All it takes is for them to say that's not how they were going to use it, and the discussion continues on and on... My point is that I don't really want to have to poke holes in each new RR type request that wants to put some other type of information in DNS that is of questionable value for the desired use and has standardization and implementation effort involved. I want some place to send them to that they can feel happy enough with that it won't show up on namedroppers. Until we have some other thing to point to that lets people do this, each one will end up on our doorstep. As this rehash proves, they don't go away easily. Officially saying "use LDAP (or whatever) and here's how" and "we hereby consider adding RR types in lieu of this to be an extrordinary action" will give us a real way to tell people to go away. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:05:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03940 for ; Fri, 2 Jun 2000 11:05:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsPv-000Arp-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:27:19 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsPv-000Arj-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:27:19 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsPu-000JrV-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:27:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: <000801bfca70$7500d540$0401a8c0@comcastwork.com> Date: Thu, 1 Jun 2000 09:00:11 -0400 To: "Jesper G. Hoy" From: Edward Lewis Subject: Re: draft-costanzo-dns-gl-02.txt Cc: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am emphatically neutral on this issue, perhaps even radically moderate. I don't see the need for the record, nor do I see any reason it is not persued. I disagree with the argument that "we don't need GL, we have LOC." I don't know of many folks who use LOC as it is. LOC is not alone, most record types are not widely used. OTOH, Having both is possible, they don't impact each other. The IETF can't stop someone from implementing a DNS feature in their name server. The standard does define "unknown" record type handling. IMHO, I think the authors/implementors of the draft should do an implementation without the "blessing" of the IETF and then demonstrate "running code." Document the record and submit an ID. It is possible that the ID could go Informational and evolve into an RFC without WG review. (There are still reviews to go through, just not the WG.) Hypothetically, if the GL record becomes so widely popular that name servers implementing the record begin to steal serious "market" share from BIND, I am sure BIND will include it. I am not suggesting that the DOJ needs to break up the ISC too, but I could understand a reluctance for adding GL to BIND at this time - there's just too much else going on. Don't take this as an indication of reluctance by ISC - I'm talking hypothetically here. I see two issues remaining. One is whether IANA/ICANN should be allowed to allocate a type number. The other is whether the GL record should be "standards track" or part of the DNS standard. These are the two issues to be debated, not the relative merit of the GL vs LOC. At 8:15 PM -0400 5/31/00, Jesper G. Hoy wrote: >We are quite anxious to implement this in our software, and would like = >to know if there is anything we can do to help the process of promoting = >this draft to an RFC. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:11:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04248 for ; Fri, 2 Jun 2000 11:11:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsXM-000B4O-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:35:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsXM-000B4I-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:35:00 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsXM-000JuD-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:35:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006021344.IAA09083@gungnir.fnal.gov> To: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: I-D ACTION:draft-ietf-dnsext-ixfr-01.txt In-reply-to: Your message of Fri, 02 Jun 2000 06:43:05 EDT. <200006021043.GAA27543@ietf.org> Date: Fri, 02 Jun 2000 08:44:08 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Could there be a "changes from RFC 1995" section, 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 Fri Jun 2 11:12:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04290 for ; Fri, 2 Jun 2000 11:12:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsWm-000B48-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:34:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsWm-000B3u-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:34:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsWm-000Jty-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:34:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3937B5A2.9E9C5ED4@software-munitions.com> Date: Fri, 02 Jun 2000 06:24:50 -0700 From: Dennis Glatting To: Mike Davison CC: Terry Lambert , namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt References: <200006020537.BAA07619@cs.utk.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mike Davison wrote: > > > Can someone give a _legitimate_ reason for wanting geographic > > information about machines? > > I'm not claiming that DNS is the best method, but there is at least > one good reason for wanting the geographic location of a client machine. > Language. It is nice if content providers can provide their content in > German, French, English, etc. as appropriate. > Language is not a geographical issue. It is a personal choice. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:21:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03702 for ; Fri, 2 Jun 2000 11:00:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsHM-000Ae2-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:18:28 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsHM-000Adw-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:18:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsHM-000Jnp-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:18:28 -0700 Message-Id: <200006021043.GAA27543@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-ixfr-01.txt Date: Fri, 02 Jun 2000 06:43:05 -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 : Incremental Zone Transfer in DNS Author(s) : M. Ohta Filename : draft-ietf-dnsext-ixfr-01.txt Pages : 10 Date : 01-Jun-00 This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ixfr-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-ixfr-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-ixfr-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: <20000601140512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ixfr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ixfr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000601140512.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:28:38 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04781 for ; Fri, 2 Jun 2000 11:28:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xscZ-000BE3-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:40:23 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xscY-000BDq-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:40:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xscY-000Jvz-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:40:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200006021234.IAA00573@ietf.org> Date: Thu, 1 Jun 2000 10:05:47 -0400 To: iesg@ietf.org From: Edward Lewis Subject: Re: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard Cc: lewis@tislabs.com, brian.wellington@nominum.com, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 8:34 AM -0400 6/2/00, The IESG wrote: >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send any comments to the >iesg@ietf.org or ietf@ietf.org mailing lists by June 16, 2000. Regarding the "Signing Authority" draft: >1 - Introduction > >... The intent >is to establish a standard policy followed by a secure resolver; this >policy can be augmented by local rules. I have been pushing for a "canonical" means of validating DNSSEC data, and this document reflects what I believe to be a manageable first-cut at an maintainable policy. However, this policy is rather conservative, which means that although security is high, brittleness is high too. (Meaning that if part of the secured DNS is unavailable, data below it can't be secure - the policy is susceptible to tears and rips in the tree.) Restricting the initial policy is necessary in order to make the software implementable. By having software released and in use, we have the opportunity to assess in what ways a policy is needed to be more flexible and relaxed yet still afford us the required safety. I suggest this be done to the document. I would like a note to be added to the introduction that states that this draft "defines a first-cut policy. It is anticipated that the policy will be modified given operational experience," or some such words to that effect. I think this will deflect some of the discussion that this policy may be too harsh for operations. P.S. The section of RFC 2535 most affected by this is 6 (6.3.1), even more so that 2.3.6 (as mentioned in the introduction). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 11:34:11 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05095 for ; Fri, 2 Jun 2000 11:34:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xsdZ-000BGk-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 07:41:25 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xsdZ-000BGb-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:41:25 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xsdZ-000JwS-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 07:41:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <006101bfcc94$f953ad60$44ef0618@union1.nj.home.com> From: "Al Costanzo" To: "Terry Lambert" , References: <200006011846.LAA22559@sh.lh.vix.com> <3936E514.EC995FDD@whistle.com> Subject: Re: draft-costanzo-dns-gl-02.txt Date: Fri, 2 Jun 2000 09:17:58 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Can someone give a _legitimate_ reason for wanting geographic > information about machines? Example: Yes I can.... We are a National ISP... We are multihomed we want to keep track of where each router/node/machine is, since we have to configure DNS anyway, create a 'simple' RR that allows the information to be entered. Why maintain an offline database for this information? We think it is a part of DNS and we do not consider it 'bloat' nor a 'kitchen sink' type record.. This is important information that should be available... Most people do not have GPS'es End example/// I have already have been told the reasons why people do not use LOC records. This draft was written to make it as simple as possible with the 'best possibility' of getting accurate information and having the RR actually used. One DNS mplemetor has contacted us already about the draft and another comany likes the record for doing a 'geographical' traceroutes since most domains do not contain LOC records. It is much easier for implemetors to query DNS that has a structured record to get the information they need then to go crazy trying to figure out how to parse a free formed TXT record.... Writing this draft has shown me that implemetors really do read IDs and there seems to be interest in this RR in the industry. Another programmer wants to submit it to Linux so I think once that happens this RR which is still only an ID mind you, will be supported on, (Windows 95,NT,2000 & now Linux) Regards, -Al to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 12:00:15 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05923 for ; Fri, 2 Jun 2000 12:00:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xtRe-000D8S-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 08:33:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xtRe-000D8M-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 08:33:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xtRe-000KH5-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 08:33:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006021529.KAA09760@gungnir.fnal.gov> To: Mike Davison Cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: draft-costanzo-dns-gl-02.txt In-reply-to: Your message of Fri, 02 Jun 2000 06:24:50 PDT. <3937B5A2.9E9C5ED4@software-munitions.com> Date: Fri, 02 Jun 2000 10:29:38 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Can someone give a _legitimate_ reason for wanting geographic > > information about machines? > > I'm not claiming that DNS is the best method, but there is at least > one good reason for wanting the geographic location of a client machine. > Language. It is nice if content providers can provide their content in > German, French, English, etc. as appropriate. We have plenty of single hosts here with multiple users logged in whose Accept-Language: sets have little overlap. By the way, we already have Accept-Language for this function, don't we? Matt Accept-Language: en,es,pt,fr,de,ru to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 12:36:19 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06909 for ; Fri, 2 Jun 2000 12:36:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xtif-000Dh1-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 08:50:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xtie-000Dgv-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 08:50:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xtie-000KO9-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 08:50:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006021549.LAA18266@ludwigia.raleigh.ibm.com> To: namedroppers@ops.ietf.org Subject: Re: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard In-Reply-To: Message from The IESG of "Fri, 02 Jun 2000 08:34:25 EDT." <200006021234.IAA00573@ietf.org> Date: Fri, 02 Jun 2000 11:49:23 -0400 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG writes: > The IESG has received a request from the DNS Extensions Working Group > to consider Simple Secure Domain Name System (DNS) Dynamic Update > as a Proposed Standard. > This will replace/obsolete RFC2137, currently a Proposed Standard. > The IESG will also consider Domain Name System Security (DNSSEC) > Signing Authority as a Proposed > Standard, updating RFC2535 Both of these IDs would appear to be significant replacements of their corresponding RFCs. Also, when a new RFC replaces on old one, its expected to include a "Changes relative to RFC XXX" section in them to help implementors understand what has changed. That might not make sense here, i.e., is this replacement vs. changing. Question: should either of the two RFCs actually be reclassified as Historic, as opposed to just being obsoleted? If there is little or no deployment and the point is to not have anyone implement the old RFCs, reclassifying them to historic might be the way to go. Thomas to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 13:25:11 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07826 for ; Fri, 2 Jun 2000 13:25:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xuh5-000FG5-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 09:53:11 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xuh5-000FFz-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 09:53:11 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xuh4-000Klh-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 09:53:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 2 Jun 2000 09:49:30 -0700 From: Mark Gritter To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt Message-ID: <20000602094930.A4757@Xenon.Stanford.EDU> References: <000801bfca70$7500d540$0401a8c0@comcastwork.com> In-Reply-To: ; from lewis@tislabs.com on Thu, Jun 01, 2000 at 09:00:11AM -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, Jun 01, 2000 at 09:00:11AM -0400, Edward Lewis wrote: > The IETF can't stop someone from implementing a DNS feature in their name > server. The standard does define "unknown" record type handling. Does it? I would appreciate a reference. Currently, deployment of new record types (GL or anything else) is pretty much predicated on getting BIND to recognize them and properly do recursive queries. Otherwise any client software must use non-recursive queries, which may be undesirable--- especially when behind a firewall. BIND 8 returns unknown record types as answers only if accompanied by a recognized answer type. If not, you get SERVFAIL. BIND 9 is at least more consistent: you get SERVFAIL if any unimplemented RR types are present. My bug report to ISC resulted in an answer that they needed more IETF guidance as to how to deal with this case. But until handling of unknown record types is better addressed, it's not really feasible to deploy a new RR type without putting it on the standards track so that it gets implemented in BIND. -- Mark Gritter http://www-cs-students.stanford.edu/~mgritter/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 14:28:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09087 for ; Fri, 2 Jun 2000 14:28:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xveY-000GnP-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 10:54:38 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xveY-000GnJ-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 10:54:38 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xveY-000L8t-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 10:54:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006021751.NAA13699@world.std.com> To: namedroppers@ops.ietf.org cc: cookie-cutters@world.std.com Subject: Re: draft-costanzo-dns-gl-02.txt Date: Fri, 02 Jun 2000 13:51:44 -0400 From: Eric Brunner Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Terry Lambert wrote: > Can someone give a _legitimate_ reason for wanting geographic > information about machines? Hi Terry. I'll get around to listing some reasons for making a mapping from ip addrs to some representation of spatial locality eventually. Milage will vary of course for values of "legitimate". [For cookie-cutters not namedroppers, draft-costanzo-dns-gl is the latest in a series of proposals to (mis)use the DNS, extending its scope to some form of a geographic resolver. The cookie-cutter interest is extracting (consent?, PII?) demographics in the form of geographic identifiers.] The following is from today's Benton Communications Policy list (a Tribal Tele/Data wonk-or-grunt-daily-must-read) and it is one application of the abstraction of territorial jurisdiction to (endpoint) ip addrs. Substitute "Tribe X" for "Canada" and you'll get the idea why source-or-sink-T-J is of interest (when I'm wearing _that_ hat). > ICraveTV, a Canadian Internet company, was forced to shut down earlier this > year after the major US TV networks objected to its steaming of live network > programming. The networks and others claimed that the company was > essentially "rebroadcasting" programming without compensation, which is > permitted in Canada, but illegal in the US. Bill Craig, iCraveTV's founder, > said that the company has now developed a system that can identify users by > country and would allow it to continue serving Canadians free. Craig says > that his "iWall" system will "verify if the computer user is in Canada or > the United States and allow them on or not on." Mr. Craig also said that > iCraveTV will charge a fee when it starts up again, functioning much like a > cable television system. > [SOURCE: New York Times (CyberTimes), AUTHOR: Barry Brown] > (http://www.nytimes.com/library/tech/00/06/cyber/articles/02icrave.html) The actual mechanism may be as "good-faith" as resorting to the ARIN block allocation to infer the applicable territorial jurisdiction, hence the risk of jurisdiction-specific service provision, or as intrusive as getting the end-user to assert (possibly without knowledge or consent) the applicable territorial jurisdiction and assume the risk of upstream compensation. The possible discussion of uses of some representation of spatial locality, those Terry touched on (transaction histories, demographics, ...) and some he didn't (persistent non-verified third-party cookies containing personal identifable information (PII), 1x1 gif images, etc. -- the webtech's vade mecum, and the analytical issues they address, as well as the end user's informed conscent, can be taken to the cookie-cutters mailing list I set up recently. List posting address: cookie-cutters@world.std.com List request address: cookie-cutters-request@world.std.com I'll write about the marketing utility of locality data in cookie-cutters, the end result should be something informational or BCP in the User-Services directorate series. The locality work which didn't go into the I-Ds I mentioned yesterday draft-polk-slp-loc-auth-server-00.txt and draft-tang-islf-req-00.txt I'll write-up after Pittsburg -- as post-Nokia this is just a hobby. Cheers, Eric P.S. If anyone from iCraveTV cares to disclose their endpoint authentication scheme I'd be happy to see 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 Fri Jun 2 16:34:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12787 for ; Fri, 2 Jun 2000 16:34:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xxPD-000JXK-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 12:46:55 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xxPC-000JXE-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 12:46:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xxPC-000LlY-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 12:46:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006021947.PAA13919@torque.pothole.com> To: Thomas Narten cc: namedroppers@ops.ietf.org, dee3@torque.pothole.com Subject: Re: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard In-reply-to: Your message of "Fri, 02 Jun 2000 11:49:23 EDT." <200006021549.LAA18266@ludwigia.raleigh.ibm.com> Date: Fri, 02 Jun 2000 15:47:05 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While draft-ietf-dnsext-simple-secure-update-01.txt replaces RFC 2137, draft-ietf-dnsext-signing-auth-01.txt really just tweaks RFC 2535 which it is an order or magnitude shorter than. I suppose 2137 could be declared historic but I'm not sure I see the point. People are not supposed to implement obsoleted RFCs and there are some elements of RFC 2137 in draft-ietf-dnsext-simple-secure-update-01.txt. I think of Historic as being for a protocol that has fallen from use or been replaced by a completely new protocol, not for a stage in the evolution of the same protocol (although such judgements are no doubt in the eye of the beholder). I think someone reading draft-ietf-dnsext-simple-secure-update-01.txt should have RFC 2137 for comparison rather than having RFC 2137 already on the trash heap, although I have no doubt that almsot all will still prefer the new draft. Donald From: Thomas Narten Message-Id: <200006021549.LAA18266@ludwigia.raleigh.ibm.com> To: namedroppers@ops.ietf.org In-Reply-To: Message from The IESG of "Fri, 02 Jun 2000 08:34:25 EDT." <200006021234.IAA00573@ietf.org> Date: Fri, 02 Jun 2000 11:49:23 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >The IESG writes: > >> The IESG has received a request from the DNS Extensions Working Group >> to consider Simple Secure Domain Name System (DNS) Dynamic Update >> as a Proposed Standard. >> This will replace/obsolete RFC2137, currently a Proposed Standard. > >> The IESG will also consider Domain Name System Security (DNSSEC) >> Signing Authority as a Proposed >> Standard, updating RFC2535 > >Both of these IDs would appear to be significant replacements of their >corresponding RFCs. Also, when a new RFC replaces on old one, its >expected to include a "Changes relative to RFC XXX" section in them to >help implementors understand what has changed. That might not make >sense here, i.e., is this replacement vs. changing. > >Question: should either of the two RFCs actually be reclassified as >Historic, as opposed to just being obsoleted? If there is little or no >deployment and the point is to not have anyone implement the old RFCs, >reclassifying them to historic might be the way to go. > >Thomas to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 16:35:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12815 for ; Fri, 2 Jun 2000 16:35:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xxT4-000JdL-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 12:50:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xxT4-000JdF-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 12:50:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xxT4-000LnE-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 12:50:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <20000602094930.A4757@Xenon.Stanford.EDU> References: ; from lewis@tislabs.com on Thu, Jun 01, 2000 at 09:00:11AM -0400 <000801bfca70$7500d540$0401a8c0@comcastwork.com> Date: Fri, 2 Jun 2000 15:48:54 -0400 To: Mark Gritter From: Edward Lewis Subject: Re: draft-costanzo-dns-gl-02.txt Cc: Edward Lewis , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12:49 PM -0400 6/2/00, Mark Gritter wrote: >On Thu, Jun 01, 2000 at 09:00:11AM -0400, Edward Lewis wrote: >> The IETF can't stop someone from implementing a DNS feature in their name >> server. The standard does define "unknown" record type handling. > >Does it? I would appreciate a reference. Well, I've been looking and it appears that I was mistaken. The reason I thought there was a standard way to handle unknown types was that this came up in the discussion of local compression. One issue was that "if a nameserver doesn't know the format of the RR, then it can't correctly uncompress the data." Looking more, in section 4.1.4 of RFC 1035 this appears: > >Pointers can only be used for occurances of a domain name where the >format is not class specific. If this were not the case, a name server >or resolver would be required to know the format of all RRs it handled. >As yet, there are no such cases, but they may occur in future RDATA >formats. Notice the middle sentance. This isn't a positive explicit affirmation of unknown RR handling, but... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 17:58:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15704 for ; Fri, 2 Jun 2000 17:58:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xyzG-000Mln-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 14:28:14 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xyzG-000Mlh-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 14:28:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xyzG-000MLY-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 14:28:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2 Jun 2000 21:27:58 -0000 Message-ID: <20000602212758.21167.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt References: <000801bfca70$7500d540$0401a8c0@comcastwork.com> <20000602094930.A4757@Xenon.Stanford.EDU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Gritter writes: > BIND 8 returns unknown record types as answers only if accompanied by a > recognized answer type. If not, you get SERVFAIL. BIND 9 is at least > more consistent: you get SERVFAIL if any unimplemented RR types are > present. Yikes! Let me make sure I understand: GL? GL? --------> --------> GL-aware client BIND 8 or 9 cache GL-aware server <-------- <-------- SERVFAIL GL You're saying that the cache doesn't pass along the packet from the server, and doesn't save the GL information for future queries? It simply drops the information and says SERVFAIL? What exactly do you mean by ``accompanied by a recognized answer type''? Normally there's only one type in the answer section. Will a CNAME to a GL work? Or a * query that returns an A and a GL? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 17:58:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15738 for ; Fri, 2 Jun 2000 17:58:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12xz3v-000Msl-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 14:33:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12xz3v-000Mse-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 14:33:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12xz3u-000MNl-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 14:33:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39382742.A01945E0@whistle.com> Date: Fri, 02 Jun 2000 14:29:38 -0700 From: Terry Lambert To: "M. T. Hollinger" CC: Mike Davison , namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt References: <200006020537.BAA07619@cs.utk.edu> <07cf01bfcc86$73c77a40$2d101c10@ucx.lkg.dec.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit M. T. Hollinger wrote: > >Terry lambert wrote: > >> Can someone give a _legitimate_ reason for wanting geographic > >> information about machines? [ ... Jerry's example ... ] > Sure, that's an example. [ ... default locale specific content ... ] [ ... locale based statistics keeping ... ] This use will simply not work, unless the draft mandates that the information either be correct or omitted. When omitted it will not work for the majority of cases. It simply can't work for dynamic IP address assignment unless the draft mandates a TTL of 0, and further mandates that all DNS servers honor this as a request not to cache, and that all DNS servers that have minimum TTL values that they substitute for cached entries (e.g. 300) discontinue this practice. This is because the DNS records are owned by ISPs, and the forward lookup of the reverse record will not give accurate GL information, without great effort and no caching. I have an ISP account with UUNET. I am dialed into a POP which is not my home POP. Where am I located? The argument that these records apply to anything other than static IP addresses, meaning machines with fixed locations, is ludicrous. > At IETF plenary meetings, we often see a list of how many > attendees are there from each country. Why? Can anyone > give a _legitimate_ reason for wanting to know how many > people from Sweden attended the Danvers IETF? (If not, > would that mean the information shouldn't be collected or > shared?) I can: in order to reassure citizens of each locale that their locale did, indeed, have representation on committees which ratified standards. This lends an air of perceived legitimacy-through-egalitarianism to IETF standards. In the technical limit, there is no additional legitimacy granted by this, but it lets non-technical people feel warm and fuzzy. Note that you are free to choose "other", if you feel your privacy is being violated by this practice. > If some people want to know, and other people want to tell > them, our role as Internet engineers is to provide a mechanism > to facilitate that communication. We have one: your web site _asks_ via a form, and your user _tells_ via a POST. GL suggests that when some people want to know, their ISP tells them, regardless of what other people want or do not want. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 19:19:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16879 for ; Fri, 2 Jun 2000 19:19:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12y0GL-000Pif-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 15:49:57 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12y0GK-000PiZ-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 15:49:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12y0GK-000Mog-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 15:49:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39382AE3.FA9DA5C6@whistle.com> Date: Fri, 02 Jun 2000 14:45:07 -0700 From: Terry Lambert To: Jerry Scharf CC: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt References: <200006020653.XAA04569@sh.lh.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jerry Scharf wrote: [ ... ] > Officially saying "use LDAP (or whatever) and here's how" > and "we hereby consider adding RR types in lieu of this > to be an extrordinary action" will give us a real way to > tell people to go away. This is perhaps workable, so long as we don't make it the job of the LDAP people to point back at the DNS people to brush off people that the DNS people have already brushed off once. We do not need a finger-pointing war. To Harald's elaboration on this suggestion: we already have the LDAP capability with SRV records, and there are algorithms (admittedly they are different from LDAPv2 and LDAPv3) for getting the base DN, so I guess the problem is already solved. Right? So we can state: That is not the type of information that belongs in the DNS. Then it's up to the people who want this information to: 1) Get an RFC for LDAP use of SRV records approved, since SRV records object to being used without an RFC per protocol on how-to-use. 2) Define schema to use for this, and convince everyone to use it and fill it out correctly for transiently connected machines on dynamically assigned IPs, just as they would have to convince people to do to deploy GLs and set TTL=0. Can we all live with that as an answer? Then the next time someone wants a new RR type for some other specific and not obviously useful addition, we can point them at that method, instead? This would certainly work to obviate the need for the GL draft going forward, and we could dismiss the idea now. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 19:38:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17008 for ; Fri, 2 Jun 2000 19:38:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12y0YB-0000U5-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 16:08:23 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12y0YB-0000Tz-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 16:08:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12y0YB-000Mvh-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 16:08:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 2 Jun 2000 16:06:37 -0700 From: Mark Gritter To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt Message-ID: <20000602160636.A16425@Xenon.Stanford.EDU> References: <000801bfca70$7500d540$0401a8c0@comcastwork.com> <20000602094930.A4757@Xenon.Stanford.EDU> <20000602212758.21167.qmail@cr.yp.to> In-Reply-To: <20000602212758.21167.qmail@cr.yp.to>; from djb@cr.yp.to on Fri, Jun 02, 2000 at 09:27:58PM -0000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, Jun 02, 2000 at 09:27:58PM -0000, D. J. Bernstein wrote: > Mark Gritter writes: > > BIND 8 returns unknown record types as answers only if accompanied by a > > recognized answer type. If not, you get SERVFAIL. BIND 9 is at least > > more consistent: you get SERVFAIL if any unimplemented RR types are > > present. > > Yikes! Let me make sure I understand: > > GL? GL? > --------> --------> > GL-aware client BIND 8 or 9 cache GL-aware server > <-------- <-------- > SERVFAIL GL > > You're saying that the cache doesn't pass along the packet from the > server, and doesn't save the GL information for future queries? It > simply drops the information and says SERVFAIL? > Yes. As was pointed out in previous discussions here, there's at least one good reason to not cache unrecognized RRs: they may include compressed names. (Verifying signatures is another.) But BIND 8 doesn't pass along anything it doesn't recognize as an answer (i.e., no recognized RRs) and BIND 9, as I understand it, synthesizes all responses rather than "forwarding" the response with the unrecognized RR in it. > What exactly do you mean by ``accompanied by a recognized answer type''? > Normally there's only one type in the answer section. Will a CNAME to a > GL work? Or a * query that returns an A and a GL? > With the version of BIND 8 I tried, an ANY query that returns both an A and a GL will be passed back to the resolver. (But subsequent ANY requests will return just the A record, of course.) I don't think CNAMEs work that way (I don't recall trying), but you can get the same behavior by putting irrelevant records (like TXT) into GL responses--- not that I would want to encourage such a thing! -- Mark Gritter http://www-cs-students.stanford.edu/~mgritter/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 2 22:58:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21002 for ; Fri, 2 Jun 2000 22:58:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12y3Gj-0007uG-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 19:02:33 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12y3Gj-0007uA-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 19:02:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12y3Gi-000No6-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 19:02:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39386234.57035D92@daimlerchrysler.com> Date: Fri, 02 Jun 2000 21:41:08 -0400 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt References: <200006020653.XAA04569@sh.lh.vix.com> <39382AE3.FA9DA5C6@whistle.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Terry Lambert wrote: > Then the next time someone wants a new RR type for some > other specific and not obviously useful addition, we can > point them at [a SRV+LDAP] method, instead? An exception should probably be made for so-called DNS "metadata", since it makes little sense to store that in a separate database. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 3 01:38:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26273 for ; Sat, 3 Jun 2000 01:38:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12y65z-000Fzs-00 for namedroppers-data@psg.com; Fri, 02 Jun 2000 22:03:39 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12y65z-000Fzm-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 22:03:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12y65z-000Ofn-00 for namedroppers@ops.ietf.org; Fri, 02 Jun 2000 22:03:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <20000602160636.A16425@Xenon.Stanford.EDU> References: <20000602212758.21167.qmail@cr.yp.to>; from djb@cr.yp.to on Fri, Jun 02, 2000 at 09:27:58PM -0000 <000801bfca70$7500d540$0401a8c0@comcastwork.com> <20000602094930.A4757@Xenon.Stanford.EDU> <20000602212758.21167.qmail@cr.yp.to> Date: Fri, 2 Jun 2000 22:28:41 -0400 To: Mark Gritter From: Edward Lewis Subject: Re: draft-costanzo-dns-gl-02.txt Cc: namedroppers@ops.ietf.org, lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 7:06 PM -0400 6/2/00, Mark Gritter wrote: >Yes. As was pointed out in previous discussions here, there's at least one >good reason to not cache unrecognized RRs: they may include compressed >names. (Verifying signatures is another.) I'd turn that statement around. Compression in the non-RFC 1035 RR's is a bad thing as the RR's format may not be understood in older servers. DNSSEC is only complicated by compressed names and uppercase names. (Perhaps the signature verification should not have required the lower casing of names in the RDATA.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 3 09:39:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06259 for ; Sat, 3 Jun 2000 09:39:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12yDXH-0004sG-00 for namedroppers-data@psg.com; Sat, 03 Jun 2000 06:00:19 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12yDXG-0004sA-00 for namedroppers@ops.ietf.org; Sat, 03 Jun 2000 06:00:18 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12yDXG-0001lR-00 for namedroppers@ops.ietf.org; Sat, 03 Jun 2000 06:00:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006030641.XAA27563@sh.lh.vix.com> To: Terry Lambert cc: namedroppers@ops.ietf.org Subject: Re: draft-costanzo-dns-gl-02.txt In-reply-to: Your message of "Fri, 02 Jun 2000 14:45:07 PDT." <39382AE3.FA9DA5C6@whistle.com> Date: Fri, 02 Jun 2000 23:41:50 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This is perhaps workable, so long as we don't make it the > job of the LDAP people to point back at the DNS people to > brush off people that the DNS people have already brushed > off once. We do not need a finger-pointing war. > > To Harald's elaboration on this suggestion: we already have > the LDAP capability with SRV records, and there are > algorithms (admittedly they are different from LDAPv2 and > LDAPv3) for getting the base DN, so I guess the problem is > already solved. Right? Being an ignorant slob about the LDAP mapping capability, I would like to hear from people who have the ideas of doing things like GL and see how this could work for them. Certainly the more general URL case the Harald proposed should be able to work. > > So we can state: > > That is not the type of information that belongs > in the DNS. > > Then it's up to the people who want this information to: > > 1) Get an RFC for LDAP use of SRV records approved, > since SRV records object to being used without > an RFC per protocol on how-to-use. Given the recent messages that this is already in use, it seems like a good idea no matter what. > > 2) Define schema to use for this, and convince > everyone to use it and fill it out correctly for > transiently connected machines on dynamically > assigned IPs, just as they would have to convince > people to do to deploy GLs and set TTL=0. I think there is also the sticky widget of where this data is attached in the hierarchy below the DN mapping you mentioned above. I have this idea that the goal is to get back just the GL (or other) schema, and so it needs to be a more specific query than just the DN. Passing the query punts this problem. > > Can we all live with that as an answer? > > Then the next time someone wants a new RR type for some > other specific and not obviously useful addition, we can > point them at that method, instead? > > This would certainly work to obviate the need for the GL > draft going forward, and we could dismiss the idea now. > > > -- Terry Lambert > -- Whistle Communications, Inc., an I.B.M. Company > -- terry@whistle.com > ------------------------------------------------------------------- > This is formal notice under California Assembly Bill 1629, enacted > 9/26/98 that any UCE sent to my email address will be billed $50 > per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 3 09:43:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06283 for ; Sat, 3 Jun 2000 09:43:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12yDZd-0004wk-00 for namedroppers-data@psg.com; Sat, 03 Jun 2000 06:02:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12yDZc-0004we-00 for namedroppers@ops.ietf.org; Sat, 03 Jun 2000 06:02:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12yDZc-0001m8-00 for namedroppers@ops.ietf.org; Sat, 03 Jun 2000 06:02:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000603111423.037b0d88@dokka.kvatro.no> Date: Sat, 03 Jun 2000 11:16:49 +0200 To: Terry Lambert , Jerry Scharf From: Harald Tveit Alvestrand Subject: LDAP (Re: draft-costanzo-dns-gl-02.txt) Cc: namedroppers@ops.ietf.org In-Reply-To: <39382AE3.FA9DA5C6@whistle.com> References: <200006020653.XAA04569@sh.lh.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 14:45 02.06.2000 -0700, Terry Lambert wrote: >To Harald's elaboration on this suggestion: we already have >the LDAP capability with SRV records, and there are >algorithms (admittedly they are different from LDAPv2 and >LDAPv3) for getting the base DN, so I guess the problem is >already solved. Right? not quite - I think SRV records for LDAP were intended to indicate "here is the address of the LDAP server to contact about information belonging to the hierarchy owned by the controller of this name". A SEE URL record would indicate "here is more information about the single named entity that this name belongs to". Note also that a SRV record can't provide the non-machine part of the URL (a search criteria, distinguished name or other info). Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 5 17:32:10 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10856 for ; Mon, 5 Jun 2000 17:32:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12z3dE-0008BO-00 for namedroppers-data@psg.com; Mon, 05 Jun 2000 13:37:56 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 12z3dE-0008BI-00 for namedroppers@ops.ietf.org; Mon, 05 Jun 2000 13:37:56 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12z3dD-000IQb-00 for namedroppers@ops.ietf.org; Mon, 05 Jun 2000 13:37:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <393C0F29.3D4D1DF9@whistle.com> Date: Mon, 05 Jun 2000 13:35:53 -0700 From: Terry Lambert To: Harald Tveit Alvestrand CC: Jerry Scharf , namedroppers@ops.ietf.org Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) References: <200006020653.XAA04569@sh.lh.vix.com> <4.3.2.7.2.20000603111423.037b0d88@dokka.kvatro.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand wrote: > At 14:45 02.06.2000 -0700, Terry Lambert wrote: > >To Harald's elaboration on this suggestion: we already have > >the LDAP capability with SRV records, and there are > >algorithms (admittedly they are different from LDAPv2 and > >LDAPv3) for getting the base DN, so I guess the problem is > >already solved. Right? > > not quite - I think SRV records for LDAP were intended > to indicate "here is the address of the LDAP server to > contact about information belonging to the hierarchy > owned by the controller of this name". > > A SEE URL record would indicate "here is more information > about the single named entity that this name belongs to". > > Note also that a SRV record can't provide the non-machine > part of the URL (a search criteria, distinguished name or > other info). Actually, it can provide whatever the draft authors wish it to provide, but you're right, it currently doesn't provide for as much as a full LDAP URL would. The current draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-locate-02.txt It does, however, provide enough to do the same job that GL is supposed to be intended to do. It would be pretty easy to define a GL schema; the RDN off the base DN could contain the actual machine name, so one directory could contain all of the information about all the machines in a domain, e.g.: objectclass GLResourceRecord requires objectClass, cn, GLAstronomicalLocation, GLCountryCode, GLPostalAddress allows GLPostalZone And the "donuts" example: donuts A 192.188.192.1 GL S3.US.45420.1910 "1425 Arbor Avenue, Dayton OH" Becomes this LDIF: dn: cn=donuts.example.com,dc=example,dc=com cn=donuts.example.com objectclass: top objectclass: GLResourceRecord GLAstronomicalLocation: S3 GLCountryCode: US GLPostalZone: 45420.1910 GLPostalAddress: 1425 Arbor Avenue, Dayton OH I locate the LDAP server for the site via: _ldap._tcp.example.com. IN SRV 0 0 389 boo.example.com. bind to the server, discover the base DN, and then within the base DN, perform the search for "donuts.example.com": (cn=donuts.example.com) which will return the appropriate GLResourceRecord object. I think the point that LDAP is a hierarchical data store, just as DNS is a hierarchical data store, and that LDAP, unlike DNS, is arbitrarily extensible, is the salient one. Plus it's appropriate to use a directory server to contain address information. I still dislike the idea that my ISP will be ratting me out about my physical location, but I suppose they could put in TXT records to do the same job today. A topic for "Risks", not this list, I suppose... -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 6 23:00:09 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23747 for ; Tue, 6 Jun 2000 23:00:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zVSG-000MLZ-00 for namedroppers-data@psg.com; Tue, 06 Jun 2000 19:20:28 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zVS4-000MLR-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:20:27 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zVS3-0000Km-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:20:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006061718.KAA09453@sh.lh.vix.com> To: "Eric A. Hall" cc: namedroppers@ops.ietf.org Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) In-reply-to: Your message of "Tue, 06 Jun 2000 10:06:11 PDT." <393D2F83.BA902B17@ehsco.com> Date: Tue, 06 Jun 2000 10:18:31 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I also prefer the SEE rrtype, but want to add a tag as well as a URL. The problem with a bare URL is it's difficult to know if what you are getting is a GL record or a yahoo map link. Remembering that DNS is for programs and not users, being able to know what is would come back is an important feature. Adding a tag allows a program to quickly tell whether attempting a TCP connection to the URL is merited. There are certainly details of such a tag to thrash through, but being able to have a LDAP-GL tag on a RR gives the applicaiton a good hint of what to expect. More to the point, if I'm after GL data, I know not to follow RRs that don't have LDAP-GL tag. I would specifically argue against IANA management of the tag namespace, but that's part of thrashing it out. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 6 23:00:48 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23758 for ; Tue, 6 Jun 2000 23:00:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zVPw-000MJ1-00 for namedroppers-data@psg.com; Tue, 06 Jun 2000 19:18:04 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zVPF-000MHO-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:17:43 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zVP1-0000Kb-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:17:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <393D2F83.BA902B17@ehsco.com> Date: Tue, 06 Jun 2000 10:06:11 -0700 From: "Eric A. Hall" To: Terry Lambert CC: Harald Tveit Alvestrand , Jerry Scharf , namedroppers@ops.ietf.org Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) References: <200006020653.XAA04569@sh.lh.vix.com> <4.3.2.7.2.20000603111423.037b0d88@dokka.kvatro.no> <393C0F29.3D4D1DF9@whistle.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> A SEE URL record would indicate "here is more information >> about the single named entity that this name belongs to". > It would be pretty easy to define a GL schema; the RDN off > the base DN could contain the actual machine name, so one > directory could contain all of the information about all > the machines in a domain, e.g.: Given that not all external references need to point to LDAP, nor is it desirable to mandate that all external references point to LDAP, I think that having a generic URL as the SEE record's data is probably the best way to go. You could just have a SEE record that pointed to a company's driving directions page with a map on it, or you could point to the full-glory LDAP data if you want to, meaning that a generic URL allows for either a simple answer or a complex answer, but doesn't require a complex answer when a simple answer is all that's desired. For non-location data, there is probably a use for a generic see-also record that is associated with common aliases. Maybe you have an ftp CNAME record, and putting a SEE ftp://ftp.domain.dom is an obvious thing to do there. Less obvious could be home pages for sub-domains with the SEE record returned along with the other domain records, or gopher:// menus for departments, or anything else you care to do. Essentially, making the referral as dumb as possible seems like the most economical thing to do from DNS' perspective, and also provides the most flexibility for the administrator without also requiring that the client have access to an LDAP agent. Dumber is probably better for a generic referral mechanism. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 6 23:01:07 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23824 for ; Tue, 6 Jun 2000 23:01:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zVTL-000MNr-00 for namedroppers-data@psg.com; Tue, 06 Jun 2000 19:21:35 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zVSz-000MMd-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:21:16 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zVSv-0000Ks-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:21:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <393D34EC.D3D3D353@whistle.com> Date: Tue, 06 Jun 2000 10:29:16 -0700 From: Terry Lambert To: "Eric A. Hall" CC: Harald Tveit Alvestrand , Jerry Scharf , namedroppers@ops.ietf.org Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) References: <200006020653.XAA04569@sh.lh.vix.com> <4.3.2.7.2.20000603111423.037b0d88@dokka.kvatro.no> <393C0F29.3D4D1DF9@whistle.com> <393D2F83.BA902B17@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric A. Hall wrote: > Essentially, making the referral as dumb as possible seems > like the most economical thing to do from DNS' perspective, > and also provides the most flexibility for the administrator > without also requiring that the client have access to an > LDAP agent. Dumber is probably better for a generic referral > mechanism. Now I have to defend GL records... 8-(. The point of introducing GL records to the DNS was, I think, to ensure that there was "One True Way" to get geographic location information about machines. Imagine if we were to try to publish DNS data over gopher:// URLs instead of a well known port with a specific protocol. It _could_ be made to work, but why bother, when it won't be commonly implemented due to it's lack of being a "One True Way"? If we can't meet this "One True Way" requirement without adding GL, then it defeats the purpose of even pretending to do the job some other way. A generic referral is perhaps useful, but it is also something that more properly belongs in KS, and thus has seriously limited utility, as anything one could imagine placing in KS would similarly not act as a useful Schelling point for a data provider and a data consumer to perform a protocol rendesvous. I don't think that I can overemphasize the need for a single, universally recognized rendevous for GL data as a requirement for the problem GL is trying to solve. Whether it's actually useful to solve this problem at all is a seperate question. If we accept for the sake of argument that the problem is worthy of soloution, then we have to meet the "One True Way" requirement, one way or another. GL is one way; specifying a directory rendevous is another, and there are uncountable other possibilities, but it's only useful if a single one is picked and deployed. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 6 23:07:55 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23836 for ; Tue, 6 Jun 2000 23:07:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zVf4-000Mdm-00 for namedroppers-data@psg.com; Tue, 06 Jun 2000 19:33:42 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zVet-000Mcr-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:33:32 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zVeo-0000LR-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:33:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <393D64FD.B8435FC4@ehsco.com> Date: Tue, 06 Jun 2000 13:54:21 -0700 From: "Eric A. Hall" To: Terry Lambert CC: Harald Tveit Alvestrand , Jerry Scharf , namedroppers@ops.ietf.org Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) References: <200006020653.XAA04569@sh.lh.vix.com> <4.3.2.7.2.20000603111423.037b0d88@dokka.kvatro.no> <393C0F29.3D4D1DF9@whistle.com> <393D2F83.BA902B17@ehsco.com> <393D34EC.D3D3D353@whistle.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Terry Lambert wrote: > A generic referral is perhaps useful, but it is also > something that more properly belongs in KS, and thus > has seriously limited utility, as anything one could > imagine placing in KS would similarly not act as a > useful Schelling point for a data provider and a data > consumer to perform a protocol rendesvous. My belief is that DNS is not viable as a generic directory service. The lack of authenticated vs anonymous queries alone precludes this usage. The lack of a version field in conjunction with the lack of in-stream definable datatypes and schema precludes it from ever becoming one, even if anonymous access is all that's ever desired (which it isn't, people want different answers depending upon who's asking each of the specific questions). The merit of a see-also rr is that it allows for rerrals to external data such as GL, not that it would make GL data in particular easier to grok. Defining explicit extensions to see-also which indicate the type of data being referenced is just as much effort as defining the GL RR and every other attribute/schema explicitly. That puts us back into the DNS-as-directory argument. This doesn't even address the issue of how you would make GL data meaningful beyond what is already provided with LOC. The *ONLY* way you will ever have assured access to valid location data is if you can find a way for every postal system in use today to be consolidated, and to get every governmental jurisdiction to mandate its use (and moreover, that they mandate it be used with accurate, globally-meaningful data). My guess is that the best resolution you will ever get is what you have now: lat/long provided on a volunteer basis. > I don't think that I can overemphasize the need for a > single, universally recognized rendevous for GL data > as a requirement for the problem GL is trying to solve. Personally, I'd suggest that adding a content-GL header to HTTP would probably be the best solution to the examples given. If a user wants to provide their location data on a per-transaction basis they can, and HTTP proxies can overwrite the data if the user is (im)mobile. The GL data can point to LDAP objects if large amounts of detail (or LDAP storage) are desired. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 6 23:08:26 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23858 for ; Tue, 6 Jun 2000 23:08:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zVfi-000MeD-00 for namedroppers-data@psg.com; Tue, 06 Jun 2000 19:34:22 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zVfZ-000Mdy-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:34:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zVfW-0000LW-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:34:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006062124.OAA13522@sh.lh.vix.com> To: Terry Lambert cc: "Eric A. Hall" , Harald Tveit Alvestrand , Jerry Scharf , namedroppers@ops.ietf.org, scharf@vix.com Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) In-reply-to: Your message of "Tue, 06 Jun 2000 10:29:16 PDT." <393D34EC.D3D3D353@whistle.com> Date: Tue, 06 Jun 2000 14:23:59 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (some of my mail to namedroppers seems to be vanishing. If you saw some of this before, I'm resending this becuase I didn't see the list echo.) Terry, I think there's a middle ground between One True Way and no idea at all. I think that there be some flavor of tag for seeing if the URL is related to GL or not. The first thing that came to mind was something like LDAP-GL, but it's an arbitrary string. To my mind, it's also not managed by the IANA except for some predefined prefixes like LDAP- ... The tage can always be null. My reason for it is that it is mighty expensive to sort through n URLs that have nothing to do with the data you are looking for. DNS is for programs, not for users. This means that the idea of put anything you want behind the URL makes it a mess for programs. This way a program can look through the RRs in the RRset and see if any have the tag that they know what to do with, and only get those. If I were writing a program, I would simply toss any URLs that I didn't recognize the tag for. Now someone could still put the wrong tag on something and I would get trash, but that's still better than without the tag, jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 6 23:10:14 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23873 for ; Tue, 6 Jun 2000 23:10:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zVQ6-000MJC-00 for namedroppers-data@psg.com; Tue, 06 Jun 2000 19:18:14 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zVPF-000MHP-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:17:54 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zVPG-0000Kd-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:17:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000606113353.00b5b570@localhost> Date: Tue, 06 Jun 2000 13:12:18 -0400 To: Thomas Narten , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard In-Reply-To: <200006021549.LAA18266@ludwigia.raleigh.ibm.com> References: <200006021234.IAA00573@ietf.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:49 AM 6/2/00 , Thomas Narten wrote: >The IESG writes: > >> The IESG has received a request from the DNS Extensions Working Group >> to consider Simple Secure Domain Name System (DNS) Dynamic Update >> as a Proposed Standard. >> This will replace/obsolete RFC2137, currently a Proposed Standard. > >> The IESG will also consider Domain Name System Security (DNSSEC) >> Signing Authority as a Proposed >> Standard, updating RFC2535 > >Both of these IDs would appear to be significant replacements of their >corresponding RFCs. Also, when a new RFC replaces on old one, its >expected to include a "Changes relative to RFC XXX" section in them to >help implementors understand what has changed. That might not make >sense here, i.e., is this replacement vs. changing. "Domain Name System Security Signing Authority" is a minor update to RFC2535 it restricts the set of keys that can sign DNS data to zone keys at APEX. This is a great simplification that is only possible as RFC2137 is obsoleted by the other draft. RFC2137 requires that other keys can sign data. Both documents contains in section 1 list of obsoleted RFCs and sections affected, but that should be broken out into "Changes .... " sections. > >Question: should either of the two RFCs actually be reclassified as >Historic, as opposed to just being obsoleted? If there is little or no >deployment and the point is to not have anyone implement the old RFCs, >reclassifying them to historic might be the way to go. > I thought Historic status is reserved for documents that are not replaced by any other document. But in this case the protocol change is significant enough to warrant moving RFC2137 to historic and consider the new one a new protocol ? But my vote is to obsolete rather than move to historic. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 6 23:11:30 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23908 for ; Tue, 6 Jun 2000 23:11:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zVgk-000Mga-00 for namedroppers-data@psg.com; Tue, 06 Jun 2000 19:35:26 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zVge-000MgK-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:35:24 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zVgX-0000Lc-00 for namedroppers@ops.ietf.org; Tue, 06 Jun 2000 19:35:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000606233925.0b03b1a8@dokka.kvatro.no> Date: Tue, 06 Jun 2000 23:42:50 +0200 To: Jerry Scharf , Terry Lambert From: Harald Tveit Alvestrand Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) Cc: "Eric A. Hall" , Jerry Scharf , namedroppers@ops.ietf.org, scharf@vix.com In-Reply-To: <200006062124.OAA13522@sh.lh.vix.com> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 14:23 06.06.2000 -0700, Jerry Scharf wrote: >My reason for it is that it is mighty expensive to sort through n URLs that >have nothing to do with the data you are looking for. DNS is for programs, >not >for users. This means that the idea of put anything you want behind the URL >makes it a mess for programs. This way a program can look through the RRs in >the RRset and see if any have the tag that they know what to do with, and >only >get those. If I were writing a program, I would simply toss any URLs that I >didn't recognize the tag for. Now someone could still put the wrong tag on >something and I would get trash, but that's still better than without the tag the approach of a text tag has been used with some success in LDAP. See this RFC: 2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs). M. Smith. January 1997. (Format: TXT=8757 bytes) (Status: PROPOSED STANDARD) Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 7 14:34:18 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17826 for ; Wed, 7 Jun 2000 14:34:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zk3v-000F4p-00 for namedroppers-data@psg.com; Wed, 07 Jun 2000 10:56:19 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zk3u-000F4S-00 for namedroppers@ops.ietf.org; Wed, 07 Jun 2000 10:56:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zjyE-0000ad-00 for namedroppers@ops.ietf.org; Wed, 07 Jun 2000 10:50:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <001c01bfd083$aba6ed00$44ef0618@union1.nj.home.com> Reply-To: "Al Costanzo" From: "Al Costanzo" To: "Terry Lambert" , "Eric A. Hall" Cc: "Harald Tveit Alvestrand" , "Jerry Scharf" , References: <200006020653.XAA04569@sh.lh.vix.com> <4.3.2.7.2.20000603111423.037b0d88@dokka.kvatro.no> <393C0F29.3D4D1DF9@whistle.com> <393D2F83.BA902B17@ehsco.com> <393D34EC.D3D3D353@whistle.com> Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) Date: Wed, 7 Jun 2000 09:24:09 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The point of introducing GL records to the DNS was, I > think, to ensure that there was "One True Way" to get > geographic location information about machines. > Terry, everyone... I am not sure if there will ever be ONE TRUE way. But your point was taken when the draft was written. This is why DNS was chosen in the first place. Every ISP needs to run DNS and already has to administer it. Does/will every ISP administrate and use LDAP? I think not. The object of this draft was to 'simplify' the introduction of geographical data for machines. I see geographic RRs (and there are a few [ not just LOC ] ) seldom used. Although GL is designed to be machine read, it is also easily to visually reference the machines location and easy to administer. Why add complexity? Let me also address a few other points that I have read on this list: Eric: I do not think of GL data as external. I see it as missing from DNS... and it is my opinion it belongs there/here. >The *ONLY* way you >will ever have assured access to valid location data is if you can find >a way for every postal system in use today to be consolidated I do not agree... LOC is only as valid as the person using the GPS to figure out what belongs in there what good is the GPS data if it is entered wrong by an administrator that is a wiz at computers but can't use a GPS? GL is only as valid as the person inputting the data as well, but everyone know their postal address (I hope). Any address may be input in the qouted string argument and every country has a ISO country code, so evern if the country does not use postal codes, the country and region are easily definable. ------ To address the issue of dynamic ips... if you wanted to enter GL information you would simply adjust the 'Hierarchical Locator' to an imprecise location. Most dynamic ips come out of pools that service a region or area, you would mearly use as much data as available for the ip and you would know a 'general area' of the machine. ------ As far as the Astronomical Location is concerned (being silly). This was included in the draft because the issue was raised - on this list - 'How would you address a computer on a space station? or Mars?' First the Astronomical Location (AL) would be defined by a request going to and being approved by IANA. To define the GL RR you would merely use the new AL and the country code would be set to the country of origin of the device. The quoted string would be used for the rest of the information. Regards, Al to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 7 14:36:29 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17864 for ; Wed, 7 Jun 2000 14:36:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zk3t-000F4c-00 for namedroppers-data@psg.com; Wed, 07 Jun 2000 10:56:17 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zk3s-000F4S-00 for namedroppers@ops.ietf.org; Wed, 07 Jun 2000 10:56:16 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zhPm-0000T7-00 for namedroppers@ops.ietf.org; Wed, 07 Jun 2000 08:06:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006071301.JAA21774@torque.pothole.com> To: "Eric A. Hall" cc: Harald Tveit Alvestrand , namedroppers@ops.ietf.org Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) In-reply-to: Your message of "Tue, 06 Jun 2000 13:54:21 PDT." <393D64FD.B8435FC4@ehsco.com> Date: Wed, 07 Jun 2000 09:01:29 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Eric A. Hall" Message-ID: <393D64FD.B8435FC4@ehsco.com> Date: Tue, 06 Jun 2000 13:54:21 -0700 To: Terry Lambert CC: Harald Tveit Alvestrand , Jerry Scharf , namedroppers@ops.ietf.org References: <200006020653.XAA04569@sh.lh.vix.com> <4.3.2.7.2.20000603111423.037b0d88 @dokka.kvatro.no> <393C0F29.3D4D1DF9@whistle.com> <393D2F83.BA902B17@ehsco.com> <393D 34EC.D3D3D353@whistle.com> >My belief is that DNS is not viable as a generic directory service. The Agree. >lack of authenticated vs anonymous queries alone precludes this usage. DNS security provides for signing and thus authenticating queries. The worst problem is lack of approximate/pattern/range searching, lack of multiple attribures to search on, etc. >The lack of a version field in conjunction with the lack of in-stream >definable datatypes and schema precludes it from ever becoming one, even >if anonymous access is all that's ever desired (which it isn't, people >want different answers depending upon who's asking each of the specific >questions). Any data you wanted to store could have a version field built in. >The merit of a see-also rr is that it allows for rerrals to external >data such as GL, not that it would make GL data in particular easier to >grok. Defining explicit extensions to see-also which indicate the type >of data being referenced is just as much effort as defining the GL RR >and every other attribute/schema explicitly. That puts us back into the >DNS-as-directory argument. > >This doesn't even address the issue of how you would make GL data >meaningful beyond what is already provided with LOC. The *ONLY* way you >will ever have assured access to valid location data is if you can find >a way for every postal system in use today to be consolidated, and to >get every governmental jurisdiction to mandate its use (and moreover, >that they mandate it be used with accurate, globally-meaningful data). >My guess is that the best resolution you will ever get is what you have >now: lat/long provided on a volunteer basis. > >> I don't think that I can overemphasize the need for a >> single, universally recognized rendevous for GL data >> as a requirement for the problem GL is trying to solve. > >Personally, I'd suggest that adding a content-GL header to HTTP would >probably be the best solution to the examples given. If a user wants to >provide their location data on a per-transaction basis they can, and >HTTP proxies can overwrite the data if the user is (im)mobile. The GL >data can point to LDAP objects if large amounts of detail (or LDAP >storage) are desired. > >-- >Eric A. Hall ehall@ehsco.com >+1-650-685-0557 http://www.ehsco.com Donald to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 8 00:21:51 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26714 for ; Thu, 8 Jun 2000 00:21:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12zsvN-000Pg3-00 for namedroppers-data@psg.com; Wed, 07 Jun 2000 20:24:05 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12zsvL-000Pfx-00 for namedroppers@ops.ietf.org; Wed, 07 Jun 2000 20:24:04 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12zsvJ-0000sP-00 for namedroppers@ops.ietf.org; Wed, 07 Jun 2000 23:24:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <393D34EC.D3D3D353@whistle.com> References: <200006020653.XAA04569@sh.lh.vix.com> <4.3.2.7.2.20000603111423.037b0d88@dokka.kvatro.no> <393C0F29.3D4D1DF9@whistle.com> <393D2F83.BA902B17@ehsco.com> Date: Wed, 7 Jun 2000 22:09:11 +0200 To: namedroppers@ops.ietf.org From: Alfred Novacek Subject: Re: LDAP (Re: draft-costanzo-dns-gl-02.txt) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Terry Lambert wrote: [...] > >The point of introducing GL records to the DNS was, I >think, to ensure that there was "One True Way" to get >geographic location information about machines. > [...] > >I don't think that I can overemphasize the need for a >single, universally recognized rendevous for GL data >as a requirement for the problem GL is trying to solve. > >Whether it's actually useful to solve this problem at >all is a seperate question. > [...] That's the point where my doubt whether GL RRs (or another mechanism that uses semistatical services like DNS) will really be usefull for getting location information: There is at least one application that may not be implemented efficiently this way: the case of the mobile user that is determining its position via GPS (or a similar device) and that wants to make this information available to others (e.g. the owner of a shipping agency that wants to steer his fleet the most efficient way). Maybe extensibility of the scheme may be of benefit, too; e.g. user service might want to know the telephone number of the user (why maintain all these informations in different places?); but then, security considerations (who shall be allowed to see which information) come into play, too. Any solution that doesn't consider such cases simply cannot be the "One True Way". A better approach might be to ask the host itself. If predefined protocols shall be used, LDAP and HTTP are suitable candidates (use some predefined URL like http://target-host.example.com/cgi-bin/location that delivers a document of "GL" XML DTD). If efficiency of communications is required, some simple UDP-based request-response protocol may be designed. Either way, implementing and deploying will be much faster than changing the way DNS works (by defining a new RR). Any of these protocols will cover the cases of the mobile user and of the local user that wants to provide this information himself. However, when central administration is desired, either a way to centralize configuration (and/or preconfiguration) or a way to redirect these queries to a central server must be provided (the SEE RR proposal might be usefull to provide this; however, redirection mechanisms of existing protocols may be used, too). BTW, allowing for various ways to provide "GL" information will eliminate another problem, too: If only DNS-Admins may enter this information, and many of them (I confess I'm one of them) see only the burden this places on them, at least the quality of the information provided will suffer (lazy updates, ...); in the worst case, the proposal simply won't take off (I think that's one reason why LOC failed). To summarize, I don't think that the DNS is a good place for location information; and a GL RR definitely isn't the "One True Way" to provide it. Sincerely Yours - Alfred Novacek ------------------------------------------------------------------------ Dipl.-Ing. Alfred Novacek Institute for Data Processing in Business Administrations, Economics and Social Sciences Johannes Kepler University Linz / Austria E-Mail: Novacek@idv.uni-linz.ac.at Novacek@pop.idv.uni-linz.ac.at WWW: http://www.idv.uni-linz.ac.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 Thu Jun 8 00:31:29 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26882 for ; Thu, 8 Jun 2000 00:31:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 12ztLP-0000A1-00 for namedroppers-data@psg.com; Wed, 07 Jun 2000 20:50:59 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 12ztLM-00009r-00 for namedroppers@ops.ietf.org; Wed, 07 Jun 2000 20:50:57 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12ztLL-0000tv-00 for namedroppers@ops.ietf.org; Wed, 07 Jun 2000 23:50:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006072110.RAA01300@hygro.adsl.duke.edu> To: Olafur Gudmundsson cc: namedroppers@ops.ietf.org Subject: Re: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard In-Reply-To: Message from Olafur Gudmundsson of "Tue, 06 Jun 2000 13:12:18 EDT." <4.1.20000606113353.00b5b570@localhost> Date: Wed, 07 Jun 2000 17:10:28 -0400 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > "Domain Name System Security Signing Authority" is a minor update to > RFC2535 it restricts the set of keys that can sign DNS data to zone > keys at APEX. This is a great simplification that is only possible > as RFC2137 is obsoleted by the other draft. RFC2137 requires that > other keys can sign data. Having now dug deeper (as I should have done before sending my first note!), I agree that 2535 is just updated. > I thought Historic status is reserved for documents that are not replaced by > any other document. But in this case the protocol change is significant > enough to warrant moving RFC2137 to historic and consider the new one a > new protocol ? Take a look at 2026 for guidelines. The paragraph I find most compelling here is: > 6.4 Retiring a Standard > > As the technology changes and matures, it is possible for a new > Standard specification to be so clearly superior technically that one > or more existing standards track specifications for the same function > should be retired. In this case, or when it is felt for some other > reason that an existing standards track specification should be > retired, the IESG shall approve a change of status of the old > specification(s) to Historic. This recommendation shall be issued > with the same Last-Call and notification procedures used for any > other standards action. A request to retire an existing standard can > originate from a Working Group, an Area Director or some other > interested party. If the message we want to send is "don't implement 2137", reclassifying it as historic would seem stronger. "Donald E. Eastlake 3rd" writes: > I think of Historic as being for a protocol that has fallen from use > or been replaced by a completely new protocol, not for a stage in > the evolution of the same protocol (although such judgements are no > doubt in the eye of the beholder). Reclassifying a document historic is also done to send a message. I.e., RIP version 1 was reclassified to historic despite widespread use precisely because RIP version 2 was what we wanted folks to implement. > I think someone reading > draft-ietf-dnsext-simple-secure-update-01.txt should have RFC 2137 > for comparison rather than having RFC 2137 already on the trash > heap, although I have no doubt that almsot all will still prefer the > new draft. What I'm hearing from these messages is that we don't want to give implementors a choice as to which to implement. We want them to implement the new ID. Reclassifying the document historic doesn't prevent people from reading it. Thomas to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 9 13:52:38 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16134 for ; Fri, 9 Jun 2000 13:52:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 130SFC-000IN8-00 for namedroppers-data@psg.com; Fri, 09 Jun 2000 10:06:54 -0700 Received: from [63.96.67.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 130SFB-000IMp-00 for namedroppers@ops.ietf.org; Fri, 09 Jun 2000 10:06:53 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 130SFA-0000V4-00 for namedroppers@ops.ietf.org; Fri, 09 Jun 2000 13:06:52 -0400 Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Jun 2000 11:26:28 -0400 To: namedroppers From: Edward Lewis Subject: Redux: Why I want to remove the null key (SIG) Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In a confernce call yesterday with members of ISC, we hit upon a situation in which the current use of the NULL key is a bad idea. (This is in light of the Signing Autority draft.) As the spec currently stands, a secured parent is not required to hold a key for a secured child, but is required to hold a NULL key (signed by the parent) for an unsecured child (that is not able to hold it's own NULL key). The situation that has arisen in the implementation is this: Given a secured parent zone and a delegated child zone that uses zone keys which are validated off-tree (i.e., not by the parent) the following happens: In the parent zone: child NS child KEY null SIG KEY ... NXT SIG NXT In the child zone: child SOA SIG SOA NS SIG NS KEY SIG KEY (signed by Mars Certification Agency) NXT SIG NXT The problem that arises is the conflicting KEY sets, particularly when the two zones share an authoritative name server. This was legal under the policy in RFC 2535, section 6, but is not legal given the updating draft. According to 2535, the credibility of the child's KEY would force a "hiding" of the parent's NULL key, and certification chains would be formed to the certifying authority. The Signing Authority does not account for off-tree certification, not at least until we understand it better. This will be fused into the promised and oft delayed update to the Zone Status Clarification draft. I just figured I'd air this for comments now. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 9 13:53:52 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16150 for ; Fri, 9 Jun 2000 13:53:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 130S1g-000I3q-00 for namedroppers-data@psg.com; Fri, 09 Jun 2000 09:52:56 -0700 Received: from ns1.crossbeamsys.com ([63.96.67.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 130S1f-000I3k-00 for namedroppers@ops.ietf.org; Fri, 09 Jun 2000 09:52:56 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 130S1e-0000Ss-00 for namedroppers@ops.ietf.org; Fri, 09 Jun 2000 12:52:54 -0400 Message-Id: <200006091109.HAA08458@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tkey-03.txt Date: Fri, 09 Jun 2000 07:09:08 -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 : Secret Key Establishment for DNS (TKEY RR) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tkey-03.txt Pages : 17 Date : 08-Jun-00 [draft-ietf-dnsext-tsig-*.txt] provides a means of authenticating Domain Name System (DNS) queries and responses using shared secret keys via the TSIG resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a TKEY RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-03.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-tkey-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tkey-03.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: <20000608093843.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000608093843.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 9 13:54:12 2000 Received: from psg.com ([147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16164 for ; Fri, 9 Jun 2000 13:54:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 130S1m-000I3y-00 for namedroppers-data@psg.com; Fri, 09 Jun 2000 09:53:02 -0700 Received: from ns1.crossbeamsys.com ([63.96.67.2] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 130S1l-000I3s-00 for namedroppers@ops.ietf.org; Fri, 09 Jun 2000 09:53:01 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 130S1k-0000Su-00 for namedroppers@ops.ietf.org; Fri, 09 Jun 2000 12:53:00 -0400 Message-Id: <200006091109.HAA08442@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-sig-zero-02.txt Date: Fri, 09 Jun 2000 07:09:04 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Request and Transaction Signatures ( SIG(0)s ) Author(s) : D. Eastlake Filename : draft-ietf-dnsext-sig-zero-02.txt Pages : 9 Date : 08-Jun-00 Extensions to the Domain Name System (DNS) are described in [RFC 2535] that can provide data origin and transaction integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Implementation experience has indicated the need for minor but non- interoperable changes in Request and Transaction signature resource records ( SIG(0)s ). These changes are documented herein. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-sig-zero-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-sig-zero-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-sig-zero-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000608093823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-sig-zero-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-sig-zero-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000608093823.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 Sun Jun 11 13:58:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08664 for ; Sun, 11 Jun 2000 13:58:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131B9m-000PtQ-00 for namedroppers-data@psg.com; Sun, 11 Jun 2000 10:04:18 -0700 Received: from [210.81.41.137] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131B9m-000PtI-00 for namedroppers@ops.ietf.org; Sun, 11 Jun 2000 10:04:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131B9j-0000TP-00 for namedroppers@ops.ietf.org; Mon, 12 Jun 2000 02:04:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: fred@cisco.com Date: Sun, 11 Jun 2000 06:00:14 -0700 (PDT) Message-Id: <200006111300.GAA02481@irp-view7.cisco.com> To: drine@cs.gmu.edu, hyangyih@cs.gmu.edu, namedroppers@internic.net, xwang4@cs.gmu.edu Subject: draft-whr-dnsext-secure-online-update-00.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I notice that you recently posted a new internet draft. A document that might be worth reading is http://www.ietf.org/ID-nits.html This document was put together by members of the IESG to help the community know what are the most common problems that we see in documents, whether from working groups or individual submissions, and pro-actively avoid them. This is an automatic email; please don't conclude that I have discovered something awful about your draft, as I haven't even read it yet. Rather, I'm just letting you know that there is a list of common issues that get raised over and over again in IESG reviews, and I'd like to save you the hassle by letting you see for yourself whether any of them apply. Let me know if you have any questions I can answer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jun 11 18:24:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09933 for ; Sun, 11 Jun 2000 18:24:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131Fk0-00079y-00 for namedroppers-data@psg.com; Sun, 11 Jun 2000 14:58:00 -0700 Received: from [210.81.41.137] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131Fjy-00079p-00 for namedroppers@ops.ietf.org; Sun, 11 Jun 2000 14:57:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131Fjw-0000J6-00 for namedroppers@ops.ietf.org; Mon, 12 Jun 2000 06:57:56 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3943F1B8.322D0908@ehsco.com> Date: Sun, 11 Jun 2000 13:08:24 -0700 From: "Eric A. Hall" To: namedroppers Subject: should retry have unique ID Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm wondering what the group experience is in regard to Identifiers on retry queries. Should each retry have a different Identifier? Nobody seems to do this today (limited testing) but I'm wondering if that's the proper behavior. Scenario: client sends query to server-a for resolution, but server-a is behind a slow connection and so it takes >5s to get an answer or server-a is down/unreachable for some reason, so client also sends the query to server-b for resolution. With all of the implementations that I have tested, the queries to server-a and server-b both have the same Identifier. Should they? How does the client tell the answers apart, or does it even need to? Surely there are some scenarios where the data is different or where some other form of selection needs to occur. I will assume that resolvers are using IP addresses or some other data to match the answers up when multiple responses are received and some form of selection needs to be made. It seems that given the nature of proxies and firewalls and so forth that these kinds of data points are not always entirely reliable, and become less so as time goes by. If that's the case, then why not just use different Identifiers in the messages? Has experience shown this is not necessary, or does everybody view multiple responses with the same Identifier as noise and discarded? 1035 is vague at best on the precise rules associated with this field so I am wondering what experience has shown. Thanks for any data. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 12 10:09:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02421 for ; Mon, 12 Jun 2000 10:09:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131UJX-0004I2-00 for namedroppers-data@psg.com; Mon, 12 Jun 2000 06:31:39 -0700 Received: from [210.81.41.133] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131UJW-0004Hv-00 for namedroppers@ops.ietf.org; Mon, 12 Jun 2000 06:31:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131UJX-0000qT-00 for namedroppers@ops.ietf.org; Mon, 12 Jun 2000 22:31:39 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006121246.FAA25062@boreas.isi.edu> Subject: Re: Redux: Why I want to remove the null key (SIG) To: lewis@tislabs.com (Edward Lewis) Date: Mon, 12 Jun 100 05:46:04 -0700 (PDT) Cc: namedroppers@ops.ietf.org, lewis@tislabs.com In-Reply-To: from "Edward Lewis" at Jun 9, 0 11:26:28 am Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % As the spec currently stands, a secured parent is not required to hold a % key for a secured child, but is required to hold a NULL key (signed by the % parent) for an unsecured child (that is not able to hold it's own NULL key). % How does the parent learn that the child isnow secure and is can drop the NULL key? --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 Jun 12 10:09:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02422 for ; Mon, 12 Jun 2000 10:09:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131UGJ-0004Ey-00 for namedroppers-data@psg.com; Mon, 12 Jun 2000 06:28:19 -0700 Received: from [210.81.41.133] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131UGI-0004Er-00 for namedroppers@ops.ietf.org; Mon, 12 Jun 2000 06:28:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131UGM-0000pK-00 for namedroppers@ops.ietf.org; Mon, 12 Jun 2000 22:28:22 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006121242.FAA24754@boreas.isi.edu> Subject: Re: Why I want to remove the null key SIG To: lewis@tislabs.com (Edward Lewis) Date: Mon, 12 Jun 100 05:42:38 -0700 (PDT) Cc: namedroppers@ops.ietf.org, lewis@tislabs.com In-Reply-To: from "Edward Lewis" at May 30, 0 11:09:23 am Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % In case you are wondering - I don't think the addition of the % aforementioned record is a foregone conclusion. I am trying to identify % ways that reduce the amount of information a parent must know and hold % about a child. % I'm coming to the conclusion that operationally we are faced w/ the following: DNSsec COTS (common, off the shelf) technology large flat spaces ... pick two. We can have DNSsec with COTS but then large flat name spaces become untenable. We can have DNSsec w/ large flat spaces, but then have to have special hw or we can have large flat spaces & COTS, giving up DNSsec. -- --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 Jun 12 10:10:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02448 for ; Mon, 12 Jun 2000 10:10:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131UJp-0004Il-00 for namedroppers-data@psg.com; Mon, 12 Jun 2000 06:31:57 -0700 Received: from [210.81.41.133] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131UJo-0004Id-00 for namedroppers@ops.ietf.org; Mon, 12 Jun 2000 06:31:56 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131UJp-0000qh-00 for namedroppers@ops.ietf.org; Mon, 12 Jun 2000 22:31:57 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006121256.WAA27484@bsdi.dv.isc.org> To: "Eric A. Hall" Cc: namedroppers From: Mark.Andrews@nominum.com Subject: Re: should retry have unique ID In-reply-to: Your message of "Sun, 11 Jun 2000 13:08:24 MST." <3943F1B8.322D0908@ehsco.com> Date: Mon, 12 Jun 2000 22:56:11 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I'm wondering what the group experience is in regard to Identifiers on > retry queries. Should each retry have a different Identifier? Nobody > seems to do this today (limited testing) but I'm wondering if that's the > proper behavior. > > Scenario: client sends query to server-a for resolution, but server-a is > behind a slow connection and so it takes >5s to get an answer or > server-a is down/unreachable for some reason, so client also sends the > query to server-b for resolution. With all of the implementations that I > have tested, the queries to server-a and server-b both have the same > Identifier. Should they? How does the client tell the answers apart, or > does it even need to? It can tell the answers apart by looking at the IP address the response comes from not that it needs to as it is looking for a answer and both servers should be providing the same view of the world. > Surely there are some scenarios where the data is different or where > some other form of selection needs to occur. I will assume that > resolvers are using IP addresses or some other data to match the answers > up when multiple responses are received and some form of selection needs > to be made. In general the first answer recieved is processed provided it has come from an address the query was sent to. Subsequent answers are discarded either a the kernel level or at the application layer. > It seems that given the nature of proxies and firewalls and > so forth that these kinds of data points are not always entirely > reliable, and become less so as time goes by. No. They actually are getting better as answers which are not expected are discarded and people complain when the DNS does not work so bugs tend to get fixed fast. > > If that's the case, then why not just use different Identifiers in the > messages? Has experience shown this is not necessary, or does everybody > view multiple responses with the same Identifier as noise and discarded? Different ID's for the same question are not necessary. This does not mean however that an implementation that chooses to use different ID's is broken. Using different ID's per IP is a way of allowing more queries to be in progress at once than using a single ID space. It is good form however to use the same ID to the same server as this allows the server to discard multiple queries if it is still processing the original query. > > 1035 is vague at best on the precise rules associated with this field so > I am wondering what experience has shown. Thanks for any data. > > -- > 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. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 13 05:27:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01074 for ; Tue, 13 Jun 2000 05:27:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131mAq-000KAi-00 for namedroppers-data@psg.com; Tue, 13 Jun 2000 01:35:52 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131mAo-000KAc-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 01:35:51 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131mB1-0000bh-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 17:36:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000612231915.02bf3d40@dokka.kvatro.no> Date: Mon, 12 Jun 2000 23:19:56 +0200 To: Bill Manning , lewis@tislabs.com (Edward Lewis) From: Harald Tveit Alvestrand Subject: Re: Redux: Why I want to remove the null key (SIG) Cc: namedroppers@ops.ietf.org, lewis@tislabs.com In-Reply-To: <200006121246.FAA25062@boreas.isi.edu> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 05:46 12.06.2000 -0700, Bill Manning wrote: >% As the spec currently stands, a secured parent is not required to hold a >% key for a secured child, but is required to hold a NULL key (signed by the >% parent) for an unsecured child (that is not able to hold it's own NULL key). >% > > How does the parent learn that the child isnow secure > and is can drop the NULL key? when it decides to sign the child's key, that seems an obvious conclusion to draw. if it doesn't want to sign the child's key, why should it consider it secure, or ask anyone else to do that? Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 13 18:53:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24297 for ; Tue, 13 Jun 2000 18:53:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131ytG-0004Mt-00 for namedroppers-data@psg.com; Tue, 13 Jun 2000 15:10:34 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131ytF-0004Mm-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 15:10:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131xmo-00015e-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 14:59:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006131649.MAA14668@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: Domain Name System (DNS) IANA Considerations to BCP Reply-to: iesg@ietf.org Date: Tue, 13 Jun 2000 12:49:42 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has received a request from the DNS Extensions Working Group to consider Domain Name System (DNS) IANA Considerations as a BCP. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 27, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-iana-dns-00.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 13 18:53:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24308 for ; Tue, 13 Jun 2000 18:53:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131yut-0004QL-00 for namedroppers-data@psg.com; Tue, 13 Jun 2000 15:12:15 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131yus-0004QF-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 15:12:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131xEs-0000xD-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 14:24:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006131530.IAA19304@boreas.isi.edu> Subject: Re: Redux: Why I want to remove the null key (SIG) To: roy@nlnetlabs.nl (Roy Arends) Date: Tue, 13 Jun 100 08:30:10 -0700 (PDT) Cc: bmanning@ISI.EDU, lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: from "Roy Arends" at Jun 13, 0 04:17:02 pm Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % % On Mon, 12 Jun 100, Bill Manning wrote: % % > % As the spec currently stands, a secured parent is not required to hold a % > % key for a secured child, but is required to hold a NULL key (signed by the % > % parent) for an unsecured child (that is not able to hold it's own NULL key). % > % % > % > How does the parent learn that the child isnow secure % > and is can drop the NULL key? % % The child asks the parent to remove the null-key, the parent can (should % ?) verify the child's (null) KEY to make sure that the child has a valid % (null) KEY. How does the child ask? -- --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 Jun 13 18:53:36 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24319 for ; Tue, 13 Jun 2000 18:53:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131yul-0004Pt-00 for namedroppers-data@psg.com; Tue, 13 Jun 2000 15:12:07 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131yuk-0004Pm-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 15:12:07 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131x3D-0000uA-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 14:12:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 13 Jun 2000 16:17:02 +0200 (CEST) From: Roy Arends To: Bill Manning cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: Redux: Why I want to remove the null key (SIG) In-Reply-To: <200006121246.FAA25062@boreas.isi.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 12 Jun 100, Bill Manning wrote: > % As the spec currently stands, a secured parent is not required to hold a > % key for a secured child, but is required to hold a NULL key (signed by the > % parent) for an unsecured child (that is not able to hold it's own NULL key). > % > > How does the parent learn that the child isnow secure > and is can drop the NULL key? The child asks the parent to remove the null-key, the parent can (should ?) verify the child's (null) KEY to make sure that the child has a valid (null) KEY. Removing the NULL-key at parent simply indicates that the child handles their own keys. This implies that the child is responsible for it's own security, and NOT that the child is secure. -roy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 13 18:53:53 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24330 for ; Tue, 13 Jun 2000 18:53:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131yur-0004QD-00 for namedroppers-data@psg.com; Tue, 13 Jun 2000 15:12:13 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131yuq-0004Q7-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 15:12:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131xEL-0000xA-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 14:24:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006131527.IAA19177@boreas.isi.edu> Subject: Re: Why I want to remove the null key SIG To: jaap@nic.nl (Jaap Akkerhuis) Date: Tue, 13 Jun 100 08:27:56 -0700 (PDT) Cc: bmanning@ISI.EDU, lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: <200006131244.OAA53703@bartok.sidn.nl> from "Jaap Akkerhuis" at Jun 13, 0 02:44:51 pm Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % We can have DNSsec with COTS but then large flat name spaces % become untenable. We can have DNSsec w/ large flat spaces, % but then have to have special hw or we can have large flat % spaces & COTS, giving up DNSsec. % % % On what grounds do you come to this conclusion? Do you have any % data to support this? % % jaap Ok, I'll admint some unlisted assumptions. ) zones should be signed in a timely manner e.g. less than 4hours ) COTS technologies today are represented by 1 or 2 G of memory, subGhz processors. ) large flat name spaces have around 1 million entries tests done in the US on some large zones (com.) and some tests done in Europe (de.) indicate that with current COTS and these zones, the time test fails. -- --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 Jun 13 18:54:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24341 for ; Tue, 13 Jun 2000 18:54:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131yuW-0004PQ-00 for namedroppers-data@psg.com; Tue, 13 Jun 2000 15:11:52 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131yuV-0004PK-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 15:11:52 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131wlB-0000s0-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 13:54:05 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006131244.OAA53703@bartok.sidn.nl> To: Bill Manning cc: lewis@tislabs.com (Edward Lewis), namedroppers@ops.ietf.org Subject: Re: Why I want to remove the null key SIG In-reply-to: Your message of Mon, 12 Jun 2000 05:42:38 -0700. <200006121242.FAA24754@boreas.isi.edu> Date: Tue, 13 Jun 2000 14:44:51 +0200 From: Jaap Akkerhuis Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Bill Manning] I'm coming to the conclusion that operationally we are faced w/ the following: DNSsec COTS (common, off the shelf) technology large flat spaces ... pick two. We can have DNSsec with COTS but then large flat name spaces become untenable. We can have DNSsec w/ large flat spaces, but then have to have special hw or we can have large flat spaces & COTS, giving up DNSsec. On what grounds do you come to this conclusion? Do you have any data to support this? jaap to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 13 18:54:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24365 for ; Tue, 13 Jun 2000 18:54:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131yuP-0004PH-00 for namedroppers-data@psg.com; Tue, 13 Jun 2000 15:11:45 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131yuO-0004PB-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 15:11:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131xCv-0000wR-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 14:22:45 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006131517.IAA18283@boreas.isi.edu> Subject: Re: Redux: Why I want to remove the null key (SIG) To: Harald@Alvestrand.no (Harald Tveit Alvestrand) Date: Tue, 13 Jun 100 08:17:15 -0700 (PDT) Cc: bmanning@ISI.EDU, lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: <4.3.2.7.2.20000612231915.02bf3d40@dokka.kvatro.no> from "Harald Tveit Alvestrand" at Jun 12, 0 11:19:56 pm Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % >% As the spec currently stands, a secured parent is not required to hold a % >% key for a secured child, but is required to hold a NULL key (signed by the % >% parent) for an unsecured child (that is not able to hold it's own NULL key). % > How does the parent learn that the child isnow secure % > and is can drop the NULL key? % % when it decides to sign the child's key, that seems an obvious conclusion % to draw. % if it doesn't want to sign the child's key, why should it consider it % secure, or ask anyone else to do that? How does the parent learn the child has a key that it should sign? -- --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 Jun 13 18:57:53 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24384 for ; Tue, 13 Jun 2000 18:57:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131ytE-0004Mk-00 for namedroppers-data@psg.com; Tue, 13 Jun 2000 15:10:32 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131ytD-0004Me-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 15:10:31 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131xwQ-0001Au-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 15:09:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006131755.KAA06848@boreas.isi.edu> Subject: Re: Last Call: Domain Name System (DNS) IANA Considerations to BCP To: iesg@ietf.org Date: Tue, 13 Jun 100 10:55:32 -0700 (PDT) Cc: IETF-Announce:@ietf.org, ;;;@ietf.org;, namedroppers@ops.ietf.org In-Reply-To: <200006131649.MAA14668@ietf.org> from "The IESG" at Jun 13, 0 12:49:42 pm Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It is useful to note that although this draft has a -00 extention, it has been discussed and revised extensivly under the draft lable draft-ietf-dnsind-iana-dns-05.txt. The two are functionally identical. % % % The IESG has received a request from the DNS Extensions Working Group % to consider Domain Name System (DNS) IANA Considerations % as a BCP. % % The IESG plans to make a decision in the next few weeks, and solicits % final comments on this action. Please send any comments to the % iesg@ietf.org or ietf@ietf.org mailing lists by June 27, 2000. % % Files can be obtained via % http://www.ietf.org/internet-drafts/draft-ietf-dnsext-iana-dns-00.txt % % -- --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jun 13 19:00:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24493 for ; Tue, 13 Jun 2000 19:00:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 131z7n-0004na-00 for namedroppers-data@psg.com; Tue, 13 Jun 2000 15:25:35 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 131z7m-0004nS-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 15:25:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 131z7r-0001IO-00 for namedroppers@ops.ietf.org; Tue, 13 Jun 2000 16:25:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard Date: Tue, 13 Jun 2000 13:46:34 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690AD71B21@SIT.platinum.corp.microsoft.com> From: "Levon Esibov" To: Cc: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to recommend to replace the text fragment from Section 3 "By default, a principal MUST NOT be permitted to make any changes to zone data; any permissions MUST be enabled though configuration." by the following text "By default, a principal SHOULD NOT be permitted to make any changes to zone data; any permissions SHOULD be enabled through configuration." I believe the decision on the default configuration should be left to implementers. The deployment experience of Beta Windows 2000 demonstrated difficulties that administrators experienced in configuration of the zones for the dynamic updates. It was found that the default configuration that satisfied majority of customers is to allow all the authenticated principals to create new names in a zone, but prohibit any unauthorized principals from modifying the existing records. This is the default configuration of the Windows 2000 DNS server. I apologize that I didn't notice the issue during the workgroup last call. Levon From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Friday, June 02, 2000 5:34 AM To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard The IESG has received a request from the DNS Extensions Working Group to consider Simple Secure Domain Name System (DNS) Dynamic Update as a Proposed Standard. This will replace/obsolete RFC2137, currently a Proposed Standard. The IESG will also consider Domain Name System Security (DNSSEC) Signing Authority as a Proposed Standard, updating RFC2535 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the=20 iesg@ietf.org or ietf@ietf.org mailing lists by June 16, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-upda te-01.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-01.tx t 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 Wed Jun 14 12:01:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26201 for ; Wed, 14 Jun 2000 12:01:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132EsQ-000NI1-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:14:46 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132EsP-000NHr-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:14:46 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132Esf-0000b2-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:15:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006140812.KAA28976@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 14 Jun 2000 10:12:47 +0200 In-Reply-To: "Bill Manning's message as of Jun 14, 1:12" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Bill Manning , jaap@nic.nl (Jaap Akkerhuis) Subject: Re: Why I want to remove the null key SIG Cc: lewis@tislabs.com, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Bill Manning, on Jun 14, 1:12, in "Re: Why I want to re ..."] > % On what grounds do you come to this conclusion? Do you have any > % data to support this? > % jaap > > Ok, I'll admint some unlisted assumptions. > ) zones should be signed in a timely manner e.g. less than 4hours > ) COTS technologies today are represented by 1 or 2 G of memory, > subGhz processors. > ) large flat name spaces have around 1 million entries > > tests done in the US on some large zones (com.) and some tests done in > Europe (de.) indicate that with current COTS and these zones, the time > test fails. I'm not sure to which test for the .de you are referring, but they are in contrast with the only tests for European ccTLDs we have seen sofar. These were performed by NLnet Labs for a CENTR workgroup on DNSSEC and published on this list two months ago. The NLnet Labs tests showed, that using a $ 1000,- PC, the .nl and .se zones were signed in minutes, and the .de zone (currently the largest ccTLD with over 2 M delegations), was signed in some 4 hours. For detailed info about the .de signing test please see: http://open.nlnetlabs.nl/dnssec/de-signing.txt The conclusion of NLnet Labs was that there are no technical problems that prevent implementing DNSSEC in its current form for even the largest ccTLDs. The 4 hours needed to sign the .de zone can be easily reduced further, for instance by: - using more powerful hardware. - signing incrementally. -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 14 12:09:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26202 for ; Wed, 14 Jun 2000 12:01:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132EsK-000NHo-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:14:40 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132EsJ-000NHi-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:14:39 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132EsZ-0000b0-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:14:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Jun 2000 09:52:44 +0200 (CEST) From: Roy Arends To: Bill Manning cc: lewis@tislabs.com, namedroppers@ops.ietf.org Subject: Re: Redux: Why I want to remove the null key (SIG) In-Reply-To: <200006131530.IAA19304@boreas.isi.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 13 Jun 100, Bill Manning wrote: > % > % On Mon, 12 Jun 100, Bill Manning wrote: > % > % > % As the spec currently stands, a secured parent is not required to hold a > % > % key for a secured child, but is required to hold a NULL key (signed by the > % > % parent) for an unsecured child (that is not able to hold it's own NULL key). > % > % > % > > % > How does the parent learn that the child isnow secure > % > and is can drop the NULL key? > % > % The child asks the parent to remove the null-key, the parent can (should > % ?) verify the child's (null) KEY to make sure that the child has a valid > % (null) KEY. > > How does the child ask? There is no security involved here as the parent can check the validity of the request. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 14 12:09:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26218 for ; Wed, 14 Jun 2000 12:01:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132EfE-000N6l-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:01:08 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132EfD-000N6c-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:01:07 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132CvP-0000P8-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 07:09:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3946C366.4558B07@whistle.com> Date: Tue, 13 Jun 2000 16:27:34 -0700 From: Terry Lambert To: Levon Esibov CC: iesg@ietf.org, namedroppers@ops.ietf.org Subject: Re: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard References: <19398D273324D3118A2B0008C7E9A5690AD71B21@SIT.platinum.corp.microsoft.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Levon Esibov wrote: > > I'd like to recommend to replace the text fragment from > Section 3 "By default, a principal MUST NOT be permitted > to make any changes to zone data; any permissions MUST be > enabled though configuration." > > by the following text > > "By default, a principal SHOULD NOT be permitted to make > any changes to zone data; any permissions SHOULD be > enabled through configuration." > > I believe the decision on the default configuration should > be left to implementers. The deployment experience of Beta > Windows 2000 demonstrated difficulties that administrators > experienced in configuration of the zones for the dynamic > updates. It was found that the default configuration that > satisfied majority of customers is to allow all the > authenticated principals to create new names in a zone, > but prohibit any unauthorized principals from modifying > the existing records. This is the default configuration of > the Windows 2000 DNS server. > > I apologize that I didn't notice the issue during the > workgroup last call. If you make this change, shouldn't there be a corresponding change to the "Security Considerations" section to note that this permits an authenticated principal to stage a denial of service attack against other authenticated principals, by creating names in a zone that another principal was going to create? We currently use DNSUPDAT at our NOC (permitting changes to be made only by a locally running daemon over the loopback interface, with a private, cryptographically secure protocol between the client and the NOC) to create names for some transiently connected machines using dynamic IP address assignment. We were very careful to only expose a cryptographically secured channel, and to limit the protocol on that channel to prohibit updates except for zones _explicitly_ associated with the credential passed via the private protocol (we went so far as to prohibit all updates except for two names in a zone, in fact). What you are proposing seems to open a very bad security hole that we were very careful to avoid (going so far as to use a private protocol, given that DNSSEC is not really ready for deployment in a customer environment yet). I think this may be a case of giving a customer what they want, instead of what they need? -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 14 12:21:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26912 for ; Wed, 14 Jun 2000 12:21:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132FK0-000Niu-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:43:16 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132FJz-000Nin-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:43:15 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132FJy-0000cI-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:43:14 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20000614115200.14589.qmail@web513.mail.yahoo.com> Received: from [195.166.26.160] by web513.mail.yahoo.com; Wed, 14 Jun 2000 04:52:00 PDT Date: Wed, 14 Jun 2000 04:52:00 -0700 (PDT) From: =?iso-8859-1?q?Simon=20Coffey?= Subject: Fwd: ID on DNS TLD for private networks To: namedroppers@ops.ietf.org Cc: sandy.strain@integralis.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Its been suggested that I forward this message to namedroppers as well as posting to dnsops, regards Simon Coffey --- Simon Coffey wrote: > Date: Wed, 14 Jun 2000 02:19:34 -0700 (PDT) > From: Simon Coffey > Subject: ID on DNS TLD for private networks > To: dnsop@cafax.se > CC: sandy.strain@integralis.com > > > I'm co-author of an I-D proposing a new TLD for > private networks. > > ftp://ietf.org/internet-drafts/draft-coffeystrain-privatednstld-00.txt > > I'd be interested in comments on and suggestions > regarding the draft > > thanks > Simon Coffey > Theale Volunteer Networking Group __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 14 12:25:02 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27066 for ; Wed, 14 Jun 2000 12:25:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132FPD-000NpQ-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:48:39 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132FPC-000NpK-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:48:38 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132FPB-0000cf-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:48:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Jun 2000 14:31:17 +0200 (CEST) From: Roy Arends To: Bill Manning cc: lewis@tislabs.com, namedroppers@ops.ietf.org Subject: Re: Redux: Why I want to remove the null key (SIG) In-Reply-To: <200006141227.FAA18463@boreas.isi.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 14 Jun 100, Bill Manning wrote: > % > % > How does the parent learn that the child isnow secure > % > % > and is can drop the NULL key? > % > % > % > % The child asks the parent to remove the null-key, the parent can (should > % > % ?) verify the child's (null) KEY to make sure that the child has a valid > % > % (null) KEY. > % > > % > How does the child ask? > % > % There is no security involved here as the parent can check the validity of > % the request. > > What triggers the parent to check? The child's request ... to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 14 12:28:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27160 for ; Wed, 14 Jun 2000 12:28:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132FP1-000NpC-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:48:27 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132FP1-000Np4-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:48:27 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132FP0-0000cd-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:48:26 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006141227.FAA18463@boreas.isi.edu> Subject: Re: Redux: Why I want to remove the null key (SIG) To: roy@nlnetlabs.nl (Roy Arends) Date: Wed, 14 Jun 100 05:27:55 -0700 (PDT) Cc: bmanning@ISI.EDU, lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: from "Roy Arends" at Jun 14, 0 09:52:44 am Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % > % > How does the parent learn that the child isnow secure % > % > and is can drop the NULL key? % > % % > % The child asks the parent to remove the null-key, the parent can (should % > % ?) verify the child's (null) KEY to make sure that the child has a valid % > % (null) KEY. % > % > How does the child ask? % % There is no security involved here as the parent can check the validity of % the request. What triggers the parent to check? -- --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 Jun 14 12:31:14 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27335 for ; Wed, 14 Jun 2000 12:31:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132FQy-000Ns9-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:50:28 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132FQx-000Ns2-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:50:28 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132FQx-0000cp-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:50:27 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006141241.FAA19541@boreas.isi.edu> Subject: Re: Redux: Why I want to remove the null key (SIG) To: roy@nlnetlabs.nl (Roy Arends) Date: Wed, 14 Jun 100 05:41:34 -0700 (PDT) Cc: bmanning@ISI.EDU, lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: from "Roy Arends" at Jun 14, 0 02:31:17 pm Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit %>%>% The child asks the parent to remove the null-key, the parent can (should %>%>% ?) verify the child's (null) KEY to make sure that the child has a valid %>%>% (null) KEY. %>%> How does the child ask? %>% There is no security involved here as the parent can check the validity of %>% the request. %> What triggers the parent to check? % The child's request ... Again, How does the child ask the parent? via some DNS protocol feature? Registered postal mail? -- --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 Jun 14 12:31:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27364 for ; Wed, 14 Jun 2000 12:31:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132FX7-000O32-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:56:49 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132FX6-000O2w-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:56:49 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132FX6-0000dE-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:56:48 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Jun 2000 15:39:06 +0200 (CEST) From: Roy Arends To: namedroppers cc: Edward Lewis Subject: Re: Redux: Why I want to remove the null key (SIG) Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 9 Jun 2000, Edward Lewis wrote: > In the parent zone: > > child NS > child KEY null > SIG KEY ... > NXT > SIG NXT > > In the child zone: > > child SOA > SIG SOA > NS > SIG NS > KEY > SIG KEY (signed by Mars Certification Agency) > NXT > SIG NXT The child zone is more authoritive than parent when it comes to child-info. As this child has a KEY, which is validated off-tree, a secure entrypoint is defined here (as explained in our remarks on the draft-ietf-dnsext-zone-status-01.txt). The resolver of interest for this secure branch has the Mars Certification Agency KEY pre-configured and knows that this is a secure entrypoint. Therefore this secure resolver can positively validate the SIG(KEY) at the child. > This was legal under the policy in RFC 2535, section 6, but is not legal > given the updating draft. Which draft would this be ? draft-ietf-dnsext-simple-secure-update-01.txt, draft-ietf-dnsext-signing-auth-01.txt or draft-ietf-dnsext-zone-status-01.txt. > According to 2535, the credibility of the > child's KEY would force a "hiding" of the parent's NULL key, and > certification chains would be formed to the certifying authority. The > Signing Authority does not account for off-tree certification, not at > least until we understand it better. According to 2535 there MUST be a NULL key signed by the parent in this case. This is also needed to prevent denial of service for this child for security aware resolvers, that are not preconfigured with the Mars Certification Agency KEY and corresponding entry-points. Of course, for these resolvers, the child is seen as unsecured. IMHO this doesn't say anything about the NULL key being a bad idea. --roy & ted to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 14 12:39:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27494 for ; Wed, 14 Jun 2000 12:39:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132FRX-000Nsf-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 08:51:03 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132FRX-000NsS-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 08:51:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132FRW-0000cv-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:51:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Jun 2000 14:50:55 +0200 (CEST) From: Roy Arends To: Bill Manning cc: lewis@tislabs.com, namedroppers@ops.ietf.org Subject: Re: Redux: Why I want to remove the null key (SIG) In-Reply-To: <200006141241.FAA19541@boreas.isi.edu> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 14 Jun 100, Bill Manning wrote: > %>%>% The child asks the parent to remove the null-key, the parent can (should > %>%>% ?) verify the child's (null) KEY to make sure that the child has a valid > %>%>% (null) KEY. > %>%> How does the child ask? > %>% There is no security involved here as the parent can check the validity of > %>% the request. > %> What triggers the parent to check? > % The child's request ... > > Again, How does the child ask the parent? via some DNS protocol feature? > Registered postal mail? Anyway the child desires and parent accepts. Not particular via some DNS protocol feature. This can be done out of band. Registered postal mail will do. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 14 12:40:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27573 for ; Wed, 14 Jun 2000 12:40:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132FjU-000ONm-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 09:09:36 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132FjT-000ONf-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 09:09:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132FjS-0000dh-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 10:09:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: <200006141241.FAA19541@boreas.isi.edu> Date: Wed, 14 Jun 2000 10:57:03 -0400 To: Roy Arends From: Edward Lewis Subject: Re: Redux: Why I want to remove the null key (SIG) Cc: Bill Manning , lewis@tislabs.com, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've iidentified this as a remaining issue. Since I'm operationally-challenged (having no real network to run) I would like to hear other opinions. If you were to ask me my idea on this (or not ask) - some RPC-like / (I hate to say it) Web-CGI-Applet interface where upon a client does: http(s)://www.WeSignKeys4You.sec/keysigningform.pl The front end accepts keys and returns results. The back end records the action and sees to it that the result is reflected in the delegating zone. Now, I've left out a heck of a lot of details (e.g., trans. sec.) and options... PS - Yeah, my scenario above assumes a largely delegated zone, yadda, yadda. At 8:50 AM -0400 6/14/00, Roy Arends wrote: >On Wed, 14 Jun 100, Bill Manning wrote: >> Again, How does the child ask the parent? via some DNS protocol feature? >> Registered postal mail? > >Anyway the child desires and parent accepts. Not particular via some DNS >protocol feature. This can be done out of band. > >Registered postal mail will do. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 14 14:35:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01563 for ; Wed, 14 Jun 2000 14:35:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132HZg-0000uH-00 for namedroppers-data@psg.com; Wed, 14 Jun 2000 11:07:36 -0700 Received: from nanog19-8-55.nanog.ihighway.net ([64.46.8.55] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 132HZg-0000uA-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 11:07:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 132HZf-0000jN-00 for namedroppers@ops.ietf.org; Wed, 14 Jun 2000 12:07:35 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006141804.LAA24319@boreas.isi.edu> Subject: Re: Redux: Why I want to remove the null key (SIG) To: roy@nlnetlabs.nl (Roy Arends) Date: Wed, 14 Jun 100 11:04:34 -0700 (PDT) Cc: bmanning@ISI.EDU, lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: from "Roy Arends" at Jun 14, 0 02:50:55 pm Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks. That the notification method is not specified should be made clear. % % On Wed, 14 Jun 100, Bill Manning wrote: % % > %>%>% The child asks the parent to remove the null-key, the parent can (should % > %>%>% ?) verify the child's (null) KEY to make sure that the child has a valid % > %>%>% (null) KEY. % > %>%> How does the child ask? % > %>% There is no security involved here as the parent can check the validity of % > %>% the request. % > %> What triggers the parent to check? % > % The child's request ... % > % > Again, How does the child ask the parent? via some DNS protocol feature? % > Registered postal mail? % % Anyway the child desires and parent accepts. Not particular via some DNS % protocol feature. This can be done out of band. % % Registered postal mail will do. % % -- --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 Jun 15 10:36:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03320 for ; Thu, 15 Jun 2000 10:36:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132a6E-000GZu-00 for namedroppers-data@psg.com; Thu, 15 Jun 2000 06:54:26 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 132a6E-000GZo-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 06:54:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 132a6D-000CIM-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 06:54:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006151218.OAA38751@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Thu, 15 Jun 2000 14:18:00 +0200 In-Reply-To: "Bill Manning's message as of Jun 15, 14:06" Reply-To: Ted.Lindgreen@tednet.nl To: Bill Manning Subject: Re: Redux: Why I want to remove the null key (SIG) Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Bill Manning, on Jun 15, 14:06, in "Re: Redux: Why I wan ..."] > > Thanks. That the notification method is not specified should be made clear. A list of what actions are needed to implement security might clarify things. Let's work out the KEY signing issues at a delegation point. We define the following possibilities: 1. Parent and child both unsecured. 2A. Parent is secured, child still unsecured. 2B. Child is secured, parent still unsecured. 3A. Parent and child both secured, parent signs childs key. 3B. Parent and child both secured, child is specially signed. Note: this scheme can be applied everywhere in the DNS-tree, by noting that at the root the child is the root and the parent does not exist and only 1 and 2B are defined. Going from 1 ==> 2A: - This is a parent-only action: The parent MUST sign a null-KEY for the child. Typically the parent will start holding this KEY in its zone file. Going from 1 ==> 2B: - This is a child-only action: We have a "secured entry point" in the DNS tree here. The child must have its KEY signed in some special way, and has to take care that the resolvers of interest are pre- configured with the secured entry point and a KEY to verify the zone KEY. Going from 2A => 3A: - Child action: When the null-KEY is still in the parent-zone file, the child must copy it into its own zone file and ask the parent to remove it from his zone file. - Parent action: Remove null-KEY. - Child action: The child must generate a real zone KEY and ask its parent to sign it. - Parent action: Verify request and sign the childs zone-KEY. - Child action: Replace the old unsecured zone file with null-KEY by the signed zone file and become secured. Going from 2A => 3B: - Child only action: identical to "1 ==> 2B". - Note that the parent signed null-KEY remains in place. Going from 2B => 3B: - Parent-only action, identical to "1 ==> 2A" Going from 2B => 3A: - Parent action, identical to "1 ==> 2A" - Child action: Copy its parent signed null-KEY from parent zone-file into own zone file. Ask parent to sign its zone-signing KEY. - Parent action: Remove null-KEY from zone-file. Verify request and sign the childs zone-KEY. - Child action: Replace the special SIG by the parents SIG and remove the parent signed null-KEY. There are a number of vulnerabilities, the obvious ones are going towards 3A: 1. As long as the parents SIG over the old null-KEY is valid, the child zone can be zone-jacked. Therefore, null-KEY SIGs should not have long expiration times. 2. The verification by the parent that a KEY, presented by a child is indeed sent by someone authorative for this child is essential, but far from trivial. Note that the functionality of the null-KEY is essential and can not be removed. Regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 15 16:22:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13887 for ; Thu, 15 Jun 2000 16:22:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132fTD-000KMW-00 for namedroppers-data@psg.com; Thu, 15 Jun 2000 12:38:31 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 132fTD-000KMQ-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 12:38:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 132fTC-000EV5-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 12:38:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <002701bfd637$d63b0240$0401a8c0@comcastwork.com> From: "Al Costanzo" To: Subject: draft-ietf-dnsext-iana-dns-00.txt (LAST CALL) Date: Wed, 14 Jun 2000 15:36:21 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear ALL, Concerning the document: draft-ietf-dnsext-iana-dns-00.txt (LAST CALL) I am opposed to this document being moved forward because of certain language contained within it. The phrase: 'assignment by IETF Consensus' seems to prohibit IANA from issuing DNS Resource Record assignments for anything other than a standards track RFCs. There are a number of RR that are currently defined in Experimental RFCs and I would NOT think that any document should restrict IANA from issuing assignments in this fashion for Experimetal RFCs. If this is what the implication is, in my opinion is downright wrong and the verbage needs to be changed to allow this... -Al Costanzo > % > % Hello, > % > % Regarding your draft: draft-ietf-dnsext-iana-dns-00.txt > % > % Could you please define your statement: > % > % 'assignment by IETF Consensus' > > As I understand this, IETF consensus is where an RFC is issued > from a working group or an individual submission is reviewed > and approved by the IESG. > > % Are you trying to state in this draft that future RR can NOT be issued by > % IANA for Experimental RFCs? > > That is my understanding of the words. (not that I agree with them > though) > > % > % If so I see no justification for this... > % > % -al > % > % > > > -- > --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 Jun 15 17:11:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14663 for ; Thu, 15 Jun 2000 17:11:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132gR5-000LCU-00 for namedroppers-data@psg.com; Thu, 15 Jun 2000 13:40:23 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 132gR5-000LCN-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 13:40:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 132gR5-000EqO-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 13:40:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006152001.QAA09587@torque.pothole.com> To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-iana-dns-00.txt (LASTCALL?) Date: Thu, 15 Jun 2000 16:01:53 -0400 From: "Donald E. Eastlake 3rd" X-Mts: smtp Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Al, From: "Al Costanzo" Message-ID: <000d01bfd634$b67927a0$0401a8c0@comcastwork.com> Reply-To: "Al Costanzo" To: "Bill Manning" , Cc: , , References: <200006160038.RAA05066@zed.isi.edu> Date: Wed, 14 Jun 2000 15:14:05 -0400 >Dear ALL, > >Concerning the document: draft-ietf-dnsext-iana-dns-00.txt (LAST CALL) > >I am opposed to this document being moved forward because of certain >language contained within it. > >The phrase: 'assignment by IETF Consensus' seems to prohibit IANA from >issuing DNS Resource Record assignments for anything other than a standards >track RFCs. There are a number of RR that are currently defined in >Experimental RFCs and I would NOT think that any document should restrict >IANA from issuing assignments in this fashion for Experimetal RFCs. (1) There is no such thing as an "Experimental RFC". There are Experimental Protocols. An RFC may document a protocol which can be, at some particular time, an Experimental Protocol. (2) The Phrase "IETF Consensus", like all of the other terms of art for IANA Considerations in this draft, is defined in RFC 2434 as follows: IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Note that this does NOT restrict to Standards Track. In any case, under this draft this applies ONLY to a certain range of RR number, in particular 1-32767. However, other values are assigned by IANA based on other criterion. In particular, RR numbers in the range of 32768 - 65279 are assigned based on "Specification Required" as specified in RFC 2434: Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. Thus, of course, IANA is quite free to assign RR numbers in connection with an Experimental Protocol documented in an RFC without any requirement to get the approval of or go through a WG or the IESG. >If this is what the implication is, in my opinion is downright wrong and the >verbage needs to be changed to allow this... I don't see that we are talking about any vague "implication" in the draft. It is quite clear that certain RR values can be allocated by IANA if IANA is satisfied that the Specification Required criterion is met. If it will give people a warm fuzzy feeling for a sentence like "Thus IANA can allocate RR numbers in this range for documented Experimental Protocols." I'm willing to do that, although I don't see the need to add such verbiage. >-Al Costanzo Donald =================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 140 Forest Avenue lde008@dma.isg.mot.com Hudson, MA 01749 USA +1 978-562-2827(h) +1 508-261-5434(w) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 15 17:27:25 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14845 for ; Thu, 15 Jun 2000 17:27:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132gem-000LPz-00 for namedroppers-data@psg.com; Thu, 15 Jun 2000 13:54:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 132gel-000LPt-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 13:54:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 132gel-000Ew5-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 13:54:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006152028.PAA06815@gungnir.fnal.gov> To: Al Costanzo Cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: draft-ietf-dnsext-iana-dns-00.txt (LAST CALL) In-reply-to: Your message of Wed, 14 Jun 2000 15:36:21 EDT. <002701bfd637$d63b0240$0401a8c0@comcastwork.com> Date: Thu, 15 Jun 2000 15:28:54 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The phrase: 'assignment by IETF Consensus' seems to prohibit IANA from > issuing DNS Resource Record assignments for anything other than a standards > track RFCs. There are a number of RR that are currently defined in > Experimental RFCs and I would NOT think that any document should restrict > IANA from issuing assignments in this fashion for Experimetal RFCs. You need to (re?)read RFC 2434, "Guidelines for Writing an IANA Considerations Section in RFCs". to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 15 17:40:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15158 for ; Thu, 15 Jun 2000 17:40:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132gqC-000Lcm-00 for namedroppers-data@psg.com; Thu, 15 Jun 2000 14:06:20 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 132gqC-000Lcg-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 14:06:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 132gqB-000F16-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 14:06:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006160406.VAA05420@zed.isi.edu> Subject: Re: draft-ietf-dnsext-iana-dns-00.txt (LASTCALL?) To: dee3@torque.pothole.com (Donald E. Eastlake 3rd) Date: Thu, 15 Jun 2000 21:06:28 -0700 (PDT) Cc: namedroppers@ops.ietf.org In-Reply-To: <200006152001.QAA09587@torque.pothole.com> from "Donald E. Eastlake 3rd" at Jun 15, 2000 04:01:53 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % >The phrase: 'assignment by IETF Consensus' seems to prohibit IANA from % >issuing DNS Resource Record assignments for anything other than a standards % >track RFCs. There are a number of RR that are currently defined in % >Experimental RFCs and I would NOT think that any document should restrict % >IANA from issuing assignments in this fashion for Experimetal RFCs. % % (1) There is no such thing as an "Experimental RFC". There are Experimental % Protocols. An RFC may document a protocol which can be, at some particular % time, an Experimental Protocol. % Donald, I beleive that while you may technically be correct that there are no "Experimental RFCs" there are RFCs that are in experimental status. (e.g. RFC 2844) To acheive this status, it is not nessasary to reach "IETF consensus" as elswhere documented. This does place an interesting burden on those using the process of experimentation and implementation to advance the state of the art in that they may not get an IANA approved codepoint until some time after the code is in use. Given the existing process and its associated latencies in getting an RFC through the IETF and the IESG, I am becoming convinced that we are encouraging anarchy by delaying the registration and documentation of new features and code points. --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 Jun 15 17:42:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15223 for ; Thu, 15 Jun 2000 17:42:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132gpq-000LcX-00 for namedroppers-data@psg.com; Thu, 15 Jun 2000 14:05:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 132gpp-000LcQ-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 14:05:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 132gpp-000F0p-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 14:05:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard Date: Thu, 15 Jun 2000 13:41:23 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690731B825@SIT.platinum.corp.microsoft.com> From: "Levon Esibov" To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Levon Esibov wrote: > >=20 > > I'd like to recommend to replace the text fragment from > > Section 3 "By default, a principal MUST NOT be permitted > > to make any changes to zone data; any permissions MUST be > > enabled though configuration." > >=20 > > by the following text > >=20 > > "By default, a principal SHOULD NOT be permitted to make > > any changes to zone data; any permissions SHOULD be > > enabled through configuration." > >=20 > > I believe the decision on the default configuration should > > be left to implementers. The deployment experience of Beta > > Windows 2000 demonstrated difficulties that administrators > > experienced in configuration of the zones for the dynamic > > updates. It was found that the default configuration that > > satisfied majority of customers is to allow all the > > authenticated principals to create new names in a zone, > > but prohibit any unauthorized principals from modifying > > the existing records. This is the default configuration of > > the Windows 2000 DNS server. > >=20 > > I apologize that I didn't notice the issue during the > > workgroup last call. >=20 > If you make this change, shouldn't there be a corresponding > change to the "Security Considerations" section to note that > this permits an authenticated principal to stage a denial of > service attack against other authenticated principals, by > creating names in a zone that another principal was going > to create? > What you are proposing seems to open a very bad security > hole that we were very careful to avoid (going so far as > to use a private protocol, given that DNSSEC is not really > ready for deployment in a customer environment yet). 1. I agree that this permits an authenticated principal to stage a denial of service attack against other authenticated principals, by creating names in a zone that another principal was going to create. That's why I am not claiming that such default configuration should be recommended/required by this RFC. I'd like to emphasize that all I am recommending is that the RFC doesn't require what the default configuration MUST be, but makes a recommendation on what the default configuration SHOULD be. i.e. "By default, a principal SHOULD NOT be permitted to make any changes to zone data; any permissions SHOULD be enabled through configuration." Implementers should be able to make there own decision on the default configuration depending on the environment where their DNS servers are used. For example, in the corporate environment a principal that generated the denial of service attack (that you described above) will be easily identified and fired. Thus our default configuration may be not only what the customer want, but also what the customer needs. 2. I don't think that the proposed modification (replacement of MUST by SHOULD) requires any modifications of the "Security Considerations". It is so because if the "Security Considerations" section doesn't need to describe the potential security issues when admin changes configuration, then there is no need to describe the potential security issues when DNS server implementer decides to change the default configuration. But I don't have strong objections against adding clarification sentence/paragraph to the "Security Considerations". If majority on the namedroppers believes that we should update the "Security Considerations", I'd be glad to volunteer to do it. Thanks, Levon. Levon Esibov Program Manager Microsoft 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 Thu Jun 15 19:03:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17228 for ; Thu, 15 Jun 2000 19:03:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132iBc-000N8t-00 for namedroppers-data@psg.com; Thu, 15 Jun 2000 15:32:32 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 132iBb-000N8n-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 15:32:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 132iBb-000FZm-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 15:32:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 15 Jun 2000 15:30:00 -0700 (PDT) From: Brian Wellington To: Levon Esibov Cc: iesg@ietf.org, namedroppers@ops.ietf.org Subject: RE: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard In-Reply-To: <19398D273324D3118A2B0008C7E9A5690AD71B21@SIT.platinum.corp.microsoft.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit On Tue, 13 Jun 2000, Levon Esibov wrote: > I'd like to recommend to replace the text fragment from Section 3 > "By default, a principal MUST NOT be permitted to make any changes to > zone > data; any permissions MUST be enabled though configuration." > > by the following text > > "By default, a principal SHOULD NOT be permitted to make any changes > to zone data; any permissions SHOULD be enabled through > configuration." > > I believe the decision on the default configuration should be left to > implementers. The deployment experience of Beta Windows 2000 > demonstrated difficulties that administrators experienced in > configuration of the zones for the dynamic updates. It was found that > the default configuration that satisfied majority of customers is to > allow all the authenticated principals to create new names in a zone, > but prohibit any unauthorized principals from modifying the existing > records. This is the default configuration of the Windows 2000 DNS > server. What do you mean by an authenticated principal? It sounds like what you mean is that anyone who has authenticated with the server should be allowed free range over dynamic updates. This is an exceedingly bad idea. If what you mean is that a certain type of authentication token can be granted which allows free range over dynamic updates, this is a lot better. The granting of this token can be considered a form of configuration, since there must be something deciding whether or not to grant the token. Of course, if this was on by default, it would also be a bad idea. Changing the draft to allow an open policy by default (even if it is a SHOULD NOT) doesn't sound like a good idea, since then people might actually implement it that way. If I'm misinterpreting what you're proposing, feel free to correct me :) Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 15 19:50:37 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18056 for ; Thu, 15 Jun 2000 19:50:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132iuw-000Nrg-00 for namedroppers-data@psg.com; Thu, 15 Jun 2000 16:19:22 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 132iuv-000Nra-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 16:19:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 132iuv-000Fqi-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 16:19:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200006152314.IAA27905@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA27905; Fri, 16 Jun 2000 08:13:45 +0859 Subject: Re: draft-ietf-dnsext-iana-dns-00.txt (LASTCALL?) In-Reply-To: <200006160406.VAA05420@zed.isi.edu> from Bill Manning at "Jun 15, 2000 09:06:28 pm" To: Bill Manning Date: Fri, 16 Jun 2000 08:13:45 +0859 () CC: "Donald E. Eastlake 3rd" , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill; > consensus" as elswhere documented. This does place an interesting burden on > those using the process of experimentation and implementation to advance the > state of the art in that they may not get an IANA approved codepoint until > some time after the code is in use. Given the existing process and its > associated latencies in getting an RFC through the IETF and the IESG, I > am becoming convinced that we are encouraging anarchy by delaying the > registration and documentation of new features and code points. Yes, I wrote in last September. : IANA Registration and the End to End Principle : To promote better interoperability, IANA is the place, recognized by : those who developed the protocols, to register interpretations of : various values of the protocol fields. : : IANA assigns unique values and make lists of the assigned values and : their meaning with references to more detailed information. : : However, IANA registration does not mean that IANA provides collision : management nor automatic identification of the registered values. The : registration, either, does not assure the interoperability of the : protocols. : IANA assignment of values, neither, overrides any intellectual : property rights such as trademark or copyright. : : The Internet works based on the end to end principle [ARCH] that, : parties, that is, end systems or hosts, of a communication are : required to have an interpretation of values common only to them. : The interpretation may be different from that registered to IANA. : : As such, when many or most hosts in the Internet share an : interpretation of protocol values, some protocol fields have defact : interpretations different from IANA registered ones. : : Because of the end to end principle, there, principally, can be no : mechanism to enforce IANA registrations. That is, Almost all the registration restrictions are silly, only to make IANA ignored by the Internet. However, please don't apply the argument to domain names, as I also wrote: : It should be noted that the argument above is not applicable to : values to identify end systems, namely, IP addresses and domain : names. IP addresses are essential to routers while domain names offer : a lot more human friendly identification. It was draft-ohta-iana-registration-00.txt. > some time after the code is in use. Given the existing process and its > associated latencies in getting an RFC through the IETF and the IESG, I No, I did not bother to try to make it an RFC. :-) 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 Thu Jun 15 20:11:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18374 for ; Thu, 15 Jun 2000 20:11:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 132j9e-000O75-00 for namedroppers-data@psg.com; Thu, 15 Jun 2000 16:34:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 132j9d-000O6z-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 16:34:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 132j9d-000FvR-00 for namedroppers@ops.ietf.org; Thu, 15 Jun 2000 16:34:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006152335.TAA10191@torque.pothole.com> To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-iana-dns-00.txt (LASTCALL?) In-reply-to: Your message of "Thu, 15 Jun 2000 21:06:28 PDT." <200006160406.VAA05420@zed.isi.edu> Date: Thu, 15 Jun 2000 19:35:39 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bill, From: Bill Manning Message-Id: <200006160406.VAA05420@zed.isi.edu> To: dee3@torque.pothole.com (Donald E. Eastlake 3rd) Date: Thu, 15 Jun 2000 21:06:28 -0700 (PDT) Cc: namedroppers@ops.ietf.org In-Reply-To: <200006152001.QAA09587@torque.pothole.com> from "Donald E. Eastlake 3rd " at Jun 15, 2000 04:01:53 PM >% >The phrase: 'assignment by IETF Consensus' seems to prohibit IANA from >% >issuing DNS Resource Record assignments for anything other than a standards >% >track RFCs. There are a number of RR that are currently defined in >% >Experimental RFCs and I would NOT think that any document should restrict >% >IANA from issuing assignments in this fashion for Experimetal RFCs. >% >% (1) There is no such thing as an "Experimental RFC". There are Experimental >% Protocols. An RFC may document a protocol which can be, at some particular >% time, an Experimental Protocol. You seem to have edited down the previous message so as to produce a misleading impression. >Donald, > > I beleive that while you may technically be correct that there are >no "Experimental RFCs" there are RFCs that are in experimental status. I would point out that one AD criticism which lead to my editing of the tkey and sig(0) drafts was that the phrase "Experimental RFC" be reworded. >(e.g. RFC 2844) To acheive this status, it is not nessasary to reach "IETF >consensus" as elswhere documented. This does place an interesting burden on Of course not. It requires only approval by the RFC Editor for an Experimental Protocol, although the IESG can approve them also. But so what? "IETF Consensus" is NOT NECESSARY to get an RR value assigned according to this draft. >those using the process of experimentation and implementation to advance the >state of the art in that they may not get an IANA approved codepoint until >some time after the code is in use. Given the existing process and its If you are saying that anyone needs either IESG or WG or RFC editor approval to get a codepoint allocated, you are wrong. Read the text I quoted from RFC 2434 which you unfortunately edited out of my message. The do NOT have to have ANY code written, they do NOT have to have any code deployed, they do NOT have to have any code in use. The need only provide a specification as described in RFC 2434. They CAN do so by an RFC by the are NOT REQURIED to do so by an RFC. >associated latencies in getting an RFC through the IETF and the IESG, I >am becoming convinced that we are encouraging anarchy by delaying the >registration and documentation of new features and code points. Since this draft does not require an RFC, I'm sure you will be relieved to know that your fears are groundless. >--bill Donald =================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 140 Forest Avenue lde008@dma.isg.mot.com Hudson, MA 01749 USA +1 978-562-2827(h) +1 508-261-5434(w) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 16 18:18:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26494 for ; Fri, 16 Jun 2000 18:18:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 1333jE-000BJL-00 for namedroppers-data@psg.com; Fri, 16 Jun 2000 14:32:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 1333jE-000BJF-00 for namedroppers@ops.ietf.org; Fri, 16 Jun 2000 14:32:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 1333jE-000MoR-00 for namedroppers@ops.ietf.org; Fri, 16 Jun 2000 14:32:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006162128.RAA25094@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: Secret Key Establishment for DNS (TKEY RR) to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 16 Jun 2000 17:28:15 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has received a request from the DNS Extensions Working Group to consider pyblication of the following Internet-Drafts as Proposed Standards: o Secret Key Establishment for DNS (TKEY RR) o DNS Request and Transaction Signatures ( SIG(0)s ) The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 30, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-03.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-sig-zero-02.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jun 18 09:28:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07688 for ; Sun, 18 Jun 2000 09:28:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 133eI8-00052P-00 for namedroppers-data@psg.com; Sun, 18 Jun 2000 05:35:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 133eI8-00052G-00 for namedroppers@ops.ietf.org; Sun, 18 Jun 2000 05:35:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 133eI7-0004CH-00 for namedroppers@ops.ietf.org; Sun, 18 Jun 2000 05:35:07 -0700 Message-Id: In-Reply-To: References: <19398D273324D3118A2B0008C7E9A5690AD71B21@SIT.platinum.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 18 Jun 2000 07:58:51 -0400 To: Brian Wellington From: Edward Lewis Subject: RE: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard Cc: Levon Esibov , iesg@ietf.org, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 6:30 PM -0400 6/15/00, Brian Wellington wrote: >Changing the draft to allow an open policy by default (even if it is a >SHOULD NOT) doesn't sound like a good idea, since then people might >actually implement it that way. > >If I'm misinterpreting what you're proposing, feel free to correct me :) I think that the wording should (must ;)) remain the same. One on hand, when dealing with issues that are purely security-related (as opposed to protocol liveness, functionality, etc.) a tighter definition is better than a looser definition. (Note - I don't advocate making the definition too tight just to be secure.) OTOH, I think Brian is misinterpreting a bit. Dropping the MUST doesn't imply that the opposite will be preferred. Dropping MUST to SHOULD doesn't mean that the default would be to use an open policy. Levon is only arguing that implementers should be given a choice. Albeit a choice I don't think that implementers need to have... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jun 18 15:15:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09573 for ; Sun, 18 Jun 2000 15:15:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 133jqa-000AdA-00 for namedroppers-data@psg.com; Sun, 18 Jun 2000 11:31:04 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 133jqZ-000Ad2-00 for namedroppers@ops.ietf.org; Sun, 18 Jun 2000 11:31:03 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 133jqZ-0007NC-00 for namedroppers@ops.ietf.org; Sun, 18 Jun 2000 11:31:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000618182803.02df1cd8@dokka.kvatro.no> Date: Sun, 18 Jun 2000 18:35:02 +0200 To: "Levon Esibov" , From: Harald Tveit Alvestrand Subject: RE: Last Call: Simple Secure Domain Name System (DNS) Dynamic Update to Proposed Standard In-Reply-To: <19398D273324D3118A2B0008C7E9A5690731B825@SIT.platinum.corp .microsoft.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 13:41 15.06.2000 -0700, Levon Esibov wrote: >1. I agree that this permits an authenticated principal to stage a >denial of service attack against other authenticated principals, by >creating names in a zone that another principal was going to create. >That's why I am not claiming that such default configuration should be >recommended/required by this RFC. I'd like to emphasize that all I am >recommending is that the RFC doesn't require what the default >configuration MUST be, but makes a recommendation on what the default >configuration SHOULD be. >i.e. "By default, a principal SHOULD NOT be permitted to make any >changes to zone data; any permissions SHOULD be enabled through >configuration." two possible readings of your text: 1) you recommend that principals authenticated in the msn.com domain should be able to insert records in the exchange.microsoft.com zone. This doesn't seem likely. 2) there is a missing piece that says that an unconfigured DNS server is able to find out which zone it has as its primary authentication domain, and verify authentications for other prinicipals in that zone, all without configuration, and that you think this should be allowed by the RFC. If you will grant that installing a DNS server in a Win2000 authentication domain involves "configuration" telling it which domain that is, I think you are conformant to the letter of the RFC as currently written. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 19 23:41:42 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00196 for ; Mon, 19 Jun 2000 23:41:41 -0400 (EDT) From: owner-namedroppers@ops.ietf.org Received: from lserv by psg.com with local (Exim 3.13 #1) id 134EG4-000JKa-00 for namedroppers-data@psg.com; Mon, 19 Jun 2000 19:59:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 134EG4-000JKU-00 for namedroppers@ops.ietf.org; Mon, 19 Jun 2000 19:59:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 134EG3-000I6p-00 for namedroppers@ops.ietf.org; Mon, 19 Jun 2000 19:59:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Dynamic update of A6 records Date: Mon, 19 Jun 2000 15:42:13 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690731B833@SIT.platinum.corp.microsoft.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk To: namedroppers-data@psg.com Content-Transfer-Encoding: 7bit X-Had-Toms-of Useless-Headers-MIME-and-Crap: From: "Levon Esibov" To: Cc: , , I didn't find in the Internet draft "DNS extensions to Support IPv6 Address Aggregation and Renumbering" any discussion on how dynamic update of the A6 records is supposed to work. Namely, is a computer with IPv6 address expected to use dynamic DNS update protocol to register its A6 record with non-zero Prefix Length? If yes, then how computers should discover Prefix Name? 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 Wed Jun 21 21:53:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17281 for ; Wed, 21 Jun 2000 21:53:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 134vWG-000Bqs-00 for namedroppers-data@psg.com; Wed, 21 Jun 2000 18:11:00 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 134vWE-000Bqd-00 for namedroppers@ops.ietf.org; Wed, 21 Jun 2000 18:10:59 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 134vWC-0000kt-00 for namedroppers@ops.ietf.org; Thu, 22 Jun 2000 02:10:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000621162543.00c6b100@localhost> Date: Wed, 21 Jun 2000 16:43:28 -0400 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Implementation reports REQUEST Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As a working group chair I need to create reports of implementations of the RFC's we are trying to advance, below is a draft form for implementors to fill out and send me (or the mailing list). Please send in any comments on this form to me before Monday 26'th. The RFC's I will be looking for reports on are 1611, 1612, 1892, 1995, 1996, 2136, 2181, 2308, 2535, 2536, 2537, 2538, 2539, 2671, 2672, 2782, 2845. thanks Olafur ---------------- RFC implemented: Implementation name and version: Organization: Reporter: (full name and email address): Compliance (Full/partial): If partial compliance explain why?: Implementation difficulty (hard: Overall comments on the RFC: Specific comments on sections in the specification: Have you conducted interoperabilty testing with other implementations: List the implementations: Do you have any tests that you are willing to donate for interoperabilty testing ? Do you recommend this RFC be advanced or retired ?: to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jun 21 22:07:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17471 for ; Wed, 21 Jun 2000 22:07:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 134vni-000C0F-00 for namedroppers-data@psg.com; Wed, 21 Jun 2000 18:29:02 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 134vnh-000C09-00 for namedroppers@ops.ietf.org; Wed, 21 Jun 2000 18:29:02 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 134vnf-0000lt-00 for namedroppers@ops.ietf.org; Thu, 22 Jun 2000 02:28:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Eric A. Hall" cc: namedroppers Subject: Re: should retry have unique ID In-Reply-To: Message from Mark.Andrews@nominum.com dated "Mon, 12 Jun 2000 10:34:51 EDT" <200006121256.WAA27484@bsdi.dv.isc.org> References: <200006121256.WAA27484@bsdi.dv.isc.org> From: Rob Austein Message-Id: <20000621223459Z46218-260+17@pak.hactrn.net> Date: Wed, 21 Jun 2000 18:35:02 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Too much time on the road lately, hence the delayed response.] The one observation I'd add to Mark's comments is that unique IDs can be useful if one is attempting to do careful measurement of round trip times, eg if one is implementing a TCP-like retransmission algorithm. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 23 11:25:53 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12788 for ; Fri, 23 Jun 2000 11:25:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 135UXT-0006LG-00 for namedroppers-data@psg.com; Fri, 23 Jun 2000 07:34:35 -0700 Received: from [212.158.2.190] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 135UXR-0006LA-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 07:34:34 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 135UXV-0000ZH-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 15:34:37 +0100 Message-Id: <200006231045.GAA06228@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-apl-rr-01.txt Date: Fri, 23 Jun 2000 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 : A DNS RR Type for Lists of Address Prefixes (APL RR) Author(s) : P. Koch Filename : draft-ietf-dnsext-apl-rr-01.txt Pages : 7 Date : 22-Jun-00 The Domain Name System is primarily used to translate domain names into IPv4 addresses using A RRs. Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type 'APL' for address prefix lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-apl-rr-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-apl-rr-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-apl-rr-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: <20000622112150.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-apl-rr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-apl-rr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000622112150.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 23 11:54:21 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13551 for ; Fri, 23 Jun 2000 11:54:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 135VGg-0006sX-00 for namedroppers-data@psg.com; Fri, 23 Jun 2000 08:21:18 -0700 Received: from [212.158.2.190] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 135VGe-0006sI-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 08:21:17 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 135VGb-0000cb-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 16:21:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19398D273324D3118A2B0008C7E9A5690AD71C1E@SIT.platinum.corp.microsoft.com> From: Levon Esibov To: "'namedroppers@ops.ietf.org'" Subject: Dynamic update of A6 records Date: Fri, 23 Jun 2000 08:08:29 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I didn't find in the Internet draft "DNS extensions to Support IPv6 Address Aggregation and Renumbering" any discussion on how dynamic update of the A6 records is supposed to work. Namely, is a computer with IPv6 address expected to use dynamic DNS update protocol to register its A6 record with non-zero Prefix Length? If yes, then how computers should discover Prefix Name? 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 Fri Jun 23 14:00:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16353 for ; Fri, 23 Jun 2000 14:00:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 135XDf-0008GI-00 for namedroppers-data@psg.com; Fri, 23 Jun 2000 10:26:19 -0700 Received: from [212.158.2.190] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 135XDd-0008GC-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 10:26:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 135XDc-0000jf-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 18:26:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200006141241.FAA19541@boreas.isi.edu> References: from "Roy Arends" at Jun 14, 0 02:31:17 pm Date: Fri, 23 Jun 2000 11:03:31 -0400 To: Bill Manning From: Edward Lewis Subject: Re: Redux: Why I want to remove the null key (SIG) Cc: roy@nlnetlabs.nl (Roy Arends), lewis@tislabs.com, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 8:41 AM -0400 6/14/00, a bunch of folks wrote: >%>%>% The child asks the parent to remove the null-key, the parent can (should >%>%>% ?) verify the child's (null) KEY to make sure that the child has a valid >%>%>% (null) KEY. >%>%> How does the child ask? >%>% There is no security involved here as the parent can check the validity of >%>% the request. >%> What triggers the parent to check? >% The child's request ... > >Again, How does the child ask the parent? via some DNS protocol feature? >Registered postal mail? With regards to getting a child key signed, recognized, and reflected in the parent zone - is the onus on the child or parent to make sure things are correct? Would this answer change if we are talking .de or .com vs. netsec.tislabs.com (i.e., a lower in the tree "small" delegation)? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 23 14:00:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16355 for ; Fri, 23 Jun 2000 14:00:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 135XDK-0008Fi-00 for namedroppers-data@psg.com; Fri, 23 Jun 2000 10:25:58 -0700 Received: from [212.158.2.190] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 135XDJ-0008Fc-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 10:25:58 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 135XDI-0000jZ-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 18:25:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200006151218.OAA38751@open.nlnetlabs.nl> References: "Bill Manning's message as of Jun 15, 14:06" Date: Fri, 23 Jun 2000 11:07:00 -0400 To: Ted.Lindgreen@tednet.nl From: Edward Lewis Subject: Re: Redux: Why I want to remove the null key (SIG) Cc: Bill Manning , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 8:18 AM -0400 6/15/00, Ted Lindgreen wrote: >1. As long as the parents SIG over the old null-KEY is valid, > the child zone can be zone-jacked. > Therefore, null-KEY SIGs should not have long expiration > times. This would be counter to the efforts of the owner of a largely delegation zone. How or where should this recommendation/requirement be specificed/enforced? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 23 14:03:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16447 for ; Fri, 23 Jun 2000 14:03:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 135XDW-0008G9-00 for namedroppers-data@psg.com; Fri, 23 Jun 2000 10:26:10 -0700 Received: from [212.158.2.190] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 135XDU-0008Fm-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 10:26:09 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 135XDQ-0000jb-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 18:26:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: Date: Fri, 23 Jun 2000 12:44:52 -0400 To: Roy Arends From: Edward Lewis Subject: Re: Redux: Why I want to remove the null key (SIG) Cc: namedroppers , Edward Lewis Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 9:39 AM -0400 6/14/00, Roy Arends wrote: >As this child has a KEY, which is validated off-tree, a secure entrypoint >is defined here (as explained in our remarks on the >draft-ietf-dnsext-zone-status-01.txt). The resolver of interest for this >secure branch has the Mars Certification Agency KEY pre-configured and >knows that this is a secure entrypoint. Therefore this secure resolver >can positively validate the SIG(KEY) at the child. This assumes that all of the resolvers-of-interest are so configured. The problem is that for all other resolvers, this is a misconfiguration. >> This was legal under the policy in RFC 2535, section 6, but is not legal >> given the updating draft. > >Which draft would this be ? > draft-ietf-dnsext-simple-secure-update-01.txt, > draft-ietf-dnsext-signing-auth-01.txt or > draft-ietf-dnsext-zone-status-01.txt. #2 - signing-auth >According to 2535 there MUST be a NULL key signed by the parent in this >case. This is also needed to prevent denial of service for this >child for security aware resolvers, that are not preconfigured with >the Mars Certification Agency KEY and corresponding entry-points. >Of course, for these resolvers, the child is seen as unsecured. > >IMHO this doesn't say anything about the NULL key being a bad idea. The "bad idea" is that although the parent has properly issued a NULL key, the NULL key is not available (hidden). OTOH, if the indication were in the NXT record (current proposal is using the OPT record bit - we'll argue that later), then the parent can still signal that it thinks the child is unsecured. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 24 00:51:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27837 for ; Sat, 24 Jun 2000 00:51:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 135hON-000EzL-00 for namedroppers-data@psg.com; Fri, 23 Jun 2000 21:18:03 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 135hOL-000EzF-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 21:18:03 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 135hOO-0000tg-00 for namedroppers@ops.ietf.org; Sat, 24 Jun 2000 05:18:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006240456.VAA23340@zed.isi.edu> Subject: Re: Redux: Why I want to remove the null key (SIG) To: lewis@tislabs.com (Edward Lewis) Date: Fri, 23 Jun 2000 21:56:14 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), roy@nlnetlabs.nl (Roy Arends), lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: from "Edward Lewis" at Jun 23, 2000 11:03:31 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % >Again, How does the child ask the parent? via some DNS protocol feature? % >Registered postal mail? % % With regards to getting a child key signed, recognized, and reflected in % the parent zone - is the onus on the child or parent to make sure things % are correct? % % Would this answer change if we are talking .de or .com vs. % netsec.tislabs.com (i.e., a lower in the tree "small" delegation)? % % -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- % Edward Lewis NAI Labs % Phone: +1 443-259-2352 Email: lewis@tislabs.com % See recent post on presumptions on zone state change wrt its being "secure". I expect that zones like de. or com. will be be -very- busy dealing w/ the state change in their sub-delegations while netsec.tislabs.com. might be lucky and have fewer and less volitile children. A good chunk of this comes from what peoples expectations are set to. -- --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 Sat Jun 24 00:51:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27836 for ; Sat, 24 Jun 2000 00:51:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 135hN5-000Eyh-00 for namedroppers-data@psg.com; Fri, 23 Jun 2000 21:16:43 -0700 Received: from [206.163.43.51] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 135hN2-000Eyb-00 for namedroppers@ops.ietf.org; Fri, 23 Jun 2000 21:16:42 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 135hN0-0000tb-00 for namedroppers@ops.ietf.org; Sat, 24 Jun 2000 05:16:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200006240440.VAA23274@zed.isi.edu> Subject: Re: Redux: Why I want to remove the null key (SIG) To: lewis@tislabs.com (Edward Lewis) Date: Fri, 23 Jun 2000 21:40:16 -0700 (PDT) Cc: roy@nlnetlabs.nl (Roy Arends), bmanning@ISI.EDU (Bill Manning), lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: from "Edward Lewis" at Jun 14, 2000 10:57:03 AM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ed, Roy, One thing we have run into here is the trap of presuming that once a zone is "secure" that it remains so. i.e. the transition from non-secure to secure is one-way and occurs once. I have come to the realization that the security of the zone is time dependent and it will flip between states on a regular basis over time. So the ability to have the child inform the parent of its particular state at any given time is important. This is easy, since there exists a well-known and used method for doing this today. The harder part is to have the parent take appropriate, automated actions based on the state change, e.g. signing the child keys and handing them back to the child. % I've iidentified this as a remaining issue. Since I'm % operationally-challenged (having no real network to run) I would like to % hear other opinions. % % If you were to ask me my idea on this (or not ask) - some RPC-like / (I % hate to say it) Web-CGI-Applet interface where upon a client does: % % http(s)://www.WeSignKeys4You.sec/keysigningform.pl % % The front end accepts keys and returns results. The back end records the % action and sees to it that the result is reflected in the delegating zone. % % Now, I've left out a heck of a lot of details (e.g., trans. sec.) and % options... % % PS - Yeah, my scenario above assumes a largely delegated zone, yadda, yadda. % % At 8:50 AM -0400 6/14/00, Roy Arends wrote: % >On Wed, 14 Jun 100, Bill Manning wrote: % >> Again, How does the child ask the parent? via some DNS protocol feature? % >> Registered postal mail? % > % >Anyway the child desires and parent accepts. Not particular via some DNS % >protocol feature. This can be done out of band. % > % >Registered postal mail will do. % % % -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- % Edward Lewis NAI Labs % Phone: +1 443-259-2352 Email: lewis@tislabs.com % % "It takes years of training to know when to do nothing" - Dogbert % % Opinions expressed are property of my evil twin, not my employer. % % % -- --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 Sat Jun 24 22:11:56 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17674 for ; Sat, 24 Jun 2000 22:11:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 1361P6-0003sz-00 for namedroppers-data@psg.com; Sat, 24 Jun 2000 18:40:08 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 1361P4-0003st-00 for namedroppers@ops.ietf.org; Sat, 24 Jun 2000 18:40:07 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 1361PK-0001NO-00 for namedroppers@ops.ietf.org; Sat, 24 Jun 2000 21:40:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200006240440.VAA23274@zed.isi.edu> References: from "Edward Lewis" at Jun 14, 2000 10:57:03 AM Date: Sat, 24 Jun 2000 11:38:46 -0400 To: Bill Manning From: Edward Lewis Subject: Re: Redux: Why I want to remove the null key (SIG) Cc: lewis@tislabs.com (Edward Lewis), roy@nlnetlabs.nl (Roy Arends), bmanning@ISI.EDU (Bill Manning), namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is something I'm well aware of. See detail below. I'm glad to hear real operations folks are concerned about this (well, not glad as in you have a problem, but glad the issues have gained significance). At 12:40 AM -0400 6/24/00, Bill Manning wrote: > Ed, Roy, > One thing we have run into here is the trap of presuming that >once a zone is "secure" that it remains so. i.e. the transition from >non-secure to secure is one-way and occurs once. I have come to >the realization that the security of the zone is time dependent and >it will flip between states on a regular basis over time. So the ability >to have the child inform the parent of its particular state at any >given time is important. This is easy, since there exists a well-known >and used method for doing this today. The harder part is to have the >parent take appropriate, automated actions based on the state change, >e.g. signing the child keys and handing them back to the child. Here's the kind of detail I've already thought over. A child submits a set of (appropriate) keys for signing and requests that the validity of the SIG record be the month of January. The child then sends another set for March (forgetting February). Let's assume both signing happen in December the year before. So, is the parent going to say the child is secure in Jan and Mar, but not Feb? I mean, the spec calls for this, but will this happen in practice? At issue is the policy a parent will have regarding the signing of keys for children (must be for contiguous periods, etc.). How will the parent "remember" what it has signed? There isn't a data structure or base in BIND that will manage this. (Note, I am not asserting that BIND is the only option for name servers, just that it is the most prevalent. I heartily endorse "competitors.") -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jun 24 22:12:15 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17685 for ; Sat, 24 Jun 2000 22:12:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 1361N9-0003rt-00 for namedroppers-data@psg.com; Sat, 24 Jun 2000 18:38:07 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 1361N7-0003rm-00 for namedroppers@ops.ietf.org; Sat, 24 Jun 2000 18:38:06 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 1361NM-0001NI-00 for namedroppers@ops.ietf.org; Sat, 24 Jun 2000 21:38:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000624170347.031761b8@dokka.kvatro.no> Date: Sat, 24 Jun 2000 17:29:56 +0200 To: Edward Lewis , Bill Manning From: Harald Tveit Alvestrand Subject: Re: Redux: Why I want to remove the null key (SIG) Cc: roy@nlnetlabs.nl (Roy Arends), lewis@tislabs.com, namedroppers@ops.ietf.org In-Reply-To: References: <200006141241.FAA19541@boreas.isi.edu> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:03 23.06.2000 -0400, Edward Lewis wrote: >With regards to getting a child key signed, recognized, and reflected in >the parent zone - is the onus on the child or parent to make sure things >are correct? > >Would this answer change if we are talking .de or .com vs. >netsec.tislabs.com (i.e., a lower in the tree "small" delegation)? the *only* thing a signature proves is that a holder of the corresponding private key signed the data. At present, we generally assume that: - only legitimate authorities for a zone hold the private keys involved - they will only issue subzone key signatures when they believe that the child is secure. If these assumptions hold, the SIG becomes a statement of belief by the parent zone authorities. How the child convinces the parent to hold that belief is not standardized. In the .de case, the child and parent are different organizations; beliefs of one organization about another are generally based upon legally binding contracts. In the case of netsec.tislabs.com, the usual reason for the zone owner to believe the child zone is secure is that he configured it himself, or that he knows and trusts the guy who did it. The appropriate protocol for the two cases is probably different. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jun 26 10:28:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06881 for ; Mon, 26 Jun 2000 10:28:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 136YtR-000Apz-00 for namedroppers-data@psg.com; Mon, 26 Jun 2000 06:25:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 136YtQ-000Apt-00 for namedroppers@ops.ietf.org; Mon, 26 Jun 2000 06:25:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 136YtQ-000AZE-00 for namedroppers@ops.ietf.org; Mon, 26 Jun 2000 06:25:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 26 Jun 2000 11:50:43 +0200 (CEST) From: Roy Arends To: Edward Lewis cc: Bill Manning , namedroppers@ops.ietf.org Subject: Re: Redux: Why I want to remove the null key (SIG) In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 23 Jun 2000, Edward Lewis wrote: > With regards to getting a child key signed, recognized, and reflected in > the parent zone - is the onus on the child or parent to make sure things > are correct? Considering this child key is a real key (not a null key), this key will probably never make it into the parent zone. The only thing that is reflected in the parent zone is the absence of the null key. we think that the onus is on the child. It has to make sure that it meets the demands of the parent's policy. > Would this answer change if we are talking .de or .com vs. > netsec.tislabs.com (i.e., a lower in the tree "small" delegation)? No, probably not. If a child wants to be secured, it is dependant on the parents policy. Regards, Roy -- roy@nlnetlabs.nl NLnetLabs tel +31208884551 Kruislaan 419 |\ || _ _|_ | _ |_ _ 1098 VA Amsterdam | \||__| )(-|_ |__(_||_)_) The Netherlands to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jun 29 19:00:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22013 for ; Thu, 29 Jun 2000 19:00:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 137mTj-0009MN-00 for namedroppers-data@psg.com; Thu, 29 Jun 2000 15:08:11 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 137mTi-0009MH-00 for namedroppers@ops.ietf.org; Thu, 29 Jun 2000 15:08:10 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 137mTi-000Jiz-00 for namedroppers@ops.ietf.org; Thu, 29 Jun 2000 15:08:10 -0700 Date: Thu, 29 Jun 2000 14:47:05 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: IESG comments on draft-ietf-dnsext-iana-dns To: namedroppers@ops.ietf.org Cc: nordmark@jurassic.Eng.Sun.COM, ogud@tislabs.com, randy@psg.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 The IANA and IESG suggests the following changes: Since the IANA is note the same as ISI please change the to See "DNS parameters" at http://www.iana.org/numbers.htm Remove section 4 on designed expert since it doesn't add any information (the IESG assumes that the IANA is capable of asking questions of the IESG should such a need arise) and it raises the possibility of a request for a designated expert even though there is nothing for the expert to do. (In general it makes sense to have designated experts to help with allocation for specific name spaces.) -- Unless there is a problem with the above changes we can update the document and have it approved. 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 Thu Jun 29 20:19:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23549 for ; Thu, 29 Jun 2000 20:19:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 137nzh-000AIS-00 for namedroppers-data@psg.com; Thu, 29 Jun 2000 16:45:17 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 137nzh-000AIM-00 for namedroppers@ops.ietf.org; Thu, 29 Jun 2000 16:45:17 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 137nzh-000KSX-00 for namedroppers@ops.ietf.org; Thu, 29 Jun 2000 16:45:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200006292345.TAA03576@torque.pothole.com> To: Erik Nordmark cc: namedroppers@ops.ietf.org, ogud@tislabs.com, randy@psg.com, lde008@dma.isg.mot.com Subject: Re: IESG comments on draft-ietf-dnsext-iana-dns In-reply-to: Your message of "Thu, 29 Jun 2000 14:47:05 PDT." Date: Thu, 29 Jun 2000 19:45:57 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >The IANA and IESG suggests the following changes: > >Since the IANA is not the same as ISI please change the > >to > See "DNS parameters" at http://www.iana.org/numbers.htm OK. I didn't know it was accessible that way. >Remove section 4 on designed expert since it doesn't add any information >(the IESG assumes that the IANA is capable of asking questions of the IESG >should such a need arise) and it raises the possibility of a request for >a designated expert even though there is nothing for the expert to do. >(In general it makes sense to have designated experts to help with allocation >for specific name spaces.) That section was added due to a previous explicit email request from IANA. I assume you have more recent data than that and we can drop it. >-- >Unless there is a problem with the above changes we can update the >document and have it approved. > > Erik Revised draft should be submitted Friday, tomorrow. Donald =================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 140 Forest Avenue lde008@dma.isg.mot.com Hudson, MA 01749 USA +1 978-562-2827(h) +1 508-261-5434(w) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 30 11:20:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19332 for ; Fri, 30 Jun 2000 11:20:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 1381hD-000HwX-00 for namedroppers-data@psg.com; Fri, 30 Jun 2000 07:23:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 1381hC-000HwR-00 for namedroppers@ops.ietf.org; Fri, 30 Jun 2000 07:23:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 1381hC-0000XB-00 for namedroppers@ops.ietf.org; Fri, 30 Jun 2000 07:23:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200006292345.TAA03576@torque.pothole.com> References: Your message of "Thu, 29 Jun 2000 14:47:05 PDT." Date: Fri, 30 Jun 2000 10:14:07 -0400 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: IESG comments on draft-ietf-dnsext-iana-dns Cc: Erik Nordmark , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 7:45 PM -0400 6/29/00, Donald E. Eastlake 3rd wrote: >Someone else wrote: >>The IANA and IESG suggests the following changes: >> >>Since the IANA is not the same as ISI please change the >> >>to >> See "DNS parameters" at http://www.iana.org/numbers.htm > >OK. I didn't know it was accessible that way. Not to protest, but when I went to access the assignments (for another reason) today, I followed the IANA link. Here's what I got: http://www.iana.org/numbers.htm pointed to: http://www.iana.org/numbers.htm#D pointed to: http://www.isi.edu/in-notes/iana/assignments/dns-parameters The page source for the "D" link: D The page source for the "DNS params" link:

DNS Parameters

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jun 30 12:48:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22067 for ; Fri, 30 Jun 2000 12:48:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 1383WX-000JBi-00 for namedroppers-data@psg.com; Fri, 30 Jun 2000 09:20:13 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 1383WW-000JBc-00 for namedroppers@ops.ietf.org; Fri, 30 Jun 2000 09:20:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 1383WW-0001VI-00 for namedroppers@ops.ietf.org; Fri, 30 Jun 2000 09:20:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 30 Jun 2000 09:15:21 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG comments on draft-ietf-dnsext-iana-dns To: Edward Lewis Cc: "Donald E. Eastlake 3rd" , Erik Nordmark , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Not to protest, but when I went to access the assignments (for another > reason) today, I followed the IANA link. Here's what I got: > > http://www.iana.org/numbers.htm pointed to: > http://www.iana.org/numbers.htm#D pointed to: > http://www.isi.edu/in-notes/iana/assignments/dns-parameters Yes, but that is likely to change at some point in time. It would make sense to have the IANA pages all live under iana.org URLs. The issue is that the RFCs live forever thus having a 1) stable reference and 2) a reference that makes it clear that the pages are maintained by the IANA (and not ISI) makes a lot of sense. 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.