From owner-namedroppers@opsmail.internic.net Mon Jan 3 01:21:18 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17022 for ; Mon, 3 Jan 2000 01:21:18 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id WAA09667 for namedroppers-outgoing; Sun, 2 Jan 2000 22:21:41 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id WAA09625 for ; Sun, 2 Jan 2000 22:21:40 -0500 (EST) Date: Sun, 2 Jan 2000 22:21:40 -0500 (EST) From: randy@psg.com Message-Id: <200001030321.WAA09625@opsmail.internic.net> Received: (qmail 29972 invoked from network); 3 Jan 2000 03:21:39 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.15 with SMTP; 3 Jan 2000 03:21:39 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 124y3v-000OMM-00 for namedroppers@internic.net; Sun, 02 Jan 2000 19:21:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit (EST) Message-Id: <199912302002.PAA04627@ietf.org> From: The IESG To: IETF-Announce: ; cc: namedroppers@internic.net Subject: WG ACTION: DNS Extensions (dnsext) Date: Thu, 30 Dec 1999 15:02:59 -0500 A new working group has been formed in the Internet Area of the IETF. For additional information, contact the Area Directors or the WG Chair. DNS Extensions (dnsext) ----------------------- Current Status: Active Working Group Chair(s): Olafur Gudmundsson Randy Bush Internet Area Director(s): Thomas Narten Erik Nordmark Internet Area Advisor: Erik Nordmark Mailing Lists: General Discussion:namedroppers@internic.net To Subscribe: namedroppers-request@internic.net Archive: ftp://rs.internic.net/archives/namedroppers Description of Working Group: The DNSEXT Working Group has assumed the RFCs and drafts of both the DNSSEC and DNSIND working groups. DNS is originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are protocol issues, including message formats, message handling, and data formats. New work items and milestones may be added from time-to-time with the approval of the Working Group and the IESG. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter. These issues are considered in other venues, such as operational issues in the DNS Operations Working Group. Broad topics under consideration in DNSEXT are dynamic update, notify, zone transfers, security and adjustments to address the requirements of IPv6 addressing. Security topics, mostly inherited from the erstwhile DNS Security Extensions Working Group, will be addressed in cooperation with the DNS Operations Working Group. The principal task within this Working Group is to advance several documents describing proposed extensions to DNS. The current list of documents under consideration for advancement is: Title RFC Status DNS Server MIB Extensions RFC1611 Proposed DNS Resolver MIB Extensions RFC1612 Proposed Serial Number Arithmetic RFC1982 Proposed Incremental Zone transfer RFC1995 Proposed Notify RFC1996 Proposed DNS SRV service location RFC2052 Experimental Dynamic Update RFC2136 Proposed Security for Dynamic Update RFC2137 Proposed Clarification to DNS RFC2181 Proposed Negative Caching RFC2308 Proposed DNS Security Extensions RFC2535 Proposed DSA KEYs and SIGs RFC2536 Proposed RSA KEYs and SIGs RFC2537 Proposed Storing Certificates RFC2538 Proposed Diffie-Hellman Keys RFC2539 Proposed Extensions to DNS0 RFC2671 Proposed Non-Terminal DNS names RFC2672 Proposed Binary Labels RFC2673 Proposed Other specific work items are: o TSIG - transaction signatures in (dnsind-tsig-xx.txt) o TKEY - Secret Key establishment for DNS (dnsind-tkey-xx.txt) o Securing dynamic update (dnsind-simple-secure-update-xx.txt) o Protocol clarifications and corrections for DNSSEC (draft-ietf-dnsind-sig-zero-xx.txt) (draft-ietf-dnsind-zone-secure-xx.txt) o Clarifications for IANA in DNS assignments (draft-ietf-dnsind-iana-dns-xx.txt) o Documentation of the zone transfer protocol (AXFR) o Retirement of DNS MIB's RFC's New work items may be added from time-to-time with the approval of the Working Group and the IESG. Goals and Milestones: Dec 99 Advance RFC2052bis to RFC. Jan 00 Advance RFC1996 for Draft standard. Jan 00 Advance TKEY and IANA considerations for IESG consideration Feb 00 SIG(0) advanced for IESG consideration Feb 00 RFC1995bis and AXFR advanced for Proposed Mar 00 RFC2136bis advanced for Proposed standard Mar 00 IXFR (RFC1995bis) interoperabilty testing complete Apr 00 Serial Number Arithmetic, Notify and DNS Clarify advanced to Draft Standard. Apr 00 RFC1611 and RFC1612 status chaned to historic. May 00 RFC2308bis advanced for IESG consideration. May 00 Secure update completed and ready for IESG consideration May 00 RFC2137 Obsoleted Jun 00 Request that TSIG be advanced to Draft Standard Jul 00 Revised DNSSEC submitted for advancement to Draft Standard From owner-namedroppers@opsmail.internic.net Mon Jan 3 01:26:18 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17330 for ; Mon, 3 Jan 2000 01:26:18 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id WAA00843 for namedroppers-outgoing; Sun, 2 Jan 2000 22:14:08 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id WAA00832 for ; Sun, 2 Jan 2000 22:14:07 -0500 (EST) Received: (qmail 495 invoked from network); 3 Jan 2000 03:14:07 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.14 with SMTP; 3 Jan 2000 03:14:07 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 124xwb-000OHG-00 for namedroppers@internic.net; Sun, 02 Jan 2000 19:14:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 31 Dec 1999 01:07:37 -0000 Message-ID: <19991231010737.16203.qmail@cr.yp.to> Mail-Followup-To: namedroppers@internic.net From: "D. J. Bernstein" To: namedroppers@internic.net Subject: Which servers crash on ID reuse? Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit BIND tries to avoid quickly repeating its outgoing query IDs. I've been told that one reason for this is to avoid triggering a crash in some old Apple DNS servers. Does anyone have more information about the buggy DNS implementations? What software has the problem? What version fixed the problem? What are the conditions that produce a crash? What happens if two independent caches (or two people running dig) use the same ID? What happens if BIND sends ID 375 to one of these servers, then sends the next 65000 queries to other servers, then sends ID 375 to the same server again? Are these servers deployed on a noticeable number of machines? Do new server implementors have to worry about this interoperability problem? Is any of this documented in the IETF DNS specifications? ---Dan From owner-namedroppers@opsmail.internic.net Mon Jan 3 01:32:41 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17810 for ; Mon, 3 Jan 2000 01:32:41 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id WAA09151 for namedroppers-outgoing; Sun, 2 Jan 2000 22:21:30 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id WAA09122 for ; Sun, 2 Jan 2000 22:21:30 -0500 (EST) Received: (qmail 1755 invoked from network); 3 Jan 2000 03:21:29 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.14 with SMTP; 3 Jan 2000 03:21:29 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 124y3l-000OME-00 for namedroppers@internic.net; Sun, 02 Jan 2000 19:21:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 30 Dec 1999 10:06:39 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: dnsind -> dnsext To: Edward Lewis Cc: namedroppers@internic.net In-Reply-To: "Your message with ID" Message-ID: Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit > 1) Not within the documented charter of DNSIND > 2) Not within the documented proposed charter of DNSEXT BTW: DNSEXT was approved 2 weeks ago. http://www.ietf.org/html.charters/dnsext-charter.html And any day now the garbage collection will remove DNSIND from the charter page (we missed doing that when dnsext was approved). Erik From owner-namedroppers@opsmail.internic.net Mon Jan 3 01:41:50 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18336 for ; Mon, 3 Jan 2000 01:41:50 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id WAA17590 for namedroppers-outgoing; Sun, 2 Jan 2000 22:36:34 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id WAA17571 for ; Sun, 2 Jan 2000 22:36:34 -0500 (EST) Received: (qmail 2709 invoked from network); 3 Jan 2000 03:36:33 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.15 with SMTP; 3 Jan 2000 03:36:33 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 124yIL-000OVu-00 for namedroppers@internic.net; Sun, 02 Jan 2000 19:36:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <199912300823.RAA18128@sh.w3.mag.keio.ac.jp> Date: Thu, 30 Dec 1999 09:14:36 +0900 To: Edward Lewis From: "Martin J. Duerst" Subject: Re: "local" names Cc: namedroppers@internic.net, lewis@tislabs.com In-Reply-To: References: <199912290241.SAA20137@toad.com> <19991228151635.A24414@noc.untraceable.net> Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit At 09:00 99/12/29 -0500, Edward Lewis wrote: > At 9:41 PM -0500 12/28/99, John Gilmore wrote: > >However, I hope the WG chairs will ask for a WG consensus on *this* > >document, and also put a stake through its heart. We have enough real > > I agree with John Gilmore and Robert Elz. This work item is: > > 1) Not within the documented charter of DNSIND > 2) Not within the documented proposed charter of DNSEXT > 3) Placing a requirement on IANA's assignment of names It looks as if many people in this group have come up with good arguments for having something like .local or .intra. If this does not fit the charter of DNSIND, then I propose that it is handed over to the IESG saing: 'This is not on our charter, and therefore not submitted as a WG document, but it's something that a lot of people on the WG felt to be useful, and we wouldn't want to just drop it on the floor, so could you process this as a document that was individually submitted to the IESG?'. Also, if this document isn't within the proposed charter of DNSEXT, then it may be possible to change that charter, as it is still proposed. As for IANA, most of what IANA does is constrained by RFCs. So this is in no way new. TLDs are politically hotter than other IANA assignements, but while the proposal of new true TLDs is probably the politically hottest issue overall, the current proposal is clearly grounded in technical management purposes, and therefore clearly a technical business that the IETF has to take care of. Any ip number allocation scheme that wouldn't take care of things such as loopback *before* handing over the rest of the number blocks to some political or whatever agency to hand out would clearly be considered technically deficient, and if the experts on this group think that they have found a similar deficiency in TLDs, and a way to fix it, then there should be ways to deal with things such as charters. One specific problem that we might worry about is the danger that .intra somehow leaks to the outside (through DNS, or on other levels, e.g. in an URI). Regards, Martin. #-#-# Martin J. Du"rst, World Wide Web Consortium #-#-# mailto:duerst@w3.org http://www.w3.org From owner-namedroppers@opsmail.internic.net Mon Jan 3 12:25:23 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04575 for ; Mon, 3 Jan 2000 12:25:22 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id JAA29973 for namedroppers-outgoing; Mon, 3 Jan 2000 09:29:53 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id JAA29952 for ; Mon, 3 Jan 2000 09:29:52 -0500 (EST) Received: (qmail 8619 invoked from network); 3 Jan 2000 14:29:52 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.14 with SMTP; 3 Jan 2000 14:29:52 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 1258UZ-0003JA-00 for namedroppers@internic.net; Mon, 03 Jan 2000 06:29:51 -0800 Message-Id: <200001031343.IAA00403@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@internic.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsind-iana-dns-04.txt Date: Mon, 03 Jan 2000 08:43:31 -0500 Sender: owner-namedroppers@internic.net 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 IXFR, Notification, and Dynamic Update Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake 3rd, E. Brunner, B. Manning Filename : draft-ietf-dnsind-iana-dns-04.txt Pages : 13 Date : 30-Dec-99 Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, RR types, operation codes, error codes, etc. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsind-iana-dns-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsind-iana-dns-04.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-dnsind-iana-dns-04.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: <19991230124936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsind-iana-dns-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsind-iana-dns-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991230124936.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-namedroppers@opsmail.internic.net Mon Jan 3 15:08:41 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06861 for ; Mon, 3 Jan 2000 15:08:41 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id MAA11459 for namedroppers-outgoing; Mon, 3 Jan 2000 12:14:00 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id MAA11366 for ; Mon, 3 Jan 2000 12:13:59 -0500 (EST) Received: (qmail 22617 invoked from network); 3 Jan 2000 17:13:58 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.14 with SMTP; 3 Jan 2000 17:13:58 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 125B3N-0004Jj-00 for namedroppers@internic.net; Mon, 03 Jan 2000 09:13:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200001031712.MAA14962@thunk.epilogue.com> From: Bill Sommerfeld To: Jim Reid cc: Robert Elz , "Donald E. Eastlake 3rd" , namedroppers@internic.net Subject: Re: "local" names In-Reply-To: Message from Jim Reid of "Tue, 28 Dec 1999 21:27:00 GMT." <9379.946416420@gromit.rfc1035.com> Date: Mon, 03 Jan 2000 12:12:21 -0500 Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit > There are some other reasons for formalising this TLD. The naming > problems are not as difficult when two private intranets get smashed > together if they are both using the same "private" TLD. My sense is that in the other case, resolving naming collisions could be more problematic (dealing with foo.tld from net 1 and foo.tld from net 2 being very different entities and disambiguating all references to them).. Changing default DNS search paths is just a matter of pretty much brute force reconfiguration. In any event, I agree that this is out of scope for this WG. - Bill From owner-namedroppers@opsmail.internic.net Mon Jan 3 19:29:22 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09389 for ; Mon, 3 Jan 2000 19:29:21 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id QAA27444 for namedroppers-outgoing; Mon, 3 Jan 2000 16:19:11 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id QAA27406 for ; Mon, 3 Jan 2000 16:19:10 -0500 (EST) Received: (qmail 14006 invoked from network); 3 Jan 2000 21:19:10 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.14 with SMTP; 3 Jan 2000 21:19:10 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 125Ese-0005jc-00 for namedroppers@internic.net; Mon, 03 Jan 2000 13:19:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 3 Jan 2000 16:11:51 -0500 From: Andrew Brown To: namedroppers@internic.net Subject: Re: Which servers crash on ID reuse? Message-ID: <20000103161151.A12800@noc.untraceable.net> Reply-To: Andrew Brown References: <19991231010737.16203.qmail@cr.yp.to> In-Reply-To: <19991231010737.16203.qmail@cr.yp.to>; from djb@cr.yp.to on Fri, Dec 31, 1999 at 01:07:37AM -0000 Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit >BIND tries to avoid quickly repeating its outgoing query IDs. I've been >told that one reason for this is to avoid triggering a crash in some old >Apple DNS servers. that very well might be the case, but it sounds hokey. the real reason to avoid re-using query ids is so that a given server doesn't have two queries outstanding to the same "other" server where the answer might be returned and get confused. bind currently (i believe) uses both the query id and the remote server's ip address to verify (or properly route) a received reply. if a query id was re-used too soon, such that there was already an outstanding query to the same "other" server, the answers would probably get mixed up. i don't think it would crash anything. >What happens if two independent caches (or two people running dig) use >the same ID? nothing, since the queries will have different questions (supposedly), source addresses (possibly), and source ports (if the addresses are the same). > What happens if BIND sends ID 375 to one of these servers, >then sends the next 65000 queries to other servers, then sends ID 375 to >the same server again? then your bind stands a chance of becoming confused. your bind is also very busy. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth." From owner-namedroppers@opsmail.internic.net Tue Jan 4 04:41:57 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26779 for ; Tue, 4 Jan 2000 04:41:57 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id BAA22839 for namedroppers-outgoing; Tue, 4 Jan 2000 01:23:44 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id BAA22794 for ; Tue, 4 Jan 2000 01:23:43 -0500 (EST) Received: (qmail 22228 invoked from network); 4 Jan 2000 06:23:42 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.15 with SMTP; 4 Jan 2000 06:23:42 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 125NNd-0008aE-00 for namedroppers@internic.net; Mon, 03 Jan 2000 22:23:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200001040623.BAA28057@torque.pothole.com> To: namedroppers@internic.net Subject: Re: WG Last Call: TKEY In-reply-to: Your message of "Wed, 29 Dec 1999 13:38:20 EST." Date: Tue, 04 Jan 2000 01:23:06 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ed, From: Edward Lewis Message-Id: In-Reply-To: <4.1.19991222150900.00c81c50@localhost> References: <4.1.19991220170146.00a5b980@localhost> <4.1.19991217151818.0091b8e0@localhost> Date: Wed, 29 Dec 1999 13:38:20 -0500 To: Olafur Gudmundsson Cc: namedroppers@internic.net >At 3:13 PM -0500 12/22/99, Olafur Gudmundsson wrote: >>Donald updated the draft The update had only two very minor changes in it, one giving a recommended CLASS of ANY for TKEY to be parallel with TSIG, and the other fixing a one word typo. I wouldn't normally do an update for such a minor change but your personal email to me of 10 December pointing out the typo said you thought the rest of the document was OK. So I though it was stable. The new changes you have come up will mostly seem like minor improvements. So if I don't have a specific response below, it means I plan to include that change if there aren't any opposing comments on the mailing ist. >> 3. Exchange via Resolver Query.............................8 >> 3.1 Query for Server Assigned Keying.......................8 >> 3.2 Query for Diffie-Hellman Exchanged Keying..............9 >> 3.3 Query for GSS-API Established.........................11 >> 3.4 Query for Querier Assigned Keying.....................11 >> 3.5 Query for TKEY Deletion...............................12 > >Since DH and delete modes are required and the others are not, I'd >rearrange the outline to be: > >3.1 <- 3.2 Query for Diffie-Hellman Exchanged Keying..............9 >3.2 <- 3.5 Query for TKEY Deletion...............................12 > >Get the mandatories out of the way. > >3.3 <- 3.3 Query for GSS-API Established.........................11 >3.4 <- 3.1 Query for Server Assigned Keying.......................8 >3.5 <- 3.4 Query for Querier Assigned Keying.....................11 > >Pairing the last two since they are complimentary ideas. > >>1.1 General Principles >> >... >> require mutual agreement. In the absence of such agreement, servers >> MUST return errors such as NotImp or Refused for an attempt to use >> TKEY and resolvers are free to ignore any TKEY RRs they receive. > >I have a problem with requirements (MUST's, et.al.) in the Introduction. >Later in the document, in the Security Considerations, there are more >requirements. I strongly encourage the concentration of requirements or >conformance statements in the meat of the document. This eases deriving a >test plan from the specification document. > >> Server and resolvers supporting >> this specification MUST implement the Diffie-Hellman key agreement >> and the key deletion modes. > >"Server and resolvers conforming to this specification MUST implement the >Diffie-Hellman key agreement mode and MUST implement the key deletion mode." >--At least add "mode" after "agreement" and make "modes" singular. This >makes clear that two modes are mandatory. > >> 4 resolver/querier assignment >> 5 key deletion >> 6-65534 - available, see IANA considerations section >> 65535 -reserved > >Table is misformatted. > >>2.1 Key Naming >> >> At any host only one octet string of keying material may be in place >> at the same time for any particular key name. > >This sentence is confusing. By a host do you mean a resolver, server, >both, neither? In trying to offer a rewording of this, I find I don't grok >the idea here. What is being refered to here is any process that caches TSIG secret keying material, that is, material which this draft provides a way to agree on via DNS messages which include a TKEY RR. Assuming this is the DNS server, there is normally only one of them on a host. It might be a "stub resolver". However, I guess it could be some miscellaneous application which is directly sending DNS queries and gettign DNS responses wants to use TKEY to boostrap to being and to use TSIG for some remote server(s). (There's no reason to define Host here. Host is a well defined IETF term used all over the place. See the Host Requirements RFCs or Host Resources MIB or DHCP or ... A Host is the end refered to in the end-to-end principle. All communications terminating at a Host generally fate share. (See RFC 1958 section 2.3.) ) >[I don't know if this a relelvant comment or not: What about a >multi-interfaced/ multi-addressed machine (or a machine owning an interface >that has a reverse map entry with multiple PTR's)? Is there a rule >governing the mapping of a domain name to the resolver?] Yes, Hosts can have multiple IP address / interfaces. If they fate share, they are one Host. When you say "an interface ... reverse map ... multiple PTR's" I assume you mean an IP address that reverse maps to PTR's to multiple forward names. That should only be true if the address is a legitimate address for each of those names. Yes, there can be multiple names that map to the same IP and are thus names for the same Host. You can pick any of the names for constructing key names. Even if the name you pick has multiple address records stored at it that go to different Hosts, there shouldn't be any key name duplication, at least in the random name case. I supose you could get a duplicate key name if there are two client Hosts accessible via the same name making request to one or more servers with the same name using the other suggested method of key naming but I don't think it would cause a problem. >> If the key is generated as the result of a query with root as >> its owner name, they the server SHOULD create a pseudo-random > | >............................n > >> >> [RFC 1750] based unique name ending with a name of the server > >"pseudo-random based unique name"? I don't grok this either. I guess it should say something more like "... create a globally unique domain name, to be the key name, by suffixing a pseudo-random [RFC 1750] label with a domain name of the server host." >> host. For example 89n3mdg072pp.server.example.com. If >> generation of a new pseudo-random name in each case is an >> excessive computation load or entropy drain, a serial number >> prefix can be added to a single pseudo-random name generated an > | >.......................................................................t > >>3.1 Query for Server Assigned Keying >> >> for the reason given. FORMERR is given if the query specified no >> encryption key. > >FORMERR is not defined in the document, yet it is also referenced in >following sections. Format Error is defined in RFC 1035 but I'm not sure just where the "FORMERR" name for it it defined. It's used in the TSIG draft as well. >> If the error field is zero, the client host supplied Diffie-Hellman >> KEY should be echoed back and a server host Diffie-Hellman KEY RR > |||||| > SHOULD > >While I am at it, "echoed back" is repetitively redundant. > >> keying material = >> XOR ( DH value, MD5 ( query data | DH value ) | >> MD5 ( server data | DH value ) ) >> >> where XOR is a byte wise left justified xor padding the shorter octet >> stream with zeros, DH value is the Diffie-Hellman value derived from >> the KEY RRs, "query data" and "server data" are the TKEY RR data >> fields sent by those parties, and "|" is concatenation. > >I'd replace that one sentence with something like: > >Where XOR is an exclusive-OR operation and "|" is byte-stream >concatenation. The shorter of the two operands to XOR is byte-wise left >justified and padded with zero-valued bytes to match the length of the >other operand. DH value is the Diffie-Hellman value derived from the KEY >RRs. Query data and server data are the values sent in the TKEY RR data >fields. > >(Keep the rest of that paragraph too.) > >>3.4 Query for Querier Assigned Keying >... >> keying data and a KEY RR specifying the server host public key used > >"Keying data" is too similar to "keying material." I can't think of a >replacement, "initialization" and "salt" come to mind, but they pertain to >specific algorithms (I think). > >>3.5 Query for TKEY Deletion >> >> a TKEY RR with the key's name. If the server has no record of a key >> with that name, it returns BADNAME. > >What does a resolver do with a BADNAME? I would guess this is the same as >a successful key delete request. So, why bother? Why not have the server >just send back okay to an unknown key? I think error reporting is a good idea. It may some day give you a clue as to why things are failing. Unless there are further requests, I don't plan to change this. >>5. Methods of Encryption >... >> decyrption which recovers the originally encrypted data. The KEY RR > > decryption > >>6. IANA Considerations >> >> changes. I.E. a mode value assigned for an Experimental Standard > > I.e., > >Page 18 is blank, the footer prints in the upper/middle part of the paper. > >> >>Donald E. Eastlake, 3rd [Page 18] > > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis NAI Labs >Phone: +1 443-259-2352 Email: lewis@tislabs.com > >"Trying is the first step to failure." - Homer Simpson >"No! Try not. Do... or do not. There is no try." - Yoda > >Opinions expressed are property of my evil twin, not my employer. Donald =================================================================== Donald E. Eastlake 3rd +1 914-276-2668 dee3@torque.pothole.com 65 Shindegan Hill Rd, RR#1 Carmel, NY 10512 USA From owner-namedroppers@opsmail.internic.net Tue Jan 4 14:04:59 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04158 for ; Tue, 4 Jan 2000 14:04:58 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id KAA29949 for namedroppers-outgoing; Tue, 4 Jan 2000 10:53:24 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx0.lb.internic.net [192.168.120.13]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id KAA29363 for ; Tue, 4 Jan 2000 10:53:15 -0500 (EST) Received: (qmail 6318 invoked from network); 4 Jan 2000 15:53:14 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.13 with SMTP; 4 Jan 2000 15:53:14 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 125WGm-000COw-00 for namedroppers@internic.net; Tue, 04 Jan 2000 07:53:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200001040623.BAA28057@torque.pothole.com> References: Your message of "Wed, 29 Dec 1999 13:38:20 EST." Date: Tue, 4 Jan 2000 09:50:00 -0500 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: WG Last Call: TKEY Cc: namedroppers@internic.net Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit At 1:23 AM -0500 1/4/00, Donald E. Eastlake 3rd wrote: >other fixing a one word typo. I wouldn't normally do an update for >such a minor change but your personal email to me of 10 December >pointing out the typo said you thought the rest of the document was >OK. So I though it was stable. I remember that. Sorry about sending so many comments after saying I thought it was ok. I can't explain why I flip-flopped, but I'd rather get comments out during the last call then be considered a consistent person ;). (This is why I could never run for political office.) >The new changes you have come up will mostly seem like minor >improvements. So if I don't have a specific response below, it means >I plan to include that change if there aren't any opposing comments on >the mailing ist. I don't consider the comment to remove requirements from the Introduction and Security Considerations to be minor ones. My irritation on this point stems from RFC 2065/2535 and trying to derive a test plan from that document. Because of the inconsistency in the presentation of the requirements, it is hard to derive a plan of what needs to be tested to show compliance. I'm now trying to make sure that that DNS security documents are clear and software shown to be compliant, so that we can make DNS more secure. If we bother to add security to DNS, but the specs are so vague as to make implementations weak and therefore vulnerable, what's the use? >(There's no reason to define Host here. Host is a well defined IETF Yes, there is no reason. That was kind of my point. I was hoping you'd not use "host" in 2.1, substituting resolver or server - actually, I wasn't all that clear. But talking about a "host" in 2.1 is misleading. >agree on via DNS messages which include a TKEY RR. Assuming this is >the DNS server, there is normally only one of them on a host. It >might be a "stub resolver". "Normally" - yes, but you are writing a spec. Cover all the legal cases, this is one example of a weakness in the spec. >Yes, Hosts can have multiple IP address / interfaces. If they fate You can ignore the blabbering I had about this. I was trying to demonstrate the absolute confusion I had over your use of the term "host." I would have only expected to see host-based (security) requirements in something like IPSEC. >Format Error is defined in RFC 1035 but I'm not sure just where the >"FORMERR" name for it it defined. It's used in the TSIG draft as >well. >From the context in which FORMERR appears in your document, you make it seem like this would be reported in the TKEY error field.: > If the error field of the response TKEY is non-zero, the query failed > for the reason given. FORMERR is given if the query specified no > encryption key. Is FORMERR placed in the TKEY error field or the message header? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "Trying is the first step to failure." - Homer Simpson "No! Try not. Do... or do not. There is no try." - Yoda Opinions expressed are property of my evil twin, not my employer. From owner-namedroppers@opsmail.internic.net Wed Jan 5 13:34:30 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12878 for ; Wed, 5 Jan 2000 13:34:30 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id KAA14763 for namedroppers-outgoing; Wed, 5 Jan 2000 10:27:43 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id KAA14714 for ; Wed, 5 Jan 2000 10:27:42 -0500 (EST) Received: (qmail 5136 invoked from network); 5 Jan 2000 15:27:42 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.15 with SMTP; 5 Jan 2000 15:27:42 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 125sLd-0006R0-00 for namedroppers@internic.net; Wed, 05 Jan 2000 07:27:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "MANE BSL" To: "'Internic List'" Subject: .local TLD usage (draft-ietf-dnsind-local-names-07.txt) Date: Wed, 5 Jan 2000 15:04:39 +0100 Message-ID: <000001bf5785$e25bd800$7674d0d4@p09475> Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm trying to define for my company an efficient internal DNS tree. I have discovered last year a very interesting draft about the TLD ".local". This document is "Local Domain Name System" and now the last version is "draft-ietf-dnsind-local-names-07.txt". Though today this draft is a Best Current Practice (but not yet an RFC), I'm obliged now to start to setup my DNS. I would like to know if someone is experience in the deployment or the usage of a ".local" TLD in an international WAN context. I would be very pleased to get your opinion and advises about this subjet. Thanks a lot Best Regards Eric SALGON Network Engineer MANE Company From owner-namedroppers@opsmail.internic.net Wed Jan 5 17:52:55 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17440 for ; Wed, 5 Jan 2000 17:52:54 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id OAA18278 for namedroppers-outgoing; Wed, 5 Jan 2000 14:50:10 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx0.lb.internic.net [192.168.120.13]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id OAA18192 for ; Wed, 5 Jan 2000 14:50:09 -0500 (EST) Received: (qmail 21729 invoked from network); 5 Jan 2000 19:50:09 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.13 with SMTP; 5 Jan 2000 19:50:09 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 125wRb-000Dwt-00 for namedroppers@internic.net; Wed, 05 Jan 2000 11:50:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200001051943.LAA12717@boreas.isi.edu> Subject: Re: .local TLD usage (draft-ietf-dnsind-local-names-07.txt) To: phanez@vmf-mane.com (MANE BSL) Date: Wed, 5 Jan 100 11:43:56 -0800 (PST) Cc: namedroppers@internic.net In-Reply-To: <000001bf5785$e25bd800$7674d0d4@p09475> from "MANE BSL" at Jan 5, 0 03:04:39 pm Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit % Though today this draft is a Best Current Practice (but not yet an RFC), I'm % obliged now to start to setup my DNS. I would like to know if someone is % experience in the deployment or the usage of a ".local" TLD in an % international WAN context. A correction. The draft is -NOT- a Best Current Practice. That designation is reserved for a draft that reaches RFC status. Based on the version number of the draft, this has not been a simple or easy task thus far and still has a number of large hurdles to overcome. That said, it is fairly simple to add domains that are locally scoped. -- --bill From owner-namedroppers@opsmail.internic.net Tue Jan 11 05:11:41 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03035 for ; Tue, 11 Jan 2000 05:11:40 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id BAA11495 for namedroppers-outgoing; Tue, 11 Jan 2000 01:43:46 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id BAA11467 for ; Tue, 11 Jan 2000 01:43:46 -0500 (EST) Received: (qmail 14942 invoked from network); 11 Jan 2000 06:43:45 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.15 with SMTP; 11 Jan 2000 06:43:45 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 127v1s-000Is3-00 for namedroppers@internic.net; Mon, 10 Jan 2000 22:43:44 -0800 To: namedroppers@internic.net Subject: =?iso-2022-jp?B?GyRCJSQlcyU5JUghPCVrQGgkTjtYRGobKEI=?= From: Ryohei Yoshioka Message-Id: <200001111518.FHB66957.IJSZPF@ftk.fujitsu.co.jp> Date: Tue, 11 Jan 2000 15:18:26 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-namedroppers@internic.net Precedence: bulk はじめまして 吉岡と申します。 こちらが、DNSのメーリングリストとお聞きし、 ひょっとすると趣旨が違うかも知れませんが、 質問させてください。 bindの8系で、インストール先をデフォルトの /usr/local/......　ではなく、 自分のホームの配下に変更したいのですが、 設定がうまく行きません。 バージョン　8.2.2-P5 OS　　　　　solaris2.6 いくつかのアドバイスを受けましたが、 それでもよく分かりませんでした。 ご指導よろしくお願いします。 -- Ryohei Yoshioka E-Mail ryohei@ftk.fujitsu.co.jp From owner-namedroppers@opsmail.internic.net Wed Jan 12 00:34:20 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27963 for ; Wed, 12 Jan 2000 00:34:19 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id VAA11610 for namedroppers-outgoing; Tue, 11 Jan 2000 21:33:16 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id VAA11588 for ; Tue, 11 Jan 2000 21:33:16 -0500 (EST) Received: (qmail 12710 invoked from network); 12 Jan 2000 02:33:14 -0000 Received: from mg-206253202-154.ricochet.net (HELO roam.psg.com) (206.253.202.154) by 192.168.119.14 with SMTP; 12 Jan 2000 02:33:14 -0000 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 128Daw-0000Ky-00 for namedroppers@internic.net; Tue, 11 Jan 2000 18:33:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 11 Jan 2000 22:16:43 -0000 Message-ID: <20000111221643.6701.qmail@cr.yp.to> From: "D. J. Bernstein" To: dns@us.ibm.com, namedroppers@internic.net, paul@vix.com Subject: An interoperability disaster Cc: cjohnson@palomine.net Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit One of ibm.net's caches, ns1.us.prserv.net, times out right now on recursive lookups for www.ipapilot.org. Can anyone explain why? 1. As you can see, the ns1.us.prserv.net cache has ipapilot.org NS a.ns.ipapilot.org ipapilot.org NS b.ns.ipapilot.org without the corresponding A records. What could have happened to the A records? The ipapilot.org servers provide the A records as additional data, with the same TTL as the NS records. 2. Normal caches recognize this situation and quickly recover from it. (It's rare, but it does happen, and DNSEXT should document it.) dnscache, for example, will fall back to the roots. BIND will drop the query but start a background ``sysquery'' to a higher-level server, hoping to have the records cached by the time the query is retried. But this cache simply times out. What could prevent a cache from recovering? 3. As an experiment, I tried looking up network-surveys.cr.yp.to and then leap.yp.to a few times through ns1.us.prserv.net. There was something very strange about the cached results, perhaps tied to the problems described above: the TTL for the yp.to NS records, and the TTLs for the corresponding A records, continued to count down, even though the authoritative leap.yp.to answer came with renewed TTLs. What could cause a cache to discard the new A records in favor of older records? The obsolete ``credibility'' rules don't seem relevant here--- the old A records have exactly the same TTL as the NS records, so presumably they come from additional data, just like the new ones. ---Dan From owner-namedroppers@opsmail.internic.net Wed Jan 12 05:25:55 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11652 for ; Wed, 12 Jan 2000 05:25:55 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id BAA20020 for namedroppers-outgoing; Wed, 12 Jan 2000 01:04:33 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id BAA19988 for ; Wed, 12 Jan 2000 01:04:32 -0500 (EST) Received: (qmail 26855 invoked from network); 12 Jan 2000 06:04:32 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.15 with SMTP; 12 Jan 2000 06:04:32 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 128GtS-0000bq-00 for namedroppers@internic.net; Tue, 11 Jan 2000 22:04:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 12 Jan 2000 07:00:06 +0100 (CET) From: Mats Dufberg To: "D. J. Bernstein" cc: dns@us.ibm.com, namedroppers@internic.net, paul@vix.com, cjohnson@palomine.net Subject: Re: An interoperability disaster In-Reply-To: <20000111221643.6701.qmail@cr.yp.to> Message-ID: Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit [ all, please move this thread to the bind-users list and dnsop. -- rb ] On 11 Jan 2000, D. J. Bernstein wrote: > One of ibm.net's caches, ns1.us.prserv.net, times out right now on > recursive lookups for www.ipapilot.org. Can anyone explain why? > > > 1. As you can see, the ns1.us.prserv.net cache has > > ipapilot.org NS a.ns.ipapilot.org > ipapilot.org NS b.ns.ipapilot.org > > without the corresponding A records. > > What could have happened to the A records? The ipapilot.org servers > provide the A records as additional data, with the same TTL as the NS > records. If it was missing in the delegation from the ORG servers... The delegation from ORG seems to have been updated (or not updated): ipapilot.org. 172800 NS NS2.PALOMINE.NET. ipapilot.org. 172800 NS SHEMP.PALOMINE.NET. According to the nameservers SHEMP.PALOMINE.NET and NS2.PALOMINE.NET the delegation should be ipapilot.org. 259200 NS a.ns.ipapilot.org. ipapilot.org. 259200 NS b.ns.ipapilot.org. ipapilot.org. 259200 NS c.ns.ipapilot.org. a.ns.ipapilot.org. 259200 A 205.198.88.200 b.ns.ipapilot.org. 259200 A 205.198.89.22 c.ns.ipapilot.org. 259200 A 205.198.89.22 Start with putting them in sync. Mats ----------------------------------------------------------------- Mats Dufberg dufberg@nic-se.se NIC-SE +46-8-545 857 06 Box 5774 fax: +46-8-545 857 29 SE-114 87 Stockholm http://www.nic-se.se/ From owner-namedroppers@opsmail.internic.net Wed Jan 12 05:26:25 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11662 for ; Wed, 12 Jan 2000 05:26:25 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id AAA04194 for namedroppers-outgoing; Wed, 12 Jan 2000 00:58:24 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx0.lb.internic.net [192.168.120.13]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id AAA04175 for ; Wed, 12 Jan 2000 00:58:23 -0500 (EST) Received: (qmail 3643 invoked from network); 12 Jan 2000 05:58:23 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.13 with SMTP; 12 Jan 2000 05:58:23 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 128GnV-0000aA-00 for namedroppers@internic.net; Tue, 11 Jan 2000 21:58:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200001120452.PAA09988@bsdi.dv.isc.org> To: "D. J. Bernstein" cc: dns@us.ibm.com, namedroppers@internic.net, cjohnson@palomine.net From: Mark.Andrews@nominum.com Subject: Re: An interoperability disaster In-reply-to: Your message of "11 Jan 2000 22:16:43 -0000." <20000111221643.6701.qmail@cr.yp.to> Date: Wed, 12 Jan 2000 15:52:11 +1100 Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit > One of ibm.net's caches, ns1.us.prserv.net, times out right now on > recursive lookups for www.ipapilot.org. Can anyone explain why? Yes. They have not updated there delegation to reflect the zone contents. Domain Name: IPAPILOT.ORG Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: www.networksolutions.com Name Server: NS2.PALOMINE.NET Name Server: SHEMP.PALOMINE.NET > > > 1. As you can see, the ns1.us.prserv.net cache has > > ipapilot.org NS a.ns.ipapilot.org > ipapilot.org NS b.ns.ipapilot.org > > without the corresponding A records. > > What could have happened to the A records? The ipapilot.org servers > provide the A records as additional data, with the same TTL as the NS > records. > > > 2. Normal caches recognize this situation and quickly recover from it. > (It's rare, but it does happen, and DNSEXT should document it.) > > dnscache, for example, will fall back to the roots. BIND will drop the > query but start a background ``sysquery'' to a higher-level server, > hoping to have the records cached by the time the query is retried. > > But this cache simply times out. What could prevent a cache from > recovering? When the nameserver asks the com servers for the addresses a.ns.ipapilot.org and b.ns.ipapilot.org they return referrals to shemp.palomine.net and ns2.palomine.net. However the NS RRset is correctly rejected as not being as credable as that from the child zone. This would not be a problem if the zone delegation was correctly managed. Before you make more complaints about credability checks, think about the case when zone are actually signed. To get out of this case you would have to throw out signed data in favour of unsigned data. > > 3. As an experiment, I tried looking up network-surveys.cr.yp.to and > then leap.yp.to a few times through ns1.us.prserv.net. > > There was something very strange about the cached results, perhaps tied > to the problems described above: the TTL for the yp.to NS records, and > the TTLs for the corresponding A records, continued to count down, even > though the authoritative leap.yp.to answer came with renewed TTLs. > > What could cause a cache to discard the new A records in favor of older > records? To work around other mis-management where old servers are not decommisioned or made stealth servers when the delegation is changed. There were cases where customers changes ISP's and the old ISP refused to decommision the servers. Unless we allowed the data to time out you would stay locked on the old servers. Mark > The obsolete ``credibility'' rules don't seem relevant here--- > the old A records have exactly the same TTL as the NS records, so > presumably they come from additional data, just like the new ones. > > > ---Dan -- Mark Andrews, Nominum Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com From owner-namedroppers@opsmail.internic.net Fri Jan 14 14:14:48 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21428 for ; Fri, 14 Jan 2000 14:14:47 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id KAA22422 for namedroppers-outgoing; Fri, 14 Jan 2000 10:45:46 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx0.lb.internic.net [192.168.120.13]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id KAA22399 for ; Fri, 14 Jan 2000 10:45:45 -0500 (EST) Received: (qmail 29689 invoked from network); 14 Jan 2000 15:45:45 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.13 with SMTP; 14 Jan 2000 15:45:45 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 1298v1-000KNy-00 for namedroppers@internic.net; Fri, 14 Jan 2000 07:45:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000114104139.00a31a30@mail.gw.tislabs.com> Date: Fri, 14 Jan 2000 10:45:51 -0500 To: Thomas Narten , namedroppers@internic.net From: Olafur Gudmundsson Subject: Re: WG Last Call: DNS-IANA In-Reply-To: <199912101639.LAA31932@rotala.raleigh.ibm.com> References: <4.1.19991203162520.00bdf520@localhost> Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit At 11:39 AM 12/10/99 , Thomas Narten wrote: >> 1 - 127 >> 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data >> TYPEs only by IETF consensus. >> >> 128 - 255 >> 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and >> Meta TYPEs only by IETF consensus. > >Is there a technical reason for this? The document itself states that >there is already an exception to the above (i.e., OPT). Yes there are technical reasons 1. separates types that are used by DNS for DNS operations from types that are stored in DNS. Allowing implementations to better handle unknown/new types. 2. Conserves the type space up to 127 (the type numbers covered by NXT). > >> 65280 - 65534 >> 0xFF00 - 0xFFFE - assigned for experimental and pre-standards use. >> Because their use is not coordinated, these values/uses may >> conflict between different experiments. These values should >> be used in Internet Drafts for protocols that do not yet have >> an RFC on the Standards Track [RFC 2026]. When such an RFC >> issues, a non-experimental value will be assigned. > >Clarification: does IANA give these out (and then reclaim them later)? >If so, how is their use "not coordinated"? Would "Private Use" as >defined in 2434 accomplish the same goal without requiring IANA be >involved with individual requests? Yes "Private use" is a better. Olafur -------- Olafur Gudmundsson - NAI Labs (443)-259-2389 The Security Research Division of Network Associates, Inc. ogud@tislabs.com Olafur_Gudmundsson@nai.com Private: ogud@acm.org From owner-namedroppers@opsmail.internic.net Fri Jan 14 20:33:41 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24458 for ; Fri, 14 Jan 2000 20:33:41 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id RAA12301 for namedroppers-outgoing; Fri, 14 Jan 2000 17:38:12 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id RAA12278 for ; Fri, 14 Jan 2000 17:38:11 -0500 (EST) Received: (qmail 12252 invoked from network); 14 Jan 2000 22:38:10 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.14 with SMTP; 14 Jan 2000 22:38:10 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 129FMA-000McZ-00 for namedroppers@internic.net; Fri, 14 Jan 2000 14:38:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000114164145.00a30520@mail.gw.tislabs.com> Date: Fri, 14 Jan 2000 16:41:58 -0500 To: "DNSEXT WG mailing list" From: Olafur Gudmundsson Subject: WGLC Summary: Simple Secrue Update. Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit The WGLC has completed. There was one major comment made on the draft that it is accomplishing two things that should not be specified in the same document. It is defining 1. how to secure dynamic update messages 2. modified DNSSEC validation policy. It has been suggested that the document be broken up into two independent documents each specifying one of the above. As 1 replaces RFC2137 and 2. updates RFC2535 this is a good suggesting and follows the guidelines the working group has agreed to in updating RFC2535 (many small documents each one updating one issue). The it is the consensus of the working group that the document be divided in two and requests that the author do that at his earliest convenience. Both documents will be sent to WGLC within two weeks is issue. Olafur -------- Olafur Gudmundsson - NAI Labs (443)-259-2389 The Security Research Division of Network Associates, Inc. ogud@tislabs.com Olafur_Gudmundsson@nai.com Private: ogud@acm.org From owner-namedroppers@opsmail.internic.net Fri Jan 14 21:57:31 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25715 for ; Fri, 14 Jan 2000 21:57:31 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id TAA21768 for namedroppers-outgoing; Fri, 14 Jan 2000 19:05:26 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx0.lb.internic.net [192.168.120.13]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id TAA21743 for ; Fri, 14 Jan 2000 19:05:25 -0500 (EST) Received: (qmail 3431 invoked from network); 15 Jan 2000 00:05:25 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.13 with SMTP; 15 Jan 2000 00:05:25 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 129GiX-000N4M-00 for namedroppers@internic.net; Fri, 14 Jan 2000 16:05:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000114164108.06dd7100@mail.gw.tislabs.com> Date: Fri, 14 Jan 2000 16:41:20 -0500 To: "DNSEXT WG mailing list" From: Olafur Gudmundsson Subject: WGLC Summary: TKEY-03 Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit The Last call has concluded, there where a few comments on the draft mostly stylistic, some editorial. The draft needs to be updated to reflect the comments. Summary of comments of significance: Introduction and security consideration section MUST NOT contain protocol specification text. Mandatory modes SHOULD be defined before optional ones. Once that is done the there will be a short delay and then we will do short WG last call. Olafur PS: I think this draft is in good shape and next version should be the final one. -------- Olafur Gudmundsson - NAI Labs (443)-259-2389 The Security Research Division of Network Associates, Inc. ogud@tislabs.com Olafur_Gudmundsson@nai.com Private: ogud@acm.org From owner-namedroppers@opsmail.internic.net Fri Jan 14 21:59:34 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25743 for ; Fri, 14 Jan 2000 21:59:34 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id TAA22927 for namedroppers-outgoing; Fri, 14 Jan 2000 19:06:03 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id TAA22913 for ; Fri, 14 Jan 2000 19:06:02 -0500 (EST) Received: (qmail 29055 invoked from network); 15 Jan 2000 00:06:02 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.14 with SMTP; 15 Jan 2000 00:06:02 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 129GjB-000N4U-00 for namedroppers@internic.net; Fri, 14 Jan 2000 16:06:01 -0800 Message-Id: <200001142136.QAA02320@hun.gw.tislabs.com> To: namedroppers@internic.net Subject: LGLC summary: DNS-IANA-03 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jan 2000 16:36:30 -0500 From: Olafur Gudmundsson Sender: owner-namedroppers@internic.net Precedence: bulk The working group last call has completed. Number of responses where submitted during the last call period. Main conclusions 1. Document should be issued as BCP not Informational Standard. 2. Number of comments on omissions and minor fixes needed. 3. There is a "conflict" extended error codes between EDNS and TSIG both assign code 16 but for different errors. The document should be updated to say that all future extended error codes should be allocated in the OPT record extended space, TSIG and TKEY are grandfathered in from this mandate. 4. There where many comments on the experimental type space, some about the reuse of of type numbers in that space other if it should be defined as "Private Use" space as defined in RFC2434. 5. There was discussion on what is acceptable documentation of new types and classes that are defined outside the IETF, such as the ATMA type and CHAOS class. The document MUST define for IANA what is acceptable documentation. 6. There was some discussion if IANA wanted someone appointed as an DNS expert that they could call upon to help them in assignments. In a mail discussion that took place on and off the mailing list it became clear that IANA wants to have a appointed DNS expert. (For now I have offered to take on that role. Normally Area directors appoint protocol experts to IANA, Erik Nordmark has not formally appointed anyone to this role). Conclusion the draft is not ready for publication yet. The author has issued a new draft 04 which addresses most of the issues raised once the authors claim that the document reflect their understanding of the working group consensus there will be an WG last call. Olafur Olafur ------- End of Forwarded Message From owner-namedroppers@opsmail.internic.net Fri Jan 14 23:08:03 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27023 for ; Fri, 14 Jan 2000 23:08:03 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id UAA25173 for namedroppers-outgoing; Fri, 14 Jan 2000 20:13:58 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx0.lb.internic.net [192.168.120.13]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id UAA25041 for ; Fri, 14 Jan 2000 20:13:55 -0500 (EST) Received: (qmail 12158 invoked from network); 15 Jan 2000 01:13:54 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.13 with SMTP; 15 Jan 2000 01:13:54 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 129Hmr-000NS1-00 for namedroppers@internic.net; Fri, 14 Jan 2000 17:13:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 15 Jan 2000 01:11:27 -0000 Message-ID: <20000115011127.25312.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@internic.net Subject: Extension prerequisites? Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit This is a general question to anyone who's working on DNS extensions. Are you relying on any BIND behavior from un-extended servers? Are you, for example, assuming that servers will handle bogus packets in some particular way? If so, you should be aware that I've recently released the beta version of a new DNS package, including a stub resolver library (dns.a), a cache (dnscache), and a non-recursive server (tinydns). The package competes directly with BIND and is being deployed rapidly. The code borrows nothing from the BIND code. There's no a-priori reason to believe that it matches your assumptions. So please tell me, as soon as possible, what you're relying on. You can download the code from http://cr.yp.to/dnscache/install.html if you want to carry out your own tests. Note that dnscache doesn't allow third-party queries, so most tests can't be carried out remotely. Some documentation is available from http://cr.yp.to/dnscache.html. ---Dan From owner-namedroppers@opsmail.internic.net Wed Jan 19 22:00:47 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08553 for ; Wed, 19 Jan 2000 22:00:46 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id RAA10090 for namedroppers-outgoing; Tue, 18 Jan 2000 17:28:13 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id RAA10070 for ; Tue, 18 Jan 2000 17:28:12 -0500 (EST) Received: (qmail 17360 invoked from network); 18 Jan 2000 22:28:06 -0000 Received: from mg-206253202-246.ricochet.net (HELO roam.psg.com) (206.253.202.246) by 192.168.119.14 with SMTP; 18 Jan 2000 22:28:06 -0000 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Ah6U-00015X-00 for namedroppers@internic.net; Tue, 18 Jan 2000 14:27:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000118114213.06969cd0@mail.gw.tislabs.com> Date: Tue, 18 Jan 2000 15:43:22 -0500 To: namedroppers@internic.net From: Olafur Gudmundsson Subject: DNSEXT mailing list Namedroppers will be moving Cc: iesg-secretary@ietf.org Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit On January 27'th the site hosting namedroppers will change from internic.net to ops.ietf.org. There will be further announcement once the change takes place. Subscribers do not have to take any action to remain subscribed. Submissions to namdroppers@internic.net will get forwarded to the new mail site. Olafur -------- Olafur Gudmundsson - NAI Labs (443)-259-2389 The Security Research Division of Network Associates, Inc. ogud@tislabs.com Olafur_Gudmundsson@nai.com Private: ogud@acm.org From owner-namedroppers@opsmail.internic.net Thu Jan 20 06:11:58 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24560 for ; Thu, 20 Jan 2000 06:11:57 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id CAA27092 for namedroppers-outgoing; Thu, 20 Jan 2000 02:41:26 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx0.lb.internic.net [192.168.120.13]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id CAA27069 for ; Thu, 20 Jan 2000 02:41:26 -0500 (EST) Received: (qmail 6103 invoked from network); 20 Jan 2000 07:41:23 -0000 Received: from mg131-029.ricochet.net (HELO roam.psg.com) (204.179.131.29) by 192.168.119.13 with SMTP; 20 Jan 2000 07:41:23 -0000 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12BCDZ-0002GD-00 for namedroppers@internic.net; Wed, 19 Jan 2000 23:41:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200001200536.AAA19024@torque.pothole.com> To: Olafur Gudmundsson cc: namedroppers@internic.net Subject: Re: LGLC summary: DNS-IANA-03 In-reply-to: Your message of "Fri, 14 Jan 2000 16:36:30 EST." <200001142136.QAA02320@hun.gw.tislabs.com> Date: Thu, 20 Jan 2000 00:36:53 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit Hi, From: Olafur Gudmundsson Message-Id: <200001142136.QAA02320@hun.gw.tislabs.com> To: namedroppers@internic.net Date: Fri, 14 Jan 2000 16:36:30 -0500 >The working group last call has completed. Number of responses where submitted >during the last call period. > >Main conclusions >1. Document should be issued as BCP not Informational Standard. Fixed in -04 >2. Number of comments on omissions and minor fixes needed. Will review... >3. There is a "conflict" extended error codes between EDNS and TSIG > both assign code 16 but for different errors. The document should be updated > to say that all future extended error codes should be allocated in the OPT > record extended space, TSIG and TKEY are grandfathered in from this mandate. Well, since EDNS is out (RFC 2671) and TSIG isn't, EDNS wins on the conflict. It should be made clear that there is only one DNS error number space. >4. There where many comments on the experimental type space, some about the > reuse of of type numbers in that space other if it should be defined as > "Private Use" space as defined in RFC2434. Private Use is what was opted for in -04. >5. There was discussion on what is acceptable documentation of new types and > classes that are defined outside the IETF, such as the ATMA type and CHAOS > class. The document MUST define for IANA what is acceptable documentation. Draft version -04 uses the ritual phrase form RFC 2434 which I assume is adequate definition. >6. There was some discussion if IANA wanted someone appointed as an DNS expert > that they could call upon to help them in assignments. > In a mail discussion that took place on and off the mailing list it became > clear that IANA wants to have a appointed DNS expert. > (For now I have offered to take on that role. Normally Area directors > appoint protocol experts to IANA, Erik Nordmark has not formally appointed > anyone to this role). I assume provision for such an expert should be added to the draft. >Conclusion the draft is not ready for publication yet. >The author has issued a new draft 04 which addresses most of the issues raised >once the authors claim that the document reflect their understanding of the >working group consensus there will be an WG last call. > > Olafur Donald ==================================================================== Donald E. Eastlake 3rd +1 914-276-2668(h) dee3@torque.pothole.com 65 Shindegan Hill Rd, RR#1 +1 508-261-5343(w) Carmel, NY 10512 USA From owner-namedroppers@opsmail.internic.net Thu Jan 20 09:13:14 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29522 for ; Thu, 20 Jan 2000 09:13:14 -0500 (EST) Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id GAA17068 for ; Thu, 20 Jan 2000 06:23:42 -0500 (EST) Received: (qmail 29859 invoked from network); 20 Jan 2000 11:23:42 -0000 Received: from muncher.math.uic.edu (131.193.178.181) by 192.168.119.15 with SMTP; 20 Jan 2000 11:23:42 -0000 Received: (qmail 24997 invoked by uid 1001); 20 Jan 2000 11:23:03 -0000 Date: 20 Jan 2000 11:20:28 -0000 Message-ID: <20000120112028.17524.qmail@cr.yp.to> From: "D. J. Bernstein" Mail-Followup-To: namedroppers@internic.net To: namedroppers@INTERNIC.NET Subject: Re: DNSEXT mailing list Namedroppers will be moving I'm disappointed that the WG chairs have not revealed the frightening story behind this change in mailing-list operations: http://cr.yp.to/dnscache/namedroppers.html If you're another DNS implementor, and you share my concerns about interoperability, please send me email. I'm sending this message directly to namedroppers-outgoing, which I hope will reach the namedroppers subscribers without interference. I doubt that this avenue of communication will be open much longer. ---Dan From owner-namedroppers@opsmail.internic.net Thu Jan 20 11:27:27 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05966 for ; Thu, 20 Jan 2000 11:27:26 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id IAA02288 for namedroppers-outgoing; Thu, 20 Jan 2000 08:34:39 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id IAA02282 for ; Thu, 20 Jan 2000 08:34:39 -0500 (EST) Received: (qmail 1993 invoked from network); 20 Jan 2000 13:34:37 -0000 Received: from mg131-029.ricochet.net (HELO roam.psg.com) (204.179.131.29) by 192.168.119.14 with SMTP; 20 Jan 2000 13:34:37 -0000 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12BHj9-00035M-00 for namedroppers@internic.net; Thu, 20 Jan 2000 05:34:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200001201204.HAA02063@hygro.adsl.duke.edu> To: "Donald E. Eastlake 3rd" cc: namedroppers@internic.net Subject: Re: LGLC summary: DNS-IANA-03 In-Reply-To: Message from "Donald E. Eastlake 3rd" of "Thu, 20 Jan 2000 00:36:53 EST." <200001200536.AAA19024@torque.pothole.com> Date: Thu, 20 Jan 2000 07:04:57 -0500 From: Thomas Narten Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit >>6. There was some discussion if IANA wanted someone appointed as an DNS >> expert that they could call upon to help them in assignments. >> In a mail discussion that took place on and off the mailing list it >> became clear that IANA wants to have a appointed DNS expert. (For now >> I have offered to take on that role. Normally Area directors appoint >> protocol experts to IANA, Erik Nordmark has not formally appointed >> anyone to this role). > I assume provision for such an expert should be added to the draft. Actually, one only needs an expert if there is a numbering space for which the IANA guidelines are not straightforward enough, and someone with DNS clue needs to think before a particular assignment is made. -04 doesn't mention "expert", so I'm assuming no subjective decisions need to be made. What exactly is the expert needed for (once this document is out as an RFC)? I can see why IANA would want an expert at present, but do they really want one once this document is out as well? Thomas From owner-namedroppers@opsmail.internic.net Thu Jan 20 11:43:29 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06628 for ; Thu, 20 Jan 2000 11:43:28 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id IAA05753 for namedroppers-outgoing; Thu, 20 Jan 2000 08:37:26 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id IAA05745 for ; Thu, 20 Jan 2000 08:37:26 -0500 (EST) Received: (qmail 2444 invoked from network); 20 Jan 2000 13:37:20 -0000 Received: from mg131-029.ricochet.net (HELO roam.psg.com) (204.179.131.29) by 192.168.119.14 with SMTP; 20 Jan 2000 13:37:20 -0000 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12BHlv-00035e-00 for namedroppers@internic.net; Thu, 20 Jan 2000 05:37:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200001201306.IAA19382@torque.pothole.com> To: Thomas Narten cc: "Donald E. Eastlake 3rd" , namedroppers@internic.net Subject: Re: LGLC summary: DNS-IANA-03 In-reply-to: Your message of "Thu, 20 Jan 2000 07:04:57 EST." <200001201204.HAA02063@hygro.adsl.duke.edu> Date: Thu, 20 Jan 2000 08:06:23 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit It would appear that IANA would like an expert to refer general DNS queries to, even if there were no other reason for the existence of an expert. Donald From: Thomas Narten Message-Id: <200001201204.HAA02063@hygro.adsl.duke.edu> To: "Donald E. Eastlake 3rd" cc: namedroppers@internic.net In-Reply-To: Message from "Donald E. Eastlake 3rd" of "Thu, 20 Jan 2000 00:36:53 EST." <200001200536.AAA19024@torque.pot hole.com> Date: Thu, 20 Jan 2000 07:04:57 -0500 >> >6. There was some discussion if IANA wanted someone appointed as an DNS expert >> > that they could call upon to help them in assignments. >> > In a mail discussion that took place on and off the mailing list it became >> > clear that IANA wants to have a appointed DNS expert. >> > (For now I have offered to take on that role. Normally Area directors >> > appoint protocol experts to IANA, Erik Nordmark has not formally appointed >> > anyone to this role). > >> I assume provision for such an expert should be added to the draft. > >Actually, one only needs an expert if there is a numbering space for >which the IANA guidelines are not straightforward enough, and someone >with DNS clue needs to think before a particular assignment is made. > >-04 doesn't mention "expert", so I'm assuming no subjective decisions >need to be made. > >What exactly is the expert needed for (once this document is out as an >RFC)? I can see why IANA would want an expert at present, but do they >really want one once this document is out as well? > >Thomas From owner-namedroppers@opsmail.internic.net Thu Jan 20 14:22:23 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12647 for ; Thu, 20 Jan 2000 14:22:22 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id LAA16732 for namedroppers-outgoing; Thu, 20 Jan 2000 11:09:24 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id LAA16700 for ; Thu, 20 Jan 2000 11:09:23 -0500 (EST) Received: (qmail 13113 invoked from network); 20 Jan 2000 16:09:21 -0000 Received: from mg131-029.ricochet.net (HELO roam.psg.com) (204.179.131.29) by 192.168.119.15 with SMTP; 20 Jan 2000 16:09:21 -0000 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12BK97-000391-00 for namedroppers@internic.net; Thu, 20 Jan 2000 08:09:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200001201453.GAA18698@boreas.isi.edu> Subject: Re: LGLC summary: DNS-IANA-03 To: dee3@torque.pothole.com (Donald E. Eastlake 3rd) Date: Thu, 20 Jan 100 06:53:24 -0800 (PST) Cc: narten@raleigh.ibm.com, dee3@torque.pothole.com, namedroppers@internic.net In-Reply-To: <200001201306.IAA19382@torque.pothole.com> from "Donald E. Eastlake 3rd" at Jan 20, 0 08:06:23 am X-Mailer: ELM [version 2.4 PL24 PGP6] Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit it is my understanding that there is the expectation that if the IANA feels that it needs DNS expertise to clarify some particular DNS issue that the IESG can provide expert(s) as will lead to a reasonable result. Its not clear that there will be a single designated individual. % % It would appear that IANA would like an expert to refer general DNS % queries to, even if there were no other reason for the existence of % an expert. % % Donald % % From: Thomas Narten % Message-Id: <200001201204.HAA02063@hygro.adsl.duke.edu> % To: "Donald E. Eastlake 3rd" % cc: namedroppers@internic.net % In-Reply-To: Message from "Donald E. Eastlake 3rd" % of "Thu, 20 Jan 2000 00:36:53 EST." <200001200536.AAA19024@torque.pot % hole.com> % Date: Thu, 20 Jan 2000 07:04:57 -0500 % % >> >6. There was some discussion if IANA wanted someone appointed as an DNS expert % >> > that they could call upon to help them in assignments. % >> > In a mail discussion that took place on and off the mailing list it became % >> > clear that IANA wants to have a appointed DNS expert. % >> > (For now I have offered to take on that role. Normally Area directors % >> > appoint protocol experts to IANA, Erik Nordmark has not formally appointed % >> > anyone to this role). % > % >> I assume provision for such an expert should be added to the draft. % > % >Actually, one only needs an expert if there is a numbering space for % >which the IANA guidelines are not straightforward enough, and someone % >with DNS clue needs to think before a particular assignment is made. % > % >-04 doesn't mention "expert", so I'm assuming no subjective decisions % >need to be made. % > % >What exactly is the expert needed for (once this document is out as an % >RFC)? I can see why IANA would want an expert at present, but do they % >really want one once this document is out as well? % > % >Thomas % -- --bill From owner-namedroppers@opsmail.internic.net Thu Jan 20 17:24:06 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16351 for ; Thu, 20 Jan 2000 17:24:05 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id OAA05825 for namedroppers-outgoing; Thu, 20 Jan 2000 14:13:46 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id OAA05794 for ; Thu, 20 Jan 2000 14:13:45 -0500 (EST) Received: (qmail 12944 invoked from network); 20 Jan 2000 19:12:03 -0000 Received: from mg132-050.ricochet.net (HELO roam.psg.com) (204.179.132.50) by 192.168.119.15 with SMTP; 20 Jan 2000 19:12:03 -0000 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12BMzr-0003IA-00 for namedroppers@internic.net; Thu, 20 Jan 2000 11:11:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200001201814.KAA30630@redpaul.mibh.net> To: namedroppers@internic.net Subject: Re: LGLC summary: DNS-IANA-03 In-reply-to: Your message of "Thu, 20 Jan 0100 06:53:24 PST." <200001201453.GAA18698@boreas.isi.edu> Date: Thu, 20 Jan 2000 10:14:04 -0800 From: Paul A Vixie Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit > it is my understanding that there is the expectation that if the > IANA feels that it needs DNS expertise to clarify some particular > DNS issue that the IESG can provide expert(s) as will lead to a > reasonable result. Its not clear that there will be a single designated > individual. i have long believed that DNS was "like Security" in that it underlaid almost every application and protocol in use on the Internet, and so, ought to have its own AD. every RFC ought to need a DNS Considerations section, like the IANA and Security considerations they have now. From owner-namedroppers@opsmail.internic.net Thu Jan 20 23:10:59 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21022 for ; Thu, 20 Jan 2000 23:10:59 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id TAA08503 for namedroppers-outgoing; Thu, 20 Jan 2000 19:59:43 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx1.lb.internic.net [192.168.120.14]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id TAA08457 for ; Thu, 20 Jan 2000 19:59:42 -0500 (EST) Received: (qmail 400 invoked from network); 21 Jan 2000 00:59:40 -0000 Received: from mg131-153.ricochet.net (HELO roam.psg.com) (204.179.131.153) by 192.168.119.14 with SMTP; 21 Jan 2000 00:59:40 -0000 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12BSQ6-0003XM-00 for namedroppers@internic.net; Thu, 20 Jan 2000 16:59:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.2.0.58.20000121013109.032cb180@dokka.maxware.no> Date: Fri, 21 Jan 2000 01:36:47 +0100 To: Paul A Vixie , namedroppers@internic.net From: Harald Tveit Alvestrand Subject: DNS considerations section (Re: LGLC summary: DNS-IANA-03) In-Reply-To: <200001201814.KAA30630@redpaul.mibh.net> References: Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit At 10:14 20.01.00 -0800, Paul A Vixie wrote: >i have long believed that DNS was "like Security" in that it underlaid >almost every application and protocol in use on the Internet, and so, >ought to have its own AD. every RFC ought to need a DNS Considerations >section, like the IANA and Security considerations they have now. take your place in the line - we already have requests for the charset/internationalization considerations section, the IANA considerations section, the intellectual property considerations section, and probably a few more. In the big picture, DNS is not the centre of the universe; if it does one function so well it can be taken for granted, all the better. IMHO, the use of boilerplate is more likely to cripple the mind than to liberate it. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no From owner-namedroppers@opsmail.internic.net Thu Jan 27 14:33:11 2000 Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12994 for ; Thu, 27 Jan 2000 14:33:10 -0500 (EST) Received: (from majordom@localhost) by opsmail.internic.net (8.9.3/8.9.1) id KAA02378 for namedroppers-outgoing; Thu, 27 Jan 2000 10:45:14 -0500 (EST) X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers@internic.net using -f Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15]) by opsmail.internic.net (8.9.3/8.9.1) with SMTP id KAA02343 for ; Thu, 27 Jan 2000 10:45:13 -0500 (EST) Received: (qmail 13869 invoked from network); 27 Jan 2000 15:45:12 -0000 Received: from rip.psg.com (147.28.0.39) by 192.168.119.15 with SMTP; 27 Jan 2000 15:45:12 -0000 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Dr6e-0008ad-00 for namedroppers@internic.net; Thu, 27 Jan 2000 07:45:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200001270401.XAA01703@hygro.adsl.duke.edu> To: "D. J. Bernstein" cc: nordmark@ENG.SUN.COM, randy@psg.com (Randy Bush), Olafur Gudmundsson , namedroppers@internic.net Subject: Re: namedroppers mismanagement In-Reply-To: Message from "D. J. Bernstein" of "15 Jan 2000 23:25:03 GMT." <20000115232503.8513.qmail@cr.yp.to> Date: Wed, 26 Jan 2000 23:01:00 -0500 From: Thomas Narten Sender: owner-namedroppers@internic.net Precedence: bulk Content-Transfer-Encoding: 7bit On January 15, 2000, the Internet ADs received a complaint from D. J. Bernstein entitled "namedroppers mismanagement". This note is our response. The jist of the complaint was summarized by Mr. Bernstein as: > In short, to use the language of RFC 2026 section 6.5.1: Mismanagement > of the namedroppers mailing list is preventing the IETF DNS working > groups from adequately considering the views of their participants, and > is placing the quality and integrity of the working group's decisions in > jeopardy. The Internet ADs do not agree with this assertion. In particular: 1) The Internet ADs are aware that the mailing list is moderated and support the chairs efforts in keeping WG activities focussed on WG chartered deliverables. 2) The specific 7 incidents cited include: - 3 that occurred more than a year ago, [not considered due to statue of limitations considerations] - 1 involving lack of timely approval of a posting, [inevitable with a moderated list] - 1 involving what was clearly a problem with the mailing list software [a message posted at the same time by one of the ADs was also caught in the same timewarp] - 1 involving a message that was rejected as off-topic (with a note suggesting a different mailing list) - 1 involving a message that was forwarded to dnsop, rather than being posted to namedroppers, without the author being told this was being done. We do not see any evidence that one of the WG chairs, Randy Bush's moderating activities "actively and deliberately bias the mailing list discussions". (As a side note, namedroppers is actually co-moderated by Randy Bush and Mark Kosters.) However, we have sent a reminder to the chairs/moderators that all rejected postings (including messages forwarded to a more appropriate list instead) should result in an explanatory note being sent to the author. Finally, in your note: > P.S. Is there an email address for the Internet Society Board of > Trustees? I have the individual addresses of the current members but > would prefer to use a group address if one exists. We feel compelled to point out that in the event that further appeals are deemed necessary, the process to follow is outlined in RFC 2026. Specifically, the next place to appeal this response is the IESG, followed by (if necessary) the IAB. Note that appeal to the ISOC is specifically mentioned in section 6.5.3 of 2026. Thomas & Erik From owner-namedroppers@ops.ietf.org Thu Jan 27 15:26:45 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13994 for ; Thu, 27 Jan 2000 15:26:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12DtsM-0002aH-00 for namedroppers-data@psg.com; Thu, 27 Jan 2000 10:42:38 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12DtsM-0002aB-00 for namedroppers@ops.ietf.org; Thu, 27 Jan 2000 10:42:38 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12DtsL-0009t1-00 for namedroppers@ops.ietf.org; Thu, 27 Jan 2000 10:42:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 27 Jan 2000 07:39:48 -0500 From: markk@netsol.com To: namedroppers@ops.ietf.org Subject: test message - please ignore Message-ID: <20000127073948.A667@borg.internic.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Checking if the list works hosted on a new machine. Mark to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jan 27 18:48:04 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16865 for ; Thu, 27 Jan 2000 18:48:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Dxbg-0004pz-00 for namedroppers-data@psg.com; Thu, 27 Jan 2000 14:41:40 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Dxbg-0004pt-00 for namedroppers@ops.ietf.org; Thu, 27 Jan 2000 14:41:40 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Dxbg-000Bdg-00 for namedroppers@ops.ietf.org; Thu, 27 Jan 2000 14:41:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: namedroppers Subject: list has new home Message-Id: Date: Thu, 27 Jan 2000 14:39:27 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit the venerable namedroppers has moved. as mark warned, it is now at ops.ietf.org. at netsol, forwarding aliases have been set up for the nonce, but please change your address books and habits. standard -request and majordomo conventions should all work. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jan 28 10:57:39 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16547 for ; Fri, 28 Jan 2000 10:57:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12ECjh-000BpI-00 for namedroppers-data@psg.com; Fri, 28 Jan 2000 06:50:57 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12ECjh-000BpC-00 for namedroppers@ops.ietf.org; Fri, 28 Jan 2000 06:50:57 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12ECjh-000IMy-00 for namedroppers@ops.ietf.org; Fri, 28 Jan 2000 06:50:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: namedroppers Subject: Re: list has new home References: Message-Id: Date: Fri, 28 Jan 2000 06:03:43 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jan 31 09:25:46 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04250 for ; Mon, 31 Jan 2000 09:25:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12FGhF-0002LZ-00 for namedroppers-data@psg.com; Mon, 31 Jan 2000 05:16:49 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12FGhF-0002LT-00 for namedroppers@ops.ietf.org; Mon, 31 Jan 2000 05:16:49 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12FGhB-000JBc-00 for namedroppers@ops.ietf.org; Mon, 31 Jan 2000 05:16:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <01BF6C01.12E30C20.srinivvs@future.futsoft.com> From: SRINIVASU V V S To: "'namedroppers@ops.ietf.org'" Subject: Info about Full resolver Date: Mon, 31 Jan 2000 15:37:24 +0530 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit hi all, i am implementing full resolver and stub resolver.. my doubts are as follows: 1) i think a full resolver needs to be as a separate task ... but is there any need for a stub resolver also to be a separate task.. i have seen so many stub resolvers running under the applications context.. 2) If u want to implement TCP queries how it will be efficient in case of full resolver, in which it has to contact so many name servers for a single query.. one more, there is a facility like TCP (stayopen) in LINUX .. can we implement this in Full resolver kindly clear my doubts thanx and regards, srini to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.