From owner-namedroppers@ops.ietf.org Tue Jul 1 06:59:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05916 for ; Tue, 1 Jul 2003 06:59:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XIld-000PNk-A8 for namedroppers-data@psg.com; Tue, 01 Jul 2003 10:53:45 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.14) id 19XIlV-000PMi-Ly for namedroppers@ops.ietf.org; Tue, 01 Jul 2003 10:53:37 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h61ArT125193; Tue, 1 Jul 2003 17:53:29 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h61ApZl10335; Tue, 1 Jul 2003 17:51:43 +0700 (ICT) From: Robert Elz To: Mike StJohns cc: Andreas.Gustafsson@nominum.com (Andreas Gustafsson), namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt In-Reply-To: <5.2.1.1.2.20030630165223.026f4008@localhost> References: <5.2.1.1.2.20030630165223.026f4008@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Jul 2003 17:51:35 +0700 Message-ID: <10910.1057056695@munnari.OZ.AU> X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 30 Jun 2003 17:03:01 -0400 From: Mike StJohns Message-ID: <5.2.1.1.2.20030630165223.026f4008@localhost> | The reason I like | the name diversity constraint is because it provides one more resolution | path to the delegated zone, even if the glue records in the parent are | messed up or more probably, missing. For what it is worth, and this might almost be a first time in history, I agree with djb's comments on this. I won't repeat those, but I would add that if you can't trust the parent zone to have your delegation configured correctly, you may as well give up and go someplace else completely - adding a server that has a name somewhere else isn't very likely to help (sure, you can craft a case where it actually solves an imagined potential problem, but in reality...) | To be clear, your issue is with "that at least one name points to a server | not named in the child zone" and not with the rest of it as above? Here, I agree with your and not Andreas - parent zone admins should do their utmost to ensure that the child zone is correctly configured before updating delegations - it is the only tool that exists to cause people managing the delegated domains to get things right. But this only extends to the technical requirements, "good policy" can't be enforced (shouldn't be anyway), so even if it were reaosnable to attempt to discover the attachment points of different servers, that wouldn't be reasonable for the parent to do. Checking that the servers are properly configured and answering correctly however it can easily, and should always, do. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 1 07:24:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07578 for ; Tue, 1 Jul 2003 07:24:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XJCP-00023g-W6 for namedroppers-data@psg.com; Tue, 01 Jul 2003 11:21:25 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19XJCN-00023K-Ax for namedroppers@ops.ietf.org; Tue, 01 Jul 2003 11:21:23 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06579; Tue, 1 Jul 2003 07:21:19 -0400 (EDT) Message-Id: <200307011121.HAA06579@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-unknown-rrs-06.txt Date: Tue, 01 Jul 2003 07:21:19 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Handling of Unknown DNS Resource Record Types Author(s) : A. Gustafsson Filename : draft-ietf-dnsext-unknown-rrs-06.txt Pages : 8 Date : 2003-6-30 Extending the Domain Name System with new Resource Record types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-unknown-rrs-06.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-unknown-rrs-06.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: <2003-6-30151032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-unknown-rrs-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-unknown-rrs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151032.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 1 13:38:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07844 for ; Tue, 1 Jul 2003 13:37:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XOtO-0002pm-4G for namedroppers-data@psg.com; Tue, 01 Jul 2003 17:26:10 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.14) id 19XOtK-0002nd-HX for namedroppers@ops.ietf.org; Tue, 01 Jul 2003 17:26:06 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 2540256824 for ; Tue, 1 Jul 2003 10:25:53 -0700 (PDT) Message-Id: <5.2.1.1.2.20030701130715.024b0168@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 01 Jul 2003 13:25:55 -0400 To: namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: draft-stjohns-secure-notify-00.txt In-Reply-To: <66677.1057078206@shell.nominum.com> References: <10910.1057056695@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk OK - the non-child named secondary is out. Let's try and bring this back to the question that I really want answered. Assuming that a parent will update NS records based on what a child sends it under the secure notify (let's not argue this assumption for now), what is a reasonable set of checks the parent should apply to the data sent to it by the child? Select one or more. a) None - trust the child to do what it is supposed to and just update the records when told to do so. b) Check to make sure the systems named in the NS records can be resolved (e.g. either glue records exist or other resolution) c) check...can be reached d) check... are serving the child zone e) Check that there are at least 2 distinct servers listed in the NS records (e.g. resolve to different A records?) Note that the child will be checking to see if the parent actually publishes the new records and will repeat the notify if the new records aren't published after some period of time. Should the child zone, regardless of any secure notify capability, check its delegation status at the parent periodically? (Actually, probably a topic for another thread, but could add this to the secure notify document as the code to do secure notify will have to do this in part). At 12:50 7/1/2003, Jim Reid wrote: > >>>>> "kre" == Robert Elz writes: > > kre> Here, I agree with your and not Andreas - parent zone admins > kre> should do their utmost to ensure that the child zone is > kre> correctly configured before updating delegations - it is the > kre> only tool that exists to cause people managing the delegated > kre> domains to get things right. > > kre> But this only extends to the technical requirements, "good > kre> policy" can't be enforced (shouldn't be anyway), so even if > kre> it were reaosnable to attempt to discover the attachment > kre> points of different servers, that wouldn't be reasonable for > kre> the parent to do. Checking that the servers are properly > kre> configured and answering correctly however it can easily, and > kre> should always, do. > >Agreed. But even this is not enough. Even in the TLDs that do have >these checks, entropy takes over eventually. ISTR Patrik Faltstrom's >survey of .se which showed 20-25% of the .se delegations were broken >even although they were checked and found to be correct at the time >the delegations were made. So the question becomes one of policy. Who >will be the DNS delegation checking police? What do they check? And >how do they deal with offenders? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 1 13:50:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09259 for ; Tue, 1 Jul 2003 13:50:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XOKl-00016C-1D for namedroppers-data@psg.com; Tue, 01 Jul 2003 16:50:23 +0000 Received: from [128.177.192.160] (helo=shell.nominum.com) by psg.com with esmtp (Exim 4.14) id 19XOKi-00015x-E6 for namedroppers@ops.ietf.org; Tue, 01 Jul 2003 16:50:20 +0000 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id EDD2E137F13; Tue, 1 Jul 2003 09:50:06 -0700 (PDT) To: Robert Elz Cc: Mike StJohns , Andreas.Gustafsson@nominum.com (Andreas Gustafsson), namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt In-Reply-To: Message from Robert Elz of "Tue, 01 Jul 2003 17:51:35 +0700." <10910.1057056695@munnari.OZ.AU> Date: Tue, 01 Jul 2003 09:50:06 -0700 Message-ID: <66677.1057078206@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "kre" == Robert Elz writes: kre> Here, I agree with your and not Andreas - parent zone admins kre> should do their utmost to ensure that the child zone is kre> correctly configured before updating delegations - it is the kre> only tool that exists to cause people managing the delegated kre> domains to get things right. kre> But this only extends to the technical requirements, "good kre> policy" can't be enforced (shouldn't be anyway), so even if kre> it were reaosnable to attempt to discover the attachment kre> points of different servers, that wouldn't be reasonable for kre> the parent to do. Checking that the servers are properly kre> configured and answering correctly however it can easily, and kre> should always, do. Agreed. But even this is not enough. Even in the TLDs that do have these checks, entropy takes over eventually. ISTR Patrik Faltstrom's survey of .se which showed 20-25% of the .se delegations were broken even although they were checked and found to be correct at the time the delegations were made. So the question becomes one of policy. Who will be the DNS delegation checking police? What do they check? And how do they deal with offenders? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 1 17:33:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17118 for ; Tue, 1 Jul 2003 17:33:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XSfh-000Faz-1W for namedroppers-data@psg.com; Tue, 01 Jul 2003 21:28:17 +0000 Received: from [203.146.155.28] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.14) id 19XSfc-000Fal-Si for namedroppers@ops.ietf.org; Tue, 01 Jul 2003 21:28:13 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h61LQ8lw012464; Wed, 2 Jul 2003 04:26:12 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h61LNNs00169; Wed, 2 Jul 2003 04:23:27 +0700 (ICT) From: Robert Elz To: Mike StJohns cc: namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt In-Reply-To: <5.2.1.1.2.20030701130715.024b0168@localhost> References: <5.2.1.1.2.20030701130715.024b0168@localhost> <10910.1057056695@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 2003 04:23:23 +0700 Message-ID: <7364.1057094603@munnari.OZ.AU> X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 01 Jul 2003 13:25:55 -0400 From: Mike StJohns Message-ID: <5.2.1.1.2.20030701130715.024b0168@localhost> | Select one or more. (b) (c) & (d). (e) would be nice, but is very difficult to do in a meaningful way, and I'm not sure that doing half a job is worth it - that is, really determining for sure that there are 2 servers is very hard to accomplish, just knowing that there are 2 different A records isn't really sufficient, so I probably wouldn't bother with that one. | Note that the child will be checking to see if the parent actually | publishes the new records and will repeat the notify if the new records | aren't published after some period of time. One would hope that if the child is automating a delegation request, that it is also checking to make sure that all the servers are functioning correctly, before sending a request to the parent. We cannot, of course, depend upon that for anything, but operationally, it is what should be happening, so the parent getting lots of repeated update requests which it is just refusing to carry out shouldn't be normal. | Should the child zone, | regardless of any secure notify capability, check its delegation status at | the parent periodically? Most likely, but it isn't clear to me what it should do when it finds itself no longer listed. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 05:17:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29348 for ; Wed, 2 Jul 2003 05:17:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xdcx-000JuD-OK for namedroppers-data@psg.com; Wed, 02 Jul 2003 09:10:11 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19Xdcv-000Jtp-0b for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 09:10:09 +0000 Received: (qmail 73962 invoked by uid 1016); 2 Jul 2003 09:10:40 -0000 Date: 2 Jul 2003 09:10:40 -0000 Message-ID: <20030702091040.73961.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt References: <10910.1057056695@munnari.OZ.AU> <5.2.1.1.2.20030701130715.024b0168@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mike StJohns writes: > c) check...can be reached > d) check... are serving the child zone Please don't use vague words like ``serving.'' Very few people know what service is actually necessary for interoperability. The average parent script writers certainly don't; I've seen them try TCP queries in violation of RFC 1123, treat the SOA suggestions from a particular book as requirements, demand root addresses from the child servers, et al. > b) Check to make sure the systems named in the NS records can be resolved > (e.g. either glue records exist or other resolution) This is a better suggestion, because it's hard for parent script writers to screw up. They'll use gethostbyname() rather than trying to write their own resolver. But it's important to emphasize that glue is allowed and encouraged, even though it means that gethostbyname() will fail. > e) Check that there are at least 2 distinct servers listed in the NS > records (e.g. resolve to different A records?) If tiddlywinks.dom consists of a single machine running an HTTP server, an SMTP server, and a DNS server, then demanding a second DNS server is a really bad idea: it adds expense while decreasing reliability. See http://cr.yp.to/djbdns/third-party.html. DNS servers should be spread as widely as the other servers at the site. For some sites this means DNS servers all over the globe. For others it means a grand total of one DNS server. ``Two different A records'' is a wild oversimplification, horribly inadequate for some sites and actively counterproductive for others. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 08:45:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12835 for ; Wed, 2 Jul 2003 08:45:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XgtK-0002UI-NN for namedroppers-data@psg.com; Wed, 02 Jul 2003 12:39:18 +0000 Received: from [128.177.192.160] (helo=shell.nominum.com) by psg.com with esmtp (Exim 4.14) id 19XgtG-0002St-3N for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 12:39:14 +0000 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 71BE1137F24; Wed, 2 Jul 2003 05:39:00 -0700 (PDT) To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt In-Reply-To: Message from "D. J. Bernstein" of "02 Jul 2003 09:10:40 -0000." <20030702091040.73961.qmail@cr.yp.to> Date: Wed, 02 Jul 2003 05:39:00 -0700 Message-ID: <89557.1057149540@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-4.4 required=5.0 tests=BAYES_30,BE_AMAZED,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "djb" == D J Bernstein writes: djb> Please don't use vague words like ``serving.'' Very few djb> people know what service is actually necessary for djb> interoperability. The average parent script writers certainly djb> don't; I've seen them try TCP queries in violation of RFC djb> 1123, treat the SOA suggestions from a particular book as djb> requirements, demand root addresses from the child servers, djb> et al. So what? A parent is entitled to apply and enforce any criteria they want on the delegations they make. Whether those criteria are good or bad is irrelevant: if someone wants a name in a certain part of the tree, they have to play by the parent's rules. The checks you refer to are not done for reasons of interoperability. They're mainly done to apply a clue threshold to the people responsible for the DNS for the name that's being registered. This reduces the load on the registry's support staff as they don't get swamped by calls from registrants about how to set up and run name servers. If you've ever visited a TLD registry -- as I have -- you'd be amazed at the number of calls they get from people who believe paying $25 or so for a name registration entitles them to hours of DNS consultancy and hand-holding. djb> If tiddlywinks.dom consists of a single machine running an djb> HTTP server, an SMTP server, and a DNS server, then demanding djb> a second DNS server is a really bad idea: it adds expense djb> while decreasing reliability. This is utter nonsense and you should know better. RFC1034 is very clear that tiddlywinks.dom should have at least two name servers and RFC2182 explains why. I suspect that cr.yp.to consists of not much more than an HTTP server, an SMTP server and a DNS server. Yet this zone has two NS 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. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 12:50:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01005 for ; Wed, 2 Jul 2003 12:50:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xkhk-000F6c-Gf for namedroppers-data@psg.com; Wed, 02 Jul 2003 16:43:36 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Xkhe-000F4X-QU for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 16:43:30 +0000 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2003 09:44:08 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62Ggv7F020853; Wed, 2 Jul 2003 09:42:57 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ53052; Wed, 2 Jul 2003 12:42:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702123658.048396e8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 12:42:50 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: DDNS-DHCP [2]: Allow for other identifying data in the DHCID RR? Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: <4.3.2.7.2.20030605221922.00bbc948@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Summary of discussion of this issue: Several respondents noted that this issue is essentially the same as "DDNS-DHCP [1]: Use DHCID RR just for DHCP or extend for other update mechanisms?" I've summarized the responses to both issues here. There were three responses to the effect that the DHCID RR should be reserved for DHCP. No other uses for the DHCID RR have been identified either in discussion (with the exception of one mention of PPP) or in deployment of the DDNS-DHCP interaction mechanism. Adding the capability in anticipation of future, as-yet-undefined protocols would add complexity with little or no added value. At 10:22 PM 6/5/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The DHCID RR data consists of a type code and a hash > of the identifier of the updater of the record. Should > it be generalized (perhaps as a side effect of generalizing > the use of the DHCID RR to other types of resolution) > to a type code and type-specific data? That is, should > the DHCID RR allow for other forms of data in addition > to a 16-byte MD5 hash value to be stored with the type code? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 12:59:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01347 for ; Wed, 2 Jul 2003 12:59:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XktE-000FuY-Fw for namedroppers-data@psg.com; Wed, 02 Jul 2003 16:55:28 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.14) id 19XktB-000FqZ-P5 for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 16:55:25 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Jul 2003 09:51:30 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h62Gsqf0020257; Wed, 2 Jul 2003 09:54:53 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ53952; Wed, 2 Jul 2003 12:54:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 12:49:55 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: <4.3.2.7.2.20030606002703.03d40c28@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Summary of discussion of this issue: We need more discussion of this issue to come to consensus on resolution. Josh Littlefield responded (see http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02107.html) Pleaes review Josh's input and post your comments. - Ralph At 12:27 AM 6/6/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The interaction between DHCPv4 and DHCPv6 needs to be carefully > defined. Suppose a DHCPv4 server updates the A RR and a DHCPv6 > server updates the AAAA RR of the same node? How is the conflict > in the use of the DHCID RR for that node resolved? > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 13:08:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02035 for ; Wed, 2 Jul 2003 13:08:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xl1I-000GV9-TW for namedroppers-data@psg.com; Wed, 02 Jul 2003 17:03:48 +0000 Received: from [64.102.124.12] (helo=rtp-core-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Xl1G-000GSv-4U for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 17:03:46 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62H2Ofq027784; Wed, 2 Jul 2003 13:02:24 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ54587; Wed, 2 Jul 2003 13:02:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702125011.04878e10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 13:01:19 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: DDNS-DHCP [4]: 12 bit RCODEs in DHCP FQDN option Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Summary of discussion of this issue: We need more discussion of this issue to determine WG consensus. Mark Stapp responded (see http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02074.html) that there are many clients that expect the 8 bit RCODE format in draft-ietf-dhc-fqdn-option-05.txt, and the RCODE values of interest to DDNS-DHCP interaction can be carried in an 8 bit field. The WG consensus was that backward compatibility with deployed clients is more important than compatibility with EDNS0 12 bit RCODES. Please review Mark's input and respond to the mailing list... - Ralph At 06:53 AM 6/6/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The DHCP FQDN option should carry 12 bit RCODEs, for > consistency with the extended RCODEs defined by EDNS0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 13:08:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02056 for ; Wed, 2 Jul 2003 13:08:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xl0T-000GRP-5r for namedroppers-data@psg.com; Wed, 02 Jul 2003 17:02:57 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Xl0P-000GPq-Hh for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 17:02:53 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h62H2Kf0027357; Wed, 2 Jul 2003 10:02:20 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ54589; Wed, 2 Jul 2003 13:02:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702130015.048b2f98@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 13:01:48 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: DDNS-DHCP [5]: IDN in DDNS-DHCP docs Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There has been no discussion of this issue. We need additional discussion on the mailing list to determine WG consensus on the resolution of this issue. - Ralph At 07:01 AM 6/6/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The IDN WG has concluded and the results of its work should be > considered in the DDNS-DHCP documents. The changes may be as > minimal as specifying the use of the IDN on-the-wire format. > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 14:17:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05152 for ; Wed, 2 Jul 2003 14:17:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xm4N-000KSc-8B for namedroppers-data@psg.com; Wed, 02 Jul 2003 18:11:03 +0000 Received: from [64.102.124.12] (helo=rtp-core-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Xm4J-000KQg-Ex for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 18:10:59 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62I9ifq003611; Wed, 2 Jul 2003 14:09:44 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ60424; Wed, 2 Jul 2003 14:09:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702130459.048217f0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 14:09:36 -0400 To: namedroppers@ops.ietf.org, dhcwg@ietf.org From: Ralph Droms Subject: Re: DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: References: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This issue generated much discussion, without any clear consensus on what to do. You can review the discussion thread starting at http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02092.html Please review the previous discussion and comment to the mailing list... - Ralph At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The RR TTLs need careful attention so that it never exceeds the > expiration time of the lease on the associated address. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 15:13:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07738 for ; Wed, 2 Jul 2003 15:13:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xmze-000Nbf-8n for namedroppers-data@psg.com; Wed, 02 Jul 2003 19:10:14 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.14) id 19Xmzb-000NbH-18 for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 19:10:11 +0000 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id AF41D1B203B; Wed, 2 Jul 2003 14:06:28 -0500 (CDT) From: Ted Lemon To: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Date: Wed, 2 Jul 2003 19:10:10 +0000 User-Agent: KMail/1.5 References: <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307021910.10225.mellon@nominum.com> X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 July 2003 16:49, Ralph Droms wrote: > > The interaction between DHCPv4 and DHCPv6 needs to be carefully > > defined. Suppose a DHCPv4 server updates the A RR and a DHCPv6 > > server updates the AAAA RR of the same node? How is the conflict > > in the use of the DHCID RR for that node resolved? I had to sit with this one for a while. But my conclusion is that the solution Josh proposes (do extra queries) isn't the right solution. The right solution is to have a different RRtype for V4 and V6, just as we have A and AAAA for IPv4 addresses and IPv6 addresses. This solution reduces the number of updates/queries required to make it work in the dual-stack case, so I think it's preferable, even though it means we have to allocate two RRtypes instead of one. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 15:22:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08493 for ; Wed, 2 Jul 2003 15:22:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xn5w-000O1l-87 for namedroppers-data@psg.com; Wed, 02 Jul 2003 19:16:44 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.14) id 19Xn5t-000O1U-RW for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 19:16:41 +0000 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id CF4451B2255; Wed, 2 Jul 2003 14:12:59 -0500 (CDT) From: Ted Lemon To: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: DDNS-DHCP [5]: IDN in DDNS-DHCP docs Date: Wed, 2 Jul 2003 19:16:41 +0000 User-Agent: KMail/1.5 References: <4.3.2.7.2.20030702130015.048b2f98@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20030702130015.048b2f98@funnel.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307021916.41653.mellon@nominum.com> X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 July 2003 17:01, Ralph Droms wrote: > There has been no discussion of this issue. We need > additional discussion on the mailing list to determine > WG consensus on the resolution of this issue. > > - Ralph > > At 07:01 AM 6/6/2003 -0400, Ralph Droms wrote: > >DDNS-DHCP issue: > > > > The IDN WG has concluded and the results of its work should be > > considered in the DDNS-DHCP documents. The changes may be as > > minimal as specifying the use of the IDN on-the-wire format. I think the reason for the lack of discussion is that this is a non-issue - the reason we went to using the DNS wire format was to avoid having to deal with this issue later. I think that if the IDN folks think there is a problem here, they should say what it is and propose a solution. I don't think there is a problem. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 15:23:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08527 for ; Wed, 2 Jul 2003 15:23:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xn7w-000O9w-Bd for namedroppers-data@psg.com; Wed, 02 Jul 2003 19:18:48 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.14) id 19Xn7u-000O9f-37 for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 19:18:46 +0000 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 163B71B203B; Wed, 2 Jul 2003 14:15:04 -0500 (CDT) From: Ted Lemon To: Ralph Droms , namedroppers@ops.ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] Re: DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Date: Wed, 2 Jul 2003 19:18:46 +0000 User-Agent: KMail/1.5 References: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> <4.3.2.7.2.20030702130459.048217f0@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20030702130459.048217f0@funnel.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307021918.46376.mellon@nominum.com> X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 July 2003 18:09, Ralph Droms wrote: > This issue generated much discussion, without any > clear consensus on what to do. > > The RR TTLs need careful attention so that it never exceeds the > > expiration time of the lease on the associated address. Most of the discussion on this topic revolved around hypothetical extensions to the DNS protocol. While I am interested in talking about these extensions, discussion of them neither represents consensus nor lack of consensus on this particular document. If you exclude the discussion about TTD from consideration about consensus, I think you will see a different picture. My own position on this is that the problem is already sufficiently addressed in the draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 15:32:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08872 for ; Wed, 2 Jul 2003 15:32:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XnHo-000P4E-TX for namedroppers-data@psg.com; Wed, 02 Jul 2003 19:29:00 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.14) id 19XnHm-000Ozt-MD for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 19:28:58 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Jul 2003 12:25:04 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h62JSQf0002395; Wed, 2 Jul 2003 12:28:26 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ67002; Wed, 2 Jul 2003 15:28:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702152118.048aedd0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 15:28:19 -0400 To: Ted Lemon From: Ralph Droms Subject: Re: DDNS-DHCP [5]: IDN in DDNS-DHCP docs Cc: dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <200307021916.41653.mellon@nominum.com> References: <4.3.2.7.2.20030702130015.048b2f98@funnel.cisco.com> <4.3.2.7.2.20030702130015.048b2f98@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think I read that draft-ietf-dhc-fqdn-option-05.txt only refers to "DNS encoding as specified in RFC1035". Is there a need for an additional reference, perhaps to RFC 3490? Or is the internationalization transparent to the FQDN option? - Ralph At 07:16 PM 7/2/2003 +0000, Ted Lemon wrote: >On Wednesday 02 July 2003 17:01, Ralph Droms wrote: > > There has been no discussion of this issue. We need > > additional discussion on the mailing list to determine > > WG consensus on the resolution of this issue. > > > > - Ralph > > > > At 07:01 AM 6/6/2003 -0400, Ralph Droms wrote: > > >DDNS-DHCP issue: > > > > > > The IDN WG has concluded and the results of its work should be > > > considered in the DDNS-DHCP documents. The changes may be as > > > minimal as specifying the use of the IDN on-the-wire format. > >I think the reason for the lack of discussion is that this is a non-issue - >the reason we went to using the DNS wire format was to avoid having to deal >with this issue later. I think that if the IDN folks think there is a >problem here, they should say what it is and propose a solution. I don't >think there is a problem. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 15:45:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09310 for ; Wed, 2 Jul 2003 15:45:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XnUZ-000Py7-8E for namedroppers-data@psg.com; Wed, 02 Jul 2003 19:42:11 +0000 Received: from [171.68.223.137] (helo=sj-core-3.cisco.com) by psg.com with esmtp (Exim 4.14) id 19XnUV-000Pw0-US for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 19:42:07 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h62Jf3vd000535; Wed, 2 Jul 2003 12:41:03 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ68073; Wed, 2 Jul 2003 15:41:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702153043.048ad380@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 15:40:56 -0400 To: Ted Lemon From: Ralph Droms Subject: Re: [dhcwg] Re: DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: namedroppers@ops.ietf.org, dhcwg@ietf.org In-Reply-To: <200307021918.46376.mellon@nominum.com> References: <4.3.2.7.2.20030702130459.048217f0@funnel.cisco.com> <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> <4.3.2.7.2.20030702130459.048217f0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There was some discussion about whether stale information in the DNS is a problem in practice. That is, as I understand the problem, stale information - specifically, A RRs in which the IP address associated with domain name foo.example may have been reassigned via DHCP to a new host using domain name bar.example - is not a problem. This stale information may be held in resolver caches for as much as 1/3 of the original lease length if the recommendations in the draft are followed. So, am I on the right track so far? If so, it would be helpful to know *why* this stale information is not a problem. Might there be situations in the future where this stale information might be a problem? I agree that the discussion of hypothetical extensions to existing protocols is out of scope... - Ralph At 07:18 PM 7/2/2003 +0000, Ted Lemon wrote: >On Wednesday 02 July 2003 18:09, Ralph Droms wrote: > > This issue generated much discussion, without any > > clear consensus on what to do. > > > The RR TTLs need careful attention so that it never exceeds the > > > expiration time of the lease on the associated address. > >Most of the discussion on this topic revolved around hypothetical extensions >to the DNS protocol. While I am interested in talking about these >extensions, discussion of them neither represents consensus nor lack of >consensus on this particular document. If you exclude the discussion about >TTD from consideration about consensus, I think you will see a different >picture. > >My own position on this is that the problem is already sufficiently addressed >in the draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 15:48:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09437 for ; Wed, 2 Jul 2003 15:48:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XnXe-0000HJ-3H for namedroppers-data@psg.com; Wed, 02 Jul 2003 19:45:22 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.14) id 19XnXa-0000BE-SO for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 19:45:19 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C2E5E1900; Wed, 2 Jul 2003 15:44:34 -0400 (EDT) Date: Wed, 02 Jul 2003 15:44:34 -0400 From: Rob Austein To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records In-Reply-To: <200307021910.10225.mellon@nominum.com> References: <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <200307021910.10225.mellon@nominum.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030702194434.C2E5E1900@thrintun.hactrn.net> X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 2 Jul 2003 19:10:10 +0000, Ted Lemon wrote: > > On Wednesday 02 July 2003 16:49, Ralph Droms wrote: > > > The interaction between DHCPv4 and DHCPv6 needs to be carefully > > > defined. Suppose a DHCPv4 server updates the A RR and a DHCPv6 > > > server updates the AAAA RR of the same node? How is the conflict > > > in the use of the DHCID RR for that node resolved? > > I had to sit with this one for a while. But my conclusion is that the > solution Josh proposes (do extra queries) isn't the right solution. The > right solution is to have a different RRtype for V4 and V6, just as we have A > and AAAA for IPv4 addresses and IPv6 addresses. This solution reduces the > number of updates/queries required to make it work in the dual-stack case, so > I think it's preferable, even though it means we have to allocate two RRtypes > instead of one. I agree with Ted on this. Use separate RR types. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 15:52:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09942 for ; Wed, 2 Jul 2003 15:52:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XnbV-0000cV-RH for namedroppers-data@psg.com; Wed, 02 Jul 2003 19:49:21 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.14) id 19XnbS-0000YG-8Z for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 19:49:18 +0000 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2003 12:49:58 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h62Jmjrm015004; Wed, 2 Jul 2003 12:48:46 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-24.cisco.com [10.82.240.24]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ68653; Wed, 2 Jul 2003 15:48:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702154727.048a5d10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 15:48:37 -0400 To: Rob Austein From: Ralph Droms Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Cc: dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <20030702194434.C2E5E1900@thrintun.hactrn.net> References: <200307021910.10225.mellon@nominum.com> <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <200307021910.10225.mellon@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk OK ... does this solution require any changes to the existing docs? Perhaps just making clear the docs aply to DHCPv4 and A records? - Ralph At 03:44 PM 7/2/2003 -0400, Rob Austein wrote: >At Wed, 2 Jul 2003 19:10:10 +0000, Ted Lemon wrote: > > > > On Wednesday 02 July 2003 16:49, Ralph Droms wrote: > > > > The interaction between DHCPv4 and DHCPv6 needs to be carefully > > > > defined. Suppose a DHCPv4 server updates the A RR and a DHCPv6 > > > > server updates the AAAA RR of the same node? How is the conflict > > > > in the use of the DHCID RR for that node resolved? > > > > I had to sit with this one for a while. But my conclusion is that the > > solution Josh proposes (do extra queries) isn't the right solution. The > > right solution is to have a different RRtype for V4 and V6, just as we > have A > > and AAAA for IPv4 addresses and IPv6 addresses. This solution reduces > the > > number of updates/queries required to make it work in the dual-stack > case, so > > I think it's preferable, even though it means we have to allocate two > RRtypes > > instead of one. > >I agree with Ted on this. Use separate RR types. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 16:30:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12257 for ; Wed, 2 Jul 2003 16:30:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XoAQ-0002rV-R6 for namedroppers-data@psg.com; Wed, 02 Jul 2003 20:25:26 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.14) id 19XoAK-0002ql-0W for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 20:25:20 +0000 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 8D3061B203B; Wed, 2 Jul 2003 15:21:37 -0500 (CDT) From: Ted Lemon To: Ralph Droms , Ted Lemon Subject: Re: [dhcwg] Re: DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Date: Wed, 2 Jul 2003 20:25:19 +0000 User-Agent: KMail/1.5 Cc: namedroppers@ops.ietf.org, dhcwg@ietf.org References: <4.3.2.7.2.20030702130459.048217f0@funnel.cisco.com> <4.3.2.7.2.20030702153043.048ad380@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20030702153043.048ad380@funnel.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307022025.19517.mellon@nominum.com> X-Spam-Status: No, hits=-24.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday 02 July 2003 19:40, Ralph Droms wrote: > This stale information may be held in > resolver caches for as much as 1/3 of the original > lease length if the recommendations in the draft > are followed. > > So, am I on the right track so far? Yup. > If so, it would be helpful to know *why* this stale > information is not a problem. Might there be > situations in the future where this stale information > might be a problem? It's not not a problem. It just not a problem for which there is a solution, other than "keep the TTL significantly shorter than the lease time." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 17:17:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19049 for ; Wed, 2 Jul 2003 17:17:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xoty-0005iu-BG for namedroppers-data@psg.com; Wed, 02 Jul 2003 21:12:30 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Xotj-0005gM-33 for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 21:12:15 +0000 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 02 Jul 2003 14:08:22 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62LBb7F009416; Wed, 2 Jul 2003 14:11:38 -0700 (PDT) Received: from mjs-xp.cisco.com (che-vpn-cluster-1-55.cisco.com [10.86.240.55]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ75316; Wed, 2 Jul 2003 17:11:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702165733.01afe510@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 17:11:50 -0400 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] Re: DDNS-DHCP [5]: IDN in DDNS-DHCP docs Cc: dhcwg@ietf.org, namedroppers@ops.ietf.org, olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: <4.3.2.7.2.20030702130015.048b2f98@funnel.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue [5] just states that there was a wg that concluded. I'm not aware of any issues raised by that wg, based on my (admittedly limited) understanding of their work. rfc3490, sec 1.1 states that no changes or demands are made on DNS servers, and I think that the idn work involved the user-visible parts of applications, and techniques for rendering unicode into canonical dns encoding. Once something's in dns encoding, the existing dns rules apply to it. The dhcp/dns drafts only use dns encoding, excepting only the special description of the legacy behavior of older clients which might use the fqdn option. -- Mark At 01:01 PM 7/2/2003 -0400, Ralph Droms wrote: >There has been no discussion of this issue. We need >additional discussion on the mailing list to determine >WG consensus on the resolution of this issue. > >- Ralph > > >At 07:01 AM 6/6/2003 -0400, Ralph Droms wrote: > >>DDNS-DHCP issue: >> >> The IDN WG has concluded and the results of its work should be >> considered in the DDNS-DHCP documents. The changes may be as >> minimal as specifying the use of the IDN on-the-wire format. >> >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 17:22:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19669 for ; Wed, 2 Jul 2003 17:22:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xp07-00067u-IA for namedroppers-data@psg.com; Wed, 02 Jul 2003 21:18:51 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.14) id 19Xozx-00065M-Ot for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 21:18:41 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h62LHMKo028327; Wed, 2 Jul 2003 14:17:23 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h62LHHQ10146; Wed, 2 Jul 2003 23:17:17 +0200 (MEST) Date: Wed, 2 Jul 2003 23:12:41 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Re: DDNS-DHCP [5]: IDN in DDNS-DHCP docs To: Ralph Droms Cc: Ted Lemon , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20030702152118.048aedd0@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I think I read that draft-ietf-dhc-fqdn-option-05.txt > only refers to "DNS encoding as specified in RFC1035". > Is there a need for an additional reference, perhaps > to RFC 3490? Or is the internationalization transparent > to the FQDN option? It might make sense to add a note saying that Internationalized Domain Names are encoded using an ASCII compatible encoding as specified in RFC 3490. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 17:34:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20490 for ; Wed, 2 Jul 2003 17:34:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xp98-0006oy-38 for namedroppers-data@psg.com; Wed, 02 Jul 2003 21:28:10 +0000 Received: from [64.102.124.12] (helo=rtp-core-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Xp8u-0006lc-8J for namedroppers@ops.ietf.org; Wed, 02 Jul 2003 21:27:56 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h62LQhfq010867; Wed, 2 Jul 2003 17:26:43 -0400 (EDT) Received: from mjs-xp.cisco.com (che-vpn-cluster-1-55.cisco.com [10.86.240.55]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAJ76437; Wed, 2 Jul 2003 17:26:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702171556.01ac29d8@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 17:26:00 -0400 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] Re: DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: namedroppers@ops.ietf.org, dhcwg@ietf.org, olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: <4.3.2.7.2.20030702130459.048217f0@funnel.cisco.com> References: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There was a bit of consensus, I think. It's just that there isn't much that can be done by the updater, and so there isn't a great deal of change to be made. I posted a message about the discussion, and there was at least a bit of agreement that this was a reasonable summary of what should be done to clarify the issue in the draft: >1. the looseness of the coupling among primary, secondary, and caching dns >servers makes it unrealistic to guarantee that no query will see stale >records. the deployment experience that we have does not indicate that >this is a problem. > >2. this section of the draft should make the issues about dns ttls and >caching more explicit, so that it's clearer what the operational >consequences of 'stale' records might be. I'll add text about the benefits >to removing dhcp-added dns records when leases expire. > >3. the simple ttl guidelines that are in the draft are present to give >implementors (and administrators) some clue about reasonable ranges and >defaults. the guidelines are meant to help folks avoid hare-brained >configurations (what Robert calls "minimizing damage"); the guidelines >aren't intended to provide a guarantee about how long it may be before >changes to the dns become universally visible. > >4. it's not worthwhile to impose new requirements on DHCP servers to put >names or addresses in limbo in some way for some period of time after >leases expire. > >-- Mark -- Mark At 02:09 PM 7/2/2003 -0400, Ralph Droms wrote: >This issue generated much discussion, without any >clear consensus on what to do. > >You can review the discussion thread starting at >http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02092.html > >Please review the previous discussion and comment >to the mailing list... > >- Ralph > > >At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote: >>DDNS-DHCP issue: >> >> The RR TTLs need careful attention so that it never exceeds the >> expiration time of the lease on the associated address. > > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 2 22:22:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11092 for ; Wed, 2 Jul 2003 22:22:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xtcc-000LcS-QT for namedroppers-data@psg.com; Thu, 03 Jul 2003 02:14:54 +0000 Received: from [2001:470:1f00:820:208:74ff:fe9f:eeae] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.14) id 19Xtca-000Lbp-B6 for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 02:14:52 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h632EJ6A089854 for ; Thu, 3 Jul 2003 12:14:20 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200307030214.h632EJ6A089854@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: draft-stjohns-secure-notify-00.txt In-reply-to: Your message of "02 Jul 2003 09:10:40 GMT." <20030702091040.73961.qmail@cr.yp.to> Date: Thu, 03 Jul 2003 12:14:19 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If tiddlywinks.dom consists of a single machine running an HTTP server, > an SMTP server, and a DNS server, then demanding a second DNS server is > a really bad idea: it adds expense while decreasing reliability. See > http://cr.yp.to/djbdns/third-party.html. And not having a second nameserver puts the failure load on the caching nameserver (which is often a shared resource) verses on the end machine making the lookup (which is often a individual resource). In otherwords it is anti-social not to provide redundancy. -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 00:13:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14063 for ; Thu, 3 Jul 2003 00:12:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XvN9-0001EA-EI for namedroppers-data@psg.com; Thu, 03 Jul 2003 04:07:03 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.14) id 19XvN7-0001Dl-BQ for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 04:07:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7E2251397F for ; Thu, 3 Jul 2003 04:06:48 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt In-Reply-To: Message from Mark.Andrews@isc.org of "Thu, 03 Jul 2003 12:14:19 +1000." <200307030214.h632EJ6A089854@drugs.dv.isc.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 03 Jul 2003 04:06:48 +0000 Message-Id: <20030703040648.7E2251397F@sa.vix.com> X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In otherwords it is anti-social not to provide redundancy. twice in the last month hotbar.com's nameservers have gone off the air (at that time there were only two and both were on the same lan) and the resulting query load (evidently a lot of win32 clients using some kind of browser plugin) caused a multihour ~1Kqps spike on the root name servers. 1Kqps more or less doesn't exactly break anything, but i will echo marka's sentiments above: not providing redundancy is antisocial (and irresponsible, and unprofessional, and so on). (as to whether that redundancy ought to be expressed in the parent domain name of the NS RR targets or not, i'm still considering the proposal... it makes as much sense, on the face of it, as the recommendation that they be on different lans.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 07:05:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05942 for ; Thu, 3 Jul 2003 07:05:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y1nO-000It8-54 for namedroppers-data@psg.com; Thu, 03 Jul 2003 10:58:34 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19Y1nM-000Isw-1e for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 10:58:32 +0000 Received: (qmail 9434 invoked by uid 1016); 3 Jul 2003 10:59:02 -0000 Date: 3 Jul 2003 10:59:02 -0000 Message-ID: <20030703105902.9433.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt References: <20030702091040.73961.qmail@cr.yp.to> <89557.1057149540@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: > So what? These clueless parent activities cause interoperability failures. For example, when the clueless .fr administrators refuse to delegate domains to servers that don't know the root server addresses, they are breaking the recommended configuration of non-caching non-root servers. Vixie has admitted that those servers shouldn't have to know the root addresses. Perhaps you're happy with some of these clueless parent activities because they favor your software---but the IETF is _not_ supposed to require or encourage this sort of behavior. See RFC 2119, section 6. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 07:05:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05960 for ; Thu, 3 Jul 2003 07:05:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y1qN-000J36-Cr for namedroppers-data@psg.com; Thu, 03 Jul 2003 11:01:39 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19Y1qK-000J2q-Te for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 11:01:36 +0000 Received: (qmail 10588 invoked by uid 1016); 3 Jul 2003 11:02:09 -0000 Date: 3 Jul 2003 11:02:09 -0000 Message-ID: <20030703110209.10587.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: third-party servers References: <20030702091040.73961.qmail@cr.yp.to> <89557.1057149540@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: > I suspect that cr.yp.to consists of not much more than an HTTP server, > an SMTP server and a DNS server. Yet this zone has two NS records. The cr.yp.to web and mail services are spread across several machines in my office, so the DNS services are too. For a while, all the services were on one machine, and there was only one DNS server. Either way, this is a good example of RFC 2182 being incorrect. Like the administrators of AOL, Harvard, CERT, et al., I have all my DNS servers on my own network. Moving them to third-party networks would _not_ be a good idea. > > If tiddlywinks.dom consists of a single machine running an > > HTTP server, an SMTP server, and a DNS server, then demanding > > a second DNS server is a really bad idea: it adds expense > > while decreasing reliability. > This is utter nonsense and you should know better. http://cr.yp.to/djbdns/third-party.html analyzes the costs and benefits in detail, and explains exactly why RFC 2182 is incorrect. Have you read the analysis? Is there some point that you don't understand? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 07:20:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06391 for ; Thu, 3 Jul 2003 07:20:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y23a-000JrF-Lm for namedroppers-data@psg.com; Thu, 03 Jul 2003 11:15:18 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19Y23Y-000Jqx-C8 for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 11:15:16 +0000 Received: (qmail 15505 invoked by uid 1016); 3 Jul 2003 11:15:48 -0000 Date: 3 Jul 2003 11:15:48 -0000 Message-ID: <20030703111548.15504.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: client bugs and root-server load References: <200307030214.h632EJ6A089854@drugs.dv.isc.org> <20030703040648.7E2251397F@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > twice in the last month hotbar.com's nameservers have gone off the > air (at that time there were only two and both were on the same lan) > and the resulting query load (evidently a lot of win32 clients using > some kind of browser plugin) caused a multihour ~1Kqps spike on the > root name servers. More details, please. How exactly were these clients generating extra load on the root servers? Do you also demand that every DNS server accept dynamic updates so that clueless Microsoft clients don't send updates to the root servers? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 07:44:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07417 for ; Thu, 3 Jul 2003 07:44:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y2Se-000LCm-Ug for namedroppers-data@psg.com; Thu, 03 Jul 2003 11:41:12 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19Y2Sc-000LCU-KY for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 11:41:10 +0000 Received: (qmail 25627 invoked by uid 1016); 3 Jul 2003 11:40:59 -0000 Date: 3 Jul 2003 11:40:59 -0000 Message-ID: <20030703114059.25626.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: third-party servers: DNS load, HTTP load, etc. References: <20030702091040.73961.qmail@cr.yp.to> <200307030214.h632EJ6A089854@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > And not having a second nameserver puts the failure load > on the caching nameserver (which is often a shared resource) > verses on the end machine making the lookup (which is often > a individual resource). ``Having a second nameserver puts the failure load on the web client, which is often a shared resource---a proxy like Squid. An HTTP failure consumes more resources than a DNS failure.'' There are actually six separate load issues, all of which are discussed in http://cr.yp.to/djbdns/third-party.html. None of them matter for the vast majority of sites. I notice that you aren't screaming ``Every web site on the Internet needs third-party HTTP servers!'' If you care so much about DNS load, why don't you encourage in-bailiwick server names, and why don't you tell RIPE and ARIN to start allowing glue? Gluelessness is a much larger source of load than server outages. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 07:51:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07522 for ; Thu, 3 Jul 2003 07:51:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y2Zj-000Les-Vw for namedroppers-data@psg.com; Thu, 03 Jul 2003 11:48:31 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19Y2ZU-000LeA-88 for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 11:48:16 +0000 From: Masataka Ohta Message-Id: <200307031125.UAA19664@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA19664; Thu, 3 Jul 2003 20:25:15 +0900 Subject: Re: DDNS-DHCP [5]: IDN in DDNS-DHCP docs In-Reply-To: <200307021916.41653.mellon@nominum.com> from Ted Lemon at "Jul 2, 2003 07:16:41 pm" To: Ted Lemon Date: Thu, 3 Jul 2003 20:25:15 +0859 () CC: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.7 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ted; > > At 07:01 AM 6/6/2003 -0400, Ralph Droms wrote: > > >DDNS-DHCP issue: > > > > > > The IDN WG has concluded and the results of its work should be > > > considered in the DDNS-DHCP documents. The changes may be as > > > minimal as specifying the use of the IDN on-the-wire format. > > I think the reason for the lack of discussion is that this is a non-issue - > the reason we went to using the DNS wire format was to avoid having to deal > with this issue later. Right! It is merely that IDN is hopeless, primarily because Unicode is hopeless. As has been proven for these 10 years, that Microsoft and other commercial entities are insisting on Unicode does not make it hopeful. > I think that if the IDN folks think there is a > problem here, they should say what it is and propose a solution. I don't > think there is a problem. The problem of them is that they must admit Unicode is hopeless and propose a solution to abandan it, which will take time of yet another few decades. Unless you want to waste the decades, just ignore IDN. Masataka Ohta PS IPv6 is hopeless too, which is why IPv6 folks is trying to push their problems to other WGs, which is why interaction between IPv6 and DNS is obscure. But, it should be admitted that IPv6 is a lot better than Unicode, especially after multihoming issues are solved end to end. PPS DHCP is the right way to go for any kind of autoconfiguration. It properly recognized roles of routers. On the other hand, half hearted attempt of stateless autoconfiguration of Neighbor Discovery is hopeless, because it expects too much on routers as the intermediate intelligent entities. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 08:01:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07805 for ; Thu, 3 Jul 2003 08:01:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y2jF-000MJL-DF for namedroppers-data@psg.com; Thu, 03 Jul 2003 11:58:21 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19Y2jC-000MJ4-U1 for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 11:58:19 +0000 From: Masataka Ohta Message-Id: <200307031146.UAA19811@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA19811; Thu, 3 Jul 2003 20:46:22 +0900 Subject: Re: third-party servers In-Reply-To: <20030703110209.10587.qmail@cr.yp.to> from "D. J. Bernstein" at "Jul 3, 2003 11:02:09 am" To: "D. J. Bernstein" Date: Thu, 3 Jul 2003 20:46:21 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DJB; > Jim Reid writes: > > I suspect that cr.yp.to consists of not much more than an HTTP server, > > an SMTP server and a DNS server. Yet this zone has two NS records. > > The cr.yp.to web and mail services are spread across several machines in > my office, so the DNS services are too. For a while, all the services > were on one machine, and there was only one DNS server. > > Either way, this is a good example of RFC 2182 being incorrect. Like the > administrators of AOL, Harvard, CERT, et al., I have all my DNS servers > on my own network. Moving them to third-party networks would _not_ be a > good idea. Well, the fundamental problem is not in RFC2182. The fundamental probelm is that DNS is a (luckily enough, not so intelligent) intermediate entity, violating the end to end princple. As such, moving them to third-party WGs is not a solution. As DNS does not follow the principle, it is valunerable to problems of lack of robustness and efficiency, which is common to protocols ignoring the principle. Anycast root servers can help the situation unless the needs on DNS is not so demanding. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 08:45:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08977 for ; Thu, 3 Jul 2003 08:45:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y3OP-000OKl-UR for namedroppers-data@psg.com; Thu, 03 Jul 2003 12:40:53 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Y3OL-000OJm-U9 for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 12:40:49 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h63CeG7F005620; Thu, 3 Jul 2003 05:40:16 -0700 (PDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-313.cisco.com [10.82.225.57]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAK07837; Thu, 3 Jul 2003 08:40:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20030703064811.00bbd280@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Jul 2003 08:40:09 -0400 To: Mark Stapp From: Ralph Droms Subject: Re: [dhcwg] Re: DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: namedroppers@ops.ietf.org, dhcwg@ietf.org, olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: <4.3.2.7.2.20030702171556.01ac29d8@goblet.cisco.com> References: <4.3.2.7.2.20030702130459.048217f0@funnel.cisco.com> <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark, I checked through the dhcwg archive, and I found one response that was mostly in agreement with your summary (http://ietf.org/mail-archive/working-groups/dhcwg/current/msg02102.html). We need some more responses to declare "consensus"... I have a couple of specific comments about your summary (in-line). We might want to discuss whether the DDNS TTL issues are specific to DDNS-DHCP interactions? If not, perhaps those issues should be broken out to a separate document... - Ralph At 05:26 PM 7/2/2003 -0400, Mark Stapp wrote: >There was a bit of consensus, I think. It's just that there isn't much >that can be done by the updater, and so there isn't a great deal of change >to be made. > >I posted a message about the discussion, and there was at least a bit of >agreement that this was a reasonable summary of what should be done to >clarify the issue in the draft: > > >>1. the looseness of the coupling among primary, secondary, and caching >>dns servers makes it unrealistic to guarantee that no query will see >>stale records. the deployment experience that we have does not indicate >>that this is a problem. I agree with the first sentence. Basing the specification on deployment experience is useful. To provide appropriate background for future readers who try to implement DDNS-DHCP interaction, the basis for this sentence from draft-ietf-dhc-ddns-resolution-05.txt: The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed 1/3 of the lease time, and SHOULD be at least 10 minutes. should be explained. If I were making decisions about deploying DDNS updates, I would want to know that these numbers came from operational experience, and it would help to get whatever insights might be available into why the stale DNS information hasn't been a problem in practice. I'm thinking specifically that, for example, the document might include text based on this exchange from the mailing list: | Another observation - is it possible that the issue of | stale cached DNS information has never been an issue | in practice because DNS information installed by a DHCP | server is rarely used, so that stale DNS information | is insignificant? Most likely, yes. If 't' isn't set very large (which for dynamically assigned addresses it should not be) and the DNS servers communicate with each other properly, the only effect is that someone attempting to contact the host with the dynamic address, by name, might fail for a while after a new assignment has been made. Most hosts with dynamic addresses aren't contacted by name anyway. >>2. this section of the draft should make the issues about dns ttls and >>caching more explicit, so that it's clearer what the operational >>consequences of 'stale' records might be. I'll add text about the >>benefits to removing dhcp-added dns records when leases expire. Does the first sentence include the potential problems from stale DNS information resulting from the recommended TTLs even if the DHCP-added DNS records are promptly removed? kre wrote: | That is, the important problem to avoid is cached DNS | information about an address that has been assigned | to a different host. Maybe there's something missing here, but I don't understand why this is supposed to be an important problem. That is, reworded, to make sure my understanding is correct, the problem to be avoided is having a name referring to an address that is now to be assigned to a different name ? Who cares? I mean, it is nice to have everything cleaned up, but there's nothing that can be done that can possibly guarantee that there isn't another name around referring to a particular address (there's no practical way to locate one - that would require IQUERY which we don't have...) The problem that you want to avoid, is having an old address still associated with the name to which a new address is being assigned. That's because it starts to be a gamble which address you will get when the name is looked up (depending upon which server happens to respond, and which cache contains what information). If we have consensus that this example of stale information truly isn't a problem, Also, if I were thinking about this issue for the first time, it would occur to me that the problem could be mitigated by: * reducing the TTL prior to the expiration of the lease * setting the TTL to something much shorter than 1/3 of the original lease (perhaps even 0), if I expect few queries to the dynamically updated name I understand it's difficult to anticipate every possible idea (hare-brained or otherwise) that someone might dream up. Seems to me it would be a good idea to write down what we can to give guidance in the future... >>3. the simple ttl guidelines that are in the draft are present to give >>implementors (and administrators) some clue about reasonable ranges and >>defaults. the guidelines are meant to help folks avoid hare-brained >>configurations (what Robert calls "minimizing damage"); the guidelines >>aren't intended to provide a guarantee about how long it may be before >>changes to the dns become universally visible. It would help future readers a lot, I think, to give more explanation about why these ranges and defaults were selected and how they minimize damage. Otherwise, the experience and wisdom that went into these recommendations will be lost... >>4. it's not worthwhile to impose new requirements on DHCP servers to put >>names or addresses in limbo in some way for some period of time after >>leases expire. OK. >>-- Mark > >-- Mark > >At 02:09 PM 7/2/2003 -0400, Ralph Droms wrote: >>This issue generated much discussion, without any >>clear consensus on what to do. >> >>You can review the discussion thread starting at >>http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02092.html >> >>Please review the previous discussion and comment >>to the mailing list... >> >>- Ralph >> >> >>At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote: >>>DDNS-DHCP issue: >>> >>> The RR TTLs need careful attention so that it never exceeds the >>> expiration time of the lease on the associated address. >> >> >> >> >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 09:01:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09418 for ; Thu, 3 Jul 2003 09:01:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y3em-000PKG-Nd for namedroppers-data@psg.com; Thu, 03 Jul 2003 12:57:48 +0000 Received: from [216.168.239.87] (helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 4.14) id 19Y3ek-000PJM-2O for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 12:57:46 +0000 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id 4E9C59BE21; Thu, 3 Jul 2003 08:57:15 -0400 (EDT) Date: Thu, 3 Jul 2003 08:57:15 -0400 From: Matt Larson To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: client bugs and root-server load Message-ID: <20030703125715.GA14480@chinook.rgy.netsol.com> References: <200307030214.h632EJ6A089854@drugs.dv.isc.org> <20030703040648.7E2251397F@sa.vix.com> <20030703111548.15504.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20030703111548.15504.qmail@cr.yp.to> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Thu, 03 Jul 2003, D. J. Bernstein wrote: > Paul Vixie writes: > > twice in the last month hotbar.com's nameservers have gone off the > > air (at that time there were only two and both were on the same lan) > > and the resulting query load (evidently a lot of win32 clients using > > some kind of browser plugin) caused a multihour ~1Kqps spike on the > > root name servers. >=20 > More details, please. How exactly were these clients generating extra > load on the root servers? Paul may have something else in mind when he mentions browser plug-ins, but the culprit is also Microsoft's name server shipped with NT and 2000. If, when performing a lookup, it cannot get a response =66rom any of a zone's authoritative servers (because of lameness, non-responsiveness--whatever), it queries that zone's parent for a fresh copy of its child's NS RRset. I suppose the reasoning is that the NS RRset in its cache could be out of date, so why not fetch the latest information? While well-intentioned, in practice this recovery technique can backfire and pound the parent zone's servers. We see this all the time when a popular com or net zone drops completely off the net. For more thoughts on this topic, see Section 2.1 of http://www.ietf.org/internet-drafts/draft-ietf-dnsop-bad-dns-res-01.txt. > Do you also demand that every DNS server accept dynamic updates so that > clueless Microsoft clients don't send updates to the root servers? All the carefully reasoned web pages in the world about how things ought to behave will not change the fact that the real world is a messy place. While we can strive for perfection, we have to accommodate reality. And in my world, multiple distributed authoritative servers per zone make things run more smoothly. We are straying into operational territory and should move this discussion to dnsop@cafax.se. Matt -- Matt Larson VeriSign Naming and Directory Services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 10:53:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14227 for ; Thu, 3 Jul 2003 10:53:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y5NU-0004Qt-Lb for namedroppers-data@psg.com; Thu, 03 Jul 2003 14:48:04 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.14) id 19Y5NS-0004Q3-JY for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 14:48:02 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h63ElNKo007619; Thu, 3 Jul 2003 07:47:24 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h63ElNQ28454; Thu, 3 Jul 2003 16:47:23 +0200 (MEST) Date: Thu, 3 Jul 2003 16:46:43 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: ad-is-secure To: namedroppers@ops.ietf.org Cc: ogud@ogud.com, olaf@ripe.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Time to try to get this document unstuck from an unresponsive AD (myself)... I'll put this document on the IESG agenda for next week. AFAICT the changes from 05 to 06 should address the concerns, but there are IESG members that were not around when this was first discussed by the IESG more than a year ago so there might be some additional concerns. Folks (Roy Arends, Steve Bellovin, and Rob Austein) have suggested some additional clarifications on 06 (and I thank them for there additional review) included below. Does anybody think that these clarifications are incorrect please speak now. Best possible case we can get this approved with an rfc-editor note by next week. Erik --- Before the last paragraph in section 4 add this paragraph: In the latter two cases, the end consumer must also trust the path to the trusted resolvers. Add this paragraph to the end of section 2.2: Note that having the AD bit clear on an authoritative answer is normal and expected behavior. The draft also has an odd "MUST" in section 2.2.1: Organisations that require that all DNS responses contain cryptographically verified data MUST separate the functions of authoritative and recursive servers, as authoritative servers are not required to validate local secure data. This introduces a new concept "local secure data", w/o defining it. Replace that paragraph with: Organisations which require that all DNS responses contain cryptographically verified data will need to separate the authoritative name server and signature verification functions, since name servers are not required to validate signatures of data for which they are authoritative. --- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 11:08:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14899 for ; Thu, 3 Jul 2003 11:08:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y5ef-0005a2-Fz for namedroppers-data@psg.com; Thu, 03 Jul 2003 15:05:49 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19Y5ed-0005Zh-2i for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 15:05:47 +0000 Received: (qmail 45930 invoked by uid 1016); 3 Jul 2003 15:06:18 -0000 Date: 3 Jul 2003 15:06:18 -0000 Message-ID: <20030703150618.45929.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: client bugs and root-server load References: <200307030214.h632EJ6A089854@drugs.dv.isc.org> <20030703040648.7E2251397F@sa.vix.com> <20030703111548.15504.qmail@cr.yp.to> <20030703125715.GA14480@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Matt Larson writes: > the culprit is also Microsoft's name server shipped with > NT and 2000. If, when performing a lookup, it cannot get a response > from any of a zone's authoritative servers (because of lameness, > non-responsiveness--whatever), it queries that zone's parent for a > fresh copy of its child's NS RRset Suppose there's a major network cut---for example, Japan losing its connectivity to the rest of the Internet. Every time one of those Microsoft programs in Japan tries to look up a site outside Japan, it will end up pestering a high-level server, such as the Japan root server. Right? If this ends up taking down the high-level server, do you blame (1) Microsoft's unusual query strategy, or (2) millions of sites that haven't bought Japanese DNS service? When you say ``NT and 2000,'' are you deliberately excluding more recent releases of Windows? Has Microsoft changed its query strategy now? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago P.S. The query strategy is a protocol issue, and should be discussed on namedroppers. Your dnsop-bad-dns-res document is misdirected. P.P.S. Your document fails to provide verifiable software information. It doesn't even contain the word ``Microsoft.'' -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 18:44:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16045 for ; Thu, 3 Jul 2003 18:44:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19YCgm-0000sz-5c for namedroppers-data@psg.com; Thu, 03 Jul 2003 22:36:28 +0000 Received: from [2001:470:1f00:820:208:74ff:fe9f:eeae] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.14) id 19YCgi-0000pM-Ek for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 22:36:24 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h63MZM6A092200; Fri, 4 Jul 2003 08:35:22 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200307032235.h63MZM6A092200@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: third-party servers: DNS load, HTTP load, etc. In-reply-to: Your message of "03 Jul 2003 11:40:59 GMT." <20030703114059.25626.qmail@cr.yp.to> Date: Fri, 04 Jul 2003 08:35:22 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > And not having a second nameserver puts the failure load > > on the caching nameserver (which is often a shared resource) > > verses on the end machine making the lookup (which is often > > a individual resource). > > ``Having a second nameserver puts the failure load on the web client, > which is often a shared resource---a proxy like Squid. An HTTP failure > consumes more resources than a DNS failure.'' > > There are actually six separate load issues, all of which are discussed > in http://cr.yp.to/djbdns/third-party.html. None of them matter for the > vast majority of sites. I notice that you aren't screaming ``Every web > site on the Internet needs third-party HTTP servers!'' Replicating a HTTP server is generally a much harder process than providing getting secondary DNS service. If your HTTP service is read-only it is much easier to do. The fact that HTTP supports active components makes it a difficult service to replicate. Lack of support for SRV records also makes it a difficult service to replicate. Having a redundant DNS service allows you to make use of redundant mail servers which will reduce the load on the clients as they usually do have dead server detection. Are you going to say that backup mail exchangers are a bad thing as well? > If you care so much about DNS load, why don't you encourage in-bailiwick > server names, and why don't you tell RIPE and ARIN to start allowing > glue? Gluelessness is a much larger source of load than server outages. I encourage nameservers to serve the zones they live in. One level of indirection is not bad. > ---D. J. Bernstein, Associate Professor, Department of Mathematics, > Statistics, and Computer Science, University of Illinois at Chicago > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 3 19:32:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25918 for ; Thu, 3 Jul 2003 19:32:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19YDVo-0003ba-Qz for namedroppers-data@psg.com; Thu, 03 Jul 2003 23:29:12 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19YDVm-0003bO-8B for namedroppers@ops.ietf.org; Thu, 03 Jul 2003 23:29:10 +0000 Received: (qmail 82527 invoked by uid 1016); 3 Jul 2003 23:29:41 -0000 Date: 3 Jul 2003 23:29:41 -0000 Message-ID: <20030703232941.82526.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: third-party servers: DNS load, HTTP load, etc. References: <20030703114059.25626.qmail@cr.yp.to> <200307032235.h63MZM6A092200@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > Are you going to say that backup mail exchangers are a bad thing as well? Third-party mail exchangers are even less useful than third-party HTTP servers. Sure, a few sites have them (in which case they should have DNS servers spread just as widely), but most sites shouldn't and don't. > The fact that HTTP supports active components makes it a difficult > service to replicate. Let me get this straight. You're saying that replication is terribly important, but that the importance suddenly disappears when you're too lazy to find a third party with the right web-serving software? Some of us have DNS software that supports ``active components,'' by the way: load balancing, scheduled record creation, etc. Your own DNS server supports client differentiation that you fail to replicate correctly. [ ARIN/RIPE gluelessness ] > One level of indirection is not bad. We're talking about gluelessness on every reverse lookup. Have you ever studied your logs? How can you possibly claim to care about the load from the occasional server outage when you clearly don't care about the much larger load caused by gluelessness? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 4 08:18:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24570 for ; Fri, 4 Jul 2003 08:18:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19YPPO-000Gyx-3i for namedroppers-data@psg.com; Fri, 04 Jul 2003 12:11:22 +0000 Received: from [192.134.4.152] (helo=maya20.nic.fr) by psg.com with esmtp (Exim 4.14) id 19YPPL-000Gyf-7j for namedroppers@ops.ietf.org; Fri, 04 Jul 2003 12:11:19 +0000 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h64CBEu91487237; Fri, 4 Jul 2003 14:11:14 +0200 (CEST) Received: by vespucci.nic.fr (Postfix, from userid 1055) id 00FDE11145; Fri, 4 Jul 2003 14:11:13 +0200 (CEST) Date: Fri, 4 Jul 2003 14:11:13 +0200 From: Stephane Bortzmeyer To: Masataka Ohta Cc: namedroppers@ops.ietf.org Subject: [OT] IDN future (Was: DDNS-DHCP [5]: IDN in DDNS-DHCP docs Message-ID: <20030704121113.GA10591@nic.fr> References: <200307021916.41653.mellon@nominum.com> <200307031125.UAA19664@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307031125.UAA19664@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.3.28i X-Operating-System: Debian GNU/Linux 3.0 X-Kernel: Linux 2.4.18-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Warning: probably off-topic] On Thu, Jul 03, 2003 at 08:25:15PM +0859, Masataka Ohta wrote a message of 52 lines which said: > The problem of them is that they must admit Unicode is hopeless and > propose a solution to abandan it, Yes, what is the alternative to Unicode? (Except switching to English and US-ASCII.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 4 09:01:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25191 for ; Fri, 4 Jul 2003 09:01:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19YQ8y-000Jg1-KH for namedroppers-data@psg.com; Fri, 04 Jul 2003 12:58:28 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19YQ8v-000Jdw-R5 for namedroppers@ops.ietf.org; Fri, 04 Jul 2003 12:58:26 +0000 From: Masataka Ohta Message-Id: <200307041246.VAA25793@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA25793; Fri, 4 Jul 2003 21:46:39 +0900 Subject: Re: [OT] IDN future (Was: DDNS-DHCP [5]: IDN in DDNS-DHCP docs In-Reply-To: <20030704121113.GA10591@nic.fr> from Stephane Bortzmeyer at "Jul 4, 2003 02:11:13 pm" To: Stephane Bortzmeyer Date: Fri, 4 Jul 2003 21:46:37 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Stephane; > Masataka Ohta wrote > a message of 52 lines which said: > > > The problem of them is that they must admit Unicode is hopeless and > > propose a solution to abandan it, > > Yes, what is the alternative to Unicode? (Except switching to English > and US-ASCII.) As a Japanese using Japanese characters daily over the Internet, ASCII only communication is no solution. The solution, of course, has been ISO 2022. See RFC 1554 for details on how efficient and stateless it can be. A sad history was that there was a wrong argument that state maintenance of ISO 2022 were complex. The reality is that it is simple switching treated by finite state automaton. It should now be easily recognized that, given the complex state transition of Unicode, which essentially needs push down automaton, you can't say state transition of ISO 2022 complex, Moreover, it has been well known that state transition of ISO 2022 can be simplified a lot to be almost stateless as is documented in RFC1468 in 1993. Note that, in Japan, Unicode is not used at all and ISO 2022 and Shift JIS (a skewed ISO 2022) are the encoding. Situation is not so different in Europe and ISO 8859/1. See RFC 1815 on poor performance of Unicode. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 4 09:35:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25811 for ; Fri, 4 Jul 2003 09:35:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19YQdq-000LQ6-0Z for namedroppers-data@psg.com; Fri, 04 Jul 2003 13:30:22 +0000 Received: from [216.220.241.233] (helo=nic-naa.net) by psg.com with esmtp (Exim 4.14) id 19YQdm-000LPj-MG for namedroppers@ops.ietf.org; Fri, 04 Jul 2003 13:30:18 +0000 Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h64DTZmu000797; Fri, 4 Jul 2003 09:29:35 -0400 (EDT) Message-Id: <200307041329.h64DTZmu000797@nic-naa.net> To: Masataka Ohta cc: Stephane Bortzmeyer , namedroppers@ops.ietf.org, brunner@nic-naa.net Subject: Re: [OT] IDN future (Was: DDNS-DHCP [5]: IDN in DDNS-DHCP docs In-Reply-To: Your message of "Fri, 04 Jul 2003 21:46:37 +0859." <200307041246.VAA25793@necom830.hpcl.titech.ac.jp> Date: Fri, 04 Jul 2003 09:29:35 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Masataka San, The comments of the CDNC and JET to the IETF circa London and Salt Lake are to the same point. Eric -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 6 07:00:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11293 for ; Sun, 6 Jul 2003 07:00:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Z786-000CE3-Nd for namedroppers-data@psg.com; Sun, 06 Jul 2003 10:52:26 +0000 Received: from [202.11.16.196] (helo=mx4.jprs.co.jp) by psg.com with esmtp (Exim 4.14) id 19Z784-000CDY-23 for namedroppers@ops.ietf.org; Sun, 06 Jul 2003 10:52:24 +0000 Received: from msgmgr.jprs.co.jp (msgmgr.jprs.co.jp [202.11.17.19]) by mx4.jprs.co.jp (8.12.9/8.12.9) with ESMTP id h66ApP45019925; Sun, 6 Jul 2003 19:51:25 +0900 (JST) Received: from tr-alias.jprs.co.jp (tr-alias.jprs.co.jp [192.168.102.1]) by msgmgr.jprs.co.jp (8.11.6/8.11.6) with ESMTP id h66ApOD22159; Sun, 6 Jul 2003 19:51:24 +0900 Received: from ssh-tunnel (island1.jprs.co.jp [202.11.16.62]) by tr-alias.jprs.co.jp (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AKD02556; Sun, 6 Jul 2003 19:51:22 +0900 (JST) Date: Sun, 06 Jul 2003 19:51:22 +0900 (JST) Message-Id: <20030706.195122.91281806.yasuhiro@jprs.co.jp> To: djb@cr.yp.to Cc: namedroppers@ops.ietf.org Subject: Re: third-party servers: DNS load, HTTP load, etc. From: Yasuhiro Orange Morishita / =?iso-2022-jp?B?GyRCPzkyPEJZOSgbKEI=?= In-Reply-To: <20030703114059.25626.qmail@cr.yp.to> References: <20030702091040.73961.qmail@cr.yp.to> <200307030214.h632EJ6A089854@drugs.dv.isc.org> <20030703114059.25626.qmail@cr.yp.to> Organization: Japan Registry Service Co.,Ltd. (JPRS) X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-21.0 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit DJB wrote: > If you care so much about DNS load, why don't you encourage in-bailiwick > server names, and why don't you tell RIPE and ARIN to start allowing > glue? Gluelessness is a much larger source of load than server outages. I found in-bailiwick servers on database of RIPE NCC, as follows. So, I think we can use in-bailiwick name on IP address block of RIPE NCC. -- Yasuhiro 'Orange' Morishita DNS Technical Engineer Research and Development department, Japan Registry Service Co.,Ltd. (JPRS) E-Mail: yasuhiro@jprs.co.jp / orange@jprs.co.jp % dnsq ns 4.4.e164.arpa. ns.ripe.net 2 4.4.e164.arpa: 133 bytes, 1+0+3+3 records, response, noerror query: 2 4.4.e164.arpa authority: 4.4.e164.arpa 14400 NS ns1.4.4.e164.arpa authority: 4.4.e164.arpa 14400 NS ns2.4.4.e164.arpa authority: 4.4.e164.arpa 14400 NS ns3.4.4.e164.arpa additional: ns1.4.4.e164.arpa 14400 A 208.184.60.4 additional: ns2.4.4.e164.arpa 14400 A 81.200.68.218 additional: ns3.4.4.e164.arpa 14400 A 81.200.66.29 % whois -h whois.ripe.net 4.4.e164.arpa % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html domain: 4.4.e164.arpa descr: Domain for UK ENUM trial admin-c: ALTH-RIPE tech-c: JIRE-RIPE zone-c: JIRE-RIPE nserver: ns1.4.4.e164.arpa nserver: ns2.4.4.e164.arpa mnt-by: UK-ENUM-MNT changed: hostmaster@ripe.net 20020521 source: RIPE (snip) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 6 09:22:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12682 for ; Sun, 6 Jul 2003 09:22:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Z9Hu-000HVe-EJ for namedroppers-data@psg.com; Sun, 06 Jul 2003 13:10:42 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19Z9Hs-000HVQ-9P for namedroppers@ops.ietf.org; Sun, 06 Jul 2003 13:10:40 +0000 Received: (qmail 64973 invoked by uid 1016); 6 Jul 2003 13:11:10 -0000 Date: 6 Jul 2003 13:11:10 -0000 Message-ID: <20030706131110.64972.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: third-party servers: DNS load, HTTP load, etc. References: <20030702091040.73961.qmail@cr.yp.to> <200307030214.h632EJ6A089854@drugs.dv.isc.org> <20030703114059.25626.qmail@cr.yp.to> <20030706.195122.91281806.yasuhiro@jprs.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At last report, RIPE was continuing to reject glued delegations inside in-addr.arpa. They claimed that a glued delegation would be a ``loop.'' That's what's forcing the extra load that I'm talking about. > authority: 4.4.e164.arpa 14400 NS ns1.4.4.e164.arpa It's always nice to see glue. However, that domain is an internal RIPE experiment; it has no relevance to the RIPE in-addr.arpa registration policy. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 6 09:51:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13064 for ; Sun, 6 Jul 2003 09:51:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Z9sm-000Iuw-Bd for namedroppers-data@psg.com; Sun, 06 Jul 2003 13:48:48 +0000 Received: from [128.177.192.160] (helo=shell.nominum.com) by psg.com with esmtp (Exim 4.14) id 19Z9sk-000Iue-8Q for namedroppers@ops.ietf.org; Sun, 06 Jul 2003 13:48:46 +0000 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 2BF5A137F0E; Sun, 6 Jul 2003 06:48:33 -0700 (PDT) To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org Subject: Re: third-party servers: DNS load, HTTP load, etc. In-Reply-To: Message from "D. J. Bernstein" of "06 Jul 2003 13:11:10 -0000." <20030706131110.64972.qmail@cr.yp.to> Date: Sun, 06 Jul 2003 06:48:33 -0700 Message-ID: <85988.1057499313@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "djb" == D J Bernstein writes: >> authority: 4.4.e164.arpa 14400 NS ns1.4.4.e164.arpa djb> It's always nice to see glue. However, that domain is an djb> internal RIPE experiment; No it's not. You simply don't have the faintest clue what you're talking about. I registered 4.4.e164.arpa on behalf of the UK government for the national ENUM trial which is co-ordinated by the UK ENUM Group, UKEG. The delegation is not an experiment by anyone. And certainly not by RIPE NCC. djb> it has no relevance to the RIPE in-addr.arpa registration That's wrong too. The template and procedure used by RIPE NCC for handling ENUM delegations is identical to that for delegations in their part of the in-addr.arpa tree. BTW, there is a big difference between RIPE NCC and RIPE, a distinction that appears to have eluded you. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 6 10:55:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15271 for ; Sun, 6 Jul 2003 10:55:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZArt-000LXl-Rp for namedroppers-data@psg.com; Sun, 06 Jul 2003 14:51:57 +0000 Received: from [202.27.17.100] (helo=sentosa.post1.com) by psg.com with smtp (Exim 4.14) id 19ZArq-000LVW-2u for namedroppers@ops.ietf.org; Sun, 06 Jul 2003 14:51:54 +0000 Received: (qmail 34849 invoked from network); 6 Jul 2003 14:57:28 -0000 Received: from bb-203-125-7-219.singnet.com.sg (HELO pobox.org.sg) (203.125.7.219) by sentosa.post1.com with SMTP; 6 Jul 2003 14:57:28 -0000 Message-ID: <3F083780.7090107@pobox.org.sg> Date: Sun, 06 Jul 2003 22:51:44 +0800 From: James Seng User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko MIME-Version: 1.0 To: Eric Brunner-Williams in Portland Maine CC: Masataka Ohta , Stephane Bortzmeyer , namedroppers@ops.ietf.org Subject: Re: [OT] IDN future (Was: DDNS-DHCP [5]: IDN in DDNS-DHCP docs References: <200307041329.h64DTZmu000797@nic-naa.net> In-Reply-To: <200307041329.h64DTZmu000797@nic-naa.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-37.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I dont remember similar statement from JET made to IETF similar to what Masataka-san made. I mean, considering I am also a member of JET and you are not, one of us obviously have a memory gap. -James Seng Eric Brunner-Williams in Portland Maine wrote: > Masataka San, > > The comments of the CDNC and JET to the IETF circa London and Salt Lake > are to the same point. > > Eric > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 6 11:23:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15669 for ; Sun, 6 Jul 2003 11:23:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZBHo-000MgF-BM for namedroppers-data@psg.com; Sun, 06 Jul 2003 15:18:44 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19ZBHm-000Mg3-4A for namedroppers@ops.ietf.org; Sun, 06 Jul 2003 15:18:42 +0000 Received: (qmail 8707 invoked by uid 1016); 6 Jul 2003 15:19:14 -0000 Date: 6 Jul 2003 15:19:14 -0000 Message-ID: <20030706151914.8706.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: third-party servers: DNS load, HTTP load, etc. References: <20030706131110.64972.qmail@cr.yp.to> <85988.1057499313@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_10,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim, how exactly do you claim that European users can register glue for their (big, direct from RIPE) in-addr.arpa delegations? http://www.ripe.net/reverse/howtoreverse.html specifically states ``IP address not allowed here'' for the ``nserver'' part of an in-addr.arpa delegation request. There's no other line allowing a server IP address. You claim that e164.arpa and in-addr.arpa have ``identical'' procedures. Evidently you are claiming that, since e164.arpa allows IP addresses on the nserver line, in-addr.arpa must also allow them; in short, that the RIPE web page is wrong. Do you have any evidence to back up this claim? Of course, even if RIPE and ARIN do fix their procedures someday to _allow_ glue, the considerable extra load from reverse lookups will continue until most people _use_ glue. If your company truly cares about DNS load, why is it encouraging people to set up glueless delegations? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 6 20:46:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26886 for ; Sun, 6 Jul 2003 20:46:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZK1v-000Jlo-8X for namedroppers-data@psg.com; Mon, 07 Jul 2003 00:38:55 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19ZK1P-000JlO-GF for namedroppers@ops.ietf.org; Mon, 07 Jul 2003 00:38:23 +0000 From: Masataka Ohta Message-Id: <200307070029.JAA26000@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA26000; Mon, 7 Jul 2003 09:29:00 +0900 Subject: Re: third-party servers: DNS load, HTTP load, etc. In-Reply-To: <20030706151914.8706.qmail@cr.yp.to> from "D. J. Bernstein" at "Jul 6, 2003 03:19:14 pm" To: "D. J. Bernstein" Date: Mon, 7 Jul 2003 09:28:58 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-8.6 required=5.0 tests=BAYES_20,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk djb; You are the first party and your peers are the second parties. DNS, however, is an intermediate system requiring third party operators, selection on which you virtually have no influence, for root, TLD, in-addr.arpa. and other important domains. Having yet another third parties of your own choice for your own domains is not a bad idea for extra redundancy of your domains. > Jim, how exactly do you claim that European users can register glue for > their (big, direct from RIPE) in-addr.arpa delegations? I don't know the situations in Europe, but, I think you are not saying you want to operate in-addr.arpa. servers by yourself. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 12:10:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29116 for ; Tue, 8 Jul 2003 12:10:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Zutw-000Aka-5D for namedroppers-data@psg.com; Tue, 08 Jul 2003 16:01:08 +0000 Received: from [171.68.223.138] (helo=sj-core-4.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Zutp-000Aja-MA for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 16:01:01 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h68Fxapp010784; Tue, 8 Jul 2003 08:59:36 -0700 (PDT) Received: from rdroms-w2k.cisco.com (sjc-vpn4-834.cisco.com [10.21.83.65]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAM22307; Tue, 8 Jul 2003 11:59:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jul 2003 11:59:33 -0400 To: Ted Lemon From: Ralph Droms Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Cc: dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <200307021910.10225.mellon@nominum.com> References: <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ted - can you give us more details, like what the sequence of update/queries would look like if there were a separate RRtype for IPv6? Will Josh's proposal work? If we use a separate RRtype for IPv6, can the existing draft progress unchanged? Would it perhaps need some clarifying text to the effect of "used for DHCPv4 only"? Can we postpone definition of the RRtype for IPv6 until we have a better sense of how DHCPv6 will be used in practice and the requirements for DDNS-DHCPv6 interactions? - Ralph At 07:10 PM 7/2/2003 +0000, Ted Lemon wrote: >On Wednesday 02 July 2003 16:49, Ralph Droms wrote: > > > The interaction between DHCPv4 and DHCPv6 needs to be carefully > > > defined. Suppose a DHCPv4 server updates the A RR and a DHCPv6 > > > server updates the AAAA RR of the same node? How is the conflict > > > in the use of the DHCID RR for that node resolved? > >I had to sit with this one for a while. But my conclusion is that the >solution Josh proposes (do extra queries) isn't the right solution. The >right solution is to have a different RRtype for V4 and V6, just as we have A >and AAAA for IPv4 addresses and IPv6 addresses. This solution reduces the >number of updates/queries required to make it work in the dual-stack case, so >I think it's preferable, even though it means we have to allocate two RRtypes >instead of one. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 14:43:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03799 for ; Tue, 8 Jul 2003 14:43:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZxN3-000IDN-Bb for namedroppers-data@psg.com; Tue, 08 Jul 2003 18:39:21 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.14) id 19ZxN0-000ID4-PS for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 18:39:18 +0000 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 6F7FA1B21EC; Tue, 8 Jul 2003 13:34:35 -0500 (CDT) From: Ted Lemon To: Ralph Droms Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Date: Tue, 8 Jul 2003 13:39:16 -0500 User-Agent: KMail/1.5 Cc: dhcwg@ietf.org, namedroppers@ops.ietf.org References: <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307081339.16545.mellon@nominum.com> X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 08 July 2003 10:59, Ralph Droms wrote: > Ted - can you give us more details, like what the sequence > of update/queries would look like if there were a separate > RRtype for IPv6? Ooh, details, details. If there is a name with a DHCIDv6 record and no DHCID record, the update's going to fail, even though it maybe should proceed. But we can't tell if it should proceed unless the v6 identifier is the same as the v4 identifier. > Will Josh's proposal work? No, actually it won't, because again we don't know that the two identifiers match. > If we use a separate RRtype for IPv6, can the existing > draft progress unchanged? Nope, it just doesn't work at all. The problem is that the DHCPv4 server doing the update has no way of knowing if the DHCPv4 client and the DHCPv6 client that are declaring interest in a name are both the same client. DHCPv6 describes a different scheme for coming up with client identifiers. So in order to make this work, the DHCPv4 client has to send the same client identifier as the DHCPv6 client, since there's no way the DHCPv6 client can send the same identifier as the DHCPv4 client. That is, if you have a dual-stack DHCP service, the _only_ way to make it work is if the v4 and v6 clients are cooperating. I think that the right answer right now is to note in the document that this solution does not work in the dual-stack case, and leave it at that. When we write a document for DHCPv6, it should say how dual-stack clients must cooperate, and the v4 and v6 clients should probably use the same DHCID. This is not going to be a simple process to describe, though, and I don't think we should hold up the current DHCID draft waiting to come up with the correct algorithm for doing v4/v6 stuff. That needs to be a separate document. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 14:44:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03832 for ; Tue, 8 Jul 2003 14:44:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZxJp-000I4L-Bs for namedroppers-data@psg.com; Tue, 08 Jul 2003 18:36:01 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19ZxJk-000I41-Pr for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 18:35:56 +0000 Received: (qmail 19892 invoked by uid 1016); 8 Jul 2003 18:36:27 -0000 Date: 8 Jul 2003 18:36:27 -0000 Message-ID: <20030708183627.19891.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: third-party servers: DNS load, HTTP load, etc. References: <20030706151914.8706.qmail@cr.yp.to> <200307070029.JAA26000@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I wrote: : Jim, how exactly do you claim that European users can register glue for : their (big, direct from RIPE) in-addr.arpa delegations? If Jim's claim was correct, I'd like to document the procedure on my web pages, so that my users can take advantage of automatic glued [ab].ns... names. But Jim hasn't responded. Has anyone here successfully convinced RIPE to add a glued in-addr.arpa server name such as 3.5.7.in-addr.arpa NS ns1.3.5.7.in-addr.arpa or should I assume that Jim didn't know what he was talking about? Masataka Ohta writes: > Having yet another third parties of your own choice for your > own domains is not a bad idea for extra redundancy of your domains. Using glueless names doesn't add any redundancy. It creates hassles for the server administrator, creates noticeable delays on occasion for the client users, and produces a far larger increase in DNS load than any of the third-party-server issues that prompted this discussion. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 15:07:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05291 for ; Tue, 8 Jul 2003 15:07:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZxjQ-000Jee-OL for namedroppers-data@psg.com; Tue, 08 Jul 2003 19:02:28 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19ZxjN-000Je7-9q for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 19:02:25 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04821; Tue, 8 Jul 2003 15:02:11 -0400 (EDT) Message-Id: <200307081902.PAA04821@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: Handling of Unknown DNS Resource Record Types to Proposed Standard Date: Tue, 08 Jul 2003 15:02:11 -0400 X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the Internet-Draft 'Handling of Unknown DNS Resource Record Types' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. Technical Summary Extending the Domain Name System with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. Working Group Summary There was WG consensus to advance the document. Protocol Quality The specification has been reviewed for the IESG by Erik Nordmark. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 16:10:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08219 for ; Tue, 8 Jul 2003 16:10:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Zydt-000Mrs-6a for namedroppers-data@psg.com; Tue, 08 Jul 2003 20:00:49 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Zydo-000MmY-6I for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 20:00:44 +0000 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2003 12:57:58 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h68K0Brm023559; Tue, 8 Jul 2003 13:00:11 -0700 (PDT) Received: from mjs-xp.cisco.com (dhcp-10-86-160-73.cisco.com [10.86.160.73]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAM44971; Tue, 8 Jul 2003 16:00:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jul 2003 16:00:23 -0400 To: Ted Lemon From: Mark Stapp Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Cc: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <200307081339.16545.mellon@nominum.com> References: <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I don't want to flog a dead horse here, but I really do wonder whether there's much benefit to be gained by adding another rr type. Unless the server has seen a client's traffic and has seen its identifier, it cannot determine whether the hash that's in the rr was generated from that client's id. A dhcpv4 server cannot tell whether the v6 client id used to generate a hash matches one of its clients's ids. Whether the hash is carried by a dhcid rr with a 'type' code, or by a new rr that is yet to be invented, the limitation is the same. The dhcid rr info was developed to allow the enforcement of some policy. The range of policies that can be enforced in this case is limited. The limitation arises from the fact that the two protocols use different client ids, not from the use of a single rr type. A dhcpv(x) server can tell - using the type byte in the existing rr - whether there are only v(x) clients associated with a name, or both v(x) and v(y) clients. It can enforce a policy that says one of: 1. allow any number of clients to share this name 2. allow any number of v(y) clients, but only a single v(x) client 3. allow only a single 'id'. a v(x) server can test a v(x) id rr, but it can't test a v(y) id rr. I don't think that that situation will be changed by the development of a new rr. As Ted notes, a dual-stack client could generate a common identifier used for both protocols (based upon a hardware address, for example). Perhaps we can define some conventions that dual-stack clients could use that might make this possible. The hardware address based id could be hashed using the chaddr-based dhcid rr type, and that might allow us to support 'recognition' of a single client. I think that the solution for these dual-stack clients will require some words - possibly 'informational' level words. I don't think it requires an additional rr. -- Mark At 01:39 PM 7/8/2003 -0500, Ted Lemon wrote: >On Tuesday 08 July 2003 10:59, Ralph Droms wrote: > > Ted - can you give us more details, like what the sequence > > of update/queries would look like if there were a separate > > RRtype for IPv6? > >Ooh, details, details. If there is a name with a DHCIDv6 record and no >DHCID >record, the update's going to fail, even though it maybe should proceed. >But we can't tell if it should proceed unless the v6 identifier is the same >as the v4 identifier. > > > Will Josh's proposal work? > >No, actually it won't, because again we don't know that the two identifiers >match. > > > If we use a separate RRtype for IPv6, can the existing > > draft progress unchanged? > >Nope, it just doesn't work at all. > >The problem is that the DHCPv4 server doing the update has no way of knowing >if the DHCPv4 client and the DHCPv6 client that are declaring interest in a >name are both the same client. DHCPv6 describes a different scheme for >coming up with client identifiers. > >So in order to make this work, the DHCPv4 client has to send the same client >identifier as the DHCPv6 client, since there's no way the DHCPv6 client can >send the same identifier as the DHCPv4 client. That is, if you have a >dual-stack DHCP service, the _only_ way to make it work is if the v4 and v6 >clients are cooperating. > >I think that the right answer right now is to note in the document that this >solution does not work in the dual-stack case, and leave it at that. When >we write a document for DHCPv6, it should say how dual-stack clients must >cooperate, and the v4 and v6 clients should probably use the same DHCID. >This is not going to be a simple process to describe, though, and I don't >think we should hold up the current DHCID draft waiting to come up with the >correct algorithm for doing v4/v6 stuff. That needs to be a separate >document. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 17:13:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10658 for ; Tue, 8 Jul 2003 17:13:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZzgQ-0000dO-Qt for namedroppers-data@psg.com; Tue, 08 Jul 2003 21:07:30 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.14) id 19ZzgN-0000cR-Oe for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 21:07:27 +0000 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id A3B3B1B21EC; Tue, 8 Jul 2003 16:02:41 -0500 (CDT) From: Ted Lemon To: Mark Stapp , Ted Lemon Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Date: Tue, 8 Jul 2003 16:07:25 -0500 User-Agent: KMail/1.5 Cc: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org References: <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> In-Reply-To: <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307081607.25834.mellon@nominum.com> X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 08 July 2003 15:00, Mark Stapp wrote: > I think that the solution for these > dual-stack clients will require some words - possibly 'informational' level > words. I don't think it requires an additional rr. We may need to do a new standard-track draft, but either way I think it needs to be a new draft. I agree that we may not need a new RRtype, although I'm not certain that's so. In any case, I don't think we should attempt to solve this new problem in the existing draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 17:14:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10822 for ; Tue, 8 Jul 2003 17:14:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Zzhv-0000gz-CS for namedroppers-data@psg.com; Tue, 08 Jul 2003 21:09:03 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.14) id 19Zzhr-0000fi-Ci for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 21:08:59 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2B37918E1; Tue, 8 Jul 2003 17:08:15 -0400 (EDT) Date: Tue, 08 Jul 2003 17:08:15 -0400 From: Rob Austein To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records In-Reply-To: <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> References: <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <200307081339.16545.mellon@nominum.com> <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030708210815.2B37918E1@thrintun.hactrn.net> X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The main point of using two separate RR types is to remove the possibility of accidental interaction. Using one RR type requires one to understand what the various DHCP implementations are doing to be sure that there are no accidental interactions. Using separate RR types makes it very easy for someone who is not a DHCP wizard to be sure that any interactions are taking place because some entity is trying to play in both worlds. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 17:20:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11009 for ; Tue, 8 Jul 2003 17:20:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZznF-000147-3t for namedroppers-data@psg.com; Tue, 08 Jul 2003 21:14:33 +0000 Received: from [64.102.124.12] (helo=rtp-core-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19ZznB-000110-97 for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 21:14:29 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h68LDAfq006509; Tue, 8 Jul 2003 17:13:11 -0400 (EDT) Received: from mjs-xp.cisco.com ([161.44.65.152]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAM51425; Tue, 8 Jul 2003 17:13:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20030708171221.01a419e0@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jul 2003 17:13:24 -0400 To: Ted Lemon From: Mark Stapp Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Cc: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <200307081607.25834.mellon@nominum.com> References: <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Yes, sorry - I meant an independent draft (of whichever level of strength) that would address the dual-stack issues. -- Mark At 04:07 PM 7/8/2003 -0500, Ted Lemon wrote: >On Tuesday 08 July 2003 15:00, Mark Stapp wrote: > > I think that the solution for these > > dual-stack clients will require some words - possibly 'informational' level > > words. I don't think it requires an additional rr. > >We may need to do a new standard-track draft, but either way I think it needs >to be a new draft. I agree that we may not need a new RRtype, although I'm >not certain that's so. In any case, I don't think we should attempt to >solve this new problem in the existing draft. > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 17:31:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11359 for ; Tue, 8 Jul 2003 17:31:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19a00L-0001tS-3R for namedroppers-data@psg.com; Tue, 08 Jul 2003 21:28:05 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.14) id 19a00I-0001t0-Bp for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 21:28:02 +0000 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 3F7F31B21EC; Tue, 8 Jul 2003 16:23:18 -0500 (CDT) From: Ted Lemon To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Date: Tue, 8 Jul 2003 16:28:03 -0500 User-Agent: KMail/1.5 References: <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> <20030708210815.2B37918E1@thrintun.hactrn.net> In-Reply-To: <20030708210815.2B37918E1@thrintun.hactrn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307081628.03372.mellon@nominum.com> X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 08 July 2003 16:08, Rob Austein wrote: > The main point of using two separate RR types is to remove the > possibility of accidental interaction. Using one RR type requires one > to understand what the various DHCP implementations are doing to be > sure that there are no accidental interactions. Using separate RR > types makes it very easy for someone who is not a DHCP wizard to be > sure that any interactions are taking place because some entity is > trying to play in both worlds. No, unfortunately this is not true. Using a separate RRtype doesn't provide this clarity, because the way that servers would act based on the presence or absence of either RR isn't clear. Unfortunately this sounds good on paper, which is why it popped into my mind in the first place, but it doesn't work in practice. In order to see why it doesn't work you need to read the other DHCP-DNS interaction drafts (there are three inter-related drafts), not just the DHCID draft. It may be that the ultimate solution to this problem is to have a second RRtype, but if that does turn out to be the case, the one thing I can promise you is that a person who wants to understand what various DHCP implementations are doing is going to have to read the standards - it's not going to be obvious from casual observation. :'( -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 17:54:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11970 for ; Tue, 8 Jul 2003 17:54:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19a0LU-0003DJ-NV for namedroppers-data@psg.com; Tue, 08 Jul 2003 21:49:56 +0000 Received: from [64.102.124.12] (helo=rtp-core-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19a0Ky-0003A9-Rm for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 21:49:24 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h68LmAfq022153; Tue, 8 Jul 2003 17:48:10 -0400 (EDT) Received: from cisco.com ([161.44.65.118]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAM54379; Tue, 8 Jul 2003 17:48:09 -0400 (EDT) Message-ID: <3F0B3C17.60701@cisco.com> Date: Tue, 08 Jul 2003 17:48:07 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lemon CC: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records References: <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> <200307081339.16545.mellon@nominum.com> In-Reply-To: <200307081339.16545.mellon@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-34.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ted Lemon wrote: > On Tuesday 08 July 2003 10:59, Ralph Droms wrote: > >>Will Josh's proposal work? > > No, actually it won't, because again we don't know that the two identifiers > match. > >>If we use a separate RRtype for IPv6, can the existing >>draft progress unchanged? > > Nope, it just doesn't work at all. I think it depends on how you define "work". If the only definition of success is a dual-stacked client being able to use the same name for both v4 and v6, while preventing a v6 client from using the same name as a different v4 client (and vice versa), then this can be achieved with either scheme (a common, or two separate, RR types). But it can only be achieved by having the client use the same client-id and DUID, or by having the v4 and v6 DHCP servers (or whoever does the updates) both know the ID used by the other's client for that name. So I don't think the choice of approach affects making that work. If we use the currently proposed, single RR, then a current v4 DHCP server can opt to enforce a policy of having a name be v4 only (a safe policy in the absense of client-id/DUID coordination). If we specify a new RR, that can't be done until the new RR type is assigned, so we'd want to not delay creating the new RR type. If we create an additional RR type for DHCIDv6, the current algorithm works if one does not care about use of a single name by different (v4 and v6) clients. But it needs adjustment involving extra prerquisites to prevent that. It's true that the proposal I made would involve additional DNS round-trips that make things a bit uglier. For name registration, these are only needed if the updater is prepared to determine that a V6 DHCID is from the same client (which is difficult for type 0x0000 DHCID RRs). For RR deletion, an additional round trip or two may be needed to compensate for someone else adding another DHCID RR to the name. I'm not particularly wedded to either approach. It seemed that using a single RR makes it possible to be overly conservative now (preventing any dual use of a name), and add generality when we recommend common client-id/DUID formation. Adding a new RR type means we need to adjust the algorithm right away to avoid implementing something too liberal (allowing a single name to be used by two different clients at v4 and v6). Does that make sense? -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 17:59:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12131 for ; Tue, 8 Jul 2003 17:59:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19a0Qb-0003Yj-Cb for namedroppers-data@psg.com; Tue, 08 Jul 2003 21:55:13 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.14) id 19a0Q5-0003UG-B7 for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 21:54:41 +0000 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 21C2F1B21EC; Tue, 8 Jul 2003 16:49:57 -0500 (CDT) From: Ted Lemon To: Josh Littlefield Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Date: Tue, 8 Jul 2003 16:54:43 -0500 User-Agent: KMail/1.5 Cc: Ralph Droms , dhcwg@ietf.org, namedroppers@ops.ietf.org References: <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <200307081339.16545.mellon@nominum.com> <3F0B3C17.60701@cisco.com> In-Reply-To: <3F0B3C17.60701@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307081654.43511.mellon@nominum.com> X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 08 July 2003 16:48, Josh Littlefield wrote: > It seemed that using a > single RR makes it possible to be overly conservative now (preventing > any dual use of a name), and add generality when we recommend common > client-id/DUID formation. Adding a new RR type means we need to adjust > the algorithm right away to avoid implementing something too liberal > (allowing a single name to be used by two different clients at v4 and v6). > > Does that make sense? Yup, that sounds exactly right. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 18:02:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12315 for ; Tue, 8 Jul 2003 18:02:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19a0UX-0003tr-KN for namedroppers-data@psg.com; Tue, 08 Jul 2003 21:59:17 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.14) id 19a0U6-0003or-TP for namedroppers@ops.ietf.org; Tue, 08 Jul 2003 21:58:50 +0000 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2003 14:56:06 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h68LwIMr020425; Tue, 8 Jul 2003 14:58:18 -0700 (PDT) Received: from cisco.com ([161.44.65.118]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAM55087; Tue, 8 Jul 2003 17:58:16 -0400 (EDT) Message-ID: <3F0B3E78.2080500@cisco.com> Date: Tue, 08 Jul 2003 17:58:16 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Austein CC: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records References: <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <200307081339.16545.mellon@nominum.com> <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> <20030708210815.2B37918E1@thrintun.hactrn.net> In-Reply-To: <20030708210815.2B37918E1@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > The main point of using two separate RR types is to remove the > possibility of accidental interaction. Using one RR type requires one > to understand what the various DHCP implementations are doing to be > sure that there are no accidental interactions. Using separate RR > types makes it very easy for someone who is not a DHCP wizard to be > sure that any interactions are taking place because some entity is > trying to play in both worlds. Rob, using two separate RR types allows more independence. However, we actually *want* these to interact. That's the issue. If the presense of a v6 registration on a name should affect the behavior of a v4 registration (and I think it should), then independence isn't helpful, and interaction is demanded by the update policy. -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 8 20:53:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17155 for ; Tue, 8 Jul 2003 20:53:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19a36e-000E8z-13 for namedroppers-data@psg.com; Wed, 09 Jul 2003 00:46:48 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.14) id 19a368-000E5q-9q for namedroppers@ops.ietf.org; Wed, 09 Jul 2003 00:46:16 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 13B5E18E0; Tue, 8 Jul 2003 20:45:33 -0400 (EDT) Date: Tue, 08 Jul 2003 20:45:33 -0400 From: Rob Austein To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records In-Reply-To: <3F0B3E78.2080500@cisco.com> References: <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <200307081339.16545.mellon@nominum.com> <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> <20030708210815.2B37918E1@thrintun.hactrn.net> <3F0B3E78.2080500@cisco.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030709004533.13B5E18E0@thrintun.hactrn.net> X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Believe it or not, I did review all three drafts, more than once, but apparently still managed to forget too much context. It looks like there's a choice to make: if the goal is to use this mechanism to prevent cases in which two nodes register the same name, one for IPv4 and one for IPv6, then I agree that one probably needs to use a single RR type, so that one can use the atomic test-and-set properties of the update operation on a single RRset, and these drafts probably can't go forward until all the details of this update operation (how one composes it, how one handles failures, etc) are nailed down. If, however, preventing this case is not a goal, then I stand by my earlier statement that two RR types would be simpler, which perhaps just means that I'm still missing something. So, what's the goal, where is it stated, and why not? :) BTW, I'll be in Vienna, and, for the first time since I don't remember when, I don't (yet) have a schedule conflict to prevent me from attending the DHC WG session, so I'm game for trying to thrash this out there (or in the bar) if that'd help. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 9 07:51:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28227 for ; Wed, 9 Jul 2003 07:51:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aDM7-000Fu2-TF for namedroppers-data@psg.com; Wed, 09 Jul 2003 11:43:27 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19aDLc-000FsT-Et for namedroppers@ops.ietf.org; Wed, 09 Jul 2003 11:42:56 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h69BgNrm004209; Wed, 9 Jul 2003 04:42:24 -0700 (PDT) Received: from rdroms-w2k.cisco.com (sjc-vpn2-391.cisco.com [10.21.113.135]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAM84437; Wed, 9 Jul 2003 07:42:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20030709072805.04683080@funnel.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jul 2003 07:39:48 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records In-Reply-To: <20030709004533.13B5E18E0@thrintun.hactrn.net> References: <3F0B3E78.2080500@cisco.com> <4.3.2.7.2.20030708115543.0495c0d8@funnel.cisco.com> <4.3.2.7.2.20030702124720.048b2270@funnel.cisco.com> <200307081339.16545.mellon@nominum.com> <4.3.2.7.2.20030708152429.01ac5008@goblet.cisco.com> <20030708210815.2B37918E1@thrintun.hactrn.net> <3F0B3E78.2080500@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-24.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Seems to me we could plausibly want to allow both behaviors... - disallow registration of an IPv4 address and an IPv6 address to the same name by different hosts - allow registration of an IPv4 address to a name by a DHCPv4 server and registration of an IPv6 address to the same name by a DHCPv6 server - Ralph At 08:45 PM 7/8/2003 -0400, Rob Austein wrote: >Believe it or not, I did review all three drafts, more than once, but >apparently still managed to forget too much context. > >It looks like there's a choice to make: if the goal is to use this >mechanism to prevent cases in which two nodes register the same name, >one for IPv4 and one for IPv6, then I agree that one probably needs to >use a single RR type, so that one can use the atomic test-and-set >properties of the update operation on a single RRset, and these drafts >probably can't go forward until all the details of this update >operation (how one composes it, how one handles failures, etc) are >nailed down. If, however, preventing this case is not a goal, then I >stand by my earlier statement that two RR types would be simpler, >which perhaps just means that I'm still missing something. > >So, what's the goal, where is it stated, and why not? :) > >BTW, I'll be in Vienna, and, for the first time since I don't remember >when, I don't (yet) have a schedule conflict to prevent me from >attending the DHC WG session, so I'm game for trying to thrash this >out there (or in the bar) if that'd help. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 9 10:11:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01949 for ; Wed, 9 Jul 2003 10:11:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aFYS-000KUd-Ch for namedroppers-data@psg.com; Wed, 09 Jul 2003 14:04:20 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19aFXv-000KT4-Uj for namedroppers@ops.ietf.org; Wed, 09 Jul 2003 14:03:48 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01070; Wed, 9 Jul 2003 10:03:44 -0400 (EDT) Message-Id: <200307091403.KAA01070@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-2535typecode-change-03.txt Date: Wed, 09 Jul 2003 10:03:44 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Legacy Resolver Compatibility for Delegation Signer Author(s) : S. Weiler Filename : draft-ietf-dnsext-dnssec-2535typecode-change-03.txt Pages : 5 Date : 2003-7-9 As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document proposes that these interactions be avoided by changing the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-2535typecode-change-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-dnssec-2535typecode-change-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: <2003-7-9102245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-2535typecode-change-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-9102245.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 10 10:35:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05058 for ; Thu, 10 Jul 2003 10:35:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19acNm-00008g-II for namedroppers-data@psg.com; Thu, 10 Jul 2003 14:26:50 +0000 Received: from [192.134.4.151] (helo=maya40.nic.fr) by psg.com with esmtp (Exim 4.14) id 19acNF-00007g-PM for namedroppers@ops.ietf.org; Thu, 10 Jul 2003 14:26:17 +0000 Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h6AEQFNl644656; Thu, 10 Jul 2003 16:26:15 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h6AEQA027426; Thu, 10 Jul 2003 16:26:10 +0200 Date: Thu, 10 Jul 2003 16:26:10 +0200 From: Mohsen Souissi To: Mike StJohns Cc: namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt Message-ID: <20030710162610.D14284@kerkenna.nic.fr> References: <200306302039.h5UKd2df003270@guava.araneus.fi> <5.2.1.1.2.20030630165223.026f4008@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5.2.1.1.2.20030630165223.026f4008@localhost>; from Mike.StJohns@nominum.com on Mon, Jun 30, 2003 at 05:03:01PM -0400 X-Spam-Status: No, hits=-18.4 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES,SATISFACTION,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Mike, Please find my comments below. On 30 Jun, Mike StJohns wrote: | At 16:39 6/30/2003, Andreas Gustafsson wrote: | >In draft-stjohns-secure-notify-00.txt, M. StJohns writes: | > > In fact, best practice requires that a zone be served by at least one | > > server that can be referenced by a name not within that zone. | > | >My interpretation of RFC2182 is that a zone should have at least one | >server on a geographically and topologically distinct network, but I | >see no requirement that it be referenced by a name in a different | >zone. | | yeah - I can actually read 2182 either way - specifically section 6 | discussion of the selection of secondaries. I'd be interested in | understanding what others think is best practice here. The reason I like | the name diversity constraint is because it provides one more resolution | path to the delegated zone, even if the glue records in the parent are | messed up or more probably, missing. | | | > > The parent zone MUST verify the names pointed to by the NS are | > > resolvable, that at least one name points to a server not named in | > > the child zone, and that it has glue A records for any server named | > > in the child zone. [Q: Does this make sense, or is it better to just | > > trust the child?] If these conditions are not satisfied, the parent | > > server MUST NOT install the new records, and MUST log the problem | > | >I don't think this makes sense. Whether the best practice is to have | >a server in a different zone or just on a different network, it is | >just an operational recommendation and not something that should be | >enforced as part of the protocol. | | | To be clear, your issue is with "that at least one name points to a server | not named in the child zone" and not with the rest of it as above? Yeah - | this might either be a) removed, b) turned into a policy configuration item | (e.g. something the parent zone wants to enforce on the child - in which | case this section become MAY) or c) left as a MUST. My guess is that | either a or b is probably appropriate given our off line discussion. ==> I believe that updating Parent DS Record and updating Parent NS Records for a given child are completely different. Using the same NOTIFY to either update DS and/or NS records at the Parent zone adds much more complexity on the Parent side. It is not necessarily the role of the Parent master server to check whether the new NS's are resolvable or not. As mentioned Jim Reid, some TLDs check zone configuration on authoritative nameservers for the child zone before creating/modifying the child NS delegation. Checking DNS configuration is for some TLDs far more than just checking whether the NS names are resolvable or not. Just have a look at http://www.zonecheck.fr and you see the numerous mandatory/optional tests one can enable for checking a DNS zone. Once again, I agree with Jim when he says that how NS's are updated at the Parent is rather related to the Parent's policy. My humble suggestion is to deal with only one feature at a time if we want to add some extra semantics to the NOTIFY message. I think that the DS update should be simpler. Regards, Mohsen. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 10 13:22:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13095 for ; Thu, 10 Jul 2003 13:22:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19af2S-0008Rp-Iv for namedroppers-data@psg.com; Thu, 10 Jul 2003 17:17:00 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.14) id 19af1w-0008QG-PH for namedroppers@ops.ietf.org; Thu, 10 Jul 2003 17:16:28 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h6AHGEw1000111 for ; Thu, 10 Jul 2003 13:16:15 -0400 (EDT) Message-ID: <00cd01c34706$f9790660$b9370681@barnacle> From: "Scott Rose" To: Subject: Revised list of DNSSECbis spec questions Date: Thu, 10 Jul 2003 13:16:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just to remind everyone before the WG meetings, here is the collection of DNSSECbis questions posed to the list. This is to the best of my knowledge, so there may be errors. Q1 - resolved Q2 - Should we move DSA to "optional" and have RSA/SHA1 be the only mandatory to implement algorithm? *Consensus? * Q3 - Can we drop the requirement to add the KEY/SIG(KEY) to the additional section of a response? *Consensus seems to be in favor of dropping requirement* Q4 - mistake in numbering, there is no Q4 Q5 - Should algorithm code 252 (now "Indirect") remain, or move it to "Reserved"? *Consensus? Could not find any resolution in archives * Q6 - Started as "Should sec-aware resolvers cache known "BAD" data"? but now encompasses how servers/resolvers should interpret the CD bit in the DNS header. * No formal consensus reached yet, discussion died out * Q7- Should the DNSSECbis documents discuss use of preconfigured trusted DSs in addition to to preconfigured trusted KEYs? Q8 - Should the apex allow zone KEY RRs only? *Consensus seems to be no restrictions at all on KEY RR placement in a zone * Q9 - Dropping the SIG(NXT) from the NXT RRs included in the Auth. section on wildcard and negative replies *Consensus seems to be no allowing of NXT/SIG(NXT) breakup in authority section. Truncate response * Q10: Reaction to "Silly NXT". NXT's that do not have the NXT and/or SIG bit set in bitmap. Q11: KEY RRs allowed at delegation points. "Consensus: not really." Seems to be more "no" than "yes" though. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 10 14:14:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15091 for ; Thu, 10 Jul 2003 14:14:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19afry-000BAb-0P for namedroppers-data@psg.com; Thu, 10 Jul 2003 18:10:14 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19afrS-000B7H-4t for namedroppers@ops.ietf.org; Thu, 10 Jul 2003 18:09:42 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6AI9ebI028203 for ; Thu, 10 Jul 2003 12:09:41 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6AI9bQ25331 for ; Thu, 10 Jul 2003 20:09:38 +0200 (MEST) Date: Thu, 10 Jul 2003 20:08:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: draft-ietf-dnsext-rfc1886bis To: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The document was approved by the IESG today with some nits as an RFC editor note. If these tweaks are problematic let me know and I'll stop the presses. Erik RFC Editor note: In the Abstract please change: s/Domain Name System/Domain Name System (DNS)/ s/RFC1886/RFC 1886/ Please add this at the end of the Introduction section: The IP protocol version used for querying resource records is independent of the protocol version of the resource records; e.g. IPv4 transport can be used to query IPv6 records and vice versa. --- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 10 14:17:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15181 for ; Thu, 10 Jul 2003 14:17:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19afve-000BMx-QL for namedroppers-data@psg.com; Thu, 10 Jul 2003 18:14:02 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19afuV-000BIs-8o for namedroppers@ops.ietf.org; Thu, 10 Jul 2003 18:12:51 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6AICnc8007217 for ; Thu, 10 Jul 2003 12:12:50 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6AICkQ25720 for ; Thu, 10 Jul 2003 20:12:47 +0200 (MEST) Date: Thu, 10 Jul 2003 20:11:24 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: draft-ietf-dnsext-gss-tsig To: namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Also approved by the IESG today. As was noted the references need to be split into normative and informative (I'd missed that since that RFC editor rule wasn't in place last year during the original approval). Thus it makes sense to specify which references are normative so that this information can be passed to the RFC editor when they start processing the document. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 10 14:18:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15229 for ; Thu, 10 Jul 2003 14:18:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19afv7-000BLA-Sf for namedroppers-data@psg.com; Thu, 10 Jul 2003 18:13:29 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19afuM-000BII-2Q for namedroppers@ops.ietf.org; Thu, 10 Jul 2003 18:12:42 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6AICec8007112 for ; Thu, 10 Jul 2003 12:12:41 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6AICbQ25715 for ; Thu, 10 Jul 2003 20:12:37 +0200 (MEST) Date: Thu, 10 Jul 2003 20:11:14 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: draft-ietf-dnsext-ad-is-secure To: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The document was approved by the IESG today with some changes as an RFC editor note. Mostly what I sent to the list earlier but some rewording in the first item, and the addition of the last item. (I know the last item is largely a repeat of existing text elsewhere in the draft, but in the interest of time and knowing that 2535bis will fold all this into one document I cut some corners.) If these tweaks are problematic let me know and I'll stop the presses. Erik RFC Editor note: Please add the standard IPR section to the document. Before the last paragraph in section 4 add this paragraph: In the latter two cases, the end consumer must also completely trust the network path to the trusted resolvers or a secure transport is employed to protect the traffic. Add this paragraph to the end of section 2.2: Note that having the AD bit clear on an authoritative answer is normal and expected behavior. The draft also has an odd "MUST" in section 2.2.1: Organisations that require that all DNS responses contain cryptographically verified data MUST separate the functions of authoritative and recursive servers, as authoritative servers are not required to validate local secure data. This introduces a new concept "local secure data", w/o defining it. Replace that paragraph with: Organisations which require that all DNS responses contain cryptographically verified data will need to separate the authoritative name server and signature verification functions, since name servers are not required to validate signatures of data for which they are authoritative. Add this paragraph at the end of the security considerations section: A resolver MUST NOT blindly trust the AD bit unless it communicates with the full function resolver over a secure transport mechanism, such as IPsec, or using message authentication such as TSIG [RFC2845] or SIG(0) [RFC2931]. In addition, the resolver must have been explicitly configured to trust this resolver. --- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 11 10:43:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01980 for ; Fri, 11 Jul 2003 10:43:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ayxf-000CtO-AX for namedroppers-data@psg.com; Fri, 11 Jul 2003 14:33:23 +0000 Received: from [131.254.10.33] (helo=w3.irisa.fr) by psg.com with esmtp (Exim 4.14) id 19ayxb-000Ct2-VY for namedroppers@ops.ietf.org; Fri, 11 Jul 2003 14:33:20 +0000 Received: from irisa.fr (estephe.irisa.fr [131.254.70.3]) by w3.irisa.fr (Postfix) with ESMTP id BB3318405; Fri, 11 Jul 2003 16:07:45 +0200 (MEST) Message-ID: <3F0EC4B3.4000806@irisa.fr> Date: Fri, 11 Jul 2003 16:07:47 +0200 From: Olivier Courtay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: fr-fr, en-us, en MIME-Version: 1.0 To: Mike.StJohns@nominum.com Cc: namedroppers@ops.ietf.org Subject: Comment on draft-stjohns-secure-notify-00 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-17.9 required=5.0 tests=BAYES_10,SIGNATURE_LONG_SPARSE,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In the draft draft-stjohns-secure-notify-00, update of the NS or DS is done by a NOTIFY signed by SIG(0). The child send a signed NOTIFY Query with new RR and wait a response. But the NOTIFY isn't crypted such anybody can see what the NOTIFY Query contains and forge a NOTIFY Response. The child think that the change is done by his parent when it receives the fake Response but the parent doesn't update the delegation RR . It's should have a security check somewhere, there are few possibilities : - the parent sign by SIG(0) the NOTIFY Response (on the same way of the draft) - the child check on the parent server that the change have been included (a simple (not signed) NOTIFY Response is sent by the parent). The first solution have the advantage to be coherent with the NOTIFY Query, but the private key may not be on the server, and the NOTIFY Response is built when the zone is resigned, it could spent a long time between Query and Response. The second solution have the advantage that the child verify that the change take effect on the parent's zone server. This check can be done independently with reception of the NOTIFY Response. -- Olivier COURTAY Research engineer IDsA Project (www.idsa.prd.fr) ENST Bretagne( www.enst-bretagne.fr) Gilles GUETTE Ph.D student Armor Project Irisa/Inria (www.irisa.fr) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 11 18:00:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19431 for ; Fri, 11 Jul 2003 18:00:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19b5pj-0009XV-38 for namedroppers-data@psg.com; Fri, 11 Jul 2003 21:53:39 +0000 Received: from [194.133.230.246] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.14) id 19b5pD-0009US-Ag for namedroppers@ops.ietf.org; Fri, 11 Jul 2003 21:53:07 +0000 Received: from ripe.net (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id A5D99BFD50; Fri, 11 Jul 2003 23:53:50 +0200 (CEST) Date: Fri, 11 Jul 2003 23:53:49 +0200 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: namedroppers@ops.ietf.org To: Erik Nordmark From: "Olaf M.Kolkman" Content-Transfer-Encoding: 7bit Message-Id: <276D5DC3-B3EA-11D7-91DD-000A9567ED24@ripe.net> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Hereby a request for the publication of draft-ietf-dnsext-dnssec-2535typecode-change-03. Last call | for (version 1) of this document was done May 29 (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/ msg01157.html.) Issues brought up during the last call and brought up by the "Keeping the KEY and SIG typecodes active" thread, dd June 17 (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/ msg01303.html) have been addressed. A list of changes can be found in the document itself. The working group has consensus for this document to be published as proposed standard. --Olaf Kolkman DNSEXT co-chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 11 18:43:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21983 for ; Fri, 11 Jul 2003 18:43:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19b6Xj-000Bap-6E for namedroppers-data@psg.com; Fri, 11 Jul 2003 22:39:07 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19b6XD-000BZp-2H for namedroppers@ops.ietf.org; Fri, 11 Jul 2003 22:38:35 +0000 From: Masataka Ohta Message-Id: <200307112231.HAA00558@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA00558; Sat, 12 Jul 2003 07:31:00 +0900 Subject: Re: third-party servers: DNS load, HTTP load, etc. In-Reply-To: <20030708183627.19891.qmail@cr.yp.to> from "D. J. Bernstein" at "Jul 8, 2003 06:36:27 pm" To: "D. J. Bernstein" Date: Sat, 12 Jul 2003 07:30:59 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-8.6 required=5.0 tests=BAYES_20,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Djb; > Masataka Ohta writes: > > Having yet another third parties of your own choice for your > > own domains is not a bad idea for extra redundancy of your domains. > > Using glueless names doesn't add any redundancy. Using third party servers does add redundancy. > It creates hassles for > the server administrator, creates noticeable delays on occasion for the > client users, They are minor issues to be negligible. > and produces a far larger increase in DNS load than any of > the third-party-server issues that prompted this discussion. It's me who pointed out that intermingled glueless delegations sometimes cause loops about 10 years ago. But, it has nothing to do with "third party servers" and is not a third-party-server issues. Use correct terminology. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 11 21:33:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29933 for ; Fri, 11 Jul 2003 21:33:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19b9A1-000JoM-Dn for namedroppers-data@psg.com; Sat, 12 Jul 2003 01:26:49 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19b99V-000Jmi-31 for namedroppers@ops.ietf.org; Sat, 12 Jul 2003 01:26:17 +0000 Received: (qmail 12477 invoked by uid 1016); 12 Jul 2003 01:26:47 -0000 Date: 12 Jul 2003 01:26:47 -0000 Message-ID: <20030712012647.12476.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: third-party servers: DNS load, HTTP load, etc. References: <20030708183627.19891.qmail@cr.yp.to> <200307112231.HAA00558@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Masataka Ohta writes: > nothing to do with "third party servers" Adding third-party servers has several minor effects, positive and negative, on DNS load. Someone whined about one of these effects, while ignoring the _much_ larger effect that gluelessness has on DNS load. Small efficiency issues have to be viewed in the context of larger efficiency issues. It's silly to claim that one has ``nothing to do with'' the other. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 12 06:13:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08144 for ; Sat, 12 Jul 2003 06:13:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bHFV-000EPo-Vk for namedroppers-data@psg.com; Sat, 12 Jul 2003 10:05:01 +0000 Received: from [212.9.163.38] (helo=mail.enyo.de) by psg.com with esmtp (Exim 4.14) id 19bHCu-000EH5-AJ for namedroppers@ops.ietf.org; Sat, 12 Jul 2003 10:02:20 +0000 Received: from [212.9.189.171] (helo=deneb.enyo.de) by mail.enyo.de with esmtp (Exim 4.20) id 19bHCt-0001Lv-8R for namedroppers@ops.ietf.org; Sat, 12 Jul 2003 12:02:19 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.20) id 19bHCs-0000c6-Ef for namedroppers@ops.ietf.org; Sat, 12 Jul 2003 12:02:18 +0200 To: namedroppers@ops.ietf.org Subject: Transport-independent naming of services From: Florian Weimer Mail-Followup-To: namedroppers@ops.ietf.org Date: Sat, 12 Jul 2003 12:02:18 +0200 Message-ID: <87u19sgj11.fsf@deneb.enyo.de> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_20,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A distributed application APP can use various transports (e.g., TCP and SCTP, or, at a higher level, HTTP, HTTPS, WebDAV, SFTP and FTP) to access remote resources. Remote resources are identified by a domain name. Can existing DNS RRs be used to describe this scenario in a meaningful way? Registering a new SRV service doesn't help because the SRV RR data does not indicate the transport service (just its port number, which is not enough data). The only approach seems to be to register SRV service names "APP_http", "APP_https" etc. and to query for all services the application might support, but this is not very elegant. Any suggestions? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jul 12 07:53:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12248 for ; Sat, 12 Jul 2003 07:53:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bIs9-000Id2-Pw for namedroppers-data@psg.com; Sat, 12 Jul 2003 11:49:01 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.14) id 19bIrd-000Ibx-6W for namedroppers@ops.ietf.org; Sat, 12 Jul 2003 11:48:29 +0000 From: Masataka Ohta Message-Id: <200307121134.UAA02507@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA02507; Sat, 12 Jul 2003 20:34:25 +0900 Subject: Re: third-party servers: DNS load, HTTP load, etc. In-Reply-To: <20030712012647.12476.qmail@cr.yp.to> from "D. J. Bernstein" at "Jul 12, 2003 01:26:47 am" To: "D. J. Bernstein" Date: Sat, 12 Jul 2003 20:34:24 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DJB; > Masataka Ohta writes: > > nothing to do with "third party servers" > > Adding third-party servers has several minor effects, positive and > negative, on DNS load. Someone whined about one of these effects, while > ignoring the _much_ larger effect that gluelessness has on DNS load. Issues caused by complicated relationships between servers operated by a single party has nothing to to with "third party servers", even if the same issues can be caused by complicated relationships between servers operated by multiple servers. > Small efficiency issues have to be viewed in the context of larger > efficiency issues. It's silly to claim that one has ``nothing to do > with'' the other. See above. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 13 10:38:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25810 for ; Sun, 13 Jul 2003 10:38:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bhqJ-000C9Y-A2 for namedroppers-data@psg.com; Sun, 13 Jul 2003 14:28:47 +0000 Received: from [194.246.96.22] (helo=smtp.denic.de) by psg.com with esmtp (Exim 4.14) id 19bhqG-000C9L-LV for namedroppers@ops.ietf.org; Sun, 13 Jul 2003 14:28:44 +0000 Received: from w4.denic.de ([194.246.96.15]) by smtp.denic.de with esmtp id 19bhqF-0001Cf-00; Sun, 13 Jul 2003 16:28:43 +0200 In-Reply-To: <87u19sgj11.fsf@deneb.enyo.de> To: Florian Weimer Cc: namedroppers@ops.ietf.org Subject: Re: Transport-independent naming of services MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Marcos Sanz/Denic Message-ID: Date: Sun, 13 Jul 2003 16:28:34 +0200 X-MIMETrack: Serialize by Router on notes/Denic(601CF1HF55 | May 13, 2003) at 13.07.2003 16:28:43, Serialize complete at 13.07.2003 16:28:43 Content-Type: multipart/alternative; boundary="=_alternative 004F4085C1256D62_=" X-Spam-Status: No, hits=-18.4 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 004F4085C1256D62_= Content-Type: text/plain; charset="US-ASCII" On 12.07.2003 12:02 Florian Weimer wrote: > > A distributed application APP can use various transports (e.g., TCP and > SCTP, or, at a higher level, HTTP, HTTPS, WebDAV, SFTP and FTP) to > access remote resources. Remote resources are identified by a > domain name. > > Can existing DNS RRs be used to describe this scenario in a meaningful > way? Registering a new SRV service doesn't help because the SRV RR > data does not indicate the transport service (just its port number, > which is not enough data). The only approach seems to be to register > SRV service names "APP_http", "APP_https" etc. and to query for all > services the application might support, but this is not very elegant. > > Any suggestions? A "straightforward" use of NAPTR records (NAPSTR) could be the thing you are looking for: http://www.ietf.org/internet-drafts/draft-daigle-napstr-02.txt Best regards, Marcos Sanz DENIC eG --=_alternative 004F4085C1256D62_= Content-Type: text/html; charset="US-ASCII"
On 12.07.2003 12:02 Florian Weimer <fw@deneb.enyo.de> wrote:
>
> A distributed application APP can use various transports (e.g., TCP and
> SCTP, or, at a higher level, HTTP, HTTPS, WebDAV, SFTP and FTP) to
> access remote resources.  Remote resources are identified by a
> domain name.
>
> Can existing DNS RRs be used to describe this scenario in a meaningful
> way?  Registering a new SRV service doesn't help because the SRV RR
> data does not indicate the transport service (just its port number,
> which is not enough data).  The only approach seems to be to register
> SRV service names "APP_http", "APP_https" etc. and to query for all
> services the application might support, but this is not very elegant.
>
> Any suggestions?

