From owner-namedroppers@ops.ietf.org Mon Feb 5 17:43:12 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19604 for ; Mon, 5 Feb 2001 17:43:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ptjs-00039n-00 for namedroppers-data@psg.com; Mon, 05 Feb 2001 14:04:00 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14Ptjp-00039Y-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 14:03:58 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14Plox-0000Qx-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 14:36:43 +0100 content-class: urn:content-classes:message Subject: RFC 2782 (SRV RRs) Interop testing report MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C087C1.52B145E2" Date: Fri, 26 Jan 2001 09:56:35 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657404082A64@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: RFC 2782 (SRV RRs) Interop testing report Thread-Index: AcCHwVB3bVB1BXIoTIu/Q1fOOo3OFg== From: "Levon Esibov" To: X-OriginalArrivalTime: 26 Jan 2001 17:56:35.0825 (UTC) FILETIME=[530E2E10:01C087C1] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C087C1.52B145E2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I compiled a formal report on the interop testing of the RFC 2782 (A DNS RR for specifying the location of services (DNS SRV)) that we conducted last Summer in Pittsburgh at IETF-48. The report is attached. - Levon ------_=_NextPart_001_01C087C1.52B145E2 Content-Type: text/plain; name="RFC2782_SRV_Interop_Testing_Report.txt" Content-Description: RFC2782_SRV_Interop_Testing_Report.txt Content-Disposition: attachment; filename="RFC2782_SRV_Interop_Testing_Report.txt" Content-Transfer-Encoding: base64 VGVzdGVkIFJGQzoNClJGQyAyNzgyICJBIEROUyBSUiBmb3Igc3BlY2lmeWluZyB0aGUgbG9jYXRp b24gb2Ygc2VydmljZXMgKEROUyBTUlYpIg0KDQpEYXRlOiBBdWd1c3QgMSwgMjAwMA0KUGxhY2U6 IERvdWJsZSBUcmVlIEhvdGVsLCBQaXR0c2J1cmdoLCBQQSwgVVNBLg0KDQpQYXJ0aWNpcGF0ZWQg aW1wbGVtZW50YXRpb25zDQpBCUNoZWNrcG9pbnQgOC4yLjMtdDZiCQkJCShLZXZpbiBEdW5sYXAp DQpCCUNpc2NvIENOUiAoYnVpbGQgMzUzKQkJCQkoSm9zaCBMaXR0bGVmaWVsZCkNCkMJSVNDIEJJ TkQgOC4yLjMtdDZiCQkJCShNYXJrIEFuZHJld3MpDQpECUx1Y2VudCBRSVAgMy4wCQkJCQkoQWxl eGlzIE1hY0ZhcmxhbmUpDQpFCU1pY3Jvc29mdCBXaW5kb3dzIDIwMDAgRE5TIHNlcnZlcgkJKExl dm9uIEVzaWJvdikNCkYJTWljcm9zb2Z0IFdoaXN0bGVyIEROUyBzZXJ2ZXIgKGJ1aWxkIDIyNTMp CShTdHVhcnQgS3dhbikNCkcJTm9taW51bSBCSU5EIDkuMS4wYQkJCQkoQW5kcmVhcyBHdXN0YWZz c29uKQ0KDQoNClJ1bm5pbmcgb24gbmV0d29yayAxMC4wLjAuMC84Lg0KDQpUZXN0IHpvbmUgd2Fz IHNydi5pbmQudGVzdC4NCkluIGFkZGl0aW9uIHRvIHRoZSBTT0EgYW5kIE5TIHJlY29yZHMgYXQg dGhlIHRvcCBvZiB0aGUgem9uZSwgdGhlIHpvbmUNCmNvbnRhaW5lZCB0aGUgZm9sbG93aW5nIHJl Y29yZHM6DQpfa2VyYmVyb3MuX3RjcCAgICAgICAgICBTUlYJMCAwIDg4CS4NCl9sZGFwLl90Y3Ag ICAgICAgICAgICAgIFNSVgkwIDAgMzg5CXRhcmdldC5zcnYuaW5kLnRlc3QuDQp0YXJnZXQgICAg ICAgICAgICAgICAgICBBCTEuMi4zLjQNCg0KRE5TIHNlcnZlciBFIHdhcyBjb25maWd1cmVkIGFz IHByaW1hcnkgc2VydmVyIGZvciB0aGUgem9uZSBzcnYuaW5kLnRlc3QuDQpBbGwgb3RoZXIgRE5T IHNlcnZlcnMgKGkuZS4gQSwgQiwgQywgRCwgRiBhbmQgRykgd2VyZSBjb25maWd1cmVkIGFzDQpz ZWNvbmRhcnkgRE5TIHNlcnZlcnMgZm9yIHRoZSB6b25lIHNydi5pbmQudGVzdC4gd2l0aCBFIERO UyBzZXJ2ZXIgYXMgdGhlDQpNYXN0ZXIgc2VydmVyIGZvciB0aGUgem9uZS4NCg0KVGhlIGZpcnN0 IHJvdW5kIG9mIHRlc3RzIGVuc3VyZWQgcHJvcGVyIHRyYW5zbWlzc2lvbiBvZiByZXNvdXJjZSBy ZWNvcmRzDQpvZiB0eXBlIFNSViBpbiBhIHpvbmUgdHJhbnNmZXIgZnJvbSBvbmUgc2VydmVyIHRv IGFub3RoZXIgQU5EIHRoZSBhYmlsaXR5DQpvZiB0aGUgRE5TIHNlcnZlcnMgdG8gcmVzcG9uZCB0 byB0aGUgcXVlcmllcyBmb3IgdGhlIHJlc291cmNlIHJlY29yZHMgb2YNCnR5cGUgU1JWOg0KQWZ0 ZXIgZXZlcnkgc2Vjb25kYXJ5IEROUyBzZXJ2ZXIgd2FzIGNvbmZpZ3VyZWQgd2l0aCBETlMgc2Vy dmVyIEUgYXMgaXRzDQpNYXN0ZXIgZm9yIHRoZSB6b25lIHNydi5pbmQudGVzdC4gYW5kIGFmdGVy IHpvbmUgdHJhbnNmZXJzIHRvb2sgcGxhY2UsDQpOU0xPT0tVUCB0b29sIGluc3RhbGxlZCBvbiB0 aGUgV2luZG93cyAyMDAwIFNlcnZlciB3YXMgdXNlZCB0byBzZW5kIHRvIHRoZQ0Kc2Vjb25kYXJ5 IHNlcnZlcnMgKG9uZSBhdCBhIHRpbWUpIHF1ZXJpZXMgZm9yIHRoZSByZXNvdXJjZSByZWNvcmRz IG9mIHR5cGUNClNSViBmb3IgdGhlIG5hbWVzIF9rZXJiZXJvcy5fdGNwLnNydi5pbmQudGVzdC4g YW5kIF9sZGFwLl90Y3Auc3J2LmluZC50ZXN0Lg0KVGhlIHJlc3BvbnNlcyBmcm9tIHRoZSBzZWNv bmRhcnkgc2VydmVycyB3ZXJlIHZlcmlmaWVkIHRvIG1hdGNoIHRoZSBTUlYNCnJlc291cmNlIHJl Y29yZHMgc3BlY2lmaWVkIGluIHRoZSBwcmltYXJ5IGNvcHkgb2YgdGhlIHNydi5pbmQudGVzdC4g em9uZS4NCg0KVGhlIHNlY29uZCByb3VuZCBvZiB0ZXN0cyBlbnN1cmVkIHRoYXQgdGhlIEROUyBz ZXJ2ZXJzIHByb3Blcmx5IHN0b3JlIGFuZA0KbG9hZCBTUlYgcmVzb3VyY2UgcmVjb3JkczoNCkV2 ZXJ5IHNlY29uZGFyeSBETlMgc2VydmVyIHJlbG9hZGVkIHRoZSBzZWNvbmRhcnkgem9uZS4gUHJl c2VuY2UgYW5kDQpjb3JyZWN0bmVzcyBvZiB0aGUgRE5TIFNSViByZWNvdXJzZSByZWNvcmRzIHdh cyBlbnN1cmVkIGJ5IGNoZWNraW5nIHRoZQ0Kem9uZSBmaWxlIGNvbnRhaW5pbmcgdGhlIHJlY29y ZHMgYW5kIGJ5IHJlcGVhdGluZyB0aGUgc2V0IG9mIHRoZSBTUlYNCnF1ZXJpZXMgdXNlZCBpbiB0 aGUgZmlyc3Qgc2VyaWVzIG9mIHRlc3RzIGFuZCB2ZXJpZnlpbmcgdGhhdCB0aGUgcmV0dXJuZWQN CmluIHRoZSBxdWVyeSByZXNwb25zZSByZWNvcmRzIG1hdGNoIHRoZSBTUlYgcmVjb3JkcyBzcGVj aWZpZWQgaW4gdGhlDQpwcmltYXJ5IGNvcHkgb2YgdGhlIHpvbmUgc3J2LmluZC50ZXN0Lg0KDQpG aW5hbGx5LCB0byBlbnN1cmUgdGhhdCB0aGUgRE5TIHNlcnZlciBFIHRoYXQgc2VydmVkIGFzIHBy aW1hcnkgRE5TIHNlcnZlcg0KaW4gdGhlIGludGVyb3BlcmFiaWxpdHkgdGVzdGluZyAoYW5kIHRo ZXJlZm9yZSB3YXMgbm90IHN1YmplY3RlZCB0byB0aGUNCnNhbWUgdGVzdGluZyBhcyBhbGwgb3Ro ZXIgc2Vjb25kYXJ5IHNlcnZlcnMpIGFsc28gcGFzc2VzIHRoZSBzYW1lIHRlc3RzLA0KaXQgd2Fz IGNvbmZpZ3VyZWQgYXMgYSBzZWNvbmRhcnkgRE5TIHNlcnZlciBmb3IgdGhlIHpvbmUgc3J2Lmlu ZC50ZXN0Lg0Kd2l0aCBETlMgc2VydmVyIEYgYmVpbmcgaXRzIE1hc3Rlci4gVGhlbiB0aGUgc2Ft ZSBzZXQgb2YgdGVzdHMgKGFzIGRlc2NyaWJlZA0KYWJvdmUpIHdhcyBhcHBsaWVkIHRvIHRoZSBE TlMgc2VydmVyIEUgYW5kIGl0IHBhc3NlZCBhbGwgdGhlIHRlc3RzLg0KDQpCeSBtb25pdG9yaW5n IG5ldHdvcmsgdHJhZmZpYyBpdCB3YXMgdmVyaWZpZWQgdGhhdCBub25lIG9mIHRoZSBETlMgc2Vy dmVyDQppbXBsZW1lbnRhdGlvbnMgdXNlIG5hbWUgY29tcHJlc3Npb24gaW4gdGhlIHRhcmdldCBm aWVsZCBvZiB0aGUgUkRBVEEgb2YNCnRoZSBTUlYgcmVzb3VyY2UgcmVjb3Jkcy4NCg0KDQpUaGUg Y29uY2x1c2lvbiBvZiB0aGUgcGFydGljaXBhbnRzIG9mIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHRl c3Rpbmc6DQpUaGUgdGVzdGluZyBkZW1vbnN0cmF0ZXMgZnVsbCBjb21wbGlhbmNlIG9mIHNldmVu IGltcGxlbWVudGF0aW9ucyBvZiB0aGUNCkROUyBzZXJ2ZXJzIHdpdGggYWxsIHJlcXVpcmVtZW50 cyBvZiB0aGUgUkZDIDI3ODIu ------_=_NextPart_001_01C087C1.52B145E2-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 5 17:43:14 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19615 for ; Mon, 5 Feb 2001 17:43:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ptjv-0003AC-00 for namedroppers-data@psg.com; Mon, 05 Feb 2001 14:04:03 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14Ptju-00039p-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 14:04:03 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14Plo8-0000Qt-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 14:35:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200101261816.NAA16811@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: DNS Security Extension Clarification on Zone Status to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 26 Jan 2001 13:16:53 -0500 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 DNS Security Extension Clarification on Zone Status 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 February 8, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.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 Mon Feb 5 17:43:35 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19628 for ; Mon, 5 Feb 2001 17:43:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ptlm-0003Db-00 for namedroppers-data@psg.com; Mon, 05 Feb 2001 14:05:58 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14Ptlk-0003DT-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 14:05:57 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14Pljj-0000QH-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 14:31:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200101261700.MAA14721@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: Indicating Resolver Support of DNSSEC to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 26 Jan 2001 12:00:00 -0500 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 Indicating Resolver Support of DNSSEC 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 February 8, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-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 Mon Feb 5 17:43:49 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19639 for ; Mon, 5 Feb 2001 17:43:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Pthi-00036O-00 for namedroppers-data@psg.com; Mon, 05 Feb 2001 14:01:46 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14Pthf-000369-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 14:01:43 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14PpeW-00016O-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 18:42:12 +0100 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14NZu7-000MG6-00 for namedroppers@ops.ietf.org; Tue, 30 Jan 2001 04:28:59 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03759; Tue, 30 Jan 2001 07:28:58 -0500 (EST) Message-Id: <200101301228.HAA03759@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-03.txt Date: Tue, 30 Jan 2001 07:28:58 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC and IPv6 A6 aware server/resolver message size requirements Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-message-size-03.txt Pages : 6 Date : 29-Jan-01 This document mandates support for EDNS0 in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back 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-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-message-size-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-message-size-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010129102655.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-message-size-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-message-size-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010129102655.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 5 17:45:30 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19713 for ; Mon, 5 Feb 2001 17:45:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Ptju-0003A2-00 for namedroppers-data@psg.com; Mon, 05 Feb 2001 14:04:02 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14Ptjs-00039e-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 14:04:01 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14PrhK-0001YL-00 for namedroppers@ops.ietf.org; Mon, 05 Feb 2001 20:53:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received: from randy by psg.com with local (Exim 3.16 #1) id 14OHT6-000KVm-00 for namedroppers@ops.ietf.org; Thu, 01 Feb 2001 03:00:00 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Thu, 01 Feb 2001 03:00:00 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 6 07:01:13 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11200 for ; Tue, 6 Feb 2001 07:01:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Q6Nc-000FuA-00 for namedroppers-data@psg.com; Tue, 06 Feb 2001 03:33:52 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14Q6Nb-000FtB-00 for namedroppers@ops.ietf.org; Tue, 06 Feb 2001 03:33:52 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14Q5LU-0001xn-00 for namedroppers@ops.ietf.org; Tue, 06 Feb 2001 05:27:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102022202.RAA01390@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 02 Feb 2001 17:02:48 -0500 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 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) 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 February 16, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-02.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 6 15:23:08 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00869 for ; Tue, 6 Feb 2001 15:23:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QDm7-000OQj-00 for namedroppers-data@psg.com; Tue, 06 Feb 2001 11:27:39 -0800 Received: from [166.60.14.81] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14QDm7-000OQP-00 for namedroppers@ops.ietf.org; Tue, 06 Feb 2001 11:27:39 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14QDlb-0000cY-00 for namedroppers@ops.ietf.org; Tue, 06 Feb 2001 14:27:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102061922.OAA28755@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: DNSSEC and IPv6 A6 aware server/resolver message size requirements to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 06 Feb 2001 14:22:42 -0500 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 DNSSEC and IPv6 A6 aware server/resolver message size requirements 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 February 20, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-03.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 Wed Feb 7 01:04:28 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12251 for ; Wed, 7 Feb 2001 01:04:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QNA5-0008nY-00 for namedroppers-data@psg.com; Tue, 06 Feb 2001 21:29:01 -0800 Received: from [147.28.4.2] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14QNA4-0008nQ-00 for namedroppers@ops.ietf.org; Tue, 06 Feb 2001 21:29:00 -0800 Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14QNA1-0000x4-00 for namedroppers@ops.ietf.org; Tue, 06 Feb 2001 21:28:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 6 Feb 2001 20:03:09 -0500 (EST) From: Steve WANG To: namedroppers@ops.ietf.org Subject: Server side: Secure DNS dynamic update In-Reply-To: <4.3.2.7.2.20010117231030.02748310@nordic.cisco.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In case that you are interested, we have a paper to enhance the security of DNS zone key management to allow DNS dynamic update. It is available at http://www.cs.gmu.edu/~xwang4/acsac00.ps Thanks, Steve to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 7 14:54:51 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07661 for ; Wed, 7 Feb 2001 14:54:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QZms-000KhQ-00 for namedroppers-data@psg.com; Wed, 07 Feb 2001 10:57:54 -0800 Received: from sd-raptor-ext.veriosc.com ([207.67.241.50]) by psg.com with smtp (Exim 3.16 #1) id 14QZmr-000KhK-00 for namedroppers@ops.ietf.org; Wed, 07 Feb 2001 10:57:54 -0800 Received: from dhcp1.veriosd.net by sd-raptor-ext.veriosc.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 7 Feb 2001 18:59:09 UT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14QZmu-0001c5-00 for namedroppers@ops.ietf.org; Wed, 07 Feb 2001 10:57:56 -0800 Message-ID: <3A819507.3B32C44C@ehsco.com> Date: Wed, 07 Feb 2001 10:33:43 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers Subject: SRV and TC flag Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I see a potential problem with the wording in RFC 2782 regarding truncated answer sets, and am wondering if the wording needs to be changed. I don't know if this is a significant enough change to cause procedural problems with the document, but it seems like a minor change albeit one that is necessary for proper functionality. Page 7 of RFC 2728 says: - If a truncated response comes back from an SRV query, the rules described in [RFC 2181] shall apply. Item 9 on page 11 of 2181 says: Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. By a strict reading, the use of "should" in 2181 allows an SRV client application to use an incomplete SRV RRset. This is bad IMO. I believe that SRV clients which receive truncated SRV RRsets MUST discard the incomplete list and reissue the query over TCP. The reasoning for this is the same as the reasoning for the same requirement for MX RRsets, as stated in section 6.1.3.2 of RFC 1123: A mailer must not use a truncated MX response, since this could lead to mail loops. The same kind of problems can occur with any use of SRV which results in a prioritized list. Although the current application-specific uses of SRV are not fatally wounded by an incomplete priority list, future uses of SRV may be. EG, if SMTP were a (unlikely) future use, SRV would be less functional than MX under the current rules. Any application which requires a prioritized answer list for message routing would also suffer. IMO, any RR which provides weighted answers MUST discard truncated RRset responses in order for the weighting to have any value. -- 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 Feb 7 16:19:46 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09139 for ; Wed, 7 Feb 2001 16:19:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QbG3-000MGv-00 for namedroppers-data@psg.com; Wed, 07 Feb 2001 12:32:07 -0800 Received: from sd-raptor-ext.veriosc.com ([207.67.241.50]) by psg.com with smtp (Exim 3.16 #1) id 14QbG2-000MGp-00 for namedroppers@ops.ietf.org; Wed, 07 Feb 2001 12:32:06 -0800 Received: from dhcp1.veriosd.net by sd-raptor-ext.veriosc.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 7 Feb 2001 20:33:22 UT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14QbG4-0001hl-00 for namedroppers@ops.ietf.org; Wed, 07 Feb 2001 12:32:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 Feb 2001 12:19:38 -0800 (PST) Message-Id: <200102072019.MAA01132@gulag.araneus.fi> To: "Eric A. Hall" Cc: namedroppers Subject: Re: SRV and TC flag In-Reply-To: <3A819507.3B32C44C@ehsco.com> References: <3A819507.3B32C44C@ehsco.com> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric A. Hall writes: > I see a potential problem with the wording in RFC 2782 regarding truncated > answer sets, and am wondering if the wording needs to be changed. I don't > know if this is a significant enough change to cause procedural problems > with the document, but it seems like a minor change albeit one that is > necessary for proper functionality. > > Page 7 of RFC 2728 says: > > - If a truncated response comes back from an SRV query, the rules > described in [RFC 2181] shall apply. > > Item 9 on page 11 of 2181 says: > > Where TC is set, the partial RRSet that would not completely fit may > be left in the response. When a DNS client receives a reply with TC > set, it should ignore that response, and query again, using a > mechanism, such as a TCP connection, that will permit larger replies. > > By a strict reading, the use of "should" in 2181 allows an SRV client > application to use an incomplete SRV RRset. I would interpret that "should" as a MUST rather than a SHOULD because of RFC2181 section 3: 3. Terminology This memo does not use the oft used expressions MUST, SHOULD, MAY, or their negative forms. In some sections it may seem that a specification is worded mildly, and hence some may infer that the specification is optional. That is not correct. Anywhere that this memo suggests that some action should be carried out, or must be carried out, or that some behaviour is acceptable, or not, that is to be considered as a fundamental aspect of this specification, regardless of the specific words used. If some behaviour or action is truly optional, that will be clearly specified by the text. -- 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 Feb 8 03:48:49 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02965 for ; Thu, 8 Feb 2001 03:48:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Qm9n-0007vS-00 for namedroppers-data@psg.com; Thu, 08 Feb 2001 00:10:23 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Qm9m-0007vM-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 00:10:22 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Qm9m-0006kS-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 00:10:22 -0800 Message-ID: <3A81FB24.71969332@ehsco.com> Date: Wed, 07 Feb 2001 17:49:25 -0800 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 Subject: Re: SRV and TC flag References: <3A819507.3B32C44C@ehsco.com> <200102072019.MAA01132@gulag.araneus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I would interpret that "should" as a MUST rather than a SHOULD > because of RFC2181 section 3: I have gone through it three times now, but whenever I read 2181 I still come away with a wishy washy mandate: "hey you know you really ought to discard these incomplete answers but if it's too much trouble, that's cool too man." What I'm saying is that I would really feel more comfortable about the integrity of various SRV client implementations if the wording in 2728 was adament to the point of military precision: "you MUST discard SRV RRset responses with TC enabled." Either that or a clarification to 2181 stating something along the lines of: "any RRs which require sorting by the client (MX, SRV, future), must be complete, so any responses with TC enabled must be discarded." I know it's a hassle to change stuff in-process but I really think this needs to be clearly stated one way or the other. My complaint has been made, the synaptic pressure has been relieved. -- 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 Feb 8 03:55:31 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02997 for ; Thu, 8 Feb 2001 03:55:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Qm5u-0007kB-00 for namedroppers-data@psg.com; Thu, 08 Feb 2001 00:06:22 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Qm5s-0007k4-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 00:06:20 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Qm5s-0006gt-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 00:06:20 -0800 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14977.60038.973395.391834@davenant.relativity.greenend.org.uk> Date: Thu, 8 Feb 2001 00:38:30 +0000 (GMT) To: iesg@ietf.org Cc: namedroppers@ops.ietf.org Subject: Re: Last Call: DNS Security Extension Clarification on Zone Status to Proposed Standard Newsgroups: chiark.mail.ietf.announce In-Reply-To: <200101261816.NAA16811@ietf.org> References: <200101261816.NAA16811@ietf.org> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just one minor comment on draft-ietf-dnsext-zone-status-04.txt: 3 Experimental Status ... special designation of an experimentally secure status. Experimentally secured is a special case of globally secured. A zone administrator ^^^^^^^^ I think this should read `locally' ? Ian. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 8 04:02:56 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03109 for ; Thu, 8 Feb 2001 04:02:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QmLJ-000862-00 for namedroppers-data@psg.com; Thu, 08 Feb 2001 00:22:17 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14QmLI-00085w-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 00:22:16 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14QmLI-0006u6-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 00:22:16 -0800 From: Robert Elz To: "Eric A. Hall" cc: namedroppers Subject: Re: SRV and TC flag In-reply-to: Your message of "Wed, 07 Feb 2001 10:33:43 PST." <3A819507.3B32C44C@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Feb 2001 14:33:02 +0700 Message-ID: <2108.981617582@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 07 Feb 2001 10:33:43 -0800 From: "Eric A. Hall" Message-ID: <3A819507.3B32C44C@ehsco.com> | By a strict reading, the use of "should" in 2181 allows What Andreas said... | IMO, any RR which provides weighted answers MUST discard truncated RRset | responses in order for the weighting to have any value. Any RR, regardless of weighted answers. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 8 10:02:05 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09229 for ; Thu, 8 Feb 2001 10:02:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Qry6-000CrS-00 for namedroppers-data@psg.com; Thu, 08 Feb 2001 06:22:42 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Qry6-000CrM-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 06:22:42 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Qry6-000BHz-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 06:22:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102081322.FAA61504@redpaul.mfnx.net> To: namedroppers Subject: Re: SRV and TC flag In-Reply-To: Message from "Eric A. Hall" of "Wed, 07 Feb 2001 17:49:25 PST." <3A81FB24.71969332@ehsco.com> Date: Thu, 08 Feb 2001 05:22:22 -0800 From: Paul A Vixie X-DCC-MAPS-Metrics: isrv3.isc.org 668; IP=0+many env_From=0+813 From=0+5874 Subject=0+1 Message-ID=0+1 Received=0+1 Body=0+1 Fuz1=0+1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I have gone through it three times now, but whenever I read 2181 I still > come away with a wishy washy mandate: "hey you know you really ought to > discard these incomplete answers but if it's too much trouble, that's cool > too man." Such an implementation would not be standards compliant. RFC2136 goes into some detail about the atomicity of rrsets. RFC1034/35 is less clear but equally insistent. If 2181 seems wishy-washy then let's upgrade the wording. RRsets are atomic. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Feb 8 11:12:58 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11839 for ; Thu, 8 Feb 2001 11:12:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QtH2-000EDw-00 for namedroppers-data@psg.com; Thu, 08 Feb 2001 07:46:20 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14QtH1-000EDq-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 07:46:19 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14QtH1-000CCG-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 07:46:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Paul A Vixie Cc: namedroppers Subject: Re: SRV and TC flag References: <3A81FB24.71969332@ehsco.com> <200102081322.FAA61504@redpaul.mfnx.net> Message-Id: Date: Thu, 08 Feb 2001 07:45:02 -0800 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If 2181 seems wishy-washy then let's upgrade the wording. RRsets are > atomic. gladly. send text. 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 Thu Feb 8 12:33:04 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14193 for ; Thu, 8 Feb 2001 12:33:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14QuX0-000FQL-00 for namedroppers-data@psg.com; Thu, 08 Feb 2001 09:06:54 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14QuX0-000FQF-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 09:06:54 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14QuWw-000D4j-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 09:06:50 -0800 Message-ID: <3A82D108.EEC6B6A4@ehsco.com> Date: Thu, 08 Feb 2001 09:02:00 -0800 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: namedroppers Subject: Re: SRV and TC flag References: <3A81FB24.71969332@ehsco.com> <200102081322.FAA61504@redpaul.mfnx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > If 2181 seems wishy-washy then let's upgrade the wording. RRsets are > > atomic. > > gladly. send text. Only change requires is replacing 'should' with 'must' in paragraph 2 of section 9. Original text: Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. New text: ... set, it must ignore that response, and query again, using a ... That one-word change unambiguates this particular issue. -- 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 Feb 8 12:52:04 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14770 for ; Thu, 8 Feb 2001 12:52:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Qun2-000Fho-00 for namedroppers-data@psg.com; Thu, 08 Feb 2001 09:23:28 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Qun1-000Fhi-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 09:23:27 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Qun1-000DFm-00 for namedroppers@ops.ietf.org; Thu, 08 Feb 2001 09:23:27 -0800 To: ehall@ehsco.com Cc: namedroppers@ops.ietf.org Subject: Re: SRV and TC flag From: Havard Eidnes In-Reply-To: Your message of "Thu, 08 Feb 2001 09:02:00 -0800" <3A82D108.EEC6B6A4@ehsco.com> References: <3A82D108.EEC6B6A4@ehsco.com> X-Mailer: Mew version 1.93 on Emacs 19.34 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-Id: <20010208182230C.he@runit.no> Date: Thu, 08 Feb 2001 18:22:30 +0100 X-Dispatcher: imput version 980905(IM100) Lines: 7 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14770 > Only change requires is replacing 'should' with 'must' in > paragraph 2 of section 9. Is this still necessary in view of section 3 of the same document which in essence says "in the rest of this document should == MUST". - Håvard to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Feb 9 11:20:46 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21983 for ; Fri, 9 Feb 2001 11:20:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14RFRs-0001aI-00 for namedroppers-data@psg.com; Fri, 09 Feb 2001 07:27:00 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14RFRs-0001aC-00 for namedroppers@ops.ietf.org; Fri, 09 Feb 2001 07:27:00 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14RFRs-000Akk-00 for namedroppers@ops.ietf.org; Fri, 09 Feb 2001 07:27:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: In-Reply-To: <14977.60038.973395.391834@davenant.relativity.greenend.org.uk> References: <200101261816.NAA16811@ietf.org> <200101261816.NAA16811@ietf.org> Date: Fri, 9 Feb 2001 09:45:24 -0500 To: Ian Jackson From: Edward Lewis Subject: Re: Last Call: DNS Security Extension Clarification on Zone Status to Proposed Standard Cc: iesg@ietf.org, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (Speaking as the author:) Hmmm, mmmmm, I suppose you're right. At 7:38 PM -0500 2/7/01, Ian Jackson wrote: >Just one minor comment on draft-ietf-dnsext-zone-status-04.txt: > > 3 Experimental Status > ... > special designation of an experimentally secure status. Experimentally > secured is a special case of globally secured. A zone administrator > ^^^^^^^^ > >I think this should read `locally' ? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Feb 9 11:24:50 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22152 for ; Fri, 9 Feb 2001 11:24:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14RFGk-0001Pu-00 for namedroppers-data@psg.com; Fri, 09 Feb 2001 07:15:30 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14RFGk-0001Po-00 for namedroppers@ops.ietf.org; Fri, 09 Feb 2001 07:15:30 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14RFGk-000AdX-00 for namedroppers@ops.ietf.org; Fri, 09 Feb 2001 07:15:30 -0800 Message-Id: <200102091417.JAA17861@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-macgowan-dnsext-label-intel-manage-00.txt Date: Fri, 09 Feb 2001 09:17:27 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name System (DNS) DNS Label Intelligence and Management System Author(s) : M. Macgowan Filename : draft-macgowan-dnsext-label-intel-manage-00.txt Pages : 6 Date : 08-Feb-01 A multidimensional array of domain label analysis and extensions are offered to overcome a number of issues with the DNS and its use to locate resources on the Internet. These goals are accomplished by proposing a naming convention to add labels to domain strings. The result will be a rational relationship to the content that will provide a method for meeting the ever-increasing need to expand the namespace, while providing an efficient search system to access content in a user- friendly manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-macgowan-dnsext-label-intel-manage-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-macgowan-dnsext-label-intel-manage-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-macgowan-dnsext-label-intel-manage-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: <20010209092027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-macgowan-dnsext-label-intel-manage-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-macgowan-dnsext-label-intel-manage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010209092027.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 timotey_date@yahoo.com Mon Feb 12 23:25:35 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28682 for ; Mon, 12 Feb 2001 23:25:34 -0500 (EST) Received: from fort.comstar.ru ([195.210.128.13]) by psg.com with smtp (Exim 3.16 #1) id 14SWPH-000KkS-00 for namedroppers-data@psg.com; Mon, 12 Feb 2001 19:45:35 -0800 Received: (qmail 27590 invoked from network); 13 Feb 2001 03:45:24 -0000 Received: from d147.p6.col.ru (212.248.5.147) by mx.comail.ru with SMTP; 13 Feb 2001 03:45:24 -0000 Message-ID: <3A883254.27ACE51F@yahoo.com> Date: Mon, 12 Feb 2001 21:58:28 +0300 From: David Felder X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: namedroppers-data@psg.com Subject: Invitation to the co-operation! Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greetings! I want to let you know about "Friendly Buys" program! My participant's ID - 1072 Every participant of the program has got the right to 1. Get any article from the catalogue 2. Use the program for earning money. If you are interested in these opportunities, please, read this text, or you may get the detailed info on http://www.friendlybuys.com Short catalogue of the offered products: (The catalogue is updated regularly, all the catalogue you may examine on http://www.friendlybuys.com) Minolta Freedom Action Zoom 90 Camera Daewoo Portland PT-1901 19" Color TV Canon BJC-2100 Bubble Jet Printer Sennheiser HD500 "Fusion" Full-Size Headphone Yamaha DD9M Touch Sensitive Digital Drums Xerox DocuPrint M750 Color Inkjet Printer Texas Instruments TI83PLUS Graphing Calculator SportBrain Personal Fitness Assistant Garmin eTrex GPS 3dfx Voodoo3 3000 PCI 2D/3D Graphics Accelerator Sony PS One Console Memorex MPT 3450 Portable CD Player & Black and White Television Combo If you became the participant of the program, you may get any of these articles. Detailed Information: 1. After you enroll in the program and fulfill necessary starting conditions, you will be able to get any article from our catalogue. This catalogue is extended and updated regularly. 2. Every active participant of the program may use it to earn money. You're getting money for the advancing of it and involving new participants into it. You may earn up to $7000+ during the first month of participation. 3. Risk free guarantees: Credit cards are accepted. You may request the return of your money during 90 days from the moment of the start of your participation in the program without any explications. Spend just a few minutes of your precious time to examine our program. Don't waste such a chance! If you are interested in the program and you will decide to become its participant, it will be necessary for you to enter my ID code while registration. That is 1072. Attention! I'm terribly sorry if you are not interested in the participation in any sort of net programs and you received this letter accidentally. I'm not going to use your e-mail to inform you about the program in future. Good luck! Be happy! From owner-namedroppers@ops.ietf.org Wed Feb 14 12:55:22 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09207 for ; Wed, 14 Feb 2001 12:55:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14T5Zj-0008cf-00 for namedroppers-data@psg.com; Wed, 14 Feb 2001 09:18:43 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14T5Zj-0008cZ-00 for namedroppers@ops.ietf.org; Wed, 14 Feb 2001 09:18:43 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14T5Zj-0007Fk-00 for namedroppers@ops.ietf.org; Wed, 14 Feb 2001 09:18:43 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.16 #1) id 14T1ZL-00041T-00 for namedroppers@ops.ietf.org; Wed, 14 Feb 2001 05:02:04 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27135; Wed, 14 Feb 2001 08:02:03 -0500 (EST) Message-Id: <200102141302.IAA27135@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-05.txt Date: Wed, 14 Feb 2001 08:02:03 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Extension Clarification on Zone Status Author(s) : E. Lewis Filename : draft-ietf-dnsext-zone-status-05.txt Pages : 9 Date : 13-Feb-01 The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, 'experimentally secure' status is deprecated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-05.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-05.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-05.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: <20010213122414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-zone-status-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-zone-status-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010213122414.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 20 23:45:40 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05621 for ; Tue, 20 Feb 2001 23:45:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14VQUs-000A9V-00 for namedroppers-data@psg.com; Tue, 20 Feb 2001 20:03:22 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14VQUr-000A9O-00 for namedroppers@ops.ietf.org; Tue, 20 Feb 2001 20:03:21 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14VQUr-0009eu-00 for namedroppers@ops.ietf.org; Tue, 20 Feb 2001 20:03:21 -0800 Date: Tue, 20 Feb 2001 11:09:11 -0500 (EST) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: namedroppers@ops.ietf.org Subject: Agenda items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk If you want anything on the agenda send me requests. 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 Fri Feb 23 11:01:44 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06439 for ; Fri, 23 Feb 2001 11:01:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14WKAj-000OTw-00 for namedroppers-data@psg.com; Fri, 23 Feb 2001 07:30:17 -0800 Received: from mg-206191146-3.ricochet.net ([206.191.146.3] helo=roam.psg.com) by psg.com with esmtp (Exim 3.16 #1) id 14WKAh-000OTm-00 for namedroppers@ops.ietf.org; Fri, 23 Feb 2001 07:30:17 -0800 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14WK9r-0005bJ-00 for namedroppers@ops.ietf.org; Fri, 23 Feb 2001 07:29:23 -0800 To: namedroppers@ops.ietf.org Subject: DNS URLs and MIME types From: Simon Josefsson Date: 23 Feb 2001 15:19:18 +0100 Message-ID: Lines: 23 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/21.0.97 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dear wg, I'm not sure if these documents would fall within the charter of this wg, but I'd appreciate comments from the DNS expertise here. I believe both of these are quite useful if more non-DNS related data are stored within DNS. Since I gather that many disagrees that to be a good thing to start with, I also think that at least the MIME type for DNS data has some usefulness, when automating transports of DNS data -- for example sending KEY and SIG's between registry/registrant via mail or http. N.B., the drafts are very sketchy. /Simon MIME types for DNS data: http://search.ietf.org/internet-drafts/draft-josefsson-mime-dns-01.txt URL format for DNS resources: http://search.ietf.org/internet-drafts/draft-josefsson-dns-url-00.txt to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Feb 25 13:49:47 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12110 for ; Sun, 25 Feb 2001 13:49:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14X5bZ-000DEe-00 for namedroppers-data@psg.com; Sun, 25 Feb 2001 10:09:09 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14X5bY-000DEX-00 for namedroppers@ops.ietf.org; Sun, 25 Feb 2001 10:09:08 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14X5bY-0006P7-00 for namedroppers@ops.ietf.org; Sun, 25 Feb 2001 10:09:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <01C09F2B.47BB20F0@INSIDE> From: Erik Aronesty To: "'Kevin Darcy'" Cc: "'namedroppers@ops.ietf.org'" Subject: RE: cnames... Date: Sun, 25 Feb 2001 13:02:59 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry Kevin, you're right, future posts (including this one) will be directed to namedroppers. I included the entire thread (below), so users there can catch up. Your summary of the proposed/implied changes in DNS/BIND regarding CNAME's (below) are generally correct, although I think a detailed explanation of "why" is in order. Anyway, here's a list of responses to your challenges (1,2,3 as numbered below): 1) Yes, however, the resolver already has to do this if the QNAME is a CNAME itself, and the others we had mentioned. 2) Right, but the answer from the server is semantically correct. In your example, an application doing this query would get the ONLY nameservers that even know who "foo.com" is. Attempting to query "bar.com's nameservers" for information about "foo.com" would result in an error anyway. Which is why SOA/NS records are already exempt from chaining for "certain situations" (IE: AXFR authoritative sections). 3) If you absolutely needed to know about the NS record at the next level (for what reason - I have no idea), you would have to query for the CNAME itself, and then query for the NS record of the result - that's all. It reduces the ability to "chain SOA's" - while dramatically improving the ability to chain "A/MX/LOC" records, etc - which is the point in CNAME's anyway. There is a "philosophical/structural" argument here as well. Why should you be able to place CNAME's in some places and not others - just because of their arbitrary location in a "text file". IE: Why should I be able to place a CNAME in the ".com" zone for "foo" and not in the "foo.com" zone for "@" - since the two requests should be equivalent as far as a DNS is concerned. DNS is, in theory, a clean hierarchical structure, the more "special exceptions" there are in such a structure - the weaker the structure. Further, it can be argued that CNAMES's should be allowed with ALL other data and that the resolver should simply 1) see if it has a local record, if not, 2) go get the remote record. This would eliminate all exception handling, and result in clearer behavior and a more flexible DNS. It would eliminate the need for special processing for CNAME/SIG/KEY/SOA/NS, etc. and would reduce the verbiage in the protocol as well. - Erik -----Original Message----- From: Kevin Darcy [SMTP:kcd@daimlerchrysler.com] Sent: Friday, February 23, 2001 9:38 PM To: comp-protocols-dns-bind@moderators.isc.org Subject: Re: cnames... Erik, I'm going to brutally summarize this discussion thread, since in my opinion it's off-topic to bind-users. (It belongs on namedroppers, as I have repeatedly pointed out). Your basic proposal appears to be (correct me if I'm wrong): NS and SOA are "special" types because they are typically used only between nameservers, not something that a normal client would query. Given this, they should be exempted from CNAME chaining, and therefore can be exempted from the "CNAME and other data" rule as well, i.e. it should be legal for a CNAME to co-exist with SOA and/or NS records. This would put an end finally to the persistent confusion over the "CNAME and other data" rule as applied to names of registered domains. I can foresee at least 3 general objections to this: 1) It complicates name resolution in the case where a query comes into a recursive nameserver, and all it has cached is a CNAME which matches QNAME, but nothing for the target of the alias. Currently, the decision of what to do next is simple: recurse to the authoritative nameservers for the *target*'s zone. Under your proposal, however, the nameserver needs to look at the query type first. If it's an NS or SOA query, then it should recurse to the nameservers for QNAME's zone, otherwise it recurses to the nameservers for the CNAME target's zone. Is the benefit to be gained here worth the cost of adding *yet*another*conditional* to the critical path of the DNS resolution algorithm? 2) It violates "the principle of least surprise". Take the following example: foo.com, a name which owns NS records, is an alias for bar.com, where bar.com owns *different* NS records and an A record. Doing a "dig foo.com a" yields the A record which is ultimately contained in the bar.com zone. Doing a "dig foo.com ns", however, yields the foo.com zone's NS records, since, under your proposal, the CNAME isn't chained for an NS query. An application or human which/who doesn't notice the indirection in the first query might be incorrectly led to believe that the A RRset and the NS RRset originated from the same zone -- a reasonable conclusion, since the QNAME was the same for both queries. Yet they are from *different* zones, and thus the human or application could be easily led astray, possibly with disastrous results. 3) It arbitrarily reduces the overall usefulness of the aliasing mechanism. Why *shouldn't* I be able to point aliases at names which own SOA and/or NS records and have them chain properly when I do SOA and/or NS queries? Maybe I have domains many levels deep and I want "friendly" aliases to those domains at some higher level (which are more likely to be in my search path), so that I can say just "dig foo ns" instead of "dig foo.bar.blech.us.northamerica.earth.daimlerchrysler.com ns". CNAMEs are supposed to provide a *general* aliasing mechanism, but here you are carving out exceptions for record types you consider "special". Where does that line get drawn? Every record type is "special" in its own way. Do we head down that slippery slope and eventually get rid of CNAMEs altogether (as DJB proposes)? I think that would be a great loss. - 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 Sun Feb 25 15:11:19 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12902 for ; Sun, 25 Feb 2001 15:11:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14X7FF-000EkP-00 for namedroppers-data@psg.com; Sun, 25 Feb 2001 11:54:13 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14X7FF-000EkJ-00 for namedroppers@ops.ietf.org; Sun, 25 Feb 2001 11:54:13 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14X7FF-00071b-00 for namedroppers@ops.ietf.org; Sun, 25 Feb 2001 11:54:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A996299.C4986A9D@ehsco.com> Date: Sun, 25 Feb 2001 11:52:58 -0800 From: "Eric A. Hall" To: Erik Aronesty Cc: Kevin Darcy , namedroppers@ops.ietf.org Subject: Re: cnames... References: <01C09F2B.47BB20F0@INSIDE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > NS and SOA are "special" types because they are typically used only > between nameservers, not something that a normal client would query. > Given this, they should be exempted from CNAME chaining, and therefore > can be exempted from the "CNAME and other data" rule as well, i.e. it > should be legal for a CNAME to co-exist with SOA and/or NS records. This > would put an end finally to the persistent confusion over the "CNAME and > other data" rule as applied to names of registered domains. CNAME shouldn't be used with NS RRs at all, despite the other-data rule. DNS uses NS RRs for two purposes: zone delegation, and authoritative server lists (if it had been me, I would have used different RRs for these purposes, but that is irrelevant). You have to be really really careful about using NS with CNAMEs for zone delegation functions because the alias' domain name could be in the target zone, thereby preventing the CNAME recursion from suceeding. This fact goes beyond the simple case (duh, add the local alias and an A RR) in that recursion for the target zone would have to occur within the delegating server -- and the server would have to be authoritative for the parent and target zones -- in order for this to work with any level of reliability. As long as NS is used for zone delegation, it cannot be used with CNAMEs without very careful planning. The level of planning required is in fact too high, with many more failure scenarios than success scenarios. See also section 10.3 of RFC 2181 for a less emphatic rendetion. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 26 11:39:30 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15555 for ; Mon, 26 Feb 2001 11:39:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XPsZ-00066i-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 07:48:03 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XPsY-00066c-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 07:48:02 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XPsY-00034L-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 07:48:02 -0800 Message-Id: <200102261205.HAA04398@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-04.txt Date: Mon, 26 Feb 2001 07:05:02 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC and IPv6 A6 aware server/resolver message size requirements Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-message-size-04.txt Pages : 6 Date : 23-Feb-01 This document mandates support for EDNS0 in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back 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-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-message-size-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-message-size-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: <20010223130553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-message-size-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-message-size-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010223130553.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 26 11:53:57 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16101 for ; Mon, 26 Feb 2001 11:53:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XQNm-0006lH-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 08:20:18 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XQNm-0006lB-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 08:20:18 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XQNl-0003IH-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 08:20:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <157501c0a009$a8159370$cd4751d1@primedata.org> From: "Erik Aronesty" To: "Eric A. Hall" Cc: "Kevin Darcy" , References: <01C09F2B.47BB20F0@INSIDE> <3A996299.C4986A9D@ehsco.com> Subject: Re: cnames are in conflict with soa's... Date: Mon, 26 Feb 2001 10:34:04 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree. The original conversation was in regard to SOA records, not NS RR's. However, NS RR's that are "required to be present" should only be used for authoritative server lists - not delegations - in the case of a CNAME on a domain. The original concept was that SOA record requests should not get "aliased" during queries, since the resulting data is misleading. Also, all CNAMRE responses have an "authority section" - and having a rule which says that CNAME's cannot have SOA RR's present is a bit odd. Therefore the restriction on CNAME's and other data should not apply to the SOA record - since it's should not get aliased anyway. There are already situations where the SOA record does not get aliased. It should be formalized - that's all. - Erik ----- Original Message ----- From: "Eric A. Hall" To: "Erik Aronesty" Cc: "Kevin Darcy" ; Sent: Sunday, February 25, 2001 2:52 PM Subject: Re: cnames... > > NS and SOA are "special" types because they are typically used only > > between nameservers, not something that a normal client would query. > > Given this, they should be exempted from CNAME chaining, and therefore > > can be exempted from the "CNAME and other data" rule as well, i.e. it > > should be legal for a CNAME to co-exist with SOA and/or NS records. This > > would put an end finally to the persistent confusion over the "CNAME and > > other data" rule as applied to names of registered domains. > > CNAME shouldn't be used with NS RRs at all, despite the other-data rule. > > DNS uses NS RRs for two purposes: zone delegation, and authoritative > server lists (if it had been me, I would have used different RRs for these > purposes, but that is irrelevant). You have to be really really careful > about using NS with CNAMEs for zone delegation functions because the > alias' domain name could be in the target zone, thereby preventing the > CNAME recursion from suceeding. This fact goes beyond the simple case > (duh, add the local alias and an A RR) in that recursion for the target > zone would have to occur within the delegating server -- and the server > would have to be authoritative for the parent and target zones -- in order > for this to work with any level of reliability. > > As long as NS is used for zone delegation, it cannot be used with CNAMEs > without very careful planning. The level of planning required is in fact > too high, with many more failure scenarios than success scenarios. > > See also section 10.3 of RFC 2181 for a less emphatic rendetion. > > -- > 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. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 26 13:03:19 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19240 for ; Mon, 26 Feb 2001 13:03:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XRfW-0008Qg-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 09:42:42 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XRfW-0008Qa-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 09:42:42 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XRfW-0003o3-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 09:42:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102261725.JAA80050@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... In-Reply-To: Message from "Erik Aronesty" of "Mon, 26 Feb 2001 10:34:04 EST." <157501c0a009$a8159370$cd4751d1@primedata.org> Date: Mon, 26 Feb 2001 09:25:07 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > However, NS RR's that are "required to be present" should only be used for > authoritative server lists - not delegations - in the case of a CNAME on a > domain. There is no such thing as a "CNAME on a domain" (zone cut). A given name is either an alias, or it's not an alias. Zones have names. Not aliases. > Also, all CNAMRE responses have an "authority section" - Untrue. And especially out-of-zone CNAME's (which is what your proposal is) the only SOA you can put into the authority section is about the query name, never the target name of the alias. > It should be formalized - that's all. It already is: "Don't try that, DNS doesn't work that way." to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 26 19:32:59 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06642 for ; Mon, 26 Feb 2001 19:32:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XXcr-000Eng-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 16:04:21 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XXcq-000EnZ-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 16:04:20 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XXcq-0006Lf-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 16:04:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19c201c0a050$ad82c430$cd4751d1@primedata.org> From: "Erik Aronesty" To: , "Paul A Vixie" References: <200102261725.JAA80050@redpaul.mfnx.net> Subject: Re: cnames are in conflict with soa's... Date: Mon, 26 Feb 2001 19:03:11 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> However, NS RR's that are "required to be present" should only be used for >> authoritative server lists - not delegations - in the case of a CNAME on a >> domain. > > There is no such thing as a "CNAME on a domain" (zone cut). A given name > is either an alias, or it's not an alias. Zones have names. Not aliases. Sorry, on an alias. >> Also, all CNAMRE responses have an "authority section" - > > Untrue. And especially out-of-zone CNAME's (which is what your proposal is) > the only SOA you can put into the authority section is about the query name, > never the target name of the alias. Right... which is why the current technique of chaining SOA's in some contexte - but not in others is goofy. >> It should be formalized - that's all. > > It already is: "Don't try that, DNS doesn't work that way." Actually, DNS does work that wa and has worked that way for many many years. BIND 8.2.3 doesn't work that way. All other DNS resolvers and libraries work just fine, and work that way. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 26 20:09:41 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07787 for ; Mon, 26 Feb 2001 20:09:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XYJu-000FXo-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 16:48:50 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XYJt-000FXi-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 16:48:49 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XYJt-0006e6-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 16:48:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102270040.QAA82609@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... In-Reply-To: Message from "Erik Aronesty" of "Mon, 26 Feb 2001 19:03:11 EST." <19c201c0a050$ad82c430$cd4751d1@primedata.org> Date: Mon, 26 Feb 2001 16:40:56 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> It already is: "Don't try that, DNS doesn't work that way." > > Actually, DNS does work that wa and has worked that way for many many years. > BIND 8.2.3 doesn't work that way. All other DNS resolvers and libraries > work just fine, and work that way. sounds like a pissing match to me. bind was wrong to do this in the past. the rfc's are clear. bind8.2.3 and bind9 get it right. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 26 20:14:12 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07943 for ; Mon, 26 Feb 2001 20:14:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XYSf-000FhB-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 16:57:53 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XYSf-000Fh5-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 16:57:53 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XYSf-0006hn-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 16:57:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1a1901c0a058$aaa1cab0$cd4751d1@primedata.org> From: "Erik Aronesty" To: "Erik Aronesty" , , "Paul A Vixie" Subject: Re: cnames are in conflict with soa's... Date: Mon, 26 Feb 2001 19:59:58 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit To be more clear: A. Confusing usage In order to create a CNAME for a domain, it is necessary to create a parent node, and then add the CNAME within it. However, you do not have to be authoritative for the parent node. This forces the DNS user to make odd configuration choices to get CNAME's to work in the case where he is not authoritative for the parent. For example: in order to CNAME "foo.com" it is currently necessary to create a "com" zone, and add a "microsoft" domain to it. This works well - however it is a potentially confusing configuration. This same analogy holds for all levels of the DNS tree. The reason why this is necessary is that SOA RR's are required for all zones - but CNAME records cannot coexist with SOA RR's. B. Misleading information 1) Currently, in the case of CNAME's the authority section, if present, returns information about the alias - not the target. 2) When requesting an SOA record for a name that has been aliased to another - the SOA record of the target is returned. 3) The SOA record of the target contains information that is misleading in any circumstances. Clearly CNAMEs are, as currently implemented a source of confusion and excessive technical support for DNS maintainers. It appears there are three solutions: 1- allow CNAMEs to coexist with SOA records 2- create a new query type (IE: DNAME, as proposed) which has a pure, recursive implementation 3- make CNAME's obsolete Also: The majority of DNS software currently supports CNAME's alongside SOA records - without any negative effects (because the majority of DNS software is based on BIND 8.2.2 or prior versions - which supported this). So, the negative impact of allowing this would be minimal. The positive impact would be that CNAME's could be used at the root of a zone - which, for a long time, was a excellent DNS feature that has recently been abandoned. - Erik ----- Original Message ----- From: "Erik Aronesty" To: ; "Paul A Vixie" Sent: Monday, February 26, 2001 7:03 PM Subject: Re: cnames are in conflict with soa's... > > > However, NS RR's that are "required to be present" should only be used > for > > > authoritative server lists - not delegations - in the case of a CNAME on > a > > > domain. > > > > There is no such thing as a "CNAME on a domain" (zone cut). A given name > > is either an alias, or it's not an alias. Zones have names. Not aliases. > > Sorry, on an alias. > > > > > > Also, all CNAMRE responses have an "authority section" - > > > > Untrue. And especially out-of-zone CNAME's (which is what your proposal > is) > > the only SOA you can put into the authority section is about the query > name, > > never the target name of the alias. > > Right... which is why the current technique of chaining SOA's in some > contexte - but not in others is goofy. > > > > It should be formalized - that's all. > > > > It already is: "Don't try that, DNS doesn't work that way." > > Actually, DNS does work that wa and has worked that way for many many years. > BIND 8.2.3 doesn't work that way. All other DNS resolvers and libraries > work just fine, and work that way. > > > > > > > > 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 Mon Feb 26 21:11:05 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09422 for ; Mon, 26 Feb 2001 21:11:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XZKv-000GfY-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 17:53:57 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XZKv-000GfS-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 17:53:57 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XZKv-00074F-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 17:53:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A9B082D.514209C0@daimlerchrysler.com> Date: Mon, 26 Feb 2001 20:51:42 -0500 From: Kevin Darcy To: "'namedroppers@ops.ietf.org'" Subject: Re: cnames... References: <01C09F2B.47BB20F0@INSIDE> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Aronesty wrote: > Sorry Kevin, you're right, future posts (including this one) will be directed to namedroppers. I included the entire thread (below), so users there can catch up. > > Your summary of the proposed/implied changes in DNS/BIND regarding CNAME's (below) are generally correct, although I think a detailed explanation of "why" is in order. > > Anyway, here's a list of responses to your challenges (1,2,3 as numbered below): > > 1) Yes, however, the resolver already has to do this if the QNAME is a CNAME itself, and the others we had mentioned. No, if the QNAME owns a CNAME, then, today, as I described, the resolver only needs to know to go to the authoritative nameservers for the CNAME's target's zone. Under your proposal, it needs to take the extra step of looking at the query type to see if it should go to *either* the CNAME's target's zone (normal case) *or* to QNAME's zone (for SOA or NS queries). This complicates and burdens the process. > 2) Right, but the answer from the server is semantically correct. Semantically correct, but confusing. > In your example, an application doing this query would get the ONLY nameservers that even know who "foo.com" is. Attempting to query "bar.com's nameservers" for information about "foo.com" would result in an error anyway. No, I think you misunderstood. When the user or application issues "dig foo.com a" (or the equivalent), and a "foo.com cname bar.com" record is known by the recursive server, then it queries the bar.com nameservers for a "bar.com" A record. In contrast, under your proposal, a "dig foo.com ns" or "dig foo.com soa" would be answered directly from the foo.com zone, since NS and SOA aren't chained. This results in apparently-inconsistent behavior which could be very confusing and lead to nasty, hard-to-diagnose bugs. > Which is why SOA/NS records are already exempt from chaining for "certain situations" (IE: AXFR authoritative sections). Um, surely you mean IXFR rather than AXFR. As far as I know, Authority Section contents aren't specified for either AXFR queries or responses... I think you are misunderstanding the purpose of the SOA in the Authority Section of an IXFR request. The SOA owner name specifies a zone of interest, and the only other item of interest in the SOA RR is the serial number. This SOA RR is expected to come from a slave's authoritative (but possibly out-of-date) copy of the zone. There is no possibility that the owner name of this SOA RR could also own an alias, because of the very "CNAME and other data" rule which we are discussing. So there is no aliasing "exemption" necessary, and you have demonstrated no inconsistency here in the application of the "CNAME and other data" rule. Or, alternatively, feel free to quote this "exemption" from RFC 1995. Maybe I missed it. > 3) If you absolutely needed to know about the NS record at the next level (for what reason - I have no idea), you would have to query for the CNAME itself, and then query for the NS record of the result - that's all. It reduces the ability to "chain SOA's" - while dramatically improving the ability to chain "A/MX/LOC" records, etc - which is the point in CNAME's anyway. The point here is that your proposal disables chaining for 2 whole record types -- SOA and NS -- while the "CNAME and other data" rule only prohibits certain data relationships, under very specific circumstances, which are quite well understood and quite easy to work around. My opinion is that your proposal results in a net reduction in the usefulness of CNAMEs. > There is a "philosophical/structural" argument here as well. Why should you be able to place CNAME's in some places and not others - just because of their arbitrary location in a "text file". IE: Why should I be able to place a CNAME in the ".com" zone for "foo" and not in the "foo.com" zone for "@" - since the two requests should be equivalent as far as a DNS is concerned. DNS is, in theory, a clean hierarchical structure, the more "special exceptions" there are in such a structure - the weaker the structure. It has nothing to do with location of entries in a text file -- there is no requirement that DNS master zones even be loaded from a text file. The rule is strictly based on relationships between data elements -- if a name owns a CNAME, it can't own records of other types (except for the DNSSEC types which we've already discussed). How zones are loaded, and in what order the records are processed in the loading process, is irrelevant to the "CNAME and other data" rule. Now you seem to think that making chaining exceptions for some record types somehow makes the hierarchical structure "cleaner" and consequently stronger. But I see it exactly the opposite way. An alias is a name which stands for another name, and has no independent existence of its own. So if name X is an alias to name Y, which may or may not happen to be a zone, it should not have any other records of its own. That's the cleanest way to consider X -- as just another name for Y, not an entity or container in its own right. Anything else is "dirtier", and therefore, by your reasoning, "weaker". To attempt an analogy, imagine I told everyone that they could call me "Fred", and this usage became somewhat prevalent. Does that suddenly mean that I can open up a separate bank account under the name "Fred"? Does it mean I could file separate 1040 tax returns under my name and the name "Fred", splitting up the income so as to pay less overall income tax? If I were given a speeding ticket, could I just show up in court and say "Fred did it, go fine him instead"? No, of course not. "Fred" is just another name for me. "Fred" has no independent existence; he/it can't own property, hold assets, earn income, pay taxes, be criminally liable, etc. for anything beyond what Kevin Darcy can. "Fred" is just a name for me, not something with its own existence. (Yes, I know the analogy might seem to break down a little bit in the case of corporations, which *are* in many respects considered independent entities, but hopefully you appreciate that a corporation is more analogous to a separate name, or to a zone, than just somebody's alias). > Further, it can be argued that CNAMES's should be allowed with ALL other data and that the resolver should simply 1) see if it has a local record, if not, 2) go get the remote record. Well, no, as RFC 1034 already alludes, if all a nameserver has cached is the CNAME RR, then if the "CNAME and other data" rule is abrogated completely, it now has to look in *two* places: 1) QNAME's zone, and 2) the CNAME's target's zone. Suddenly, you double the nameserver's workload in these situations. For no appreciable benefit. > This would eliminate all exception handling, and result in clearer behavior and a more flexible DNS. To what "exception handling" are you referring? > It would eliminate the need for special processing for CNAME/SIG/KEY/SOA/NS, etc. and would reduce the verbiage in the protocol as well. Actually, the processing of CNAMEs during normal nameserver operation is *simpler* because of the "CNAME and other data" rule. The rule is enforced at zone load time, which takes most of the special processing out of the critical path -- once a zone is loaded, the nameserver can assume that any CNAMEs in the zone own no other records. The special processing required by your lead proposal, however, would have to be done in the heart of the query-processing/recursion/name-resolution code, and thus could be rather expensive. - Kevin > -----Original Message----- > From: Kevin Darcy [SMTP:kcd@daimlerchrysler.com] > Sent: Friday, February 23, 2001 9:38 PM > To: comp-protocols-dns-bind@moderators.isc.org > Subject: Re: cnames... > > Erik, > I'm going to brutally summarize this discussion thread, since in my opinion it's off-topic to bind-users. (It belongs on namedroppers, as I have repeatedly pointed out). > > Your basic proposal appears to be (correct me if I'm wrong): > > NS and SOA are "special" types because they are typically used only between nameservers, not something that a normal client would query. Given this, they should be exempted from CNAME chaining, and therefore can be exempted from the "CNAME and other data" rule as well, i.e. it should be legal for a CNAME to co-exist with SOA and/or NS records. This would put an end finally to the persistent confusion over the "CNAME and other data" rule as applied to names of registered domains. > > I can foresee at least 3 general objections to this: > > 1) It complicates name resolution in the case where a query comes into a recursive nameserver, and all it has cached is a CNAME which matches QNAME, but nothing for the target of the alias. Currently, the decision of what to do next is simple: recurse to the authoritative nameservers for the *target*'s zone. Under your proposal, however, the nameserver needs to look at the query type first. If it's an NS or SOA query, then it should recurse to the nameservers for QNAME's zone, otherwise it recurses to the nameservers for the CNAME target's zone. Is the benefit to be gained here worth the cost of adding *yet*another*conditional* to the critical path of the DNS resolution algorithm? > > 2) It violates "the principle of least surprise". Take the following example: foo.com, a name which owns NS records, is an alias for bar.com, where bar.com owns *different* NS records and an A record. Doing a "dig foo.com a" yields the A record which is ultimately contained in the bar.com zone. Doing a "dig foo.com ns", however, yields the foo.com zone's NS records, since, under your proposal, the CNAME isn't chained for an NS query. An application or human which/who doesn't notice the indirection in the first query might be incorrectly led to believe that the A RRset and the NS RRset originated from the same zone -- a reasonable conclusion, since the QNAME was the same for both queries. Yet they are > from *different* zones, and thus the human or application could be easily led astray, possibly with disastrous results. > > 3) It arbitrarily reduces the overall usefulness of the aliasing mechanism. Why *shouldn't* I be able to point aliases at names which own SOA and/or NS records and have them chain properly when I do SOA and/or NS queries? Maybe I have domains many levels deep and I want "friendly" aliases to those domains at some higher level (which are more likely to be in my search path), so that I can say just "dig foo ns" instead of "dig foo.bar.blech.us.northamerica.earth.daimlerchrysler.com ns". CNAMEs are supposed to provide a *general* aliasing mechanism, but here you are carving out exceptions for record types you consider "special". Where does that line get drawn? Every record type is "special" in its own > way. Do we head down that slippery slope and eventually get rid of CNAMEs altogether (as DJB proposes)? I think that would be a great loss. > > - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Feb 26 22:01:41 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11247 for ; Mon, 26 Feb 2001 22:01:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Xa59-000HTv-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 18:41:43 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Xa58-000HTp-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 18:41:42 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Xa58-0007M0-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 18:41:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102270240.f1R2eAh67515@drugs.dv.isc.org> To: "Erik Aronesty" Cc: namedroppers@ops.ietf.org, "Paul A Vixie" From: Mark.Andrews@nominum.com Subject: Re: cnames are in conflict with soa's... In-reply-to: Your message of "Mon, 26 Feb 2001 19:59:58 CDT." <1a1901c0a058$aaa1cab0$cd4751d1@primedata.org> Date: Tue, 27 Feb 2001 13:40:10 +1100 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric, why do you want a CNAME at the top of zone? Is it because you have a another party hosting your HTTP service? There is DNS resource record specifically for supporting this sort of thing, it is called SRV which provides a generalised form of the MX record. It has been around since 1996. Now you will find it much easier to update all the http clients in the world than it will be to update all the DNS servers in the world. For one thing, people are used to updating HTTP clients. Secondly it is a better solution. Of course if we go down your track you can't arange to get your mail delivered to a different box than where the mail is delivered for box hosting the HTTP traffic. People want to be able to say @ MX 0 mail.example.com. _http._tcp SRV ... http.example1.net. _ftp._tcp SRV ... ftp.example2.net. _kerberos._udp SRV ... kdc.example.com. This is the solution space you should be aiming at. Complain to Netscape, Microsoft etc. saying that you want SRV support in the browsers, ftp client etc. > To be more clear: > > A. Confusing usage > > In order to create a CNAME for a domain, it is necessary to create a parent > node, and then add the CNAME within it. However, you do not have to be > authoritative for the parent node. This forces the DNS user to make odd > configuration choices to get CNAME's to work in the case where he is not > authoritative for the parent. > > For example: in order to CNAME "foo.com" it is currently necessary to create > a "com" zone, and add a "microsoft" domain to it. This works well - however > it is a potentially confusing configuration. If you want example.com to be an alias lobby the Internic to allow CNAMES to be added to the COM zone. Other registries allow it, however you have a to choose between that and a delegation. > > This same analogy holds for all levels of the DNS tree. > > The reason why this is necessary is that SOA RR's are required for all > zones - but CNAME records cannot coexist with SOA RR's. > > B. Misleading information > > 1) Currently, in the case of CNAME's the authority section, if present, > returns information about the alias - not the target. You are getting back a negative answer here. If you don't understand why you are getting the SOA record from the target zone then I suggest that you read RFC 2308. > 2) When requesting an > SOA record for a name that has been aliased to another - the SOA record of > the target is returned. You get undefined behaviour when you choose to ignore errors. > 3) The SOA record of the target contains > information that is misleading in any circumstances. Again you have choosen to ignore error messages and get undefined behaviour. > > Clearly CNAMEs are, as currently implemented a source of confusion and > excessive technical support for DNS maintainers. There is no confusion. RFC 1034/1035 clearly state that CNAMES cannot exist with other records. It is precisely because it can cause the confusion you are seeing here that they are are not allowed to exist with any other record. You get the same sort of confusion when you deal with MX records and CNAME's. The next thing you will be asking us for is to support CNAMES and MX records at top of zone. > > It appears there are three solutions: > > 1- allow CNAMEs to coexist with SOA records > 2- create a new query type (IE: DNAME, as proposed) which has a pure, > recursive implementation > 3- make CNAME's obsolete > 4. Read the existing RFC's and error messages from your software and work within the constraints imposed. > Also: > > The majority of DNS software currently supports CNAME's alongside SOA > records - without any negative effects (because the majority of DNS software > is based on BIND 8.2.2 or prior versions - which supported this). So, the > negative impact of allowing this would be minimal. BIND 8.2.2 does *not* support CNAME's along side SOA records. It flags it as a error. It prevents the zone being tranmitted in this error state. The reason this was done was so that the server could continue to serve the rest of the zone WHILE YOU FIXED THE ERRROR. > > The positive impact would be that CNAME's could be used at the root of a > zone - which, for a long time, was a excellent DNS feature that has recently > been abandoned. It's not been abandoned. It's NEVER been allowed. > > - Erik -- 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 Feb 26 22:52:50 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13384 for ; Mon, 26 Feb 2001 22:52:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XasG-000IIR-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 19:32:28 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XasG-000IIL-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 19:32:28 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XasG-0007fD-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 19:32:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A9B1ED6.572A9CE9@daimlerchrysler.com> Date: Mon, 26 Feb 2001 22:28:22 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... References: <1a1901c0a058$aaa1cab0$cd4751d1@primedata.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Aronesty wrote: > To be more clear: > > A. Confusing usage > > In order to create a CNAME for a domain, it is necessary to create a parent > node, and then add the CNAME within it. However, you do not have to be > authoritative for the parent node. This forces the DNS user to make odd > configuration choices to get CNAME's to work in the case where he is not > authoritative for the parent. > > For example: in order to CNAME "foo.com" it is currently necessary to create > a "com" zone, and add a "microsoft" domain to it. This works well - however > it is a potentially confusing configuration. > > This same analogy holds for all levels of the DNS tree. > > The reason why this is necessary is that SOA RR's are required for all > zones - but CNAME records cannot coexist with SOA RR's. If a name is intended to only be an alias to some other name, why on earth would one even *try* to delegate it as a zone as well? The usage here only becomes "confusing" if people try to do things which don't make any sense in the first place. Now, I appreciate that, given the way DNS is *implemented*, certain desirable kinds of aliasing -- e.g. make foo.com an alias for bar.com -- are precluded by the policies of certain TLD registrars. One cannot just go to NSI (say) and successfully get foo.com aliased to bar.com, at least as far as I know (I haven't personaly tried this). I don't believe they are set up to handle such a request. But is this bureaucratic obstacle a justification for making a *protocol* change? Perhaps you should be expending your effort trying to persuade ICANN or various TLD registrars to offer an "alias registration" service, instead of lobbying for a protocol change of dubious technical merit (?) Seems to me like the registrars would jump at the chance to make money off adding CNAMEs to TLDs, especially since this means that many of the names which currently require 2 or more delegation records, and possibly also glue records, could be accommodated with a single CNAME record, thus reducing the size of the zone(s) and the load on the TLD servers (thus reducing overhead costs)... > B. Misleading information > > 1) Currently, in the case of CNAME's the authority section, if present, > returns information about the alias - not the target. > 2) When requesting an > SOA record for a name that has been aliased to another - the SOA record of > the target is returned. BUT NOT IN THE AUTHORITY SECTION! You are mixing apples and oranges here. If someone asks for an SOA record, why should it be surprising in the least that they get an SOA record in the *Answer* Section of the response? But this has nothing to do with what's in the Authority Section. > 3) The SOA record of the target contains > information that is misleading in any circumstances. Huh? What's "misleading" about getting the SOA record one asked for, albeit through one or more levels of aliasing? Is it any less "misleading" to do an A record query and get the answer through one or more levels of aliasing? If you think aliases are _inherently_ "misleading", don't use them. > Clearly CNAMEs are, as currently implemented a source of confusion and > excessive technical support for DNS maintainers. I think you have failed to demonstrate that. Sure, there's a lot of confusion. But that can explained by the dilution of average DNS administrator skill levels in recent years, no doubt due to the "dot com explosion", "new economy", whatever-you-want-to-call-it. Good help is hard to find. If people don't really grasp the essence of CNAMEs being *aliases* without any independent existence, just like a different name for your dog, then yes, they may get confused by the "CNAME and other data" rule. But this is generally temporary: once they grasp that essence, the "CNAME and other data" rule makes perfect sense; the owner name of a CNAME isn't a *different* thing, it's just another name for the *same* thing, and therefore shouldn't be expected to own other records. > It appears there are three solutions: > > 1- allow CNAMEs to coexist with SOA records I'll note that this wouldn't, _ipso_facto_, get you what you want. A CNAME with the same name as a zone would still conflict with the zone's NS records, even if it could co-exist with the SOA record. > 2- create a new query type (IE: DNAME, as proposed) which has a pure, > recursive implementation I'm not sure what you mean by "pure, recursive implementation". In any case, as I understand DNAME, it wouldn't do what you want. It effectively aliases *suffixes*, not whole names. So, while one could effectively alias www.foo.com, ftp.foo.com, and mail.foo.com to www.bar.com, ftp.bar.com, mail.bar.com, respectively, with a single DNAME, one could not, however, effectively alias foo.com to bar.com using a DNAME. This characteristic, along with the "no descendants" rule, prevents DNAME from incurring the evils warned against in RFC 1034, which gave rise to the "CNAME and other data" prohibition. > 3- make CNAME's obsolete I don't think any reasonable person advocates this. > Also: > > The majority of DNS software currently supports CNAME's alongside SOA > records - without any negative effects (because the majority of DNS software > is based on BIND 8.2.2 or prior versions - which supported this). So, the > negative impact of allowing this would be minimal. BIND failed to follow the RFC's, and unreliable/inefficient behavior was the result. As Paul (Vixie) has pointed out, ISC/Nominum has now seen the error of their ways and fixed the non-conforming behavior. Now, don't get me wrong. I'm not saying that *blindly* following rules is a good thing. I've had my differences with, for example, BIND's adherence to the rules (such as they are perceived to exist) with respect to the underscore character. But there are strong technical justifications for the "CNAME and other data" rule. This is a rule that should have been enforced all along, and I applaud BIND's conformance. > The positive impact would be that CNAME's could be used at the root of a > zone - which, for a long time, was a excellent DNS feature that has recently > been abandoned. It's a "feature" that comes at the cost of reliability and efficiency. The original DNS RFC's didn't think that the benefits of the "feature" were worth the costs, and that's why they instituted the "CNAME and other data" rule. And nothing has really transpired in the meantime, in my opinion, to give rise to a repeal of that rule. Not even the abovementioned skill-level dilution: I'm not in favor of dumbing down protocols just because administrators are less cluefull than they used to be... -Kevin > ----- Original Message ----- > From: "Erik Aronesty" > To: ; "Paul A Vixie" > Sent: Monday, February 26, 2001 7:03 PM > Subject: Re: cnames are in conflict with soa's... > > > > > However, NS RR's that are "required to be present" should only be used > > for > > > > authoritative server lists - not delegations - in the case of a CNAME > on > > a > > > > domain. > > > > > > There is no such thing as a "CNAME on a domain" (zone cut). A given > name > > > is either an alias, or it's not an alias. Zones have names. Not > aliases. > > > > Sorry, on an alias. > > > > > > > > > Also, all CNAMRE responses have an "authority section" - > > > > > > Untrue. And especially out-of-zone CNAME's (which is what your proposal > > is) > > > the only SOA you can put into the authority section is about the query > > name, > > > never the target name of the alias. > > > > Right... which is why the current technique of chaining SOA's in some > > contexte - but not in others is goofy. > > > > > > It should be formalized - that's all. > > > > > > It already is: "Don't try that, DNS doesn't work that way." > > > > Actually, DNS does work that wa and has worked that way for many many > years. > > BIND 8.2.3 doesn't work that way. All other DNS resolvers and libraries > > work just fine, and work that way. > > > > > > > > > > > > > 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 Mon Feb 26 23:12:11 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13737 for ; Mon, 26 Feb 2001 23:12:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XbBn-000Ifu-00 for namedroppers-data@psg.com; Mon, 26 Feb 2001 19:52:39 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XbBn-000Ifo-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 19:52:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XbBn-0007oE-00 for namedroppers@ops.ietf.org; Mon, 26 Feb 2001 19:52:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102270349.TAA83442@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... In-Reply-To: Message from Mark.Andrews@nominum.com of "Tue, 27 Feb 2001 13:40:10 +1100." <200102270240.f1R2eAh67515@drugs.dv.isc.org> Date: Mon, 26 Feb 2001 19:49:55 -0800 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If you want example.com to be an alias lobby the Internic to allow > CNAMES to be added to the COM zone. Other registries allow it, > however you have a to choose between that and a delegation. The cases aren't parallel. What nobody but me seems to realize about this proposal is that it makes CNAME's nonterminal. If erik.com had both a CNAME and an SOA (or in Mark's example, a CNAME and an NS in the delegating zone) then the meaning of www.erik.com becomes quite undefined. This whole thing is silly. > It's not been abandoned. It's NEVER been allowed. For the benefit of the gallery, here's what happened on bind-bugs@isc.org when Erik wanted 8.2.3 to propagate the same bad data that 8.2.2 had done. (This is just how it ended, and as you can see, I had by then lost my temper.) ------- Forwarded Messages To: Erik Aronesty cc: "'Mark.Andrews@nominum.com'" , Erik Aronesty , Michael Krebs , "bind-bugs@isc.org" Subject: Re: [BIND-BUGS #4054] root CNAME error in new version In-Reply-To: Message from Erik Aronesty of "Tue, 30 Jan 2001 23:06:30 EST." <01C08B11.48C97100@INSIDE> Date: Tue, 30 Jan 2001 20:26:17 -0800 From: Paul A Vixie i keep thinking this is a joke, and yet you keep acting as if you're serious. > If a CNAME exists at the root, it MUST NOT have any other records, > including an SOA and a NS. > > So, if BIND intends to follow the RFC fully, then it must allow a > CNAME to fully define the root of the zone. > > To repeat: > > OWNER IN CNAME CANONICAL-NAME > > ****The resolver goes to the canonical name for the SOA and the NS.**** > > To reiterate my email to Paul: > > > > > I would propose that if you want to really get CNAME's right, BIND > > > > should allow "*either*" a CNAME or an SOA/NS pair to define the > > > > root of a zone, and never both. everything you have said about CNAMEs refers to query behaviour. now pay some attention to the zone content and zone service behaviour. [RFC1034] | 4.2.1. Technical considerations | ... | - Data that defines the top node of the zone (can be thought of | as part of the authoritative data). | ... | Though logically part of the authoritative data, the RRs that describe | the top node of the zone are especially important to the zone's | management. These RRs are of two types: name server RRs that list, one | per RR, all of the servers for the zone, and a single SOA RR that | describes zone management parameters. this doesn't admit the possibility you wish it did. furthermore: | 4.3.4. Negative response caching (Optional) | ... | Note that in some circumstances, the answer section may contain multiple | owner names. In this case, the SOA mechanism should only be used for | the data which matches QNAME, which is the only authoritative data in | this section. QNAME would be an alias in the case you're attempting to describe, and the SOA would not be able to describe it (since there is no SOA there.) (CNAME synthesis works in the answer section but NOT in the authority section or the additional data section.) furthermore, AXFR is not a query and must not follow CNAME's. so the "zone" you wish you were creating would not be transferrable. furthermore, CNAME aliased SOA's could be higher up in the DNS hierarchy than the original alias, which could lead to loops if zone transfers were allowed. furthermore, in RFC1035 we see: | 5.2. Use of master files to define zones | | When a master file is used to load a zone, the operation should be | suppressed if any errors are encountered in the master file. ... | ... | Several other validity checks that should be performed in addition to | insuring that the file is syntactically correct: | ... | 2. Exactly one SOA RR should be present at the top of the zone. so, while loading a zone, it is not a requirement to look at any other zone in order to determine its syntactic correctness. in your imaginary world, a zone's correctness could only be determined by examining out-of-zone data. isc remains deeply apologetic that prior versions of BIND did not properly catch the configuration error that you appear to have built your business on. however, there are workarounds, and i suggest that rather than wasting more of your time and our time arguing about it, you get to work on implementing one. paul ------- Message 2 To: Erik Aronesty cc: "'Mark.Andrews@nominum.com'" , Erik Aronesty , Michael Krebs , "bind-bugs@isc.org" Subject: Re: [BIND-BUGS #4054] root CNAME error in new version In-Reply-To: Message from Erik Aronesty of "Wed, 31 Jan 2001 10:13:50 EST." <01C08B6E.8272A9F0@INSIDE> Date: Wed, 31 Jan 2001 08:44:05 -0800 From: Paul A Vixie > 1. The RFC1034 specification of a CNAME allows for a CNAME at the root of > a zone. No, it does not. > Your response, though it seems correct, does not address this at all. I'm done arguing with you about this. Please reread the RFC's and reread what I wrote to you previously. ------- End of Forwarded 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 Tue Feb 27 12:03:11 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17976 for ; Tue, 27 Feb 2001 12:03:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XmnY-0002VK-00 for namedroppers-data@psg.com; Tue, 27 Feb 2001 08:16:24 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XmnY-0002VE-00 for namedroppers@ops.ietf.org; Tue, 27 Feb 2001 08:16:24 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XmnY-000CSl-00 for namedroppers@ops.ietf.org; Tue, 27 Feb 2001 08:16:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5.0.2.1.0.20010227105724.02d426b0@gatt.dc.ogud.com> Date: Tue, 27 Feb 2001 11:16:38 -0500 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Q: Is authenticated denial needed ?? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The working group needs to answer some hard questions, and I would like them to be discussed before we start rewriting RFC2535. This message is contains an introduction to the subject and the first/biggest question. Background: When DNSSEC was designed there was perceived need to be able to signal existence of names and types to prevent spoofing. The NXT record is used to signal the existence or non existence of a name and/or RR type. NXT are generally not liked but have been considered "necessary evil" to protect the DNS. We have on the table an alternate proposal that addresses many of the deficiencies in NXT. The NO record has been designed as a alternative to NXT addressing the drawbacks identified in NXT. Advantages: No spoofed data will be trusted if it is not substantiated by NXT/NO records. One of the nice side effects of NXT/NO records is that they can be used to authenticate the existence of delegations and if the parent has signed key sets for the child. (A better solution would to have a real Delegation record at the parent). The NXT/NO can in theory be used for negative answer generation by caching servers. Spoofing attacks against DNS servers become harder. Disadvantages: Zones get larger, 1 more record set for each name in the zone, in the case of NO double the number of names. Negative answers still need SOA records in them for backward compatibility. Answers are larger as multiple NXT/NO records are needed in the wild card case. In many cases authoritative servers must be asked to get trusted answer. Authenticated denial of existence can be accomplished by asking a authoritative server, either directly or via chain of trusted servers. NXT and NO require ordering in DNS data bases and prevent efficient lookups. NXT and NO require quite a bit of extra processing. Alternatives to NXT/NO: Signed/Authenticated answer from a Authorative server can be used to derive enough information to determine that record/name does not exist. The cost of TSIG without TKEY is astronomical, the cost with TKEY is high and can become DOS attack on servers. The cost of SIG(0) is lower if there are only few messages exchanged. And of course this depends on nameservers having keys on line and complicates DNSSEC validation process as keys of nameservers have to be validated as well as the name in question. Question 1: Is authenticated denial NEEDED ? If answer to 1 is yes Question 2: Does NO have advantages over NXT that justify replacement considerations? If answer to 1 is maybe Question 3: Should NXT/NO become experimental for now ? (If yes this complicates DNSSEC resolver quite a bit). One of the reasons for asking this questions now is to document the why NXT/NO is included in DNSSEC. I would like this debate to conclude at the Minneapolis meeting. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 27 12:04:31 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18026 for ; Tue, 27 Feb 2001 12:04:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XmjL-0002Qj-00 for namedroppers-data@psg.com; Tue, 27 Feb 2001 08:12:03 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XmjK-0002Qd-00 for namedroppers@ops.ietf.org; Tue, 27 Feb 2001 08:12:02 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XmjK-000CPj-00 for namedroppers@ops.ietf.org; Tue, 27 Feb 2001 08:12:02 -0800 Message-ID: <1ad501c0a0d8$1dbd01c0$cd4751d1@primedata.org> From: "Erik Aronesty" To: Cc: , "Paul A Vixie" References: <200102270240.f1R2eAh67515@drugs.dv.isc.org> Subject: Re: cnames are in conflict with soa's... Date: Tue, 27 Feb 2001 11:12:39 -0500 MIME-Version: 1.0 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 1. Because it makes absolutely no sense to have CNAME's excluded from a particluar node in the tree - since the DNS algorithm is generic and works (check to see if there's a CNAME, if there is, go back to step 1 using the target) regardless of where a CNAME is. 2. Most DNS servers in the world already support this feature though BIND 8.2.2, only BIND 8.2.3 stopped supporting it -and subsequently a percentage of zones in the world stopped working. 3. So now these people are hard-coding in IP addresses to service providers like everyone.net, yahoo and akamai - resuling in a support nighmare that is getting worse by the hour. 4. There's a hack to get CNAME's to work for any node within the DNS system. You can make a zone "com" and put a "foo.com IN CNAME ..." record in it. However, requiring people to be authoritative for "com" in order to get their old CNAME's to work is completely wacky - and I had to patch BIND to prevent users from doing it on my servers. Anyway, the system allowed CNAME's at any level in the tree for 15 years or so. Suddenly it doesn't and there's bound to be some issues. I outlined a few - that's all. - Erik ----- Original Message ----- From: To: "Erik Aronesty" Cc: ; "Paul A Vixie" Sent: Monday, February 26, 2001 9:40 PM Subject: Re: cnames are in conflict with soa's... > > Eric, why do you want a CNAME at the top of zone? Is it because > you have a another party hosting your HTTP service? There is DNS > resource record specifically for supporting this sort of thing, > it is called SRV which provides a generalised form of the MX > record. It has been around since 1996. > > Now you will find it much easier to update all the http clients > in the world than it will be to update all the DNS servers in > the world. For one thing, people are used to updating HTTP > clients. Secondly it is a better solution. > > Of course if we go down your track you can't arange to get your > mail delivered to a different box than where the mail is delivered > for box hosting the HTTP traffic. > > People want to be able to say > > @ MX 0 mail.example.com. > _http._tcp SRV ... http.example1.net. > _ftp._tcp SRV ... ftp.example2.net. > _kerberos._udp SRV ... kdc.example.com. > > This is the solution space you should be aiming at. Complain > to Netscape, Microsoft etc. saying that you want SRV support > in the browsers, ftp client etc. > > > To be more clear: > > > > A. Confusing usage > > > > In order to create a CNAME for a domain, it is necessary to create a parent > > node, and then add the CNAME within it. However, you do not have to be > > authoritative for the parent node. This forces the DNS user to make odd > > configuration choices to get CNAME's to work in the case where he is not > > authoritative for the parent. > > > > For example: in order to CNAME "foo.com" it is currently necessary to create > > a "com" zone, and add a "microsoft" domain to it. This works well - however > > it is a potentially confusing configuration. > > If you want example.com to be an alias lobby the Internic to allow > CNAMES to be added to the COM zone. Other registries allow it, > however you have a to choose between that and a delegation. > > > > > This same analogy holds for all levels of the DNS tree. > > > > The reason why this is necessary is that SOA RR's are required for all > > zones - but CNAME records cannot coexist with SOA RR's. > > > > B. Misleading information > > > > 1) Currently, in the case of CNAME's the authority section, if present, > > returns information about the alias - not the target. > > You are getting back a negative answer here. If you don't > understand why you are getting the SOA record from the > target zone then I suggest that you read RFC 2308. > > > 2) When requesting an > > SOA record for a name that has been aliased to another - the SOA record of > > the target is returned. > > You get undefined behaviour when you choose to ignore > errors. > > > 3) The SOA record of the target contains > > information that is misleading in any circumstances. > > Again you have choosen to ignore error messages and get > undefined behaviour. > > > > > Clearly CNAMEs are, as currently implemented a source of confusion and > > excessive technical support for DNS maintainers. > > There is no confusion. RFC 1034/1035 clearly state that > CNAMES cannot exist with other records. It is precisely > because it can cause the confusion you are seeing here that > they are are not allowed to exist with any other record. > > You get the same sort of confusion when you deal with MX records > and CNAME's. The next thing you will be asking us for is to > support CNAMES and MX records at top of zone. > > > > > It appears there are three solutions: > > > > 1- allow CNAMEs to coexist with SOA records > > 2- create a new query type (IE: DNAME, as proposed) which has a pure, > > recursive implementation > > 3- make CNAME's obsolete > > > > 4. Read the existing RFC's and error messages from your software > and work within the constraints imposed. > > > Also: > > > > The majority of DNS software currently supports CNAME's alongside SOA > > records - without any negative effects (because the majority of DNS software > > is based on BIND 8.2.2 or prior versions - which supported this). So, the > > negative impact of allowing this would be minimal. > > BIND 8.2.2 does *not* support CNAME's along side SOA records. It > flags it as a error. It prevents the zone being tranmitted in this > error state. The reason this was done was so that the server could > continue to serve the rest of the zone WHILE YOU FIXED THE ERRROR. > > > > > The positive impact would be that CNAME's could be used at the root of a > > zone - which, for a long time, was a excellent DNS feature that has recently > > been abandoned. > > It's not been abandoned. It's NEVER been allowed. > > > > > - Erik > -- > 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. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 27 13:22:06 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21900 for ; Tue, 27 Feb 2001 13:22:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XoHC-0004Ck-00 for namedroppers-data@psg.com; Tue, 27 Feb 2001 09:51:06 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XoHC-0004Ce-00 for namedroppers@ops.ietf.org; Tue, 27 Feb 2001 09:51:06 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XoHB-000DBE-00 for namedroppers@ops.ietf.org; Tue, 27 Feb 2001 09:51:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A9BE8C1.B7FD30E2@san.rr.com> Date: Tue, 27 Feb 2001 09:49:53 -0800 From: Doug Barton To: Erik Aronesty CC: namedroppers@ops.ietf.org, Paul A Vixie Subject: Re: cnames are in conflict with soa's... References: <1a1901c0a058$aaa1cab0$cd4751d1@primedata.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Aronesty wrote: > Clearly CNAMEs are, as currently implemented a source of confusion and > excessive technical support for DNS maintainers. Mostly because they are used improperly and excessively as solutions for problems they were never intended to address. Kevin's point about dns administrator clue dilution is well taken here. > It appears there are three solutions: > > 1- allow CNAMEs to coexist with SOA records > 2- create a new query type (IE: DNAME, as proposed) which has a pure, > recursive implementation > 3- make CNAME's obsolete You are ignoring the fourth option, which is to continue following the RFC's and use CNAME's as they were intended. > Also: > > The majority of DNS software currently supports CNAME's alongside SOA > records - without any negative effects (because the majority of DNS software > is based on BIND 8.2.2 or prior versions - which supported this). So, the > negative impact of allowing this would be minimal. The only truly safe way to handle this situation is to follow the RFC's. Before an implementation change could be considered it should be vetted through the traditional RFC engineering process which includes compatability testing. Forcing an implementation change that contradicts the RFC's because you think it will work is simply not how it is done. > The positive impact would be that CNAME's could be used at the root of a > zone - which, for a long time, was a excellent DNS feature that has recently > been abandoned. Other than the fact that this option would make it easier for certain silly edge case configurations you've yet to show any benefits from your proposal. On the other hand, you are either ignoring, or ignorant of the many reasons this is a bad idea. Doug -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Feb 27 15:00:08 2001 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26859 for ; Tue, 27 Feb 2001 15:00:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14XppR-0005ru-00 for namedroppers-data@psg.com; Tue, 27 Feb 2001 11:30:33 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14XppQ-0005rm-00 for namedroppers@ops.ietf.org; Tue, 27 Feb 2001 11:30:32 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XppQ-000Dwy-00 for namedroppers@ops.ietf.org; Tue, 27 Feb 2001 11:30:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 27 Feb 2001 14:29:10 -0500 (EST) From: Olafur Gudmundsson To: Erik Aronesty cc: Mark.Andrews@nominum.com, namedroppers@ops.ietf.org, Paul A Vixie Subject: Re: cnames are in conflict with soa's... In-Reply-To: <1ad501c0a0d8$1dbd01c0$cd4751d1@primedata.org> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 27 Feb 2001, Erik Aronesty wrote: > 1. Because it makes absolutely no sense to have CNAME's excluded from a > particluar node in the tree - since the DNS algorithm is generic and works > (check to see if there's a CNAME, if there is, go back to step 1 using the > target) regardless of where a CNAME is. Yes it does, but you are not listening, read what Mark said. CNAME says this name has been renamed and the only information you can store with CNAME is KEY, SIG and NXT (see RFC2535) why. > > 2. Most DNS servers in the world already support this feature though BIND > 8.2.2, only BIND 8.2.3 stopped supporting it -and subsequently a percentage > of zones in the world stopped working. This is the cost of not following the rules, just like speeding and running read lights, we all do it, but that does not make it legal. > > 3. So now these people are hard-coding in IP addresses to service providers > like everyone.net, yahoo and akamai - resuling in a support nighmare that is > getting worse by the hour. Follow the rules and life will get better. > > 4. There's a hack to get CNAME's to work for any node within the DNS system. > You can make a zone "com" and put a "foo.com IN CNAME ..." record in it. > However, requiring people to be authoritative for "com" in order to get > their old CNAME's to work is completely wacky - and I had to patch BIND to > prevent users from doing it on my servers. If that works for you, use it, but stop trying to change the rules without writing an Internet Draft documenting the change and have the working group comment on it. > > Anyway, the system allowed CNAME's at any level in the tree for 15 years or > so. Suddenly it doesn't and there's bound to be some issues. I outlined a > few - that's all. I do not see any groundswell support for your insistance that non compliant software not be fixed. Remember: the DNS protocol is defined by RFC's not by implementations. 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 Feb 28 05:11:13 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01292 for ; Wed, 28 Feb 2001 05:11:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Y2ro-000Lg9-00 for namedroppers-data@psg.com; Wed, 28 Feb 2001 01:25:52 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Y2rn-000Lg3-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 01:25:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Y2rn-000J8N-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 01:25:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102280905.f1S95O662685@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 28 Feb 2001 10:05:24 +0100 In-Reply-To: "Olafur Gudmundsson's message as of Feb 27, 18:24" To: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: Q: Is authenticated denial needed ?? Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Olafur Gudmundsson, on Feb 27, 18:24, in "Q: Is authenticated ..."] > The working group needs to answer some hard questions, and I > would like them to be discussed before we start rewriting RFC2535. Before going into these questions, I am interested to know wether I have missed that there was consensus to abort the current effort to implement RFC2535? As it stands now, ISC/Nominum has spent and is still spending considerable effort into implementing RFC2535 into BIND, and NLnet Labs (for CENTR) into building an automated TLD registry. Currently, there is a working set of tools, which is in use for the secure test-ccTLD .nl.nl. These tools were developed and (worked more or less) with Bind8.2.2p5 and are now in "test-production" with the current Bind9 release. If we were mistaken to put effort into implementing RFC2535, it would have been a rather costly mistake, as some man-years of work have been wasted then. So again my question: Is there consensus to abort the implementation of RFC2535 and wait for a rewrite to defined? 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 Wed Feb 28 12:26:06 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15000 for ; Wed, 28 Feb 2001 12:26:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14Y9mK-0001zO-00 for namedroppers-data@psg.com; Wed, 28 Feb 2001 08:48:40 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14Y9mJ-0001zH-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 08:48:39 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Y9mJ-00041x-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 08:48:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102281330.f1SDU8m09421@syn.hamachi.org> From: Bill Sommerfeld To: Olafur Gudmundsson Cc: namedroppers@ops.ietf.org Subject: Re: Q: Is authenticated denial needed ?? In-Reply-To: Message from Olafur Gudmundsson of "Tue, 27 Feb 2001 11:16:38 EST." <5.0.2.1.0.20010227105724.02d426b0@gatt.dc.ogud.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Wed, 28 Feb 2001 08:30:08 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Question 1: Is authenticated denial NEEDED ? Yes. While it is impossible to guard against all denial-of-service attacks, authenticated denial provides robustness against transient denial-of-service attacks. In the absence of authenticated denial, applications (such as MTA's) which run "in background" without human intervention cannot take full advantage of DNSSEC; they would either have to (a) treat all NXDOMAIN responses as a "soft failure" (delaying notification to the end user, perhaps for days, that they misaddressed time-critical email), or (b) bounce mail when they get a NXDOMAIN (creating a vulnerability to a transient denial-of-service). > If answer to 1 is yes > Question 2: Does NO have advantages over NXT that justify replacement > considerations? It appears to answer several of the common complaints about NXT. I think deployment considerations should prevail here -- if the choice is between "NO" and either "no dnssec deployment for TLD's" or "no authenticated denial", then we should go with "NO". - Bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 28 12:52:35 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16092 for ; Wed, 28 Feb 2001 12:52:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YAJP-0002g7-00 for namedroppers-data@psg.com; Wed, 28 Feb 2001 09:22:51 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YAJO-0002fq-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 09:22:50 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YAJO-00051d-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 09:22:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 28 Feb 2001 11:01:44 -0500 (EST) From: Olafur Gudmundsson To: Ted.Lindgreen@tednet.nl cc: namedroppers@ops.ietf.org Subject: Re: Q: Is authenticated denial needed ?? In-Reply-To: <200102280905.f1S95O662685@open.nlnetlabs.nl> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 28 Feb 2001, Ted Lindgreen wrote: > [Quoting Olafur Gudmundsson, on Feb 27, 18:24, in "Q: Is authenticated ..."] > > > The working group needs to answer some hard questions, and I > > would like them to be discussed before we start rewriting RFC2535. > > Before going into these questions, I am interested to know wether > I have missed that there was consensus to abort the current effort > to implement RFC2535? No that is not what is happening, the plan is to rewrite RFC2535 to reflect all the update RFC's that have been issued (or are in the IESG queue). > > As it stands now, ISC/Nominum has spent and is still spending > considerable effort into implementing RFC2535 into BIND, and > NLnet Labs (for CENTR) into building an automated TLD registry. Most of the changes/updates to RFC2535 have come from that effort. The overall goal is to make RFC2535 more readable, implementable and testable. > > Currently, there is a working set of tools, which is in use for the > secure test-ccTLD .nl.nl. These tools were developed and (worked more > or less) with Bind8.2.2p5 and are now in "test-production" with > the current Bind9 release. We hope that the experiance from these will help the update effort and will feed into the operational guidelines documents replacing RFC2541. > > If we were mistaken to put effort into implementing RFC2535, it > would have been a rather costly mistake, as some man-years of work > have been wasted then. IF that is the conclusion it is better to come to that conclusion now than 3-5 years down the road when 10x-100x more man years have been wasted in operating DNSSEC. But I do not think that is going to happen. The goal is to make DNSSEC more deployable. > > So again my question: > > Is there consensus to abort the implementation of RFC2535 > and wait for a rewrite to defined? > The question on the table is about one aspect of DNSSEC the authenticated denial, it is the most costly part of the specification and the one with least benefit. The question is it worth the cost, and if so we better document why. There is strong opposition to deploying NXT from many camps. The questions that I asked where is there need for authenticated denial and if there is need is NO so much better that we should switch. One proposal that I have got privatly is to make both NXT and NO experimental and see which one gets deployed and then move that one into the standards track. 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 Feb 28 13:16:43 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17360 for ; Wed, 28 Feb 2001 13:16:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YAlz-0003HC-00 for namedroppers-data@psg.com; Wed, 28 Feb 2001 09:52:23 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YAly-0003H5-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 09:52:22 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YAly-0005rF-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 09:52:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102281749.JAA94448@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: Q: Is authenticated denial needed ?? In-Reply-To: Message from Olafur Gudmundsson of "Wed, 28 Feb 2001 11:01:44 EST." Date: Wed, 28 Feb 2001 09:49:31 -0800 From: Paul A Vixie X-DCC-MAPS-Metrics: isrv3.isc.org 668; IP=0+391 env_From=0+436 From=0+441 Subject=0+13 Message-ID=0+1 Received=0+1 Body=0+1 Fuz1=0+1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > There is strong opposition to deploying NXT from many camps. > The questions that I asked where is there need for authenticated denial > and if there is need is NO so much better that we should switch. NO looks different but not necessarily better. The only people I'd trust to give an answer are actual engineers and engineering managers who have implemented NXT (operably but not nec'ily interoperabily) and read the draft for NO. If those conditions can't be satisfied, then we're just shooting into the darkness with this whole discussion. > One proposal that I have got privatly is to make both NXT and NO > experimental and see which one gets deployed and then move that one into > the standards track. Please, gods, no. That was tried (by omission) with DSA vs RSA, with the result that the IESG flipflopped on the matter twice, upsetting a lot of plans each time. Is DNSSEC a complete architecture? If not, then let's abandon implementation attempts until it is. To be considered complete, such an architecture must specify whether authentic NXDOMAIN is a requirement, and if so, precisely how it is to be implemented (interoperably -- the Internet is not a collection of sandboxes any more). to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 28 19:09:55 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02561 for ; Wed, 28 Feb 2001 19:09:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YGGS-000A7U-00 for namedroppers-data@psg.com; Wed, 28 Feb 2001 15:44:12 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YGGR-000A7O-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 15:44:11 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YGGR-000FiO-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 15:44:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <081a01c0a1bd$fe84a290$cd4751d1@primedata.org> From: "Erik Aronesty" To: "Doug Barton" Cc: , "Paul A Vixie" References: <1a1901c0a058$aaa1cab0$cd4751d1@primedata.org> <3A9BE8C1.B7FD30E2@san.rr.com> Subject: Re: cnames are in conflict with soa's... Date: Wed, 28 Feb 2001 14:37:58 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Doug, Clearly, the resolver algorithm already supports this feature - if it plans on following the RFC's. This is a completely backward-compatible feature. Eliciting dialogue on this forum *is* a part of the process. RFC's are not used as "requests for comments" anymore. Should a DNS server issue an error if a CNAME is at the "zone top"? DNS is a "tree" of information. CNAME's can be at any node on this tree. If the text file they are in has SOA record for the same domain, then there's a problem. However the text file is required to have an SOA record if it's a "zone top". This is an indirect restriction on CNAME's at the zone top and should have been clarified in the RFC. RFC's should not create "implied rules". They should be careful to list all of the rules - so that things like this don't happen. At the very least, the RFC should be amended to state that CNAMEs are restricted from being served from any node that is a "parent" in the tree. This would be acceptable - but would expose the obvious problem. But, that way none of this would have happened. - Erik ----- Original Message ----- From: "Doug Barton" To: "Erik Aronesty" Cc: ; "Paul A Vixie" Sent: Tuesday, February 27, 2001 12:49 PM Subject: Re: cnames are in conflict with soa's... > Erik Aronesty wrote: > > > Clearly CNAMEs are, as currently implemented a source of confusion and > > excessive technical support for DNS maintainers. > > Mostly because they are used improperly and excessively as solutions for > problems they were never intended to address. Kevin's point about dns > administrator clue dilution is well taken here. > > > It appears there are three solutions: > > > > 1- allow CNAMEs to coexist with SOA records > > 2- create a new query type (IE: DNAME, as proposed) which has a pure, > > recursive implementation > > 3- make CNAME's obsolete > > You are ignoring the fourth option, which is to continue following the > RFC's and use CNAME's as they were intended. > > > Also: > > > > The majority of DNS software currently supports CNAME's alongside SOA > > records - without any negative effects (because the majority of DNS software > > is based on BIND 8.2.2 or prior versions - which supported this). So, the > > negative impact of allowing this would be minimal. > > The only truly safe way to handle this situation is to follow the RFC's. > Before an implementation change could be considered it should be vetted > through the traditional RFC engineering process which includes > compatability testing. Forcing an implementation change that contradicts > the RFC's because you think it will work is simply not how it is done. > > > The positive impact would be that CNAME's could be used at the root of a > > zone - which, for a long time, was a excellent DNS feature that has recently > > been abandoned. > > Other than the fact that this option would make it easier for certain > silly edge case configurations you've yet to show any benefits from your > proposal. On the other hand, you are either ignoring, or ignorant of the > many reasons this is a bad idea. > > Doug > -- > "Pain heals. Chicks dig scars. Glory . . . lasts forever." > -- Keanu Reeves as Shane Falco in "The Replacements" > > Do YOU Yahoo!? > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 28 19:46:40 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03624 for ; Wed, 28 Feb 2001 19:46:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YGvd-000B4P-00 for namedroppers-data@psg.com; Wed, 28 Feb 2001 16:26:45 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YGvd-000B4J-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 16:26:45 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YGvd-000Gsx-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 16:26:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200102282151.QAA03921@ct.engin.umich.edu> To: namedroppers@ops.ietf.org cc: levone@microsoft.com, skwan@microsoft.com Subject: Re: I-D ACTION:draft-esibov-dnsext-dynupdtld-00.txt Date: Wed, 28 Feb 2001 16:51:19 -0500 From: Steve Mattson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Concerning this draft: Date: Wed, 28 Feb 2001 06:58:39 EST To: IETF-Announce: ; From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-esibov-dnsext-dynupdtld-00.txt Title : Dynamic DNS Update of the Top Level Domain and Root Zones Author(s) : L. Esibov, S. Kwan Filename : draft-esibov-dnsext-dynupdtld-00.txt Pages : 4 Date : 27-Feb-01 Are you addressing the cause of the problem, or a symptom? If a pervasive misconfiguration of DNS clients is resulting in dyamic updates being sent to the root and tld servers, then shouldn't the draft address the basic configuration issue and not just say "well, we know they're wrong, but we'll turn then off and forget about it"? I'm not saying that this was your intent, but it could be read that way. Steve Mattson University of Michigan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Feb 28 20:06:26 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04271 for ; Wed, 28 Feb 2001 20:06:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YHJv-000BcF-00 for namedroppers-data@psg.com; Wed, 28 Feb 2001 16:51:51 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YHJv-000Bc9-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 16:51:51 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YHJv-000Hdl-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 16:51:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: I-D ACTION:draft-esibov-dnsext-dynupdtld-00.txt Date: Wed, 28 Feb 2001 15:40:01 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657405146F16@DF-BOWWOW.platinum.corp.microsoft.com> From: "Levon Esibov" To: "Steve Mattson" , Cc: "Stuart Kwan" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Are you addressing the cause of the problem, or a symptom? =20 > If a pervasive > misconfiguration of DNS clients is resulting in dyamic=20 > updates being sent > to the root and tld servers, then shouldn't the draft address=20 > the basic > configuration issue and not just say "well, we know they're wrong, but > we'll turn then off and forget about it"? I'm not saying=20 > that this was > your intent, but it could be read that way. We are not suggesting that DNS client configuration is not important. It is. But often implementers can't control configuration performed by Internet users. What we are saying is that DNS client should prevent at least "preventable" useless dynamic update requests - dynamic updates to the TLD zones and the root 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 Wed Feb 28 23:58:48 2001 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10960 for ; Wed, 28 Feb 2001 23:58:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14YKqV-000Fyq-00 for namedroppers-data@psg.com; Wed, 28 Feb 2001 20:37:43 -0800 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14YKqU-000Fyk-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 20:37:42 -0800 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14YKqU-000NmW-00 for namedroppers@ops.ietf.org; Wed, 28 Feb 2001 20:37:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3A9DA062.63744DB3@daimlerchrysler.com> Date: Wed, 28 Feb 2001 20:05:38 -0500 From: Kevin Darcy To: namedroppers@ops.ietf.org Subject: Re: cnames are in conflict with soa's... References: <1a1901c0a058$aaa1cab0$cd4751d1@primedata.org> <3A9BE8C1.B7FD30E2@san.rr.com> <081a01c0a1bd$fe84a290$cd4751d1@primedata.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Aronesty wrote: > Doug, > > Clearly, the resolver algorithm already supports this feature - if it plans > on following the RFC's. This is a completely backward-compatible feature. > Eliciting dialogue on this forum *is* a part of the process. RFC's are not > used as "requests for comments" anymore. > > Should a DNS server issue an error if a CNAME is at the "zone top"? > > DNS is a "tree" of information. CNAME's can be at any node on this tree. Subject to the "CNAME and other data" rule, of course. > If the text file they are in has SOA record for the same domain, then > there's a problem. However the text file is required to have an SOA record > if it's a "zone top". No, this has nothing to do with "text files" _per_se_. Although the RFC's specify "master file format", I'm not aware of any requirement that text files be used to load DNS zones. It is more proper, I think, to state that a zone must have at least 1 SOA RR and 1 NS RR. This is true *regardless* of whether a text file is used to load the zone. > This is an indirect restriction on CNAME's at the zone top and should have > been clarified in the RFC. I suppose we can differ on whether the restriction is "indirect" or not, but it seems to me to follow, by simple logical implication, from 1. CNAME records can't co-exist with records of other types having the same owner name, and 2. The name of a zone must own at least 1 NS and 1 SOA record that 3. a CNAME can't have the same owner name as that of a zone. But then, what do I know from syllogisms? I only have a degree in Philosophy... > RFC's should not create "implied rules". They should be careful to list all > of the rules - so that things like this don't happen. > > At the very least, the RFC should be amended to state that CNAMEs are > restricted from being served from any node that is a "parent" in the tree. > This would be acceptable - but would expose the obvious problem. But, that > way none of this would have happened. Feel free to submit a clarifying Internet Draft. - 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.