From owner-namedroppers@ops.ietf.org Tue Feb 1 01:44:24 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28743 for ; Tue, 1 Feb 2000 01:44:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12FVyb-000HOS-00 for namedroppers-data@psg.com; Mon, 31 Jan 2000 21:35:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12FVya-000HOM-00 for namedroppers@ops.ietf.org; Mon, 31 Jan 2000 21:35:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12FVya-000OvQ-00 for namedroppers@ops.ietf.org; Mon, 31 Jan 2000 21:35:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38964D13.FB06802F@daimlerchrysler.com> Date: Mon, 31 Jan 2000 22:03:47 -0500 From: Kevin Darcy To: SRINIVASU V V S CC: "'namedroppers@ops.ietf.org'" Subject: Re: Info about Full resolver References: <01BF6C01.12E30C20.srinivvs@future.futsoft.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit SRINIVASU V V S wrote: > 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 A full resolver wouldn't *necessarily* have to run as a separate task; one could theoretically co-ordinate the use of system resources, including a centralized name cache and UDP/TCP port usage, between multiple tasks. But most implementors find it easier and more versatile to just run a "caching-only" nameserver accessed by stub resolvers, than to implement a "full" resolver. What value would there be in running the stub resolver as a separate task, given, as above, the option of running a caching-only nameserver as a separate task instead? I don't really understand the first part of question (2): like stub resolvers, full resolvers would presumably use UDP whenever possible, for efficiency. Even if *forced* to use TCP, I don't know that it would usually be advantageous for them to keep the connections open; typical nameserver-usage patterns are so diverse, that such a resolver might incur more overhead keeping the connections open (keepalives and whatnot) than it would building them and tearing them down again "on demand". Besides, I think most nameserver implementations will shut down the TCP connection on the server-side once the answer is given. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 1 07:46:03 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13386 for ; Tue, 1 Feb 2000 07:46:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Fc0E-000Nxj-00 for namedroppers-data@psg.com; Tue, 01 Feb 2000 04:01:50 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Fc0D-000Nxd-00 for namedroppers@ops.ietf.org; Tue, 01 Feb 2000 04:01:49 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Fc0D-0001ag-00 for namedroppers@ops.ietf.org; Tue, 01 Feb 2000 04:01:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <01BF6CB7.3D64E2A0.srinivvs@future.futsoft.com> From: SRINIVASU V V S To: "'bind-users@isc.org'" , "'namedroppers@ops.ietf.org'" Subject: "A" records missing for NS - suggest a sol Date: Tue, 1 Feb 2000 13:21:23 +0530 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit hi all, If the NS records are present and the corresponding 'A' records are missing then we will start using sysquery() to resolve the address of the name server. but my doubt is if some of the name servers addresses are present and some are missing in the "list of name servers(SLIST)" that we are going to query.. then what is the solution .. plz suggest a procedure for the above thanks in advance, 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. From owner-namedroppers@ops.ietf.org Wed Feb 2 09:26:55 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10355 for ; Wed, 2 Feb 2000 09:26:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Fzg1-0004HI-00 for namedroppers-data@psg.com; Wed, 02 Feb 2000 05:18:33 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Fzg0-0004HC-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 05:18:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Fzfz-000AyT-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 05:18:31 -0800 Message-Id: <200002021135.GAA03129@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-dnsext-signing-auth-00.txt Date: Wed, 02 Feb 2000 06:35:57 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System Security (DNSSEC) Signing Authority Author(s) : B. Wellington Filename : draft-ietf-dnsext-signing-auth-00.txt Pages : 7 Date : 01-Feb-00 This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-signing-auth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-signing-auth-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000201143558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-signing-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-signing-auth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000201143558.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 2 09:27:12 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10377 for ; Wed, 2 Feb 2000 09:27:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Fzg6-0004HS-00 for namedroppers-data@psg.com; Wed, 02 Feb 2000 05:18:38 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Fzg6-0004HM-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 05:18:38 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Fzg6-000AyY-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 05:18:38 -0800 Message-Id: <200002021136.GAA03143@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-dnsext-simple-secure-update-00.txt Date: Wed, 02 Feb 2000 06:36:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Simple Secure Domain Name System (DNS) Dynamic Update Author(s) : B. Wellington Filename : draft-ietf-dnsext-simple-secure-update-00.txt Pages : 9 Date : 01-Feb-00 This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-simple-secure-update-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-simple-secure-update-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000201143628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-simple-secure-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-simple-secure-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000201143628.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 2 10:23:17 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12215 for ; Wed, 2 Feb 2000 10:23:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12G0uO-0005p7-00 for namedroppers-data@psg.com; Wed, 02 Feb 2000 06:37:28 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Fzg6-0004HM-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 05:18:38 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Fzg6-000AyY-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 05:18:38 -0800 Message-Id: <200002021136.GAA03143@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-dnsext-simple-secure-update-00.txt Date: Wed, 02 Feb 2000 06:36:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Simple Secure Domain Name System (DNS) Dynamic Update Author(s) : B. Wellington Filename : draft-ietf-dnsext-simple-secure-update-00.txt Pages : 9 Date : 01-Feb-00 This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-simple-secure-update-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-simple-secure-update-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000201143628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-simple-secure-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-simple-secure-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000201143628.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 2 10:33:17 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12617 for ; Wed, 2 Feb 2000 10:33:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12G0vd-0005qF-00 for namedroppers-data@psg.com; Wed, 02 Feb 2000 06:38:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Fzg0-0004HC-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 05:18:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Fzfz-000AyT-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 05:18:31 -0800 Message-Id: <200002021135.GAA03129@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-dnsext-signing-auth-00.txt Date: Wed, 02 Feb 2000 06:35:57 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System Security (DNSSEC) Signing Authority Author(s) : B. Wellington Filename : draft-ietf-dnsext-signing-auth-00.txt Pages : 7 Date : 01-Feb-00 This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-signing-auth-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-signing-auth-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000201143558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-signing-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-signing-auth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000201143558.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 2 17:07:33 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22766 for ; Wed, 2 Feb 2000 17:07:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12G6z7-000Btd-00 for namedroppers-data@psg.com; Wed, 02 Feb 2000 13:06:45 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12G6z6-000BtW-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 13:06:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12G6z6-000Dwc-00 for namedroppers@ops.ietf.org; Wed, 02 Feb 2000 13:06:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 2 Feb 2000 16:04:39 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: New draft on zone status coming Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A new draft on Zone Status has been submitted. This will come out as ...dnsext...-00.txt, it is the second version of the draft that originated as ..dnsind...-00.txt. The only change to this later edition is the inclusion of section 3.4, a discussion of issues relating to dynamic update. I have received no feedback to the first draft, the update was driven by a personal epiphany on the topic. Please give this draft a critical look when it is posted. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Feb 4 10:40:02 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00423 for ; Fri, 4 Feb 2000 10:40:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Gk3R-000GJd-00 for namedroppers-data@psg.com; Fri, 04 Feb 2000 06:49:49 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Gk3R-000GJX-00 for namedroppers@ops.ietf.org; Fri, 04 Feb 2000 06:49:49 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Gk3R-0003nc-00 for namedroppers@ops.ietf.org; Fri, 04 Feb 2000 06:49:49 -0800 Message-Id: <200002041139.GAA21930@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-zone-status-00.txt Date: Fri, 04 Feb 2000 06:39:48 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Extension Clarification on Zone Status Author(s) : E. Lewis Filename : draft-ietf-dnsext-zone-status-00.txt Pages : 10 Date : 03-Feb-00 The definition of a secured zone is presented, updating RFC 2535. The new definition has consequences which alter the interpretation of the NXT record, obsolete NULL keys, and the designation of 'experimentally secure.' A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-zone-status-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-zone-status-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000203131053.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-zone-status-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-zone-status-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000203131053.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Feb 4 10:46:05 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00550 for ; Fri, 4 Feb 2000 10:46:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12GjnN-000FUB-00 for namedroppers-data@psg.com; Fri, 04 Feb 2000 06:33:13 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12GjnM-000FU5-00 for namedroppers@ops.ietf.org; Fri, 04 Feb 2000 06:33:12 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12GjnL-0003h0-00 for namedroppers@ops.ietf.org; Fri, 04 Feb 2000 06:33:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <01BF6EFD.A1A9BC20.srinivvs@future.futsoft.com> From: SRINIVASU V V S To: "'namedroppers@ops.ietf.org'" Subject: how NS handles mutiple queries Date: Fri, 4 Feb 2000 10:50:19 +0530 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit hi all, How a typical recursive name server handles mutiple queries. i think it has forked only once for its task.. my questions are : 1) A name server should send a query to some other name server for one of the request and wait for some time for its retransmission. Meanwhile if some other query times out it has to handle that also..how it diverts it's attention.. 2) The above situation becomes more complicated when some of the connections are TCP and some are UDP.. may be i am a bit confused.. plz suggest any docs for more info.. thanks in advance 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. From owner-namedroppers@ops.ietf.org Fri Feb 4 11:52:17 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02525 for ; Fri, 4 Feb 2000 11:52:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12GlG9-000HVW-00 for namedroppers-data@psg.com; Fri, 04 Feb 2000 08:07:01 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12GlG9-000HVQ-00 for namedroppers@ops.ietf.org; Fri, 04 Feb 2000 08:07:01 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12GlG9-0004Kv-00 for namedroppers@ops.ietf.org; Fri, 04 Feb 2000 08:07:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002041606.LAA09011@grosse.manhattan.fugue.com> To: SRINIVASU V V S cc: "'namedroppers@ops.ietf.org'" Subject: Re: how NS handles mutiple queries In-Reply-To: Message from SRINIVASU V V S of "Fri, 04 Feb 2000 10:50:19 +0530." <01BF6EFD.A1A9BC20.srinivvs@future.futsoft.com> Date: Fri, 04 Feb 2000 11:06:15 -0500 From: Ted Lemon Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1) A name server should send a query to some other name server for one of > the request and wait for some time for its retransmission. Meanwhile if > some other query times out it has to handle that also..how it diverts it's > attention.. The solution to this problem is to process requests (incoming and outgoing) and maintain state on pending requests, rather than simply handling one request to completion and ignoring other requests that come in while the first request is pending with some other server. You might consider reading over the source code to BIND 8 to see how it does it! :') _MelloN_ to unsubscribe send a message to 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 Feb 7 09:34:25 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10684 for ; Mon, 7 Feb 2000 09:34:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Hnwo-000CLq-00 for namedroppers-data@psg.com; Mon, 07 Feb 2000 05:11:22 -0800 Received: from mg130-037.ricochet.net ([204.179.130.37] helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12Hnwl-000CLj-00 for namedroppers@ops.ietf.org; Mon, 07 Feb 2000 05:11:20 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Hnwu-0000fT-00 for namedroppers@ops.ietf.org; Mon, 07 Feb 2000 05:11:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002070426.XAA05296@torque.pothole.com> To: Edward Lewis cc: "Donald E. Eastlake 3rd" , namedroppers@internic.net Subject: Re: WG Last Call: TKEY In-reply-to: Your message of "Tue, 04 Jan 2000 09:50:00 EST." Date: Sun, 06 Feb 2000 23:26:09 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ed, From: Edward Lewis 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" Cc: namedroppers@internic.net >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. Well, I suppose it all depends on your point of view. I do consider requests to move requirements around in a document to be more minor than requests to add or delete requirements... However, I must say that the process of reviewing and re-organization this material was a lot more work than I thought it would be and has lead, in my opinion, to a lot more improvement than I though it would. In fact, I found cases that said "SHOULD" which have to say "MUST" to actually achieve security. I belive the next version of the draft, which I hope to add the final touches to later tonight, will be a really substantial improvement. >... >>(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. I've banished "host" from the document. >... > >>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? There are three reasons for the error field in TKEY. Originally the draft permitted multiple TKEY RRs in a request and you could therefore have multiple errors in a response (it was restricted in number and variety so you could tell the responses apart). This reason has gone away with the simplification to one TKEY per DNS message. Second, TKEY Errors can be > 15 so in some casee they do not fit in the DNS message header RCODE field. Third, there is a provision for spontaneous inclusion of TKEY in a response. This is optional to implement but such spontaneous inclusion might sometime require a non-zero error code unrelated to the DNS message header RCODE. Based on all this it seems best to not use the DNS header RCODE field, so the current -dnsind-tkey-03.txt draft on page 7 where the error codes are listed says the following which I essentially plan to retain in the next draft: When an extended RCODE appears in the TKEY in a response, the DNS header RCODE field indicates no error. >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >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 Thanks, Donald =================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Rd, RR#1 lde008@dma.isg.mot.com Carmel, NY 10512 USA +1 914-276-2668(h) +1 508-261-5434(w) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 7 11:57:18 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15144 for ; Mon, 7 Feb 2000 11:57:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12HqXd-000FD7-00 for namedroppers-data@psg.com; Mon, 07 Feb 2000 07:57:33 -0800 Received: from [216.33.132.75] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12HqXd-000FD1-00 for namedroppers@ops.ietf.org; Mon, 07 Feb 2000 07:57:33 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12HqXn-00012a-00 for namedroppers@ops.ietf.org; Mon, 07 Feb 2000 07:57:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200002070426.XAA05296@torque.pothole.com> References: Your message of "Tue, 04 Jan 2000 09:50:00 EST." Date: Mon, 7 Feb 2000 09:10:30 -0500 To: "Donald E. Eastlake 3rd" From: Edward Lewis Subject: Re: WG Last Call: TKEY Cc: Edward Lewis , "Donald E. Eastlake 3rd" , namedroppers@internic.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:26 PM -0500 2/6/00, Donald E. Eastlake 3rd wrote: >However, I must say that the process of reviewing and re-organization >this material was a lot more work than I thought it would be and has >lead, in my opinion, to a lot more improvement than I though it would. >In fact, I found cases that said "SHOULD" which have to say "MUST" to >actually achieve security. This is what I thought would happen. By following a stricter discipline (e.g., no requirements in intro, discussions), I have found that the result is much better. Not only do the aesthetics improve, the reorganization effort often finds other places where one can tighten the work. I think the reason is that the author sees the requirements from another angle, performing another round of requirements analysis. >Based on all this it seems best to not use the DNS header RCODE field, >so the current -dnsind-tkey-03.txt draft on page 7 where the error >codes are listed says the following which I essentially plan to retain >in the next draft: > > When an extended RCODE appears in the TKEY in a response, the DNS > header RCODE field indicates no error. I think it is wise to report an error just once, lest you start seeing messages with multiple error codes, leading to confusion by the reader. Writing a "good" client that understands the error codes is very hard once we start indicating multiple failures. OTOH, reporting "no error" in the header field is probably misleading, is there a "error inside" value? That being said, I think having "no error" in the header field is better than having some other specific error code there. --- There is a paper by Ferguson & Schneier called "A Cryptographic Evaluation of IPsec," unfortunately I have a copy for which I cannot give a published reference[1] (it was handed to me). In this, they[2] criticize IPsec from a security/cryptographic point of view. I think that some of the interesting points are the claims that the documentation of IPsec prevents good security analysis, as well as the protocol's complexity making it hard to ensure that security is "attained." The reason I am riding the DNS security documents hard is to try and avoid the same criticisms if DNS security. [1] There is a URL: www.counterpane.com under the title. [2] Assuming the paper did not forge their typed names...;) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 8 11:55:36 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01658 for ; Tue, 8 Feb 2000 11:55:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12ICpm-000Pw6-00 for namedroppers-data@psg.com; Tue, 08 Feb 2000 07:45:46 -0800 Received: from t75-132.nanog.exodus.net ([216.33.132.75] helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12ICpl-000Pw0-00 for namedroppers@ops.ietf.org; Tue, 08 Feb 2000 07:45:45 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12ICq7-0001c1-00 for namedroppers@ops.ietf.org; Tue, 08 Feb 2000 07:46:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <389EAA75.D7209D01@pobox.org.sg> Date: Mon, 07 Feb 2000 19:20:21 +0800 From: James Seng To: Ted Lemon CC: SRINIVASU V V S , "'namedroppers@ops.ietf.org'" Subject: Re: how NS handles mutiple queries References: <200002041606.LAA09011@grosse.manhattan.fugue.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit BIND 4 or 8 does not fork. Nor does it do multi-treading. It is a single process and maintain a queue for each recursive query (and remove them when it recieves a response). The relevant algo can be described as: If Incoming is Query Packet Then // ns_req Query Packet If in cache or authorizative for Query Then Response with appropriate answer Else If Recursive Query And Server able to do Recursion Then If ID already exist in Queue Then // Well, be patient. I am still waiting from the recursion Else Put Query ID and IP onto Queue Recurse the query EndIf Else Response Error EndIf Else // ns_resp Response Packet (received from recursive query) If ID match one in queue Then Response with answer from recursion Remove ID from Queue Else Response Error EndIf EndIf Of course, in between there are other stuff like cache etc. -James Seng Ted Lemon wrote: > > 1) A name server should send a query to some other name server for one of > > the request and wait for some time for its retransmission. Meanwhile if > > some other query times out it has to handle that also..how it diverts it's > > attention.. > > The solution to this problem is to process requests (incoming and > outgoing) and maintain state on pending requests, rather than simply > handling one request to completion and ignoring other requests that > come in while the first request is pending with some other server. > You might consider reading over the source code to BIND 8 to see how > it does it! :') > > _MelloN_ > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 8 13:35:01 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06640 for ; Tue, 8 Feb 2000 13:34:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12IEj9-0002Cq-00 for namedroppers-data@psg.com; Tue, 08 Feb 2000 09:47:03 -0800 Received: from t75-132.nanog.exodus.net ([216.33.132.75] helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12IEj9-0002Ck-00 for namedroppers@ops.ietf.org; Tue, 08 Feb 2000 09:47:03 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12IEjV-0001iW-00 for namedroppers@ops.ietf.org; Tue, 08 Feb 2000 09:47:25 -0800 Message-Id: <200002081131.GAA13497@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tkey-00.txt Date: Tue, 08 Feb 2000 06:31:12 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Secret Key Establishment for DNS (TKEY RR) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tkey-00.txt Pages : 17 Date : 07-Feb-00 [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating Domain Name System (DNS) queries and responses using shared secret keys via the TSIG resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a TKEY RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-tkey-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tkey-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000207125434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000207125434.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 10 02:37:00 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17003 for ; Thu, 10 Feb 2000 02:36:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12InAC-000KjF-00 for namedroppers-data@psg.com; Wed, 09 Feb 2000 22:33:16 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12InAC-000Kj9-00 for namedroppers@ops.ietf.org; Wed, 09 Feb 2000 22:33:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12InAB-000E88-00 for namedroppers@ops.ietf.org; Wed, 09 Feb 2000 22:33:15 -0800 Date: 10 Feb 2000 04:38:02 -0000 Message-ID: <20000210043802.14136.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Truncation interoperability problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk RFC 1035 says that UDP messages ``are restricted to 512 bytes .... Longer messages are truncated and the TC bit is set.'' The obvious interpretation of ``truncated'' here is ``truncated to 512 bytes.'' In my new cache, when I have a message longer than 512 bytes to send by UDP, I truncate it to 512 bytes and set the TC bit. Unfortunately, Squid, a popular client, dies if it receives a UDP packet truncated in the middle of an answer record. Dying is much more serious than merely dropping truncated packets, as most clients do. BIND doesn't trigger this Squid bug, because BIND truncates messages between records. In this case, Squid uses a record set that's almost always incomplete; this behavior is still wrong but users don't notice. I am considering the following solution for my cache: when the answer section goes past the 512-byte mark, truncate it immediately after the query, and set the TC bit. From a correct client's point of view, all record sets are potentially incomplete in this situation, so the packet has to be discarded in any case. Eliminating the useless records also prevents confused clients from using incomplete record sets. Does BIND's truncation at <512 bytes comply with RFC 1035? Does truncation immediately after the query comply with RFC 1035? Are there any uses of truncated packets for which this would cause problems? DNSEXT should issue a clarification here, to point out any relevant interoperability issues and make clear what has to be done. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 10 11:46:21 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03629 for ; Thu, 10 Feb 2000 11:46:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Ivmc-0004KK-00 for namedroppers-data@psg.com; Thu, 10 Feb 2000 07:45:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Ivmc-0004KE-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 07:45:30 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Ivmc-000I3a-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 07:45:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: Truncation interoperability problems In-Reply-To: Message from "D. J. Bernstein" dated "Thu, 10 Feb 2000 01:52:36 EST" <20000210043802.14136.qmail@cr.yp.to> References: <20000210043802.14136.qmail@cr.yp.to> From: Rob Austein Message-Id: <20000210083019Z23276-3955+55@thrintun.hactrn.net> Date: Thu, 10 Feb 2000 03:30:05 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In theory it is possible for a packet with a truncated answer section to be marginally useful if the first RR in the answer section is intact and happens to be a CNAME. to unsubscribe send a message to 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 Feb 10 11:53:36 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03774 for ; Thu, 10 Feb 2000 11:53:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Ivzt-0004fP-00 for namedroppers-data@psg.com; Thu, 10 Feb 2000 07:59:13 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Ivzt-0004fJ-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 07:59:13 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Ivzt-000I8T-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 07:59:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "D. J. Bernstein" Cc: namedroppers@internic.net Subject: Re: Truncation interoperability problems In-Reply-To: Your message of "10 Feb 2000 04:38:02 -0000." <20000210043802.14136.qmail@cr.yp.to> Date: Thu, 10 Feb 2000 22:09:26 +1100 Message-Id: <3995.950180966@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: 10 Feb 2000 04:38:02 -0000 From: "D. J. Bernstein" Message-ID: <20000210043802.14136.qmail@cr.yp.to> | RFC 1035 says that UDP messages ``are restricted to 512 bytes .... | Longer messages are truncated and the TC bit is set.'' | The obvious interpretation of ``truncated'' here is ``truncated to 512 | bytes.'' I don't think that's obvious at all, though it is clearly one of the possible interpretations. I guess the question is what is the point of sending a partial RR? It shouldn't do any harm to a properly implemented resolver, but it cannot possibly do any good either, the best that can happen is for the resolver to ignore that partial record (or just treat the whole answer as a request to try again using TCP). The only benefit would appear to be a trivial simplifying of the packet building code in the server, the cost (aside from violating "be conservative in what you send") is that poorly written resolvers are much more likely to fail, and those extra few bytes of meaningless overhead being transported around. | In my new cache, when I have a message longer than 512 bytes to | send by UDP, I truncate it to 512 bytes and set the TC bit. Sounds like lazy coding to me. | Unfortunately, Squid, a popular client, dies if it receives a UDP packet | truncated in the middle of an answer record. Dying is much more serious | than merely dropping truncated packets, as most clients do. That's not good. I assume you have sent a bug report to the squid people? | BIND doesn't trigger this Squid bug, because BIND truncates messages | between records. In this case, Squid uses a record set that's almost | always incomplete; this behavior is still wrong but users don't notice. No, not wrong, for an application, what squid does there is just fine. Caches (DNS caches, squid being a web cache starts to overload the term...) aren't allowed to remember partial RRsets - but there is no reason at all for a client to fail to use the data it has been able to obtain. There is no basic difference between getting back one (or two) A records and using that one (or two) than getting back a dozen (or more) and ignoring all but the first one returned, which is what many applications do with the data they get back. | I am considering the following solution for my cache: when the answer | section goes past the 512-byte mark, truncate it immediately after the | query, and set the TC bit. That would be legal as well, though less useful to those clients (like squid apparently) that simply want any data as quickly as possible, and don't care whether or not they have all of the data. | From a correct client's point of view, all | record sets are potentially incomplete in this situation, All record sets in the section that was in progress where the truncation occurred, yes. It is entirely possible for there to be a complete answer, or answer and authority section, but truncation after that (in the additional data). In that case, everything in the sections that are complete is intact, and completely useable. | so the packet has to be discarded in any case. No, not at all, some of the data might be complete and useable. Even for the parts that are not, it is for the client to decide whether the amount that it received is enough to be useful or not. Only DNS caches are prohibited from using partial RRsets - because they have no idea whether the client they would later return the partial set to needs the whole set, or only a part. | Eliminating the useless records also | prevents confused clients from using incomplete record sets. Perfectly reasonable clients can use partial RRsets. You don't need to protect them from themselves. | Does BIND's truncation at <512 bytes comply with RFC 1035? Yes. | Does truncation immediately after the query comply with RFC 1035? Yes. | Are there | any uses of truncated packets for which this would cause problems? Yes, as above (especially if you are going to drop sections that were complete because of a later section which does not completely fit). If you really feel you must protect clients from using partial RRsets, drop just the one (entire) RRset that would not fit in the reply. If that means that you are left with just the question, and no answers at all, then so be it. Usually it won't. | DNSEXT should issue a clarification here, to point out any relevant | interoperability issues and make clear what has to be done. This does something that sounds as if it could have usefully been covered in 2181, had anyone thought of it then, and perhaps should be in 2181bis or in a similar doc. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 10 12:16:23 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04537 for ; Thu, 10 Feb 2000 12:16:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Iw7X-0004uS-00 for namedroppers-data@psg.com; Thu, 10 Feb 2000 08:07:07 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Iw7W-0004uM-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 08:07:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Iw7W-000IAe-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 08:07:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <20000210043802.14136.qmail@cr.yp.to> Date: Thu, 10 Feb 2000 08:39:50 -0500 To: "D. J. Bernstein" From: Edward Lewis Subject: Re: Truncation interoperability problems Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 11:38 PM -0500 2/9/00, D. J. Bernstein wrote: >The obvious interpretation of ``truncated'' here is ``truncated to 512 >bytes.'' I disagree with your interpretation, therefore I do not consider your interpretation to be "obvious." IMHO, a resolver, upon seeing the TC bit set to indicate truncation should initiate a TCP request to the responding server to get a complete answer. Trying to make use of a truncated reply is an effort of questionable payoff. As the resolver had just gotten an answer from a server to which TCP is to be initiated, the resolver already knows the IP address of a server containing the answer. Barring a failure within the next few seconds, the TCP interaction will have the complete answer in the resolver's hands within a few seconds. If the resolver thinks that a few seconds is too long to wait, the resolver must be in the position to judge whether the data in hand is all that is needed. This sounds like a decision that a general purpose resolver would be hard pressed to make. E.g., let's say an A record set for a name results in a truncated answer because the domain name has so many addresses, each address only reachable by some subset of the network. Using round-robining of answers, it would be hard to predict whether the one A record is included or truncated, imagine what computation the resolver would have to undertake to find the right answer and whether it is present. It would be more economical to just initiate the TCP connection and pass the answer to the application. Recall that a TCP delivered response contains the data in the UDP message plus the missing records, so there is no saving of time in partially processing the included data. As far as a resolver crashing because of a record being malformed, or the record counts being incorrectly sent, this is something that should be remedied in the resolver. No software that crashes is correct. As far as the resolver's attempt to parse the body of the message even though the TC bit is set, I would consider this unwise. I do not mean to disparage the reputation of the author/authors of the resolver, but I would recommend correcting the resolver to avoid crashes on malformed data and to quite processing a response if there is something anomolous in the header, such as the TC bit. As far as whether a server whould truncate on a 512 byte count boundary or on an RR or RR set boundary, I would vote for the RR set boundary. This is a bit more computationally intensive than on a strict 512 byte boundary. The principle I apply here in this decision is "be conservative in what you send, liberal in what you parse." PS - Truncating on a byte count boundary will be less deterministic once the EDNS feature allowing larger UDP segments becomes operational. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 10 12:18:40 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04653 for ; Thu, 10 Feb 2000 12:18:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Iw7q-0004uj-00 for namedroppers-data@psg.com; Thu, 10 Feb 2000 08:07:26 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Iw7p-0004ud-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 08:07:25 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12Iw7p-000IAr-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 08:07:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <20000210043802.14136.qmail@cr.yp.to> Date: Thu, 10 Feb 2000 08:58:05 -0500 To: "D. J. Bernstein" From: Edward Lewis Subject: part 2 Re: Truncation interoperability problems Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I should have consulted 1035 before sending the previous message. No where does the RFC 1035 specify how a message is to be truncated, except for this passage in section 6.2: #When a response is so long that truncation is required, the truncation #should start at the end of the response and work forward in the #datagram. Thus if there is any data for the authority section, the #answer section is guaranteed to be unique. This only demands that the message is shaved from the bottom. Nothing is said about the granularity of the shaving. (Note that this says "should" and not "must," however, RFC 2119 had not yet been available to define the severity of a "should.") Note that other RFCs do describe an RR set based algorithm for truncating data. For example, see RFC 2535, section 4.2. Compare the first and second clauses. I would consider the truncation you described as legal. As for the rest of my previous message, it stands, i.e., I would not interpret the truncation as being on the 512 byte boundary, I don't agree that the interpretaion you offer is obvious, and that the resolver you cite is buggy. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 10 17:34:51 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12330 for ; Thu, 10 Feb 2000 17:34:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12J1LT-000IIm-00 for namedroppers-data@psg.com; Thu, 10 Feb 2000 13:41:51 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12J1LT-000IIg-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 13:41:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12J1LS-0004cd-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 13:41:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: (qmail 19806 invoked by uid 1001); 10 Feb 2000 21:40:27 -0000 Date: 10 Feb 2000 21:40:27 -0000 Message-ID: <20000210214027.27794.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Truncation interoperability problems References: <20000210043802.14136.qmail@cr.yp.to> <3995.950180966@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz writes: [ removing a set from the answer section removes the whole section? ] > Usually it won't. Where do you get that idea? Squid sends A queries and PTR queries, not * queries. In theory there could be CNAMEs, but there aren't any in my random sample of truncated packets. Anyway, CNAME records are useless for most clients. The big exception is MTAs. MTAs currently care about CNAMEs---although this practice is going away. To work around BIND's lameness problems, MTAs use * lookups to check for CNAMEs. In this case, however, my cache stops the answer after one cached record set anyway. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Feb 11 00:02:20 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18589 for ; Fri, 11 Feb 2000 00:02:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12J7eC-000Chv-00 for namedroppers-data@psg.com; Thu, 10 Feb 2000 20:25:36 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12J7eB-000Cho-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 20:25:35 -0800 Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12J7eB-0007Tg-00 for namedroppers@ops.ietf.org; Thu, 10 Feb 2000 20:25:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000210231521.00c96810@sentry.gw.tislabs.com> Date: Thu, 10 Feb 2000 23:21:27 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Fwd: Internet-Draft Cut-off for Adelaide IETF Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The cut-off for Internet-Draft submissions prior to the > Adelaide, Australia IETF meeting is Friday, March 10, 2000 > at 5 pm US-ET. Internet-Drafts received after this time will NOT > be announced nor made available in the Internet-Drafts > Directories. > > NOTE: All initial submissions (-00.txt) with a filename > beginning with draft-ietf MUST be approved by the > appropriate WG Chair prior to processing and announcing. > WG Chair approval must be received prior to the I-D cut-off > date. Please send me copies of your 00 drafts ASAP and no later than March 5'th that so I can determine if the draft is candidate to be admitted as a working group document. Thank you Olafur (the WG document dictator :-) -------- 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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 15 11:25:22 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12251 for ; Tue, 15 Feb 2000 11:25:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12KjgM-000HVc-00 for namedroppers-data@psg.com; Tue, 15 Feb 2000 07:14:30 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12KjgM-000HVW-00 for namedroppers@ops.ietf.org; Tue, 15 Feb 2000 07:14:30 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12KjgL-0009T0-00 for namedroppers@ops.ietf.org; Tue, 15 Feb 2000 07:14:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002151339.IAA17975@torque.pothole.com> To: Domain Names WG cc: lde008@dma.isg.mot.colm Subject: DNS Error Codes Date: Tue, 15 Feb 2000 08:39:54 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, DNS headers provide for only a four bit error code so EDNS0 added an 8 bit extension, bringing it up to 12 bits, and assigned value 16 for BADVERS. Since this is out in an RFC, I think its pretty fixed. I believe the current tsig draft assignes 16-18 with a different meaning for 16. When this was noted, I posted something to the effect that I thought EDNS won, having gotten there first, and I don't recall any response to this on the list. When I updated the tkey draft, I bumped the tsig and tkey error numbers up by one to avoid the conflict. This is the dnsext TKEY draft currently out there. However, I now understand that there is enough tsig deployment that this may be a problem. I have just sent a message to internet-drafts requesting that be posted. This is a minor update, mostly just providing that the IESG may appoint an expert, in addition to the provisions in earlier iana-dns drafts. In it, we did not bump the error codes, and show 16 as multiply assigned with a unified EDNS/OPT, TSIG, TKEY error space. It seems to me there is a three way choice: (1) Have a unified error space and bump the tsig and tkey error codes up by one. This is the cleanest but may be difficult due to tsig deployment. (2) Have a unified error space with the assignment documented in the new IANA-DNS draft. This has the wart that code 16 has different meaning in OPT than in TSIG but it is not clear that this would be much problem in practice. (3) Have disjoint OPT and TSIG/TKEY error spaces. This may seem clean now but in the long run, I think it would be a disaster. Presumably codes <16 would be joint anyway. And there are bound to be future cases where the same error needs to be defined in both and there will be great pressure to use the same valude and/or symbol resulting eventually in a crazy patchwork of joint and disjoint error numbers. I suggest we go for option 2. Whichever way we go, it will be a very minor edit to make the tkey and iana-dns drafts consistent with the decision. Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) Carmel, NY 10512 USA +1 508-261-5434(w) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 15 15:12:44 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21023 for ; Tue, 15 Feb 2000 15:12:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12KnYj-000Kgj-00 for namedroppers-data@psg.com; Tue, 15 Feb 2000 11:22:53 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12KnYi-000Kgd-00 for namedroppers@ops.ietf.org; Tue, 15 Feb 2000 11:22:52 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12KnYh-000BHf-00 for namedroppers@ops.ietf.org; Tue, 15 Feb 2000 11:22:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 15 Feb 2000 19:19:52 -0000 Message-ID: <20000215191952.24273.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@internic.net Subject: a.dns.int Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As has been discussed here before, many system administrators would like to use IP addresses in NS records and MX records. I propose that DNSEXT update RFC 1034 to require that DNS caches manufacture artificial A records for dotted-decimal IPv4 addresses (in canonical form), and for addresses with a.dns.int appended: e.g., 192.48.96.2. 604800 IN A 192.48.96.2 192.48.96.2.a.dns.int. 604800 IN A 192.48.96.2 You may object that these records won't be universally accessible until all caches have been upgraded. But we can also delegate .0 through .255 and a.dns.int to a bunch of servers that manufacture the same records. Unfortunately, BIND already goes out of its way to return NXDOMAIN for numeric TLDs. This is why I'm proposing a.dns.int: it's something that can be made to work for everyone very easily, as soon as desired. I already have a very small, very fast special-purpose server that manufactures PTR records and matching A records under in-addr.arpa for firewalls. See http://cr.yp.to/dnscache/faq/walldns.html. Adapting it for this job would be trivial. I also propose that dns.int be set aside for other subdomains that have global semantics but that are expected to be manufactured by caches. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 15 22:31: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 WAA03536 for ; Tue, 15 Feb 2000 22:31:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12KuKI-0005Pk-00 for namedroppers-data@psg.com; Tue, 15 Feb 2000 18:36:26 -0800 Received: from mg-206191146-175.ricochet.net ([206.191.146.175] helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12KuKC-0005PV-00 for namedroppers@ops.ietf.org; Tue, 15 Feb 2000 18:36:21 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12KuK3-0000ah-00 for namedroppers@ops.ietf.org; Tue, 15 Feb 2000 18:36:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19398D273324D3118A2B0008C7E9A56909493A89@SIT.platinum.corp.microsoft.com> From: James Gilroy To: "Donald E. Eastlake 3rd" , Domain Names WG Cc: lde008@dma.isg.mot.colm Subject: RE: DNS Error Codes Date: Tue, 15 Feb 2000 18:27:19 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I second the vote for option #2. I just plain missed the conflict and shipped a product with the current TSIG usage (BADSIG as 16). The key thing being to track these in the future and make sure that even for drafts we assign the number and avoid the conflict. jim > -----Original Message----- > From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] > Sent: Tuesday, February 15, 2000 5:40 AM > To: Domain Names WG > Cc: lde008@dma.isg.mot.colm > Subject: DNS Error Codes > > > Hi, > > DNS headers provide for only a four bit error code so EDNS0 added an 8 > bit extension, bringing it up to 12 bits, and assigned value 16 for > BADVERS. Since this is out in an RFC, I think its pretty fixed. > > I believe the current tsig draft assignes 16-18 with a different > meaning for 16. When this was noted, I posted something to the effect > that I thought EDNS won, having gotten there first, and I don't recall > any response to this on the list. > > When I updated the tkey draft, I bumped the tsig and tkey error > numbers up by one to avoid the conflict. This is the dnsext TKEY > draft currently out there. However, I now understand that there is > enough tsig deployment that this may be a problem. > > I have just sent a message to internet-drafts requesting that > be > posted. This is a minor update, mostly just providing that the IESG > may appoint an expert, in addition to the provisions in earlier > iana-dns drafts. In it, we did not bump the error codes, and show 16 > as multiply assigned with a unified EDNS/OPT, TSIG, TKEY error space. > > It seems to me there is a three way choice: > > (1) Have a unified error space and bump the tsig and tkey error codes > up by one. This is the cleanest but may be difficult due to tsig > deployment. > > (2) Have a unified error space with the assignment documented in the > new IANA-DNS draft. This has the wart that code 16 has different > meaning in OPT than in TSIG but it is not clear that this would be > much problem in practice. > > (3) Have disjoint OPT and TSIG/TKEY error spaces. This may seem clean > now but in the long run, I think it would be a disaster. Presumably > codes <16 would be joint anyway. And there are bound to be future > cases where the same error needs to be defined in both and there will > be great pressure to use the same valude and/or symbol resulting > eventually in a crazy patchwork of joint and disjoint error numbers. > > I suggest we go for option 2. > > Whichever way we go, it will be a very minor edit to make the tkey and > iana-dns drafts consistent with the decision. > > Donald > ===================================================================== > Donald E. Eastlake 3rd dee3@torque.pothole.com > 65 Shindegan Hill Road, RR#1 +1 914-276-2668(h) > Carmel, NY 10512 USA +1 508-261-5434(w) > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 01:51:41 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10580 for ; Wed, 16 Feb 2000 01:51:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Kxh5-000BjI-00 for namedroppers-data@psg.com; Tue, 15 Feb 2000 22:12:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Kxh4-000BjC-00 for namedroppers@ops.ietf.org; Tue, 15 Feb 2000 22:12:10 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Kxh4-000FKP-00 for namedroppers@ops.ietf.org; Tue, 15 Feb 2000 22:12:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002160310.OAA13296@bsdi.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@internic.net From: Mark.Andrews@nominum.com Subject: Re: a.dns.int In-reply-to: Your message of "15 Feb 2000 19:19:52 -0000." <20000215191952.24273.qmail@cr.yp.to> Date: Wed, 16 Feb 2000 14:10:46 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Unfortunately, BIND already goes out of its way to return NXDOMAIN for > numeric TLDs. This is why I'm proposing a.dns.int: it's something that > can be made to work for everyone very easily, as soon as desired. Dan, please stop spreading untruths. It is obvious that you did not attempt to even create such a zone because it you had you would have found out that there are no impediments. The following test zone loads without error as zone 1 on BIND 8.2.2-P5. Mark $TTL 3600 @ SOA bsdi.dv.isc.org. marka.isc.org. ( 1 3600 1200 3600000 3600 ) NS bsdi.dv.isc.org. 2.3.4 A 2.3.4.1 -- 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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 08:10:03 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25821 for ; Wed, 16 Feb 2000 08:09:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12L3Jl-000IuK-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 04:12:29 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12L3Jl-000IuE-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 04:12:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12L3Jk-000IGr-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 04:12:28 -0800 Message-Id: <200002161139.GAA22397@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-iana-dns-00.txt Date: Wed, 16 Feb 2000 06:39:20 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake, E. Brunner, B. Manning Filename : draft-ietf-dnsext-iana-dns-00.txt Pages : 12 Date : 15-Feb-00 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-dnsext-iana-dns-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-iana-dns-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-iana-dns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000215124111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-iana-dns-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-iana-dns-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000215124111.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 18:15:36 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18213 for ; Wed, 16 Feb 2000 18:15:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LCeW-000OKr-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 14:10:32 -0800 Received: from dengate.it.verio.net ([129.250.33.253] helo=dengate.verio.net) by psg.com with smtp (Exim 3.12 #1) id 12LCeW-000OKl-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 14:10:32 -0800 Received: from [172.16.1.121] by dengate.verio.net via smtpd (for psg.com [147.28.0.62]) with SMTP; 16 Feb 2000 21:02:39 UT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LCeb-0000g5-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 14:10:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38AB1C9D.D9565DDC@daimlerchrysler.com> Date: Wed, 16 Feb 2000 16:54:37 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: To Be Cached, or Not To Be Cached, That is the Question Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, Talking about OPT flags (EDNS0, EDNS1), how about one that means "Answer Will Not Be Cached"? Seems to me a Not-To-Be-Cached DNS answer could be optimized in some dramatic ways: 1. Except for referrals (and ???), the Authority and Additional sections could be omitted. 2. TTL fields could be omitted. Imagine the savings in packet sizes and processing costs! Although undoubtedly far more modest, maybe some optimizations could also be achieved for answers which a server knows is going to a caching-capable requestor. For instance, maybe a server could safely assume that a requestor capable of caching answers is also capable of performing sorting and/or ordering of answer sets, and could therefore forego such operations itself, thus eliminating duplicated sorting/ordering effort. Although a given client or server process would normally *always* set or not set the Not-To-Be-Cached flag for all queries it generates, in some circumstances I could see an application for dynamic and/or temporary switching of behavior, e.g. during a memory-exhaustion situation, a node which normally caches may switch to Not-To-Be-Cached queries while it goes about freeing up memory resources (presumably by purging old cache entries). A couple of caveats immediately spring to mind: 1. A server performing recursion should give a downstream client an answer in the format the client requests, regardless of the format the server uses to communicate with upstream servers. A non-caching server performing recursion should simply preserve the Not-To-Be-Cached flag and pass the answer through. A caching server performing recursion for a self-identified non-caching client should convert the answer to Not-To-Be-Cached format. 2. To reap full benefits of this optimization, the default for resolvers should at some point switch from To-Be-Cached to Not-To-Be-Cached. At that time, any applications using a resolver API, and which require "full" (To-Be-Cached) DNS answers, will need to explicitly turn on an option to get them. This will require a certain amount of advance notice and coordination, but should be fairly easily implementable with a construct like #ifdef RES_NOCACHE _res.options &= ~RES_NOCACHE; #endif Am I totally out to lunch here? Please point out the error of my ways. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 19:06:57 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18766 for ; Wed, 16 Feb 2000 19:06:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LDsJ-000P42-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 15:28:51 -0800 Received: from dengate.it.verio.net ([129.250.33.253] helo=dengate.verio.net) by psg.com with smtp (Exim 3.12 #1) id 12LDsJ-000P3u-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 15:28:51 -0800 Received: from [172.16.1.121] by dengate.verio.net via smtpd (for psg.com [147.28.0.62]) with SMTP; 16 Feb 2000 22:20:58 UT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LDsO-0000kx-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 15:28:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002162323.KAA16260@bsdi.dv.isc.org> To: Kevin Darcy Cc: namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: To Be Cached, or Not To Be Cached, That is the Question In-reply-to: Your message of "Wed, 16 Feb 2000 16:54:37 CDT." <38AB1C9D.D9565DDC@daimlerchrysler.com> Date: Thu, 17 Feb 2000 10:23:40 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Generally caching is a good thing and just because one client also has a cache is no reason not to cache an answer. So far in over 10 years of working with the DNS I have only found one example where the client requesting the cache be disabled would be useful. That case was discovering the zone a domain belonged to and even then only to disable negative caching. Mark -- 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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 19:09:55 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18798 for ; Wed, 16 Feb 2000 19:09:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LDyI-000P7t-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 15:35:02 -0800 Received: from dengate.it.verio.net ([129.250.33.253] helo=dengate.verio.net) by psg.com with smtp (Exim 3.12 #1) id 12LDyI-000P7k-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 15:35:02 -0800 Received: from [172.16.1.121] by dengate.verio.net via smtpd (for psg.com [147.28.0.62]) with SMTP; 16 Feb 2000 22:27:09 UT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LDyN-0000lV-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 15:35:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Kevin Darcy Cc: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question In-Reply-To: Your message of "Wed, 16 Feb 2000 16:54:37 CDT." <38AB1C9D.D9565DDC@daimlerchrysler.com> Date: Thu, 17 Feb 2000 10:29:34 +1100 Message-Id: <8129.950743774@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 16 Feb 2000 16:54:37 -0500 From: Kevin Darcy Message-ID: <38AB1C9D.D9565DDC@daimlerchrysler.com> | Talking about OPT flags (EDNS0, EDNS1), how about one | that means "Answer Will Not Be Cached"? I'm not sure the saving is worth it - it would need careful investigation of what canbe saved. | 1. Except for referrals (and ???), the Authority and Additional | sections could be omitted. Those can be omitted now if they aren't sending anything useful, and omitting them does any good. Whether the answer is to be cached or not is generally irrelevant (the SOA in an NXDOMAIN might be the one difference). | 2. TTL fields could be omitted. That would not be a good idea at all - it would mean the packet format would change in a horrible way - the saving there just isn't worth it. | Imagine the savings in packet sizes and processing costs! The server is where the processing costs are, and the cost to make the decision is likely to be more than the saving of not copying in the extra few bytes. | For instance, maybe a server could safely | assume that a requestor capable of caching answers is also capable of | performing sorting and/or ordering of answer sets, and could therefore | forego such operations itself, thus eliminating duplicated | sorting/ordering effort. Servers shouldn't be sorting answers in any case, they don't have nearly enough information to work out what a sane ordering is. Until some real benefit can be found - something which the server could really avoid doing in an answer which is not to be cached, I don't think it is worth spending much time on this. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 19:26:34 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19009 for ; Wed, 16 Feb 2000 19:26:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LEFr-000POy-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 15:53:11 -0800 Received: from dengate.it.verio.net ([129.250.33.253] helo=dengate.verio.net) by psg.com with smtp (Exim 3.12 #1) id 12LEFq-000POr-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 15:53:10 -0800 Received: from [172.16.1.121] by dengate.verio.net via smtpd (for psg.com [147.28.0.62]) with SMTP; 16 Feb 2000 22:45:17 UT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LEFw-0000nc-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 15:53:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002162350.KAA16379@bsdi.dv.isc.org> To: Mark.Andrews@nominum.com Cc: "D. J. Bernstein" , namedroppers@internic.net From: Mark.Andrews@nominum.com Subject: Re: a.dns.int In-reply-to: Your message of "Wed, 16 Feb 2000 14:10:46 +1100." Date: Thu, 17 Feb 2000 10:50:22 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Its been pointed out that I overlooked the code #ifdef YPKLUGE in ns_req.c. Dan's description is not accurate however. This code blocks domains that are syntactically identical to IPv4 addresses. Mark > > > Unfortunately, BIND already goes out of its way to return NXDOMAIN for > > numeric TLDs. This is why I'm proposing a.dns.int: it's something that > > can be made to work for everyone very easily, as soon as desired. > > Dan, please stop spreading untruths. It is obvious that you did > not attempt to even create such a zone because it you had you > would have found out that there are no impediments. > > The following test zone loads without error as zone 1 on BIND > 8.2.2-P5. > > Mark > > $TTL 3600 > @ SOA bsdi.dv.isc.org. marka.isc.org. ( > 1 3600 1200 3600000 3600 ) > NS bsdi.dv.isc.org. > 2.3.4 A 2.3.4.1 > -- > 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 -- 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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 19:44:37 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19176 for ; Wed, 16 Feb 2000 19:44:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LEY4-000Pkb-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 16:12:00 -0800 Received: from dengate.it.verio.net ([129.250.33.253] helo=dengate.verio.net) by psg.com with smtp (Exim 3.12 #1) id 12LEY4-000PkR-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 16:12:00 -0800 Received: from [172.16.1.121] by dengate.verio.net via smtpd (for psg.com [147.28.0.62]) with SMTP; 16 Feb 2000 23:04:07 UT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LEY9-0000qI-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 17:12:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38AB3BD2.35B78390@daimlerchrysler.com> Date: Wed, 16 Feb 2000 19:07:46 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <200002162323.KAA16260@bsdi.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@nominum.com wrote: > Generally caching is a good thing and just because one client > also has a cache is no reason not to cache an answer. So far > in over 10 years of working with the DNS I have only found one > example where the client requesting the cache be disabled would > be useful. > > That case was discovering the zone a domain belonged to and even > then only to disable negative caching. Mark, I don't think you quite understood my suggestion. The client wouldn't be able to disable the server's cache; it would only be capable of asking that the response to its own query be given in a slimmer, non-cacheable form. The server would still cache answers -- if that is its normal mode of operation -- regardless of the respective formats in which it answered its clients. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 23:11:59 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22981 for ; Wed, 16 Feb 2000 23:11:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LHq0-0001a8-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 19:42:44 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12LHpz-0001Zx-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 19:42:44 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LHq8-0000sE-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 20:42:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 17 Feb 2000 02:16:36 -0000 Message-ID: <20000217021636.7824.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <38AB1C9D.D9565DDC@daimlerchrysler.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My cache always omits AU and AR. BIND could do the same when RD is set. I don't see the need for a protocol extension. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 23:12:00 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22988 for ; Wed, 16 Feb 2000 23:11:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LHrJ-0001bO-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 19:44:05 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12LHrI-0001bG-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 19:44:05 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LHrR-0000sK-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 20:44:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 17 Feb 2000 02:37:20 -0000 Message-ID: <20000217023720.32312.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@internic.net Subject: Re: a.dns.int References: <200002162350.KAA16379@bsdi.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To set the record straight here: 1. As I said, the BIND cache intercepts and nixes A queries for dotted-decimal domain names, so delegating those names from the roots wouldn't make them work everywhere. This is why I'm proposing a.dns.int. 2. As Mark said, BIND will pass along other queries for numeric TLDs. But this fact has no relevance to the discussion. My proposal would create numeric TLDs consisting entirely of dotted-decimal names. 3. As Mark illustrated, one can create a local numeric TLD under BIND. But this fact has no relevance to the discussion. BIND is incapable of loading billions of records. Mark still owes me an apology. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 23:12:48 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23017 for ; Wed, 16 Feb 2000 23:12:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LHm7-0001Y3-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 19:38:43 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12LHm5-0001Xw-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 19:38:42 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LHly-0000ru-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 20:38:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002170102.MAA16637@bsdi.dv.isc.org> To: Kevin Darcy Cc: namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: To Be Cached, or Not To Be Cached, That is the Question In-reply-to: Your message of "Wed, 16 Feb 2000 19:07:46 CDT." <38AB3BD2.35B78390@daimlerchrysler.com> Date: Thu, 17 Feb 2000 12:02:35 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Mark, > I don't think you quite understood my suggestion. The client > wouldn't be able to disable the server's cache; it would only be capable of > asking that the response to its own query be given in a slimmer, > non-cacheable form. The server would still cache answers -- if that is its > normal mode of operation -- regardless of the respective formats in which it > answered its clients. We were talking at cross purposes apon re-reading. Mark -- 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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 16 23:13:49 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23032 for ; Wed, 16 Feb 2000 23:13:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LHmB-0001YB-00 for namedroppers-data@psg.com; Wed, 16 Feb 2000 19:38:47 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12LHm8-0001Y5-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 19:38:45 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LHmH-0000rw-00 for namedroppers@ops.ietf.org; Wed, 16 Feb 2000 20:38:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38AB4EE2.E13DFDA0@daimlerchrysler.com> Date: Wed, 16 Feb 2000 20:29:06 -0500 From: Kevin Darcy To: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <8129.950743774@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: Wed, 16 Feb 2000 16:54:37 -0500 > From: Kevin Darcy > Message-ID: <38AB1C9D.D9565DDC@daimlerchrysler.com> > > | Talking about OPT flags (EDNS0, EDNS1), how about one > | that means "Answer Will Not Be Cached"? > > I'm not sure the saving is worth it - it would need careful investigation > of what canbe saved. > > | 1. Except for referrals (and ???), the Authority and Additional > | sections could be omitted. > > Those can be omitted now if they aren't sending anything useful, and > omitting them does any good. Whether the answer is to be cached or not > is generally irrelevant (the SOA in an NXDOMAIN might be the one difference). Current implementations can only guess whether the requestor will find Authority or Additional information "useful" or not. Maybe the requestor doesn't need the extra data *now*, but should have it in cache for some future query. On this assumption, most server implementations understandably seem to err on the "safe" side and populate Authority and Additional sections willy-nilly. This is wasted processing and packet bloat if the client doesn't care about the data. If it is known that the answer won't be cached, the server can, I believe, assume that the requestor has a "short-attention span" and only cares about data directly relevant to the question asked or successful resolution of same, i.e. the answer itself, or a referral (or possibly the SOA for an NXDOMAIN, as you mentioned). > | 2. TTL fields could be omitted. > > That would not be a good idea at all - it would mean the packet format > would change in a horrible way - the saving there just isn't worth it. 4 octets per RR isn't worth it? It seems like some of the recent DNS protocol-enhancements have been focused on packet- or message-size limitations, and some of them call for more convoluted manipulations than a simple conditional skipping of the TTL field in the low-level RR encoding and/or decoding routines. Are we (collectively) being penny-wise and pound-foolish? The packet-space is there; it's just being squandered right now by caching-related information that's only useful some certain percentage of the time. > | Imagine the savings in packet sizes and processing costs! > > The server is where the processing costs are, and the cost to make the > decision is likely to be more than the saving of not copying in the > extra few bytes. I guess I was thinking about packet-size savings primarily and processing optimization secondarily. Having said that, though, the decision should be pretty cheap, since it requires matching only a single bit. Plus the omission of Authority and Additional sections is bound to save some processing cycles as well. And don't forget that smaller packets mean less processing -- often interrupt-level processing -- in the lower levels of the protocol stack. Overall, I see it as being a significant performance and latency win. > | For instance, maybe a server could safely > | assume that a requestor capable of caching answers is also capable of > | performing sorting and/or ordering of answer sets, and could therefore > | forego such operations itself, thus eliminating duplicated > | sorting/ordering effort. > > Servers shouldn't be sorting answers in any case, they don't have > nearly enough information to work out what a sane ordering is. Ah, you discovered my ulterior motive! That's all I'll say for now... > Until some real benefit can be found - something which the server could > really avoid doing in an answer which is not to be cached, I don't think > it is worth spending much time on this. 1. 32 TTL bits per RR2. a much higher confidence -- I hesitate to use the term "certainty" -- that the Authority and Additional sections can be safely omitted from the response. There's gold in them thar hills! I was dreading a reply more along the lines of "You can't omit Authority in X situation, because, unbeknownst to you, the client may need to do Y and/or Z, and those actions have a dependency on Authority data", which would be a significant spanner in the works. But, no offense intended, a "the savings don't seem to be worth it" type of response doesn't deter me at all from further research and experimentation. I think I have a pretty good gut feel for what performs well and what doesn't, and this mod sure feels like a performance winner to me. Would any of this impact the security extensions? Positively *or* negatively? - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 17 07:26:53 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10130 for ; Thu, 17 Feb 2000 07:26:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LPNU-0005T2-00 for namedroppers-data@psg.com; Thu, 17 Feb 2000 03:45:48 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12LPNT-0005Sw-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 03:45:47 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LPNZ-0001hQ-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 04:45:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002170552.QAA23668@bsdi.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@internic.net From: Mark.Andrews@nominum.com Subject: Re: a.dns.int In-reply-to: Your message of "17 Feb 2000 02:37:20 -0000." <20000217023720.32312.qmail@cr.yp.to> Date: Thu, 17 Feb 2000 16:52:26 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I hereby apologise for stating stating that Dan was spreading untruths about BIND going out of its way to return NXDOMAIN for numeric TLDs. BIND does block a subset of these queries. Let this put an end to this. Mark -- 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 to unsubscribe send a message to 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 Feb 17 07:38:19 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10131 for ; Thu, 17 Feb 2000 07:26:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LPNm-0005TJ-00 for namedroppers-data@psg.com; Thu, 17 Feb 2000 03:46:06 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12LPNl-0005TC-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 03:46:06 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LPNu-0001hZ-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 04:46:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002170600.RAA23707@bsdi.dv.isc.org> To: Kevin Darcy Cc: namedroppers@internic.net From: Mark.Andrews@nominum.com Subject: Re: To Be Cached, or Not To Be Cached, That is the Question In-reply-to: Your message of "Wed, 16 Feb 2000 20:29:06 CDT." <38AB4EE2.E13DFDA0@daimlerchrysler.com> Date: Thu, 17 Feb 2000 17:00:10 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I was dreading a reply more along the lines of "You can't omit Authority in X > situation, because, unbeknownst to you, the client may need to do Y and/or Z, > and those actions have a dependency on Authority data", which would be a > significant spanner in the works. But, no offense intended, a "the savings do > n't > seem to be worth it" type of response doesn't deter me at all from further > research and experimentation. I think I have a pretty good gut feel for what > performs well and what doesn't, and this mod sure feels like a performance > winner to me. > > Would any of this impact the security extensions? Positively *or* negatively? If your client needs to authenticate negative answers some of the authority section needs to be sent. Mark -- 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 to unsubscribe send a message to 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 Feb 17 20:53:06 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29008 for ; Thu, 17 Feb 2000 20:53:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Lbpn-000CpL-00 for namedroppers-data@psg.com; Thu, 17 Feb 2000 17:03:51 -0800 Received: from mg128-074.ricochet.net ([204.179.128.74] helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12Lbpk-000Coz-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 17:03:51 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Lbpo-000245-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 18:03:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38AC6F2E.4267A452@daimlerchrysler.com> Date: Thu, 17 Feb 2000 16:59:10 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <38AB1C9D.D9565DDC@daimlerchrysler.com> <20000217021636.7824.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > My cache always omits AU and AR. BIND could do the same when RD is set. Isn't that behavior a little indiscriminate? The requestor could be a caching server _selectively_ forwarding to you. In that case, you're depriving it of potentially valuable, query-saving information. Admittedly, you're optimizing for the general case (which IMHO is an improvement over BIND's behavior), but the bottom line is, without some explicit indication from the requestor, the server is limited to pure guesswork as to whether the client will be able to productively use AU, AR, or TTL. My aim is to take the guesswork out of the equation. > I don't see the need for a protocol extension. > What level of performance gains and/or packet-size-reduction would change your mind? - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 17 20:53:09 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29019 for ; Thu, 17 Feb 2000 20:53:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Lbrj-000Cqt-00 for namedroppers-data@psg.com; Thu, 17 Feb 2000 17:05:51 -0800 Received: from mg128-074.ricochet.net ([204.179.128.74] helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12Lbri-000CqT-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 17:05:50 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12Lbrm-00024D-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 18:05:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38AC7133.E02A29DE@daimlerchrysler.com> Date: Thu, 17 Feb 2000 17:07:47 -0500 From: Kevin Darcy To: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <200002170600.RAA23707@bsdi.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@nominum.com wrote: >> I was dreading a reply more along the lines of "You can't omit Authority >> in X situation, because, unbeknownst to you, the client may need to do Y >> and/or Z, and those actions have a dependency on Authority data", which >> would be a significant spanner in the works. But, no offense intended, a >> "the savings do n't seem to be worth it" type of response doesn't deter >> me at all from further research and experimentation. I think I have a >> pretty good gut feel for what performs well and what doesn't, and this >> mod sure feels like a performance winner to me. >> >> Would any of this impact the security extensions? Positively *or* >> negatively? > > If your client needs to authenticate negative answers some of the > authority section needs to be sent. Thanks, Mark: that's the kind of "gotcha" I was looking for. Pardon my ignorance -- I haven't dealt with the security extensions in any depth -- but would the server *know* that the client needed the Authority section in such a situation? - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Feb 18 01:46:09 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07337 for ; Fri, 18 Feb 2000 01:46:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LgQw-000FVG-00 for namedroppers-data@psg.com; Thu, 17 Feb 2000 21:58:30 -0800 Received: from mg131-222.ricochet.net ([204.179.131.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12LgQv-000FVA-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 21:58:30 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LgR0-0002Cc-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 22:58:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38ACCACC.9EDB8FF6@gorean.org> Date: Thu, 17 Feb 2000 20:30:04 -0800 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority To: Robert Elz CC: Kevin Darcy , namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <8129.950743774@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > > Date: Wed, 16 Feb 2000 16:54:37 -0500 > From: Kevin Darcy > Message-ID: <38AB1C9D.D9565DDC@daimlerchrysler.com> > > | Talking about OPT flags (EDNS0, EDNS1), how about one > | that means "Answer Will Not Be Cached"? > > I'm not sure the saving is worth it - it would need careful investigation > of what canbe saved. How many millions of queries per day/month/year do you have to have before saving N number of bytes per query becomes significant? Personally I'd love to save those bytes wherever possible, and would fully support an innovation like this. Doug -- "Welcome to the desert of the real." - Laurence Fishburne as Morpheus, "The Matrix" to unsubscribe send a message to 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 Feb 18 01:46:10 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07338 for ; Fri, 18 Feb 2000 01:46:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LgPc-000FUx-00 for namedroppers-data@psg.com; Thu, 17 Feb 2000 21:57:08 -0800 Received: from mg131-222.ricochet.net ([204.179.131.222] helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12LgPa-000FUp-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 21:57:07 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LgPd-0002CX-00 for namedroppers@ops.ietf.org; Thu, 17 Feb 2000 22:57:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002180328.OAA26256@bsdi.dv.isc.org> To: Kevin Darcy Cc: namedroppers@internic.net From: Mark.Andrews@nominum.com Subject: Re: To Be Cached, or Not To Be Cached, That is the Question In-reply-to: Your message of "Thu, 17 Feb 2000 17:07:47 CDT." <38AC7133.E02A29DE@daimlerchrysler.com> Date: Fri, 18 Feb 2000 14:28:27 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> If your client needs to authenticate negative answers some of the >> authority section needs to be sent. > > Thanks, Mark: that's the kind of "gotcha" I was looking for. > > Pardon my ignorance -- I haven't dealt with the security extensions in any > depth -- but would the server *know* that the client needed the Authority > section in such a situation? Yes (CD bit), but it doesn't know when it doesn't need them. See RFC 2535. -- 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 to unsubscribe send a message to 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 Feb 18 10:25:10 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25028 for ; Fri, 18 Feb 2000 10:25:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12LoLn-000KDX-00 for namedroppers-data@psg.com; Fri, 18 Feb 2000 06:25:43 -0800 Received: from mg130-111.ricochet.net ([204.179.130.111] helo=roam.psg.com) by psg.com with esmtp (Exim 3.12 #1) id 12LoLm-000KDR-00 for namedroppers@ops.ietf.org; Fri, 18 Feb 2000 06:25:43 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 12LoLp-0002kU-00 for namedroppers@ops.ietf.org; Fri, 18 Feb 2000 06:25:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Doug Barton Cc: Kevin Darcy , namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question In-Reply-To: Your message of "Thu, 17 Feb 2000 20:30:04 -0800." <38ACCACC.9EDB8FF6@gorean.org> Date: Fri, 18 Feb 2000 18:07:36 +1100 Message-Id: <6520.950857656@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 17 Feb 2000 20:30:04 -0800 From: Doug Barton Message-ID: <38ACCACC.9EDB8FF6@gorean.org> | How many millions of queries per day/month/year do you have to have before | saving N number of bytes per query becomes significant? If we really believed that saving a few bytes from DNS responses was worth mangling the packet formats, we would have optimised away (from almost all uses) the class field from RR's years ago (perhaps leave it in the question section and omit it elsewhere). The pain of having to cope with packet (and even RR) formats that aren't the same everywhere just isn't worth the gain. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 21 20:25:51 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19754 for ; Mon, 21 Feb 2000 20:25:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12N2yC-000ObQ-00 for namedroppers-data@psg.com; Mon, 21 Feb 2000 16:14:28 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12N2yC-000ObK-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 16:14:28 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12N2yB-0003yM-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 16:14:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38ADE20A.C6308FF5@daimlerchrysler.com> Date: Fri, 18 Feb 2000 19:21:30 -0500 From: Kevin Darcy To: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <6520.950857656@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: Thu, 17 Feb 2000 20:30:04 -0800 > From: Doug Barton > Message-ID: <38ACCACC.9EDB8FF6@gorean.org> > > | How many millions of queries per day/month/year do you have to have before > | saving N number of bytes per query becomes significant? > > If we really believed that saving a few bytes from DNS responses was > worth mangling the packet formats, we would have optimised away (from > almost all uses) the class field from RR's years ago (perhaps leave it > in the question section and omit it elsewhere). This isn't "years ago", it's *now*, with the address lists of large server clusters being thrown around in DNS responses, which are increasingly being re-queried via TCP because of UDP packet size limitations. The packet-size situation is bound to get even worse when SIG/NXT/A6/SRV/etc. RR's start showing up more ubiquitously in responses, not to mention multiple-answers-to-multiple-questions responses. Whatever undoubtedly exhaustive research was done years ago to determine that optimizing the class field wasn't worth any "mangling" is in serious need of review in light of the subsequent extensions and evolving usages of the protocol -- pain-versus-gain is a moving target here! And there's nothing to say that class-field omission couldn't be rolled into this protocol "weight-reduction" effort as well; thanks for bringing it up. > The pain of having to cope with packet (and even RR) formats that aren't > the same everywhere just isn't worth the gain. To get a handle on the "pain" level, I just whipped up an experimental-but-functional version of BIND 8.2.2-p5 -- just the named, nslookup and resolver library parts of the distribution -- which implements the NCF (non-cacheable format) option, as I have spec'ed it up to this point. I picked BIND 8 rather than BIND 9 because of the relative infancy of the latter plus my greater familiarity with the BIND 8 code base; however, since BIND 8 doesn't support OPT, I had to cheat a little bit and give NCF meaning to the Z bit instead. Results: changed or added lines of code (not including #ifdef's, comments, or mere indentation changes): named: 37 nslookup: 30 resolver library functions and resolv.h: 5 The named binary (Sun Sparc, with full debugging) was less than 0.7% larger than an unmodified named. So far, it doesn't look too painful to me. Of course, I realize NCF would require changes in *many* more places than just these. But experience so far is that a "if the NCF bit is set, skip the TTL field" conditional is quite trivial to code (a large percentage of the "nslookup" code changes, for instance, involved debug-output and option-setting rather than low-level response decoding). And since -- as previously pointed out in this thread -- inclusion of Authority and Additional sections in responses is often optional anyway, client applications should *already* be prepared to deal with answers missing those sections. Next week, if I have the time, I'll run some performance trials. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 21 20:46:16 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19992 for ; Mon, 21 Feb 2000 20:46:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12N3iA-000PPg-00 for namedroppers-data@psg.com; Mon, 21 Feb 2000 17:01:58 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12N3iA-000PPa-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 17:01:58 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12N3i9-0004Ii-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 17:01:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 20 Feb 2000 19:54:45 -0000 Message-ID: <20000220195445.21265.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@internic.net Subject: Re: a.dns.int References: <20000215191952.24273.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let me add some practical comments. Thousands of system administrators are _already_ using dotted-decimal domain names in MX records. My MTA, like sendmail, supports these names. My DNS cache now supports dotted-decimal domain names. This provides an immediate benefit for other MTAs. It's reasonably clear what will happen to this protocol in the future. System administrators will continue to use dotted-decimal domain names. There will be occasional failures from other MTAs running under other DNS caches; the MTA implementors and the DNS implementors will react by adding support. Eventually, no matter what DNSEXT does, dotted-decimal domain names will be a de facto standard. DNSEXT can reduce the number of failures by documenting this situation, and by delegating some TLDs to the servers that I described. The only remaining problem will be the (many) versions of BIND that destroy dotted-decimal domain names. I'm willing to add one line of code to support a.dns.int for BIND's benefit; this won't eliminate the problem but it will provide an easy workaround. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 21 21:34:03 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20461 for ; Mon, 21 Feb 2000 21:33:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12N4jB-00011c-00 for namedroppers-data@psg.com; Mon, 21 Feb 2000 18:07:05 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12N4jB-00011W-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 18:07:05 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12N4jB-0004jE-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 18:07:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@internic.net Subject: Re: a.dns.int In-Reply-To: Message from "D. J. Bernstein" dated "Mon, 21 Feb 2000 20:14:11 EST" <20000220195445.21265.qmail@cr.yp.to> References: <20000220195445.21265.qmail@cr.yp.to> <20000215191952.24273.qmail@cr.yp.to> From: Rob Austein Message-Id: <20000222012829Z23306-3955+261@thrintun.hactrn.net> Date: Mon, 21 Feb 2000 20:28:15 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Mon, 21 Feb 2000 20:14:11 -0500 From: "D. J. Bernstein" Thousands of system administrators are _already_ using dotted-decimal domain names in MX records. Interesting. Do you have evidence to support this assertion? to unsubscribe send a message to 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 Feb 21 21:34:20 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20472 for ; Mon, 21 Feb 2000 21:34:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12N4XB-0000iG-00 for namedroppers-data@psg.com; Mon, 21 Feb 2000 17:54:41 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12N4XA-0000iA-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 17:54:40 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12N4XA-0004e1-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 17:54:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 21 Feb 2000 22:46:07 -0000 Message-ID: <20000221224607.26183.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: AD+CD interoperability problems Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Queries with AD or CD violate RFC 1035. My DNS cache discards them as bogus. My DNS servers refuse them as bogus. I've now encountered a serious interoperability problem, which DNSEXT should document: the Ultrix version of BIND sends queries with AD+CD set. I'm going to have to accept these queries; should I echo AD+CD in the responses? Have any other bogus query bits been spotted? I also see that there is a serious potential interoperability problem, if DNSSEC is ever deployed: the DNSSEC documents allow clients and caches to send queries with CD set. These queries violate RFC 1035; what happens if they're rejected or discarded as bogus? Evidently the DNSSEC designers assumed, incorrectly, that all other caches and servers would respond to CD in a particular way. This DNSSEC assumption constitutes a change in the base DNS protocol, and it needs to be documented as such. This is exactly the type of careless protocol extension that I specifically asked about last month. To repeat the question, for everyone working on DNS extensions: Exactly what assumptions are you making on the behavior of non-extended servers? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 21 22:41:21 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22830 for ; Mon, 21 Feb 2000 22:41:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12N5gW-0002PC-00 for namedroppers-data@psg.com; Mon, 21 Feb 2000 19:08:24 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12N5gW-0002P6-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 19:08:24 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12N5gW-000583-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 19:08:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 21 Feb 2000 22:05:18 -0500 From: "Michael H. Warfield" To: Rob Austein Cc: namedroppers@internic.net Subject: Re: a.dns.int Message-ID: <20000221220518.B9973@alcove.wittsend.com> References: <20000220195445.21265.qmail@cr.yp.to> <20000215191952.24273.qmail@cr.yp.to> <20000222012829Z23306-3955+261@thrintun.hactrn.net> In-Reply-To: <20000222012829Z23306-3955+261@thrintun.hactrn.net>; from sra@hactrn.net on Mon, Feb 21, 2000 at 08:28:15PM -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, Feb 21, 2000 at 08:28:15PM -0500, Rob Austein wrote: > Date: Mon, 21 Feb 2000 20:14:11 -0500 > From: "D. J. Bernstein" > Thousands of system administrators are _already_ using dotted-decimal > domain names in MX records. > Interesting. Do you have evidence to support this assertion? I can support his assertion here by simply saying that I'm the technical POC for a couple hundred domains and that it is a common practice (whether or not it is one I encourage or discourage). Even if I go back and tell everyone that this is wrong and that they have to change, they're just going to come back to me and claim "well it's always worked before". As to the claim of "thousands", I can not personally atest to that. But if it's only a FEW thousand, then I may well know of a significant fraction of that few. Right or wrong, agree or disagree, that's what it be. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 21 23:19:49 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23117 for ; Mon, 21 Feb 2000 23:19:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12N6Kp-0003Kz-00 for namedroppers-data@psg.com; Mon, 21 Feb 2000 19:50:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12N6Ko-0003Kt-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 19:50:02 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12N6Ko-0005PF-00 for namedroppers@ops.ietf.org; Mon, 21 Feb 2000 19:50:02 -0800 From: Randy Bush MIME-Version: 1.0 To: namedroppers Subject: Re: a.dns.int References: <3.0.32.20000221220332.01705a94@odie.av8.com> Message-Id: Date: Mon, 21 Feb 2000 19:47:52 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i think the protocol specs are pretty clear on what is legal in the rhs of an mx rr. in almost twenty thousand zones secondaried here from all over the world, i can not find an mx rr with a dotted quad on the rhs. can we focus on real issues of substance as opposed to my server is better than yours? thanks. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 12:25:27 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15924 for ; Tue, 22 Feb 2000 12:25:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NI0z-000FdZ-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 08:18:21 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NI0y-000FdT-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 08:18:20 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NI0y-000ArM-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 08:18:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002220419.PAA11311@bsdi.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: AD+CD interoperability problems In-reply-to: Your message of "21 Feb 2000 22:46:07 -0000." <20000221224607.26183.qmail@cr.yp.to> Date: Tue, 22 Feb 2000 15:19:31 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Queries with AD or CD violate RFC 1035. My DNS cache discards them as > bogus. My DNS servers refuse them as bogus. RFC 1035 states these are reserved for future use. If you are a RFC 1035 client these bits must be zero when you send the query. If you are a RFC 1035 server these bits must be zero when you send the response. That is about all RFC 1035 says about those bits. Unfortunately RFC 1035 does not say that if you are a RFC1035 server you should ignore those bits in queries received. Then again it doesn't say you should test them either. It does say that they may be set (reserved for future use). The only assumption made for DNSSEC was that RFC1035 servers and clients would ignore these bits in queries and answers respectively. This is a valid assumption given the clients and servers at the time. It is also a valid assumption that future implementers would make themselves aware of protocol extentions that have been published. > > I've now encountered a serious interoperability problem, which DNSEXT > should document: the Ultrix version of BIND sends queries with AD+CD > set. I'm going to have to accept these queries; should I echo AD+CD in > the responses? Have any other bogus query bits been spotted? If you are a RFC 1035 server those bits are zero in your response. > > I also see that there is a serious potential interoperability problem, > if DNSSEC is ever deployed: the DNSSEC documents allow clients and > caches to send queries with CD set. These queries violate RFC 1035; what > happens if they're rejected or discarded as bogus? They don't violate RFC 1035 as they are reserved for future use. A client should expect that they may be set in a response. > > Evidently the DNSSEC designers assumed, incorrectly, that all other > caches and servers would respond to CD in a particular way. This DNSSEC > assumption constitutes a change in the base DNS protocol, and it needs > to be documented as such. > > This is exactly the type of careless protocol extension that I > specifically asked about last month. To repeat the question, for > everyone working on DNS extensions: Exactly what assumptions are you > making on the behavior of non-extended servers? > > ---Dan Mark -- 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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 12:25:32 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15929 for ; Tue, 22 Feb 2000 12:25:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NIE7-000Fpm-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 08:31:55 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NIE7-000Fpg-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 08:31:55 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NIE6-000Aws-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 08:31:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 21 Feb 2000 23:44:00 -0500 From: "Michael H. Warfield" To: Randy Bush Cc: namedroppers Subject: Re: a.dns.int Message-ID: <20000221234400.A13136@alcove.wittsend.com> References: <3.0.32.20000221220332.01705a94@odie.av8.com> In-Reply-To: ; from randy@psg.com on Mon, Feb 21, 2000 at 07:47:52PM -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, Feb 21, 2000 at 07:47:52PM -0800, Randy Bush wrote: > i think the protocol specs are pretty clear on what is legal in the rhs of > an mx rr. Matter of interpretation. Unfortunately, not always OUR interpretation. Many people (and, contrary to popular belief, admins do qualify as people) think that because dotted quads can be used in URL's and ftp addresses that they qualify as "host specifiers". That means (in their minds) that they feel that they can use them wherever they see a requirment for a host specifier. That means, to them, MX records. > in almost twenty thousand zones secondaried here from all over the world, > i can not find an mx rr with a dotted quad on the rhs. Ok... Couple that I've got (zone files not under my immediate control)... dotplanet.com tewna.com wht.net wma-online.com Tip of the iceberg (just primary zone files at my DNS server). Ok... So that's only a couple of percent of what my servers deal with. I could dig deeper at a couple of other sites that I don't host the primary zone file for... > can we focus on real issues of substance as opposed to my server is better > than yours? thanks. Who gives a rats $#@$#@ about whose server is better than whose server. It's out there and it's gonna happen. Not better, not worse. Fact of life. Deal. > randy Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 12:29:27 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16026 for ; Tue, 22 Feb 2000 12:29:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NILj-000Fy5-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 08:39:47 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NILi-000Fxz-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 08:39:47 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NILi-000B0N-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 08:39:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: namedroppers@internic.net Subject: Re: a.dns.int In-Reply-To: Your message of "20 Feb 2000 19:54:45 -0000." <20000220195445.21265.qmail@cr.yp.to> Date: Tue, 22 Feb 2000 16:40:06 +1100 Message-Id: <526.951198006@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: 20 Feb 2000 19:54:45 -0000 From: "D. J. Bernstein" Message-ID: <20000220195445.21265.qmail@cr.yp.to> | Thousands of system administrators are _already_ using dotted-decimal | domain names in MX records. My MTA, like sendmail, supports these names. Your MTA might, sendmail does not. It happens that on many systems the way sendmail is written dotted quads happen to work - but that's purely coincidence. Sendmail uses gethostbyname() to translate the domain name part of the RDATA of an MX record (the MX target) from a name to an IP address. But gethostbyname() is also used by applications like telnet, ftp, ... for the same purpose. It is very common for those applications to expect to work given a dotted quad instead of a domain name - they're documented to do that. But the coding is often, shall we say, sub-optimal, and attempted the DNS translation first, then would try treating the supplied string as a dotted quad only if that failed. While that is really the most general way, in that it allows domain names that are syntatically identical to a dotted quad, it put rather a burden on the root servers, with many queries that were never going to succeed, and at a time when negative caching was barely used. So, gethostbyname() was altered to look for dotted quads, and simply return the equivalent IP address, and avoid DNS lookups altogether. This came long after sendmail started using it - and if gethostnyname() were changed back to the way it used to be, this practice of sticking dotted quads in MX records would fail miserably, with no changes to sendmail at all. What sendmail does allow, believe it or not, is an MX record with [a.b.c.d] as its valie (dotted quad in brackets) - that's also not really aimed at working for the value in an MX record, but is a by-product of code to handle mail to user@[a.b.c.d] (literal address). While I guess one could rely upon that, I have never seen anyone, ever, write an MX record value that way. And we have been through this before. | It's reasonably clear what will happen to this protocol in the future. | System administrators will continue to use dotted-decimal domain names. You are dreaming. There are just three reasons anyone would do such a thing. One is simple ignorance. The next is some perceived performance improvement in not having to translate the domain name to an address. And third, some bizarre desire to be perverse. Because of the way BIND (as you said) treats straight dotted quads as illegal domain names, nothing that can be done in any reasonable timeframe is going to help any of those groups. The need to add ".a.dns.int." (or any other suffix) will kill all the first group - if they were to know than a simple IP address wouldn't work as is, then they'd just use a more normal domain name instead. Then, if there's to be (most hosts) still using the DNS to translate the dotted quad as a domain name (with the "a.dns.int" or even without it), any possible performance benefit is lost - the only people who could possibly win are those who know the lookups will be done using a server which knows not to actually send queries - of which there are less than a negligible number deployed. In practice it will be a performance loss, as essentially no servers are going to be synthesising a.b.c.d. IN A a.b.c.d RR's for the additional section meaning that an extra DNS lookup to do that translation would be needed (except where something short circuits that - and nothing will with .a.dns.int. appended). For the last group, I simply don't care. In practice, essentially everyone I see attempting to do this (and yes, there are some, though not many) are in the first group, and as soon as it is explained to them the way they're supposed to use MX records, they do it as defined, then, and forever after. When they get it wrong, they also usually leave out the trailing "." in the MX target value, and get a.b.c.d.$ORIGIN anyway, which isn't going to work in any of these schemes. kre ps: the practice of using gethostbyname() for MX target lookups is also what makes mail sometimes fail (bounce) when DNS lookups suffer an outage (server unavailable, etc). There are still sites around that use NIS server provided DNS lookups, and who have gethostbyname() do a lookup in the NIS database. NIS (last time I looked anyway) had no way to signal "temporary failure" - only "here is the address" or "no such name". When the NIS server was unable to translate the name to an address, the protocol could only say "no such name", which causes the mail to bounce. And yes, I have actually seen the effects of this. Broken without a doubt, but it does happen. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 12:49:26 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16644 for ; Tue, 22 Feb 2000 12:49:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NIpH-000GXV-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 09:10:19 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NIpG-000GXP-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 09:10:18 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NIpG-000BFp-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 09:10:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kevin Darcy cc: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question In-reply-to: Your message of "Fri, 18 Feb 2000 19:21:30 EST." <38ADE20A.C6308FF5@daimlerchrysler.com> Date: Tue, 22 Feb 2000 09:43:27 +0000 Message-ID: <14219.951212607@gromit.rfc1035.com> From: Jim Reid Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Kevin" == Kevin Darcy writes: Kevin> This isn't "years ago", it's *now*, with the address lists Kevin> of large server clusters being thrown around in DNS Kevin> responses, which are increasingly being re-queried via TCP Kevin> because of UDP packet size limitations. The packet-size Kevin> situation is bound to get even worse when SIG/NXT/A6/SRV/etc. Kevin> RR's start showing up more ubiquitously in responses Indeed. And that's what is solved by EDNS0. It gives us bigger DNS payloads without breaking anything in the current installed base. And saving a few bytes in a DNS packet is moot when you consider how big the typical SIG record is. >> The pain of having to cope with packet (and even RR) formats >> that aren't the same everywhere just isn't worth the gain. Kevin> To get a handle on the "pain" level, I just whipped up an Kevin> experimental-but-functional version of BIND 8.2.2-p5 -- Kevin> just the named, nslookup and resolver library parts of the Kevin> distribution I believe you miss the point. It's not an issue about how quick someone can hack code or even how many lines in BIND have to be changed. The issue is interoperability. One part of that is testing and deploying this change. Just look at the number of installations that are still running BIND4, or the number of vendors who still ship BIND4 with their OS. [And remember BIND isn't the only DNS implementation out there.] An even bigger issue will be preserving compatibility with the millions of resolvers and name servers that are currently in use and expect/demand that DNS packets are in the current format. They will choke badly if the explicit class and TTL fields go away as you (seem to) propose. And you've *no hope* of ever getting all of that installed base upgraded. Personally, I think micro-optimising the size of DNS packets is a waste of time and effort. Why is anyone worrying about a few bytes in a DNS packet when there are petabytes of unmitigated junk - spam, netnews, www, streaming audio/video, etc. - crossing the Internet every day? What fraction of the Internet's traffic is DNS these days anyway, 2-3%? Would shaving a few bytes from every DNS packet make the world a better place? Will the typical dialup or T1 user even see a difference? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 12:51:19 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16707 for ; Tue, 22 Feb 2000 12:51:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NIjq-000GQ1-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 09:04:42 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NIjp-000GPv-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 09:04:41 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NIjp-000BCs-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 09:04:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.2.0.58.20000222094532.01be2ed0@dokka.maxware.no> Date: Tue, 22 Feb 2000 09:49:13 +0100 To: "D. J. Bernstein" , namedroppers@internic.net From: Harald Tveit Alvestrand Subject: Re: a.dns.int In-Reply-To: <20000220195445.21265.qmail@cr.yp.to> References: <20000215191952.24273.qmail@cr.yp.to> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 19:54 20.02.00 +0000, D. J. Bernstein wrote: >Let me add some practical comments. > >Thousands of system administrators are _already_ using dotted-decimal >domain names in MX records. My MTA, like sendmail, supports these names. > >My DNS cache now supports dotted-decimal domain names. This provides an >immediate benefit for other MTAs. > >It's reasonably clear what will happen to this protocol in the future. >System administrators will continue to use dotted-decimal domain names. >There will be occasional failures from other MTAs running under other >DNS caches; the MTA implementors and the DNS implementors will react by >adding support. Eventually, no matter what DNSEXT does, dotted-decimal >domain names will be a de facto standard. Dan Bernstein made this argument in DRUMS some years ago, and found little to no support from other mail developers there. That doesn't mean he cannot be right, it just means that he's proposed dotted-decimal MX targets before, and did not get agreement from other mail developers. >DNSEXT can reduce the number of failures by documenting this situation, >and by delegating some TLDs to the servers that I described. I think the Right Thing in this situation (where Bernstein argues for a point of view not shared with many others) is for Bernstein to delegate this as a subdomain under cr.yp.to or other domains that he controls, and publish his grant of this domain name to the community in a suitable format (such as an info RFC). There is no magic associated with a.dns.int. Harald A -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 12:55:43 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16811 for ; Tue, 22 Feb 2000 12:55:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NIuV-000Ge1-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 09:15:43 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NIuU-000Gdu-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 09:15:42 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NIuU-000BHp-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 09:15:42 -0800 Message-Id: <200002221137.GAA08628@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idn@ops.ietf.org, namedroppers@internic.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idn-requirment-00.txt Date: Tue, 22 Feb 2000 06:37:43 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internationalized Domain Name Working Group of the IETF. Title : Requirements of Internationalized Domain Names Author(s) : J. Seng Filename : draft-ietf-idn-requirment-00.txt Pages : 7 Date : 21-Feb-00 This document describes the requirement for encoding international characters into DNS names and records. This document is guidance for developing protocols for internationalized domain names. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-requirment-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idn-requirment-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idn-requirment-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000221101207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idn-requirment-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idn-requirment-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000221101207.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 13:37:29 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18228 for ; Tue, 22 Feb 2000 13:37:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NJWn-000Hdq-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 09:55:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NJWn-000Hdi-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 09:55:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NJWn-000BZQ-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 09:55:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002221636.LAA25356@torque.pothole.com> To: namedroppers@ops.ietf.org Subject: Re: AD+CD interoperability problems In-reply-to: Your message of "21 Feb 2000 22:46:07 GMT." <20000221224607.26183.qmail@cr.yp.to> Date: Tue, 22 Feb 2000 11:36:20 -0500 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "D. J. Bernstein" Date: 21 Feb 2000 22:46:07 -0000 Message-ID: <20000221224607.26183.qmail@cr.yp.to> To: namedroppers@ops.ietf.org >Queries with AD or CD violate RFC 1035. My DNS cache discards them as >bogus. My DNS servers refuse them as bogus. RFC 1035 was updated in this regard years ago by RFC 2065. >I've now encountered a serious interoperability problem, which DNSEXT >should document: the Ultrix version of BIND sends queries with AD+CD >set. I'm going to have to accept these queries; should I echo AD+CD in >the responses? Have any other bogus query bits been spotted? A query with the AD bit on does not conform to either RFC 1035 or to RFC 2065/2535 (DNSSEC). You should clear the AD bit in a response unless you have cryptographically autenticated the response according to DNSSEC and thus it would contain Authenticated Data. If you are not implementing DNSSEC, you should ignore the CD bit in requests and it is immaterial whether it is on in responses or not. >I also see that there is a serious potential interoperability problem, >if DNSSEC is ever deployed: the DNSSEC documents allow clients and >caches to send queries with CD set. These queries violate RFC 1035; what >happens if they're rejected or discarded as bogus? Its not just "allow". Under some circumstances, DNSSEC strongly encourages turning on CD in queries. I assume your question above is rhetorical. >Evidently the DNSSEC designers assumed, incorrectly, that all other >caches and servers would respond to CD in a particular way. This DNSSEC >assumption constitutes a change in the base DNS protocol, and it needs >to be documented as such. DNSSEC assumes that security ignorant DNS servers will ignore the CD bit. This is entirely consistent with the general principle of Internet architecture of being liberal in what you accept (RFC 1958, section 3.9) although I will grant that that principle has not always been applied in the DNS world. This change is certainly documented in RFC 2065 issued in Janaury 1997, over two years ago, and in its successor RFC 2535, both of which are properly labeled as updating RFC 1035. Furthermore, RFC 1035 does not label its Z bits as being zero for all eternity but as reserved for future use, use which would seem to me to require that they sometimes not be zero. And RFCs 2065 and 2535 clearly state that are allocating two previously unused bits out of the DNS header. Donald >This is exactly the type of careless protocol extension that I >specifically asked about last month. To repeat the question, for >everyone working on DNS extensions: Exactly what assumptions are you >making on the behavior of non-extended servers? > >---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 14:08:21 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19164 for ; Tue, 22 Feb 2000 14:08:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NJuD-000IBG-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 10:19:29 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NJuD-000IBA-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 10:19:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NJuD-000Bki-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 10:19:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38B2CEA4.12F6AF6B@whistle.com> Date: Tue, 22 Feb 2000 10:00:04 -0800 From: Terry Lambert To: Robert Elz CC: namedroppers@internic.net Subject: Re: a.dns.int References: <526.951198006@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > > What sendmail does allow, believe it or not, is an MX > record with [a.b.c.d] as its valie (dotted quad in brackets) > - that's also not really aimed at working for the value in > an MX record, but is a by-product of code to handle mail to > user@[a.b.c.d] (literal address). While I guess one could > rely upon that, I have never seen anyone, ever, write an > MX record value that way. This is actually not quite correct. Sendmail doesn't allow bracketed dotted quads in an MX record. The use of brackets is a signal to sendmail to not attempt an MX lookup of the item in brackets. In practice, this means that you can specify bracketed machine names in things like the ``mailertable'' file right hand side argument (local configuration data), and no lookup will occur, but _not_ in MX records. For non-bracketed dotted quads, the hacked version of gethostbyname() in common use will eventually call inet_pton() on a completely numeric value. You _can_ override this behaviour, even for a completely numeric value, by placing an additional dot at the end, in which case it _will_ do a DNS lookup on the numeric value. As you point out, this is a terrible practice, in that it unreasonably loads the root servers with things that can never really be resolved, since there do not exist delegations at the root for numerics not in reverse format in the in-addr.arpa zone. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 14:08:54 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19185 for ; Tue, 22 Feb 2000 14:08:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NJyu-000IHF-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 10:24:20 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NJyt-000IH9-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 10:24:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NJyt-000BnD-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 10:24:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Michael H. Warfield" cc: Randy Bush , namedroppers Subject: Re: a.dns.int In-reply-to: Your message of "Mon, 21 Feb 2000 23:44:00 EST." <20000221234400.A13136@alcove.wittsend.com> Date: Tue, 22 Feb 2000 18:23:05 +0000 Message-ID: <14811.951243785@gromit.rfc1035.com> From: Jim Reid Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Michael" == Michael H Warfield writes: >> i think the protocol specs are pretty clear on what is legal in >> the rhs of an mx rr. Michael> Matter of interpretation. Unfortunately, not always Michael> OUR interpretation. Many people (and, contrary to Michael> popular belief, admins do qualify as people) think that Michael> because dotted quads can be used in URL's and ftp Michael> addresses that they qualify as "host specifiers". That Michael> means (in their minds) that they feel that they can use Michael> them wherever they see a requirment for a host specifier. Michael> That means, to them, MX records. Well, these people are simply wrong. RFC1034 is crystal-clear on this. I quote: MX a 16 bit preference value (lower is better) followed by a host name willing to act as a mail exchange for the owner domain. Dotted quads are not host names, as RFC1123 makes clear. Now if people choose to misinterpret something as fundamental as the mandatory Host Requirements RFC, then that's their problem. Just because someone believes Elvis is alive doesn't make that belief true. And if you think these RFCs are ambiguous or lack clarity, I'm sure the IETF would be delighted if you suggested an improved wording. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 15:45:49 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22482 for ; Tue, 22 Feb 2000 15:45:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NLLc-000Jwf-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 11:51:52 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NLLc-000JwZ-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 11:51:52 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NLLc-000CEd-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 11:51:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 22 Feb 2000 19:27:03 -0000 Message-ID: <20000222192703.28382.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: AD+CD interoperability problems References: <20000221224607.26183.qmail@cr.yp.to> <200002220419.PAA11311@bsdi.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The ``reserved means ignore'' argument is bogus. Packets that contain opcode 14, rcode 11, or label 01 are normally discarded or rejected, even though all of these numbers are marked as ``reserved'' in RFC 1035. If a widespread client happens to ignore bogus rcodes by treating them as rcode 0, and an extension assumes that all un-extended clients will work this way, then that's a change to the un-extended protocol, and it needs to be documented as such. Mark.Andrews@nominum.com writes: > It does say that they may be set No. It says that they must not be set. ``Must be zero in all queries.'' These AD+CD queries blatantly violate this requirement. I'm not objecting generally to changes in the protocol. But I am objecting to inadequately documented transition plans: in particular, mandatory changes that are hidden inside ``optional'' extension specs. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 17:55:42 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26613 for ; Tue, 22 Feb 2000 17:55:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NNbu-000MOf-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 14:16:50 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NNbt-000MOX-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 14:16:49 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NNbs-000D1h-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 14:16:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 22 Feb 2000 20:11:11 -0000 Message-ID: <20000222201111.2486.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@internic.net Subject: Re: a.dns.int References: <20000215191952.24273.qmail@cr.yp.to> <20000220195445.21265.qmail@cr.yp.to> <4.2.0.58.20000222094532.01be2ed0@dokka.maxware.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand writes: > Dan Bernstein made this argument in DRUMS some years ago, and found little > to no support from other mail developers there. False. Most MTAs _already_ permitted IP addresses in MX records. Two exceptions came to light in that discussion. At least one of them (vmailer) was subsequently changed to permit IP addresses in MX records, for precisely the reasons I've explained. One virtue of making this change in the DNS protocol is that there are relatively few DNS cache installations, using a relatively small variety of implementations. In the short term, many interoperability failures will be prevented; in the long term, perhaps MTA implementors will eventually be able to stop worrying about the problem. Another virtue of making this change in the DNS protocol is that it will automatically apply to other applications, such as applications using SRV records, with no extra effort. > delegate this as a subdomain under cr.yp.to You don't mind if software starts assigning special meanings to domains that could be transferred to other people later? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 18:03: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 SAA26856 for ; Tue, 22 Feb 2000 18:02:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NNsG-000Mj9-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 14:33:44 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NNsG-000Mj2-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 14:33:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NNsG-000DBH-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 14:33:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002222059.OAA29102@gungnir.fnal.gov> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: AD+CD interoperability problems In-reply-to: Your message of Tue, 22 Feb 2000 19:27:03 GMT. <20000222192703.28382.qmail@cr.yp.to> Date: Tue, 22 Feb 2000 14:59:05 -0600 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The ``reserved means ignore'' argument is bogus. No it isn't. But like any statement, it could be subjected to a reductio ad absurdam lampooning. If it's more important to win an argument than to be correct, feel free. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 19:06:54 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27951 for ; Tue, 22 Feb 2000 19:06:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NOnY-000Nqh-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 15:32:56 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NOnY-000Nqb-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 15:32:56 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NOnX-000DcU-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 15:32:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 22 Feb 2000 23:12:39 -0000 Message-ID: <20000222231239.25835.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: a.dns.int References: <20000220195445.21265.qmail@cr.yp.to> <20000215191952.24273.qmail@cr.yp.to> <20000222012829Z23306-3955+261@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein writes: > Do you have evidence to support this assertion? Peter Koch reported in 1998 that there were 223 *.de dotted-decimal MX records. If you try MX lookups on several thousand second-level domains obtained from PTR lookups on random IP addresses---note that this is biased towards large sites---you'll see some dotted-decimal MX records. If there's any serious dispute about the accuracy of my estimate, we can get the .com database from NSI and try a random sample of (say) 100000 domains. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 19:16:41 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28017 for ; Tue, 22 Feb 2000 19:16:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NP2B-000O7g-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 15:48:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NP2B-000O7W-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 15:48:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NP2B-000DjR-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 15:48:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Bill Manning Message-Id: <200002222344.PAA01016@zed.isi.edu> Subject: Re: a.dns.int To: djb@cr.yp.to (D. J. Bernstein) Date: Tue, 22 Feb 2000 15:44:37 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <20000222231239.25835.qmail@cr.yp.to> from "D. J. Bernstein" at Feb 22, 2000 11:12:39 PM Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % % Rob Austein writes: % > Do you have evidence to support this assertion? % % Peter Koch reported in 1998 that there were 223 *.de dotted-decimal MX % records. If you try MX lookups on several thousand second-level domains % obtained from PTR lookups on random IP addresses---note that this is % biased towards large sites---you'll see some dotted-decimal MX records. % % If there's any serious dispute about the accuracy of my estimate, we can % get the .com database from NSI and try a random sample of (say) 100000 % domains. % % ---Dan I, for one, would appreciate it if you would take this on and publish the results. Preferably that can be independently verified. Can you do this in the next few weeks? --bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 19:19:51 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28028 for ; Tue, 22 Feb 2000 19:19:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NP1X-000O7K-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 15:47:23 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NP1X-000O7E-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 15:47:23 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NP1X-000Dj7-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 15:47:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "D. J. Bernstein" Cc: namedroppers@internic.net Subject: Re: a.dns.int References: <20000215191952.24273.qmail@cr.yp.to> <20000220195445.21265.qmail@cr.yp.to> <4.2.0.58.20000222094532.01be2ed0@dokka.maxware.no> <20000222201111.2486.qmail@cr.yp.to> Message-Id: Date: Tue, 22 Feb 2000 15:34:53 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit as we have real work to do in preparation for adelaide, this digression and pissing contest will have to move off this list at the end of today. randy namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 21:54:51 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00485 for ; Tue, 22 Feb 2000 21:54:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NR5K-0000hz-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 17:59:26 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NR5K-0000ht-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 17:59:26 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NR5J-000EXg-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 17:59:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19398D273324D3118A2B0008C7E9A56909881E5D@SIT.platinum.corp.microsoft.com> From: James Gilroy To: namedroppers@internic.net Subject: RCODEs in EDNS Date: Tue, 22 Feb 2000 17:51:12 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One issue that i've always found annoying, that i'd like to see cleaned up in EDNS is the overloading of the NO_ERROR RCODE in queries. Currently NO_ERROR can mean -- have an answer -- empty auth response (name exists, RR set doesn't) -- referral To correctly distinguish the later two response from some BIND implementations, involves testing a bunch of bits or further parsing the packet. (It was never clear to me why empty auth response didn't have an RCODE to begin with as name error did.) I think it would be a useful service -- primarily to implementors, but also to anyone diagnosing problems, looking at traces, etc. -- to clean this up now. I'd propose using NXRRSET -> empty auth response (that's exactly what it means in the update case) NOTAUTH -> referral (sorta captures the idea) The idea would be that EDNS aware implementations would just tack these onto the revelant case statements in their packet parsers and do whatever processing they now do when they detect these conditions by the appropriate set of tests. jim to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 22 23:21:40 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02058 for ; Tue, 22 Feb 2000 23:21:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NSZz-0002bS-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 19:35:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NSZz-0002bM-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 19:35:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NSZz-000F7o-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 19:35:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002230332.OAA14090@bsdi.dv.isc.org> To: James Gilroy Cc: namedroppers@internic.net From: Mark.Andrews@nominum.com Subject: Re: RCODEs in EDNS In-reply-to: Your message of "Tue, 22 Feb 2000 17:51:12 -0800." <19398D273324D3118A2B0008C7E9A56909881E5D@SIT.platinum.corp.microsoft.com> Date: Wed, 23 Feb 2000 14:32:23 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit What's the point in doing it? Servers and clients are still going to have to do it the old way when talking to old client and servers so the code to do this has to exist. In general having only one way to do something leads to less errors. Mark > One issue that i've always found annoying, that i'd like to see cleaned up > in EDNS is the overloading of the NO_ERROR RCODE in queries. > > Currently NO_ERROR can mean > -- have an answer > -- empty auth response (name exists, RR set doesn't) > -- referral > > To correctly distinguish the later two response from some BIND > implementations, involves testing a bunch of bits or further parsing the > packet. (It was never clear to me why empty auth response didn't have an > RCODE to begin with as name error did.) > > I think it would be a useful service -- primarily to implementors, but also > to anyone diagnosing problems, looking at traces, etc. -- to clean this up > now. > > I'd propose using > NXRRSET -> empty auth response (that's exactly what it means in the > update case) > NOTAUTH -> referral (sorta captures the idea) > > The idea would be that EDNS aware implementations would just tack these onto > the revelant case statements in their packet parsers and do whatever > processing they now do when they detect these conditions by the appropriate > set of tests. > > jim > > > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 23 00:24:13 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02855 for ; Wed, 23 Feb 2000 00:24:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NTSs-0003jk-00 for namedroppers-data@psg.com; Tue, 22 Feb 2000 20:31:54 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NTSs-0003je-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 20:31:54 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NTSr-000FV8-00 for namedroppers@ops.ietf.org; Tue, 22 Feb 2000 20:31:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38B360E7.7297740D@daimlerchrysler.com> Date: Tue, 22 Feb 2000 23:24:07 -0500 From: Kevin Darcy To: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <14219.951212607@gromit.rfc1035.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Reid wrote: > >>>>> "Kevin" == Kevin Darcy writes: > > Kevin> This isn't "years ago", it's *now*, with the address lists > Kevin> of large server clusters being thrown around in DNS > Kevin> responses, which are increasingly being re-queried via TCP > Kevin> because of UDP packet size limitations. The packet-size > Kevin> situation is bound to get even worse when SIG/NXT/A6/SRV/etc. > Kevin> RR's start showing up more ubiquitously in responses > > Indeed. And that's what is solved by EDNS0. With all due respect to the creators of EDNS0, I wouldn't say that the UDP-payload-size field -- assuming that's what you are referring to -- "solves" the problem of protocol bloat. It's more of an accommodation than a solution. It allows bigger UDP transactions between capable nodes and helps avoid some of the UDP-truncated-retry-via-TCP waste and delays, but doesn't get to the root cause of why the query was so large that it didn't fit into the default-payload UDP packet in the first place. In other words, payload-size-reporting increases "supply" of network (and to a lesser extent, processing) resources, whereas an NCF (non-cacheable format) option reduces "demand" on those resources. It's kind of like the recurring political question: prevent crime or build more jails? NCF is prevention; payload-size-reporting builds a bigger hoosegow. > It gives us bigger DNSpayloads without breaking anything in the current > installed base. As a client-originated EDNS *option*, NCF wouldn't break anything in the installed base unless and until the low-level resolver API default was changed, which wouldn't happen until the option was widely tested and accepted. See below. > And > saving a few bytes in a DNS packet is moot when you consider how big > the typical SIG record is. I still profess relative ignorance of the security extensions. How big is the "typical" SIG record? > >> The pain of having to cope with packet (and even RR) formats > >> that aren't the same everywhere just isn't worth the gain. > > Kevin> To get a handle on the "pain" level, I just whipped up an > Kevin> experimental-but-functional version of BIND 8.2.2-p5 -- > Kevin> just the named, nslookup and resolver library parts of the > Kevin> distribution > > I believe you miss the point. It's not an issue about how quick > someone can hack code or even how many lines in BIND have to be > changed. The issue is interoperability. One part of that is testing > and deploying this change. Just look at the number of installations > that are still running BIND4, or the number of vendors who still ship > BIND4 with their OS. [And remember BIND isn't the only DNS > implementation out there.] An even bigger issue will be preserving > compatibility with the millions of resolvers and name servers that are > currently in use and expect/demand that DNS packets are in the current > format. They will choke badly if the explicit class and TTL fields go > away as you (seem to) propose. And you've *no hope* of ever getting > all of that installed base upgraded. As mentioned above, NCF would be a client-originating option in the EDNS framework. If the resolver doesn't grok NCF, then it doesn't set the NCF flag and doesn't receive NCF responses. The *servers* have to change, granted, but only conditional on a certain EDNS{X} (where {X} is > 1) conformance level. If the server doesn't grok EDNS{X}, the client will discover this quickly and know to not set the NCF flag, in which case they will get "classic", obese responses as always. Now, in my original message I made reference to a "big switch" where the low-level resolver API default would change from NCF=off to NCF=on. At this point, any application using a low-level resolver API would have to either a) know how to decode TTL-less responses (typically 1 line of code), or b) explicitly tell the API to turn off the NCF flag on the query to get fat responses, either directly (if the API supports it) or by specifying a lower EDNS conformance level that doesn't include NCF functionality (again, the API would need to co-operate by supporting conformance-level-setting). Admittedly, either option requires application code changes. But how many applications actually grovel through DNS packets as opposed to just calling the gethostby*() routines? sendmail comes to mind. Others? Maybe a few sniffer programs and other troubleshooting tools. With a little advance notice, co-ordination and some careful #ifdef'ing, the "big switch" wouldn't necessarily have to require huge code changes or loss of application portability. (Originally I thought application code changes would also be necessary because of the omission of the Authority and Additional sections, but as a result of enlightenment from the feedback on this list, plus re-review of RFC 1035, it is now obvious to me that any RFC-conforming application must *already* be prepared to deal with missing Authority and/or Additional sections in response to its recursive queries). > Personally, I think micro-optimising the size of DNS packets is a > waste of time and effort. Why is anyone worrying about a few bytes in > a DNS packet when there are petabytes of unmitigated junk - spam, > netnews, www, streaming audio/video, etc. - crossing the Internet > every day? What fraction of the Internet's traffic is DNS these days > anyway, 2-3%? Would shaving a few bytes from every DNS packet make the > world a better place? Will the typical dialup or T1 user even see a > difference? I'm thinking more of the large organizations and ISP's who are installing DNS server farms to handle the query load, or those unfortunate non-US users who are still paying per-byte charges to monopolistic or pseudo-monopolistic telco's, rather than the typical dialup or T1 user on a free-market, open network. Don't you think they would appreciate *every* reasonable effort to curb protocol bloat? Will it make the world a better place? As long as the gain exceeds the pain, most certainly, though probably not in any dramatic or spectacular way. Every bit helps (well, maybe not every *bit*, due to padding, but 4 octets per RR does :-) Your points about spam, netnews, streaming protocols, etc. are well taken, but why exacerbate the problem? Moreover, the argument can at least be made that the users of the netnews/www/streaming-whatever are deriving heightened perceived value from the additional bandwidth they are consuming and thus volunteering to pay for the necessary infrastructure. In the case of DNS protocol bloat, which is not known by the vast majority of users, that argument is much weaker. In fact, because of the "invisibility" of DNS -- the unseen costs of the transactions -- I think in many ways we (those who have a working if not perfect understanding of the protocol) have a sort of quasi-custodial duty to curb the bloat as much as possible on the users' behalf: since they don't know what's being consumed, we don't have their "permission" to consume any more than is necessary. Your point above about the size of SIG records -- assuming that they are large -- is quite a propos: a large part of the reason why I'm bringing up protocol weight-reduction *now* is because I can foresee that the capacity requirements of the upcoming new extensions are likely to cause problems. If we (speaking collectively again) can selectively and interoperably remove some of the old protocol baggage at the same time we add new features, then maybe the capacity problems will be mostly averted. Not to sound alarmist, but if DNS consumption is left to grow without bounds, what is not a problem today could easily become one tomorrow. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 23 05:10:49 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17544 for ; Wed, 23 Feb 2000 05:10:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12NYBf-00096T-00 for namedroppers-data@psg.com; Wed, 23 Feb 2000 01:34:27 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12NYBe-00096M-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 01:34:26 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12NYBe-000HcB-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 01:34:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200002230716.SAA14366@bsdi.dv.isc.org> To: Kevin Darcy Cc: namedroppers@internic.net From: Mark.Andrews@nominum.com Subject: Re: To Be Cached, or Not To Be Cached, That is the Question In-reply-to: Your message of "Tue, 22 Feb 2000 23:24:07 CDT." <38B360E7.7297740D@daimlerchrysler.com> Date: Wed, 23 Feb 2000 18:16:27 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin, this optimisation would really only come into play between stub resolvers and their servers. This is normally a LAN connection or a couple of hops to the ISP's nameserver. It will not (normally) result in savings on international links as most of those queries are coming from servers which do cache the results and do need those additional RRsets. I would suggest that you consider what Dan said and use RD as a flag bit, not worry about the ttl and just trim the RRsets that are not required to answer the question. Patches welcome. Mark -- 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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 23 11:45: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 LAA25866 for ; Wed, 23 Feb 2000 11:45:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Ne5k-000F8I-00 for namedroppers-data@psg.com; Wed, 23 Feb 2000 07:52:44 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Ne5k-000F8C-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 07:52:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Ne5k-000Kih-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 07:52:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000323002330.00a486d0@mail.gw.tislabs.com> Date: Thu, 23 Mar 2000 00:31:13 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WG Last call: Signing Authority Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This document was spun off from the Simple Secure Update document after WGLC. This document specifies that for DNSSEC purposes only zone key signatures are material. This restriction simplifies signature validation, and allows flexible dynamic update policies. The changes result from implementation experience. This is a WG last call ending March 8'th 2000. The draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-signing-auth-00.txt There are no known defects in this version of the document. Please send comments to the list. This document is to be published as an standards track RFC, updating RFC2565. 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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 23 11:52:23 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26072 for ; Wed, 23 Feb 2000 11:52:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Ne5y-000F8f-00 for namedroppers-data@psg.com; Wed, 23 Feb 2000 07:52:58 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Ne5x-000F8X-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 07:52:57 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Ne5x-000Kim-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 07:52:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000223001306.00970ae0@mail.gw.tislabs.com> Date: Thu, 23 Mar 2000 00:31:06 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WG Last Call: Simple Secure Update Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a second last call on this document, in the first round some changes where suggested mainly spilt the document in two as the original document was updating RFC2535 and obsoleting RFC2137 this document reflects all comments received. This document specifies how to update zones securely using only message authentication. This document does not specify update policy, but extends dynamic update RFC2136 to DNSSEC types and their restrictions. This is a WG last call ending March 8'th 2000. The draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-simple-secure-update-0 0.txt There are no known defects in this version of the document, but it depends on the Signing Auth document which is in parallel WGLC. Please send comments to the list. This document is to be published as an standards track RFC, obsoleting RFC2137. 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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 23 12:08:02 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26991 for ; Wed, 23 Feb 2000 12:08:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Nedc-000FpO-00 for namedroppers-data@psg.com; Wed, 23 Feb 2000 08:27:44 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Nedc-000FpI-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 08:27:44 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Nedb-000Kxe-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 08:27:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.2.0.58.20000223160407.01e11510@dokka.maxware.no> Date: Wed, 23 Feb 2000 16:04:58 +0100 To: "D. J. Bernstein" , namedroppers@internic.net From: Harald Tveit Alvestrand Subject: Re: a.dns.int In-Reply-To: <20000222201111.2486.qmail@cr.yp.to> References: <20000215191952.24273.qmail@cr.yp.to> <20000220195445.21265.qmail@cr.yp.to> <4.2.0.58.20000222094532.01be2ed0@dokka.maxware.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 20:11 22.02.00 +0000, D. J. Bernstein wrote: >Harald Tveit Alvestrand writes: > > Dan Bernstein made this argument in DRUMS some years ago, and found little > > to no support from other mail developers there. > >False. Most MTAs _already_ permitted IP addresses in MX records. I was talking about the people present on the list, not about MTAs. > > delegate this as a subdomain under cr.yp.to > >You don't mind if software starts assigning special meanings to domains >that could be transferred to other people later? In that respect, too, there is nothing unique about a.dns.int. Harald -- Harald Tveit Alvestrand, EDB Maxware, Norway Harald.Alvestrand@edb.maxware.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 23 15:32:19 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02358 for ; Wed, 23 Feb 2000 15:32:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Nhcz-000JUn-00 for namedroppers-data@psg.com; Wed, 23 Feb 2000 11:39:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Nhcz-000JUe-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 11:39:17 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Nhcy-0000w2-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 11:39:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19398D273324D3118A2B0008C7E9A5690988205F@SIT.platinum.corp.microsoft.com> From: James Gilroy To: Mark.Andrews@nominum.com, namedroppers@internic.net Subject: RE: RCODEs in EDNS Date: Wed, 23 Feb 2000 11:12:14 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Mark.Andrews@nominum.com [mailto:Mark.Andrews@nominum.com] > > > What's the point in doing it? > Excellent question Mark. My answer would be clarity. I consider it an exercise in cleaning detritus from the spec. I guess how much appeal that has depends on how anal one is about such stuff. I'd like to push towards having a spec that's clear and easily implementable from scratch. I would also note, that there's probably more than one existing implementation that doesn't do this correctly. I know of one -- the first one I wrote. I assumed that the Authority bit was sufficient to distinguish between empty-auth responses and referrals. Once caching of empty-auth responses started, that code was broken. Currently to do this correctly you must completely parse the packet to determine whether the answer is a referral or empty-auth response. That just strikes me as unnecessarily complex. So yeah. I'd agree that one way to do something is better. But moving forward with a GOOD way to do something also has advantages. jim > Servers and clients are still going to have to do it the > old way when talking to old client and servers so the code > to do this has to exist. > > In general having only one way to do something leads to less > errors. > > Mark > > > One issue that i've always found annoying, that i'd like to > see cleaned up > > in EDNS is the overloading of the NO_ERROR RCODE in queries. > > > > Currently NO_ERROR can mean > > -- have an answer > > -- empty auth response (name exists, RR set doesn't) > > -- referral > > > > To correctly distinguish the later two response from some BIND > > implementations, involves testing a bunch of bits or > further parsing the > > packet. (It was never clear to me why empty auth response > didn't have an > > RCODE to begin with as name error did.) > > > > I think it would be a useful service -- primarily to > implementors, but also > > to anyone diagnosing problems, looking at traces, etc. -- > to clean this up > > now. > > > > I'd propose using > > NXRRSET -> empty auth response (that's exactly what it > means in the > > update case) > > NOTAUTH -> referral (sorta captures the idea) > > > > The idea would be that EDNS aware implementations would > just tack these onto > > the revelant case statements in their packet parsers and do whatever > > processing they now do when they detect these conditions by > the appropriate > > set of tests. > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 23 16:38:41 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03195 for ; Wed, 23 Feb 2000 16:38:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12Nifk-000Kmq-00 for namedroppers-data@psg.com; Wed, 23 Feb 2000 12:46:12 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12Nifj-000Kmi-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 12:46:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12Niff-0001PB-00 for namedroppers@ops.ietf.org; Wed, 23 Feb 2000 12:46:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.1.20000223121004.00a707b0@mail.gw.tislabs.com> Date: Wed, 23 Feb 2000 15:10:40 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Agenda items Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Current schedule is: TUESDAY, March 28, 2000 0900-1130 Morning Sessions INT dnsext DNS Extensions WG * (MBONE) Send in agenda slot requests to me ASAP including how much time you need. 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 to unsubscribe send a message to 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 Feb 24 12:31:29 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06678 for ; Thu, 24 Feb 2000 12:31:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12O19H-0009Zt-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 08:29:55 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12O19H-0009Zn-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 08:29:55 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12O19G-0009dS-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 08:29:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.1.20000223001306.00970ae0@mail.gw.tislabs.com> Date: Thu, 24 Feb 2000 09:32:29 -0500 To: Olafur Gudmundsson From: Edward Lewis Subject: What month is it? Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 12:31 AM -0500 3/23/00, Olafur Gudmundsson wrote: >This is a second last call on this document, in the first round some March 23rd? What happened to February? Did you cross the International Month Line? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 24 12:31:38 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06697 for ; Thu, 24 Feb 2000 12:31:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12O18Y-0009Yq-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 08:29:10 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12O18X-0009Yk-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 08:29:09 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12O18X-0009d0-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 08:29:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <38B360E7.7297740D@daimlerchrysler.com> References: <14219.951212607@gromit.rfc1035.com> Date: Thu, 24 Feb 2000 09:17:41 -0500 To: Kevin Darcy From: Edward Lewis Subject: Re: To Be Cached, or Not To Be Cached, That is the Question Cc: namedroppers@internic.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just to contribute another (vote/)opinion on the value of eliminating a few bytes from transmitted resource records. I've been under the impression that the network performance is a function of number of packets rather than the size of packets. If the change cuts down the number of messages, then we win. Here are some reasons why I don't think a few bytes are worth the change.: On ethernet, there is a minimum size, so small packets would be padded anyway. Also, the network's "waste" time is during the collision avoidance, not the transmission. In this case, a few bytes here or there aren't worth worrying about. (I know the world isn't entirely ethernet, so maybe this is a red herring.) I think a more important factor is how a host accepts a packet. An interrupt is raised and the OS has to handle that. Whether the packet is 2 bytes or 2 K bytes, the time to handle the packet is pretty much the same. To some extent, this rule also applies to routers. I won't bother to repeat the other reasons I agree with that have already appeared in the thread. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 24 12:38:23 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06679 for ; Thu, 24 Feb 2000 12:31:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12O18L-0009YQ-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 08:28:57 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12O18K-0009YK-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 08:28:56 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12O18F-0009cI-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 08:28:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <4.1.20000223121004.00a707b0@mail.gw.tislabs.com> Date: Wed, 23 Feb 2000 21:14:11 -0500 To: Olafur Gudmundsson From: Edward Lewis Subject: Re: Agenda items Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since this is MBone'd, what is the time/date in UTC? At 3:10 PM -0500 2/23/00, Olafur Gudmundsson wrote: >Current schedule is: >TUESDAY, March 28, 2000 >0900-1130 Morning Sessions >INT dnsext DNS Extensions WG * (MBONE) > >Send in agenda slot requests to me ASAP including how much time you need. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 24 19:35:23 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13154 for ; Thu, 24 Feb 2000 19:35:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12O7ue-000Go7-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 15:43:16 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12O7ue-000Go1-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 15:43:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12O7ud-000Chq-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 15:43:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Edward Lewis Cc: Olafur Gudmundsson , namedroppers@internic.net Subject: Re: Agenda items In-Reply-To: Your message of "Wed, 23 Feb 2000 21:14:11 CDT." Date: Fri, 25 Feb 2000 10:18:30 +1100 Message-Id: <545.951434310@munnari.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Wed, 23 Feb 2000 21:14:11 -0500 From: Edward Lewis Message-ID: | Since this is MBone'd, what is the time/date in UTC? | | At 3:10 PM -0500 2/23/00, Olafur Gudmundsson wrote: | >Current schedule is: | >TUESDAY, March 28, 2000 | >0900-1130 Morning Sessions In UTC that would be 23:30 Mar 27 to 02:00 Mar 28. DST will have (just) ended, so Adelaide will be UTC+09:30 for the entire IETF, for any other time conversions you might need to make. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 24 19:58:56 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13350 for ; Thu, 24 Feb 2000 19:58:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12O8Xo-000Hvx-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 16:23:44 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12O8Xn-000Hvq-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 16:23:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12O8Xn-000D03-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 16:23:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38B5AE21.72D2C0C9@daimlerchrysler.com> Date: Thu, 24 Feb 2000 17:18:09 -0500 From: Kevin Darcy To: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <14219.951212607@gromit.rfc1035.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > Just to contribute another (vote/)opinion on the value of eliminating a few > bytes from transmitted resource records. I've been under the impression > that the network performance is a function of number of packets rather than > the size of packets. > > If the change cuts down the number of messages, then we win. > > Here are some reasons why I don't think a few bytes are worth the change.: > > On ethernet, there is a minimum size, so small packets would be padded > anyway. Also, the network's "waste" time is during the collision > avoidance, not the transmission. In this case, a few bytes here or there > aren't worth worrying about. (I know the world isn't entirely ethernet, so > maybe this is a red herring.) > > I think a more important factor is how a host accepts a packet. An > interrupt is raised and the OS has to handle that. Whether the packet is 2 > bytes or 2 K bytes, the time to handle the packet is pretty much the same. > To some extent, this rule also applies to routers. Yes, network performance is *largely* dependent on the number of packets rather than the number of bytes, but I believe there are also some components which are packet-size dependent. I don't make my living as a network engineer, but from my general knowledge of such matters, it seems to me that packet fragmentation and reassembly is more likely with larger packets. Also, a typical networking stack implementation does a fair number of internal buffer copies in the course of processing network transactions, and these can be more resource-intensive with larger packets. And it seems to me that serial and/or point-to-point protocols like the ubiquitous PPP are going to be affected by large packets more than "bus" protocols like Ethernet (although doesn't a larger payload increase the chance of collisions even in an Ethernet context?). - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 24 20:38: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 UAA14045 for ; Thu, 24 Feb 2000 20:38:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12O99z-000J37-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 17:03:11 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12O99z-000J31-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 17:03:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12O99z-000DH0-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 17:03:11 -0800 Message-Id: <200002250047.QAA25242@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2782 on DNS SRV RR Cc: rfc-ed@ISI.EDU, namedroppers@internic.net Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 24 Feb 2000 16:47:43 -0800 From: RFC Editor Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2782 Title: A DNS RR for specifying the location of services (DNS SRV) Author(s): A. Gulbrandsen, P. Vixie, L. Esibov Status: Standards Track Date: February 2000 Mailbox: agulbra@troll.no, vixie@isc.org, levone@microsoft.com Pages: 12 Characters: 24013 Obsoletes: 2052 I-D Tag: draft-ietf-dnsind-rfc2052bis-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2782.txt This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. This document is a product of the DNS IXFR, Notification, and Dynamic Update Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000224164320.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2782 --OtherAccess Content-Type: Message/External-body; name="rfc2782.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000224164320.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 24 21:00:24 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14236 for ; Thu, 24 Feb 2000 21:00:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12O9fq-000K0I-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 17:36:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12O9fp-000K0A-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 17:36:05 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12O9fp-000DTj-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 17:36:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38B5D939.D55C3C7C@whistle.com> Date: Thu, 24 Feb 2000 17:22:01 -0800 From: Terry Lambert To: Kevin Darcy CC: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <14219.951212607@gromit.rfc1035.com> <38B5AE21.72D2C0C9@daimlerchrysler.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kevin Darcy wrote: > Yes, network performance is *largely* dependent on the > number of packets rather than the number of bytes, but > I believe there are also some components which are > packet-size dependent. There are. For one, a larger packet will hold the carrier up longer. There are a lot of good reasons to want to use the same number of smaller packets, or have smaller payload components so that the agregate won't push you to TCP. > I don't make my living as a network engineer, but from > my general knowledge of such matters, it seems to me > that packet fragmentation and reassembly is more likely > with larger packets. The whole path minimum MTU, not fragging, is the gating factor on UDP packet sizes. A lot of things, including NAT, tend to break MTU discovery. > Also, a typical networking stack implementation does a > fair number of internal buffer copies in the course of > processing network transactions, and these can be more > resource-intensive with larger packets. In general, most modern systems do "zero copy" transmits; they copy once from user-to-kernel or from buffer cache to network buffer (as in "sendfile()"), and they copy once from the network buffer to the network adapter memory. Some systems use references and buffer mapping so that they can pass a reference to a buffer cache entry instead of needing to copy the data to a seperate network buffer (this is most common in systems with a unified VM and buffer cache). Fragged packet reassembly on the receiver is commonly done using scatter-gather to only copy the data once from the network card memory into a network (or buffer cache) buffer. > And it seems to me that serial and/or point-to-point > protocols like the ubiquitous PPP are going to be affected > by large packets more than "bus" protocols like Ethernet > (although doesn't a larger payload increase the chance of > collisions even in an Ethernet context?). PPP usually has a smaller MTU, but as a general rule, it is high enough for a 512b UDP packet plus headers. We should note now that this is more a client resolver issue than it is a server issue, since servers are unlikely to be on the other side of transient connections, and it would be very hard for a server on the other side of a transient connection to be authoritative, even under the best of circumstances. I think we all acknowledge that if you had smaller bits of data, you'd be better of than if you had larger bits of data. We don't need to reach for examples that end up being straw men; if we set up straw men to be knocked down, we risk the legitimate reasons for keeping packets small being tarred with the same brush. As far as the current argument goes, I think it would be a good idea if we could notify the server to not send us stuff we are going to discard. By the same token, it's not a good idea to break interoperability. I'd like to see a clarification on options for implicit negotiation, such that the responding server is permitted to treat all unknown option bits as zeros. Without that basis, I think even the currently drafted non-zero bits could legitimately result in undefined behaviour. It only makes sense to add the "don't send me this crap" bit after you've defined a way for down-rev servers to ignore your request because they can't satisfy it. -- Terry Lambert -- Whistle Communications, Inc., an I.B.M. Company -- terry@whistle.com ------------------------------------------------------------------- This is formal notice under California Assembly Bill 1629, enacted 9/26/98 that any UCE sent to my email address will be billed $50 per incident to the legally allowed maximum of $25,000. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 24 22:54:58 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17909 for ; Thu, 24 Feb 2000 22:54:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12OB9x-000MVh-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 19:11:17 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12OB9w-000MVa-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 19:11:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12OB9w-000E3Z-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 19:11:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38B5EFD7.D3E301CE@ehsco.com> Date: Thu, 24 Feb 2000 18:58:31 -0800 From: "Eric A. Hall" CC: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <14219.951212607@gromit.rfc1035.com> <38B5AE21.72D2C0C9@daimlerchrysler.com> <38B5D939.D55C3C7C@whistle.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > As far as the current argument goes, I think it would be a > good idea if we could notify the server to not send us stuff > we are going to discard. By the same token, it's not a good > idea to break interoperability. That's my opinion as well. Personally, I also think it would be an extremely useful for CDPD and other media that are both lossy and expensive. It would not be extremely useful on LANs, and could actually be harmful in some situations. But as an option that must be implemented to be used, no harm should fall to devices that don't use it. I would think that the first step would be to have some sort of proof that somebody will actually use this feature. If so, I see no reason not to do it. But if not, then I see no reason to waste time on it. It would also seem to be prudent to show that a significant number of products would implement such a feature. If only one client (or only one server) supports it, then that wouldn't be very compelling either. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 24 22:55:14 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17923 for ; Thu, 24 Feb 2000 22:55:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12OBBm-000MaK-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 19:13:10 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12OBBl-000MaA-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 19:13:09 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12OBBl-000E4f-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 19:13:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <38B5AE21.72D2C0C9@daimlerchrysler.com> References: <14219.951212607@gromit.rfc1035.com> Date: Thu, 24 Feb 2000 21:50:16 -0500 To: Kevin Darcy From: Edward Lewis Subject: Re: To Be Cached, or Not To Be Cached, That is the Question Cc: namedroppers@internic.net Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 5:18 PM -0500 2/24/00, Kevin Darcy wrote: >large packets more than "bus" protocols like Ethernet (although doesn't a >larger payload increase the chance of collisions even in an Ethernet >context?). Not with carrier sensing, per se, although a longer packet transmission increases the expected number of waiting stations ready to participate in the next round of competition for the channel. I guess you could say this is an increase in collisions. This is getting a bit far afield now. IMHO, saving a few bytes in the envelope isn't really worth it. We've already discarded local compression because the WG judged the savings weren't worth the effort. Saving bytes by "stifling" the sending of certain types of SIG records is another matter. See the following link for the draft. Eliminating SIG records gives more bang for the (insert local currency reference here). http://www.ietf.org/internet-drafts/draft-ietf-dnsind-sigalgopt-00.txt. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 "It takes years of training to know when to do nothing" - Dogbert 1/21/00 Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 24 22:57:15 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17934 for ; Thu, 24 Feb 2000 22:57:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12OBMj-000Mv3-00 for namedroppers-data@psg.com; Thu, 24 Feb 2000 19:24:29 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12OBMj-000Muw-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 19:24:29 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12OBMi-000EA2-00 for namedroppers@ops.ietf.org; Thu, 24 Feb 2000 19:24:28 -0800 Message-ID: <38B5F4D1.D90C506A@daimlerchrysler.com> Date: Thu, 24 Feb 2000 22:19:45 -0500 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.7 sun4u) MIME-Version: 1.0 To: namedroppers@internic.net Subject: Re: To Be Cached, or Not To Be Cached, That is the Question References: <200002230716.SAA14366@bsdi.dv.isc.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@nominum.com wrote: > Kevin, > this optimisation would really only come into play between > stub resolvers and their servers. This is normally a LAN > connection or a couple of hops to the ISP's nameserver. It will > not (normally) result in savings on international links as most > of those queries are coming from servers which do cache the results > and do need those additional RRsets. Such generalizations are iffy. Yes, what you say may be true of *most* Internet arrangements and *most* intranet architectures, but our intranet, for one, has many stub resolvers sending their queries over WAN links -- in many cases *international* WAN links -- because local DNS servers are not cost-justified for the location. As they say in the automotive business and elsewhere: Your Mileage May Vary. > I would suggest that you consider what Dan said and use RD as > a flag bit, not worry about the ttl and just trim the RRsets that > are not required to answer the question. Patches welcome. RD is a rough approximation. RD queries can come from downstream selective-forwarders who may be able to put Authority and/or Additional data to good use: by omitting Authority and Additional in that case, you are causing them to generate extra queries over the long haul. Nevertheless, trimming responses to RD queries optimizes for the general case, which is a Good Thing, and I'll see what I can do about producing a patch (BIND 8 or BIND 9? #ifdef'ed or not?). The TTL field constitutes 28% of an A RR's size, less for other fixed-RDATA-size types, and possibly more for records where the RDATA consists of only a compressed label. Together with the class field, we're talking 42%, plus or minus. That's the level of potential "gain" we're talking about here (although Jim Reid's comment about 4 octets being a drop in the bucket compared to the size of SIG records is of course salient). As for "pain", my initial performance trials indicate a 16%/4%/12% *savings* for NCF in user/system/overall CPU time, but the modified named was omitting Authority and Additional sections for many if not most of the queries (the simulator set NCF only for recursive A and PTR queries -- the kind of queries mostly likely to originate from high-level resolver calls -- which constituted 72% of the total query volume, but that figure needs to be offset by some as-yet-unknown percentage of queries which received referrals, containing Authority and Additional sections). I'll run some more trials between a "section-trimming" BIND and "full NCF" -- including, I think, class-field omission as well as TTL-field omission -- and see how the numbers turn out. BIND patch or no BIND patch, I don't know that I'm ready to abandon full field-omitting optimization just yet. There's still a lot of resources to be saved. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Feb 25 08:43:59 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07411 for ; Fri, 25 Feb 2000 08:43:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12OKD1-0006mL-00 for namedroppers-data@psg.com; Fri, 25 Feb 2000 04:51:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12OKD1-0006mF-00 for namedroppers@ops.ietf.org; Fri, 25 Feb 2000 04:51:03 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12OKD0-000IwD-00 for namedroppers@ops.ietf.org; Fri, 25 Feb 2000 04:51:02 -0800 Message-Id: <200002251132.GAA04990@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-edns0dot5-00.txt Date: Fri, 25 Feb 2000 06:32:06 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A Proposed Enhancement to the EDNS0 Version Mechanism Author(s) : R. Austein, H. Alvestrand Filename : draft-ietf-dnsext-edns0dot5-00.txt Pages : 5 Date : 24-Feb-00 EDNS0 [EDNS0] specifies a general framework for extending the packet format used by the Domain Name System protocols. The framework includes a simple version numbering scheme to allow the parties in a DNS protocol exchange to determine which extension features the other party understands. While having the advantage of simplicity, the version numbering scheme as specified has drawbacks: - It provides no way to deprecate a protocol feature; - It provides no way to deploy experimental protocol features. This note proposes to replace the monolithic version numbering mechanism with a mechanism for listing an explicit set of protocol features that a particular implementation supports. We retain version numbering as a way of abbreviating the feature sets that we expect to see in common use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-edns0dot5-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-edns0dot5-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000224111624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-edns0dot5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-edns0dot5-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000224111624.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 28 13:03:47 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16519 for ; Mon, 28 Feb 2000 13:03:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12PTVA-000H6L-00 for namedroppers-data@psg.com; Mon, 28 Feb 2000 08:58:32 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12PTVA-000H6F-00 for namedroppers@ops.ietf.org; Mon, 28 Feb 2000 08:58:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12PTV9-000G6d-00 for namedroppers@ops.ietf.org; Mon, 28 Feb 2000 08:58:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: dfernan1@airtel.es To: namedroppers@internic.net Message-ID: Date: Mon, 28 Feb 2000 16:54:44 +0100 Subject: About name syntax Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, In RFC 1035 parragraph 2.3.1. ("Preferred name syntax") recomended characters for domain names are a-z, A-Z, 0-9 and "-". What kind of problems could i find if i used the "/" char inside a host name (for example the/host.my.domain).? Thanks. David Fernandez. to unsubscribe send a message to 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 Feb 28 13:07:32 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16606 for ; Mon, 28 Feb 2000 13:07:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12PTe9-000HLx-00 for namedroppers-data@psg.com; Mon, 28 Feb 2000 09:07:49 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12PTe8-000HLr-00 for namedroppers@ops.ietf.org; Mon, 28 Feb 2000 09:07:48 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12PTe8-000GAb-00 for namedroppers@ops.ietf.org; Mon, 28 Feb 2000 09:07:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: dfernan1@airtel.es Cc: namedroppers@internic.net Subject: Re: About name syntax References: Message-Id: Date: Mon, 28 Feb 2000 09:00:00 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > In RFC 1035 parragraph 2.3.1. ("Preferred name syntax") recomended > characters for domain names are a-z, A-Z, 0-9 and "-". What kind of > problems could i find if i used the "/" char inside a host name (for > example the/host.my.domain).? rfc 2181 11. Name syntax Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose. The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default. Note however, that the various applications that make use of DNS data can have restrictions imposed on what particular values are acceptable in their environment. For example, that any binary label can have an MX record does not imply that any binary name can be used as the host part of an e-mail address. Clients of the DNS can impose whatever restrictions are appropriate to their circumstances on the values they use as keys for DNS lookup requests, and on the values returned by the DNS. If the client has such restrictions, it is solely responsible for validating the data from the DNS to ensure that it conforms before it makes any use of that data. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 28 15:06:20 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18830 for ; Mon, 28 Feb 2000 15:06:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12PVk6-000LVG-00 for namedroppers-data@psg.com; Mon, 28 Feb 2000 11:22:06 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12PVk6-000LV9-00 for namedroppers@ops.ietf.org; Mon, 28 Feb 2000 11:22:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12PVk6-000H20-00 for namedroppers@ops.ietf.org; Mon, 28 Feb 2000 11:22:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38BAC2E5.5B8C5D47@ehsco.com> Date: Mon, 28 Feb 2000 10:48:05 -0800 From: "Eric A. Hall" To: dfernan1@airtel.es CC: namedroppers@internic.net Subject: Re: About name syntax References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > What kind of problems could i find if i used the "/" char inside a > host name (for example the/host.my.domain).? DNS itself doesn't care; you can use any data inside of any label for any purpose, as long as it meets the length requirements. But if you plan to use this as a hostname, you will have a wide degree of problems, depending upon the intended usage. Applications that use host names will tend to barf when the hostname doesn't confor to RFC 972/1122 rules for host naming (not DNS labels, but host NAMES). You can expect problems such as web servers rejecting the connection (later versions of Apache do this I believe, after doing the PTR lookup), BOOTP/DHCP servers refusing to assign a lease if that host name is included in the string, X clients/servers not working right, .rhosts and the like barfing, and so forth. Lots of stuff still depends on rules for host naming. You'll find them when you try to do it. There are also some tricks you'll have to play to put this kind of data into some DNS servers, who normally see / as an escape character, if you do end up trying it. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 28 16:20:16 2000 Received: from psg.com (root@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20258 for ; Mon, 28 Feb 2000 16:20:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.12 #1) id 12PWrQ-000OC4-00 for namedroppers-data@psg.com; Mon, 28 Feb 2000 12:33:44 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.12 #1) id 12PWrP-000OBy-00 for namedroppers@ops.ietf.org; Mon, 28 Feb 2000 12:33:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12PWrP-000HVc-00 for namedroppers@ops.ietf.org; Mon, 28 Feb 2000 12:33:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38BADB20.FE76B997@ehsco.com> Date: Mon, 28 Feb 2000 12:31:28 -0800 From: "Eric A. Hall" To: dfernan1@airtel.es, namedroppers@internic.net Subject: Re: About name syntax References: <38BAC2E5.5B8C5D47@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Applications that use host names will tend to barf when the hostname > doesn't confor to RFC 972/1122 rules for host naming (not DNS labels, > but host NAMES). I meant RFC 952 (as supplemented by RFC 1122 which changed the max length to 63 chars, although "man hosts" on many systems will show a 24 character limit which proves my point about backwards compatibility with 952 being important). RFC 972 does not apply to this discussion at all. Sorry for any confusion. -- Eric A. Hall ehall@ehsco.com +1-650-685-0557 http://www.ehsco.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.