A "straightforward" use of NAPTR records (NAPSTR) could be the thing you are looking for:
http://www.ietf.org/internet-drafts/draft-daigle-napstr-02.txt

Best regards,
Marcos Sanz
DENIC eG --=_alternative 004F4085C1256D62_=-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 13 12:46:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29975 for ; Sun, 13 Jul 2003 12:46:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bjv2-000I2o-Ku for namedroppers-data@psg.com; Sun, 13 Jul 2003 16:41:48 +0000 Received: from [81.160.229.50] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.14) id 19bjv0-000I2X-Fe for namedroppers@ops.ietf.org; Sun, 13 Jul 2003 16:41:46 +0000 Received: from ripe.net (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 3DA0EC0BD5; Sun, 13 Jul 2003 18:42:36 +0200 (CEST) Date: Sun, 13 Jul 2003 18:42:35 +0200 Subject: Updated Agenda DNSEXT Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: agenda@ietf.org To: namedroppers@ops.ietf.org From: "Olaf M.Kolkman" Content-Transfer-Encoding: 7bit Message-Id: <0195579F-B551-11D7-AA01-000A9567ED24@ripe.net> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_20,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit DNS Extensions WG (dnsext) Tuesday, July 15, 1300-15:15 Afternoon Sessions I and II Hall IK Chairs: Olafur Gudmundsson, Olaf Kolkman. ------------------------------------------------------------ - Administrivia 3 min agenda bashing appointing scribes - Charter 7 min For draft see mailinglist dd Mon, 23 Jun 2003 - Other administrivia: Update from the AD 5 min Request from the IPSECKEY WG 2 min - Bernard Aboba Linklocal Multicast Name Resolution (LLMNR) (summary of changes since IETF56) draft-ietf-dnsext-mdns-21.txt 5 min - DNSSEC editors report 10 min presentation 15 min discussion draft-ietf-dnsext-dnssec-intro-05.txt draft-ietf-dnsext-dnssec-protocol-01.txt draft-ietf-dnsext-dnssec-records-03.txt - Ed Lewis 15 min Wildcard Clarification draft-lewis-dns-wildcard-clarify-00.tx - Moshen Souissi Update on RFC2845 (TSIG) interop tests 10 min - Mike St Johns. 10 min Using DNSSEC-secured NOTIFY to Trigger Parent Zone Updating draft-stjohns-secure-notify-00 - AOB 10 min Please inform chairs in advance of the meeting. ------------------------------------------------------------ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 13 12:46:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29993 for ; Sun, 13 Jul 2003 12:46:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bjv1-000I2j-EH for namedroppers-data@psg.com; Sun, 13 Jul 2003 16:41:47 +0000 Received: from [81.160.229.50] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.14) id 19bjuw-000I2N-9T for namedroppers@ops.ietf.org; Sun, 13 Jul 2003 16:41:42 +0000 Received: from ripe.net (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id C9B95C0BC4 for ; Sun, 13 Jul 2003 18:42:31 +0200 (CEST) Date: Sun, 13 Jul 2003 18:42:30 +0200 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: multipart/mixed; boundary=Apple-Mail-4-350455586 Subject: Working Group Meeting update and Administrativia From: "Olaf M.Kolkman" To: namedroppers@ops.ietf.org Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_30,HTML_50_60,OPT_IN,USER_AGENT_APPLEMAIL version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-4-350455586 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Dear Colleagues, Some updates for the DNSEXT WG meeting. Initially we planned for a 1 hour meeting, fortunately we have been able to secure the meeting room for the slot immediately after the meeting. This means that we can take the agenda items and go in somewhat more depth. We've also added extra agenda items: update from the AD and request from the IPSECKEY wg chairs. The updated agenda follows in a separate message. To avoid having to read out the list of drafts and explaining where we are and to get a good feeling for the work that is still on our plate I have made a spreadsheet with the draft-ietf-dnsext files and identified their status. The spreadsheet is attached as HTML. I hope the comments are clear enough and that no errors are made in the status. The status is really workgroup centric, if you want to know what the status in for documents passed to the IESG you have to check the request checker. Please let us know if you spot serious inconsistencies and feel free to ask questions in private or on the list. A second spreadsheet contains all the Standard Track documents that are relevant to DNSEXT. It is important that these documents get progressed. Since not all the work can be done at once we have started to assign priorities to the documents, we invite your suggestions and motivations for changed priorities. In august we (the chairs) will fix the priorities and will determine an order in which we want to bring up these document for progress at that point each document will get a milestone attached to it. We want to and guide each document from proposed to draft in roughly 3-6 months, we will publish the details about this later. As for the draft Charter. As you may be aware Erik, our AD, is in the process of being replaced. At the moment of this writing it is not clear who the new AD will be. We want to discuss the draft charter with our new AD hence there has not been any activity with respect to the draft charter. --Olaf Kolkman DNSEXT Co-Chair P.S. Sorry for the text/html attachment. :-) --Apple-Mail-4-350455586 Content-Disposition: attachment; filename=Table1.htm Content-Type: text/html; x-mac-creator=4D534945; x-unix-mode=0644; x-mac-type=54455854; name="Table1.htm" Content-Transfer-Encoding: quoted-printable =0D=0D=0D=0D=0D= =0D=0D=0D= =0D=0D=0D=0D =0D =0D =0D =0D = =0D =0D =0D= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D= =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D= =0D =0D =0D= =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D = =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D= =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D= =0D =0D= =0D =0D =0D = =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D = =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D= =0D =0D= =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D= =0D =0D = =0D =0D =0D =0D =0D =0D= =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D = =0D =0D =0D= =0D =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D
nameLast VersionWG stateFirst to IESGtable update
or RFC publication date
draft-ietf-dnsext-dnssec-intro5Active
draft-ietf-dnsext-dnssec-protocol1Active
draft-ietf-dnsext-dnssec-records3Active
draft-ietf-dnsext-mdns21Active
draft-ietf-dnsext-wcard-clarify0Active
draft-ietf-dnsext-keyrr-key-signing-flag7Active lastcall update
draft-ietf-dnsext-dhcid-rr6Active past last callWaiting for = related documents in DHC, need to=0D go to = the AD at the same time
draft-ietf-dnsext-ipv6-name-auto-reg0Active past last callOlafur need to = sumarize last call results
draft-ietf-dnsext-tkey-renewal-mode3Active past last callWaiting for = summary of last call by Olafur
draft-ietf-dnsext-dns-threats3Active past last callNeeds a summary write up for last call
draft-ietf-dnsext-insensitive3Active ReadyNeeds a summary = write up for WG last call
draft-ietf-dnsext-rfc2536bis-dsa3ExpiredShould be revised as soon as DNSEXT key=0D modifications = converts
draft-ietf-dnsext-rfc2539bis-dhk3ExpiredShould be revised as soon as DNSEXT key=0D modifications = converts
draft-ietf-dnsext-rfc2782bis2Expired (See comments)This is about moving SRV to draft = std. Process=0D stalled.
draft-ietf-dnsext-axfr-clarify6IESGNov-02
draft-ietf-dnsext-delegation-signer15IESGJul-03
draft-ietf-dnsext-dnssec-2535typecode-change3IESGJul-03
draft-ietf-dnsext-dnssec-opt-in5IESGJul-03
draft-ietf-dnsext-dnssec-roadmap7IESGFeb-03
draft-ietf-dnsext-unknown-rrs6IESG RFC QueueNov-02
draft-ietf-dnsext-ad-is-secure6IESG/RFC QueueMar-03
draft-ietf-dnsext-gss-tsig6IESG/RFC QueueFeb-02
draft-ietf-dnsext-rfc1886bis3IESG/RFC QueueFeb-03
draft-ietf-dnsext-ecc-key3kept alliveWaiting for develepments in DNSSEC
draft-ietf-dnsext-aaaa-a62obsoleted
draft-ietf-dnsext-edns14Obsoleted
draft-ietf-dnsext-parent-sig1obsoleted
draft-ietf-dnsext-parent-stores-zone-keys2obsoleted
draft-ietf-dnsext-zone-status5RFC3090May-01
draft-ietf-dnsext-rsa3RFC3110May-01
draft-ietf-dnsext-apl-rr2RFC3123Jun-01July 13, 2001
draft-ietf-dnsext-dnsmib-historical0RFC3197Nov-01
draft-ietf-dnsext-dnssec-okbit3RFC3225Dec-01
draft-ietf-dnsext-message-size4RFC3226Dec-01
draft-ietf-dnsext-ipv6-addresses2RFC3363Aug-02
draft-ietf-dnsext-ipv6-dns-tradeoffs2RFC3364Aug-02
draft-ietf-dnsext-obsolete-iquery4RFC3425Nov-02
draft-ietf-dnsext-restrict-key-for-dnssec4RFC3445Dec-02
=0D=0D=0D=0D=0D= --Apple-Mail-4-350455586 Content-Disposition: attachment; filename=Table2.htm Content-Type: text/html; x-mac-creator=4D534945; x-unix-mode=0644; x-mac-type=54455854; name="Table2.htm" Content-Transfer-Encoding: quoted-printable =0D=0D=0D=0D=0D= =0D=0D=0D=0D=0D=0D=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D= =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D = =0D =0D = =0D =0D =0D =0D =0D =0D = =0D =0D = =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D= =0D =0D = =0D =0D =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D= =0D =0D =0D =0D= =0D =0D = =0D =0D = =0D =0D =0D =0D =0D =0D= =0D =0D = =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D= =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D = =0D =0D = =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D = =0D =0D = =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D= =0D =0D= =0D =0D = =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D= =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D= =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D = =0D =0D = =0D =0D =0D = =0D =0D =0D =0D = =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D =0D =0D =0D = =0D =0D =0D =0D =0D
Standard track = documents related to DNSEXT
Proposed Standard.PublishedStatusCommentsprioriity
rfc1886 (AAAA)Dec-95Proposed1(worked on)
rfc1982 (Serial Number Arith)Aug-96Proposed2
rfc1995 (IXFR)Aug-96Proposed3with 1996
rfc1996 (Notify)Aug-96Proposed3with 1995
rfc2065 (DNSSEC)Jan-97Obsoleted by = 253510
rfc2136 = (Dynamic Update)Apr-97Proposed3
rfc2137 (Secure Dynamic Udate)Apr-97Obsoleted by 300710
rfc2181 (Clarify)Jul-97Proposed4
rfc2308 (Neg Caching)Mar-98Proposed5
rfc2535 (DNSSEC)Mar-99Proposed hit by = rfc2535bis10
rfc2536 (DSA Key)Mar-99Proposedhit by rfc2535bis10
rfc2536 (RSA/MD5 Key)Mar-99Obsoleted by 311010
rfc2671 (EDNS0)Aug-99Proposed3
rfc2672 (DNAME)Aug-99Proposed8
rfc2782 (SRV RR)Feb-00Proposed3
rfc2845 (TSIG)May-02Proposed1(worked on)
rfc2930 (TKEY)Sep-00Proposed5
rfc2931 (SIG0)Sep-00Proposed4
rfc3007 (Secure Dynamic = Update)Nov-00Proposed4
rfc3008 (Signing Authority)Nov-00Proposedhit by = rfc2535bis10
rfc3090 (Zone = status)Mar-01Proposedhit by rfc2535bis10
rfc3110 (RSA/SHA1)May-01Proposedhit = by rfc2535bis10
rfc3123 (APL RR)Jun-01Proposed9
rfc3225 (DNSSEC OK)Dec-01Proposedhit by = rfc2535bis10
rfc3226 (Message = size)Dec-01Proposed6
rfc3425 (Obsolete iquery)Nov-00Proposed10
rfc3445 (Restrict Key)Dec-02Proposedhit by rfc2535bis10
rfc3538 (CERT RR)Mar-99Proposed9
rfc3539 (DH key RR)Mar-99Proposed7
Priority:1 = being worked on
2-9 prefered order
10= not being worked on
=0D= =0D=0D=0D=0D= --Apple-Mail-4-350455586-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jul 13 16:40:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05226 for ; Sun, 13 Jul 2003 16:40:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bnVo-0004yI-Cu for namedroppers-data@psg.com; Sun, 13 Jul 2003 20:32:00 +0000 Received: from [144.135.24.138] (helo=mta02bw.bigpond.com) by psg.com with esmtp (Exim 4.14) id 19bnVk-0004xU-UT for namedroppers@ops.ietf.org; Sun, 13 Jul 2003 20:31:57 +0000 Received: from rachel ([144.135.24.72]) by mta02bw.email.bigpond.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0HHZ00KIBD0CZD@mta02bw.email.bigpond.com> for namedroppers@ops.ietf.org; Mon, 14 Jul 2003 06:31:25 +1000 (EST) Received: from cpe-203-51-30-237.nsw.bigpond.net.au ([203.51.30.237]) by bwmam02bpa.bigpond.com(MAM REL_3_3_2c 17/3410108); Mon, 14 Jul 2003 06:31:24 +0000 Date: Mon, 14 Jul 2003 06:25:28 +1000 From: Brad Hards Subject: Re: Transport-independent naming of services In-reply-to: <87u19sgj11.fsf@deneb.enyo.de> To: Florian Weimer , namedroppers@ops.ietf.org Message-id: <200307140625.34921.bhards@bigpond.net.au> MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5.9 References: <87u19sgj11.fsf@deneb.enyo.de> X-Spam-Status: No, hits=-44.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 12 Jul 2003 20:02 pm, Florian Weimer wrote: > A distributed application APP can use various transports (e.g., TCP and > SCTP, or, at a higher level, HTTP, HTTPS, WebDAV, SFTP and FTP) to > access remote resources. Remote resources are identified by a > domain name. > > Can existing DNS RRs be used to describe this scenario in a meaningful > way? Registering a new SRV service doesn't help because the SRV RR > data does not indicate the transport service (just its port number, > which is not enough data). The only approach seems to be to register > SRV service names "APP_http", "APP_https" etc. and to query for all > services the application might support, but this is not very elegant. Apple's approach uses TXT records for supplemental data. Check out http://www.dns-sd.org. I still think that this is mild abuse of DNS, and recommend using SLPv2 (rfc: 2608, http://www.srvloc.org). However that is purely opinion, and you need to evaluate the available options based on your situation. Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/EcA9W6pHgIdAuOMRAu6mAJ42Vg8MMFCSt7FAASkWbx3eT4ocMgCgmIJS iYCR+JrhQ1eQ80GYZqABxdw= =AWTG -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 14 00:00:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13177 for ; Mon, 14 Jul 2003 00:00:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19buQF-0000jZ-K2 for namedroppers-data@psg.com; Mon, 14 Jul 2003 03:54:43 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.14) id 19buQD-0000jM-KJ for namedroppers@ops.ietf.org; Mon, 14 Jul 2003 03:54:41 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h6E3Rpu20149 for ; Sun, 13 Jul 2003 20:27:51 -0700 Date: Sun, 13 Jul 2003 20:27:51 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Request for DNSEXT WG last call on draft-ietf-dnsext-mdns-21.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a request that DNSEXT WG last call be started on draft-ietf-dnsext-mdns-21.txt. At this point, we have not received additional comments on the draft for several weeks, and all known issues have been resolved. See the LLMNR Issues Web Page for details: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 14 18:35:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02143 for ; Mon, 14 Jul 2003 18:35:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cBku-000Mu8-Ac for namedroppers-data@psg.com; Mon, 14 Jul 2003 22:25:12 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.14) id 19cBko-000MtU-MW for namedroppers@ops.ietf.org; Mon, 14 Jul 2003 22:25:06 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h6EMP2h1012934; Mon, 14 Jul 2003 15:25:02 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h6EMP2m8006546; Mon, 14 Jul 2003 15:25:02 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h6EMP0HY006543; Mon, 14 Jul 2003 15:25:00 -0700 (PDT) Date: Mon, 14 Jul 2003 15:25:00 -0700 (PDT) Message-Id: <200307142225.h6EMP0HY006543@guava.araneus.fi> To: namedroppers@ops.ietf.org CC: llmnr-editors@internaut.com Subject: LLMNR Issue: Authority and additional section processing From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_20,RCVD_IN_RFCI version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Authority and additional section processing Submitter name: Andreas Gustafsson Submitter email address: gson@nominum.com Date first submitted: July 14, 2003 Reference: Document: LLMNR-21 Comment type: T Priority: S Section: 2.3, 2.7 Rationale/Explanation of issue: The mdns draft is vague when it comes to how the authority and additional sections of the DNS(-like) message are used. These sections have well-known and well-defined uses in the DNS protocol, but it is far from clear that these are relevant to and appropriate for LLMNR. In particular, section 2.3 currently says: Unicast queries SHOULD be sent when: [...] b. The sender's LLMNR cache contains an NS resource record that enables the sender to send a query directly to the hosts I have several issues with this: 1. Responder behavior The above text seems to assume that responders have NS records and glue address records associated with them and include them in responses. The following text in section 2.7 could be interpreted as requiring the responder to do that: In the additional and authority section of the response the responder includes the same records as a DNS server would insert in the response to the unicast DNS query. However, doing this seems redundant and wasteful - if the responder is authoritative for some given name N, the response NS record would always be of the form "N NS N", which carries no actual information. I also find the requirement to include additional section data "as a DNS server would" problematic. Other parts of the mdns specification takes great care to ensure that LLMNR responders only respond to queries for the name for which it is authoritative, yet the provision for additional section data seems to allow a responder to send additional records whose owner name is not within the server's authority. 2. Sender behavior The text in section 2.3 (b) also seems to assume that senders will have NS records cached, presumably ones responders sent in the authority sections of previous responses. However, the specification does not actually require such caching, and I would argue that it is wasteful for the same reason as sending the NS record is wasteful - it would always be of the form "N NS N" and carry no actual information. 3. Additional failure modes Using unicast based on cached NS records as specified in section 2.3 (b) introduces new failure modes; for example, if a responder detaches from the network and reattaches with a different IP address, queries will be sent to the old address and LLMNR resolution will fail until the NS TTL has expired. 4. Additional security issues If a sender caches arbitrary records from the authority and additional section, this allows a malicious responder to trivially inject information pertaining to another responder in the sender's cache. 5. No reduction in multicast traffic While it may at first glance seem that the text of 2.3 (b) would reduce the amount of multicast traffic, in fact it does not. To illustrate, consider the case of a type A lookup. To avoid the failure mode described above, you would have to make the NS record TTL no longer than the A record TTL, which means the unicast would never actually happen since any time an A record times out in the LLMNR sender's cache, the corresponding NS records have also timed out. On the other hand, if you don't care about the possibility of failure, you can achieve the same reduction in multicast traffic without using NS records, simply by increasing the TTL of the A record. 6. Increased complexity Implementing the logic of 2.3 (b) would needlessly complicate the sender implementation. Requested change: Remove item b. in section 2.3. Remove the following sentence in section 2.7: In the additional and authority section of the response the responder includes the same records as a DNS server would insert in the response to the unicast DNS query. Add a new section as follows: 2.8. Use of the authority and additional sections Unlike the DNS, LLMNR is a peer-to-peer system and does not have a concept of delegation. In LLMNR, the NS resource record type may be stored and queried for like any other type, but it has no special delegation semantics as it does in the DNS. Responders MAY have NS records associated with the names for which they are authoritative, but they SHOULD NOT include these NS records in the authority sections of responses. Responders SHOULD insert an SOA record into the authority section of a negative response, to facilitate negative caching as specified in RFC2308. The owner name of of this SOA record MUST be equal to the query name. Responders SHOULD NOT perform DNS additional section processing. Senders MUST NOT cache RRs from the authority or additional section of a response as answers, though they may be used for other purposes such as negative caching. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 15 02:04:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12547 for ; Tue, 15 Jul 2003 02:04:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cIos-000Ehq-QE for namedroppers-data@psg.com; Tue, 15 Jul 2003 05:57:46 +0000 Received: from [69.140.166.204] (helo=ogud.com) by psg.com with esmtp (Exim 4.14) id 19cIoW-000Eg4-Cs for namedroppers@ops.ietf.org; Tue, 15 Jul 2003 05:57:28 +0000 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h6EF8Sue066683; Mon, 14 Jul 2003 11:08:29 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20030713171053.026b87e0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 14 Jul 2003 11:09:39 -0400 To: Sam Weiler , From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: [IPSECKEY] IPSECKEY inheritance of DNSSEC algorithm registry Cc: ipseckey In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-24.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 19:00 2003-06-17, Sam Weiler wrote: >The IPSECKEY RR definition draft is nearing WG last call -- this would >be a good time to review the document. > >The chairs would particularly like feedback on whether or not the >IPSECKEY record should inherit format definitions from the DNS >Security Algorithm registry -- if someone defines a (DNS)KEY RR format >for Sam's Public Key Algorithm, does it automagically show up as an >IPSECKEY format? > >The text in draft-ietf-ipseckey-rr-04.txt is internally inconsistent, >but the intent with this version was that, yes, the formats are >inherited. To repeat what I said on June 19'th http://www.sandelman.ca/lists/html/ipseckey/msg00201.html There is no way to avoid having different registry, the main reason is we can not guarantee that one registry will contain all algorithms needed. For example IPSEC may adopt ECC while DNSSEC may not, thus IPSECKEY will not be able to inherit ECC wire format from DNS. The format of the registry can be quite simple, IPSECKEY registry entry for algorithm N is that wire format is identical as specified in RFCxxxx section yy. The same comment applies to the registry for DNSKEY in the type code rollover, so that document needs updated IANA considerations section. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 15 02:05:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13623 for ; Tue, 15 Jul 2003 02:05:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cItT-000F55-Af for namedroppers-data@psg.com; Tue, 15 Jul 2003 06:02:31 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.14) id 19cItL-000F3B-R9 for namedroppers@ops.ietf.org; Tue, 15 Jul 2003 06:02:23 +0000 Received: from lapdancer ([129.6.220.34]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h6EE9iw1023147 for ; Mon, 14 Jul 2003 10:09:45 -0400 (EDT) Message-ID: <007001c34a44$00ff9fd0$2ee6a051@lapdancer> From: "Scott Rose" To: Subject: Current status of DNSSECbis questions - Date: Mon, 14 Jul 2003 16:10:37 -0400 Organization: NIST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_20,DATE_IN_FUTURE_06_12 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Below is the same question list I sent out last week, but with the status of discussion (CLOSED or not). And if it is closed, or no longer relevant (see below), the reason why. Q1 - CLOSED resolved Q2 - Should we move DSA to "optional" and have RSA/SHA1 be the only mandatory to implement algorithm? *Consensus? * Q3 - Can we drop the requirement to add the KEY/SIG(KEY) to the additional section of a response? *CLOSED: Consensus seems to be in favor of dropping requirement* Q4 - mistake in numbering, there is no Q4 Q5 - Should algorithm code 252 (now "Indirect") remain, or move it to "Reserved"? *CLOSED: Consensus - Obsoleted by typecode rollover. Useless since there is still no draft describing its use. DNSKEY and KEY would have to have differing IANA algorithm registries. Q6 - Started as "Should sec-aware resolvers cache known "BAD" data"? but now encompasses how servers/resolvers should interpret the CD bit in the DNS header. * No formal consensus reached yet, discussion died out * Q7- Should the DNSSECbis documents discuss use of preconfigured trusted DSs in addition to preconfigured trusted KEYs? *CLOSED: consensus is: sure, why not? * Q8 - Should the apex allow zone KEY RRs only? *CLOSED: Consensus seems to be no restrictions at all on KEY RR placement in a zone * besides, DNSKEY are the zone keys now. Q9 - Dropping the SIG(NXT) from the NXT RRs included in the Auth. section on wildcard and negative replies *CLOSED: Consensus seems to be no allowing of NXT/SIG(NXT) breakup in authority section. Truncate response * Q10 - Silly state - some further elaboration and text will be presented to the list at a later date. Q11 - KEY RRs at delegation point. CLOSED: DNSKEY/KEY would be glue. Not a DNSSEC issue about what to allow as non-auth glue. Local policy about serving and accepting unsigned data would dictate. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 15 05:34:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10349 for ; Tue, 15 Jul 2003 05:34:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cM8S-0001vY-Cc for namedroppers-data@psg.com; Tue, 15 Jul 2003 09:30:12 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19cM8Q-0001vH-5S for namedroppers@ops.ietf.org; Tue, 15 Jul 2003 09:30:10 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09873; Tue, 15 Jul 2003 05:30:03 -0400 (EDT) Message-Id: <200307150930.FAA09873@ietf.org> To: IETF-Announce: ; From: "The IESG" Cc: "RFC Editor" , "Internet Architecture Board" , namedroppers@ops.ietf.org Subject: Protocol Action: GSS Algorithm for TSIG (GSS-TSIG) to Proposed Standard Date: Tue, 15 Jul 2003 05:30:02 -0400 X-Spam-Status: No, hits=-4.0 required=5.0 tests=BAYES_10,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the Internet-Draft 'GSS Algorithm for TSIG (GSS-TSIG)' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 15 05:49:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11162 for ; Tue, 15 Jul 2003 05:49:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cMPB-00037F-1g for namedroppers-data@psg.com; Tue, 15 Jul 2003 09:47:29 +0000 Received: from [216.168.239.87] (helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 4.14) id 19cMP7-00033x-QK for namedroppers@ops.ietf.org; Tue, 15 Jul 2003 09:47:25 +0000 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id 4EBBE9BE21; Tue, 15 Jul 2003 05:46:53 -0400 (EDT) Date: Tue, 15 Jul 2003 05:46:53 -0400 From: Matt Larson To: Namedroppers Mailing List Subject: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver Message-ID: <20030715094653.GA19146@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This question corresponds to editor's note #11 from draft-ietf-dnsext-dnssec-protocol-01. Q-12: Should support for configuring multiple trusted public keys in a security-aware resolver be a MUST rather than a SHOULD? Background: Here is the text in question from Section 4 (page 22) of draft-ietf-dnsext-dnssec-protocol-01: A security-aware resolver MUST be capable of being preconfigured with at least one trusted public key, and SHOULD be capable of being preconfigured with multiple trusted public keys. Since a security- aware resolver will not be able to validate signatures without such a preconfigured trusted key, the resolver SHOULD have some reasonably robust mechanism for obtaining such keys when it boots. Suggested text: It is reasonable to assume the need for multiple trusted public keys during initial DNSSEC deployment as various portions of the name space become secured. A resolver that supported only a single trusted public key would constrain its users. Therefore, the following text is suggested: A security-aware resolver MUST be capable of being preconfigured with multiple trusted public keys. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 15 07:12:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14118 for ; Tue, 15 Jul 2003 07:12:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cNe6-0007ft-Hz for namedroppers-data@psg.com; Tue, 15 Jul 2003 11:06:58 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.14) id 19cNe4-0007fd-0L for namedroppers@ops.ietf.org; Tue, 15 Jul 2003 11:06:56 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) with ESMTP id h6FB6rJE024768 for ; Tue, 15 Jul 2003 13:06:53 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.6/8.12.6/Debian-7) id h6FB6qgm024766 for namedroppers@ops.ietf.org; Tue, 15 Jul 2003 13:06:52 +0200 Date: Tue, 15 Jul 2003 13:06:52 +0200 From: Miek Gieben To: Namedroppers Mailing List Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver Message-ID: <20030715110652.GA24722@atoom.net> Mail-Followup-To: Namedroppers Mailing List References: <20030715094653.GA19146@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030715094653.GA19146@chinook.rgy.netsol.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 15 Jul, @11:46, Matt wrote in "DNSSECbis Q-12: Support for mu ..."] > Suggested text: It is reasonable to assume the need for multiple > trusted public keys during initial DNSSEC deployment as various > portions of the name space become secured. A resolver that supported > only a single trusted public key would constrain its users. > Therefore, the following text is suggested: > > A security-aware resolver MUST be capable of being preconfigured with > multiple trusted public keys. I support this, grtz Miek -- NLnet Labs -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 15 07:22:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14306 for ; Tue, 15 Jul 2003 07:22:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cNpj-0008F1-Ld for namedroppers-data@psg.com; Tue, 15 Jul 2003 11:18:59 +0000 Received: from [213.178.169.5] (helo=ext1.enyo.de) by psg.com with esmtp (Exim 4.14) id 19cNph-0008Ed-0e for namedroppers@ops.ietf.org; Tue, 15 Jul 2003 11:18:57 +0000 Received: from host-212-9-162-162.dial.netic.de ([212.9.162.162] helo=mail.enyo.de) by ext1.enyo.de with asmtp (Exim 4.20) id 19cNpg-000Li8-1f; Tue, 15 Jul 2003 13:18:56 +0200 Received: from [212.9.189.171] (helo=deneb.enyo.de) by mail.enyo.de with esmtp (Exim 4.20) id 19cNpg-0004qs-G6; Tue, 15 Jul 2003 13:18:56 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.20) id 19cNpf-00051f-Io; Tue, 15 Jul 2003 13:18:55 +0200 To: Marcos Sanz/Denic Cc: namedroppers@ops.ietf.org Subject: Re: Transport-independent naming of services References: From: Florian Weimer Mail-Followup-To: Marcos Sanz/Denic , namedroppers@ops.ietf.org Date: Tue, 15 Jul 2003 13:18:55 +0200 In-Reply-To: (Marcos Sanz's message of "Sun, 13 Jul 2003 16:28:34 +0200") Message-ID: <87smp8f36o.fsf@deneb.enyo.de> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-35.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Marcos Sanz/Denic writes: > A "straightforward" use of NAPTR records (NAPSTR) could be the thing you > are looking for: > http://www.ietf.org/internet-drafts/draft-daigle-napstr-02.txt Thanks. This proposal adds the an indirection that straight usage of SRV RRs lacks, and it appears to be sufficient. I still have to check if the protocol ballast is acceptable, though. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 15 10:30:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21656 for ; Tue, 15 Jul 2003 10:30:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cQjM-000Ict-BP for namedroppers-data@psg.com; Tue, 15 Jul 2003 14:24:36 +0000 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.14) id 19cQjB-000IbB-5S for namedroppers@ops.ietf.org; Tue, 15 Jul 2003 14:24:25 +0000 Received: from sandelman.ottawa.on.ca ([2002:51a0:4ed::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6FEOAW15426 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 15 Jul 2003 10:24:13 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6FBomPB012451 for ; Tue, 15 Jul 2003 13:50:48 +0200 To: namedroppers Subject: Security-Aware Recursive Name Server Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 15 Jul 2003 13:50:47 +0200 Message-ID: <12450.1058269847@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,PGP_SIGNATURE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Security-Aware Recursive Name Server = SARNS Or, in homage to Toronto's recent debacle: Security-Aware Recursive Server = SARS Security-Aware Recursive Domain Name server = SARDeeN ] At IETF57 in Wien, Austria | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPxPqlYqHRg3pndX9AQG5ZAP9FQnMGwcUfTYvLRBSr2Sfx9lfPGUVlE5T EYfOEaWFRm4JX3NMCt0hE7uEJ92BBTLNdUjnBJRS/1ptr1+Ipmjo+StG0paADVDD +SCFyzvDv6AKYLc1HoqwVXjdtfsgyKS9eFD+LO4TtfHo+jgRN+TbaWmZADFIFniW 34s9yOcnvXU= =dk7F -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 16 09:51:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00174 for ; Wed, 16 Jul 2003 09:51:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmZn-000OON-T4 for namedroppers-data@psg.com; Wed, 16 Jul 2003 13:44:11 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19cmZk-000OO2-PS for namedroppers@ops.ietf.org; Wed, 16 Jul 2003 13:44:08 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29878; Wed, 16 Jul 2003 09:44:03 -0400 (EDT) Message-Id: <200307161344.JAA29878@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: DNS Extensions to support IP version 6 to Draft Standard Date: Wed, 16 Jul 2003 09:44:03 -0400 X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_20,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has approved the Internet-Draft 'DNS Extensions to support IP version 6' as a Draft Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark Technical Summary This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This Document combines RFC1886 and changes to RFC 1886 made by RFC 3152, obsoleting both. Changes mainly consist in replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152. Working Group Summary There was WG consensus to advance this document. Protocol Quality The specification has been reviewed for the IESG by Erik Nordmark. Submitted Implementation Report can be viewed at http://www.ietf.org/IESG/Implementations/RFC1886-Implementation/rfc1886-Implementation.html RFC Editor note: In the Abstract please change: s/Domain Name System/Domain Name System (DNS)/ s/RFC1886/RFC 1886/ Please add this at the end of the Introduction section: The IP protocol version used for querying resource records is independent of the protocol version of the resource records; e.g. IPv4 transport can be used to query IPv6 records and vice versa. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 16 10:07:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01535 for ; Wed, 16 Jul 2003 10:07:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmsU-000Pv3-US for namedroppers-data@psg.com; Wed, 16 Jul 2003 14:03:30 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.14) id 19cmsN-000Pu5-8U for namedroppers@ops.ietf.org; Wed, 16 Jul 2003 14:03:23 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HI40042UF3P31@eListX.com> for namedroppers@ops.ietf.org; Wed, 16 Jul 2003 10:04:38 -0400 (EDT) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h6GE1jES073976 for ; Wed, 16 Jul 2003 10:01:46 -0400 (EDT envelope-from ogud@ogud.com) Date: Wed, 16 Jul 2003 10:03:12 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: Protocol Action: DNS Extensions to support IP version 6 to Draft Standard In-reply-to: <200307161344.JAA29878@ietf.org> X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030716095758.02aa2d08@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09:44 2003-07-16, The IESG wrote: >The IESG has approved the Internet-Draft 'DNS Extensions to support IP >version 6' as a Draft Standard. This >document is the product of the DNS Extensions Working Group. The IESG >contact persons are Thomas Narten and Erik Nordmark The chairs want to express thanks and gratitude to Mohsen Souissi, Vladimir Ksinant and the other people involved in this effort. that helped with the interoperabilty testing that made it possible for this working group to succeed in advancing this DNSEXT RFC from Draft to Proposed standard good work DNSEXT chairs Olafur & Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 16 10:51:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04670 for ; Wed, 16 Jul 2003 10:51:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cnZH-0002gg-Kj for namedroppers-data@psg.com; Wed, 16 Jul 2003 14:47:43 +0000 Received: from [192.134.4.151] (helo=maya40.nic.fr) by psg.com with esmtp (Exim 4.14) id 19cnZD-0002gO-GQ for namedroppers@ops.ietf.org; Wed, 16 Jul 2003 14:47:39 +0000 Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h6GElWNl603141; Wed, 16 Jul 2003 16:47:32 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h6GElUb28476; Wed, 16 Jul 2003 16:47:30 +0200 Date: Wed, 16 Jul 2003 16:47:30 +0200 From: Mohsen Souissi To: namedroppers@ops.ietf.org Cc: Vladimir Ksinant , rfc2845@nic.fr Subject: RFC 2845 (TSIG) Interop Report Message-ID: <20030716164730.J14763@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=-7.3 required=5.0 tests=BAYES_30,MAILTO_TO_SPAM_ADDR,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, RFC 2845 interoperability tests were performed on June 17th, 2003. Interop report was presented on July 15th, 2003 during dnsext wg session at IETF 57 - Vienna. A preliminary html report is already available at: http://w6.nic.fr/RFC2845/ (dual-stack) As the report is still preliminary, we would much appreciate if you sent us any feedback after reviewing it. If you think you can run further tests in the slave-master category (as documented in the report) so that we could obtain (and report on) more successful tests, please let us know. Also, if you are implementer yourself and believe your implementation does fully support TSIG, please let us know. Please to send/Cc any message related to this topic to: rfc2845@nic.fr so that you could have a reply as soon as possible. Thanks in advance, Mohsen (for RFC2845 Interop Team). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 21 18:44:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13991 for ; Mon, 21 Jul 2003 18:44:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ejDd-000Lu4-US for namedroppers-data@psg.com; Mon, 21 Jul 2003 22:33:21 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.14) id 19ejDZ-000Lto-TE for namedroppers@ops.ietf.org; Mon, 21 Jul 2003 22:33:18 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h6LM5h432557 for ; Mon, 21 Jul 2003 15:05:43 -0700 Date: Mon, 21 Jul 2003 15:05:43 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue #42: Authority and additional section processing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.3 required=5.0 tests=BAYES_30,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue #42 is enclosed below. In my opinion, the changes are compelling, and I would like to propose that they be accepted. Any objections? A version of the draft with the changes applied is available at: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-22.txt ------------------------------------------------------------------------- Issue 42: Authority and additional section processing Submitter name: Andreas Gustafsson Submitter email address: gson@nominum.com Date first submitted: July 14, 2003 Reference: Document: LLMNR-21 Comment type: T Priority: S Section: 2.3, 2.7 Rationale/Explanation of issue: The mdns draft is vague when it comes to how the authority and additional sections of the DNS(-like) message are used. These sections have well-known and well-defined uses in the DNS protocol, but it is far from clear that these are relevant to and appropriate for LLMNR. In particular, section 2.3 currently says: Unicast queries SHOULD be sent when: [...] b. The sender's LLMNR cache contains an NS resource record that enables the sender to send a query directly to the hosts I have several issues with this: 1. Responder behavior The above text seems to assume that responders have NS records and glue address records associated with them and include them in responses. The following text in section 2.7 could be interpreted as requiring the responder to do that: In the additional and authority section of the response the responder includes the same records as a DNS server would insert in the response to the unicast DNS query. However, doing this seems redundant and wasteful - if the responder is authoritative for some given name N, the response NS record would always be of the form "N NS N", which carries no actual information. I also find the requirement to include additional section data "as a DNS server would" problematic. Other parts of the mdns specification takes great care to ensure that LLMNR responders only respond to queries for the name for which it is authoritative, yet the provision for additional section data seems to allow a responder to send additional records whose owner name is not within the server's authority. 2. Sender behavior The text in section 2.3 (b) also seems to assume that senders will have NS records cached, presumably ones responders sent in the authority sections of previous responses. However, the specification does not actually require such caching, and I would argue that it is wasteful for the same reason as sending the NS record is wasteful - it would always be of the form "N NS N" and carry no actual information. 3. Additional failure modes Using unicast based on cached NS records as specified in section 2.3 (b) introduces new failure modes; for example, if a responder detaches from the network and reattaches with a different IP address, queries will be sent to the old address and LLMNR resolution will fail until the NS TTL has expired. 4. Additional security issues If a sender caches arbitrary records from the authority and additional section, this allows a malicious responder to trivially inject information pertaining to another responder in the sender's cache. 5. No reduction in multicast traffic While it may at first glance seem that the text of 2.3 (b) would reduce the amount of multicast traffic, in fact it does not. To illustrate, consider the case of a type A lookup. To avoid the failure mode described above, you would have to make the NS record TTL no longer than the A record TTL, which means the unicast would never actually happen since any time an A record times out in the LLMNR sender's cache, the corresponding NS records have also timed out. On the other hand, if you don't care about the possibility of failure, you can achieve the same reduction in multicast traffic without using NS records, simply by increasing the TTL of the A record. 6. Increased complexity Implementing the logic of 2.3 (b) would needlessly complicate the sender implementation. Requested change: Remove item b. in section 2.3. Remove the following sentence in section 2.7: In the additional and authority section of the response the responder includes the same records as a DNS server would insert in the response to the unicast DNS query. Add a new section as follows: 2.8. Use of the authority and additional sections Unlike the DNS, LLMNR is a peer-to-peer system and does not have a concept of delegation. In LLMNR, the NS resource record type may be stored and queried for like any other type, but it has no special delegation semantics as it does in the DNS. Responders MAY have NS records associated with the names for which they are authoritative, but they SHOULD NOT include these NS records in the authority sections of responses. Responders SHOULD insert an SOA record into the authority section of a negative response, to facilitate negative caching as specified in RFC2308. The owner name of of this SOA record MUST be equal to the query name. Responders SHOULD NOT perform DNS additional section processing. Senders MUST NOT cache RRs from the authority or additional section of a response as answers, though they may be used for other purposes such as negative caching. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 22 07:01:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09274 for ; Tue, 22 Jul 2003 07:01:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eumS-0007mH-Vc for namedroppers-data@psg.com; Tue, 22 Jul 2003 10:54:04 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.14) id 19eumJ-0007le-Qi for namedroppers@ops.ietf.org; Tue, 22 Jul 2003 10:53:55 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h6MArrgh024984 for ; Tue, 22 Jul 2003 12:53:54 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h6MArqqJ024980 for ; Tue, 22 Jul 2003 12:53:53 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 22 Jul 2003 12:53:52 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Namedroppers Mailing List Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver In-Reply-To: <20030715094653.GA19146@chinook.rgy.netsol.com> Message-ID: References: <20030715094653.GA19146@chinook.rgy.netsol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-39.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 15 Jul 2003, Matt Larson wrote: > This question corresponds to editor's note #11 from > draft-ietf-dnsext-dnssec-protocol-01. > > Q-12: Should support for configuring multiple trusted public keys in a > security-aware resolver be a MUST rather than a SHOULD? > > Background: Here is the text in question from Section 4 (page 22) of > draft-ietf-dnsext-dnssec-protocol-01: > > A security-aware resolver MUST be capable of being preconfigured with > at least one trusted public key, and SHOULD be capable of being > preconfigured with multiple trusted public keys. Since a security- > aware resolver will not be able to validate signatures without such a > preconfigured trusted key, the resolver SHOULD have some reasonably > robust mechanism for obtaining such keys when it boots. > > Suggested text: It is reasonable to assume the need for multiple > trusted public keys during initial DNSSEC deployment as various > portions of the name space become secured. A resolver that supported > only a single trusted public key would constrain its users. > Therefore, the following text is suggested: > > A security-aware resolver MUST be capable of being preconfigured with > multiple trusted public keys. I support the suggested change. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 22 07:46:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10303 for ; Tue, 22 Jul 2003 07:46:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19evXn-000A0c-Pv for namedroppers-data@psg.com; Tue, 22 Jul 2003 11:42:59 +0000 Received: from [68.71.251.111] (helo=osprey.the-paynes.com) by psg.com with esmtp (Exim 4.14) id 19evXd-000A08-Oe for namedroppers@ops.ietf.org; Tue, 22 Jul 2003 11:42:49 +0000 Received: from osprey.the-paynes.com (localhost [127.0.0.1]) by osprey.the-paynes.com (8.12.8/8.12.8) with ESMTP id h6MBgjXh002521 for ; Tue, 22 Jul 2003 07:42:45 -0400 Received: (from repayne@localhost) by osprey.the-paynes.com (8.12.8/8.12.8/Submit) id h6MBgjM1002520 for namedroppers@ops.ietf.org; Tue, 22 Jul 2003 07:42:45 -0400 Date: Tue, 22 Jul 2003 07:42:45 -0400 From: Rob Payne To: Namedroppers Mailing List Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver Message-ID: <20030722114245.GA19478@osprey.the-paynes.com> References: <20030715094653.GA19146@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20030715094653.GA19146@chinook.rgy.netsol.com> User-Agent: Mutt/1.4.1i X-Use-Encryption: Encrypted email preferred (see www.gnupg.org) X-GnuPG-Keyid: 9B6E7165 X-GnuPG-Fingerprint: D42C ACC0 CA2A B7D5 7A01 A43F 80B5 FBFE 9B6E 7165 X-Spam-Status: No, hits=-45.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2003 at 05:46:53AM -0400, Matt Larson wrote: > This question corresponds to editor's note #11 from > draft-ietf-dnsext-dnssec-protocol-01. >=20 > Q-12: Should support for configuring multiple trusted public keys in a > security-aware resolver be a MUST rather than a SHOULD? >=20 > Background: Here is the text in question from Section 4 (page 22) of > draft-ietf-dnsext-dnssec-protocol-01: >=20 > A security-aware resolver MUST be capable of being preconfigured with > at least one trusted public key, and SHOULD be capable of being > preconfigured with multiple trusted public keys. Since a security- > aware resolver will not be able to validate signatures without such a > preconfigured trusted key, the resolver SHOULD have some reasonably > robust mechanism for obtaining such keys when it boots. >=20 > Suggested text: It is reasonable to assume the need for multiple > trusted public keys during initial DNSSEC deployment as various > portions of the name space become secured. A resolver that supported > only a single trusted public key would constrain its users. > Therefore, the following text is suggested: >=20 > A security-aware resolver MUST be capable of being preconfigured with > multiple trusted public keys. I support this text. -rob --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/HSM1gLX7/ptucWURAqOQAJ9owpykO4hpzSlf9E+Xkx0WVKL6FACfeMWR mItAxWLDz+EOvoYFPGIGUQo= =9M5h -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 22 18:24:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29407 for ; Tue, 22 Jul 2003 18:24:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19f5QD-0003Dk-Uw for namedroppers-data@psg.com; Tue, 22 Jul 2003 22:15:49 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.14) id 19f5QB-0003DY-R4 for namedroppers@ops.ietf.org; Tue, 22 Jul 2003 22:15:47 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HIG0000F5WI7I@eListX.com> for namedroppers@ops.ietf.org; Tue, 22 Jul 2003 18:17:07 -0400 (EDT) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h6MMGUjE005557 for ; Tue, 22 Jul 2003 18:16:30 -0400 (EDT envelope-from ogud@ogud.com) Date: Tue, 22 Jul 2003 18:15:25 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT WGLC: Case Insensitive X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030722180157.02ca8730@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This starts a working group last call on this draft: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-03.txt This document clarifies RFC1035 in regards to what values in a Domain Name are affected by case insensitivity rules. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-03.txt This document is on standards track. Please send in any comments/support/opposition to this document to namedroppers mailing list by August 7'th. Silence on this draft will be considered as support to advance it. Olafur and Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jul 22 22:25:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03483 for ; Tue, 22 Jul 2003 22:25:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19f9Cq-000F6P-09 for namedroppers-data@psg.com; Wed, 23 Jul 2003 02:18:16 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.14) id 19f9Cm-000F6D-V8 for namedroppers@ops.ietf.org; Wed, 23 Jul 2003 02:18:13 +0000 Received: from lapdancer (asynce001.nist.gov [129.6.31.1]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h6N2Htw3000038 for ; Tue, 22 Jul 2003 22:17:59 -0400 (EDT) Message-ID: <000401c350c0$bafde450$011f0681@lapdancer> From: "Scott Rose" To: "Namedroppers Mailing List" References: <20030715094653.GA19146@chinook.rgy.netsol.com> Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver Date: Tue, 22 Jul 2003 14:51:16 -0400 Organization: NIST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.2 required=5.0 tests=BAYES_01,DATE_IN_PAST_06_12,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To keep the text in line with a previous consensus - it should read "public key or DS RR" instead of just the public key. Minor change, but bring it in line with the possibility that a resolver could be configured with multiple DS RRs instead of public keys. Scott ----- Original Message ----- From: "Roy Arends" To: "Namedroppers Mailing List" Sent: Tuesday, July 22, 2003 6:53 AM Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver > On Tue, 15 Jul 2003, Matt Larson wrote: > > > This question corresponds to editor's note #11 from > > draft-ietf-dnsext-dnssec-protocol-01. > > > > Q-12: Should support for configuring multiple trusted public keys in a > > security-aware resolver be a MUST rather than a SHOULD? > > > > Background: Here is the text in question from Section 4 (page 22) of > > draft-ietf-dnsext-dnssec-protocol-01: > > > > A security-aware resolver MUST be capable of being preconfigured with > > at least one trusted public key, and SHOULD be capable of being > > preconfigured with multiple trusted public keys. Since a security- > > aware resolver will not be able to validate signatures without such a > > preconfigured trusted key, the resolver SHOULD have some reasonably > > robust mechanism for obtaining such keys when it boots. > > > > Suggested text: It is reasonable to assume the need for multiple > > trusted public keys during initial DNSSEC deployment as various > > portions of the name space become secured. A resolver that supported > > only a single trusted public key would constrain its users. > > Therefore, the following text is suggested: > > > > A security-aware resolver MUST be capable of being preconfigured with > > multiple trusted public keys. > > I support the suggested change. > > Roy > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 23 10:27:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14907 for ; Wed, 23 Jul 2003 10:27:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fKQN-0000Ea-ML for namedroppers-data@psg.com; Wed, 23 Jul 2003 14:16:59 +0000 Received: from [192.52.233.66] (helo=mlbxsmtp2.harris.com) by psg.com with esmtp (Exim 4.14) id 19fKQ3-0000Cv-AB for namedroppers@ops.ietf.org; Wed, 23 Jul 2003 14:16:39 +0000 Received: from mail pickup service by mlbxsmtp2.harris.com with Microsoft SMTPSVC; Wed, 23 Jul 2003 10:16:08 -0400 Received: from mlbxsmtp1.harris.com ([192.52.233.68]) by mlbxsmtp2.harris.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 22:27:16 -0400 Received: from psg.com ([147.28.0.62]) by mlbxsmtp1.harris.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 22:27:14 -0400 Received: from lserv by psg.com with local (Exim 4.14) id 19f9Cq-000F6P-09 for namedroppers-data@psg.com; Wed, 23 Jul 2003 02:18:16 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.14) id 19f9Cm-000F6D-V8 for namedroppers@ops.ietf.org; Wed, 23 Jul 2003 02:18:13 +0000 Received: from lapdancer (asynce001.nist.gov [129.6.31.1]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h6N2Htw3000038 for ; Tue, 22 Jul 2003 22:17:59 -0400 (EDT) Message-ID: <000401c350c0$bafde450$011f0681@lapdancer> From: "Scott Rose" To: "Namedroppers Mailing List" References: <20030715094653.GA19146@chinook.rgy.netsol.com> Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver Date: Tue, 22 Jul 2003 14:51:16 -0400 Organization: NIST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Jul 2003 02:27:14.0964 (UTC) FILETIME=[EE130540:01C350C1] X-Spam-Status: No, hits=-16.2 required=5.0 tests=BAYES_01,DATE_IN_PAST_06_12,QUOTED_EMAIL_TEXT,REFERENCES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To keep the text in line with a previous consensus - it should read "public key or DS RR" instead of just the public key. Minor change, but bring it in line with the possibility that a resolver could be configured with multiple DS RRs instead of public keys. Scott ----- Original Message ----- From: "Roy Arends" To: "Namedroppers Mailing List" Sent: Tuesday, July 22, 2003 6:53 AM Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver > On Tue, 15 Jul 2003, Matt Larson wrote: > > > This question corresponds to editor's note #11 from > > draft-ietf-dnsext-dnssec-protocol-01. > > > > Q-12: Should support for configuring multiple trusted public keys in a > > security-aware resolver be a MUST rather than a SHOULD? > > > > Background: Here is the text in question from Section 4 (page 22) of > > draft-ietf-dnsext-dnssec-protocol-01: > > > > A security-aware resolver MUST be capable of being preconfigured with > > at least one trusted public key, and SHOULD be capable of being > > preconfigured with multiple trusted public keys. Since a security- > > aware resolver will not be able to validate signatures without such a > > preconfigured trusted key, the resolver SHOULD have some reasonably > > robust mechanism for obtaining such keys when it boots. > > > > Suggested text: It is reasonable to assume the need for multiple > > trusted public keys during initial DNSSEC deployment as various > > portions of the name space become secured. A resolver that supported > > only a single trusted public key would constrain its users. > > Therefore, the following text is suggested: > > > > A security-aware resolver MUST be capable of being preconfigured with > > multiple trusted public keys. > > I support the suggested change. > > Roy > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 23 10:43:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15494 for ; Wed, 23 Jul 2003 10:43:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fKjE-0001B1-W1 for namedroppers-data@psg.com; Wed, 23 Jul 2003 14:36:28 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.14) id 19fKjC-0001Al-GE for namedroppers@ops.ietf.org; Wed, 23 Jul 2003 14:36:26 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h6NEaMCx026943; Wed, 23 Jul 2003 16:36:22 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h6NEaMMr026939; Wed, 23 Jul 2003 16:36:22 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 23 Jul 2003 16:36:22 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Scott Rose cc: Namedroppers Mailing List Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver In-Reply-To: <000401c350c0$bafde450$011f0681@lapdancer> Message-ID: References: <20030715094653.GA19146@chinook.rgy.netsol.com> <000401c350c0$bafde450$011f0681@lapdancer> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-36.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 22 Jul 2003, Scott Rose wrote: > To keep the text in line with a previous consensus - it should read "public > key or DS RR" instead of just the public key. Minor change, but bring it in > line with the possibility that a resolver could be configured with multiple > DS RRs instead of public keys. I agree, and a note that a mix of DS/KEY is possible as well. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jul 23 15:23:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26004 for ; Wed, 23 Jul 2003 15:23:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fP57-000JHP-6a for namedroppers-data@psg.com; Wed, 23 Jul 2003 19:15:21 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19fP53-000JHD-JL for namedroppers@ops.ietf.org; Wed, 23 Jul 2003 19:15:17 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25019; Wed, 23 Jul 2003 15:14:07 -0400 (EDT) Message-Id: <200307231914.PAA25019@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-mdns-22.txt Date: Wed, 23 Jul 2003 15:14:06 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-22.txt Pages : 21 Date : 2003-7-23 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name Service (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-22.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-22.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-mdns-22.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: <2003-7-23150905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-23150905.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 24 14:40:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20796 for ; Thu, 24 Jul 2003 14:40:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fktN-000KN8-UQ for namedroppers-data@psg.com; Thu, 24 Jul 2003 18:32:41 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19fktG-000KKd-L4 for namedroppers@ops.ietf.org; Thu, 24 Jul 2003 18:32:35 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20209; Thu, 24 Jul 2003 14:31:57 -0400 (EDT) Message-Id: <200307241831.OAA20209@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-keyrr-key-signing-flag-08.txt Date: Thu, 24 Jul 2003 14:31:57 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : KEY RR Secure Entry Point (SEP) Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-08.txt Pages : 10 Date : 2003-7-24 With the DS resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-keyrr-key-signing-flag-08.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-keyrr-key-signing-flag-08.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: <2003-7-24122242.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122242.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 25 10:18:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06807 for ; Fri, 25 Jul 2003 10:18:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g3H4-0000eK-0C for namedroppers-data@psg.com; Fri, 25 Jul 2003 14:10:22 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.14) id 19g3Gj-0000ao-4r for namedroppers@ops.ietf.org; Fri, 25 Jul 2003 14:10:01 +0000 Received: from ogud.com (pcp04400154pcs.nrockv01.md.comcast.net [69.140.166.204]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HIL00BGY3EZN6@eListX.com> for namedroppers@ops.ietf.org; Fri, 25 Jul 2003 10:11:23 -0400 (EDT) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h6PEAKjE014922; Fri, 25 Jul 2003 10:10:21 -0400 (EDT envelope-from ogud@ogud.com) Date: Fri, 25 Jul 2003 10:09:35 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver (fwd) X-Sender: post@localhost To: namedroppers@ops.ietf.org Cc: Sam Weiler Message-id: <5.1.1.6.2.20030725100713.02408ba0@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sam has been unable to post this on namedroppers himself, so he asked me to forward this message. Olafur >Date: Tue, 22 Jul 2003 18:10:28 -0400 (EDT) >From: Sam Weiler >To: namedroppers@ops.ietf.org >Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys > in a security-aware resolver (fwd) [I've seen this bounce twice. If it actually got through and you're seeing a duplicate, my apologies.] > Q-12: Should support for configuring multiple trusted public keys in a > security-aware resolver be a MUST rather than a SHOULD? A security aware resolver is unlikely to be very useful without this capability, but does omiting it negatively impact the protocol? It doesn't affect the on-the-wire bits. "Constraining users" doesn't justify a MUST. If, however, having only one configured key would effectively prevent key rollover (as in, rollover of the one true root key), then we need to be concerned. Imagine this scenario: the root wants to roll its key. Having clients with only one configurable key mean that the root must sign with both keys during the transition window. If all clients can configure multiple keys, they can add the new one before it's actually in use, the root can make the change all at once, and everyone who has updated their keys keeps on going, removing the old keys at their leisure. Is it valuable for the root (or any zone who's key will be configured in end clients) to be able to roll over all at once? With the layer of indirection (SEP/ZSK) introduced by DS, it's not manadatory -- it's tractable to sign a KEYset with multiple KEYs for an extended time. Except that those extra signatures may make packets big. With 2535, if the secure entry point was, say, .com, then keeping the whole zone signed with multiple keys would not be tractable. Summary: I don't see a jutification for a MUST. Or even a SHOULD. This is implementation advice, not protocol requirement. It should be there, but it's not critical to interoperability. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jul 25 10:35:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07728 for ; Fri, 25 Jul 2003 10:35:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g3Zg-0001vX-BE for namedroppers-data@psg.com; Fri, 25 Jul 2003 14:29:36 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.14) id 19g3ZZ-0001uh-0U for namedroppers@ops.ietf.org; Fri, 25 Jul 2003 14:29:29 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id CC6DB56824; Fri, 25 Jul 2003 07:29:14 -0700 (PDT) Message-Id: <6.0.0.12.2.20030725102438.0213f3d0@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.12 (Beta) Date: Fri, 25 Jul 2003 10:29:17 -0400 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver (fwd) Cc: Sam Weiler In-Reply-To: <5.1.1.6.2.20030725100713.02408ba0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-22.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Sorry - wrong answer. MUST is correct. MUST is used to indicate features to implementers that if omitted,=20 adversely affect the operation of the protocol *or system*. While the=20 omission of this might not have an adverse affect on the protocol bits on=20 wire stuff, it most definitely does have an effect on the system. This is not a key rollover issue - its an island of trust issue. There=20 will not be one true root for a long time to come and a resolver needs to=20 be able to configure multiple trust anchors at different points in the tree. Mike At 10:09 7/25/2003, =D3lafur Gu=F0mundsson wrote: >Sam has been unable to post this on namedroppers himself, so he asked me >to forward this message. > > Olafur > >>Date: Tue, 22 Jul 2003 18:10:28 -0400 (EDT) >>From: Sam Weiler >>To: namedroppers@ops.ietf.org >>Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public= keys >> in a security-aware resolver (fwd) > >[I've seen this bounce twice. If it actually got through and you're >seeing a duplicate, my apologies.] > > > Q-12: Should support for configuring multiple trusted public keys in a > > security-aware resolver be a MUST rather than a SHOULD? > >A security aware resolver is unlikely to be very useful without this >capability, but does omiting it negatively impact the protocol? It >doesn't affect the on-the-wire bits. "Constraining users" doesn't >justify a MUST. If, however, having only one configured key would >effectively prevent key rollover (as in, rollover of the one true root >key), then we need to be concerned. > >Imagine this scenario: the root wants to roll its key. Having >clients with only one configurable key mean that the root must sign >with both keys during the transition window. If all clients can >configure multiple keys, they can add the new one before it's actually >in use, the root can make the change all at once, and everyone who has >updated their keys keeps on going, removing the old keys at their >leisure. Is it valuable for the root (or any zone who's key will be >configured in end clients) to be able to roll over all at once? With >the layer of indirection (SEP/ZSK) introduced by DS, it's not >manadatory -- it's tractable to sign a KEYset with multiple KEYs for >an extended time. Except that those extra signatures may make packets >big. With 2535, if the secure entry point was, say, .com, then >keeping the whole zone signed with multiple keys would not be >tractable. > >Summary: I don't see a jutification for a MUST. Or even a SHOULD. >This is implementation advice, not protocol requirement. It should be >there, but it's not critical to interoperability. > >-- Sam > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 28 10:32:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03284 for ; Mon, 28 Jul 2003 10:32:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19h8sj-000PaM-3n for namedroppers-data@psg.com; Mon, 28 Jul 2003 14:21:45 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.20) id 19h8sf-000Pa9-D3 for namedroppers@ops.ietf.org; Mon, 28 Jul 2003 14:21:41 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h6SELKGi018496 for ; Mon, 28 Jul 2003 10:21:21 -0400 (EDT) Message-ID: <003d01c35513$850012e0$b9370681@barnacle> From: "Scott Rose" To: References: <5.1.1.6.2.20030725100713.02408ba0@localhost> Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver (fwd) Date: Mon, 28 Jul 2003 10:21:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-11.9 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I agree with StJohns on this. It should be a MUST. If a resolver cannot handle 2 or more pre-configured DNSKEY RRs, There is no way it can handle more than one island of security, or even more than one signing algorithm. I believe that the text should state that support for multiple preconfigured DNSKEY/DS hash be a MUST. Scott ----- Original Message ----- From: "Ólafur Guðmundsson" To: Cc: "Sam Weiler" Sent: Friday, July 25, 2003 10:09 AM Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys in a security-aware resolver (fwd) > > Sam has been unable to post this on namedroppers himself, so he asked me > to forward this message. > > Olafur > > >Date: Tue, 22 Jul 2003 18:10:28 -0400 (EDT) > >From: Sam Weiler > >To: namedroppers@ops.ietf.org > >Subject: Re: DNSSECbis Q-12: Support for multiple preconfigured public keys > > in a security-aware resolver (fwd) > > [I've seen this bounce twice. If it actually got through and you're > seeing a duplicate, my apologies.] > > > Q-12: Should support for configuring multiple trusted public keys in a > > security-aware resolver be a MUST rather than a SHOULD? > > A security aware resolver is unlikely to be very useful without this > capability, but does omiting it negatively impact the protocol? It > doesn't affect the on-the-wire bits. "Constraining users" doesn't > justify a MUST. If, however, having only one configured key would > effectively prevent key rollover (as in, rollover of the one true root > key), then we need to be concerned. > > Imagine this scenario: the root wants to roll its key. Having > clients with only one configurable key mean that the root must sign > with both keys during the transition window. If all clients can > configure multiple keys, they can add the new one before it's actually > in use, the root can make the change all at once, and everyone who has > updated their keys keeps on going, removing the old keys at their > leisure. Is it valuable for the root (or any zone who's key will be > configured in end clients) to be able to roll over all at once? With > the layer of indirection (SEP/ZSK) introduced by DS, it's not > manadatory -- it's tractable to sign a KEYset with multiple KEYs for > an extended time. Except that those extra signatures may make packets > big. With 2535, if the secure entry point was, say, .com, then > keeping the whole zone signed with multiple keys would not be > tractable. > > Summary: I don't see a jutification for a MUST. Or even a SHOULD. > This is implementation advice, not protocol requirement. It should be > there, but it's not critical to interoperability. > > -- Sam > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 28 11:08:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04992 for ; Mon, 28 Jul 2003 11:08:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19h9Z8-0002hP-Hi for namedroppers-data@psg.com; Mon, 28 Jul 2003 15:05:34 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19h9Z4-0002gf-99 for namedroppers@ops.ietf.org; Mon, 28 Jul 2003 15:05:30 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04218; Mon, 28 Jul 2003 11:05:25 -0400 (EDT) Message-Id: <200307281505.LAA04218@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-ipv6-name-auto-reg-01.txt Date: Mon, 28 Jul 2003 11:05:24 -0400 X-Spam-Status: No, hits=3.1 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Domain Name Auto-Registration for Plugged-in IPv6 Nodes Author(s) : H. Kitamura Filename : draft-ietf-dnsext-ipv6-name-auto-reg-01.txt Pages : 21 Date : 2003-7-28 This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. Since IPv6 addresses are too long to remember and EUI64-based addresses are too complicated to remember, there are strong requirements to use logical names that are easy to remember instead of IPv6 addresses to specify IPv6 nodes and to register domain name information of plugged-in IPv6 nodes automatically. In order to meet the requirements, a mechanism is proposed as one of the IPv6 auto-configuration (plug and play) functions. After the Address Autoconfiguration [ADDR-AUTO] has been executed, it works as a succeeding plug and play mechanism. This document clarifies problems that we meet when we apply the Dynamic Updates in the DNS [DYN-DNS] to automatic domain name information registration mechanisms. This document describes the Domain Name Auto-Registration mechanism as a solution to these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ipv6-name-auto-reg-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-ipv6-name-auto-reg-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: <2003-7-28111044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ipv6-name-auto-reg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-28111044.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 28 13:29:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13449 for ; Mon, 28 Jul 2003 13:29:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hBiW-000CeB-KL for namedroppers-data@psg.com; Mon, 28 Jul 2003 17:23:24 +0000 Received: from [2001:4f8:4:d:290:27ff:fef7:1ad8] (helo=skid.isc.org) by psg.com with esmtp (Exim 4.20) id 19hBiT-000Cdm-Mt for namedroppers@ops.ietf.org; Mon, 28 Jul 2003 17:23:21 +0000 Received: from farside.isc.org (farside.isc.org [2001:4f8:3:bb:290:27ff:fe73:8215]) by skid.isc.org (Postfix) with ESMTP id 360188D623 for ; Mon, 28 Jul 2003 17:21:33 +0000 (UTC) (envelope-from weiler@tislabs.com) Received: from dhcp-149.isc.org (dhcp-149.isc.org [204.152.187.149]) by farside.isc.org (Postfix) with ESMTP id 4821FA85D for ; Mon, 28 Jul 2003 17:23:21 +0000 (UTC) (envelope-from weiler@tislabs.com) Date: Mon, 28 Jul 2003 10:23:12 -0700 (PDT) From: Samuel Weiler X-X-Sender: weiler@localhost.localdomain To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-10.5 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Here's another message that kept bouncing.] (Possibly reopening Q-9. Sorrry, Scott.) > More importantly, separating SIGs from what they sign is something to > avoid. Whenever you separate a SIG, you run into the possibility that > the SIG you subsequently fetch will be for another version of the > data. When the SIG doesn't verify, the validator must not treat that > as a failure of validation, but instead must refetch both data and its > SIG and try again. Given that the validator action when presented with an NXT and no SIG(NXT) will probably be to query for that NXT, not SIG, is this worry mitigated? The (possibly new) data and accompanying SIG will arrive atomically, and the new NXT will replace any stale NXT. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 28 13:54:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14103 for ; Mon, 28 Jul 2003 13:54:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hC9i-000EfD-Lk for namedroppers-data@psg.com; Mon, 28 Jul 2003 17:51:30 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.20) id 19hC9e-000Edn-PZ for namedroppers@ops.ietf.org; Mon, 28 Jul 2003 17:51:26 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 13FAC18E3 for ; Mon, 28 Jul 2003 13:50:25 -0400 (EDT) Date: Mon, 28 Jul 2003 13:50:25 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response. In-Reply-To: References: User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030728175025.13FAC18E3@thrintun.hactrn.net> X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 28 Jul 2003 10:23:12 -0700 (PDT), Sam Weiler wrote: > > [Here's another message that kept bouncing.] > > (Possibly reopening Q-9. Sorrry, Scott.) > > > More importantly, separating SIGs from what they sign is something to > > avoid. Whenever you separate a SIG, you run into the possibility that > > the SIG you subsequently fetch will be for another version of the > > data. When the SIG doesn't verify, the validator must not treat that > > as a failure of validation, but instead must refetch both data and its > > SIG and try again. > > Given that the validator action when presented with an NXT and no SIG(NXT) > will probably be to query for that NXT, not SIG, is this worry mitigated? > The (possibly new) data and accompanying SIG will arrive atomically, and > the new NXT will replace any stale NXT. This eliminates the version skew problem between the NXT and the SIG(NXT), but now you you have the version skew problem between the original RCODE and the requeried NXT/SIG(NXT). The fundamental issue here is that SIG and NXT are part of what one might call an "answer blob" (the collection of conceptually related stuff that one gets back in response to a particular query at a particular time), and requerying for just part of an answer blob always opens up the possibility of a version skew. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jul 28 18:10:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22836 for ; Mon, 28 Jul 2003 18:10:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hG5h-00050M-0s for namedroppers-data@psg.com; Mon, 28 Jul 2003 22:03:37 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.20) id 19hG5e-000506-0E for namedroppers@ops.ietf.org; Mon, 28 Jul 2003 22:03:34 +0000 Received: by shell-ng.nominum.com (Postfix, from userid 1411) id 46EF456845; Mon, 28 Jul 2003 15:03:33 -0700 (PDT) To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response. References: <20030728175025.13FAC18E3@thrintun.hactrn.net> From: Bob Halley Date: 28 Jul 2003 15:03:33 -0700 In-Reply-To: <20030728175025.13FAC18E3@thrintun.hactrn.net> Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: > The fundamental issue here is that SIG and NXT are part of what one > might call an "answer blob" (the collection of conceptually related > stuff that one gets back in response to a particular qclass> query at a particular time), and requerying for just part of > an answer blob always opens up the possibility of a version skew. Also, every time you add more cases that you expect the validator to deal with, the more likely it is that implementors will forget a case, produce an incorrect validation, crash the server, etc. It also makes it harder for people to validate the validator by auditing the code. For all these reasons, I think we should be trying to make things as simple as possible for the validator. /Bob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 31 10:05:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26434 for ; Thu, 31 Jul 2003 10:05:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iDso-000MPx-If for namedroppers-data@psg.com; Thu, 31 Jul 2003 13:54:18 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19iDsk-000MPf-GR for namedroppers@ops.ietf.org; Thu, 31 Jul 2003 13:54:14 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25705; Thu, 31 Jul 2003 09:54:10 -0400 (EDT) Message-Id: <200307311354.JAA25705@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-rfc2536bis-dsa-03.txt Date: Thu, 31 Jul 2003 09:54:10 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : DSA Keying and Signature Information in the DNS Author(s) : D. Eastlake Filename : draft-ietf-dnsext-rfc2536bis-dsa-03.txt Pages : 7 Date : 2003-7-31 A standard method of encoding US Government Digital Signature Algorithm keying and signature information is described for use in the Domain Name System. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-rfc2536bis-dsa-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-rfc2536bis-dsa-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: <2003-7-31101226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2536bis-dsa-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2536bis-dsa-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-31101226.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jul 31 23:07:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22683 for ; Thu, 31 Jul 2003 23:07:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iQ9D-000CdQ-IZ for namedroppers-data@psg.com; Fri, 01 Aug 2003 03:00:03 +0000 Received: from randy by psg.com with local (Exim 4.20) id 19iQ9A-000Ccs-Id for namedroppers@ops.ietf.org; Fri, 01 Aug 2003 03:00:00 +0000 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Fri, 01 Aug 2003 03:00:00 +0000 X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. posts are only accepted from subscribers. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have your alternate address added to the list of addresses from which submissions are automatically accepted. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: