From owner-namedroppers@ops.ietf.org Mon Jul 3 11:08:34 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03075 for ; Mon, 3 Jul 2000 11:08:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 1396x6-000Hzi-00 for namedroppers-data@psg.com; Mon, 03 Jul 2000 07:12:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 1396x5-000Hzc-00 for namedroppers@ops.ietf.org; Mon, 03 Jul 2000 07:11:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 1396x5-0003Vb-00 for namedroppers@ops.ietf.org; Mon, 03 Jul 2000 07:11:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007031156.HAA01093@hygro.adsl.duke.edu> To: Edward Lewis cc: "Donald E. Eastlake 3rd" , Erik Nordmark , namedroppers@ops.ietf.org Subject: Re: IESG comments on draft-ietf-dnsext-iana-dns In-Reply-To: Message from Edward Lewis of "Fri, 30 Jun 2000 10:14:07 EDT." Date: Mon, 03 Jul 2000 07:56:05 -0400 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Not to protest, but when I went to access the assignments (for another > reason) today, I followed the IANA link. Here's what I got: > http://www.iana.org/numbers.htm pointed to: > http://www.iana.org/numbers.htm#D pointed to: > http://www.isi.edu/in-notes/iana/assignments/dns-parameters A known issue, and my understanding is that IANA is working to get this cleaned up. But it will take some time. Thomas to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 5 15:24:08 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15131 for ; Wed, 5 Jul 2000 15:24:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 139u27-0006cN-00 for namedroppers-data@psg.com; Wed, 05 Jul 2000 11:36:27 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 139u27-0006cH-00 for namedroppers@ops.ietf.org; Wed, 05 Jul 2000 11:36:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 139u26-000L1p-00 for namedroppers@ops.ietf.org; Wed, 05 Jul 2000 11:36:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007051835.OAA13684@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: A DNS RR Type for Lists of Address Prefixes (APL RR) to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 05 Jul 2000 14:35:15 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has received a request from the DNS Extensions Working Group to consider A DNS RR Type for Lists of Address Prefixes (APL RR) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 19, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-apl-rr-01.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 7 09:46:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26036 for ; Fri, 7 Jul 2000 09:46:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13AXpE-0006eB-00 for namedroppers-data@psg.com; Fri, 07 Jul 2000 06:05:48 -0700 Received: from cnri-2-112.cnri.reston.va.us ([132.151.2.112] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13AXpD-0006e5-00 for namedroppers@ops.ietf.org; Fri, 07 Jul 2000 06:05:47 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13AXpH-0001Gx-00 for namedroppers@ops.ietf.org; Fri, 07 Jul 2000 09:05:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.13 #1) id 13AVjV-0005rK-00 for namedroppers@ops.ietf.org; Fri, 07 Jul 2000 03:51:46 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19915; Fri, 7 Jul 2000 06:51:44 -0400 (EDT) Message-Id: <200007071051.GAA19915@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-01.txt Date: Fri, 07 Jul 2000 06:51:44 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) IANA Considerations Author(s) : D. Eastlake, E. Brunner, B. Manning Filename : draft-ietf-dnsext-iana-dns-01.txt Pages : 12 Date : 06-Jul-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-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-iana-dns-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-iana-dns-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000706151824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-iana-dns-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-iana-dns-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706151824.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 Jul 7 09:46:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26071 for ; Fri, 7 Jul 2000 09:46:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13AXpA-0006dm-00 for namedroppers-data@psg.com; Fri, 07 Jul 2000 06:05:44 -0700 Received: from cnri-2-112.cnri.reston.va.us ([132.151.2.112] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13AXpA-0006dg-00 for namedroppers@ops.ietf.org; Fri, 07 Jul 2000 06:05:44 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13AXpD-0001Gv-00 for namedroppers@ops.ietf.org; Fri, 07 Jul 2000 09:05:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.13 #1) id 13AVjP-0005r6-00 for namedroppers@ops.ietf.org; Fri, 07 Jul 2000 03:51:39 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19901; Fri, 7 Jul 2000 06:51:38 -0400 (EDT) Message-Id: <200007071051.GAA19901@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-message-size-00.txt Date: Fri, 07 Jul 2000 06:51:37 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC and IPv6 A6 aware server/resolver message size requirements Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-message-size-00.txt Pages : 5 Date : 06-Jul-00 This document mandates support for EDNS0 in DNS entities claiming to support DNS Security Extensions and A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fallback to TCP will happen, having a detrimental impact on query latency and DNS server load. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-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-message-size-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-message-size-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: <20000706151815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-message-size-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-message-size-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706151815.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 Jul 10 15:41:08 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25729 for ; Mon, 10 Jul 2000 15:41:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13BiRu-000Az4-00 for namedroppers-data@psg.com; Mon, 10 Jul 2000 11:38:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13BiRu-000Ayy-00 for namedroppers@ops.ietf.org; Mon, 10 Jul 2000 11:38:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13BiRu-0001Hx-00 for namedroppers@ops.ietf.org; Mon, 10 Jul 2000 11:38:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000710114743.07f79d20@localhost> Date: Mon, 10 Jul 2000 11:58:02 -0400 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: Agenda Items for DNSEXT meeting in Pittsburg Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If you want a slot on the agenda send me a note and how long you need. I asked for a two hour slot I do not know what day yet. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 12 11:10:28 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26597 for ; Wed, 12 Jul 2000 11:10:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13CNUg-0003Ze-00 for namedroppers-data@psg.com; Wed, 12 Jul 2000 07:28:10 -0700 Received: from [63.67.187.98] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13CNUg-0003ZY-00 for namedroppers@ops.ietf.org; Wed, 12 Jul 2000 07:28:10 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13CNUe-0000FE-00 for namedroppers@ops.ietf.org; Wed, 12 Jul 2000 07:28:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007121223.IAA18705@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: Domain Name System (DNS) IANA Considerations to BCP Date: Wed, 12 Jul 2000 08:23:46 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'Domain Name System (DNS) IANA Considerations' as a BCP. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary The document specifies 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. Working Group Summary There was WG consensus to advance the document. Protocol Quality The document has been reviewed for the IESG by Erik Nordmark to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 12 11:23:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27345 for ; Wed, 12 Jul 2000 11:23:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13CNc5-0003eG-00 for namedroppers-data@psg.com; Wed, 12 Jul 2000 07:35:49 -0700 Received: from [63.67.187.98] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13CNc4-0003eA-00 for namedroppers@ops.ietf.org; Wed, 12 Jul 2000 07:35:49 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13CNc3-0000Fi-00 for namedroppers@ops.ietf.org; Wed, 12 Jul 2000 07:35:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 12 Jul 2000 10:03:53 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: New edition of the Zone Status draft Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've put out a new version of the zone status draft (announcement sooner or later) without a section urging for the removal of the NULL keys and with a section on "islands" of security. The three reasons why the NULL key dropping in favor of the NXT KEY bit was, umm, dropped are: 1) No one substantiated the claim that the NULL keys represented a volume problem. 2) Folks are more against the NXT, especially expanding its mission, than against the NULL key. 3) There was no backwards-compatible way to address resolvers that expect a NULL key if we remove the NULL key. Now the draft is back to being concerned only with defining terms of a zone's status. - The draft still deprecates the experimental status and defines a zone as secured/not secured rather than secured per algorithm. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 13 10:11:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20033 for ; Thu, 13 Jul 2000 10:11:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Cixd-000FZc-00 for namedroppers-data@psg.com; Thu, 13 Jul 2000 06:23:29 -0700 Received: from ppp244-as10.lsanca.ni.net ([209.189.118.244] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13Cixb-000FZW-00 for namedroppers@ops.ietf.org; Thu, 13 Jul 2000 06:23:27 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Cixg-0000mz-00 for namedroppers@ops.ietf.org; Thu, 13 Jul 2000 06:23:32 -0700 Message-Id: <200007131026.GAA10947@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-02.txt Date: Thu, 13 Jul 2000 06:26:23 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Extension Clarification on Zone Status Author(s) : E. Lewis Filename : draft-ietf-dnsext-zone-status-02.txt Pages : 8 Date : 12-Jul-00 The definition of a secured zone is presented, updating RFC 2535. After discussion on the mailing list and other working group consideration, removed from earlier editions of this draft are a new interpretation of the NXT record and a proposal to obsolete NULL keys. Deprecation of 'experimentally secure' remains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-zone-status-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-zone-status-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000712135951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-zone-status-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-zone-status-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712135951.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 Jul 14 11:53:39 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10811 for ; Fri, 14 Jul 2000 11:53:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13D6yC-0008W9-00 for namedroppers-data@psg.com; Fri, 14 Jul 2000 08:01:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13D6yC-0008W2-00 for namedroppers@ops.ietf.org; Fri, 14 Jul 2000 08:01:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13D6yB-000LIz-00 for namedroppers@ops.ietf.org; Fri, 14 Jul 2000 08:01:39 -0700 Message-Id: <200007141050.GAA08623@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-01.txt Date: Fri, 14 Jul 2000 06:50:02 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A Proposed Enhancement to the EDNS0 Version Mechanism Author(s) : R. Austein, H. Alvestrand Filename : draft-ietf-dnsext-edns0dot5-01.txt Pages : 6 Date : 13-Jul-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-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-edns0dot5-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-edns0dot5-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000713145009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-edns0dot5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-edns0dot5-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713145009.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 Sat Jul 15 03:58:32 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27523 for ; Sat, 15 Jul 2000 03:58:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13DMEO-000HkE-00 for namedroppers-data@psg.com; Sat, 15 Jul 2000 00:19:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13DMEN-000Hk8-00 for namedroppers@ops.ietf.org; Sat, 15 Jul 2000 00:19:23 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13DMEN-0001E7-00 for namedroppers@ops.ietf.org; Sat, 15 Jul 2000 00:19:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Sat, 15 Jul 2000 00:18:38 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 15 10:36:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07033 for ; Sat, 15 Jul 2000 10:36:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13DSMm-000MNA-00 for namedroppers-data@psg.com; Sat, 15 Jul 2000 06:52:28 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13DSMl-000MN4-00 for namedroppers@ops.ietf.org; Sat, 15 Jul 2000 06:52:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13DSMl-0003mI-00 for namedroppers@ops.ietf.org; Sat, 15 Jul 2000 06:52:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007151042.e6FAgR900668@malmo.trab.se> Date: Sat, 15 Jul 2000 12:42:15 +0200 (MET DST) From: Dan Reply-To: Dan Subject: What do you think about internationalisation of DNS? To: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi The IDN working group have been discussing the requirements for non-ASCII domain names for a while now. Below is the annoucement for one draft with a way to handle non-ASCII domain names in DNS. I am very interested in hearing your comments on it. The goal of it is to add non-ASCII domain names in a controlled manner so it can work together with the DNS servers that do not know about non-ASCII names and with software that only expect ASCII in names. And still be possible to start using immedately without any large query overhead. To be able to do this, the DNS server must be able to identify queries coming from non-ASCII aware clients. The draft includes both the (as I see it) best choice, and some alternatives to help the discussion. Regards, Dan --- 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 : Using the Universal Character Set in the Domain Name System (UDNS) Author(s) : D. Oscarsson Filename : draft-ietf-idn-udns-00.txt Pages : 16 Date : 10-Jul-00 Since the Domain Name System (DNS) [RFC1035] was created there have been a desire to use other characters than ASCII in domain names. Lately this desire have grown very strong and several groups have started to experiment with non-ASCII names. By using the Universal Character Set (UCS) [ISO10646] this document updates the Domain Name System so that non-ASCII domain names can be used while still being compatible with the current (RFC 1035) DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idn-udns-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-udns-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-udns-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. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 15 12:49:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09960 for ; Sat, 15 Jul 2000 12:49:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13DUn4-000NJu-00 for namedroppers-data@psg.com; Sat, 15 Jul 2000 09:27:46 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13DUn3-000NJo-00 for namedroppers@ops.ietf.org; Sat, 15 Jul 2000 09:27:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13DUn3-0004li-00 for namedroppers@ops.ietf.org; Sat, 15 Jul 2000 09:27:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From: =?iso-8859-1?Q?Mathias_K=F6rber?= To: "Dan" , Subject: RE: What do you think about internationalisation of DNS? Date: Sat, 15 Jul 2000 23:34:19 +0800 Message-ID: In-reply-to: <200007151042.e6FAgR900668@malmo.trab.se> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I elieve DNS INternationlaization may be at firstimpression a worthy goal, but will in the long term only lead to nationalization or regionalization of the NEt, or (if we're lucky) fail and people willfall back again on ASCII. While it allows many people in the world who don't use ASCII only character sets to use name in their languages and scripts in their Internet addresses, it will restrict the actual use of those addresses to those who can a) somewhat understand/distingush them from others b) enter them As a German living and working in Singapore, I have after 10 years not mastered the Chinese script a single bit. I cannot distinguish between many characters (most look the same to me), let alone type them in. If I got email from someone with a Chinese only name, I would have to save that address in my address book, and use some private indicator distingushing the name. (I would most likely use his romanized name if I knew that, or write something like 'Zhang from '. But private address books etc are not going to cut it in the long term, as they would overflow with entries if everyone;s email address had to be saved to be available later for cut and paste... In ASCII, I can remenmber (and easily enter) email addresses, webpages, even if I have them in paperform, saw the, on TV etc. With a URL in Chinese, Japanese, Mongolian or Thai, it would be impossible for me. I *do* think that an extension to Latin-1 would be a good thing, as many languages can be covered by that, which share a large amount of characters with ASCII, but have *some* own characters. But even there, most languages have accepted and agreed upon transliterations for those special characters (in Gernan: ö -> oe etc), that it does not matter very much. Even other languagas that do not have anything in common with the ASCII or Latin-1 based scripts have transliterations (eg Hanyu Pinyin for Chinese), which many native speakers/readers/riters of those languages already learn, that ASCII still makes for the most usefulk common ground. As such I think that I18N in the DNS would be a step in the wrong direction, as it would pave the way for countries and whole regions to isolate their Internet presence into their regional cultural zone, rather than opening up ways of communications by using a simple, widely available and understood common ground, ASCII (or Latin-1) Mathias > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Dan > Sent: Saturday, July 15, 2000 6:42 PM > To: namedroppers@ops.ietf.org > Subject: What do you think about internationalisation of DNS? > > > Hi > > The IDN working group have been discussing the requirements for > non-ASCII domain names for a while now. Below is the annoucement > for one draft with a way to handle non-ASCII domain names in DNS. > > I am very interested in hearing your comments on it. > The goal of it is to add non-ASCII domain names in > a controlled manner so it can work together with the > DNS servers that do not know about non-ASCII names and with software > that only expect ASCII in names. And still be possible to start > using immedately without any large query overhead. > To be able to do this, the DNS server must be able to identify > queries coming from non-ASCII aware clients. > > The draft includes both the (as I see it) best choice, and some > alternatives to help the discussion. > > Regards, > > Dan > > > --- > 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 : Using the Universal Character Set in the > Domain Name > System (UDNS) > Author(s) : D. Oscarsson > Filename : draft-ietf-idn-udns-00.txt > Pages : 16 > Date : 10-Jul-00 > > Since the Domain Name System (DNS) [RFC1035] was created there have > been a desire to use other characters than ASCII in domain names. > Lately this desire have grown very strong and several groups have > started to experiment with non-ASCII names. > By using the Universal Character Set (UCS) [ISO10646] this document > updates the Domain Name System so that non-ASCII domain names can be > used while still being compatible with the current (RFC 1035) DNS. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idn-udns-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-udns-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-udns-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. > > > > > 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 Sat Jul 15 16:20:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24624 for ; Sat, 15 Jul 2000 16:20:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13DXxO-000Ojv-00 for namedroppers-data@psg.com; Sat, 15 Jul 2000 12:50:38 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13DXxM-000Ojo-00 for namedroppers@ops.ietf.org; Sat, 15 Jul 2000 12:50:37 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13DXxJ-0002BW-00 for namedroppers@ops.ietf.org; Sat, 15 Jul 2000 12:50:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200007151723.CAA04452@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA04452; Sun, 16 Jul 2000 02:22:55 +0859 Subject: Re: What do you think about internationalisation of DNS? In-Reply-To: from "[Mathias K_rber]" at "Jul 15, 2000 11:34:19 pm" To: "[Mathias K_rber]" Date: Sun, 16 Jul 2000 02:22:54 +0859 () CC: Dan , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mathias; > I elieve DNS INternationlaization may be at firstimpression It is no INternatnalization. It is just an localization. > If I got email from someone with a Chinese only name, I would have to save > that address in my address book, and use some private indicator > distingushing the name. (I would most likely use his romanized That's why it is just an localization. As it is just a localization, there is NO international framework necessary. But, people working on the international framework won't admit it. So, just ignore them. > As such I think that I18N in the DNS would be a step in the wrong direction, They have been told so a lot of times. > I *do* think that an extension to Latin-1 would be a good thing, *YOU* do think so, of course. :-) Seriously speaking, Latin-1 is utterly broken. Introduction of soft hypen in Latin-1 completely breaks DNS. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 16 21:57:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29672 for ; Sun, 16 Jul 2000 21:57:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13DziA-0009oV-00 for namedroppers-data@psg.com; Sun, 16 Jul 2000 18:28:46 -0700 Received: from dhcp-065076.wireless-conference.inet2000.gr.jp ([133.195.65.76] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13DziA-0009oP-00 for namedroppers@ops.ietf.org; Sun, 16 Jul 2000 18:28:46 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Dzi9-0000SM-00 for namedroppers@ops.ietf.org; Mon, 17 Jul 2000 10:28:45 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200007160204.LAA05709@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA05709; Sun, 16 Jul 2000 11:04:31 +0900 Subject: Re: What do you think about internationalisation of DNS? In-Reply-To: from "[Mathias K_rber]" at "Jul 16, 2000 09:41:29 am" To: "[Mathias K_rber]" Date: Sun, 16 Jul 2000 11:04:30 +0859 () CC: Dan , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > That's why it is just an localization. > Which is why it's wrong. Well, as long as it is a localization, it is not wrong. It is wrong, however, to call it internatinalization and try to define meaningless frameworks. It is wrong, too, that international forums such as IETF waste time on localization issues. > > > I *do* think that an extension to Latin-1 would be a good thing, > > > > *YOU* do think so, of course. :-) > > I do, As it is localizatin, you can use any encodings, including Latin-1 (without soft hyphen), without bothering interopeability to other localization. There can be no interoperability, anyway. Your localization is assured not to be compatible with localization preferred in Japan. But, I have no reason to act against you use Latin-1 locally, because that's your localization, not mine. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 16 21:57:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29698 for ; Sun, 16 Jul 2000 21:57:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13DzeL-0009mO-00 for namedroppers-data@psg.com; Sun, 16 Jul 2000 18:24:49 -0700 Received: from dhcp-065076.wireless-conference.inet2000.gr.jp ([133.195.65.76] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13DzeK-0009mI-00 for namedroppers@ops.ietf.org; Sun, 16 Jul 2000 18:24:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13DzeJ-0000S7-00 for namedroppers@ops.ietf.org; Mon, 17 Jul 2000 10:24:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: =?iso-8859-1?Q?Mathias_K=F6rber?= To: "Masataka Ohta" , "[Mathias K_rber]" Cc: "Dan" , Subject: RE: What do you think about internationalisation of DNS? Date: Sun, 16 Jul 2000 09:41:29 +0800 Message-ID: In-reply-to: <200007151723.CAA04452@necom830.hpcl.titech.ac.jp> Importance: Normal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Sunday, July 16, 2000 1:24 AM > That's why it is just an localization. Which is why it's wrong. > > I *do* think that an extension to Latin-1 would be a good thing, > > *YOU* do think so, of course. :-) I do, because Latin-1 covers a lot of languages, I believe more languages than any other system of script. But I did point out that I consider it not a big problem if this did not happen, as transliterations exist for many of these languages, as well a others. > > Seriously speaking, Latin-1 is utterly broken. Introduction of soft > hypen in Latin-1 completely breaks DNS. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 16 21:57:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29716 for ; Sun, 16 Jul 2000 21:57:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13DzeY-0009mX-00 for namedroppers-data@psg.com; Sun, 16 Jul 2000 18:25:02 -0700 Received: from dhcp-065076.wireless-conference.inet2000.gr.jp ([133.195.65.76] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13DzeX-0009mR-00 for namedroppers@ops.ietf.org; Sun, 16 Jul 2000 18:25:02 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13DzeW-0000S9-00 for namedroppers@ops.ietf.org; Mon, 17 Jul 2000 10:25:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From: =?iso-8859-1?Q?Mathias_K=F6rber?= To: "James Seng" , =?iso-8859-1?Q?Mathias_K=F6rber?= Cc: "Dan" , Subject: RE: What do you think about internationalisation of DNS? Date: Sun, 16 Jul 2000 09:42:03 +0800 Message-ID: In-reply-to: <3970FC7D.FAD21C98@pobox.org.sg> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I think I know the intention quite well. I think it is only a bit misguided and a step in the wrong direction. You seem not to understand the use of examples to illustrate principles (in this case problems the majority of people will have to recognize, understand, distinguish and be able to use domainnames in languages in scripts totally foreignto them I think I18N in the DNS will in the long run prove a step in the wrong direction.. Get a clue, learn some discussion culture. > -----Original Message----- > From: James Seng [mailto:jseng@pobox.org.sg] > Sent: Sunday, July 16, 2000 8:06 AM > To: Mathias Körber > Cc: Dan; namedroppers@ops.ietf.org > Subject: Re: What do you think about internationalisation of DNS? > > > > You have misunderstood the intention of I18N of DNS. > > 1. get a clue. The world don't revolve around you. > > 2. the target audience for IDN is for non-English speaker, and once > again not for you. > > > -James Seng > > Mathias Körber wrote: > > > > I elieve DNS INternationlaization may be at firstimpression > > a worthy goal, but will in the long term only lead to > > nationalization or regionalization of the NEt, or (if we're > > lucky) fail and people willfall back again on ASCII. > > > > While it allows many people in the world who don't use > > ASCII only character sets to use name in their languages and scripts > > in their Internet addresses, it will restrict the actual use of those > > addresses to those who can > > a) somewhat understand/distingush them from others > > b) enter them > > > > As a German living and working in Singapore, I have after 10 years not > > mastered the Chinese script a single bit. I cannot distinguish > > between many characters (most look the same to me), let alone > > type them in. > > > > If I got email from someone with a Chinese only name, I would > have to save > > that address in my address book, and use some private indicator > > distingushing the name. (I would most likely use his romanized > > name if I knew that, or write something like 'Zhang from '. > > > > But private address books etc are not going to cut it in the > long term, as > > they would overflow with entries if everyone;s email address > had to be saved > > to be available later for cut and paste... > > > > In ASCII, I can remenmber (and easily enter) email addresses, > webpages, even > > if I have them in paperform, saw the, on TV etc. With a URL in Chinese, > > Japanese, Mongolian or Thai, it would be impossible for me. > > > > I *do* think that an extension to Latin-1 would be a good thing, as many > > languages can be covered by that, which share a large amount of > characters > > with ASCII, but have *some* own characters. But even there, > most languages > > have accepted and agreed upon transliterations for those > special characters > > (in Gernan: ö -> oe etc), that it does not matter very much. > > > > Even other languagas that do not have anything in common with > the ASCII or > > Latin-1 based scripts have transliterations (eg Hanyu Pinyin > for Chinese), > > which many native speakers/readers/riters of those languages > already learn, > > that ASCII still makes for the most usefulk common ground. > > > > As such I think that I18N in the DNS would be a step in the > wrong direction, > > as it would pave the way for countries and whole regions to > isolate their > > Internet presence into their regional cultural zone, rather > than opening up > > ways of communications by using a simple, widely available and > understood > > common ground, ASCII (or Latin-1) > > > > Mathias > > > > > -----Original Message----- > > > From: owner-namedroppers@ops.ietf.org > > > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Dan > > > Sent: Saturday, July 15, 2000 6:42 PM > > > To: namedroppers@ops.ietf.org > > > Subject: What do you think about internationalisation of DNS? > > > > > > > > > Hi > > > > > > The IDN working group have been discussing the requirements for > > > non-ASCII domain names for a while now. Below is the annoucement > > > for one draft with a way to handle non-ASCII domain names in DNS. > > > > > > I am very interested in hearing your comments on it. > > > The goal of it is to add non-ASCII domain names in > > > a controlled manner so it can work together with the > > > DNS servers that do not know about non-ASCII names and with software > > > that only expect ASCII in names. And still be possible to start > > > using immedately without any large query overhead. > > > To be able to do this, the DNS server must be able to identify > > > queries coming from non-ASCII aware clients. > > > > > > The draft includes both the (as I see it) best choice, and some > > > alternatives to help the discussion. > > > > > > Regards, > > > > > > Dan > > > > > > > > > --- > > > 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 : Using the Universal Character Set in the > > > Domain Name > > > System (UDNS) > > > Author(s) : D. Oscarsson > > > Filename : draft-ietf-idn-udns-00.txt > > > Pages : 16 > > > Date : 10-Jul-00 > > > > > > Since the Domain Name System (DNS) [RFC1035] was created there have > > > been a desire to use other characters than ASCII in domain names. > > > Lately this desire have grown very strong and several groups have > > > started to experiment with non-ASCII names. > > > By using the Universal Character Set (UCS) [ISO10646] this document > > > updates the Domain Name System so that non-ASCII domain names can be > > > used while still being compatible with the current (RFC 1035) DNS. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-idn-udns-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-udns-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-udns-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. > > > > > > > > > > > > > > > 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. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 16 21:59:13 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00023 for ; Sun, 16 Jul 2000 21:59:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13DzdB-0009lx-00 for namedroppers-data@psg.com; Sun, 16 Jul 2000 18:23:37 -0700 Received: from dhcp-065076.wireless-conference.inet2000.gr.jp ([133.195.65.76] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13DzdA-0009lq-00 for namedroppers@ops.ietf.org; Sun, 16 Jul 2000 18:23:36 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Dzd7-0000S1-00 for namedroppers@ops.ietf.org; Mon, 17 Jul 2000 10:23:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3970FC7D.FAD21C98@pobox.org.sg> Date: Sun, 16 Jul 2000 08:06:21 +0800 From: James Seng To: Mathias =?iso-8859-1?Q?K=F6rber?= CC: Dan , namedroppers@ops.ietf.org Subject: Re: What do you think about internationalisation of DNS? References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit You have misunderstood the intention of I18N of DNS. 1. get a clue. The world don't revolve around you. 2. the target audience for IDN is for non-English speaker, and once again not for you. -James Seng Mathias Körber wrote: > > I elieve DNS INternationlaization may be at firstimpression > a worthy goal, but will in the long term only lead to > nationalization or regionalization of the NEt, or (if we're > lucky) fail and people willfall back again on ASCII. > > While it allows many people in the world who don't use > ASCII only character sets to use name in their languages and scripts > in their Internet addresses, it will restrict the actual use of those > addresses to those who can > a) somewhat understand/distingush them from others > b) enter them > > As a German living and working in Singapore, I have after 10 years not > mastered the Chinese script a single bit. I cannot distinguish > between many characters (most look the same to me), let alone > type them in. > > If I got email from someone with a Chinese only name, I would have to save > that address in my address book, and use some private indicator > distingushing the name. (I would most likely use his romanized > name if I knew that, or write something like 'Zhang from '. > > But private address books etc are not going to cut it in the long term, as > they would overflow with entries if everyone;s email address had to be saved > to be available later for cut and paste... > > In ASCII, I can remenmber (and easily enter) email addresses, webpages, even > if I have them in paperform, saw the, on TV etc. With a URL in Chinese, > Japanese, Mongolian or Thai, it would be impossible for me. > > I *do* think that an extension to Latin-1 would be a good thing, as many > languages can be covered by that, which share a large amount of characters > with ASCII, but have *some* own characters. But even there, most languages > have accepted and agreed upon transliterations for those special characters > (in Gernan: ö -> oe etc), that it does not matter very much. > > Even other languagas that do not have anything in common with the ASCII or > Latin-1 based scripts have transliterations (eg Hanyu Pinyin for Chinese), > which many native speakers/readers/riters of those languages already learn, > that ASCII still makes for the most usefulk common ground. > > As such I think that I18N in the DNS would be a step in the wrong direction, > as it would pave the way for countries and whole regions to isolate their > Internet presence into their regional cultural zone, rather than opening up > ways of communications by using a simple, widely available and understood > common ground, ASCII (or Latin-1) > > Mathias > > > -----Original Message----- > > From: owner-namedroppers@ops.ietf.org > > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Dan > > Sent: Saturday, July 15, 2000 6:42 PM > > To: namedroppers@ops.ietf.org > > Subject: What do you think about internationalisation of DNS? > > > > > > Hi > > > > The IDN working group have been discussing the requirements for > > non-ASCII domain names for a while now. Below is the annoucement > > for one draft with a way to handle non-ASCII domain names in DNS. > > > > I am very interested in hearing your comments on it. > > The goal of it is to add non-ASCII domain names in > > a controlled manner so it can work together with the > > DNS servers that do not know about non-ASCII names and with software > > that only expect ASCII in names. And still be possible to start > > using immedately without any large query overhead. > > To be able to do this, the DNS server must be able to identify > > queries coming from non-ASCII aware clients. > > > > The draft includes both the (as I see it) best choice, and some > > alternatives to help the discussion. > > > > Regards, > > > > Dan > > > > > > --- > > 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 : Using the Universal Character Set in the > > Domain Name > > System (UDNS) > > Author(s) : D. Oscarsson > > Filename : draft-ietf-idn-udns-00.txt > > Pages : 16 > > Date : 10-Jul-00 > > > > Since the Domain Name System (DNS) [RFC1035] was created there have > > been a desire to use other characters than ASCII in domain names. > > Lately this desire have grown very strong and several groups have > > started to experiment with non-ASCII names. > > By using the Universal Character Set (UCS) [ISO10646] this document > > updates the Domain Name System so that non-ASCII domain names can be > > used while still being compatible with the current (RFC 1035) DNS. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-idn-udns-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-udns-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-udns-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. > > > > > > > > > > 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. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 16 22:00:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00377 for ; Sun, 16 Jul 2000 22:00:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Dzoc-0009ti-00 for namedroppers-data@psg.com; Sun, 16 Jul 2000 18:35:26 -0700 Received: from dhcp-065076.wireless-conference.inet2000.gr.jp ([133.195.65.76] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13Dzob-0009tc-00 for namedroppers@ops.ietf.org; Sun, 16 Jul 2000 18:35:25 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Dzoa-0000Se-00 for namedroppers@ops.ietf.org; Mon, 17 Jul 2000 10:35:24 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From: =?iso-8859-1?Q?Mathias_K=F6rber?= To: "James Seng" , =?iso-8859-1?Q?Mathias_K=F6rber?= Cc: "Dan" , Subject: RE: What do you think about internationalisation of DNS? Date: Sun, 16 Jul 2000 16:44:38 +0800 Message-ID: In-reply-to: <3971746A.2EA78663@pobox.org.sg> Importance: Normal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ ok kiddies. unless there are actual technical contributions, this is the last post on this thread i will approve. -- randy ] Nice flames James, as you are working for a company whose whole business plan hands on I18S of the DNS, I did not expect you to be open for dissenting voices. I was right. > -----Original Message----- > From: James Seng [mailto:jseng@pobox.org.sg] > Sent: Sunday, July 16, 2000 4:38 PM > To: Mathias Körber > Cc: Dan; namedroppers@ops.ietf.org > Subject: Re: What do you think about internationalisation of DNS? > > > Mathias Körber wrote: > > > > You seem not to understand the use of examples to illustrate > > principles (in this case problems the majority of people will > > have to recognize, understand, distinguish and be able to use > > domainnames in languages in scripts totally foreignto them > > > > You dont seem to get the idea. > > IF you cant read or type the URL or Email address, then obvious you are > not going to able to read or understand the Website or the Email you > receiving anyway. > > So it is not about _YOU_, it is about _OTHERS_ who need the non-English > system. > > There will and always will be people like who thinks they are center of > the world and it is okay to force everyone else to learn English to > accommodate their need. So I hardly see a need to continue this argument > with you. > > -James Seng > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 16 22:38:48 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29699 for ; Sun, 16 Jul 2000 21:57:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13DznY-0009t4-00 for namedroppers-data@psg.com; Sun, 16 Jul 2000 18:34:20 -0700 Received: from dhcp-065076.wireless-conference.inet2000.gr.jp ([133.195.65.76] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13DznY-0009sy-00 for namedroppers@ops.ietf.org; Sun, 16 Jul 2000 18:34:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13DznX-0000Sb-00 for namedroppers@ops.ietf.org; Mon, 17 Jul 2000 10:34:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3971746A.2EA78663@pobox.org.sg> Date: Sun, 16 Jul 2000 16:38:02 +0800 From: James Seng To: Mathias =?iso-8859-1?Q?K=F6rber?= CC: Dan , namedroppers@ops.ietf.org Subject: Re: What do you think about internationalisation of DNS? References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Mathias Körber wrote: > > You seem not to understand the use of examples to illustrate > principles (in this case problems the majority of people will > have to recognize, understand, distinguish and be able to use > domainnames in languages in scripts totally foreignto them > You dont seem to get the idea. IF you cant read or type the URL or Email address, then obvious you are not going to able to read or understand the Website or the Email you receiving anyway. So it is not about _YOU_, it is about _OTHERS_ who need the non-English system. There will and always will be people like who thinks they are center of the world and it is okay to force everyone else to learn English to accommodate their need. So I hardly see a need to continue this argument with you. -James Seng to unsubscribe send a message to 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 Jul 18 17:19:20 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26401 for ; Tue, 18 Jul 2000 17:19:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Ee7o-0004Tm-00 for namedroppers-data@psg.com; Tue, 18 Jul 2000 13:37:56 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13Ee7n-0004Td-00 for namedroppers@ops.ietf.org; Tue, 18 Jul 2000 13:37:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13Ee7l-0000r4-00 for namedroppers@ops.ietf.org; Wed, 19 Jul 2000 05:37:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.2.0.58.J.20000718162239.03063220@sh.w3.mag.keio.ac.jp> Date: Tue, 18 Jul 2000 16:24:26 +0900 To: Masataka Ohta , "[Mathias K_rber]" From: "Martin J. Duerst" Subject: Re: What do you think about internationalisation of DNS? Cc: Dan , namedroppers@ops.ietf.org In-Reply-To: <200007151723.CAA04452@necom830.hpcl.titech.ac.jp> References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 00/07/16 02:22 +0859, Masataka Ohta wrote: >Mathias; > > > I *do* think that an extension to Latin-1 would be a good thing, > >*YOU* do think so, of course. :-) > >Seriously speaking, Latin-1 is utterly broken. Introduction of soft >hypen in Latin-1 completely breaks DNS. Interesting. Can you be more specific? What exactly is the problem with soft hyphen? Can it be avoided if it is excluded from DNS names? Are there any other such characters, in Latin-1 or elsewhere? Regards, Martin. to unsubscribe send a message to 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 Jul 18 17:19:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26663 for ; Tue, 18 Jul 2000 17:19:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13EeFY-0004cj-00 for namedroppers-data@psg.com; Tue, 18 Jul 2000 13:45:56 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13EeFW-0004cd-00 for namedroppers@ops.ietf.org; Tue, 18 Jul 2000 13:45:55 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13EeFV-0000rR-00 for namedroppers@ops.ietf.org; Wed, 19 Jul 2000 05:45:53 +0900 Message-Id: <200007181032.GAA12139@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-04.txt Date: Tue, 18 Jul 2000 06:32:29 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Secret Key Establishment for DNS (TKEY RR) Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tkey-04.txt Pages : 17 Date : 17-Jul-00 [RFC 2845] 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-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-tkey-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-tkey-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000717145323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tkey-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tkey-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717145323.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 Jul 18 17:27:42 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00052 for ; Tue, 18 Jul 2000 17:27:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13EeAf-0004XD-00 for namedroppers-data@psg.com; Tue, 18 Jul 2000 13:40:53 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13EeAd-0004X4-00 for namedroppers@ops.ietf.org; Tue, 18 Jul 2000 13:40:51 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13EeAc-0000rB-00 for namedroppers@ops.ietf.org; Wed, 19 Jul 2000 05:40:50 +0900 Message-Id: <4.2.0.58.J.20000718162602.030bb3d0@sh.w3.mag.keio.ac.jp> Date: Tue, 18 Jul 2000 17:31:19 +0900 To: Mathias K=?ISO-2022-JP?B?GyRCi1MbKEI=?=ber , "Dan" , From: "Martin J. Duerst" Subject: RE: What do you think about internationalisation of DNS? In-Reply-To: References: <200007151042.e6FAgR900668@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ this needs to be moved to the idn mailing list, idn@ops.ietf.org -- randy ] Hello Mathias, At 00/07/15 23:34 +0800, Mathias K$B‹S(Bber wrote: >I elieve DNS INternationlaization may be at firstimpression >a worthy goal, but will in the long term only lead to >nationalization or regionalization of the NEt, Well, the net is to a large part already nationalized or regionalized. Most of the content is in a particular language, and not everybody can read the language. And this is not just so for the net, it's so for the rest of the world. As much as we would like, and hope, computer technology hasn't yet reached the breakthrough in machine translation that would make this problem go away. If we accept the fact that contents (web pages, email) is in various languages, and I hope you accept this, then we have to think about how to make it easy for people to find this content. There are a lot of ways to do that. Search engines and directories for various languages already abound and show a clear need. >While it allows many people in the world who don't use >ASCII only character sets to use name in their languages and scripts >in their Internet addresses, it will restrict the actual use of those >addresses to those who can > a) somewhat understand/distingush them from others > b) enter them Yes indeed. But is that a problem? As you may have noticed (I'm not sure about Singapore, though), in countries with a non-latin script, mail addresses on letters and packages are in that script as long as it's assumed that both parties can handle that. This has very clear benefits on various levels; among else, it's easier not to misspell the address, it's easier for people to remember it, it's easier for the workers in the mail service to not make errors, and the recipient feels personally addressed. In cases where this does not work, a Latin-based address can always be used. >As a German living and working in Singapore, I have after 10 years not >mastered the Chinese script a single bit. I cannot distinguish >between many characters (most look the same to me), let alone >type them in. It's a lot of work. It's a lot of work, too, for many people to learn English, even if there are many fewer characters. English orthography isn't that straightforward at all, and is often very helpful when typing in an address. Also, as a Swiss in Japan, with the ability to speak and read Japanese (and write when I use a computer or dictionary), I became aware of the fact that the difference that is probably most difficult to overcome is not to learn characters, but to get up to full speed. You have spent thousands of hours, in school and later, looking at Latin script. Compared to that, somebody in China or Japan has done that for maybe only 1% of your time. On a billboard with a lot of Chinese and some Latin, you immediately look at the Latin, while they more or less ignore it. Given the problem of having to search a word on a page of text, I'm sure Chinese and Japanese perform significantly slower with Latin text (I would guess something like 3 times slower). It's the same the other way round (for those of us who can read Chinese or Japanese). So for many people, it's not a question of whether they know Latin characters or not, it's a question of whether they can work at full speed or not. >If I got email from someone with a Chinese only name, I would have to save >that address in my address book, and use some private indicator >distingushing the name. (I would most likely use his romanized >name if I knew that, or write something like 'Zhang from '. It's rather easy to get an MUA to check what language is sent out, and choose from a list of addresses for the sender the appropriate address. This is similar to what people do on their own when they send out a letter or a package. Of course current emailers don't do that, but future ones will. >But private address books etc are not going to cut it in the long term, as >they would overflow with entries if everyone;s email address had to be saved >to be available later for cut and paste... For most of the mails I get, I don't put recipients in my address book, but just file the mail somewhere. And I just use reply (with a changed subject) to get back to that person. That would work in that case, too, but as explained above, we should never get there. >In ASCII, I can remenmber (and easily enter) email addresses, webpages, even >if I have them in paperform, saw the, on TV etc. With a URL in Chinese, >Japanese, Mongolian or Thai, it would be impossible for me. Yes indeed. It's just the other way round for Japanese, Chinese, Mongolians, or Thai. It may seem impossible to you that one of these scripts is easier to work with than Latin, but script efficiency depends to a very high percentage (probably 95%) on 'getting used to it, and getting used to it a lot, and early on in your life', and only for a very small percentage on what we would call engineering design. As an example you might be more familiar with, what about the Blackletter/Fraktur (usually also called Gotisch) style of printing that was used in Germany maybe up to the generation of your grandmother? We now have serious difficulties to imagine that people used to it found that easier to read than the current 'Antiqua' style, but that was indeed the case. Of course, such things may very well translate into sales figures at the end of the day. And I guess there are many cases where e.g. a Chinese company won't mind not doing business with a few expatriates if they get a better buyin from their Chinese customers. And if they still want to market to expatriates, or abroad, they can always provide an ASCII equivalent host name for their site, or can set up a site in English (or German, French,...). >I *do* think that an extension to Latin-1 would be a good thing, as many >languages can be covered by that, which share a large amount of characters >with ASCII, but have *some* own characters. But even there, most languages >have accepted and agreed upon transliterations for those special characters >(in Gernan: $B‹(B-> oe etc), that it does not matter very much. Latin-1 would indeed cover quite a few languages, but not those that need it most. German/French/Spanish/...-speaking people are used to the Latin script, and therefore have much less difficulties with ASCII than people from Asia used to different scripts. Also, as you say, for example for German, transliteration is rather easy, but for languages written with other scripts, it's not at all. As an example, the electronics company Toshiba writes itself Toshiba in Latin, and that's what they use as a domain name, but the official transcription is something like 'To^siba' (the ^ going on the 'o'), what many Japanese type in when they input the Kanji is 'toushiba', if you want to come close in pronunciation, it's maybe Tohshiba, for German, it would be Tohschiba, and so on. And similar for many other languages and companies. With Kanji, there are no such problems at all. >Even other languagas that do not have anything in common with the ASCII or >Latin-1 based scripts have transliterations (eg Hanyu Pinyin for Chinese), >which many native speakers/readers/riters of those languages already learn, >that ASCII still makes for the most usefulk common ground. First, Pinyin comes with accents not being part of ASCII. Second, many people in the southern regions of China have problems with Pinyin, because it's based on the standard Beijing dialect. Third, it can happen (in particular when you remove the accents) that several names are collapsed into a single one. Fourth, while pinyin is learned in school, it's just tought at a certain grade, but not widely and regularly practiced. That means that the efficiency arguments I made above fully apply. >As such I think that I18N in the DNS would be a step in the wrong direction, >as it would pave the way for countries and whole regions to isolate their >Internet presence into their regional cultural zone, rather than opening up >ways of communications by using a simple, widely available and understood >common ground, ASCII (or Latin-1) Latin-1 is definitely not a common ground, although in some regions of the world, some people might get that impression. And the question is not isolation or opening up, it's how to open up while being efficient by being able to keep well-learned conventions as long as they don't bother anybody else. Would the fact that some Chinese use Chinese domain names for Chinese web sites bother you, if that web site also has an ASCII-only address? In conclusion, I think there are some potential problems, but they are minor, and easy to address, and nothing that people aren't familiar with from other experiences in their daily life. On the other hand, there are quite some advantages for a lot of people, not so much with respect to can vs. cannot, but can with ease vs. can with (serious) difficulties. Regards, Martin. to unsubscribe send a message to 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 Jul 18 18:13:53 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18923 for ; Tue, 18 Jul 2000 18:13:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13EewG-0005cx-00 for namedroppers-data@psg.com; Tue, 18 Jul 2000 14:30:04 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13EewE-0005cp-00 for namedroppers@ops.ietf.org; Tue, 18 Jul 2000 14:30:02 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13EewC-0000v2-00 for namedroppers@ops.ietf.org; Wed, 19 Jul 2000 06:30:00 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 18 Jul 2000 12:01:20 -0700 (PDT) Message-Id: <200007181901.e6IJ1Kb24821@trebuchet.rc.vix.com> From: Andreas Gustafsson To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-axfr-clarify-01.txt Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I was planning to update the axfr-clarify draft before Pittsburgh, but due to a misunderstanding on my part, I missed the publication deadline. At Olafur's request, I'm sending the attached copy of the updated draft (not yet officially published as an I-D) to namedroppers. The changes from the -00 draft are minor: - Two bits in the flags field are now referred to using their new DNSSEC names "AD" and "CD" rather than being part of the "Z" field. - A "Security Considerations" section has been added. -- Andreas Gustafsson, gson@nominum.com INTERNET-DRAFT Andreas Gustafsson draft-ietf-dnsext-axfr-clarify-01.txt Nominum Inc. July 2000 DNS Zone Transfer Protocol Clarifications Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In the Domain Name System, zone data is replicated among authoritative DNS servers by means of the "zone transfer" protocol, also known as the "AXFR" protocol. This memo clarifies, updates, and adds missing detail to the original AXFR protocol specification in RFC1034. 1. Introduction The original definition of the DNS zone transfer protocol consists of a single paragraph in [RFC1034] section 4.3.5 and some additional notes in [RFC1035] section 6.3. It is not sufficiently detailed to serve as the sole basis for constructing interoperable implementations. This document is an attempt to provide a more complete definition of the protocol. Where the text in RFC1034 conflicts with existing practice, the existing practice has been codified in the interest of interoperability. Expires January 2000 [Page 1] draft-ietf-dnsext-axfr-clarify-01.txt July 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. The zone transfer request To initiate a zone transfer, the slave server sends a zone transfer request to the master server over a reliable transport such as TCP. The form of this request is specified in sufficient detail in RFC1034 and needs no further clarification. 3. The zone transfer response If the master server is unable or unwilling to provide a zone transfer, it MUST respond with a single DNS message containing an appropriate RCODE other than NOERROR. If a zone transfer can be provided, the master server sends one or more DNS messages containing the zone data as described below. 3.1. Multiple answers per message The zone data in a zone transfer response is a sequence of answer RRs. These RRs are transmitted in the answer section(s) of one or more DNS response messages. The AXFR protocol definition in RFC1034 does not make a clear distinction between response messages and answer RRs. Historically, DNS servers always transmitted a single answer RR per message. This encoding is wasteful due to the overhead of repeatedly sending DNS message headers and the loss of domain name compression opportunities. To improve efficiency, some newer servers support a mode where multiple RRs are transmitted in a single DNS response message. A master MAY transmit multiple answer RRs per response message up to the largest number that will fit within the 65535 byte limit on TCP DNS message size. In the case of a small zone, this can cause the entire transfer to be transmitted in a single response message. Slaves MUST accept messages containing any number of answer RRs. For compatibility with old slaves, masters that support sending multiple answers per message SHOULD be configurable to revert to the historical mode of one answer per message, and the configuration SHOULD be settable on a per-slave basis. 3.2. DNS message header contents Expires January 2000 [Page 2] draft-ietf-dnsext-axfr-clarify-01.txt July 2000 RFC1034 does not specify the contents of the DNS message header of the zone transfer response messages. The header of each message MUST be as follows: ID Copy from request QR 1 OPCODE QUERY AA 1 (but MAY be 0 when RCODE is nonzero) TC 0 RD Copy from request RA Set according to availability of recursion Z 0 AD 0 CD 0 RCODE 0 or error code The slave MUST check the RCODE and abort the transfer if it is nonzero. It SHOULD check the ID of the first message received and abort the transfer if it does not match the ID of the request. The ID SHOULD be ignored in subsequent messages, and fields other than RCODE and ID SHOULD be ignored in all messages, to ensure interoperability with certain older implementations which transmit incorrect or arbitrary values in these fields. 3.3. Additional section and SIG processing Zone transfer responses are not subject to any kind of additional section processing or automatic inclusion of SIG records. SIG RRs in the zone data are treated exactly the same as any other RR type. 3.4. The question section RFC1034 does not specify whether zone transfer response messages have a question section or not. The initial message of a zone transfer response SHOULD have a question section identical to that in the request. Subsequent messages SHOULD NOT have a question section, though the final message MAY. The receiving slave server MUST accept any combination of messages with and without a question section. 3.5. The authority section The master server MUST transmit messages with an empty authority section. Slaves MUST ignore any authority section contents they may receive from masters that do not comply with this requirement. 3.6. The additional section The additional section MAY contain additional RRs such as transaction Expires January 2000 [Page 3] draft-ietf-dnsext-axfr-clarify-01.txt July 2000 signatures. The slave MUST ignore any unexpected RRs in the additional section. 4. Glue Zone transfers MAY contain glue RRs pertaining to NS records in the zone. An RR is considered a glue RR when it is not within the zone being transferred. A slave MUST recognize glue RRs as such; it MUST NOT treat them as authoritative data. Note that classifying an RR as glue or non-glue may not be possible until the entire zone has been received so that the zone cuts defined by the zone's NS records can be determined. 5. Transmission order RFC1034 states that "The first and last messages must contain the data for the top authoritative node of the zone". This is not consistent with existing practice. All known master implementations send, and slave implementations expect to receive, the zone's SOA RR as the first and last record of the transfer. Any other RRs at the zone's apex are transmitted only once. Therefore, the quoted sentence is hereby changed to read "The first and last RR transmitted must be the SOA record of the zone". The initial and final SOA record MUST be identical, with the possible exception of case and compression. In particular, they MUST have the same serial number. The transmission order of all other RRs in the zone, including glue records, is undefined. 6. Security Considerations The zone transfer protocol as defined in [RFC1034] and clarified by this memo does not have a built-in authentication mechanism. The use of TSIG [RFC2845] for authentication of zone transfers is recommended. These clarifications are not believed to themselves cause any new security problems, nor to solve any existing ones. References [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, November 1987. Expires January 2000 [Page 4] draft-ietf-dnsext-axfr-clarify-01.txt July 2000 [RFC1035] - Domain Names - Implementation and Specifications, P. Mockapetris, November 1987. [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, BCP 14, March 1997. [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. Author's Address Andreas Gustafsson Nominum Inc. 950 Charter Street Redwood City, CA 94063 USA Phone: +1 650 779 6004 Email: gson@nominum.com Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF Expires January 2000 [Page 5] draft-ietf-dnsext-axfr-clarify-01.txt July 2000 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expires January 2000 [Page 6] to unsubscribe send a message to 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 Jul 19 18:55:00 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18429 for ; Wed, 19 Jul 2000 18:54:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13F1t8-000POr-00 for namedroppers-data@psg.com; Wed, 19 Jul 2000 15:00:22 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13F1t7-000POl-00 for namedroppers@ops.ietf.org; Wed, 19 Jul 2000 15:00:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13F1t5-0001bv-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 07:00:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007191911.VAA11219@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Andreas Gustafsson Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt In-reply-to: Your message of "Tue, 18 Jul 2000 12:01:20 PDT." <200007181901.e6IJ1Kb24821@trebuchet.rc.vix.com> Date: Wed, 19 Jul 2000 21:11:05 +0200 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 4. Glue > > Zone transfers MAY contain glue RRs pertaining to NS records in the For the ``real'' glue, this should be a MUST. > zone. An RR is considered a glue RR when it is not within the zone > being transferred. A slave MUST recognize glue RRs as such; it MUST > NOT treat them as authoritative data. The latter would be very easy were glue RRs sent in the additional section, but that's not backwards compatible. Should the document explicitly say that the glue RRs belong into the answer section? A problem with very large zones, such as certain TLDs, is the frequent repetition of (sometimes even unnecessary) glue RRs, which increases the amount of data to transfer. Even in the light of SIG RRs - do you see a chance for recommending an optimization here? > 6. Security Considerations > > The zone transfer protocol as defined in [RFC1034] and clarified by > this memo does not have a built-in authentication mechanism. The use > of TSIG [RFC2845] for authentication of zone transfers is > recommended. It's clear that the source of data should be authenticated, but this recommendation could easily be (mis?)read to suggest to allow AXFR only to authenticated requestors. Whether or not one likes that advice, and I don't, this is probably the wrong place for it. In addition I'd suggest to insert "and integrity" after "authentication". -Peter to unsubscribe send a message to 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 Jul 19 22:59:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14822 for ; Wed, 19 Jul 2000 22:59:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13F67p-0001QS-00 for namedroppers-data@psg.com; Wed, 19 Jul 2000 19:31:49 -0700 Received: from dhcp-065076.wireless-conference.inet2000.gr.jp ([133.195.65.76] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13F67n-0001QM-00 for namedroppers@ops.ietf.org; Wed, 19 Jul 2000 19:31:48 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13F4xr-0001q3-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 10:17:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3976506D.78B9C9D3@ehsco.com> Date: Wed, 19 Jul 2000 18:05:49 -0700 From: "Eric A. Hall" To: Andreas Gustafsson CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt References: <200007181901.e6IJ1Kb24821@trebuchet.rc.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 3.1. Multiple answers per message > A master MAY transmit multiple answer RRs per response message up to > the largest number that will fit within the 65535 byte limit on TCP > DNS message size. In the case of a small zone, this can cause the > entire transfer to be transmitted in a single response message. In general I agree with this. It's smart, although it's also potentially problematic in multiple scenarios. > Slaves MUST accept messages containing any number of answer RRs. For > compatibility with old slaves, masters that support sending multiple > answers per message SHOULD be configurable to revert to the > historical mode of one answer per message, and the configuration > SHOULD be settable on a per-slave basis. Isn't there something that can be done with the flags to signify that this should occur in-protocol? Like, since AXFR is a targeted send over a TCP circuit, we *KNOW* that the flag isn't going to be useful. We also know that several RESPONSE flags aren't going to be set in the query. Couldn't we say something like: "if RD, RA and AA are set in the query, the slave desires the compressed form". Wouldn't that be the best approach instead of relying on manual configs that may be outside the scope of control of a single administrator? It would also allow heterogenous multi-tiered distributions to be implemented without having to worry about what product supports what feature. NetWare 6 do it? Who cares, the proto takes care of all that. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 20 05:26:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07460 for ; Thu, 20 Jul 2000 05:26:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FBqk-0004X6-00 for namedroppers-data@psg.com; Thu, 20 Jul 2000 01:38:34 -0700 Received: from dhcp-065076.wireless-conference.inet2000.gr.jp ([133.195.65.76] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13FBqi-0004X0-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 01:38:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13FBqk-0001zI-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 17:38:34 +0900 Message-ID: <39768A2D.A74AEB5B@ehsco.com> Date: Wed, 19 Jul 2000 22:12:13 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Gustafsson CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt References: <200007181901.e6IJ1Kb24821@trebuchet.rc.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 4. Glue > > Zone transfers MAY contain glue RRs pertaining to NS records in the > zone. An RR is considered a glue RR when it is not within the zone > being transferred. A slave MUST recognize glue RRs as such; it MUST > NOT treat them as authoritative data. This seems problematic. Since glue data is by definition data which is outside the zone, including it in zone transfers not only wasteful but is also extremely dangerous. For example, let's say that somehow I've got my zone being served by www.yahoo.com. and just for safety's sake I have glue data in the ntrg.net. zone for that domain name. If I transfer the domain and the glue data goes with it, the recipient may cache it, use it for answers, or worse yet it may respond to requests for www.yahoo.com. with AA in the response messages (it comes from an authoritative source, so AA is possible and even likely). A subsequent danger is that my slaves are masters for other slaves who repeat this process. And because I have REFRESH of 1 week, this data is out and running around in all of those downstream servers for a few weeks until I wise up and remove the glue. I'd say that glue data MUST NOT be sent during a zone transfer UNLESS the glue points to a domain name that is within the scope of the domain for the zone being transferred. The server will know this during the transfer (it knows the scope of the zone and can filter on send easier than slaves can filter on receipt) so it shouldn't be a burden. Well worth the costs anyway if it stops bad data from floating around. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 20 13:32:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14496 for ; Thu, 20 Jul 2000 13:32:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FJcH-0008yX-00 for namedroppers-data@psg.com; Thu, 20 Jul 2000 09:56:09 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13FJcE-0008yQ-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 09:56:07 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13FJc5-00024s-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 01:55:57 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007201244.OAA11769@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Thu, 20 Jul 2000 14:44:28 +0200 To: lewis@tislabs.com, Domain Names WG Subject: Comments on draft-ietf-dnsext-zone-status-02 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > DNSEXT WG Edward Lewis > INTERNET DRAFT NAI Labs > Category:I-D July 12, 2000 > > DNS Security Extension Clarification on Zone Status > > .... > 1.1 When a Zone's Status is Important .... > A delegating zone is required to indicate whether a child zone is > secured. The reason for this requirement lies in the way in which a No. Only when the child zone is clueless, the delegating zone needs to indicate that the the child zone is unsecured. Otherwise, it is up to the child zone zone to indicate whether it is secure or unsecure. > resolver makes its own determination about a zone (next paragraph). To > shorten a long story, a parent needs to know whether a child should be > considered secured. This is a two part question, what does a parent > consider a secure child to be, and how does a parent know if the child > conforms? As soon as the child has declared to its parent that it will be carrying its own zone-KEY (or NULL-KEY), the parent removes the NULL-KEY for this child from its zonefile. It's from now on up to the child to conform. > A resolver needs to know if a zone is secured when the resolver is > processing data from the zone. Ultimately, a resolver needs to know > whether or not to expect a usable signature covering the data. How > this determination is done is out of the scope of this document, > except that, in some cases, the resolver will need to contact the > parent of the zone to see if the parent states that the child is > secured. No. If the parent is secured and no parent-signed NULL-KEY is encountered in the childs apex, the child must be secured as well. So, again, for a non-clueless child, it is the child, by having a zone-KEY or NULL-KEY in its zonefile, that states it is secured or unsecured. The parents zone is only consulted to verify the SIG over childs KEY, not whether it is a real zone-KEY or a NULL-KEY. > 1.2 Islands of Security .... > The popular term for the secured zones at or below subarea1 is an > "island of security." The only way in which a DNSSEC resolver will > come to trust any data from this island is if the resolver is > pre-configured with the zone key(s) for subarea1. ... I think it is important to note, that the resolver of interest must not only be pre-configured with zone keys, but also with the entry-point of such an island, as it does not get this info from the (unsecured) parent. Without this knowledge the island remains vulnarable for zone-hijacking. > pre-configured with the zone key(s) for subarea1. All other resolvers > will not recognize this island as secured. Agreed. > 1.3 Impact on RFC 2535 > 2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01 > for name type (indicating a zone key) and either value 00 or value 01 > for key type (indicating a key permitted to authenticate data). (See > RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value > of DNSSEC (3) or ALL (255). > > The definition updates RFC 2535's definition of a zone key. The > requirement that the protocol field be either DNSSEC or ALL is a new > requirement. This update seems unnecessary, see comments from Eastlake, Arends, and myself on previous drafts. > 2.c Off-tree Validation - Any authorization model that permits domain > names other than the parent's to provide a signature over a child's > zone keys that will enable a resolver to trust the keys. A remark could be added, that resolvers of interest must not only be able to use the alternative authorization model to verify the zone-KEY, but must also know exactly which zones to expect to be secured this way. > 2.1 Fully Secured A remark: from this definition, I conclude that: 1. RSA-signed zones are not Fully Secured 2. As long as the root is Unsecured, there is no zone can ever be Fully Secured at all. And therefore that we should aim for Private Security to start with, and perhaps forget about Full Security at all? > 2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC > 2535, section 2.3.2.) Note: there is some operational discomfort with Because this requirement is already in RFC 2535, this is not an update, but a clarification. > 2.1.d. Each RR set that qualifies for zone membership MUST be signed > by a key that is in the apex's KEY RR set and is a zone signing KEY RR > (2.a) of a mandatory to implement algorithm. (Updates 2535, section > 2.3.1.) Again, this requirement is already in RFC 2535, so this is not an update, but a clarification. > 2.2 Privately Secured Perhaps a remark or statement could be made, that the resolvers of interest must know exactly which zones to expect to be secured. With a handful of well-published islands of security, in which the verification chain internally follows the delegation tree, this seems possible to implement. But large numbers of random, off-tree signed zones seems rather impractible. > 2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC > 2535, section 2.3.2.) Note: see the discussion following 2.1.c. Again, this requirement is already in RFC 2535, so this is not an update, but a clarification. > 2.2.d. Each RR set that qualifies for zone membership MUST be signed > by a key that is in the apex's KEY RR set and is a zone signing KEY RR > (2.a). (Updates 2535, section 2.3.1.) Again, this requirement is already in RFC 2535, so this is not an update, but a clarification. Regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 20 13:32:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14495 for ; Thu, 20 Jul 2000 13:32:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FJXc-0008vC-00 for namedroppers-data@psg.com; Thu, 20 Jul 2000 09:51:20 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13FJXU-0008uw-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 09:51:13 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13FJXT-00024f-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 01:51:11 +0900 Date: Thu, 20 Jul 2000 12:36:45 +0200 (CEST) From: Roy Arends To: Edward Lewis cc: DNS Extensions WG Subject: Re: draft-ietf-dnsext-zone-status-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Comments by Roy Arends from NLnet Labs on the I-D DNS Security Extension Clarification on Zone Status July 12, 2000, by Edward Lewis. > 1.1 When a Zone's Status is Important A few times there is mentioning of "the parent states that the child is secured". The parent holds the KEY information to verify the parent's SIG over the child's KEY or null-KEY. Only in the case where a child is clueless, a parent states that the child is _not_ secure, by holding a signed NULL-key for the child in their zone. In all other cases, information on child-status in the parent zone is redundant. > 1.2 Islands of Security This clarification is very welcome. > 2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC > 2535, section 2.3.2.) As discussed in previous remarks, this update is not neccesary. The requirement is already there. This is a clarification, not an update. It does not change the protocol. > Note: there is some operational discomfort with > the current NXT record. This requirement is open to modification when > two things happen. First, an alternate mechanism to the NXT is > defined and second, a means by which a zone can indicate that it is > using an alternate method. This seems to point to section 3 & 4 which are deleted. > 2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC > 2535, section 2.3.2.) Note: see the discussion following 2.1.c. As mentioned at 2.1.c this update is not neccesary. As for 2.1.d and 2.2.d, the terms privately & fully secure are welcome when it comes to evaluating a zone's status (as mentioned in 2.4). For clarification purposes updating a proposed standard seems unnecessary. Regards, Roy Arends NLnet Labs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 20 13:49:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23513 for ; Thu, 20 Jul 2000 13:49:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FJrC-0009Bb-00 for namedroppers-data@psg.com; Thu, 20 Jul 2000 10:11:34 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13FJrA-0009BV-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 10:11:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13FJr9-00025f-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 02:11:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39772F41.5A60E526@ehsco.com> Date: Thu, 20 Jul 2000 09:56:33 -0700 From: "Eric A. Hall" To: Peter Koch CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt References: <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > For example, let's say that somehow I've got my zone being served by > > www.yahoo.com. and just for safety's sake I have glue data in the > > ntrg.net. zone for that domain name. If I transfer the domain and > This is not glue data but what usually becomes part of the additional > section. You cannot have a RR for www.yahoo.com *inside* ntrg.net. That's what I would like to see explicitly prohibited. > > I'd say that glue data MUST NOT be sent during a zone transfer > > UNLESS the glue points to a domain name that is within the scope > > of the domain > > What's the scope of the domain? Do you mean the subtree rooted at a > zone apex, i.e. that zone and all its subzones, if any? Then I'd > second your statement. Yes. Any data for www.yahoo.com. would be outside the subtree under ntrg.net. and would fall under the "MUST be filtered" rule by the server before axfr occurs. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 20 14:00:22 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14494 for ; Thu, 20 Jul 2000 13:32:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FJgX-00092b-00 for namedroppers-data@psg.com; Thu, 20 Jul 2000 10:00:33 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13FJgV-00092U-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 10:00:32 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13FJgU-000250-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 02:00:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 20 Jul 2000 07:05:31 -0700 (PDT) Message-Id: <200007201405.HAA22204@gulag.araneus.fi> To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt In-Reply-To: <200007191911.VAA11219@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200007181901.e6IJ1Kb24821@trebuchet.rc.vix.com> <200007191911.VAA11219@grimsvotn.TechFak.Uni-Bielefeld.DE> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Koch wrote: > > 4. Glue > > > > Zone transfers MAY contain glue RRs pertaining to NS records in the > > For the ``real'' glue, this should be a MUST. I agree that a MUST is reasonable here, but could you explain what you mean by "real" glue? > > zone. An RR is considered a glue RR when it is not within the zone > > being transferred. A slave MUST recognize glue RRs as such; it MUST > > NOT treat them as authoritative data. > > The latter would be very easy were glue RRs sent in the additional section, > but that's not backwards compatible. Right. If or when a new protocol is devised to replace AXFR, it should separate the glue from the authoritative data. > Should the document explicitly say that > the glue RRs belong into the answer section? Perhaps; I'll see if I can fit that in somewhere. > A problem with very large zones, such as certain TLDs, is the frequent > repetition of (sometimes even unnecessary) glue RRs, which increases the > amount of data to transfer. Even in the light of SIG RRs - do you see > a chance for recommending an optimization here? We could certainly add something like this: Each glue record SHOULD be transmitted only once, even if it its name occurs in multiple NS records. > > 6. Security Considerations > > > > The zone transfer protocol as defined in [RFC1034] and clarified by > > this memo does not have a built-in authentication mechanism. The use > > of TSIG [RFC2845] for authentication of zone transfers is > > recommended. > > It's clear that the source of data should be authenticated, but this > recommendation could easily be (mis?)read to suggest to allow AXFR only > to authenticated requestors. Good point. I will try to make it clearer that the issue is authenticating the source and integrity of the data, not restricting access to it. > In addition I'd suggest to insert "and integrity" after "authentication". Will do. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 20 14:00:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14490 for ; Thu, 20 Jul 2000 13:32:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FJaT-0008x1-00 for namedroppers-data@psg.com; Thu, 20 Jul 2000 09:54:17 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13FJaN-0008wu-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 09:54:12 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13FJaN-00024m-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 01:54:11 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> To: "Eric A. Hall" Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt In-reply-to: Your message of "Wed, 19 Jul 2000 22:12:13 PDT." <39768A2D.A74AEB5B@ehsco.com> Date: Thu, 20 Jul 2000 14:10:10 +0200 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This seems problematic. Since glue data is by definition data which is > outside the zone, including it in zone transfers not only wasteful but > is also extremely dangerous. Well, part of the problem is that this document provides for yet another not backwards compatible definition of "glue" RRs. At least from a teaching viewpoint this is suboptimal and that's why I mentioned the ``real'' glue in my previous message. > For example, let's say that somehow I've got my zone being served by > www.yahoo.com. and just for safety's sake I have glue data in the > ntrg.net. zone for that domain name. If I transfer the domain and the This is not glue data but what usually becomes part of the additional section. You cannot have a RR for www.yahoo.com *inside* ntrg.net. > glue data goes with it, the recipient may cache it, use it for answers, > or worse yet it may respond to requests for www.yahoo.com. with AA in > the response messages (it comes from an authoritative source, so AA is > possible and even likely). Andreas' document clearly states that this MUST NOT happen. But then, it's still not prohibited (and was practiced) to use this data (e.g. A RR for www.yahoo.com) in answers with never decreasing TTL. > A subsequent danger is that my slaves are masters for other slaves who > repeat this process. And because I have REFRESH of 1 week, this data is You're free to shoot yourself. That high a refresh timer and no NOTIFY is beyond current practice. > I'd say that glue data MUST NOT be sent during a zone transfer UNLESS > the glue points to a domain name that is within the scope of the domain What's the scope of the domain? Do you mean the subtree rooted at a zone apex, i.e. that zone and all its subzones, if any? Then I'd second your statement. > for the zone being transferred. The server will know this during the > transfer (it knows the scope of the zone and can filter on send easier > than slaves can filter on receipt) so it shouldn't be a burden. Well > worth the costs anyway if it stops bad data from floating around. Still you can't just forbid this at the master side without suggesting precautions at the slave side. Zone master servers are often operated by end customers, running old and sometimes strange software. You can't trust them doing it right. -Peter to unsubscribe send a message to 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 Jul 20 20:32:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03273 for ; Thu, 20 Jul 2000 20:32:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FQ13-000D3C-00 for namedroppers-data@psg.com; Thu, 20 Jul 2000 16:46:09 -0700 Received: from 210197100158.cidr.odn.ne.jp ([210.197.100.158] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13FQ12-000D2z-00 for namedroppers@ops.ietf.org; Thu, 20 Jul 2000 16:46:08 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13FQ10-0002L8-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 08:46:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 20 Jul 2000 11:41:18 -0700 (PDT) Message-Id: <200007201841.LAA22384@gulag.araneus.fi> To: "Eric A. Hall" CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt In-Reply-To: <3976506D.78B9C9D3@ehsco.com> References: <200007181901.e6IJ1Kb24821@trebuchet.rc.vix.com> <3976506D.78B9C9D3@ehsco.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Eric A. Hall" said: > > Slaves MUST accept messages containing any number of answer RRs. For > > compatibility with old slaves, masters that support sending multiple > > answers per message SHOULD be configurable to revert to the > > historical mode of one answer per message, and the configuration > > SHOULD be settable on a per-slave basis. > > Isn't there something that can be done with the flags to signify that > this should occur in-protocol? Like, since AXFR is a targeted send over > a TCP circuit, we *KNOW* that the flag isn't going to be useful. We also > know that several RESPONSE flags aren't going to be set in the query. > Couldn't we say something like: "if RD, RA and AA are set in the query, > the slave desires the compressed form". Something like this could (and probably should) have been done years ago when multi-answer messages were first introduced, but I don't think there's much point in doing it now. Also, the purpose of this draft is not to change the protocol but to document it in its existing form. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 21 22:19:25 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19408 for ; Fri, 21 Jul 2000 22:19:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FoJk-00033Y-00 for namedroppers-data@psg.com; Fri, 21 Jul 2000 18:43:04 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13FoJk-00033S-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 18:43:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13FoJj-0008YO-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 18:43:03 -0700 Message-Id: <200007211306.JAA07171@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-gss-tsig-00.txt Date: Fri, 21 Jul 2000 09:06:29 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : GSS Algorithm for TSIG (GSS-TSIG) Author(s) : S. Kwan, P. Garg, J. Gilroy, L. Esibov Filename : draft-ietf-dnsext-gss-tsig-00.txt Pages : 20 Date : 20-Jul-00 The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-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-gss-tsig-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-gss-tsig-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: <20000720141251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-gss-tsig-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-gss-tsig-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000720141251.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 Jul 21 22:20:19 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19703 for ; Fri, 21 Jul 2000 22:20:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FoEy-000300-00 for namedroppers-data@psg.com; Fri, 21 Jul 2000 18:38:08 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13FoEy-0002zu-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 18:38:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13FoEy-0008WM-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 18:38:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <200007201244.OAA11769@open.nlnetlabs.nl> Date: Fri, 21 Jul 2000 07:30:20 -0400 To: Ted.Lindgreen@tednet.nl From: Edward Lewis Subject: Re: Comments on draft-ietf-dnsext-zone-status-02 Cc: lewis@tislabs.com, Domain Names WG Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 8:44 AM -0400 7/20/00, Ted Lindgreen wrote: >> My Draft is double >'d ... >> A delegating zone is required to indicate whether a child zone is >> secured. The reason for this requirement lies in the way in which a > >No. Only when the child zone is clueless, the delegating zone needs >to indicate that the the child zone is unsecured. Otherwise, it is >up to the child zone zone to indicate whether it is secure or unsecure. I answered this in a message to Roy. "Stating" by being silent is still stating. It's like an appellate court refusing to hear an appeal of a lower court case - the appellate court is "saying" that the lower court verdict stands. ... >No. If the parent is secured and no parent-signed NULL-KEY is >encountered in the childs apex, the child must be secured >as well. Perhaps I should point out that in section 1 I am describing the functional requirements regarding the times at which I need to know the status of a zone, in particular during verification of a name resolution. What we are arguing is a requirement (stating the status) versus an implementaion (by not saying anything if secure). I believe you are looking at this from the perspective of the server. A few years back I wrote a resolver - which gives quite a different viewpoint of the DNSSEC process. If you had to slog through the resolver process you might see what I am describing. >> 1.3 Impact on RFC 2535 > >> 2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01 >> for name type (indicating a zone key) and either value 00 or value 01 >> for key type (indicating a key permitted to authenticate data). (See >> RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value >> of DNSSEC (3) or ALL (255). >> >> The definition updates RFC 2535's definition of a zone key. The >> requirement that the protocol field be either DNSSEC or ALL is a new >> requirement. > >This update seems unnecessary, see comments from Eastlake, Arends, >and myself on previous drafts. This update was offerred following consultation with implementers (i.e., folks other than myself). We (including myself) that it was just good programming practice to check the field. All known signers to date do this, so I thought it should be documented - lest some one want to reassign the field's meaning later only to find that antiquated signers would have a problem. >> 2.c Off-tree Validation - Any authorization model that permits domain ... > >A remark could be added, that resolvers of interest must not only >be able to use the alternative authorization model to verify the >zone-KEY, but must also know exactly which zones to expect to be >secured this way. This issue is a subject of a smoldering idea of mine. I've floated a few proposals over the years to address this - but the time for the proposal hasn't arisen. So I left that comment out. What is important is that RFC 2535 is all about resolver security. DNSSEC is entirely targeted at making the world safe for the resolver. Server's are at the mercy of what the resolver thinks. This observation is the motivation behind this draft - even if the server admin does everything to secure the zone the best that can be done, a resolver still might not see the zone as secure. > >> 2.1 Fully Secured > >A remark: from this definition, I conclude that: >1. RSA-signed zones are not Fully Secured >2. As long as the root is Unsecured, there is no zone can ever > be Fully Secured at all. >And therefore that we should aim for Private Security to start >with, and perhaps forget about Full Security at all? Your observations are correct. I wouldn't "forget" about Full Security, but just that we should know that until the root is fully secured and until RSA is declared a mandatory to implement algorithm, an RSA signed zone may not be judged to be secured by a minimally conforming resolver (i.e., one that only allows a root key configured and knows only the mandatory to implement algorithms). Recall that the difference between being "Fully" and "Privately" secured is just in name - a zone can switch from one to the other without moving a finger. E.g., you are set up and your parent (someone you don't control) changes from Privately to Fully - and therefore so do you. (Caveats abound.) >Again, this requirement is already in RFC 2535, so this is not an >update, but a clarification. Roy mentioned this... >> 2.2 Privately Secured > >Perhaps a remark or statement could be made, that the resolvers of >interest must know exactly which zones to expect to be secured. I'll address this part of your comment only - I've tried to float an idea here and it was mercilessly trashed. Although I believe the zone should be able to reveal to a resolver what the security parameters are ("I use NXT" vs. "I don't use NXT"), we don't have enough experience to develop a workable implementation of this. ... >Again, this requirement is already in RFC 2535, so this is not an >update, but a clarification. Hmmm - since this is so obviously an accurate statement, either I was brain fogged when I wrote this or there was some other intent when I wrote the text about which you comment. Either way, I'll need to address it. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 21 22:20:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19729 for ; Fri, 21 Jul 2000 22:20:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FoKG-00034D-00 for namedroppers-data@psg.com; Fri, 21 Jul 2000 18:43:36 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13FoKG-000347-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 18:43:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13FoKG-0008Yh-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 18:43:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007211326.JAA11941@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: Secret Key Establishment for DNS (TKEY RR) to Proposed Standard Date: Fri, 21 Jul 2000 09:26:52 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the following Internet-Drafts for publication as Proposed Standards: o Secret Key Establishment for DNS (TKEY RR) o DNS Request and Transaction Signatures ( SIG(0)s ) These documents are the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary TSIG 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. The TKEY 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. Extensions to the Domain Name System (DNS) are described in [RFC 2535] that can provide data origin and transaction integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Implementation experience has indicated the need for minor but non- interoperable changes in Request and Transaction signature resource records ( SIG(0)s ). These changes are documented in the SIG(0) document. Working Group Summary There was consensus in the WG to advance these documents. Protocol Quality The specifications have been reviewed for the IETF by Erik Nordmark. Note to RFC Editor: In both documents, the "References" sections need to be updated and edited: Change: draft-ietf-dnsext-tsig-*.txt - P. Vixie, O. Gudmundsson, D. Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". To: Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. Working Group Summary There was consensus in the WG to advance these documents. Protocol Quality The specifications have been reviewed for the IETF by Erik Nordmark. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 21 22:21:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19990 for ; Fri, 21 Jul 2000 22:21:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13FoEp-0002zr-00 for namedroppers-data@psg.com; Fri, 21 Jul 2000 18:37:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13FoEp-0002zl-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 18:37:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13FoEp-0008WG-00 for namedroppers@ops.ietf.org; Fri, 21 Jul 2000 18:37:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: Date: Fri, 21 Jul 2000 07:07:06 -0400 To: Roy Arends From: Edward Lewis Subject: Re: draft-ietf-dnsext-zone-status-02.txt Cc: Edward Lewis , DNS Extensions WG Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 6:36 AM -0400 7/20/00, Roy Arends wrote: >Comments by Roy Arends from NLnet Labs on the I-D > > DNS Security Extension Clarification on Zone Status > > July 12, 2000, by Edward Lewis. > >> 1.1 When a Zone's Status is Important > >A few times there is mentioning of "the parent states that the child is >secured". > >The parent holds the KEY information to verify the parent's SIG over the >child's KEY or null-KEY. Only in the case where a child is clueless, a >parent states that the child is _not_ secure, by holding a signed >NULL-key for the child in their zone. In all other cases, information >on child-status in the parent zone is redundant. I'm not completely clear on your comment, so allow me to jump to a conclusion. I claim that "parent states a child is secured (or not)" is a requirement of DNS security. I think (this is the jump) that you think that I think that the only way to do this is with an explicit record or bit in the parent. But I don't think (umm, the latter think) so. The fact that there is confusion here is because of an issue Mark Kosters and I have come to roaring agreement upon. In RFC 2535, if a parent and child are secured, then the parent may "be silent" about the child. If a sibling is unsecured, the parent will have an explicit null KEY record. In summary, secured delegations are implicit and unsecured delegations are explicit. Mark I and I don't like this design "feature" but that's how the spec is written. So, I say that the parent indicates that a child is secure (when appropriate). RFC 2535 says that this is done by saying nothing - which meets the requirement. The confusion existing over the "meeting" of the requirement is one of many nuisances of the specification. Nuisances are not reasons to stop, change, etc., at this time, however. So (again), your're answer is 100% correct, but it is not in conflict with my statements. I appologize for two things - the complexity of this topic and for possibly leaping to the wrong conclusion about the discussion. >> 1.2 Islands of Security > >This clarification is very welcome. > >> 2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC >> 2535, section 2.3.2.) > >As discussed in previous remarks, this update is not neccesary. The >requirement is already there. This is a clarification, not an update. It >does not change the protocol. Hmmm, why did I screw that up. You're right, I guess I've just tied myself into a knot trying to get this draft updated. (This isn't a "it's the deadline" excuse, these words have been there quite a while.) >> Note: there is some operational discomfort with >> the current NXT record. This requirement is open to modification when >> two things happen. First, an alternate mechanism to the NXT is >> defined and second, a means by which a zone can indicate that it is >> using an alternate method. > >This seems to point to section 3 & 4 which are deleted. Yeah, now, this is a "it's the deadline" excuse. I wasn't too careful to remove all references to the dropped proposal. >> 2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC >> 2535, section 2.3.2.) Note: see the discussion following 2.1.c. > >As mentioned at 2.1.c this update is not neccesary. > >As for 2.1.d and 2.2.d, the terms privately & fully secure are welcome >when it comes to evaluating a zone's status (as mentioned in 2.4). For >clarification purposes updating a proposed standard seems unnecessary. Hopefully we can have a face to face meeting on this in Pittsburgh, or during a *possible* European swing in September. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 22 10:35:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17478 for ; Sat, 22 Jul 2000 10:35:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Fzkg-000Cd7-00 for namedroppers-data@psg.com; Sat, 22 Jul 2000 06:55:38 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Fzkf-000Cd1-00 for namedroppers@ops.ietf.org; Sat, 22 Jul 2000 06:55:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Fzkf-000CvR-00 for namedroppers@ops.ietf.org; Sat, 22 Jul 2000 06:55:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007221001.MAA19990@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Sat, 22 Jul 2000 12:01:31 +0200 In-Reply-To: "Edward Lewis's message as of Jul 22, 4:36" To: Edward Lewis , Ted.Lindgreen@tednet.nl Subject: Re: Comments on draft-ietf-dnsext-zone-status-02 Cc: Domain Names WG Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Edward Lewis, on Jul 22, 4:36, in "Re: Comments on draf ..."] > At 8:44 AM -0400 7/20/00, Ted Lindgreen wrote: > >> My Draft is double >'d > ... > >> A delegating zone is required to indicate whether a child zone is > >> secured. The reason for this requirement lies in the way in which a > > > >No. Only when the child zone is clueless, the delegating zone needs > >to indicate that the the child zone is unsecured. Otherwise, it is > >up to the child zone zone to indicate whether it is secure or unsecure. > > I answered this in a message to Roy. "Stating" by being silent is still > stating. It's like an appellate court refusing to hear an appeal of a > lower court case - the appellate court is "saying" that the lower court > verdict stands. OK, I now see our misunderstanding, it's a language problem. What you mean to say with: "A delegating zone is required to indicate whether a child zone is secured." is: "For a child zone to be secured, the parent zone must also be secured, not hold a NULL-KEY, etc. or in other words: "If the parent zone is unsecured, etc., the child is unsecured". So, it is a necessary (but not sufficient) condition. Yes, for on-tree validation, we agree completely. However, the way I interpreted the same sentence: "A delegating zone is required to indicate whether a child zone is secured." was (probably because English is not my native language): "The state of the child (secured or unsecured) is indicated in the delegating zone". And this latter interpretation is, of course, not true, as the delegating zone only tells us to check for a valid KEY in the apex of the childs zone (and it is this KEY, which is for secured zones always in the childs zone file, which indicates the status). To avoid mis-interpretation by other non-native English speakers, I suggest to refraise the sentence, for instance into something like: "A delegating zone is required to indicate whether the apex of the childs zone contains a signed KEY RR." Regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 22 10:35:08 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17486 for ; Sat, 22 Jul 2000 10:35:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Fzj4-000CcB-00 for namedroppers-data@psg.com; Sat, 22 Jul 2000 06:53:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Fzj4-000Cc5-00 for namedroppers@ops.ietf.org; Sat, 22 Jul 2000 06:53:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Fzj3-000Cuk-00 for namedroppers@ops.ietf.org; Sat, 22 Jul 2000 06:53:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39795CB6.8FD1E8C9@ehsco.com> Date: Sat, 22 Jul 2000 01:35:02 -0700 From: "Eric A. Hall" To: namedroppers Subject: ixfr clarify draft Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ixfr-01.txt has a bug in the example. First the relevant portion of the spec: 3. Query Format The IXFR query packet format is the same as that of a normal DNS query, but with the query type being IXFR and the authority section containing the SOA record of client's version of the zone. So the serial sent in the query is the KNOWN version of the zone on the slave server? Now the bug: 7. Example Given the following three generations of data with the current serial number of 3, example.domain. IN SOA ns.example.domain. rt.example.domain. ( 1 600 600 3600000 604800) IN NS ns.example.domain. ns.example.domain. IN A 10.0.0.1 ftp.example.domain. IN A 10.0.1.1 ftp.example.domain. is removed and www.example.domain. is added. example.domain. IN SOA ns.example.domain. rt.example.domain. ( 2 600 600 3600000 604800) IN NS ns.example.domain. ns.example.domain. IN A 10.0.0.1 www.example.domain. IN A 10.0.1.2 IN A 10.0.2.1 One of the IP addresses of www.example.domain. is changed. example.domain. IN SOA ns.example.domain. rt.example.domain. ( 3 600 600 3600000 604800) IN NS ns.example.domain. ns.example.domain. IN A 10.0.0.1 www.example.domain. IN A 10.0.3.1 IN A 10.0.2.1 The following IXFR query +---------------------------------------------------+ Header | OPCODE=SQUERY | +---------------------------------------------------+ Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | +---------------------------------------------------+ Answer | | +---------------------------------------------------+ Authority | example.domain. IN SOA serial=1 | +---------------------------------------------------+ Additional | | +---------------------------------------------------+ continuing... +---------------------------------------------------+ Header | OPCODE=SQUERY, RESPONSE | +---------------------------------------------------+ Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | +---------------------------------------------------+ Answer | example.domain. IN SOA serial=3 | | example.domain. IN SOA serial=1 | | ftp.example.domain. IN A 10.0.1.1 | | example.domain. IN SOA serial=2 | | www.example.domain. IN A 10.0.1.2 | | www.example.domain. IN A 10.0.2.1 | | example.domain. IN SOA serial=2 | | www.example.domain. IN A 10.0.1.2 | | example.domain. IN SOA serial=3 | | www.example.domain. IN A 10.0.3.1 | | example.domain. IN SOA serial=3 | +---------------------------------------------------+ Authority | | +---------------------------------------------------+ Additional | | +---------------------------------------------------+ In the examples shown above, the slave KNOWS serial 1, because that's the version that it is reporting possesion of in the query. As such, it already knows about ftp.example.domain. If the client sends serial 1 in the query, the response should start at serial 2. The example should either have the client sending serial 0 in the query (if the answer is correct), or the response should be as follows (if the current query is correct): +---------------------------------------------------+ Answer | example.domain. IN SOA serial=3 | | example.domain. IN SOA serial=2 | | www.example.domain. IN A 10.0.1.2 | | www.example.domain. IN A 10.0.2.1 | ........ Right? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 22 18:39:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11075 for ; Sat, 22 Jul 2000 18:39:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13G7L3-000HTU-00 for namedroppers-data@psg.com; Sat, 22 Jul 2000 15:01:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13G7L2-000HTO-00 for namedroppers@ops.ietf.org; Sat, 22 Jul 2000 15:01:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13G7L2-000Gk8-00 for namedroppers@ops.ietf.org; Sat, 22 Jul 2000 15:01:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3979FC13.A10605D8@ehsco.com> Date: Sat, 22 Jul 2000 12:54:59 -0700 From: "Eric A. Hall" To: namedroppers Subject: Re: ixfr clarify draft References: <39795CB6.8FD1E8C9@ehsco.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I was wrong: > ftp.example.domain. is removed Apologies for the distraction. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 23 13:28:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24524 for ; Sun, 23 Jul 2000 13:28:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13GOrJ-00025V-00 for namedroppers-data@psg.com; Sun, 23 Jul 2000 09:44:09 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13GOrJ-00025P-00 for namedroppers@ops.ietf.org; Sun, 23 Jul 2000 09:44:09 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13GOrJ-0003y1-00 for namedroppers@ops.ietf.org; Sun, 23 Jul 2000 09:44:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007231548.BAA66537@drugs.dv.isc.org> To: "Eric A. Hall" Cc: namedroppers From: Mark.Andrews@nominum.com Subject: Re: ixfr clarify draft In-reply-to: Your message of "Sat, 22 Jul 2000 01:35:02 MST." <39795CB6.8FD1E8C9@ehsco.com> Date: Mon, 24 Jul 2000 01:48:32 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ixfr-01.txt has a > bug in the example. > > > First the relevant portion of the spec: > > 3. Query Format > > The IXFR query packet format is the same as that of a normal DNS > query, but with the query type being IXFR and the authority section > containing the SOA record of client's version of the zone. > > So the serial sent in the query is the KNOWN version of the zone on the > slave server? Yes. > > > Now the bug: > > 7. Example > > Given the following three generations of data with the current serial > number of 3, > > example.domain. IN SOA ns.example.domain. rt.example.domain. ( > 1 600 600 3600000 604800) > IN NS ns.example.domain. > ns.example.domain. IN A 10.0.0.1 > ftp.example.domain. IN A 10.0.1.1 > > ftp.example.domain. is removed and www.example.domain. is added. > > example.domain. IN SOA ns.example.domain. rt.example.domain. ( > 2 600 600 3600000 604800) > IN NS ns.example.domain. > ns.example.domain. IN A 10.0.0.1 > www.example.domain. IN A 10.0.1.2 > IN A 10.0.2.1 > > One of the IP addresses of www.example.domain. is changed. > > example.domain. IN SOA ns.example.domain. rt.example.domain. ( > 3 600 600 3600000 604800) > IN NS ns.example.domain. > ns.example.domain. IN A 10.0.0.1 > www.example.domain. IN A 10.0.3.1 > IN A 10.0.2.1 > > The following IXFR query > > +---------------------------------------------------+ > Header | OPCODE=SQUERY | > +---------------------------------------------------+ > Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | > +---------------------------------------------------+ > Answer | | > +---------------------------------------------------+ > Authority | example.domain. IN SOA serial=1 | > +---------------------------------------------------+ > Additional | | > +---------------------------------------------------+ > > continuing... > > +---------------------------------------------------+ > Header | OPCODE=SQUERY, RESPONSE | > +---------------------------------------------------+ > Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR | > +---------------------------------------------------+ Final SOA value. > Answer | example.domain. IN SOA serial=3 | Records to be deleted to get from 1 -> 2. > | example.domain. IN SOA serial=1 | > | ftp.example.domain. IN A 10.0.1.1 | Records to be added to get from 1 -> 2. > | example.domain. IN SOA serial=2 | > | www.example.domain. IN A 10.0.1.2 | > | www.example.domain. IN A 10.0.2.1 | Records to be deleted to get from 2 -> 3. > | example.domain. IN SOA serial=2 | > | www.example.domain. IN A 10.0.1.2 | Records to be added to get from 2 -> 3. > | example.domain. IN SOA serial=3 | > | www.example.domain. IN A 10.0.3.1 | End marker. > | example.domain. IN SOA serial=3 | > +---------------------------------------------------+ > Authority | | > +---------------------------------------------------+ > Additional | | > +---------------------------------------------------+ > > In the examples shown above, the slave KNOWS serial 1, because that's > the version that it is reporting possesion of in the query. As such, it > already knows about ftp.example.domain. Yes the slave knows about it but it being told to *delete* it. > > If the client sends serial 1 in the query, the response should start at > serial 2. No. Read Section 4 paragraph 3. > > The example should either have the client sending serial 0 in the query > (if the answer is correct), or the response should be as follows (if the > current query is correct): > > +---------------------------------------------------+ > Answer | example.domain. IN SOA serial=3 | > | example.domain. IN SOA serial=2 | > | www.example.domain. IN A 10.0.1.2 | > | www.example.domain. IN A 10.0.2.1 | > ........ > > Right? No. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Jul 24 07:55:52 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03029 for ; Mon, 24 Jul 2000 07:55:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13GgJh-000GPe-00 for namedroppers-data@psg.com; Mon, 24 Jul 2000 04:22:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13GgJh-000GPY-00 for namedroppers@ops.ietf.org; Mon, 24 Jul 2000 04:22:37 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13GgJh-0005qo-00 for namedroppers@ops.ietf.org; Mon, 24 Jul 2000 04:22:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: NO RR draft announcement From: Simon Josefsson Date: 24 Jul 2000 13:12:01 +0200 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Either I didn't get the announcement, or there wasn't one, anyway: http://www.ietf.org/internet-drafts/draft-jas-dnsext-no-00.txt Comments solicited. As suggested by Olafur Gudmundsson's, the "type bit map" will be replaced with a sorted list of RR numbers. Also, using a unique subdomain (pointed out by a SRV record) to store NO records, so they doesn't interfer with other records, is a likely further enhancement. I include title and abstract below. /Simon Authenticating denial of existence in DNS with minimum disclosure (or; An alternative to DNSSEC NXT records) draft-jas-dnsext-no-00 ... Abstract This draft present an alternative to NXT records, used to achieve authenticated denial of existence of a domain name, class and type. Problems with NXT records, as specified in RFC 2535, are identified, and one solution is presented. to unsubscribe send a message to 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 Jul 24 20:42:44 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23508 for ; Mon, 24 Jul 2000 20:42:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13GsAu-0000OT-00 for namedroppers-data@psg.com; Mon, 24 Jul 2000 17:02:20 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13GsAs-0000OJ-00 for namedroppers@ops.ietf.org; Mon, 24 Jul 2000 17:02:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13GsBQ-0006R4-00 for namedroppers@ops.ietf.org; Mon, 24 Jul 2000 17:02:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007241234.OAA21559@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement In-reply-to: Your message of "24 Jul 2000 13:12:01 +0200." Date: Mon, 24 Jul 2000 14:34:49 +0200 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Either I didn't get the announcement, or there wasn't one, anyway: It was sent to ietf-announce last Wednesday. Generally I like the idea, most because it solves the ambiguity at the delegation point. The chaining prevention is a nice add-on then. > As suggested by Olafur Gudmundsson's, the "type bit map" will be > replaced with a sorted list of RR numbers. Also, using a unique > subdomain (pointed out by a SRV record) to store NO records, so they > doesn't interfer with other records, is a likely further enhancement. OK, this was one of my points - the "no-" prefix only (which is not really necessary anyway) somehow clutters the namespace in that the NO RRs deny their own existence. Dedicating a subdomain is a good idea, although I'd prefer a fixed name relative to the zone apex over a SRV based solution. I've two further questions: 1) Concerning wildcards, I understand the necessity to prove the absence of one or more wildcard owners, but why is the special NO RR for the wildcard owner itself needed? Consider the zone example.org(*) with only www.example.org in it: example.org OWH -> 10 www.example.org OWH -> 30 If I ask for mail.example.org (which hashes, e.g. to 20), I receive "no-10 NO OWH 30 ... " to prove the non-existence of mail.example.org. Then, to prove that no wildcard exists (let OWH(*.example.org) be 40), shouldn't it be sufficient to send "no-30 NO OWH 10 ..." ? If in the above example the zone also contains ftp.example.org OWH -> 50 and we ask for "www.sub.example.org" (hashing to 60), you would have to also prove the non-existence of "*.sub.example.org" by sending the "no-50 NO OWH 10 ...". In this case you cannot prepare the NO RR for the wildcard because you can't know in advance what domain names people are going to ask for. So, the resolver would have to conclude itself that said NO RR is for the "*.sub.example.org" owner. Now, is there anything special with the "*.example.org" wildcard that I don't see? 2) How is an empty non-leaf node handled? The example.org zone consists of the following owners: example.org www.example.org www.sub.example.org So, there's no RR associated with "sub.example.org", which results in NOERROR with empty answer section, if you ask for that domain name. The entity generating the NO RRs must then insert a NO RR corrsponding to "sub.example.org" with empty type bitmap/list, but I'm not sure that's all. -Peter PS: (*) minor nit: example domain names best follow RFC 2606 to avoid problems for uninvolved parties. to unsubscribe send a message to 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 Jul 24 20:52:06 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26629 for ; Mon, 24 Jul 2000 20:52:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13GsM9-0000XS-00 for namedroppers-data@psg.com; Mon, 24 Jul 2000 17:13:57 -0700 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13GsM8-0000XM-00 for namedroppers@ops.ietf.org; Mon, 24 Jul 2000 17:13:56 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13GsMf-0006Rn-00 for namedroppers@ops.ietf.org; Mon, 24 Jul 2000 17:14:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement References: <200007241234.OAA21559@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: Peter Koch's message of "Mon, 24 Jul 2000 14:34:49 +0200" From: Simon Josefsson Date: 24 Jul 2000 15:45:38 +0200 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit First, thanks for your comments. Answers inline below.. Peter Koch writes: > > As suggested by Olafur Gudmundsson's, the "type bit map" will be > > replaced with a sorted list of RR numbers. Also, using a unique > > subdomain (pointed out by a SRV record) to store NO records, so they > > doesn't interfer with other records, is a likely further enhancement. > > OK, this was one of my points - the "no-" prefix only (which is not really > necessary anyway) somehow clutters the namespace in that the NO RRs > deny their own existence. Dedicating a subdomain is a good idea, although > I'd prefer a fixed name relative to the zone apex over a SRV based solution. Let's say "_no.example.org". Perhaps a SRV record isn't necessery. (The "no-" prefix is necessery to make sure that base32 encoded domain names doesn't start with 0-9, which is forbidden.) > 1) Concerning wildcards, I understand the necessity to prove the absence > of one or more wildcard owners, but why is the special NO RR for the > wildcard owner itself needed? > > Consider the zone example.org(*) with only www.example.org in it: > > example.org OWH -> 10 > www.example.org OWH -> 30 > > If I ask for mail.example.org (which hashes, e.g. to 20), I receive > "no-10 NO OWH 30 ... " to prove the non-existence of mail.example.org. > Then, to prove that no wildcard exists (let OWH(*.example.org) be 40), > shouldn't it be sufficient to send "no-30 NO OWH 10 ..." ? Yes. You're right, generating NO records for non-existing wildcard domains are redundant. > 2) How is an empty non-leaf node handled? > > The example.org zone consists of the following owners: > > example.org > www.example.org > www.sub.example.org > > So, there's no RR associated with "sub.example.org", which results > in NOERROR with empty answer section, if you ask for that domain name. > The entity generating the NO RRs must then insert a NO RR corrsponding > to "sub.example.org" with empty type bitmap/list, but I'm not sure that's > all. Yes, this should be pointed out in the document. I don't see other issues, but perhaps there are. > PS: (*) minor nit: example domain names best follow RFC 2606 to avoid > problems for uninvolved parties. Of course, I've updated this. Thanks. /Simon to unsubscribe send a message to 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 Jul 25 12:16:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12960 for ; Tue, 25 Jul 2000 12:16:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13H6p3-000CUH-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 08:40:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13H6p2-000CUB-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 08:40:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13H6p2-000GDw-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 08:40:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 25 Jul 2000 14:10:52 +0200 (CEST) From: Roy Arends To: DNS Extensions WG Subject: Is this a possible DoS scenario within DNSSEC ? Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, A SIG record covers RR Sets. Consider a caching server (not secured), which has cached the following: example.org. NS ns1.example.org. example.org. NS ns2.example.org. example.org. SIG NS DSA ..... The SIG above validates the two NS records. At one point the cache gets spoofed with for instance: example.org. NS very.ugly.org. Upon a query for these records, the cache server will respond with all 3 NS records and the SIG record. The secure resolver validates the NS RR set with the SIG record, and its conclusion will be that the SIG record does not authenticate the 3 NS records. The secure resolver now disregards these NS records (they are seen as BAD). This zone can not be resolved. If this scheme is true, this is an easy to perform denial of service attack against the example.org zone. Is this a possible scenario ? Regards, Roy Arends NLnet Labs. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 25 12:17:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13385 for ; Tue, 25 Jul 2000 12:17:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13H6aP-000CIN-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 08:25:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13H6aO-000CIH-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 08:25:36 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13H6aO-000G6V-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 08:25:36 -0700 Message-Id: <200007251032.GAA22222@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-dhcid-rr-00.txt Date: Tue, 25 Jul 2000 06:32:47 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : A DNS RR for encoding DHCP information Author(s) : A. Gustafsson, M. Stapp Filename : draft-ietf-dnsext-dhcid-rr-00.txt Pages : 6 Date : 24-Jul-00 A situation can arise where multiple DHCP clients request the same DNS name from their (possibly distinct) DHCP servers. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[7] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients 'owning' them. This memo defines a distinct RR type for use by DHCP servers, the 'DHCID' RR. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-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-dhcid-rr-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-dhcid-rr-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: <20000724141655.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dhcid-rr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dhcid-rr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000724141655.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 Jul 25 12:21:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14252 for ; Tue, 25 Jul 2000 12:21:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13H6wT-000Cav-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 08:48:25 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13H6wS-000Cao-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 08:48:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13H6wS-000GHU-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 08:48:24 -0700 Date: Tue, 25 Jul 2000 15:35:01 +0200 (CEST) From: Roy Arends To: DNS Extensions WG Subject: Null-key priority during key-clash. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Regarding: RFC 2535, : Handling of DNS Zone Signing Keys Hello, Suppose the domains example.org and .org are secure. Now consider a Real-key SIG for the zone example.org , which is issued for the period of January 1st until April 1st. On March 1st the Real key for the example.org zone gets compromised. This is noticed by the example.org owner and the Real-Key is immediatly removed from the example.org zone. After TTL expires, this key will not exist, and this zone will be considered BAD by secure resolvers. Therefore, the .org domain issues a signature for a Null-key for the example.org zone. Now the example.org zone can still be resolved, though it is marked by secure resolvers as "Unsecure". All this happens before April 1st. But, A malicious entity (for example, this could be the compromiser of the key) can poison caches with the old Real-key and SIG for the example.org zone. This Key's SIG is still valid until April 1st, and any secure resolver which stumbles across this Real-Key & SIG will see these as valid. Upon a query for the KEY & SIG of example.org. a (poisoned) cache will return both KEYs and both SIGS. Should the secure resolve see this zone as Secure (which, in this case it is obviously not) or as Unsecure. I think the latter. In other words, should the Null-key be given a higher priority during a Key-Clash ? Note: This is not the same issue as what in rfc 2535 was noted as "Experimentally secure." I haven't found this priority issue in rfc 2535, nor in any draft. Though the draft "Handling of DNS Zone Signing Keys" has a section on Removing a Key From Use (2.5) though this section does not suffice. Any comments ? Roy Arends NLnet Labs. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 25 13:39:30 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08326 for ; Tue, 25 Jul 2000 13:39:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13H8Jh-000DwO-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 10:16:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13H8Jg-000DwI-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 10:16:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13H8Jg-000GsP-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 10:16:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 25 Jul 2000 09:50:51 -0700 (PDT) Message-Id: <200007251650.JAA26163@gulag.araneus.fi> To: Simon Josefsson CC: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement In-Reply-To: References: <200007241234.OAA21559@grimsvotn.TechFak.Uni-Bielefeld.DE> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > (The "no-" prefix is necessery to make sure that base32 encoded domain > names doesn't start with 0-9, which is forbidden.) No, it's not. Consider for example the IN-ADDR.ARPA tree, where most labels consist solely of digits. Also see RFC2181 section 11. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 25 13:44:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09465 for ; Tue, 25 Jul 2000 13:44:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13H8FL-000Dsm-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 10:11:59 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13H8FK-000Dsg-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 10:11:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13H8FK-000GqQ-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 10:11:58 -0700 Message-Id: <200007251641.JAA27558@sh.lh.vix.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Roy Arends cc: DNS Extensions WG , scharf@vix.com Subject: Re: Null-key priority during key-clash. In-reply-to: Your message of "Tue, 25 Jul 2000 15:35:01 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 2000 09:41:43 -0700 From: Jerry Scharf Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Roy, there are many DoS attacks that can be done with Secure DNS, nad that has been known since the original design. I think both of these, or variants, have been known since the beginning. I think everyone goes thought this at some point. I think it has to be ackowledges that DNS as it exists today has many DoS attacks as well, so it's not like we're taking something that is hard to attack and then making it easy. I've always figured it was more work than needed to use subtle secure DNS attacks when it is so simple to just jam any answer back with the right source address and sequence. Just return an NXDOM, it's much more effective with the exception of not wasting CPU cycles on the resolver/recursive system. If you want to burn their CPU you do want to use secure DNS, but what you really want to do is make the longest key possible to maximize checking cost. jerry to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 25 14:04:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15483 for ; Tue, 25 Jul 2000 14:04:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13H8g8-000EKH-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 10:39:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13H8g8-000EKB-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 10:39:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13H8g7-000H3N-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 10:39:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000725133159.00e7edb0@localhost> Date: Tue, 25 Jul 2000 13:36:55 -0400 To: Roy Arends , DNS Extensions WG From: Olafur Gudmundsson Subject: Re: Is this a possible DoS scenario within DNSSEC ? In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 08:10 AM 7/25/00, Roy Arends wrote: >Hello, > >A SIG record covers RR Sets. Consider a caching server (not secured), >which has cached the following: > >example.org. NS ns1.example.org. >example.org. NS ns2.example.org. >example.org. SIG NS DSA ..... > >The SIG above validates the two NS records. At one point the cache >gets spoofed with for instance: > >example.org. NS very.ugly.org. > >Upon a query for these records, the cache server will respond with all 3 >NS records and the SIG record. > >The secure resolver validates the NS RR set with the SIG record, and its >conclusion will be that the SIG record does not authenticate the 3 NS >records. > >The secure resolver now disregards these NS records (they are seen as >BAD). This zone can not be resolved. If this scheme is true, this is an >easy to perform denial of service attack against the example.org zone. > >Is this a possible scenario ? Yes it is quite likely and the only thing that can be done is to have resolvers that will check if the data came from caching or authoritative server. If the resolver did not get the data from an authoritative server it MUST try to get the data from one and hope that it can reach it and it gets a better answer. This is one of the operational issues that DNSSEC, traffic to authoritative servers will increase significantly. And DNSSEC may not work well if resolvers are stuck behind a non DNSSEC capable forwarder. Olafur >Regards, > >Roy Arends >NLnet Labs. > > > > > > > > > > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to 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 Jul 25 14:29:55 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23619 for ; Tue, 25 Jul 2000 14:29:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13H8yv-000JKg-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 10:59:05 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13H8yu-000JJy-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 10:59:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13H8yu-000HBe-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 10:59:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 25 Jul 2000 10:56:25 -0700 (PDT) Message-Id: <200007251756.KAA26189@gulag.araneus.fi> To: Peter Koch Cc: "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt In-Reply-To: <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <39768A2D.A74AEB5B@ehsco.com> <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Well, part of the problem is that this document provides for yet another > not backwards compatible definition of "glue" RRs. At least from a teaching > viewpoint this is suboptimal and that's why I mentioned the ``real'' glue > in my previous message. I would still like to know what your definition of "real" glue is. After thinking a bit more about the issue, I would say that what distinguishes glue appropriate for inclusion in zone transfers from other glue is not the owner name of the glue RRs but whether the glue is considered "glue of the zone" by the master. Here's an updated section 4 reflecting this definition: Zone transfers MUST include any glue RR configured specifically for the zone being transfered, such as any non-authoritative zone data loaded from the zone's master file or received as part of an incoming zone transfer of the zone in case, except such glue RRs that the master has deemed inappropriate and discarded on loading. Zone transfers SHOULD NOT contain RRs from the authoritative data of zones other than the one being transferred, and MUST NOT contain RRs from the cache, even when such RRs are pointed to by NS records in the zone being transferred. The glue RRs are transmitted in the answer section along with the authoritative data. This is unlike ordinary DNS responses where glue is transmitted in the additional section. A slave MUST recognize any data outside the zone being transferred as glue; it MUST NOT be treated as authoritative data nor entered into the cache. Note that classifying an RR as glue or non-glue may not be possible until the entire zone has been received so that the zone cuts defined by the zone's NS records can be determined. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 25 15:26:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09715 for ; Tue, 25 Jul 2000 15:26:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13H9k3-000GSF-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 11:47:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13H9k3-000GS4-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 11:47:47 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13H9k3-000HYN-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 11:47:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: gson@nominum.com (Andreas Gustafsson) Cc: Peter Koch , "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt References: <39768A2D.A74AEB5B@ehsco.com> <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> <200007251756.KAA26189@gulag.araneus.fi> Message-Id: Date: Tue, 25 Jul 2000 11:46:07 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit one way i think of glue is, presuming there is no $origin above it, could an ns rr's label be written without a terminating dot? if so, then a glue a rr is needed for it. 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 Jul 25 16:13:15 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23471 for ; Tue, 25 Jul 2000 16:13:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HASB-000MMm-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 12:33:23 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HASA-000MMg-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 12:33:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HASA-000Hs8-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 12:33:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: gson@nominum.com (Andreas Gustafsson) Cc: Peter Koch , "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt References: <39768A2D.A74AEB5B@ehsco.com> <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> <200007251756.KAA26189@gulag.araneus.fi> Message-Id: Date: Tue, 25 Jul 2000 11:46:07 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit one way i think of glue is, presuming there is no $origin above it, could an ns rr's label be written without a terminating dot? if so, then a glue a rr is needed for it. s/label/rhs/ sorry. 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 Jul 25 16:17:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24151 for ; Tue, 25 Jul 2000 16:17:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HAZJ-000MUe-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 12:40:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HAZI-000MUY-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 12:40:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HAZI-000Hvr-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 12:40:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007251917.OAA25662@gungnir.fnal.gov> To: namedroppers@internic.net From: "Matt Crawford" Subject: draft-levone-dns-wins-lookup-01.txt Date: Tue, 25 Jul 2000 14:17:10 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This seems like a wrong approach to the problem for several reasons. 1. A WINS server may know if a name has gone away, but cannot tell the DNS server. 2. If you enable this WINS RR feature "at the root of the zone" example.org, then a query coming in for foo.a.b.c.d.e.example.org will apparently activate all the same processing as foo.example.org. 3. It requires that you permit WINS access from the off-site secondaries that you're urged to have for your zone. 4. Both offered choices for handing non-A queries are awkward. 5. You generally can't resolve the address of a WINS client that happens to be down or unreachable at the moment. 6. What the DNS server returns upon timeout of the "NetBIOS node adapter status query" generated by a DNS PTR query is not stated. Attempting to specify the DNS server's behavior in this case would probably lead to the conclusion that the only right response is SRVFAIL. Ugh! 7. This new "local" flag which causes omission of an RR from a zone transfer looks like an awful idea! After spending a few paragraphs on prevention of misleading NXDOMAIN returns, this puts them right back in. 8. Last, but not least, it's explicitly incompatible with DNS Security. As a complete alternative, I suggest having a WINS server dynamically update DNS using already-specified methods. ______________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab to unsubscribe send a message to 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 Jul 25 18:56:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10877 for ; Tue, 25 Jul 2000 18:56:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HCnP-0005xL-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 15:03:27 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HCnO-0005xE-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 15:03:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HCnO-000IxC-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 15:03:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 25 Jul 2000 17:35:56 -0400 Message-Id: <200007252135.RAA11832@hun.gw.tislabs.com> From: Olafur Gudmundsson To: namedroppers@ops.ietf.org, agenda@iet.org Subject: DNSEXT Draft Agenda Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Draft agenda (2000/7/25) 48'th IETF DNSEXT WG meeting Thursday August 3'rd 2000. 9:00 -- 11:30 Chairs: Randy Bush, Verio Olafur Gudmundsson, NAI Working group items 05 min Agenda bashing Randy Bush, Verio 10 min New charter discussion Olafur Gudmundsson, NAI 10 min WG status Olafur Gudmundsson, NAI 05 min Interop testing results Bill Manning, ISI Current working group documents: 04 min IXFRbis Last Call Last Call comments 10 min AXFR Clarify Andreas Gustafson, Nominum 05 min Message Size Olafur Gudmundsson, NAI 10 min EDNS0.5 Harald Alvestrand, EDB Maxware 10 min GSSAPI-TSIG Levon Esibov, Microsoft 10 min Zone Secure Edward Lewis, NAI 10 min DHC ID Mark Strap, Cisco, Andreas Gustafson Nominum New documents requesting WG status: 10 min NO Record Simon Josefson/Magnus Nystroom RSASecurity 10 min DNSSEC Roadmap Glen Rose, NIST 10 min Multicast DNS Bernard Aboba, Microsoft Non-document slots: 10 min Use of AD bit in query David Conrad, Nominum 15 min Other items 02 min Summary to unsubscribe send a message to 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 Jul 25 19:28:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21273 for ; Tue, 25 Jul 2000 19:28:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HDLO-0006t4-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 15:38:34 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HDLN-0006sx-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 15:38:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HDLN-000JBC-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 15:38:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007252222.AAA30381@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 26 Jul 2000 00:22:42 +0200 In-Reply-To: "Olafur Gudmundsson's message as of Jul 25, 20:16" Reply-To: Ted.Lindgreen@tednet.nl To: Olafur Gudmundsson , Roy Arends , DNS Extensions WG Subject: Re: Is this a possible DoS scenario within DNSSEC ? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Olafur Gudmundsson, on Jul 25, 20:16, in "Re: Is this a possib ..."] > At 08:10 AM 7/25/00, Roy Arends wrote: > > > >Is this a possible scenario ? > > Yes it is quite likely and the only thing that can be done is to > have resolvers that will check if the data came from caching or > authoritative server. If the resolver did not get the data from an > authoritative server it MUST try to get the data from one and hope that > it can reach it and it gets a better answer. I do not think it is good to recommend, and certainly not make it a MUST, that everyone always tries to go to the authoritative servers in order to check for possibly better answers. This defeats the whole idea of the distributed mechanisme of the DNS service, and it is just that, which has made it so powerful and scalably as it has proven to be. > This is one of the operational issues that DNSSEC, traffic to authoritative > servers will increase significantly. .... Hopefully not, it may kill the large TLDs, and thus the Internet. But please note, that only non-DNSSEC caching servers can be fooled: secure aware caching servers will discover the spoofed data as being bad upon entry, and must discard it immediately. So, it is really not necessary to go straight to the authoritive server, consulting your favourite secure aware caching server is just as good. > servers will increase significantly. And DNSSEC may not work well if > resolvers are stuck behind a non DNSSEC capable forwarder. Absolutely, and the real lessons are therefore clear: - Secure aware resolvers should not use non secure aware caching servers as forwarder. - Maintainers of important forwarding servers, e.g. the large ISPs, need to be convinced that they must implement DNSSEC as soon as it starts being deployed, if they care for their customers. Regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 25 19:57:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28015 for ; Tue, 25 Jul 2000 19:57:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HDuR-00009L-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 16:14:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HDLN-0006sx-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 15:38:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HDLN-000JBC-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 15:38:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007252222.AAA30381@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 26 Jul 2000 00:22:42 +0200 In-Reply-To: "Olafur Gudmundsson's message as of Jul 25, 20:16" Reply-To: Ted.Lindgreen@tednet.nl To: Olafur Gudmundsson , Roy Arends , DNS Extensions WG Subject: Re: Is this a possible DoS scenario within DNSSEC ? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Olafur Gudmundsson, on Jul 25, 20:16, in "Re: Is this a possib ..."] > At 08:10 AM 7/25/00, Roy Arends wrote: > > > >Is this a possible scenario ? > > Yes it is quite likely and the only thing that can be done is to > have resolvers that will check if the data came from caching or > authoritative server. If the resolver did not get the data from an > authoritative server it MUST try to get the data from one and hope that > it can reach it and it gets a better answer. I do not think it is good to recommend, and certainly not make it a MUST, that everyone always tries to go to the authoritative servers in order to check for possibly better answers. This defeats the whole idea of the distributed mechanisme of the DNS service, and it is just that, which has made it so powerful and scalably as it has proven to be. > This is one of the operational issues that DNSSEC, traffic to authoritative > servers will increase significantly. .... Hopefully not, it may kill the large TLDs, and thus the Internet. But please note, that only non-DNSSEC caching servers can be fooled: secure aware caching servers will discover the spoofed data as being bad upon entry, and must discard it immediately. So, it is really not necessary to go straight to the authoritive server, consulting your favourite secure aware caching server is just as good. > servers will increase significantly. And DNSSEC may not work well if > resolvers are stuck behind a non DNSSEC capable forwarder. Absolutely, and the real lessons are therefore clear: - Secure aware resolvers should not use non secure aware caching servers as forwarder. - Maintainers of important forwarding servers, e.g. the large ISPs, need to be convinced that they must implement DNSSEC as soon as it starts being deployed, if they care for their customers. Regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Jul 25 19:57:42 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28131 for ; Tue, 25 Jul 2000 19:57:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HDvn-0000Bb-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 16:16:11 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HCnO-0005xE-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 15:03:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HCnO-000IxC-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 15:03:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 25 Jul 2000 17:35:56 -0400 Message-Id: <200007252135.RAA11832@hun.gw.tislabs.com> From: Olafur Gudmundsson To: namedroppers@ops.ietf.org, agenda@iet.org Subject: DNSEXT Draft Agenda Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Draft agenda (2000/7/25) 48'th IETF DNSEXT WG meeting Thursday August 3'rd 2000. 9:00 -- 11:30 Chairs: Randy Bush, Verio Olafur Gudmundsson, NAI Working group items 05 min Agenda bashing Randy Bush, Verio 10 min New charter discussion Olafur Gudmundsson, NAI 10 min WG status Olafur Gudmundsson, NAI 05 min Interop testing results Bill Manning, ISI Current working group documents: 04 min IXFRbis Last Call Last Call comments 10 min AXFR Clarify Andreas Gustafson, Nominum 05 min Message Size Olafur Gudmundsson, NAI 10 min EDNS0.5 Harald Alvestrand, EDB Maxware 10 min GSSAPI-TSIG Levon Esibov, Microsoft 10 min Zone Secure Edward Lewis, NAI 10 min DHC ID Mark Strap, Cisco, Andreas Gustafson Nominum New documents requesting WG status: 10 min NO Record Simon Josefson/Magnus Nystroom RSASecurity 10 min DNSSEC Roadmap Glen Rose, NIST 10 min Multicast DNS Bernard Aboba, Microsoft Non-document slots: 10 min Use of AD bit in query David Conrad, Nominum 15 min Other items 02 min Summary to unsubscribe send a message to 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 Jul 25 20:59:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12159 for ; Tue, 25 Jul 2000 20:59:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HF5K-0001ot-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 17:30:06 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HF5K-0001on-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 17:30:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HF5K-000JsX-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 17:30:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397E3029.977B371D@cisco.com> Date: Tue, 25 Jul 2000 20:26:17 -0400 From: Josh Littlefield To: Andreas Gustafsson CC: Peter Koch , "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt References: <39768A2D.A74AEB5B@ehsco.com> <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> <200007251756.KAA26189@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think attention to section 7.18 of RFC2136 may induce caution with the discussion of necessary and/or real glue. While its important that a slave recognize the boundaries of the zone, and that the master not send a bunch of random stuff, its also essential that the master sends, and that the slave retains, all records considered part of the zone, whether necessary glue or not. Based on the "occluding zone cut" case in this section of 7.18, its important that a full zone transfer, followed by an incremental which removes the zone cut, leaves the slave with the correct state of the zone, which will include the newly exposed records. I think Andreas new text is consistent with this, but it could be read as the server choosing to include a subset of the configured zone data in the transfer. The server should take care in what is allowed to be configured in the zone, but once configured it should all be transferred. The slave should be careful to recognize the portions which are currently exposed either directly or as needed glue. Andreas Gustafsson wrote: > > > Well, part of the problem is that this document provides for yet another > > not backwards compatible definition of "glue" RRs. At least from a teaching > > viewpoint this is suboptimal and that's why I mentioned the ``real'' glue > > in my previous message. > > I would still like to know what your definition of "real" glue is. > > After thinking a bit more about the issue, I would say that what > distinguishes glue appropriate for inclusion in zone transfers from > other glue is not the owner name of the glue RRs but whether the glue > is considered "glue of the zone" by the master. > > Here's an updated section 4 reflecting this definition: > > Zone transfers MUST include any glue RR configured specifically > for the zone being transfered, such as any non-authoritative zone data > loaded from the zone's master file or received as part of an incoming > zone transfer of the zone in case, except such glue RRs that the > master has deemed inappropriate and discarded on loading. > > Zone transfers SHOULD NOT contain RRs from the authoritative data > of zones other than the one being transferred, and MUST NOT contain > RRs from the cache, even when such RRs are pointed to by NS records > in the zone being transferred. > > The glue RRs are transmitted in the answer section along with the > authoritative data. This is unlike ordinary DNS responses where > glue is transmitted in the additional section. > > A slave MUST recognize any data outside the zone being transferred > as glue; it MUST NOT be treated as authoritative data nor entered > into the cache. Note that classifying an RR as glue or non-glue may > not be possible until the entire zone has been received so that the > zone cuts defined by the zone's NS records can be determined. > > -- > Andreas Gustafsson, gson@nominum.com > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 to unsubscribe send a message to 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 Jul 25 21:28:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19976 for ; Tue, 25 Jul 2000 21:28:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HFgC-0002m2-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 18:08:12 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HFgC-0002lw-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 18:08:12 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HFgC-000K8j-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 18:08:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007260104.VAA18389@torque.pothole.com> To: Roy Arends cc: DNS Extensions WG Subject: Re: Is this a possible DoS scenario within DNSSEC ? In-reply-to: Your message of "Tue, 25 Jul 2000 14:10:52 +0200." Date: Tue, 25 Jul 2000 21:04:55 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit DNSSEC does not claim to provide any protection against denial of service. If you get data from an insecure cache, it could be anything. Certainly it could have been diddled in a number of ways so that signatures would fail. In fact, you have no idea whether what you are getting is what is really in the cache or some bad guy is answering for the caching server or corrupting the answers in transit. If the cache were secure and supported the service, you could use TSIG or SIG(0) transaction signatures with it and at least distinguish between the data being bad or the communications being corrupted. But then again, if the cache were secure and knew the zone you were retrieving from was signed and could verify it, it would be nice it if wouldn't add an RR so as to break a verified signature. And if the caching server were secure using policies you liked and will handle will handle recursive requests for you, there is no particular reason for your resovler to be secure. It might as well use TSIG with the cacing server it trusts.... Thanks, Donald From: Roy Arends Date: Tue, 25 Jul 2000 14:10:52 +0200 (CEST) To: DNS Extensions WG Message-ID: >Hello, > >A SIG record covers RR Sets. Consider a caching server (not secured), >which has cached the following: > >example.org. NS ns1.example.org. >example.org. NS ns2.example.org. >example.org. SIG NS DSA ..... > >The SIG above validates the two NS records. At one point the cache >gets spoofed with for instance: > >example.org. NS very.ugly.org. > >Upon a query for these records, the cache server will respond with all 3 >NS records and the SIG record. > >The secure resolver validates the NS RR set with the SIG record, and its >conclusion will be that the SIG record does not authenticate the 3 NS >records. > >The secure resolver now disregards these NS records (they are seen as >BAD). This zone can not be resolved. If this scheme is true, this is an >easy to perform denial of service attack against the example.org zone. > >Is this a possible scenario ? > >Regards, > >Roy Arends >NLnet Labs. > > > > > > > > > > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. to unsubscribe send a message to 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 Jul 26 02:22:38 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00276 for ; Wed, 26 Jul 2000 02:22:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HJls-0009H9-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 22:30:20 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HJls-0009H3-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 22:30:20 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HJlh-000Lh8-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 22:30:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> Date: Tue, 25 Jul 2000 21:22:29 +0200 To: Roy Arends , DNS Extensions WG From: Harald Tveit Alvestrand Subject: Re: Null-key priority during key-clash. In-Reply-To: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 15:35 25/07/2000 +0200, Roy Arends wrote: >This is noticed by the example.org owner and the >Real-Key is immediatly removed from the example.org zone. I thought this would read "is replaced by a NULL key" or "is replaced by a new key" - why would a security-aware admin *remove* a KEY record rather than replacing it with a sensible one? DNSSEC was designed without revocation lists; your scenario seems a consequence of that decision. Harald -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.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 Jul 26 02:23:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00583 for ; Wed, 26 Jul 2000 02:23:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HJuu-0009ZM-00 for namedroppers-data@psg.com; Tue, 25 Jul 2000 22:39:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HJuu-0009ZG-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 22:39:40 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HJuu-000LlB-00 for namedroppers@ops.ietf.org; Tue, 25 Jul 2000 22:39:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 25 Jul 2000 22:37:04 -0700 (PDT) Message-Id: <200007260537.WAA26628@gulag.araneus.fi> To: Josh Littlefield CC: Peter Koch , "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt In-Reply-To: <397E3029.977B371D@cisco.com> References: <39768A2D.A74AEB5B@ehsco.com> <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> <200007251756.KAA26189@gulag.araneus.fi> <397E3029.977B371D@cisco.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Josh Littlefield said: > I think attention to section 7.18 of RFC2136 may induce caution with the > discussion of necessary and/or real glue. > > While its important that a slave recognize the boundaries of the zone, and > that the master not send a bunch of random stuff, its also essential that > the master sends, and that the slave retains, all records considered part of > the zone, whether necessary glue or not. Well said. > Based on the "occluding zone cut" case in this section of 7.18, its > important that a full zone transfer, followed by an incremental which > removes the zone cut, leaves the slave with the correct state of the zone, > which will include the newly exposed records. I agree that this is the correct behavior, but since this is an issue specific to IXFR, it would be more appropriate to bring it up in the IXFR specification than in the AXFR one. > [...] but it could be read as > the server choosing to include a subset of the configured zone data > in the transfer. That was not the intent. > The server should take care in what is allowed to be configured > in the zone, but once configured it should all be transferred. Yes. In particular, in slave servers, such "configuring data in the zone" is done by means of incoming zone transfers, and "taking care in what is allowed to be configured" may involve discarding some of the RRs in the incoming transfer, but all zone data retained by the server MUST be transmitted in outgoing transfers. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 04:37:10 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04502 for ; Wed, 26 Jul 2000 04:37:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HMBw-000DwP-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 01:05:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HMBw-000DwJ-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 01:05:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HMBw-000Mki-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 01:05:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 26 Jul 2000 10:03:27 +0200 (CEST) From: Roy Arends To: "Donald E. Eastlake 3rd" cc: DNS Extensions WG Subject: Re: Is this a possible DoS scenario within DNSSEC ? In-Reply-To: <200007260104.VAA18389@torque.pothole.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 25 Jul 2000, Donald E. Eastlake 3rd wrote: > DNSSEC does not claim to provide any protection against denial of > service. If you get data from an insecure cache, it could be > anything. Certainly it could have been diddled in a number of ways so > that signatures would fail. In fact, you have no idea whether what > you are getting is what is really in the cache or some bad guy is > answering for the caching server or corrupting the answers in transit. > If the cache were secure and supported the service, you could use TSIG > or SIG(0) transaction signatures with it and at least distinguish > between the data being bad or the communications being corrupted. But > then again, if the cache were secure and knew the zone you were > retrieving from was signed and could verify it, it would be nice it if > wouldn't add an RR so as to break a verified signature. And if the > caching server were secure using policies you liked and will handle > will handle recursive requests for you, there is no particular reason > for your resovler to be secure. It might as well use TSIG with the > cacing server it trusts.... Okay, clear. Thanks. We will use this in the Best Current Practice document we are working on. Regards, Roy Arends, NLnet Labs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 04:42:50 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05725 for ; Wed, 26 Jul 2000 04:42:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HMQy-000ETs-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 01:20:56 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HMQx-000ETm-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 01:20:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HMQx-000Mr7-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 01:20:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 26 Jul 2000 10:20:22 +0200 (CEST) From: Roy Arends To: Harald Tveit Alvestrand cc: DNS Extensions WG Subject: Re: Null-key priority during key-clash. In-Reply-To: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 25 Jul 2000, Harald Tveit Alvestrand wrote: > At 15:35 25/07/2000 +0200, Roy Arends wrote: > >This is noticed by the example.org owner and the > >Real-Key is immediatly removed from the example.org zone. > > I thought this would read "is replaced by a NULL key" or "is replaced by a > new key" - why would a security-aware admin > *remove* a KEY record rather than replacing it with a sensible one? For a secure resolver, there is no null-key without it's parents SIG (regardless if example.org replaces the old key with a null-key in the zone). Ofcourse, as soon as the parent issues a SIG for the null-key, the child (or parent) can put it in the child's apex. The issue here is that the old key is still very much alive regardless its removal/replacement by the example.org zone. A possible solution is to give more priority to the NULL-key when there is a KEY clash. > DNSSEC was designed without revocation lists; Yep, but time is the revocation method in DNSSEC. > your scenario seems a consequence of that decision. Not exactly, I'm suggesting a possible solution. Thanks, Regards, Roy Arends, NLnet Labs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 10:57:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23604 for ; Wed, 26 Jul 2000 10:57:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HSB6-000KBK-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 07:28:56 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HSB5-000KBE-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 07:28:55 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HSB5-000OvT-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 07:28:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007261341.IAA00588@gungnir.fnal.gov> To: Ted.Lindgreen@tednet.nl Cc: DNS Extensions WG From: "Matt Crawford" Subject: Re: Is this a possible DoS scenario within DNSSEC ? In-reply-to: Your message of Wed, 26 Jul 2000 00:22:42 +0200. <200007252222.AAA30381@open.nlnetlabs.nl> Date: Wed, 26 Jul 2000 08:41:56 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I suppose a clever implementation with cycles to spare might try every subset of an rrset whose SIG was found to be bad ... to unsubscribe send a message to 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 Jul 26 10:57:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23625 for ; Wed, 26 Jul 2000 10:57:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HRvz-000Jvs-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 07:13:19 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HRvy-000Jvm-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 07:13:18 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HRvy-000OpT-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 07:13:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gson@nominum.com (Andreas Gustafsson) Cc: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement References: <200007241234.OAA21559@grimsvotn.TechFak.Uni-Bielefeld.DE> <200007251650.JAA26163@gulag.araneus.fi> In-Reply-To: gson@nominum.com's message of "Tue, 25 Jul 2000 09:50:51 -0700 (PDT)" From: Simon Josefsson Date: 26 Jul 2000 13:35:32 +0200 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit gson@nominum.com (Andreas Gustafsson) writes: > > (The "no-" prefix is necessery to make sure that base32 encoded domain > > names doesn't start with 0-9, which is forbidden.) > > No, it's not. Consider for example the IN-ADDR.ARPA tree, where > most labels consist solely of digits. Also see RFC2181 section 11. You're right. So, it would be possible to drop the base32 encoding from the draft. RFC 2181 indicate this, but I'm not familiar with if existing servers handle it correctly, are they? It has also been suggested that a new EDNS label could be used, for storing hashed domain names. /Simon to unsubscribe send a message to 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 Jul 26 11:14:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26299 for ; Wed, 26 Jul 2000 11:14:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HSKo-000KNZ-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 07:38:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HSKn-000KNT-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 07:38:57 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HSKn-000Ozx-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 07:38:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: References: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> Date: Wed, 26 Jul 2000 10:36:33 -0400 To: Roy Arends From: Edward Lewis Subject: (background) Re: Null-key priority during key-clash. Cc: DNS Extensions WG Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 4:20 AM -0400 7/26/00, Roy Arends wrote: >On Tue, 25 Jul 2000, Harald Tveit Alvestrand wrote: >> DNSSEC was designed without revocation lists; > >Yep, but time is the revocation method in DNSSEC. This email doesn't come to a point, but it explains other answers I may give on the original thread... Harald's point is correct. Sorry not to answer sooner, but it took a lot longer to get back home from the ICANN/INET meetings. Revocation means "I no longer meant what I said." To put a fine point on it, time is not a revokation method in DNSSEC. For example, let's say I issue a SIG with a validity period of August. If on August 15th, I (as a server) want to have the SIG invalidated I would need to "revoke" it. The SIG record is not revoked on September 1st, it is "expired." The difference between the two is that when I (as a resolver) receive data, I can see its validity period and can use it within that constraint. If data is revoked, I probably won't know that when I receive the data - I need to be told it is revoked when the decision is made. Note that being told could be a "push" from the source to me, or a "pull" when I ask the source to refresh the revokation information. Here is some long winded background material that may explain my point of view: The facts that DNSSEC suffer from a lack of revokation and is suspect to denial of service are known, and are artifacts of the design of the system. I am pretty sure you can't completely solve these problems because of the nature of DNS. Recall that DNSSEC is designed to allow a resolver to be able to be sure the answer the resolver gets is truely from an authoritative source. DNSSEC does not protect the zone (server) and cannot guarantee that the resolver will get the best answer. Why is this? The nature of DNSSEC is that it is a backwards compatible extension to the DNS protocol, strengthening the DNS protocol in places where the protocol is vulnerable to an attack. DNSSEC has a couple of weaknesses, but I think that most of these can be traced to fundamental weaknesses in the DNS protocol. Here are some of the major underlying problems: 1) DNS is not real-time. DNS data carries no sequence information, with the exception of the SOA record. I.e., if you were to get two A record sets for a name from two sources, you can't tell which is more recent. 2) DNS is loosely coupled between servers and clients. When a server changes the data for a zone, it has no means to contact and update the resolvers that have asked for information. 3) DNS provides no explicit (modular) authoritative data in a zone that it has made a delegation. I.e., the parent inserts the NS record, but is not responsible for the data in it. As far as point 1, DNSSEC adds validity periods to SIG records which verify sets of data. But this is done so that we can limit the damage done by a key's exposure. If you were to receive two validly signed sets of data for a domain name/type/class, which would you trust? The one with later validity start period? This isn't specified anywhere. The way I deal with this is that a DNSSEC SIG record merely indicates that the data you see came from someone with the private key generating the signature. This way you can pin-point the source, or at least who to ask whether the data is valid (in case of a key exposure). DNSSEC does not prevent bad data and attacks. Don't rely too heavily on the SIG record alone for protection. As far as point 2, if a zone changes it's mind, it has always and will remain to be vigilant that old data maybe floating through DNS. There's no way for a server to alert users that it's data that data has been changed. Since this is not possible, it is not possible to secure the action. (I can't secure nothing.) As far as point 3, I threw this in for "completeness" - it's not germaine here, but is the reason why delegation points are a pain in the DNSSEC. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 11:29:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00494 for ; Wed, 26 Jul 2000 11:29:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HSaL-000KjG-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 07:55:01 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HSaK-000KjA-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 07:55:00 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HSaK-000P6X-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 07:55:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: Date: Wed, 26 Jul 2000 10:50:29 -0400 To: Roy Arends From: Edward Lewis Subject: Re: Is this a possible DoS scenario within DNSSEC ? Cc: DNS Extensions WG Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 8:10 AM -0400 7/25/00, Roy Arends wrote: >A SIG record covers RR Sets. Consider a caching server (not secured), >which has cached the following: ... >The SIG above validates the two NS records. At one point the cache >gets spoofed with for instance: > >example.org. NS very.ugly.org. > >Upon a query for these records, the cache server will respond with all 3 >NS records and the SIG record. ... > >Is this a possible scenario ? I think this scenario is incorrect. If a cache (secured or not) has data for a name/type/class and receives different data for the same triplet, the cache is supposed to retain one and drop the other. Caches are not supposed to merge data. The clarify RFC explicitly states this. Any caching server merging data is in violation of the spec. As far as which set is retained, which is dropped - in the pre-DNSSEC days, the "credibility" level was used (see also Clarify RFC). Data arriving in the answer section was more credible than additional data, etc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 11:55:11 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09322 for ; Wed, 26 Jul 2000 11:55:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HT6c-000LWu-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 08:28:22 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HT6b-000LWo-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 08:28:21 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HT6b-000PLQ-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 08:28:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 26 Jul 2000 17:19:44 +0200 (CEST) From: Roy Arends To: Edward Lewis cc: DNS Extensions WG Subject: Re: Is this a possible DoS scenario within DNSSEC ? In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 26 Jul 2000, Edward Lewis wrote: > At 8:10 AM -0400 7/25/00, Roy Arends wrote: > >A SIG record covers RR Sets. Consider a caching server (not secured), > >which has cached the following: > ... > >The SIG above validates the two NS records. At one point the cache > >gets spoofed with for instance: > > > >example.org. NS very.ugly.org. > > > >Upon a query for these records, the cache server will respond with all 3 > >NS records and the SIG record. > ... > > > >Is this a possible scenario ? > > I think this scenario is incorrect. If a cache (secured or not) has data > for a name/type/class and receives different data for the same triplet, the > cache is supposed to retain one and drop the other. > > Caches are not supposed to merge data. The clarify RFC explicitly states > this. Any caching server merging data is in violation of the spec. Yes, you are correct. RFC 2181 sec 5.4 and 5.3.1 explicitly states this. Thank you for pointing this out. Roy Arends NLnet Labs to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 12:19:09 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14870 for ; Wed, 26 Jul 2000 12:19:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HTC7-000LfS-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 08:34:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HTC6-000LfM-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 08:34:02 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HTC6-000POR-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 08:34:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397F034B.69EB3C9D@cisco.com> Date: Wed, 26 Jul 2000 11:27:07 -0400 From: Josh Littlefield To: Andreas Gustafsson CC: Peter Koch , "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt References: <39768A2D.A74AEB5B@ehsco.com> <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> <200007251756.KAA26189@gulag.araneus.fi> <397E3029.977B371D@cisco.com> <200007260537.WAA26628@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andreas Gustafsson wrote: >> Based on the "occluding zone cut" case in this section of 7.18, its >> important that a full zone transfer, followed by an incremental which >> removes the zone cut, leaves the slave with the correct state of the zone, >> which will include the newly exposed records. > > I agree that this is the correct behavior, but since this is an issue > specific to IXFR, it would be more appropriate to bring it up in the > IXFR specification than in the AXFR one. I generall agree, but IXFR and AXFR are not independent. A slave with no data must always start with an AXFR, since there is no way to request a full IXFR (perhaps there should be, but the feeling has been that AXFR serves that purpose). So, AXFR must support communicating data which remains meaningful after a subsequent IXFR. > Yes. In particular, in slave servers, such "configuring data in the > zone" is done by means of incoming zone transfers, and "taking care in > what is allowed to be configured" may involve discarding some of the > RRs in the incoming transfer, but all zone data retained by the server > MUST be transmitted in outgoing transfers. Well, its this discarding of data by slaves which I think is problematic, and where this clarification is essential. I do not think a slave should discard records considered non-essential, such as random, non-glue records beneath a zone cut. It should not expose them, but it should not discard them if it expects to recieve an IXFR in the future. A slave can freely discard records of the wrong class, or not beneath the zone in any way, since these can never be exposed by changes to the zone in the future. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 to unsubscribe send a message to 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 Jul 26 12:59:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20989 for ; Wed, 26 Jul 2000 12:59:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HTyC-000Mmx-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 09:23:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HTyB-000Mmr-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 09:23:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HTyB-0001Bj-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 09:23:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 26 Jul 2000 09:20:31 -0700 (PDT) Message-Id: <200007261620.JAA27007@gulag.araneus.fi> To: Simon Josefsson CC: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement In-Reply-To: References: <200007241234.OAA21559@grimsvotn.TechFak.Uni-Bielefeld.DE> <200007251650.JAA26163@gulag.araneus.fi> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> (The "no-" prefix is necessery to make sure that base32 encoded domain >>> names doesn't start with 0-9, which is forbidden.) >> >> No, it's not. Consider for example the IN-ADDR.ARPA tree, where >> most labels consist solely of digits. Also see RFC2181 section 11. > > You're right. So, it would be possible to drop the base32 encoding > from the draft. Not the encoding, just the "no-" prefix. The base32 encoding (or equivalent, personally I would prefer base16) is still necessary becase of case folding. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 13:10:23 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23410 for ; Wed, 26 Jul 2000 13:10:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HU9f-000N47-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 09:35:35 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HU9f-000N41-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 09:35:35 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HU9f-0001GQ-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 09:35:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4.3.2.7.2.20000725220039.00ae6980@localhost> Date: Wed, 26 Jul 2000 11:59:55 -0400 To: DNSEXT WG Mailing list From: Olafur Gudmundsson Subject: DNSEXT WG LC: IXFR to Draft Standard Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a last call on this document, IXFR defines a DNS protocol mechanism to allow two DNS servers compactly exchange changes to a zone both are authoritative for. The document contains minor clarifications from the original [RFC1995] all the changes are clarifications that have been suggested by implementation and inter-op testing experience. There are at least two implementations that are deemed to have implemented the whole specification and inter operate. This is a WG last call ending August 20'th 2000 (After WG chair returns from vacation). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ixfr-01.txt The URL for RFC1995 is http://www.ietf.org/rfc/rfc1995.txt This draft is on standards track, to be advanced to DRAFT standard if you disagree with the advancement please state why this document is not ready or if it should be recycled at Proposed. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 13:38:16 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29488 for ; Wed, 26 Jul 2000 13:38:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HUhq-000Nne-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 10:10:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HUhq-000NnY-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 10:10:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HUhp-0001Sd-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 10:10:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007261649.SAA27061@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement In-reply-to: Your message of "26 Jul 2000 13:35:32 +0200." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Wed, 26 Jul 2000 18:49:38 +0200 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > from the draft. RFC 2181 indicate this, but I'm not familiar with if > existing servers handle it correctly, are they? It has also been It would probably be kind of a benchmark. > suggested that a new EDNS label could be used, for storing hashed > domain names. That's a good idea because it could help solve another problem: What happens if I explicitly ask for the NO-RR attached to "no-42.example.org"? While that NO RR might exist, there's also information in the other NO RRs that the owner name "no-42.example.org" does not exist, because the NO RRs were constructed before they got inserted into the zone. You cannot change that without constructing and endless loop (or at least a chain as long as the "collision distance" of the underlying hash function). So, choosing a different namespace (I've thought about a CLASS "INC", like the "complement" to IN, but that won't work), e.g. by using another label type could solve this. That label in a query would lead to a direct answer, i.e. not hashed again. However, there is not yet much experience with the deployment of new label types and that might become the hard part. -Peter to unsubscribe send a message to 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 Jul 26 13:44:41 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01628 for ; Wed, 26 Jul 2000 13:44:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HUjv-000Nr2-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 10:13:03 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HUju-000Nqw-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 10:13:02 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HUju-0001TM-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 10:13:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397F1ABD.F02E889D@cisco.com> Date: Wed, 26 Jul 2000 13:07:09 -0400 From: Josh Littlefield To: Andreas Gustafsson CC: Peter Koch , "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt References: <39768A2D.A74AEB5B@ehsco.com> <200007201210.OAA12889@grimsvotn.TechFak.Uni-Bielefeld.DE> <200007251756.KAA26189@gulag.araneus.fi> <397E3029.977B371D@cisco.com> <200007260537.WAA26628@gulag.araneus.fi> <397F034B.69EB3C9D@cisco.com> <200007261648.JAA27020@gulag.araneus.fi> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andreas Gustafsson wrote: > Regarding records of the wrong class, I think those should be > considered protocol errors and cause the transfer as a whole to be > rejected with FORMERR. I believe I tried that in my implementation about 5 years ago. Didn't get very far when talking to some old BIND servers. Perhaps its a safer thing to do now, but I found it more practical to ignore the records of the wrong class. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 to unsubscribe send a message to 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 Jul 26 19:27:29 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24574 for ; Wed, 26 Jul 2000 19:27:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HZpA-0004t7-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 15:38:48 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HZpA-0004t1-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 15:38:48 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HZpA-0003Ru-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 15:38:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007261812.LAA45665@redpaul.mibh.net> To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt In-reply-to: Your message of "Wed, 26 Jul 2000 13:07:09 EDT." <397F1ABD.F02E889D@cisco.com> Date: Wed, 26 Jul 2000 11:12:39 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I believe I tried that in my implementation about 5 years ago. Didn't get > very far when talking to some old BIND servers. Perhaps its a safer thing > to do now, but I found it more practical to ignore the records of the wrong > class. BIND8 has had in it, for some time, the following logic: /* Parse class (IN, etc) */ someclass = sym_ston(__p_class_syms, buf, &success); if (success && someclass != zp->z_class) { ns_info(ns_log_load, "%s: Line %d: wrong class: %s.", filename, lineno, p_class(someclass)); errs++; break; } I think if there are old servers passing bad class info around in zone transfers, then they are failing to transfer them to BIND8 slaves, and already feeling whatever pain that can bring. Ignoring a subset of the zone's data and then treating what's left as authoritative is an error. Zones have identity. You're either serving the zone, the same zone the primary master is serving, or you're not. to unsubscribe send a message to 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 Jul 26 19:51:58 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27584 for ; Wed, 26 Jul 2000 19:51:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HaQq-0005oc-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 16:17:44 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HaQq-0005oW-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 16:17:44 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HaQq-0003i9-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 16:17:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 26 Jul 2000 13:42:02 -0700 (PDT) From: Brian Wellington To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 26 Jul 2000, Simon Josefsson wrote: > It has also been suggested that a new EDNS label could be used, for > storing hashed domain names. When first reading the draft, I thought that using a binary label (bitstring) would be a good choice, since it isn't subject to case folding. The problem is that it's a label type that isn't understood by most resolvers. It's fairly easy for a resolver to skip NXT records, since it's just an unknown type, but I wouldn't be surprised if there were resolvers that did very bad things when seeing an unknown label type. Using a new label type would be even worse, because there are some resolvers that understand binary labels, but none that would understand the new type. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 20:29:33 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02758 for ; Wed, 26 Jul 2000 20:29:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HapP-0006ec-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 16:43:07 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HapP-0006eR-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 16:43:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HapO-0003s0-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 16:43:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397F7037.ED2857D1@cisco.com> Date: Wed, 26 Jul 2000 19:11:51 -0400 From: Josh Littlefield To: Paul A Vixie CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-axfr-clarify-01.txt References: <200007261812.LAA45665@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie wrote: > Ignoring a subset of the zone's data and then treating what's left as > authoritative is an error. Zones have identity. You're either serving > the zone, the same zone the primary master is serving, or you're not. I agree, and that was my earlier point. On the question of invalid class, I think its a question of ignoring data which isn't part of the zone, because the zone is class-specific. But I'm glad BIND 8 tightened this up. I ran into the problem in the days of BIND 4.9.3, when UNIX vendors were shipping variants of 4.8 -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 to unsubscribe send a message to 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 Jul 26 20:30:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02832 for ; Wed, 26 Jul 2000 20:30:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HaOs-0005m3-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 16:15:42 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HaOs-0005lx-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 16:15:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HaOs-0003h5-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 16:15:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397F4984.FE11DE3B@ehsco.com> Date: Wed, 26 Jul 2000 13:26:44 -0700 From: "Eric A. Hall" To: namedroppers Subject: using AA in queries Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Is there room in the protocol for allowing resolvers to demand that an authoritative server be used to answer the query? For example, does it make sense to allow resolvers to set AA in the query message, and for compliant servers to recognize this bit as a demand that the query be referred/forwarded to an authoritative server for the domain name? Here's the scenario that prompted this: When sendmail tries to locate the server for a mail domain, it issues a query for ANY in an effort to get the A and MX records for the mail domain in a single response. Currently, some servers will treat a query for ANY specially, and will forward/refer the query to an authoritative server for the domain name, while some other servers do not do this and will answer the query using any data that is currently available in their cache (more often than not this is NS data for the domain, provided by the servers for the parent domain). In the latter case, sendmail has to deal with the incomplete response by generating multiple unique queries that explicit request the A and MX records for the domain. The obvious solution to this point problem is to require that queries for ANY be resolved by an authoritative server, although that seems like a heavy-handed solution to this particular problem. Instead, a broader solution would be to allow the client to specify Authority Required in the query message by setting the AA flag in the query message. This might also be useful for some of the security stuff, and might be useful for many other application-specific problems as well (getting SOA or RP records, for example). It might also be a way around some lameness problems, if a resolver knows they can reissue a query with AA if the original query seems to have failed for some reason. If the server was unable/unwilling to comply, it could still respond with AA cleared in the response message, and the resolver could either (A) accept the answer anyway, or (B) try another server. Is this a feasible extension? I'm sure somebody else has brought this up in the past; why didn't it fly? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Jul 26 20:39:00 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04745 for ; Wed, 26 Jul 2000 20:38:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Hb1y-00072A-00 for namedroppers-data@psg.com; Wed, 26 Jul 2000 16:56:06 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Hb1y-000724-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 16:56:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Hb1y-0003xo-00 for namedroppers@ops.ietf.org; Wed, 26 Jul 2000 16:56:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <397F797C.747BBCD3@daimlerchrysler.com> Date: Wed, 26 Jul 2000 19:51:24 -0400 From: Kevin Darcy To: DNS Extensions WG Subject: NOTIFY Extension? (was Re: (background) Re: Null-key priority during key-clash.) References: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > DNSSEC has a couple of weaknesses, but I think that most of these can be > traced to fundamental weaknesses in the DNS protocol. Here are some of > the major underlying problems: > > 1) DNS is not real-time. DNS data carries no sequence information, with > the exception of the SOA record. I.e., if you were to get two A record > sets for a name from two sources, you can't tell which is more recent. > > 2) DNS is loosely coupled between servers and clients. When a server > changes the data for a zone, it has no means to contact and update the > resolvers that have asked for information. > > [...] > > As far as point 2, if a zone changes it's mind, it has always and will > remain to be vigilant that old data maybe floating through DNS. There's no > way for a server to alert users that it's data that data has been changed. Is it time, perhaps, to start thinking of extending NOTIFY as suggested in RFC 1996, Section 1.2, i.e. to other purposes besides triggering zone transfers? >From what Ed says above, this may be useful from a DNSSEC standpoint, but my more immediate concern is all of the load-balancing and/or failover implementations these days which are setting TTL=0 on their address records in order to defeat caching. If NOTIFY could be used to "poke" caches to fetch changed versions of important RRsets, then maybe those TTL's could return to more reasonable values... (Obviously, some form of negotiation would be necessary -- probably using EDNS -- to determine whether the querier wants to receive the NOTIFY or not; there's no point in trying to poke a non-caching resolver). - 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 Jul 27 11:50:24 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22875 for ; Thu, 27 Jul 2000 11:50:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HpGM-0003Sn-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 08:07:54 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HpGJ-0003Sf-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 08:07:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HpGJ-0009p3-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 08:07:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007270938.LAA28544@grimsvotn.TechFak.Uni-Bielefeld.DE> To: "Eric A. Hall" Cc: namedroppers Subject: Re: using AA in queries In-reply-to: Your message of "Wed, 26 Jul 2000 13:26:44 PDT." <397F4984.FE11DE3B@ehsco.com> Date: Thu, 27 Jul 2000 11:38:25 +0200 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > make sense to allow resolvers to set AA in the query message, and for > compliant servers to recognize this bit as a demand that the query be > referred/forwarded to an authoritative server for the domain name? For that to work sufficiently all the still very old systems in the field (see e.g. Bill Manning's surveys) would have to be upgraded (silently assuming that those "servers" also act as full resolvers). Apart from that there are some drawbacks (see below). > Here's the scenario that prompted this: When sendmail tries to locate > the server for a mail domain, it issues a query for ANY in an effort to > get the A and MX records for the mail domain in a single response. Yes, and other MTAs act in a similar fashion, which sometimes leads to problems if the result to an "ANY" query is larger than fits into a DNS UDP packet. > Currently, some servers will treat a query for ANY specially, and will > forward/refer the query to an authoritative server for the domain name, > while some other servers do not do this and will answer the query using > any data that is currently available in their cache (more often than not RFC 1035 says "all", while "any" is usually implemented. > this is NS data for the domain, provided by the servers for the parent > domain). In the latter case, sendmail has to deal with the incomplete > response by generating multiple unique queries that explicit request the > A and MX records for the domain. So that optimization turns out not to be one? > The obvious solution to this point problem is to require that queries > for ANY be resolved by an authoritative server, although that seems like > a heavy-handed solution to this particular problem. Instead, a broader > solution would be to allow the client to specify Authority Required in > the query message by setting the AA flag in the query message. I see two alternatives: first, do not use the "ANY" trick; second (not yet available): with multiple entries in the query section (EDNSx) it might be possible to ask for "MX, else A". Anyway, even in the current situation, the ANY query should only fail the first time (in a given interval) because afterwards the MX RRSet sits in the local cache and will be delivered for subsequent queries, whereas with your proposed solution all the queries would hit the authoritative servers. > If the server was unable/unwilling to comply, it could still respond > with AA cleared in the response message, and the resolver could either > (A) accept the answer anyway, or (B) try another server. On the other hand it's likely to contribute to the problem should a resolver insist on an authoritative answer in case of "perfectly lame" delegations. We're seeing similar problems with negative answers every now and then. > Is this a feasible extension? I'm sure somebody else has brought this up > in the past; why didn't it fly? I'd worry about the future of DNS caching once the news is spread that you can request "more valuable" responses by setting the "AA" bit in the query. -Peter to unsubscribe send a message to 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 Jul 27 12:19:54 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26563 for ; Thu, 27 Jul 2000 12:19:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Hpo7-0004EW-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 08:42:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Hpo5-0004EQ-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 08:42:45 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Hpo5-000A7h-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 08:42:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <397F797C.747BBCD3@daimlerchrysler.com> References: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> Date: Thu, 27 Jul 2000 08:39:47 -0400 To: Kevin Darcy From: Edward Lewis Subject: Re: NOTIFY Extension? (was Re: (background) Re: Null-key priority during key-clash.) Cc: DNS Extensions WG Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 7:51 PM -0400 7/26/00, Kevin Darcy wrote: >Edward Lewis wrote: >> As far as point 2, if a zone changes it's mind, it has always and will >> remain to be vigilant that old data maybe floating through DNS. There's no >> way for a server to alert users that it's data that data has been changed. I used 'vigilant' in a message? Man, was I out of it yesterday... ;) >Is it time, perhaps, to start thinking of extending NOTIFY as suggested in >RFC 1996, Section 1.2, i.e. to other purposes besides triggering zone >transfers? >From what Ed says above, this may be useful from a DNSSEC >standpoint, but my more immediate concern is all of the load-balancing >and/or failover implementations these days which are setting TTL=0 on their >address records in order to defeat caching. If NOTIFY could be used to >"poke" caches to fetch changed versions of important RRsets, then maybe >those TTL's could return to more reasonable values... IMHO this would be a bad thing. The problem is knowing what entities a server would NOTIFY. We don't want to introduce a requirement that a server remembers all the resolvers that have queried it for information, nor do we want to impose a requirement that if A learns from B information that originated at C, A would register this learning with C. Within DNS there are really three sub-protocols, all sharing the same wire format but differentiated by processing and configuration information. General DNS resovler-server is a open community protocol. DNS primary-secondary protocol and the DNS stub resolver-defaul server are closed community protocols. Open community protocols are built to scale, to so this you have to suffer anonimity of actions. Servers of this type cannot be expected to bear the burden of maintaining state information about (all) individual clients - clients who may never return for more information. We can't have this in the general DNS resolver-server protocol and remain within the spirit of the DNS architecture. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 27 12:31:57 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28715 for ; Thu, 27 Jul 2000 12:31:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Hq2v-0004Z5-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 08:58:05 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Hq2v-0004Yz-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 08:58:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Hq2v-000AFT-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 08:58:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement References: <200007261649.SAA27061@grimsvotn.TechFak.Uni-Bielefeld.DE> From: Simon Josefsson In-Reply-To: Peter Koch's message of "Wed, 26 Jul 2000 18:49:38 +0200" Date: 27 Jul 2000 16:54:19 +0200 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Koch writes: > > suggested that a new EDNS label could be used, for storing hashed > > domain names. > > That's a good idea because it could help solve another problem: > What happens if I explicitly ask for the NO-RR attached to "no-42.example.org"? > While that NO RR might exist, there's also information in the other NO RRs > that the owner name "no-42.example.org" does not exist, because the NO RRs > were constructed before they got inserted into the zone. You cannot change > that without constructing and endless loop (or at least a chain as long > as the "collision distance" of the underlying hash function). I'm not sure I see the point here, why would you want to authenticate denial for NO records? I've made a change in the draft to point this out, ala "NO records (together with SIG) are used to authenticate denial of other types". But I'm not sure we should try very hard to make NO records authenticate denial for themself. Am I missing something? /Simon to unsubscribe send a message to 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 Jul 27 12:33:00 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28942 for ; Thu, 27 Jul 2000 12:32:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Hq62-0004do-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 09:01:18 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Hq61-0004da-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 09:01:17 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Hq61-000AH7-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 09:01:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian Wellington Cc: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement References: From: Simon Josefsson In-Reply-To: Brian Wellington's message of "Wed, 26 Jul 2000 13:42:02 -0700 (PDT)" Date: 27 Jul 2000 17:01:08 +0200 Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian Wellington writes: > > It has also been suggested that a new EDNS label could be used, for > > storing hashed domain names. > > When first reading the draft, I thought that using a binary label > (bitstring) would be a good choice, since it isn't subject to case > folding. The problem is that it's a label type that isn't understood by > most resolvers. It's fairly easy for a resolver to skip NXT records, > since it's just an unknown type, but I wouldn't be surprised if there were > resolvers that did very bad things when seeing an unknown label type. Would these bad things be any more harmful than not being able to authenticate denial for records? If so, I don't think it's worth persuing the idea, since a alternative that is backwards compatible can work equally well. to unsubscribe send a message to 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 Jul 27 12:54:05 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03614 for ; Thu, 27 Jul 2000 12:54:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HqVs-0005KB-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 09:28:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HqVr-0005K5-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 09:27:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HqVr-000AQy-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 09:27:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14720.25122.546945.589804@horsey.gshapiro.net> Date: Thu, 27 Jul 2000 09:24:02 -0700 (PDT) From: Gregory Neil Shapiro To: "Eric A. Hall" CC: pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org Subject: Re: using AA in queries In-Reply-To: References: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Note that I am not part of the namedroppers mailing list. A member of the list forwarded this message to me for comment. Please include me in any replies. >> Here's the scenario that prompted this: When sendmail tries to locate >> the server for a mail domain, it issues a query for ANY in an effort to >> get the A and MX records for the mail domain in a single response. Actually, this *only* happens when sendmail checks to make sure the host exists (dns_getcanonname()). At delivery time, it specifically asks for MX records, then AAAA and A records (getmxrr()). The use of T_ANY for looking up delivery information is a misconception. pk> Yes, and other MTAs act in a similar fashion, which sometimes leads to pk> problems if the result to an "ANY" query is larger than fits into a DNS pk> UDP packet. dns_getcanonname() deals with this situation (and variations). From the top of sendmail/domain.c: /* ** The standard udp packet size PACKETSZ (512) is not sufficient for some ** nameserver answers containing very many resource records. The resolver ** may switch to tcp and retry if it detects udp packet overflow. ** Also note that the resolver routines res_query and res_search return ** the size of the *un*truncated answer in case the supplied answer buffer ** it not big enough to accommodate the entire answer. */ As well as later in the code: /* ** If the ANY query is larger than the ** UDP packet size, the resolver will ** fall back to TCP. However, some ** misconfigured firewalls block 53/TCP ** so the ANY lookup fails whereas an MX ** or A record might work. Therefore, ** don't fail on ANY queries. ** ** The ANY query is really meant to prime ** the cache so this isn't dangerous. */ >> this is NS data for the domain, provided by the servers for the parent >> domain). In the latter case, sendmail has to deal with the incomplete >> response by generating multiple unique queries that explicit request the >> A and MX records for the domain. pk> So that optimization turns out not to be one? If the res_querydomain(..., T_ANY, ...) request returns -1 and (h_errno != TRY_AGAIN || h_errno != HOST_NOT_FOUND) then we try for individual MX, AAAA, or A records. However, if HOST_NOT_FOUND is returned, we do not go for the specific records. Likewise, if TRY_AGAIN is returned, we return a temporary error. to unsubscribe send a message to 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 Jul 27 13:09:08 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06229 for ; Thu, 27 Jul 2000 13:09:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HqpU-0005vA-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 09:48:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HqpT-0005v4-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 09:48:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HqpT-000AZi-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 09:48:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14720.26523.957630.630771@horsey.gshapiro.net> Date: Thu, 27 Jul 2000 09:47:23 -0700 (PDT) From: Gregory Neil Shapiro To: "Eric A. Hall" Cc: pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org Subject: Re: using AA in queries In-Reply-To: <39806578.4B9F67FD@ehsco.com> References: <14720.25122.546945.589804@horsey.gshapiro.net> <39806578.4B9F67FD@ehsco.com> X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> /* >> ** The ANY query is really meant to prime >> ** the cache so this isn't dangerous. >> */ ehall> Interesting. Is this a complete and true statement by itself? If so, my ehall> point example is false to begin with. Partially. In 99% of the cases, sendmail will canonify a hostname before delivery time. If that canonification is able to get the necessary information in cache (MX, AAAA, A records) into the cache, then it is successful in this goal since at delivery time, the specific MX and AAAA/A queries can be answered out of the cache. The comment is also meant to convey the fact that even if the T_ANY request fails, it doesn't break anything. to unsubscribe send a message to 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 Jul 27 13:09:17 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06254 for ; Thu, 27 Jul 2000 13:09:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Hqkm-0005n1-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 09:43:24 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Hqkm-0005mu-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 09:43:24 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Hqkm-000AXF-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 09:43:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39806578.4B9F67FD@ehsco.com> Date: Thu, 27 Jul 2000 09:38:16 -0700 From: "Eric A. Hall" To: Gregory Neil Shapiro CC: pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org Subject: Re: using AA in queries References: <14720.25122.546945.589804@horsey.gshapiro.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > /* > ** The ANY query is really meant to prime > ** the cache so this isn't dangerous. > */ Interesting. Is this a complete and true statement by itself? If so, my point example is false to begin with. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 27 13:49:38 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12843 for ; Thu, 27 Jul 2000 13:49:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HrCB-0006at-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 10:11:43 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HrCA-0006am-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 10:11:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HrCA-000AkG-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 10:11:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39806C27.73BC2A3F@ehsco.com> Date: Thu, 27 Jul 2000 10:06:47 -0700 From: "Eric A. Hall" To: Gregory Neil Shapiro CC: pk@TechFak.Uni-Bielefeld.DE, namedroppers@ops.ietf.org Subject: Re: using AA in queries References: <14720.25122.546945.589804@horsey.gshapiro.net> <39806578.4B9F67FD@ehsco.com> <14720.26523.957630.630771@horsey.gshapiro.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Partially. In 99% of the cases, sendmail will canonify a hostname > before delivery time. Ok, this is what we're talking about. The process above occurs with ANY, followed by A and MX when ANY fails. We're not talking about delivery yet, we're only talking about finding the servers for the mail domain (canonifying the target as you say). My point was that ANY fails on most external lookups because the servers for the destination domain's parent often answer a query of ANY with the NS records from the destination domain's delegation. For example, a.root-servers.net. responds to ANY query for ehsco.com. with NS records for ehsco.com. since those records satisfies the query for "all of the known RRs associated with ehsco.com." Thus, in those cases where mail is for a remote domain that has not been recently resolved, the query for ANY is almost guaranteed to fail and will be followed with two additional queries. However, since the Authority Section of the (incomplete) answer points to the authoritative servers for the mail domain, the A and MX queries go directly to the authoritative servers and are able to get answered immediately and completely. It would save a lot of work if ANY went to those servers in the first place is my thinking, and is an example of a proposed beneficary of an Authoritative Answer Required flag for queries. The other approach is not to use ANY at all, and just do A and MX in the first place. However, in those cases where the data is cached (such as would happen with recently or frequently resolved domains), using ANY is more efficient since it is just one transaction. Just trying to clearly identify what's going on. > at delivery time, the specific MX and AAAA/A queries can be answered > out of the cache. Yeah, but that's a different part of the cycle. Getting ANY answered correctly wouldn't affect that. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 27 14:16:47 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16501 for ; Thu, 27 Jul 2000 14:16:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Hrdm-0007JS-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 10:40:14 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Hrdm-0007JM-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 10:40:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Hrdm-000AxJ-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 10:40:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: "Eric A. Hall" Cc: Gregory Neil Shapiro , pk@TechFak.Uni-Bielefeld.DE, namedroppers@internic.net Subject: Re: using AA in queries In-Reply-To: Your message of "Thu, 27 Jul 2000 10:06:47 MST." <39806C27.73BC2A3F@ehsco.com> Date: Fri, 28 Jul 2000 03:35:59 +1000 Message-Id: <27187.964719359@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 27 Jul 2000 10:06:47 -0700 From: "Eric A. Hall" Message-ID: <39806C27.73BC2A3F@ehsco.com> | We're not talking about delivery | yet, we're only talking about finding the servers for the mail domain | (canonifying the target as you say). No, canonifying the target is testing whether it is an alias, and if so, substituting the RHS of the CNAME record. Using ANY to look for CNAME is generally successful, as if there are any RRs at all, then they must be the CNAME - otherwise no CNAME exists. The side-effect of perhaps getting other records into the local cache while determining that is just a mild efficiency hack (might as well get the auth server to send any data that exists, rather than just saying "no CNAME", if you end up talking to it). | My point was that ANY fails on most external lookups because the servers | for the destination domain's parent often answer a query of ANY with the | NS records from the destination domain's delegation. For example, | a.root-servers.net. responds to ANY query for ehsco.com. with NS records | for ehsco.com. since those records satisfies the query for "all of the | known RRs associated with ehsco.com." No, that has nothing whatever to do with ANY queries - any query at all sent to the root servers for that domain would return the same answer. That's a referral. | Thus, in those cases where mail is for a remote domain that has not been | recently resolved, the query for ANY is almost guaranteed to fail The local cache (resolver back end) should really be following any referral even if it was looking for ANY - it should be sending the ANY query to the auth servers. What broken server are you using that isn't doing that? (note: this assumes that there was no local cached data for the name previously - simply returning what is in the local cache is a useful optimisation, even if it does lead to some of the data not being available). | It would save a lot of work if ANY went to those servers in the first | place is my thinking, and is an example of a proposed beneficary of an | Authoritative Answer Required flag for queries. That should happen without any AA flag - the only difference the proposed AA would make would be if there was already data in the cache. For sendmail purposes that's irrelevant though, as that "other data" is all sendmail needs to know to know there is no CNAME. If the other data is not A or MX then the specific query will go look for that later. 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 Jul 27 14:52:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27073 for ; Thu, 27 Jul 2000 14:52:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HsDK-0008FR-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 11:16:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HsDK-0008FL-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 11:16:58 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HsDK-000BEX-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 11:16:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39807A38.7DADE972@ehsco.com> Date: Thu, 27 Jul 2000 11:06:48 -0700 From: "Eric A. Hall" To: Peter Koch CC: namedroppers Subject: Re: using AA in queries References: <200007270938.LAA28544@grimsvotn.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Peter Koch made some excellent points: > > make sense to allow resolvers to set AA in the query message, and > > for compliant servers to recognize this bit as a demand that the > > query be referred/forwarded to an authoritative server for the > > domain name? > > For that to work sufficiently all the still very old systems in the > field (see e.g. Bill Manning's surveys) would have to be upgraded > (silently assuming that those "servers" also act as full resolvers). This isn't necessarily true. The only systems that would need to support it are the stub resolvers that generate the queries, and the recursive servers that process those queries. All of the other servers in the world could be ignorant of the auth. desired mechanism, since only the recursive server would have to find an AA answer. In essence, the recursive server would ignore answers without AA set, and treat non-AA answers with authoritative data as referrals until it got to one of those authoritative servers. > the ANY query should only fail the first time (in a given interval) > because afterwards the MX RRSet sits in the local cache and will be > delivered for subsequent queries, whereas with your proposed solution > all the queries would hit the authoritative servers. In the proposal outlined, the use of Auth Desired should be limited to situations where a non-auth answer was already obtained that the client application knew to be either incomplete or wrong. For example, query for ANY results in incomplete answer, rather than following up with multiple queries for A and MX, issue another query for ANY with the Auth Desired flag set. This argument admittedly has pretty weak legs. I suppose this is where the idea really starts falling down, since we're back to multiple queries already. If the auth. desired query failed, then discrete queries would be necessary again, so extra cost would have been introduced for no real gain in some situations where an AA answer was not available. > I'd worry about the future of DNS caching once the news is spread > that you can request "more valuable" responses by setting the "AA" > bit in the query. Yeah, I guess. I'd think most implementations wouldn't bother with it, and the only applications that would do anything special would be the ones that needed absolute data. I guess my assumption is that most folks would be too lazy to do the extra coding unless it was really important for them to do it. > > Currently, some servers will treat a query for ANY specially, and > > will forward/refer the query to an authoritative server for the > > domain name, while some other servers do not do this and will > > answer the query using any data that is currently available in > > their cache (more often than not > > RFC 1035 says "all", while "any" is usually implemented. OK. Maybe the letter of the law is that "all" implies processing by a server that knows all records, not just any records. An auth. desired flag might still be useful in some other situations. I think you've successfully shot down this situation however. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 27 14:52:59 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27352 for ; Thu, 27 Jul 2000 14:52:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HsDV-0008Fd-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 11:17:09 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HsDU-0008FX-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 11:17:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HsDU-000BEd-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 11:17:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39807A3F.FB162262@ehsco.com> Date: Thu, 27 Jul 2000 11:06:55 -0700 From: "Eric A. Hall" To: Robert Elz CC: Gregory Neil Shapiro , pk@TechFak.Uni-Bielefeld.DE, namedroppers@internic.net Subject: Re: using AA in queries References: <27187.964719359@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Using ANY to look for CNAME is generally successful, as if there are > any RRs at all, then they must be the CNAME - otherwise no CNAME > exists. The side-effect of perhaps getting other records into the > local cache while determining that is just a mild efficiency hack > (might as well get the auth server to send any data that exists, > rather than just saying "no CNAME", if you end up talking to it). This clarifies things somewhat. > | My point was that ANY fails on most external lookups because the > | servers for the destination domain's parent often answer a query > | of ANY with the NS records from the destination domain's delegation. > | For example, a.root-servers.net. responds to ANY query for > | ehsco.com. with NS records for ehsco.com. since those records > | satisfies the query for "all of the known RRs associated with > | ehsco.com." > > No, that has nothing whatever to do with ANY queries - any query at > all sent to the root servers for that domain would return the same > answer. That's a referral. Queries for ANY return non-authoritative answer data, while queries for explicit types return referrals. ehall@Goose.NTRG.com> dig @a.root-servers.net. ehsco.com. ANY ; <<>> DiG 8.3 <<>> @a.root-servers.net. ehsco.com. any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 5, AUTHORITY: 5, ADDITIONAL: 5 ;; QUERY SECTION: ;; ehsco.com, type = ANY, class = IN ;; ANSWER SECTION: ehsco.com. 2D IN NS ARACHNID.ehsco.com. ehsco.com. 2D IN NS NAMESERVER.CONCENTRIC.NET. ehsco.com. 2D IN NS NAMESERVER3.CONCENTRIC.NET. ehsco.com. 2D IN NS NAMESERVER2.CONCENTRIC.NET. ehsco.com. 2D IN NS NAMESERVER1.CONCENTRIC.NET. ;; AUTHORITY SECTION: ehsco.com. 2D IN NS ARACHNID.ehsco.com. ehsco.com. 2D IN NS NAMESERVER.CONCENTRIC.NET. ehsco.com. 2D IN NS NAMESERVER3.CONCENTRIC.NET. ehsco.com. 2D IN NS NAMESERVER2.CONCENTRIC.NET. ehsco.com. 2D IN NS NAMESERVER1.CONCENTRIC.NET. ;; ADDITIONAL SECTION: ARACHNID.ehsco.com. 2D IN A 209.31.7.46 NAMESERVER.CONCENTRIC.NET. 2D IN A 207.155.183.72 NAMESERVER3.CONCENTRIC.NET. 2D IN A 206.173.119.72 NAMESERVER2.CONCENTRIC.NET. 2D IN A 207.155.184.72 NAMESERVER1.CONCENTRIC.NET. 2D IN A 207.155.183.73 ;; Total query time: 364 msec ;; FROM: Goose.NTRG.com to SERVER: a.root-servers.net. 198.41.0.4 ;; WHEN: Thu Jul 27 10:56:14 2000 ;; MSG SIZE sent: 27 rcvd: 317 ehall@Goose.NTRG.com> dig @a.root-servers.net. ehsco.com. MX ; <<>> DiG 8.3 <<>> @a.root-servers.net. ehsco.com. MX ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5 ;; QUERY SECTION: ;; ehsco.com, type = MX, class = IN ;; AUTHORITY SECTION: ehsco.com. 2D IN NS ARACHNID.ehsco.com. ehsco.com. 2D IN NS NAMESERVER.CONCENTRIC.NET. ehsco.com. 2D IN NS NAMESERVER3.CONCENTRIC.NET. ehsco.com. 2D IN NS NAMESERVER2.CONCENTRIC.NET. ehsco.com. 2D IN NS NAMESERVER1.CONCENTRIC.NET. ;; ADDITIONAL SECTION: ARACHNID.ehsco.com. 2D IN A 209.31.7.46 NAMESERVER.CONCENTRIC.NET. 2D IN A 207.155.183.72 NAMESERVER3.CONCENTRIC.NET. 2D IN A 206.173.119.72 NAMESERVER2.CONCENTRIC.NET. 2D IN A 207.155.184.72 NAMESERVER1.CONCENTRIC.NET. 2D IN A 207.155.183.73 ;; Total query time: 363 msec ;; FROM: Goose.NTRG.com to SERVER: a.root-servers.net. 198.41.0.4 ;; WHEN: Thu Jul 27 11:02:18 2000 ;; MSG SIZE sent: 27 rcvd: 247 Returns NS answers for ANY, referrals for explicits. The ANY query is completely processed and returned to the calling process with the answer data. > | It would save a lot of work if ANY went to those servers in the > | first place is my thinking, and is an example of a proposed > | beneficary of an Authoritative Answer Required flag for queries. > > That should happen without any AA flag This seems to be a common refrain. I will submit a bug report for BIND. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Jul 27 20:01:49 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06058 for ; Thu, 27 Jul 2000 20:01:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13HwoL-000F8a-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 16:11:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13HwoK-000F8O-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 16:11:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13HwoK-000DIP-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 16:11:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3980B7C8.3FD6C70F@daimlerchrysler.com> Date: Thu, 27 Jul 2000 18:29:28 -0400 From: Kevin Darcy To: DNS Extensions WG Subject: Re: NOTIFY Extension? (was Re: (background) Re: Null-key priorityduring key-clash.) References: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 7:51 PM -0400 7/26/00, Kevin Darcy wrote: > >Edward Lewis wrote: > >> As far as point 2, if a zone changes it's mind, it has always and will > >> remain to be vigilant that old data maybe floating through DNS. There's no > >> way for a server to alert users that it's data that data has been changed. > > I used 'vigilant' in a message? Man, was I out of it yesterday... ;) > > >Is it time, perhaps, to start thinking of extending NOTIFY as suggested in > >RFC 1996, Section 1.2, i.e. to other purposes besides triggering zone > >transfers? >From what Ed says above, this may be useful from a DNSSEC > >standpoint, but my more immediate concern is all of the load-balancing > >and/or failover implementations these days which are setting TTL=0 on their > >address records in order to defeat caching. If NOTIFY could be used to > >"poke" caches to fetch changed versions of important RRsets, then maybe > >those TTL's could return to more reasonable values... > > IMHO this would be a bad thing. The problem is knowing what entities a > server would NOTIFY. We don't want to introduce a requirement that a > server remembers all the resolvers that have queried it for information, > nor do we want to impose a requirement that if A learns from B information > that originated at C, A would register this learning with C. I wasn't thinking of this as a *mandatory* requirement. The client would request the server to notify it of any future changes to the data it is fetching. The server chooses to accept or decline this request. Even if the server accepts the request, if it runs into some (hopefully configurable) resource limits, it would still be allowed to "forget" that it gave a particular answer to a particular client. Nothing would be mandatory. Everything would be on a "best efforts" basis, and thus imperfect. But at least I think it would be better than all of the TTL=0 crap that's coming increasingly into vogue... > Within DNS there are really three sub-protocols, all sharing the same wire > format but differentiated by processing and configuration information. > General DNS resovler-server is a open community protocol. DNS > primary-secondary protocol and the DNS stub resolver-defaul server are > closed community protocols. > > Open community protocols are built to scale, to so this you have to suffer > anonimity of actions. Servers of this type cannot be expected to bear the > burden of maintaining state information about (all) individual clients - > clients who may never return for more information. > > We can't have this in the general DNS resolver-server protocol and remain > within the spirit of the DNS architecture. Reasonable people can disagree, of course, about what that "spirit" is or is not. I think it's perfectly within the spirit of modern DNS for two nameservers to participate in a mutually-agreed-upon optional extension to the protocol. Isn't that what EDNS options were invented for, after all? - 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 Jul 27 20:53:26 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11727 for ; Thu, 27 Jul 2000 20:53:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13Hxlk-000GfJ-00 for namedroppers-data@psg.com; Thu, 27 Jul 2000 17:12:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13Hxlj-000GfD-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 17:12:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13Hxlj-000Djh-00 for namedroppers@ops.ietf.org; Thu, 27 Jul 2000 17:12:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 27 Jul 2000 17:11:50 -0700 (PDT) From: Brian Wellington To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: NO RR draft announcement In-Reply-To: Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 27 Jul 2000, Simon Josefsson wrote: > Brian Wellington writes: > > > > It has also been suggested that a new EDNS label could be used, for > > > storing hashed domain names. > > > > When first reading the draft, I thought that using a binary label > > (bitstring) would be a good choice, since it isn't subject to case > > folding. The problem is that it's a label type that isn't understood by > > most resolvers. It's fairly easy for a resolver to skip NXT records, > > since it's just an unknown type, but I wouldn't be surprised if there were > > resolvers that did very bad things when seeing an unknown label type. > > Would these bad things be any more harmful than not being able to > authenticate denial for records? If so, I don't think it's worth > persuing the idea, since a alternative that is backwards compatible > can work equally well. Got me. That's the point - I don't know if all resolvers properly handle unknown label types. New record types are added fairly often, but until binary labels, no new label types had been introduced for a long time. I don't think it's possible to fully parse a message containing an unknown label type. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 28 11:18:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13716 for ; Fri, 28 Jul 2000 11:18:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13IBD6-000AIH-00 for namedroppers-data@psg.com; Fri, 28 Jul 2000 07:34:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13IBD6-000AIB-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 07:34:00 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13IBD6-000K02-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 07:34:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 28 Jul 2000 16:11:56 +0200 To: Kevin Darcy , DNS Extensions WG From: Harald Alvestrand Subject: Re: NOTIFY Extension? (was Re: (background) Re: Null-key priorityduring key-clash.) In-Reply-To: <3980B7C8.3FD6C70F@daimlerchrysler.com> References: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit At 18:29 27/07/2000 -0400, Kevin Darcy wrote: >I think it's perfectly within the spirit of modern DNS for two nameservers to >participate in a mutually-agreed-upon optional extension to the protocol. >Isn't >that what EDNS options were invented for, after all? that's what EDNS0.5 features were invented for (among other things). EDNS version numbers is a quite different kettle of fish. Harald -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 28 11:57:31 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26643 for ; Fri, 28 Jul 2000 11:57:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13IBqe-000BJe-00 for namedroppers-data@psg.com; Fri, 28 Jul 2000 08:14:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13IBqe-000BJY-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 08:14:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13IBqe-000KGj-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 08:14:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3981A0C9.C307B1AB@daimlerchrysler.com> Date: Fri, 28 Jul 2000 11:03:37 -0400 From: Kevin Darcy To: DNS Extensions WG Subject: Re: NOTIFY Extension? (was Re: (background) Re: Null-keypriorityduring key-clash.) References: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> <4.3.2.7.2.20000728161059.05c353e0@127.0.0.1> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Oh? I've read the EDNS0.5 draft quite thoroughly (I thought) and I think it's a great idea. However, my impression was that these "features" were only for extensions which were expected to eventually be folded into the main protocol spec for all clients and servers. Full-blown EDNS options, on the other hand, still have a place when only _certain_ clients and _certain_ servers want to use extensions between themselves. Plus, I took EDNS0.5 features to be basically binary-valued, i.e. either you request/support/comply with the feature or you don't. Options allow extra data to be sent. I'm thinking that this "Change Notification" option, for instance, might allow the requestor to optionally specify a key or some kind of token so that only NOTIFY's "authenticated" with that key/token will be acted upon. This is to try and ward off a certain kind of Denial-of-Service attack, e.g. bad guy X spoofs a NOTIFY from Y, causing Z to resend a huge RRset or ANY query, thus amplifying the attack. - Kevin Harald Alvestrand wrote: > At 18:29 27/07/2000 -0400, Kevin Darcy wrote: > >I think it's perfectly within the spirit of modern DNS for two nameservers to > >participate in a mutually-agreed-upon optional extension to the protocol. > >Isn't > >that what EDNS options were invented for, after all? > > that's what EDNS0.5 features were invented for (among other things). > EDNS version numbers is a quite different kettle of fish. > > Harald > > -- > Harald Tveit Alvestrand, alvestrand@cisco.com > +47 41 44 29 94 > Personal email: Harald@Alvestrand.no to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 28 14:55:48 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12013 for ; Fri, 28 Jul 2000 14:55:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13IEhP-000FkD-00 for namedroppers-data@psg.com; Fri, 28 Jul 2000 11:17:31 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13IEhO-000Fk7-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 11:17:30 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13IEhO-000LZX-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 11:17:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <3980B7C8.3FD6C70F@daimlerchrysler.com> References: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> Date: Fri, 28 Jul 2000 14:13:02 -0400 To: Kevin Darcy From: Edward Lewis Subject: Re: NOTIFY Extension? (was Re: (background) Re: Null-key priorityduring key-clash.) Cc: DNS Extensions WG Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 6:29 PM -0400 7/27/00, Kevin Darcy wrote: >I think it's perfectly within the spirit of modern DNS for two nameservers to >participate in a mutually-agreed-upon optional extension to the protocol. >Isn't >that what EDNS options were invented for, after all? I had interpreted your message to mean extending NOTIFY to be a means to notify (stub) resolvers of updates to servers they had contacted. Still, outside of grouping name servers into sets begin authoritative for a zone, DNS is still an open community protocol. Before attempting to define an extension to NOTIFY as you are suggesting, we'd need to define a way to group servers together in a more general set. (E.g., all the servers running in my network - regardless of zone.) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 28 20:48:45 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08855 for ; Fri, 28 Jul 2000 20:48:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13IK0M-000MrI-00 for namedroppers-data@psg.com; Fri, 28 Jul 2000 16:57:26 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13IK0M-000MrC-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 16:57:26 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13IK0M-000NxR-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 16:57:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39821CC5.A2658022@daimlerchrysler.com> Date: Fri, 28 Jul 2000 19:52:37 -0400 From: Kevin Darcy To: DNS Extensions WG Subject: Re: NOTIFY Extension? (was Re: (background) Re: Null-key priorityduring key-clash.) References: <4.3.2.7.2.20000725212020.060a2100@dokka.maxware.no> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis wrote: > At 6:29 PM -0400 7/27/00, Kevin Darcy wrote: > >I think it's perfectly within the spirit of modern DNS for two nameservers to > >participate in a mutually-agreed-upon optional extension to the protocol. > >Isn't > >that what EDNS options were invented for, after all? > > I had interpreted your message to mean extending NOTIFY to be a means to > notify (stub) resolvers of updates to servers they had contacted. Sorry, perhaps I wasn't clear. The NOTIFY would only be sent to a resolver that had asked for it. And generally speaking there wouldn't be any incentive for a non-caching resolver, like a stub resolver, to ask for the NOTIFY, since it has no cache entries to refresh. > Still, outside of grouping name servers into sets begin authoritative for a > zone, DNS is still an open community protocol. Before attempting to define > an extension to NOTIFY as you are suggesting, we'd need to define a way to > group servers together in a more general set. (E.g., all the servers > running in my network - regardless of zone.) Not to be glib, but isn't this an implementation detail? The implementation just needs to know the set of who has requested to be NOTIFY'ed and then NOTIFY them if the RRset changes. How it maintains that knowledge -- what data structures are used, whether it is maintained in volatile or non-volatile storage, whether it is purely dynamic or the administrator can also specify addresses which should *always* receive NOTIFYs for a particular RRset, etc. -- seems to me not a part of the protocol _per_se_. Note that in terms of conserving capacity, the server can age out of the dynamic NOTIFY set any targets that it knows will have already expired their entries (based on when they last fetched the RRset and what its TTL value was at the time); those targets will be fetching a new version of the RRset when they need it anyway, so the NOTIFY is not necessary. This means that the administrator can tune the amount of storage required for the NOTIFY set indirectly by manipulating the TTL's on the records. For machines short on memory (or disk space, if that's where it's storing the NOTIFY set), maybe the TTL's would be tuned down to an hour, 30 minutes, 15 minutes, or whatever. That's not great, but it's still better for the Internet DNS infrastructure as a whole than TTL=0, especially in the case of popular RRset's. - 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 Jul 28 20:57:18 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10687 for ; Fri, 28 Jul 2000 20:57:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13IKI1-000NDQ-00 for namedroppers-data@psg.com; Fri, 28 Jul 2000 17:15:41 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13IKI1-000NDJ-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 17:15:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13IKI1-000O5D-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 17:15:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007281506.RAA02020@grimsvotn.TechFak.Uni-Bielefeld.DE> To: "Eric A. Hall" Cc: Gregory Neil Shapiro , namedroppers@internic.net Subject: Re: using AA in queries In-reply-to: Your message of "Thu, 27 Jul 2000 11:06:55 PDT." <39807A3F.FB162262@ehsco.com> Date: Fri, 28 Jul 2000 17:06:46 +0200 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> No, that has nothing whatever to do with ANY queries - any query at >> all sent to the root servers for that domain would return the same >> answer. That's a referral. > > Queries for ANY return non-authoritative answer data, while queries for > explicit types return referrals. > > ehall@Goose.NTRG.com> dig @a.root-servers.net. ehsco.com. ANY a.root-servers.net (like "F" and "G") not only serves "." but also "COM", so of course an ANY query returns the NS RRs (as would an explicit NS query), while an MX query is answered by a referral (due to non-recursiveness). The NS RR responses are not authoritative because they are the delegation info from the parent (COM) zone. No magic. -Peter to unsubscribe send a message to 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 Jul 28 21:06:51 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12775 for ; Fri, 28 Jul 2000 21:06:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13IKYd-000Nai-00 for namedroppers-data@psg.com; Fri, 28 Jul 2000 17:32:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13IKYd-000Nac-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 17:32:51 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13IKYd-000OC9-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 17:32:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3981A742.5D6C70B5@ehsco.com> Date: Fri, 28 Jul 2000 08:31:14 -0700 From: "Eric A. Hall" To: Peter Koch CC: Gregory Neil Shapiro , namedroppers@internic.net Subject: Re: using AA in queries References: <200007281506.RAA02020@grimsvotn.TechFak.Uni-Bielefeld.DE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ please continue this over in dnsop -- randy ] > a.root-servers.net (like "F" and "G") not only serves "." but also > "COM", Just because I sent the dig query to a.gtld-servers.net. doesn't mean that it's the only server that's returning incomplete answers to queries for ANY. This behavior manifests whenever a query for ANY encounters a BIND server in the last-hop delegation, so the same thing happens with *.gtld-servers.net., various places within the ccTLD delegation trees, and also within private delegations (punch in "dig @ns.ibm.com. chips.ibm.com. ANY" for example). It happens everwhere. > so of course an ANY query returns the NS RRs (as would an explicit > NS query), while an MX query is answered by a referral (due to > non-recursiveness). If you believe that "all records" is satisfied by "RRs I know about", then yes "of course" it does. > The NS RR responses are not authoritative because they are the > delegation info from the parent (COM) zone. No magic. Yep. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Jul 28 21:16:03 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14710 for ; Fri, 28 Jul 2000 21:16:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13IKlt-000Nua-00 for namedroppers-data@psg.com; Fri, 28 Jul 2000 17:46:33 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13IKlt-000NuU-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 17:46:33 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13IKls-000OI7-00 for namedroppers@ops.ietf.org; Fri, 28 Jul 2000 17:46:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200007290043.RAA61584@redpaul.mibh.net> To: namedroppers@internic.net Subject: Re: using AA in queries In-reply-to: Your message of "Fri, 28 Jul 2000 17:06:46 +0200." <200007281506.RAA02020@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Fri, 28 Jul 2000 17:43:59 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Queries for ANY return non-authoritative answer data, while queries for >> explicit types return referrals. >> > a.root-servers.net (like "F" and "G") not only serves "." but also "COM", > so of course an ANY query returns the NS RRs (as would an explicit NS query), > while an MX query is answered by a referral (due to non-recursiveness). > The NS RR responses are not authoritative because they are the delegation > info from the parent (COM) zone. No magic. note that bind8 wrongly sends back an answer for ANY and NS queries while bind9 correctly sends back a referral in both cases since the authoritative answer has to come from the authority zone rather than the delegating zone. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Jul 29 09:18:07 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17367 for ; Sat, 29 Jul 2000 09:18:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13IVoy-000CaD-00 for namedroppers-data@psg.com; Sat, 29 Jul 2000 05:34:28 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.13 #1) id 13IVoy-000Ca1-00 for namedroppers@ops.ietf.org; Sat, 29 Jul 2000 05:34:28 -0700 Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13IVox-0003V2-00 for namedroppers@ops.ietf.org; Sat, 29 Jul 2000 05:34:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 29 Jul 2000 06:47:37 -0000 Message-ID: <20000729064737.6343.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@internic.net Subject: Re: using AA in queries References: <200007281506.RAA02020@grimsvotn.TechFak.Uni-Bielefeld.DE> <200007290043.RAA61584@redpaul.mibh.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie writes: > note that bind8 wrongly sends back an answer for ANY and NS queries > while bind9 correctly sends back a referral in both cases since the > authoritative answer has to come from the authority zone rather than > the delegating zone. Caches around the net will still save the NS records from the parent and give them to clients on subsequent requests. There's no guarantee that the child NS records will show up to replace the parent NS records in the cache before this happens. If the child servers are unreachable for a few seconds, for example, then the client's retry of its * query will be answered by the parent's NS records, rather than timing out. As for ``wrongly'': The BIND 8 behavior and the cache behavior are entirely permissible under RFC 1034 and RFC 1035. Under those RFCs, the way to stop the roots from spreading bad data for (say) munnari.oz.au is to avoid giving them bad data in the first place. ---Dan P.S. My server sends back a referral in this situation. I found this much easier to implement than the BIND 8 behavior. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Jul 30 02:10:12 2000 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04726 for ; Sun, 30 Jul 2000 02:10:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.13 #1) id 13IlJE-0004uh-00 for namedroppers-data@psg.com; Sat, 29 Jul 2000 22:06:44 -0700 Received: from wired-128-197.ietf.marconi.com ([147.73.128.197] helo=roam.psg.com) by psg.com with esmtp (Exim 3.13 #1) id 13IlJD-0004uY-00 for namedroppers@ops.ietf.org; Sat, 29 Jul 2000 22:06:43 -0700 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13IlIx-0000FE-00 for namedroppers@ops.ietf.org; Sat, 29 Jul 2000 22:06:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: namedroppers@internic.net Subject: Re: using AA in queries In-Reply-To: Your message of "29 Jul 2000 06:47:37 GMT." <20000729064737.6343.qmail@cr.yp.to> Date: Sun, 30 Jul 2000 06:44:08 +1000 Message-Id: <22435.964903448@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: 29 Jul 2000 06:47:37 -0000 From: "D. J. Bernstein" Message-ID: <20000729064737.6343.qmail@cr.yp.to> | Caches around the net will still save the NS records from the parent and | give them to clients on subsequent requests. That's true, and relatively harmless. | As for ``wrongly'': The BIND 8 behavior and the cache behavior are | entirely permissible under RFC 1034 and RFC 1035. Perhaps. And perhaps this is another area that could do with some clarification. I would have thought (and obviously did so in the earlier message I sent) that a server sending referrals should send just referrals (ie: if RA isn't set, and the server isn't authoritative). On the other hand, if the server will attempt to return answers (RA is set, and the request contained RD) then returning the delegation (glue) NS records as answers is just fine (as well as returning them in the auth section, though I always thought returning the same RRs twice in an answer as bordering on stupidity). | Under those RFCs, the | way to stop the roots from spreading bad data for (say) munnari.oz.au is | to avoid giving them bad data in the first place. If only it were easy to make them do that. Unfortunately, the broken and totally bogus database used (not BIND, the thing they use to create the zone files for BIND) insists on returning only half of the RRset that is munnari.oz.au's A records. If you have any insights on how to convince them to fix that broken behaviour, please advise... | P.S. My server sends back a referral in this situation. I found this | much easier to implement than the BIND 8 behavior. And much more correct I believe. 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.