From owner-namedroppers@ops.ietf.org Wed Jun 1 02:41:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08156 for ; Wed, 1 Jun 2005 02:41:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdMoj-000Eru-LL for namedroppers-data@psg.com; Wed, 01 Jun 2005 06:35:05 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DdMoh-000Er0-Ma for namedroppers@ops.ietf.org; Wed, 01 Jun 2005 06:35:04 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id C55FC24248; Wed, 1 Jun 2005 08:35:02 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C6E94242C6 for ; Wed, 1 Jun 2005 08:35:01 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j516Z145031230 for ; Wed, 1 Jun 2005 08:35:01 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j516Z1fH015638 for namedroppers@ops.ietf.org; Wed, 1 Jun 2005 08:35:01 +0200 Date: Wed, 1 Jun 2005 08:35:01 +0200 From: Olaf Kolkman Message-Id: <200506010635.j516Z1fH015638@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: U 0.491037 / -5.9 X-RIPE-Signature: 49f6130ccfc5aeddab259806cfb1b1ce X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. 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. - Specific items that are not not appropriate for posting 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, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 1 05:52:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14687 for ; Wed, 1 Jun 2005 05:52:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdPrL-0002vs-IE for namedroppers-data@psg.com; Wed, 01 Jun 2005 09:49:59 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DdPrH-0002vZ-Pg for namedroppers@ops.ietf.org; Wed, 01 Jun 2005 09:49:55 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 1125F24506; Wed, 1 Jun 2005 11:49:55 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 289B323EFD for ; Wed, 1 Jun 2005 11:49:54 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j519ns45023770 for ; Wed, 1 Jun 2005 11:49:54 +0200 Date: Wed, 1 Jun 2005 11:49:54 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: RFC2538bis, an update. Message-Id: <20050601114954.44a84e37.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000002 / -5.9 X-RIPE-Signature: fec964075bc84225a2911da2ec891822 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear colleagues, The last call on RFC2538bis has concluded[1], there were a few issues that have been addressed in version 2 in the document. There were some questions on the IANA considerations (see thread starting at [2]), since nobody identified possible interoperability problems if we leave the text as is we'll leave the text as is. No volunteers have stepped forward for interoperability testing. If nobody steps forward before the end of the week I'll be forwarding this document to obsolete RFC2538 as a proposed standard. There is no reason to stall any longer. --Olaf Also see http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-02.txt and http://josefsson.org/rfc2538bis/ [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00740.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00273.html -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 1 08:33:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12067 for ; Wed, 1 Jun 2005 08:33:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdSL5-000GhD-Vf for namedroppers-data@psg.com; Wed, 01 Jun 2005 12:28:51 +0000 Received: from [130.59.4.87] (helo=diotima.switch.ch) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DdSL4-000Ggq-Jw for namedroppers@ops.ietf.org; Wed, 01 Jun 2005 12:28:51 +0000 Received: from diotima.switch.ch (localhost [IPv6:::1]) by diotima.switch.ch (8.13.3+Sun/8.13.3) with ESMTP id j51CSm0N027772; Wed, 1 Jun 2005 14:28:48 +0200 (CEST) From: Simon Leinen Message-ID: <17053.43520.87383.96692@diotima.switch.ch> Date: Wed, 1 Jun 2005 14:28:48 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0TlUsJ0M1x" Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Fwd: [Announcing the 2005 SIGCOMM Award Winner: Paul Mockapetris] X-Mailer: VM 7.18 under Emacs 21.3.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --0TlUsJ0M1x Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I hope you find this relevant for namedroppers-- Simon. --0TlUsJ0M1x Content-Type: message/rfc822 Content-Description: forwarded message Received: from ozzie (ozzie.acm.org) by ozzie.acm.org (LSMTP for Windows NT v1.1b) with SMTP id <5.00062FC7@ozzie.acm.org>; Tue, 31 May 2005 22:25:55 -0400 Reply-To: Erich Nahum Sender: ACM SIGCOMM organizational discussions Precedence: list Message-Id: <1DdIkF-0004j0-Sl@zinal.switch.ch> From: Erich Nahum To: SIGCOMM-MEMBERS@LISTSERV.ACM.ORG Subject: Announcing the 2005 SIGCOMM Award Winner: Paul Mockapetris Date: Tue, 31 May 2005 22:14:00 -0400 MIME-Version: 1.0 PAUL V. MOCKAPETRIS WINS 2005 ACM SIGCOMM AWARD Paul V. Mockapetris, Chairman and Chief Scientist at Nominum Inc., is the winner of the 2005 ACM SIGCOMM Award. The SIGCOMM Award is widely recognized as the highest honor in computer networking. The Award recognizes lifetime achievement in and contributions to the field. It is awarded annually to a person whose work, over the course of his or her career, represents a significant contribution to the field and a substantial influence on the work and perceptions of others in the field. The SIGCOMM Award is presented to Dr. Mockapetris "in recognition of his foundational work in designing, developing and deploying the Domain Name System, and his sustained leadership in overall Internet architecture development." Paul Mockapetris created the original DNS protocol, wrote its first implementation, and worked with others to spread the DNS across the Internet. The design of DNS, which was the first major datagram protocol of the Internet, established a number of principles for key Internet infrastructural services. Its simplicity of design and fitness for purpose have stood the test of time. The strength of its design lies in a novel combination of hierarchy and caching that gives each organization absolute control over part of the namespace while simultaneously relying on caching to make the entire system efficient. Its success can be seen from the fact that DNS now handles many orders of magnitude more names and traffic than when it was first deployed, and yet the design and structure have remained intact. As a result the DNS design and caching mechanisms are often cited as two of the cornerstones on which the success of the Internet is built. In addition to his work on DNS, Dr. Mockapetris's career has included pioneering work on multiprocessor operating systems, virtual machines, and ring LAN technology. Further, Dr. Mockapetris played an important role in the deployment of networking technologies internationally. Starting during 1990-1993 as a program manager at ARPA, Dr. Mockapetris fostered the international deployment of multimedia conferencing, multicast, and QoS. His strong leadership in development of Internet architecture continued as Chair of the Internet Engineering Task Force during 1994-1996, as member of the Internet Architecture Board during 1994-1996, and then as member of the Federal Networking Council. Dr. Mockapetris is a recipient of the IEEE Internet Award and is an ACM Fellow. In summary, through his sustained effort in support of the Internet archicture, beginning with DNS and continuing through work at ARPA, IETF, and industry, Dr. Mockapetris has made far-reaching and influential contributions to computer networking. The 2005 SIGCOMM award recognizes Dr. Mockapetris for this lifetime record of achievement. --0TlUsJ0M1x-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 1 10:33:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22036 for ; Wed, 1 Jun 2005 10:33:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdUDj-0000FM-79 for namedroppers-data@psg.com; Wed, 01 Jun 2005 14:29:23 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DdUDh-0000F5-AF for namedroppers@ops.ietf.org; Wed, 01 Jun 2005 14:29:21 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 79830248E4; Wed, 1 Jun 2005 16:29:20 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id E3CE62483A for ; Wed, 1 Jun 2005 16:29:17 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j51ETH45017850 for ; Wed, 1 Jun 2005 16:29:17 +0200 Date: Wed, 1 Jun 2005 16:29:17 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07 Message-Id: <20050601162917.3444dc5b.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.001828 / -5.9 X-RIPE-Signature: cb49e047b0d91d23da6b1adfdb4a7a68 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, This is the second WGLC for the "Wildcard clarification document" The Role of Wildcards in the Domain Name System draft-ietf-dnsext-wcard-clarify-07.txt Abstract: This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. The first WGLC of this document was in September 2003 [1] and raised the issue of wildcard synthesis. That last call concluded [2] with overall consensus of the working-group is that clarification of wildcard behavior is necessary and that the document is to proceed on the standard track. A number of open issues were identified at that time and while clarifying these new issues came up. The main topics were the handling of NS, SOA, CNAME and DNAME types owned by a "*-labels". Hereby we start a last call that will end Sunday June 19. Please review the document. Please state you reviewed the document with your objections and support. Send your statement to the mailing list or to both chairs directly. Statements that the documents has been thoroughly reviewed by working group members do help in writing a summary for the IESG and to further shepherd the document. If no support or objections have been received the default action will be to forward this document to the IESG with a request to publish on the standards track. --Olaf & Olafur DNSEXT Chairs [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01558.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01756.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 1 11:00:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23907 for ; Wed, 1 Jun 2005 11:00:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdUfm-0003Im-BU for namedroppers-data@psg.com; Wed, 01 Jun 2005 14:58:22 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DdUfk-0003IG-Ge for namedroppers@ops.ietf.org; Wed, 01 Jun 2005 14:58:20 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j51EwFW1026720 for ; Wed, 1 Jun 2005 10:58:15 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.1.2.2.20050601104058.03cf0320@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 01 Jun 2005 10:58:06 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: DNSEXT WGLC LLMNR-40 (Link-Local Multicast Name Resolution) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message starts a WGLC for LLMNR ending on June 17'th. Short history: The working group issued a Last call on this document[1] (version -22) in August 2003, after major changes version (34) was advanced[2] to the IESG in August 2004. The AD raised issues of omission in the design of the protocol. This resulted in a number of significant changes in the document. The current version (40) has addressed all the issued raised by the AD and subsequently by others. As the changes to the protocol document and protocol itself are significant the AD asked the working group to review the document again. Current version of the draft is at: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-40.txt This document has an issues tracker at: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html Summary of changes since version 33: - How names are determined to be unique and conflict resolution. - Coexistence of LLMNR, DNS and multiple transport protocols, this relates to if/when LLMNR is used and over what transport. - Editorial and clarifications of text. The document is on standards track. Please reply either to working group mailing list or both chairs with comments, or acknowledgement that you have no issues with the document. Olafur & Olaf [1] http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01510.html [2] http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01466.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 1 15:30:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19247 for ; Wed, 1 Jun 2005 15:30:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DdYrL-0001so-Ke for namedroppers-data@psg.com; Wed, 01 Jun 2005 19:26:35 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DdYrK-0001sY-Un for namedroppers@ops.ietf.org; Wed, 01 Jun 2005 19:26:34 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 01 Jun 2005 12:26:33 -0700 X-IronPort-AV: i="3.93,157,1115017200"; d="scan'208"; a="640235783:sNHT28562088" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j51JOols027414; Wed, 1 Jun 2005 12:26:30 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 15:26:19 -0400 Received: from 161.44.65.252 ([161.44.65.252]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Jun 2005 19:26:18 +0000 Received: from localhost.localdomain by email.cisco.com; 01 Jun 2005 15:26:49 -0400 Subject: dhc WG last call on From: Ralph Droms To: dhcwg@ietf.org, namedroppers@ops.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 01 Jun 2005 15:26:49 -0400 Message-Id: <1117654009.11049.67.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-2) X-OriginalArrivalTime: 01 Jun 2005 19:26:19.0068 (UTC) FILETIME=[C9491FC0:01C566DF] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, RCVD_NUMERIC_HELO autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (Cross-posted to namedroppers; see http://www1.ietf.org/mail- archive/web/dhcwg/current/msg05005.html for earlier discussion of this document) This message announces a WG last call on "Resolution of DNS Name Conflicts among DHCP Clients" . The last call will conclude at 1700 EST (USA) on 2005-06-08. Please respond to this WG last call. Note that this is the *second* last call for this document. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of discussion does not represent positive support. If there is no expression of support for acceptance during the WG last call, the document will not be advanced to the IESG. If you commented about this document between the first last call and this new last call, please repost your comment so we can be sure to assess all support for the document. Summary: There are options in DHCP that can be used for transmitting information about updating DNS. However, these do not explicitly control updating the name to address and address to name mappings maintained in the DNS, as performed by hosts acting as DHCP clients and servers. draft-ietf-dhc-ddns-resolution-08.txt describes techniques for the resolution of DNS name conflicts among DHCP clients and servers. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns- resolution-08.txt - Ralph Droms -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 08:54:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24028 for ; Fri, 3 Jun 2005 08:54:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeBbt-000G6k-BH for namedroppers-data@psg.com; Fri, 03 Jun 2005 12:49:13 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DeBbq-000G6R-Qm for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 12:49:11 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j53CjEjJ018633 for ; Fri, 3 Jun 2005 08:45:14 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAkKaGyK; Fri, 3 Jun 05 08:45:11 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j53Cl1N3006843; Fri, 3 Jun 2005 08:47:01 -0400 (EDT) Date: Fri, 3 Jun 2005 08:47:00 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: Glue (was Re: validating a qtype=* response) In-Reply-To: Message-ID: References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> <20050520125231.GE17267@chinook.corpit.vrsn.com> <42932670.9060106@verisignlabs.com> <42937CE3.7020105@verisignlabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 24 May 2005, Edward Lewis wrote: > So - in summary, what I am saying is that you should only return > NOERROR/NODATA for a qtype=* when the name is a previously sought > empty non-terminal, in the negative cache. The existence of names > ought never be inferred by a cache, if a name is not explicitly in > local information, and recursion is permitted, the server ought to > recurse. I think I agree with Ed here. Would you gentlemen take a look at the new bis-updates doc and see if Section 2.3 is adequate? I know it doesn't capture all of the subtlety discussed in this thread, but I'm thinking it still might be adequate for most readers. Here it is, for ease of reference: 2.3 Validating Responses to an ANY Query RFC4035 does not address now to validate responses when QTYPE=*. As described in Section 6.2.2 of RFC1034, a proper response to QTYPE=* may include a subset of the RRsets at a given name -- it is not necessary to include all RRsets at the QNAME in the response. When validating a response to QTYPE=*, validate all received RRsets that match QNAME and QCLASS. If any of those RRsets fail validation, treat the answer as Bogus. If there are no RRsets matching QNAME and QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as clarified in this document). To be clear, a validator must not insist on receiving all records at the QNAME in response to QTYPE=*. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 09:35:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26895 for ; Fri, 3 Jun 2005 09:35:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeCJ0-000J0e-Qr for namedroppers-data@psg.com; Fri, 03 Jun 2005 13:33:46 +0000 Received: from [195.47.254.10] (helo=mail.schlyter.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DeCJ0-000J0P-1q for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 13:33:46 +0000 Received: by mail.schlyter.se (Postfix, from userid 2038) id 68DE22DE5F; Fri, 3 Jun 2005 15:33:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.schlyter.se (Postfix) with ESMTP id 67B922DE5A for ; Fri, 3 Jun 2005 15:33:44 +0200 (CEST) Date: Fri, 3 Jun 2005 15:33:44 +0200 (CEST) From: Roy Arends X-X-Sender: roy@trinitario.schlyter.se To: namedroppers@ops.ietf.org Subject: where did all them bits go ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I guess 4034 and 4035 are missing information on where exactly the CD and AD bits reside in the DNS header. Its specified in rfc2535, but omitted in the current drafts, which obsolete 2535. I'll send text. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 10:00:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29491 for ; Fri, 3 Jun 2005 10:00:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeCgh-000Kjw-6T for namedroppers-data@psg.com; Fri, 03 Jun 2005 13:58:15 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DeCgg-000Kjc-9a for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 13:58:14 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j53Dvqg0008848 for ; Fri, 3 Jun 2005 09:58:11 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j53Dv76u016493 for ; Fri, 3 Jun 2005 09:57:07 -0400 (EDT) From: "Scott Rose" To: Subject: RE: Glue (was Re: validating a qtype=* response) Date: Fri, 3 Jun 2005 09:57:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit So to summarize: if one RRSIG covering one RRset in a response for QTYPE="*" fails to validate, then the whole response is marked Bogus. I can accept that. However, that might lead to a weird situation where a cache would have the same RRset in the BAD cache and the "good" cache for the same QNAME, but with one stored as a part of a QTYPE="*" query. This assumes the cache is storing responses as a single atomic unit based on qname/qclass/qtype (which may not be the case for some). Not sure how that would affect things. I would suggest changing the wording of the last sentence to state: "To be clear, a validator must not expect to receive all records at the QNAME in response to QTYPE=* if the query is sent to a cache and not an authoritative server." This would bring it in line with what RFC 1034 has in the examples for QTYPE="*" (Section 6.2.2). Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Samuel Weiler > > On Tue, 24 May 2005, Edward Lewis wrote: > > > So - in summary, what I am saying is that you should only return > > NOERROR/NODATA for a qtype=* when the name is a previously sought > > empty non-terminal, in the negative cache. The existence of names > > ought never be inferred by a cache, if a name is not explicitly in > > local information, and recursion is permitted, the server ought to > > recurse. > > I think I agree with Ed here. > > Would you gentlemen take a look at the new bis-updates doc and see if > Section 2.3 is adequate? I know it doesn't capture all of the > subtlety discussed in this thread, but I'm thinking it still might be > adequate for most readers. Here it is, for ease of reference: > > 2.3 Validating Responses to an ANY Query > > RFC4035 does not address now to validate responses when QTYPE=*. As > described in Section 6.2.2 of RFC1034, a proper response to QTYPE=* > may include a subset of the RRsets at a given name -- it is not > necessary to include all RRsets at the QNAME in the response. > > When validating a response to QTYPE=*, validate all received RRsets > that match QNAME and QCLASS. If any of those RRsets fail validation, > treat the answer as Bogus. If there are no RRsets matching QNAME and > QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as > clarified in this document). To be clear, a validator must not > insist on receiving all records at the QNAME in response to QTYPE=*. > > -- Sam > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 10:00:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29517 for ; Fri, 3 Jun 2005 10:00:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeChA-000KnY-1o for namedroppers-data@psg.com; Fri, 03 Jun 2005 13:58:44 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DeCh9-000KnI-9A for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 13:58:43 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j53DvqgK008848; Fri, 3 Jun 2005 09:58:16 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j53Dv76w016493; Fri, 3 Jun 2005 09:57:08 -0400 (EDT) From: "Scott Rose" To: "Roy Arends" , Subject: RE: where did all them bits go ? Date: Fri, 3 Jun 2005 09:57:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yeah, I think Sam W mentioned this to me at some point as well. I remember earlier versions of the text had them included, but disappeared in the rewrites. I think because it was in the records draft, and we forgot to move it, but I'm not sure. The IANA registry for DNS header bits does include the CD and AD positions, but an implementor would only know that if they consulted the IANA registry as well as the spec. Also, the IANA reference for the bits is still given as the dnssec-protocol draft and not the RFC... oops. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Roy Arends > Sent: Friday, June 03, 2005 9:34 AM > To: namedroppers@ops.ietf.org > Subject: where did all them bits go ? > > > I guess 4034 and 4035 are missing information on where exactly the CD and > AD bits reside in the DNS header. Its specified in rfc2535, but omitted in > the current drafts, which obsolete 2535. > > I'll send text. > > Roy > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 10:22:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02894 for ; Fri, 3 Jun 2005 10:22:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeD1b-000MYz-BW for namedroppers-data@psg.com; Fri, 03 Jun 2005 14:19:51 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DeD1Y-000MYi-HL for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 14:19:48 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j53EFrOB026679 for ; Fri, 3 Jun 2005 10:15:53 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWLaOg0; Fri, 3 Jun 05 10:15:50 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j53EHdJX010744; Fri, 3 Jun 2005 10:17:39 -0400 (EDT) Date: Fri, 3 Jun 2005 10:17:39 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Roy Arends cc: namedroppers@ops.ietf.org, iana@iana.org Subject: Re: where did all them bits go ? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 3 Jun 2005, Roy Arends wrote: > I guess 4034 and 4035 are missing information on where exactly the CD and > AD bits reside in the DNS header. Its specified in rfc2535, but omitted in > the current drafts, which obsolete 2535. > > I'll send text. I concur that it's a good idea to mention this registry in draft-ietf-dnsext-dnssec-bis-updates just as 4034 section 7 mentioned, but did not change, (some of?) the other relevant ones. That said, since this is an IANA-managed registry[1] and the assignment is still documented in RFC2929 (BCP42), I don't think this is a big deal. A citation to 2929 is probably in order, too. Curiously, the IANA registry for those bits[1] still references the -protocol draft -- it was never updated to reflect the publication of RFC4035. It also doesn't mention 2929, which sets a threshhold for assigning a meaning to the Z bit (bit 9). The typecode registry [2] also still has refereces to -records and the ipseckey drafts. Sigh. I'm CC'ing this to IANA so they can fix both of these. Also, 4034 has an error in the IANA section (Section 7): the last paragraph claims that 3755 opened a registry [3] for KEY and DNSKEY flag values. That registry's applicablity was limited to only DNSKEY, not KEY, as noted in the registry. Since 4034 asserts that it's not making changes to IANA registries, I'll document this in bis-updates as an error in 4034, not a change to the registry. -- Sam, obsessive protocol geek [1] http://www.iana.org/assignments/dns-header-flags [2] http://www.iana.org/assignments/dns-parameters [3] http://www.iana.org/assignments/dnskey-flags -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 10:28:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03437 for ; Fri, 3 Jun 2005 10:28:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeD83-000N0z-0G for namedroppers-data@psg.com; Fri, 03 Jun 2005 14:26:31 +0000 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DeD81-000N0i-4R for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 14:26:29 +0000 Received: from [10.131.244.197] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Fri, 03 Jun 2005 10:26:27 -0400 id 00598381.42A06893.00004123 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Blacka Subject: Re: Glue (was Re: validating a qtype=* response) Date: Fri, 3 Jun 2005 10:26:22 -0400 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.730) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jun 3, 2005, at 9:57 AM, Scott Rose wrote: > So to summarize: if one RRSIG covering one RRset in a response for > QTYPE="*" fails to validate, then the whole response is marked > Bogus. I can > accept that. However, that might lead to a weird situation where a > cache > would have the same RRset in the BAD cache and the "good" cache for > the same > QNAME, but with one stored as a part of a QTYPE="*" query. This > assumes the > cache is storing responses as a single atomic unit based on > qname/qclass/qtype (which may not be the case for some). Not sure > how that > would affect things. I think implementers and implementations need to be careful with how they mix this sort of granularity. I would think that marking a message as bad in a BAD cache (or otherwise) shouldn't automatically effect the cached validation status (if any) of individual rrsets. You would mark a response as bogus if, say, the NS rrset in the authority section was bogus, even if the answer rrset in the answer section validated. In any case, Sam's proposed text isn't discussing caching, as I read it. It is discussing what should be returned to the client in a very generic way, which I think is appropriate. > I would suggest changing the wording of the last sentence to state: > > "To be clear, a validator must not expect to receive all records at > the > QNAME in response to QTYPE=* if the query is sent to a cache and > not an > authoritative server." Does that mean different validation rules for responses with AA=1? > This would bring it in line with what RFC 1034 has in the examples for > QTYPE="*" (Section 6.2.2). Otherwise, I'm fairly happy with Sam's proposed text, myself. I'm still concerned as to whether there is supporting text elsewhere in the DNS standard that speaks to the necessity to recurse when qtype=* and qname/qclass isn't present in the cache. I mean, I agree with Ed that certainly a cache *should* recurse, but are we confident that they all *do*? -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 10:49:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04866 for ; Fri, 3 Jun 2005 10:49:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeDS0-000ODi-HG for namedroppers-data@psg.com; Fri, 03 Jun 2005 14:47:08 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DeDRy-000ODM-NU for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 14:47:06 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j53EkqfU002069; Fri, 3 Jun 2005 10:47:00 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j53EkK6u006778; Fri, 3 Jun 2005 10:46:20 -0400 (EDT) From: "Scott Rose" To: "David Blacka" , Subject: RE: Glue (was Re: validating a qtype=* response) Date: Fri, 3 Jun 2005 10:46:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Blacka > > > I would suggest changing the wording of the last sentence to state: > > > > "To be clear, a validator must not expect to receive all records at > > the > > QNAME in response to QTYPE=* if the query is sent to a cache and > > not an > > authoritative server." > > Does that mean different validation rules for responses with AA=1? > Nope - probably should be more clear. I meant to say that a client should not expect to get all the RRsets for a given QNAME if it sends a query to a cache. Bascially change the "insist" to "expect", since there is no way to say "I really, really mean it this time" when sending a query. :) > > This would bring it in line with what RFC 1034 has in the examples for > > QTYPE="*" (Section 6.2.2). > > Otherwise, I'm fairly happy with Sam's proposed text, myself. I'm > still concerned as to whether there is supporting text elsewhere in > the DNS standard that speaks to the necessity to recurse when qtype=* > and qname/qclass isn't present in the cache. I mean, I agree with Ed > that certainly a cache *should* recurse, but are we confident that > they all *do*? > I'm not. Scott > -- > David Blacka > Sr. Engineer VeriSign Applied Research > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 10:50:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04955 for ; Fri, 3 Jun 2005 10:50:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeDUO-000OMs-A9 for namedroppers-data@psg.com; Fri, 03 Jun 2005 14:49:36 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DeDUN-000OMe-JI for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 14:49:35 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j53Ejepn029091 for ; Fri, 3 Jun 2005 10:45:40 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAg0aWZ4; Fri, 3 Jun 05 10:45:37 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j53ElVwg011714; Fri, 3 Jun 2005 10:47:31 -0400 (EDT) Date: Fri, 3 Jun 2005 10:47:31 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Scott Rose cc: namedroppers@ops.ietf.org Subject: RE: where did all them bits go ? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (oops -- replies crossing on the wire) On Fri, 3 Jun 2005, Scott Rose wrote: > Yeah, I think Sam W mentioned this to me at some point as well. I remember > earlier versions of the text had them included, but disappeared in the > rewrites. I think because it was in the records draft, and we forgot to > move it, but I'm not sure. Scott's memory seems to be better than mine -- looking back though old mail, I see that on 20 Jan 2004 I did indeed point out that the AD and CD bits were missing from the omnibus IANA section in -records (4034), and Scott replied, telling me they were in -protocol (4035). (You'd think I would have learned...) It's still there (in section 6 of 4035), but, as Roy said, doesn't repeat the exact bit locations -- since 4034 section 7 talks about the contents of all the registries it mentions, I'll look forward to getting Roy's bis-updates contribution that adds the same detail for the header bits. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 11:30:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08169 for ; Fri, 3 Jun 2005 11:30:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeE5h-0001Jn-RB for namedroppers-data@psg.com; Fri, 03 Jun 2005 15:28:09 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DeE5e-0001JX-QI for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 15:28:06 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6369813921 for ; Fri, 3 Jun 2005 15:28:06 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Glue (was Re: validating a qtype=* response) In-Reply-To: Your message of "Fri, 03 Jun 2005 08:47:00 -0400." References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> <20050520125231.GE17267@chinook.corpit.vrsn.com> <42932670.9060106@verisignlabs.com> <42937CE3.7020105@verisignlabs.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 03 Jun 2005 15:28:06 +0000 Message-Id: <20050603152806.6369813921@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > So - in summary, what I am saying is that you should only return > > NOERROR/NODATA for a qtype=* when the name is a previously sought > > empty non-terminal, in the negative cache. The existence of names > > ought never be inferred by a cache, if a name is not explicitly in > > local information, and recursion is permitted, the server ought to > > recurse. > > I think I agree with Ed here. me too. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 14:46:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22065 for ; Fri, 3 Jun 2005 14:46:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeH7M-000Fg1-Uc for namedroppers-data@psg.com; Fri, 03 Jun 2005 18:42:04 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DeH7L-000Ffj-ND for namedroppers@ops.ietf.org; Fri, 03 Jun 2005 18:42:04 +0000 Received: from [10.31.32.238] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j53Ifrrk039729; Fri, 3 Jun 2005 14:41:54 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <428CE13A.4070503@verisignlabs.com> <428CF96B.4090806@verisignlabs.com> <20050520125231.GE17267@chinook.corpit.vrsn.com> <42932670.9060106@verisignlabs.com> <42937CE3.7020105@verisignlabs.com> Date: Fri, 3 Jun 2005 14:41:54 -0400 To: Samuel Weiler From: Edward Lewis Subject: Re: Glue (was Re: validating a qtype=* response) Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:47 -0400 6/3/05, Samuel Weiler wrote: >Would you gentlemen take a look at the new bis-updates doc and see if >Section 2.3 is adequate? I know it doesn't capture all of the >subtlety discussed in this thread, but I'm thinking it still might be >adequate for most readers. Here it is, for ease of reference: > >2.3 Validating Responses to an ANY Query > > RFC4035 does not address now to validate responses when QTYPE=*. As > described in Section 6.2.2 of RFC1034, a proper response to QTYPE=* > may include a subset of the RRsets at a given name -- it is not > necessary to include all RRsets at the QNAME in the response. > > When validating a response to QTYPE=*, validate all received RRsets > that match QNAME and QCLASS. If any of those RRsets fail validation, > treat the answer as Bogus. If there are no RRsets matching QNAME and > QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as > clarified in this document). To be clear, a validator must not > insist on receiving all records at the QNAME in response to QTYPE=*. I'm a little puzzled by the need for a bis-updates document at this point. For instance, the last sentence is not an update to the protocol but an reminder to implementers of something that is already plainly evident in the protocol definition. By plainly evident I mean that I can't think of any implementation to date that equates qtype=any with "all." I would say that serious work on an updates document ought to be held until there is demonstrated evidence of a need to clarify the original specifications. I think that incrementally trying to stamp out all foreseen bugs may work against a true test of the quality of the documents. There's something to be said for isolated development coming together in a bake-off and documenting the identifiable issues. Why had no one noticed that the bit position for the, what, CD and AD, bits been omitted? Maybe because we've all become a bit too chummy in the process. Being chummy is fine. But sometimes we tend to trust each other too much. Another reason I am surprised that such a document is progressing now is that documents sometimes peak too early. The first operation practices document for DNSSEC in DNSOP was begun by me on a plane coming home from the 1999 Minneapolis IETF. Yeah, a doomed effort if there ever was one. (It was based on 2065 semantics, or maybe 2535.) Even though the document was known to be needed then, it wasn't the time for it yet. I think discussing implementation faults is good, but I'd lag on the document effort for sometime. I think the experience gained is not yet ripe - and I wouldn't want to stunt an effort that might diverge from current popular sentiment that later proves to the the right way. Getting back to the issue at hand though, I really don't see a clarification here at all. Assuming we have a bad answer cache (as opposed to a negative cache and a good answer cache), then some part of the answer smells funny, it's funny - whether it's a specific type query or a qtype=any query. As per usual, a negative answer is a negative answer and needs to be treated as such. Looking back at the 4035 document, does it ever mention that there be a relationship between the QTYPE in the QUERY section and the RR's in the ANSWER section? I don't see it. I also don't see treatment of "bogus" messages ("treat the answer as bogus"), just "bogus" RRSets. So - I am not sure what we are trying to update or clarify here. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 3 20:46:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29432 for ; Fri, 3 Jun 2005 20:46:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DeMhy-000AnA-BF for namedroppers-data@psg.com; Sat, 04 Jun 2005 00:40:14 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DeMhw-000Amm-Jk for namedroppers@ops.ietf.org; Sat, 04 Jun 2005 00:40:12 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j540e9KN030944 for ; Sat, 4 Jun 2005 00:40:09 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j540e9gO030943 for namedroppers@ops.ietf.org; Sat, 4 Jun 2005 00:40:09 GMT Date: Sat, 4 Jun 2005 00:40:09 +0000 From: bmanning@vacation.karoshi.com To: namedroppers@ops.ietf.org Subject: blast from the past... Message-ID: <20050604004009.GA30900@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk draft-manning-opcode-discover-01.txt is BACK.... just in case your interested, the WG dropped this item formally at the London IETF. I'm going to ask for this to go out as an experimental RFC, as it documents some experimental work done in the late 1990s. --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. archive: From MarissaDean@obligor.com Sun Jun 5 09:09:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05276 for ; Sun, 5 Jun 2005 09:09:49 -0400 (EDT) Received: from 159.red-80-25-107.pooles.rima-tde.net ([80.25.107.159]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DevDG-0007NU-SF for dnsext-archive@ietf.org; Sun, 05 Jun 2005 09:31:11 -0400 Received: from oJd@localhost by ZhD.int (8.11.6/8.11.6); Sun, 05 Jun 2005 14:59:35 +0100 Message-ID: From: "Robt Harmon" Reply-To: "Robt Harmon" To: dnsext-archive@ietf.org Subject: All Photoshop software for cheap Date: Sun, 05 Jun 2005 07:59:35 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MarissaDean@obligor.com Content-Type: multipart/mixed; boundary="--e264BTSRghlFMC26kn" X-Spam-Score: 2.5 (++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 nina ----e264BTSRghlFMC26kn Content-Type: text/html; Content-Transfer-Encoding: quoted-printable v
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
5

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Window= s XP Pro
 3 Adobe Cre= ative Suite Premium
 4 Norton Antivirus 2005
  Flash MX 2004
 6 Corel Draw 12
 7 Adobe = Acrobat 7.0
 8 Window= s 2003 Server
 9 Alias = Maya 6 Wavefrt
 10 Adobe = Premiere
  See more= by this manufacturer
 <= /td>  Microsoft<= /td>
   Apple Software
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...
<= /td>



Microsoft Offi= ce Professional Edition *2003*
Microsoft
Choose= :
&= nbsp;
=
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze= and manage business information using Access databases
  • Exchange data with other systems using enhance= d XML technology
  • Control inf= ormation sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters a= nd printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: Int= ernational/US or via instant download
Date Coupon Expires: June= 30th, 2005
Average Customer Review: = 3D"5 Based on 1,768 reviews. Write a= review.
Microsoft Windows XP Professional or = Longhorn Edition
Microsoft =
Choose:
<= /td> <= /a>

List Price:$279.00
Price:$49.99
You Save:<= /td>$229.01 (= 85%)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Desi= gned for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt f= iles and folders
  • Built-in vo= ice, video, and instant messaging support
  • <= font size=3D1>Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Co= upon Expires: June 30th, 2005
Average= Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9= 0
Adobe=
Choose:=
 

List Price:<= /td> $599.00
Price:$69.99
You Save:$529.01 (90%)



= Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |&nb= sp; Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.=

----e264BTSRghlFMC26kn-- From KateMcwilliams@raceme.net Sun Jun 5 18:21:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08964 for ; Sun, 5 Jun 2005 18:21:25 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Df3pS-0000Ux-VR for dnsext-archive@ietf.org; Sun, 05 Jun 2005 18:42:53 -0400 Received: from [218.191.73.46] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Df3TW-0003TG-LI for dnsext-archive@ietf.org; Sun, 05 Jun 2005 18:20:11 -0400 Received: from YTzl@localhost by SSbN.int (8.11.6/8.11.6); Mon, 06 Jun 2005 02:26:15 +0300 Message-ID: From: "Diane Nicholas" Reply-To: "Diane Nicholas" To: dnsext-archive@ietf.org Subject: Windows XP Pro $49.95 Adobe, Windows Date: Sun, 05 Jun 2005 19:30:15 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: KateMcwilliams@raceme.net Content-Type: multipart/mixed; boundary="--HAcksmRKJR6FhwFEXArm" X-Spam-Score: 6.9 (++++++) X-Spam-Flag: YES X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 KnNS ----HAcksmRKJR6FhwFEXArm Content-Type: text/html; Content-Transfer-Encoding: quoted-printable l
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= tbody><= /td>
=
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

<= td width=3D4>  Microsoft=

 = ON SALE NOW!

 1 Office Pro 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
&nbs= p;4 Norton Antivirus 2005
 5 Flash MX 2004
 6 Corel Draw 12
 7 Adobe Acrobat 7.0
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
10 Adobe Premiere
 = See more by this manufacturer=
  
&= nbsp;  Apple Software
  Customers also bought
   these oth= er items...



Microsoft Office Professional= Edition *2003*
Microsoft
<= td vAlign=3Dtop noWrap>
Choose:
<= tr>
 
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Featur= es:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems u= sing enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
  • = More than 20 preformatted business reports
    • Sales Rank: #1
    Ship= ping: International/US or via instant download
    Date Coupon Expi= res: June 30th, 2005
    Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
    <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
    Microsoft Windows XP= Professional or Longhorn Edition
    Microsoft
    Choose:
     

    <= a href=3Dhttp://yoursmartware.com/?j>

    $279.00
    Price:$49.99
    You Save= :$229.01 (85%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Acces= sories  |  Other Versi= ons

    Features:=

    • Designed for businesses o= f all sizes
    • Manage digital p= ictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and folders
    • Built-in voice, video, and insta= nt messaging support
    • Integra= tion with Windows servers and management solutions

    Sales Rank: #2
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

    Adobe Photoshop CS2 V 9.0
    Adobe
    Choose:
     

    List Price: $599.00
    Price:$69.99
    You Save:$529.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

    <= p>Features:

      Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
    • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
    • Create or modify ph= otos using painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping:= International/US or via instant download
    Date Coupon Expires:<= /b> June 30th, 2005
    Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

----HAcksmRKJR6FhwFEXArm-- From KateMcwilliams@raceme.net Sun Jun 5 18:23:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09227 for ; Sun, 5 Jun 2005 18:23:47 -0400 (EDT) Received: from [221.127.94.218] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Df3lo-0000Rt-FO for dnsext-archive@ietf.org; Sun, 05 Jun 2005 18:45:15 -0400 Received: from YTzl@localhost by SSbN.int (8.11.6/8.11.6); Mon, 06 Jun 2005 02:26:15 +0300 Message-ID: From: "Diane Nicholas" Reply-To: "Diane Nicholas" To: dnsext-archive@ietf.org Subject: Windows XP Pro $49.95 Adobe, Windows Date: Sun, 05 Jun 2005 19:30:15 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: KateMcwilliams@raceme.net Content-Type: multipart/mixed; boundary="--HAcksmRKJR6FhwFEXArm" X-Spam-Score: 13.3 (+++++++++++++) X-Spam-Flag: YES X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 KnNS ----HAcksmRKJR6FhwFEXArm Content-Type: text/html; Content-Transfer-Encoding: quoted-printable l
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= tbody><= /td>
=
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

<= td width=3D4>  Microsoft=

 = ON SALE NOW!

 1 Office Pro 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
&nbs= p;4 Norton Antivirus 2005
 5 Flash MX 2004
 6 Corel Draw 12
 7 Adobe Acrobat 7.0
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
10 Adobe Premiere
 = See more by this manufacturer=
  
&= nbsp;  Apple Software
  Customers also bought
   these oth= er items...



Microsoft Office Professional= Edition *2003*
Microsoft
<= td vAlign=3Dtop noWrap>
Choose:
<= tr>
 
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Featur= es:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems u= sing enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
  • = More than 20 preformatted business reports
    • Sales Rank: #1
    Ship= ping: International/US or via instant download
    Date Coupon Expi= res: June 30th, 2005
    Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
    <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
    Microsoft Windows XP= Professional or Longhorn Edition
    Microsoft
    Choose:
     

    <= a href=3Dhttp://yoursmartware.com/?j>

    $279.00
    Price:$49.99
    You Save= :$229.01 (85%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Acces= sories  |  Other Versi= ons

    Features:=

    • Designed for businesses o= f all sizes
    • Manage digital p= ictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and folders
    • Built-in voice, video, and insta= nt messaging support
    • Integra= tion with Windows servers and management solutions

    Sales Rank: #2
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

    Adobe Photoshop CS2 V 9.0
    Adobe
    Choose:
     

    List Price: $599.00
    Price:$69.99
    You Save:$529.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

    <= p>Features:

      Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
    • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
    • Create or modify ph= otos using painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping:= International/US or via instant download
    Date Coupon Expires:<= /b> June 30th, 2005
    Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

----HAcksmRKJR6FhwFEXArm-- From owner-namedroppers@ops.ietf.org Mon Jun 6 06:42:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17604 for ; Mon, 6 Jun 2005 06:41:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfEy8-0008hI-N5 for namedroppers-data@psg.com; Mon, 06 Jun 2005 10:36:32 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfEy8-0008gu-1X for namedroppers@ops.ietf.org; Mon, 06 Jun 2005 10:36:32 +0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 06 Jun 2005 12:36:31 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j56AaM7J021149; Mon, 6 Jun 2005 12:36:28 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 6 Jun 2005 12:36:23 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Jun 2005 12:36:23 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: namedroppers@ops.ietf.org, sra@isc.org Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: draft-iab-dns-choices-00 comments Date: Mon, 6 Jun 2005 12:36:17 +0200 To: Pekka Savola X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 06 Jun 2005 10:36:23.0168 (UTC) FILETIME=[95849000:01C56A83] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Dec 14, 2004, at 12:16, Pekka Savola wrote: > The fight over draft-iab-dns-choices-00 appears to have settled > down a bit.. I wonder how it's going forward. In any case, below > are the comments I sent in May but for which I didn't get a > response to. > (Found this when searching for the name of the I-D in my mailboxes globally) Your input is merged in the next version of the document that will be sent to the I-D today. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From UrsulaBouchard@brooding.com Mon Jun 6 14:35:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27236 for ; Mon, 6 Jun 2005 14:35:35 -0400 (EDT) Received: from [221.126.133.110] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfMmP-0008Rh-RZ for dnsext-archive@ietf.org; Mon, 06 Jun 2005 14:57:12 -0400 Received: from PVH@localhost by luQ.int (8.11.6/8.11.6); Mon, 06 Jun 2005 16:55:02 -0300 Message-ID: <6CZQS0zEnuheZB2NceKhw@approperties.co.uk> From: "Anne Finch" Reply-To: "Anne Finch" To: dnsext-archive@ietf.org Subject: All Photoshop software for cheap Date: Mon, 06 Jun 2005 22:54:02 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: UrsulaBouchard@brooding.com Content-Type: multipart/mixed; boundary="--4BFKcbBdRQSp38Ukf" X-Spam-Score: 3.5 (+++) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Ndtm ----4BFKcbBdRQSp38Ukf Content-Type: text/html; Content-Transfer-Encoding: quoted-printable P
Opt-in Email Special Offer &n= bsp;   unsubscribe me
<= tbody><= /td>
=
SEARCH

<= td vAlign=3Dbottom>

TOP 10 NEW TITLES

<= td width=3D4>  Microsoft=

 = ON SALE NOW!

 1 Office Pro 2003
 2 Windows XP Pro
 3 Adobe Creative Suite Premium
&nbs= p;4 Norton Antivirus 2005
 5 Flash MX 2004
 6 Corel Draw 12
 7 Adobe Acrobat 7.0
 8 Windows 2003 Server
 9 Alias Maya 6 Wavefrt
10 Adobe Premiere
 = See more by this manufacturer=
  
&= nbsp;  Apple Software
  Customers also bought
   these oth= er items...



Microsoft Office Professional= Edition *2003*
Microsoft
<= td vAlign=3Dtop noWrap>
Choose:
<= tr>
 
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Featur= es:

  • Analyze and manage business information using Access databases
  • Exchange data with other systems u= sing enhanced XML technology
  • Control information sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail n= ewsletters and printed marketing materials
  • = More than 20 preformatted business reports
    • Sales Rank: #1
    Ship= ping: International/US or via instant download
    Date Coupon Expi= res: June 30th, 2005
    Average Customer= Review: 3D"5 Based on 1,768 reviews. Write a review.
    <= td class=3Dsmall vAlign=3Dtop noWrap align=3Dright height=3D18 width=3D73>= List Price:
    Microsoft Windows XP= Professional or Longhorn Edition
    Microsoft
    Choose:
     

    <= a href=3Dhttp://yoursmartware.com/?T>

    $279.00
    Price:$49.99
    You Save= :$229.01 (85%)



    Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
    Media: CD-ROM / Download

    System = requirements  |  Acces= sories  |  Other Versi= ons

    Features:=

    • Designed for businesses o= f all sizes
    • Manage digital p= ictures, music, video, DVDs, and more
    • More security with the ability to encrypt files and folders
    • Built-in voice, video, and insta= nt messaging support
    • Integra= tion with Windows servers and management solutions

    Sales Rank: #2
    Shipping: In= ternational/US or via instant download
    Date Coupon Expires: Jun= e 30th, 2005
    Average Customer Review:= 3D"5 Based on 868 reviews. Writ= e a review.

    Adobe Photoshop CS2 V 9.0
    Adobe
    Choose:
     

    List Price: $599.00
    Price:$69.99
    You Save:$529.01 (90%)


    Availability: Available for INSTANT download!
    Coupon Code:= ISe229
    Media: CD-ROM / Download

    System requirements&nb= sp; |  Accessories  |&= nbsp; Other Versions

    <= p>Features:

      Customized workspace; save personalized wor= kspace and tool settings; create customized shortcuts
    • Unparalleled efficiency--automate production ta= sks with built-in or customized scripts
    • Improved file management, new design possibilities, and a more= intuitive way to create for the Web
    • Support for 16-bit images, digital camera raw data, and non-squar= e pixels
    • Create or modify ph= otos using painting, drawing, and retouching tools

    Sales Rank: #3
    Shipping:= International/US or via instant download
    Date Coupon Expires:<= /b> June 30th, 2005
    Average Customer Revi= ew: 3D"5 Based on 498 reviews. Write a review.

----4BFKcbBdRQSp38Ukf-- From owner-namedroppers@ops.ietf.org Tue Jun 7 01:36:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26077 for ; Tue, 7 Jun 2005 01:36:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DfWg4-000LkO-WC for namedroppers-data@psg.com; Tue, 07 Jun 2005 05:31:05 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfWg2-000Lk9-Mm for namedroppers@ops.ietf.org; Tue, 07 Jun 2005 05:31:03 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id BB2BA24584; Tue, 7 Jun 2005 07:31:01 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CFAA9244B5 for ; Tue, 7 Jun 2005 07:31:00 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j575V045026154 for ; Tue, 7 Jun 2005 07:31:00 +0200 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id j575V0sd018238 for namedroppers@ops.ietf.org; Tue, 7 Jun 2005 07:31:00 +0200 Received: from [80.245.62.11] (helo=mx.laposte.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DfJBc-0007Jh-SB for namedroppers@ops.ietf.org; Mon, 06 Jun 2005 15:06:45 +0000 Received: from [192.168.10.123] (62.206.52.42) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 4291895A00846412; Mon, 6 Jun 2005 17:06:43 +0200 From: Julien Laganier To: namedroppers@ops.ietf.org Subject: review of draft-ietf-hip-dns-01 (DNS extension for HIP ) User-Agent: KMail/1.7 Cc: pekka.nikander@nomadiclab.com, hipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 6 Jun 2005 16:20:50 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200506061620.53254.julien.IETF@laposte.net> X-RIPE-Spam-Tests: BAYES_00 X-RIPE-Spam-Status: N 0.001708 / -2.6 X-RIPE-Signature: 57a6bc7c0e1d4656010629c0d0405002 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: This post needed manual approval. Either it was posted by a non-subscribed address, or the posting was too large ( > 20000bytes ) for this list. With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please use your subscribed address to post, or shorten your postings by using links instead of attachments. ] Dear dnsext members, I am editor for draft-ietf-hip-dns-01 (DNS extensions for the Host Identity Protocol), which defines two new RRs for storing HIP nodes public keys and rendezvous servers IP addresses in the DNS. Our intent is to publish it as an EXPERIMENTAL RFC to allow further experimentations with HIP. Because the document is now quite mature w.r.t. to the HIP WG, I'd like to solicit some help from the DNS experts to do a cross-area review of the document (which is short and very similar to RFC4025 - IPSECKEY RR). Do you have an idea of the best way to proceed? Thanks. Best Regards, -- Julien Laganier -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From HankLockett@telegraphone.com Tue Jun 7 11:34:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03634 for ; Tue, 7 Jun 2005 11:34:35 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfgRD-0005rD-P9 for dnsext-archive@ietf.org; Tue, 07 Jun 2005 11:56:25 -0400 Received: from chello084010127067.chello.pl ([84.10.127.67]) by mx2.foretec.com with smtp (Exim 4.24) id 1Dfg5W-0000pF-4J for dnsext-archive@ietf.org; Tue, 07 Jun 2005 11:34:33 -0400 Received: from H6A@localhost by Sj4F.int (8.11.6/8.11.6); Tue, 07 Jun 2005 22:49:25 +0600 Message-ID: From: "Chance Everett" Reply-To: "Chance Everett" To: dnsext-archive@ietf.org Subject: dJT a REVOLUTION in Online Gambling ! ID: 20Vu7C Date: Tue, 07 Jun 2005 19:54:25 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: HankLockett@telegraphone.com Content-Type: multipart/mixed; boundary="--4pinwrZYvsK9yzD" X-Spam-Score: 0.6 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 t6S ----4pinwrZYvsK9yzD Content-Type: text/html; Content-Transfer-Encoding: quoted-printable q55lQcVGfxs4

Welcome to MS@Casin0 - a REVOLUTION in = CYBER GAMlNG!
MS@Casin0 establishes a turning point in Casin0 history by
uniquely allowing players worldwide to play as dealer thus
receiving some of the most favorable odds normally reserved for
the Casin0.

MS@Casin0 offers popular games, including Black-jack, Roullette,
Sl0t Machines and Video P0ker all featuring unmatched graphics and sounds.=

You may play with REAL M0NEY or just play for Fun (no bank details needed)=

Questions and Answers
--------------------

Q: MS@Casin0 offers matchless credibility and it's easy to check. How ? A: Robert as Player and Graham as Dealer enter one of the games. Once the = game
is over, they verify that one's losing sum is the other's winning sum.
=
Q: MS@Casin0 offers the highest payouts available. How is that possible? A: Payouts are constant in games like Blackjack and Roulette (and for all<= br> games with the same rules). MS@Casin0's unique concept allows players to become the Dealer, which improves their winning odds, thus B00STING
their payout rates.

The top daily player (determined at 23:59) gets $200 bonus!

Winnings generated from playing as Dealer are also accumulated.

The scoreboard will be updated every hour.

Visit our site http://4highrollers.net -try your luck & NO DEP0= SIT REQUIRED !

Best regards,

Francis Kaufman
Casin0 Manager

----4pinwrZYvsK9yzD-- From HankLockett@telegraphone.com Tue Jun 7 12:20:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03638 for ; Tue, 7 Jun 2005 11:34:36 -0400 (EDT) Received: from cc4-24.207.135.225.charter-stl.com ([24.207.135.225]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfgRE-0005rA-6O for dnsext-archive@ietf.org; Tue, 07 Jun 2005 11:56:25 -0400 Received: from H6A@localhost by Sj4F.int (8.11.6/8.11.6); Tue, 07 Jun 2005 22:49:25 +0600 Message-ID: From: "Chance Everett" Reply-To: "Chance Everett" To: dnsext-archive@ietf.org Subject: dJT a REVOLUTION in Online Gambling ! ID: 20Vu7C Date: Tue, 07 Jun 2005 19:54:25 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: HankLockett@telegraphone.com Content-Type: multipart/mixed; boundary="--4pinwrZYvsK9yzD" X-Spam-Score: 15.2 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 t6S ----4pinwrZYvsK9yzD Content-Type: text/html; Content-Transfer-Encoding: quoted-printable q55lQcVGfxs4

Welcome to MS@Casin0 - a REVOLUTION in = CYBER GAMlNG!
MS@Casin0 establishes a turning point in Casin0 history by
uniquely allowing players worldwide to play as dealer thus
receiving some of the most favorable odds normally reserved for
the Casin0.

MS@Casin0 offers popular games, including Black-jack, Roullette,
Sl0t Machines and Video P0ker all featuring unmatched graphics and sounds.=

You may play with REAL M0NEY or just play for Fun (no bank details needed)=

Questions and Answers
--------------------

Q: MS@Casin0 offers matchless credibility and it's easy to check. How ? A: Robert as Player and Graham as Dealer enter one of the games. Once the = game
is over, they verify that one's losing sum is the other's winning sum.
=
Q: MS@Casin0 offers the highest payouts available. How is that possible? A: Payouts are constant in games like Blackjack and Roulette (and for all<= br> games with the same rules). MS@Casin0's unique concept allows players to become the Dealer, which improves their winning odds, thus B00STING
their payout rates.

The top daily player (determined at 23:59) gets $200 bonus!

Winnings generated from playing as Dealer are also accumulated.

The scoreboard will be updated every hour.

Visit our site http://4highrollers.net -try your luck & NO DEP0= SIT REQUIRED !

Best regards,

Francis Kaufman
Casin0 Manager

----4pinwrZYvsK9yzD-- From owner-namedroppers@ops.ietf.org Wed Jun 8 21:04:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09006 for ; Wed, 8 Jun 2005 21:04:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgBNp-0004yC-BY for namedroppers-data@psg.com; Thu, 09 Jun 2005 00:58:57 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgBNo-0004xg-0u for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 00:58:56 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DgBNc-0001fN-Mj for namedroppers@ops.ietf.org; Wed, 08 Jun 2005 19:58:52 -0500 To: "IETF DNSEXT WG" From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Jun 2005 19:58:44 -0500 Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I believe that dns-choices is fundamentally flawed, it will be ignored by developers that decide to use TXT and does not provide an useful way forward. I believe that that dns-choices flies in the face of decades of successful Unix semantics about data storage in files. I believe what needs to be done is to allocate say, 100 new DNS RRs as clones of TXT records (say, TXT0-TXT99). There are tens of thousands of RR numbers sitting totally unused. What the Unix philosophy about files is that there shouldn't be a "file type" (RR number), most things should be put into flat text files. Files should be distinguished by "magic numbers", located within the file. These "magic numbers" do not need a central authority to allocate them. While text is often not as compact as binary formats and require conversions/parsers, the advantages of being able to use standard tools to edit and debug the files is huge. Binary files are often not significantly smaller, nor are the overhead of parsing is often irrelevant. Of course, the Unix philosophy of flat text files was developed back in the 1970s when storage space and CPU cycles were far more expensive than they are today, so these considerations are even less relevant 30 years later. Reasonably long magic numbers are unlikely to collide, even globally. When localized to particular application area, they are even less likely to collide. If one magic number is in widespread use, and someone comes along and tries to re-use it, they will quickly discover the collision and they, being the newer and less popular use, will almost certainly back down. Intelligent designers will do a survey of the application area first to make sure there isn't a problem with collisions. Two unpopular systems that use the same magic number are unlikely to collide because they are unpopular. History has shown that collisions with Unix magic numbers is rare. An unofficial, first-come first-served registry of (TXTxx, magic number, application area) tuples could make it even more rare. By having, say, 100 TXT record clones to choose from, applications can choose one that keeps the RR set small. If there ever comes a day when it looks like those 100 TXT RR clones are filling up, we can allocate another 100, or even 1000 or 10,000 TXT RR clones. The whole dns-choices I-D makes the assumption that TXT space is limited, and instead of changing that assumption, it goes off claiming that new, special purpose RRs should be used. There are two conflicting problems with allocating new RRs. First off, the vast majority of ideas never take off, and if you allocate a new RR type for every harebrained idea, we would run out of RR numbers quickly and we would have a very long list of RRs that aren't used. Secondly, if you try to do some sort of gate-keeping to make sure only "popular"/"useful" RRs get allocated, then that will be too much work for people who want to just test an idea and they will go off and use TXT RRs. Of course, if that test proves successful, it will be too late to change from a TXT. Of course, right now we have a long list of RR numbers that have been allocated, but hardly ever used, and the process of getting a new RR number allocated is far too burdensome. Let's take an example of Cisco's IIM email anti-forgery system. Instead of using TXT, it is using a binary format called KR. That's what dns-choices says to do, right? So this is good, right? Well, they have used used RR type number 1010 (decimal), which isn't in the range that RFC2929 says to use. Ooops. So now there are people out there deploying 1010 RR numbers and if IIM dies, that RR number will be polluted for many years to come. And how am I supposed to look to see if these KR records exists with dig? Maybe there is a way, but I couldn't find it. And how is this stuff entered or displayed? If you think that hex is as easy to read as text, well, why aren't you reading this as hex now? And since the goal of IIM is to be used everywhere that email is used, every MTA, every box that a mail admin uses, every DNS hosting service that lets people create RRs will need to be updated with special code to deal with KR records in a nice way. Of course,Cisco's IIM system is defined by an I-D published on the IETF website so it is easy to find. How many other systems are there that have gone and defined some other "easily typed" RR number that we don't know about? Dns-choices is doing nothing but tilting at windmills. People will continue to use TXT RRs because they are the best solution. The only problem with TXT is that their space is limited, but that can be fixed as easily as it would take to create one single other new RR type. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 8 22:20:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26840 for ; Wed, 8 Jun 2005 22:20:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgCcN-000BHR-Sp for namedroppers-data@psg.com; Thu, 09 Jun 2005 02:18:03 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DgCcL-000BHB-SN for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 02:18:02 +0000 Received: (qmail 3642 invoked by uid 100); 9 Jun 2005 02:17:55 -0000 Date: 9 Jun 2005 02:17:55 -0000 Message-ID: <20050609021755.3641.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >I believe that dns-choices is fundamentally flawed, it will be ignored >by developers that decide to use TXT and does not provide an useful >way forward. I agree that the draft is fairly badly flawed, but I completely disagree about what the problems are. The first 2/3 is basically fine, the discussions about all of the ways that one might add new data to the DNS and why most of them are bad are fine. But then section 5 waves its hands, and makes lame arguments against the difficulty of adding new RR types. The reality is that adding new RR types is hard, and the honest thing to say is yes, it's hard, there are barriers to doing so, but they're worth the pain. The claim that most DNS servers and clients handle unknown RR types is, unfortunately, just false. One of the things we learned during the MARID fiasco is that for some reason our pals in Redmond defined a DNS API with a separate call for each RR type, and no escape for RR types not in the API. They then have built this API into a whole lot of computers in use all over the world, and none of those computers can handle new RR types at all, neither serve them nor look them up. Yes, they should fix it, but getting them to do so and to get it shipped to all the customers won't happen overnight. It also understates the difficulty in assigning type numbers to RRs. I am surely not the first person to note that the number of RR types is the same as the number of TCP ports, and to wonder why assigning RR numbers has been so much more of a problem than assigning TCP ports. It also needs to address the issue of how front end and back end tools will deal with hitherto unknown RR types beyond dumping them out in hex. It occurs to me that proposed RR types invariably consist of sequences of a small set of basic data types, integers of various lengths, IP addresses, strings, and names. I would think it would be easy to define a template language to describe new RRs, perhaps in XML, so to upgrade our tools to handle new types we only need to install an updated template, not a new version of the program. (XML bloat doesn't matter, this XML only goes into the DNS management applications, not into the DNS itself.) A more honest assessment of the current problems of new RR types and some direction about solving those problems would make this document a whole lot more persuasive. R's, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 8 22:21:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26896 for ; Wed, 8 Jun 2005 22:21:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgCcJ-000BH6-QN for namedroppers-data@psg.com; Thu, 09 Jun 2005 02:17:59 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DgCcI-000BGt-JH for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 02:17:59 +0000 Received: (qmail 3642 invoked by uid 100); 9 Jun 2005 02:17:55 -0000 Date: 9 Jun 2005 02:17:55 -0000 Message-ID: <20050609021755.3641.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >I believe that dns-choices is fundamentally flawed, it will be ignored >by developers that decide to use TXT and does not provide an useful >way forward. I agree that the draft is fairly badly flawed, but I completely disagree about what the problems are. The first 2/3 is basically fine, the discussions about all of the ways that one might add new data to the DNS and why most of them are bad are fine. But then section 5 waves its hands, and makes lame arguments against the difficulty of adding new RR types. The reality is that adding new RR types is hard, and the honest thing to say is yes, it's hard, there are barriers to doing so, but they're worth the pain. The claim that most DNS servers and clients handle unknown RR types is, unfortunately, just false. One of the things we learned during the MARID fiasco is that for some reason our pals in Redmond defined a DNS API with a separate call for each RR type, and no escape for RR types not in the API. They then have built this API into a whole lot of computers in use all over the world, and none of those computers can handle new RR types at all, neither serve them nor look them up. Yes, they should fix it, but getting them to do so and to get it shipped to all the customers won't happen overnight. It also understates the difficulty in assigning type numbers to RRs. I am surely not the first person to note that the number of RR types is the same as the number of TCP ports, and to wonder why assigning RR numbers has been so much more of a problem than assigning TCP ports. It also needs to address the issue of how front end and back end tools will deal with hitherto unknown RR types beyond dumping them out in hex. It occurs to me that proposed RR types invariably consist of sequences of a small set of basic data types, integers of various lengths, IP addresses, strings, and names. I would think it would be easy to define a template language to describe new RRs, perhaps in XML, so to upgrade our tools to handle new types we only need to install an updated template, not a new version of the program. (XML bloat doesn't matter, this XML only goes into the DNS management applications, not into the DNS itself.) A more honest assessment of the current problems of new RR types and some direction about solving those problems would make this document a whole lot more persuasive. R's, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 8 22:42:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11587 for ; Wed, 8 Jun 2005 22:42:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgCxu-000D9s-J6 for namedroppers-data@psg.com; Thu, 09 Jun 2005 02:40:18 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgCxs-000D9a-S8 for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 02:40:16 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DgCxk-0003aK-31 for namedroppers@ops.ietf.org; Wed, 08 Jun 2005 21:40:15 -0500 To: "IETF DNSEXT WG" References: <20050609021755.3641.qmail@xuxa.iecc.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Jun 2005 21:40:07 -0500 In-Reply-To: <20050609021755.3641.qmail@xuxa.iecc.com> (John Levine's message of "9 Jun 2005 02:17:55 -0000") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <20050609021755.3641.qmail@xuxa.iecc.com> John Levine writes: > The first 2/3 is basically fine, the discussions about all of the ways > that one might add new data to the DNS and why most of them are bad > are fine. But then section 5 waves its hands, and makes lame > arguments against the difficulty of adding new RR types. The reality > is that adding new RR types is hard, and the honest thing to say is > yes, it's hard, there are barriers to doing so, but they're worth the > pain. Agreed. > The claim that most DNS servers and clients handle unknown RR types > is, unfortunately, just false. One of the things we learned during > the MARID fiasco is that for some reason our pals in Redmond defined a > DNS API with a separate call for each RR type, and no escape for RR > types not in the API. They then have built this API into a whole lot > of computers in use all over the world, and none of those computers > can handle new RR types at all, neither serve them nor look them up. > Yes, they should fix it, but getting them to do so and to get it > shipped to all the customers won't happen overnight. Oh, but it is worse! They have a firewall product that apparently many people use that blocks all port 53 queries, so that you are *locked* into using this braindead API and can't escape even if you roll your own resolver code. Mind you, the folks at the MARID interim meeting were not defending these choices in any way, and the looked more than a little embarrassed about the situation. However, they weren't in any position to change things, and it didn't sound like there were any plans to change things. > It also understates the difficulty in assigning type numbers to RRs. > I am surely not the first person to note that the number of RR types > is the same as the number of TCP ports, and to wonder why assigning RR > numbers has been so much more of a problem than assigning TCP ports. Well, there are certainly similar problems with collisions in usage, but DNS has the extra problem that name servers and resolvers have done special process on certain records and have to know how to deal with new record types. There isn't an equivalent problem with TCP ports. > A more honest assessment of the current problems of new RR types and > some direction about solving those problems would make this document > a whole lot more persuasive. Yep. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 8 23:31:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24104 for ; Wed, 8 Jun 2005 23:31:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgDiA-000HU1-Rd for namedroppers-data@psg.com; Thu, 09 Jun 2005 03:28:06 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgDi9-000HTi-5n for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 03:28:05 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DgDi2-0004Qa-7L for namedroppers@ops.ietf.org; Wed, 08 Jun 2005 22:28:04 -0500 To: "IETF DNSEXT WG" References: <20050609021755.3641.qmail@xuxa.iecc.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 08 Jun 2005 22:27:57 -0500 In-Reply-To: (wayne@schlitt.net's message of "Wed, 08 Jun 2005 21:40:07 -0500") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In wayne writes: > In <20050609021755.3641.qmail@xuxa.iecc.com> John Levine writes: > >> The first 2/3 is basically fine, the discussions about all of the ways >> that one might add new data to the DNS and why most of them are bad >> are fine. But then section 5 waves its hands, and makes lame >> arguments against the difficulty of adding new RR types. The reality >> is that adding new RR types is hard, and the honest thing to say is >> yes, it's hard, there are barriers to doing so, but they're worth the >> pain. > > Agreed. Oops. I misread the last sentence. I agree with everything that John said, except that I *don't* think it is worth the pain. At least not in a many cases and a very large percentage of the cases that this dns-choices document tries to address. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 8 23:40:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24638 for ; Wed, 8 Jun 2005 23:40:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgDsL-000IOO-6f for namedroppers-data@psg.com; Thu, 09 Jun 2005 03:38:37 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DgDsI-000IO3-Do for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 03:38:34 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j593cQgU020477 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 8 Jun 2005 23:38:26 -0400 Date: Wed, 8 Jun 2005 23:38:26 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: John Levine cc: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: <20050609021755.3641.qmail@xuxa.iecc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 9 Jun 2005, John Levine wrote: > The first 2/3 is basically fine, the discussions about all of the ways > that one might add new data to the DNS and why most of them are bad > are fine. But then section 5 waves its hands, and makes lame > arguments against the difficulty of adding new RR types. The reality > is that adding new RR types is hard, and the honest thing to say is > yes, it's hard, there are barriers to doing so, but they're worth the > pain. I don't think adding new RR types is too hard. Most implementations can handle unknown RR types properly. I think at this point, the ones that don't are in the realm of "implementation problems" that aren't of concern to a standards group. But, I would agree that adding new RRs is not a completely trivial exercise, and should not be undertaken frivolously. Frivolous RR types waste limited RR type space. > The claim that most DNS servers and clients handle unknown RR types > is, unfortunately, just false. One of the things we learned during > the MARID fiasco is that for some reason our pals in Redmond defined a I don't recall this being a problem with MARID, nor have I found anything to date that this was ever raised as a MARID problem. I'm presently writing a paper on MARID problems, so if you have more specifics on this problem WRT MARID, I would greatly appreciate it if you would forward that to me. Thanks, --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 00:14:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26836 for ; Thu, 9 Jun 2005 00:14:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgEO9-000LSx-3X for namedroppers-data@psg.com; Thu, 09 Jun 2005 04:11:29 +0000 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgEO7-000LSi-0u for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 04:11:27 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j594BQau029814 for ; Wed, 8 Jun 2005 21:11:26 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j594BQET029811 for ; Wed, 8 Jun 2005 21:11:26 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 8 Jun 2005 21:11:26 -0700 (PDT) From: "william(at)elan.net" To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 8 Jun 2005, Dean Anderson wrote: > I don't think adding new RR types is too hard. Most implementations can > handle unknown RR types properly. I think at this point, the ones that > don't are in the realm of "implementation problems" that aren't of concern > to a standards group. But, I would agree that adding new RRs is not a > completely trivial exercise, and should not be undertaken frivolously. > Frivolous RR types waste limited RR type space. Tell me what percentage of RR type space is currently in use? Would it be 1%? Perhaps less? We have plenty of arguably "frivolous" tcp port assignments, yet we are nowhere close to exhausting the number of available tcp ports. DNS people on this list really do guard assignments of new RR types too closely. What should be done instead is separate registration into standard and provisional and allow easy registration of provisional RR type (with id assignment just for them, listing in IANA, etc) when just the internet draft is present. Then DNS group would then watch their progress and if in say 2 years they are able to get to standard level, provisional becomes standard (keeping number) but if they fail, the provisional registration is removed and in another 2 years the id is available for reuse by somebody else. Obviously after 2 years pass/fail is not the only option they could apply for continuance of the provisional registration for another 2 years, etc. -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 01:26:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01835 for ; Thu, 9 Jun 2005 01:25:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgFVH-0001BY-OP for namedroppers-data@psg.com; Thu, 09 Jun 2005 05:22:55 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DgFVE-0001B9-TX for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 05:22:53 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j595MdLA022396 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Jun 2005 01:22:40 -0400 Date: Thu, 9 Jun 2005 01:22:39 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: "william(at)elan.net" cc: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 8 Jun 2005, william(at)elan.net wrote: > > On Wed, 8 Jun 2005, Dean Anderson wrote: > > > I don't think adding new RR types is too hard. Most implementations can > > handle unknown RR types properly. I think at this point, the ones that > > don't are in the realm of "implementation problems" that aren't of concern > > to a standards group. But, I would agree that adding new RRs is not a > > completely trivial exercise, and should not be undertaken frivolously. > > Frivolous RR types waste limited RR type space. > > Tell me what percentage of RR type space is currently in use? > Would it be 1%? Perhaps less? Less at present. But if we created new RR's for every anti-spam email authentication proposal I've seen, we would quickly run out of 16 bits of space. And we expect that space to last for a long, long time. > We have plenty of arguably "frivolous" tcp port assignments, yet we are > nowhere close to exhausting the number of available tcp ports. DNS people > on this list really do guard assignments of new RR types too closely. Getting harder to have rational allocaton of anonymous TCP ports. Can't just assume all services are less than 1024, now can you. > What should be done instead is separate registration into standard and > provisional and allow easy registration of provisional RR type (with id > assignment just for them, listing in IANA, etc) when just the internet > draft is present. Reusing RR types is a bit harder than reusing IP address space. > Then DNS group would then watch their progress and if in say 2 years > they are able to get to standard level, provisional becomes standard > (keeping number) but if they fail, the provisional registration is > removed and in another 2 years the id is available for reuse by > somebody else. Obviously after 2 years pass/fail is not the only option > they could apply for continuance of the provisional registration for > another 2 years, etc. Only problem is that this creates chaos for implementations to follow. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 07:43:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16660 for ; Thu, 9 Jun 2005 07:43:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgLNK-0003jj-CC for namedroppers-data@psg.com; Thu, 09 Jun 2005 11:39:06 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgLNJ-0003jT-8q for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 11:39:05 +0000 Received: from deneb.enyo.de ([2001:14b0:202:1::ab]) by albireo.enyo.de with esmtp id 1DgLNE-00010j-Tj; Thu, 09 Jun 2005 13:39:01 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1DgLN7-0007YX-5I; Thu, 09 Jun 2005 13:38:53 +0200 From: Florian Weimer To: John Levine Cc: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments References: <20050609021755.3641.qmail@xuxa.iecc.com> Date: Thu, 09 Jun 2005 13:38:53 +0200 In-Reply-To: <20050609021755.3641.qmail@xuxa.iecc.com> (John Levine's message of "9 Jun 2005 02:17:55 -0000") Message-ID: <87zmtzu5de.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * John Levine: > The claim that most DNS servers and clients handle unknown RR types > is, unfortunately, just false. One of the things we learned during > the MARID fiasco is that for some reason our pals in Redmond defined a > DNS API with a separate call for each RR type, and no escape for RR > types not in the API. They then have built this API into a whole lot > of computers in use all over the world, and none of those computers > can handle new RR types at all, neither serve them nor look them up. > Yes, they should fix it, but getting them to do so and to get it > shipped to all the customers won't happen overnight. But you can't be considerate eternally and halt all protocol improvements because you think that a single vendor won't feel any market pressure. Section 3.5 in the draft misses the registration problem. IANA is probably unwilling to assign RR types to experimental protocols (in the general sense of the word, not the IETF sense). This is the main reason why approaches solely based on RR types aren't generic enough as an extension mechanism. I see two solutions to the mess: Either fix wildcards to handle prefixes gracefully, or dynamically assign RR types on a per-domain basis (reserve a range of RR types, and use a two-stage query scheme, to obtain the RR number first and the actual data in a second query). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 08:56:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25183 for ; Thu, 9 Jun 2005 08:56:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgMXQ-000A8C-3L for namedroppers-data@psg.com; Thu, 09 Jun 2005 12:53:36 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgMXO-000A7b-6j for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 12:53:34 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id A43BEC2E01; Thu, 9 Jun 2005 13:53:28 +0100 (BST) Date: Thu, 09 Jun 2005 13:53:24 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Florian Weimer , John Levine Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> In-Reply-To: <87zmtzu5de.fsf@deneb.enyo.de> References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 09 June 2005 13:38 +0200 Florian Weimer wrote: > I see two solutions to the mess: Either fix wildcards to handle > prefixes gracefully, or dynamically assign RR types on a per-domain > basis (reserve a range of RR types, and use a two-stage query scheme, > to obtain the RR number first and the actual data in a second query). Dumb question time, based on two questionable assumptions. IF one is the opinion TXT records should not be used for this AND one is of the opinion "fixing" (breaking? :-) ) wildcards to do this is not desirable THEN you are left with a new RR type as the only solution anyway. So, if those assumptions hold true, why would you want to invent two-stage queries, when you can just do $ORIGIN example.com foo IN TXT2 "SPFv71" "Here's my SPF String" foo IN TXT2 "killspam3" "Here's my other string" IE encapsulate the type in the record itself, but not as part of the freeform text field. Sure you can't query by it (today) by type, but you can get all the information back anyway, and if we wanted at some stage to query by 4-tuple rather than 3-tuple, it would be obvious how to do it. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 09:05:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26042 for ; Thu, 9 Jun 2005 09:05:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgMgz-000BJL-BB for namedroppers-data@psg.com; Thu, 09 Jun 2005 13:03:29 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgMgv-000BIW-Lm for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 13:03:25 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DgMgd-00061O-3H for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 08:03:22 -0500 To: "IETF DNSEXT WG" From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 09 Jun 2005 08:03:03 -0500 Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: draft-iab-dns-choices-02.txt comments: host names vs domain names X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In section 3.2, "Add a prefix to the owner name", it uses examples such as _mail.example.com. I suspect that there is a large amount of confusion between what a "host name" is and a "domain name" right here on this list. The underscore in _mail prefix is used to ensure that the domain name is not a valid host name. Most DNS hosting services allow you to only create subdomains made up of letter-digit-hyphens. I think there will be a large educational problem explaining to the general public why you can create _mail.example.com, but not www_2.example.com or my_example.com. So, in order to help this educational process, can someone give a short paragraph that explains the differences between host names and domain names, why the allowed characterset is different between the two and when you should use one or the other? -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 09:09:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26689 for ; Thu, 9 Jun 2005 09:09:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgMja-000BgO-L0 for namedroppers-data@psg.com; Thu, 09 Jun 2005 13:06:10 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgMjZ-000Bg7-QS for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 13:06:10 +0000 Received: from deneb.enyo.de ([2001:14b0:202:1::ab]) by albireo.enyo.de with esmtp id 1DgMjW-0003Dj-Bw; Thu, 09 Jun 2005 15:06:06 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1DgMjM-0007vW-3L; Thu, 09 Jun 2005 15:05:56 +0200 From: Florian Weimer To: Alex Bligh Cc: John Levine , namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> Date: Thu, 09 Jun 2005 15:05:56 +0200 In-Reply-To: <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> (Alex Bligh's message of "Thu, 09 Jun 2005 13:53:24 +0100") Message-ID: <87wtp3smrv.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Alex Bligh: > IF one is the opinion TXT records should not be used for this > AND one is of the opinion "fixing" (breaking? :-) ) wildcards to do this > is not desirable > THEN you are left with a new RR type as the only solution anyway. Seems reasonable, but as I wrote, I don't think the new RR type route is a real solution, unless assignment is handled more liberally (which is difficult because there are just 2**16 types). > So, if those assumptions hold true, why would you want to invent two-stage > queries, when you can just do > > $ORIGIN example.com > foo IN TXT2 "SPFv71" "Here's my SPF String" > foo IN TXT2 "killspam3" "Here's my other string" > > > IE encapsulate the type in the record itself, but not as part of > the freeform text field. > > Sure you can't query by it (today) by type, but you can get all the > information back anyway, and if we wanted at some stage to query > by 4-tuple rather than 3-tuple, it would be obvious how to do it. I'm not sure how such a transition would interact with DNSSEC. Just for clarity, I would propose something like this: foo IN RTYPE ("SPFv71", 1025) ("killspam3", 1026) foo IN TYPE1025 "Here's my SPF String" foo IN TYPE1026 "Here's my other string" (Everything is crammed into one RTYPE to cut down the protocol overhead. Another level of indirection (ahem) could be used to increase caching.) A client would request the RTYPE record, search for the corresponding RR type, and request that RR type. As a result, it wouldn't be bogged down by large RRsets of a kind it's not interested in. There's a slight synchronization problem (you've to be careful when reusing dynamic type numbers), but it doesn't look too bad. IANA could liberally assign the indification strings because they aren't a scarce resource. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 09:29:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29224 for ; Thu, 9 Jun 2005 09:29:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgN3j-000DZQ-Uv for namedroppers-data@psg.com; Thu, 09 Jun 2005 13:26:59 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgN3i-000DYk-7t for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 13:26:58 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DgN3Z-0006Td-2F for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 08:26:57 -0500 To: "IETF DNSEXT WG" References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> <87wtp3smrv.fsf@deneb.enyo.de> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 09 Jun 2005 08:26:48 -0500 In-Reply-To: <87wtp3smrv.fsf@deneb.enyo.de> (Florian Weimer's message of "Thu, 09 Jun 2005 15:05:56 +0200") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <87wtp3smrv.fsf@deneb.enyo.de> Florian Weimer writes: >> Sure you can't query by it (today) by type, but you can get all the >> information back anyway, and if we wanted at some stage to query >> by 4-tuple rather than 3-tuple, it would be obvious how to do it. > > I'm not sure how such a transition would interact with DNSSEC. Yeah, I'm not sure how this would work either and I'm interested in learning the answer. At one time, I pondered the idea of using an EDNS0-type extension system to allow for a *small* magic number selector to be sent with the query in order to limit the number of TXT records that are returned. I think this would also cause problems with conflicting TTLs. > Just for clarity, I would propose something like this: > > foo IN RTYPE ("SPFv71", 1025) ("killspam3", 1026) > foo IN TYPE1025 "Here's my SPF String" > foo IN TYPE1026 "Here's my other string" > > (Everything is crammed into one RTYPE to cut down the protocol > overhead. Another level of indirection (ahem) could be used to > increase caching.) What happens if the list of mapped dynamic RR types exceeds the size of a 512 byte UDP packet? -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 09:45:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00972 for ; Thu, 9 Jun 2005 09:45:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgNIw-000Eyj-KD for namedroppers-data@psg.com; Thu, 09 Jun 2005 13:42:42 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgNIu-000EyQ-TB for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 13:42:41 +0000 Received: from deneb.enyo.de ([2001:14b0:202:1::ab]) by albireo.enyo.de with esmtp id 1DgNIs-0004TI-Gz for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 15:42:38 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1DgNIl-00088X-9V for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 15:42:31 +0200 From: Florian Weimer To: "IETF DNSEXT WG" Subject: Re: draft-iab-dns-choices-02.txt comments References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> <87wtp3smrv.fsf@deneb.enyo.de> Date: Thu, 09 Jun 2005 15:42:31 +0200 In-Reply-To: (wayne@schlitt.net's message of "Thu, 09 Jun 2005 08:26:48 -0500") Message-ID: <87zmtzpry0.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> Just for clarity, I would propose something like this: >> >> foo IN RTYPE ("SPFv71", 1025) ("killspam3", 1026) >> foo IN TYPE1025 "Here's my SPF String" >> foo IN TYPE1026 "Here's my other string" >> >> (Everything is crammed into one RTYPE to cut down the protocol >> overhead. Another level of indirection (ahem) could be used to >> increase caching.) > > What happens if the list of mapped dynamic RR types exceeds the size > of a 512 byte UDP packet? Fallback to TCP, as usual. This doesn't seem to be too likely in practice. You can include more than ten identifiers before it happens. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 09:57:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02102 for ; Thu, 9 Jun 2005 09:57:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgNV4-000GGJ-WA for namedroppers-data@psg.com; Thu, 09 Jun 2005 13:55:15 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgNV3-000GF1-Dh for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 13:55:13 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DFE8413A7A; Thu, 9 Jun 2005 13:55:12 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Florian Weimer cc: Alex Bligh , John Levine , namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Thu, 09 Jun 2005 15:05:56 +0200." <87wtp3smrv.fsf@deneb.enyo.de> References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> <87wtp3smrv.fsf@deneb.enyo.de> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 09 Jun 2005 13:55:12 +0000 Message-Id: <20050609135512.DFE8413A7A@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Just for clarity, I would propose something like this: > > foo IN RTYPE ("SPFv71", 1025) ("killspam3", 1026) > foo IN TYPE1025 "Here's my SPF String" > foo IN TYPE1026 "Here's my other string" yow! lack of subclassing bites us again. we need a new kind of wildcard, for nonterminal matching. but the above is a reasonable pave-over for this pothole, until the protocol catches up someday. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 10:01:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02520 for ; Thu, 9 Jun 2005 10:01:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgNZE-000Gn4-7v for namedroppers-data@psg.com; Thu, 09 Jun 2005 13:59:32 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgNZC-000Gmn-6n for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 13:59:30 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 10045C2DA5; Thu, 9 Jun 2005 14:59:29 +0100 (BST) Date: Thu, 09 Jun 2005 14:59:25 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Florian Weimer Cc: John Levine , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: In-Reply-To: <87wtp3smrv.fsf@deneb.enyo.de> References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> <87wtp3smrv.fsf@deneb.enyo.de> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Florian, --On 09 June 2005 15:05 +0200 Florian Weimer wrote: > * Alex Bligh: > >> IF one is the opinion TXT records should not be used for this >> AND one is of the opinion "fixing" (breaking? :-) ) wildcards to do this >> is not desirable >> THEN you are left with a new RR type as the only solution anyway. > > Seems reasonable, but as I wrote, I don't think the new RR type route > is a real solution, unless assignment is handled more liberally (which > is difficult because there are just 2**16 types). Indeed. So for clarification, my straw man proposal is, rather than to invent 2 stage queries, or assign lots of new RR-Types, to assign a single new RR-Type, the first field of which is (if you like) a sub-type. >> So, if those assumptions hold true, why would you want to invent >> two-stage queries, when you can just do >> >> $ORIGIN example.com >> foo IN TXT2 "SPFv71" "Here's my SPF String" >> foo IN TXT2 "killspam3" "Here's my other string" >> >> >> IE encapsulate the type in the record itself, but not as part of >> the freeform text field. >> >> Sure you can't query by it (today) by type, but you can get all the >> information back anyway, and if we wanted at some stage to query >> by 4-tuple rather than 3-tuple, it would be obvious how to do it. > > I'm not sure how such a transition would interact with DNSSEC. The 4-tuple query? Oh neither am I. No idea how it would interact with anything. But it works on a 3-tuple query model too, which has no adverse interactions. > Just for clarity, I would propose something like this: > > foo IN RTYPE ("SPFv71", 1025) ("killspam3", 1026) > foo IN TYPE1025 "Here's my SPF String" > foo IN TYPE1026 "Here's my other string" > > (Everything is crammed into one RTYPE to cut down the protocol > overhead. Another level of indirection (ahem) could be used to > increase caching.) > > A client would request the RTYPE record, search for the corresponding > RR type, and request that RR type. As a result, it wouldn't be bogged > down by large RRsets of a kind it's not interested in. There's a > slight synchronization problem (you've to be careful when reusing > dynamic type numbers), but it doesn't look too bad. > > IANA could liberally assign the indification strings because they > aren't a scarce resource. Understand. Why (other than minimizing size of responses where multiple things are present) do you need to have different RRTYPEs for "SPF" and "other string" if this wasn't necessary with a TXT-type solution (i.e. have 2 records of the same RRTYPE instead). Again, possibly a dumb question. & in reply to Wayne: > What happens if the list of mapped dynamic RR types exceeds the size > of a 512 byte UDP packet? Wasn't this thrashed out in the more general case in EDNSO et al? If you are saying "what about broken resolvers, broken firewalls, broken servers etc. that don't support larger responses (e.g. by falling back to TCP" then that type of broken stuff is equally likely to be broken for any new RR type anyway, and encoding in TXT records (all of which will be returned for one 3-tuple query) is not going to be any more compact. IE it's no more broken either in Florian's proposal or my straw man than any other way around it. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 10:10:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04066 for ; Thu, 9 Jun 2005 10:10:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgNhq-000HwZ-Dm for namedroppers-data@psg.com; Thu, 09 Jun 2005 14:08:26 +0000 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgNhp-000Hvu-GL for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 14:08:25 +0000 Received: from deneb.enyo.de ([2001:14b0:202:1::ab]) by albireo.enyo.de with esmtp id 1DgNhm-00055w-Bw; Thu, 09 Jun 2005 16:08:22 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1DgNhd-0008Gu-AM; Thu, 09 Jun 2005 16:08:13 +0200 From: Florian Weimer To: Alex Bligh Cc: John Levine , namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> <87wtp3smrv.fsf@deneb.enyo.de> Date: Thu, 09 Jun 2005 16:08:13 +0200 In-Reply-To: (Alex Bligh's message of "Thu, 09 Jun 2005 14:59:25 +0100") Message-ID: <87is0npqr6.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Alex Bligh: > Understand. Why (other than minimizing size of responses where > multiple things are present) do you need to have different RRTYPEs > for "SPF" and "other string" if this wasn't necessary with a > TXT-type solution (i.e. have 2 records of the same RRTYPE instead). My two-stage proposal is entirely driven by a desire to minimize response size. In particular, it's possible to treat each record type separately if your goal is the 512 byte packet size limit. If TCP fallback isn't a practical problem, the simplicity of your proposal clearly wins. Unfortunately, I lack the kind of operational experience necessary to make an informed judgment on the TCP fallback question. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 10:17:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05145 for ; Thu, 9 Jun 2005 10:17:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgNor-000IiQ-JG for namedroppers-data@psg.com; Thu, 09 Jun 2005 14:15:41 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgNon-000IhX-S9 for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 14:15:38 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 89444C2DA5; Thu, 9 Jun 2005 15:15:33 +0100 (BST) Date: Thu, 09 Jun 2005 15:15:30 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Florian Weimer Cc: John Levine , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: In-Reply-To: <87is0npqr6.fsf@deneb.enyo.de> References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> <87wtp3smrv.fsf@deneb.enyo.de> <87is0npqr6.fsf@deneb.enyo.de> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 09 June 2005 16:08 +0200 Florian Weimer wrote: > My two-stage proposal is entirely driven by a desire to minimize > response size. In particular, it's possible to treat each record type > separately if your goal is the 512 byte packet size limit. > > If TCP fallback isn't a practical problem, the simplicity of your > proposal clearly wins. Unfortunately, I lack the kind of operational > experience necessary to make an informed judgment on the TCP fallback > question. So we would some real world data to tell us whether the set of resolvers and middleboxen that break large answers is largely a subset of the set of resolvers and middleboxen that choke on new RR-Types (because if they choke on new RR-Types such as either yours or mine then whether they choke on large queries is irrelevant). My guess (uninformed by any actual data) is that the latter set (don't support new RR-Types) is much larger, especially given the "helpful" nature of many firewalls. Research opportunity for someone. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 10:50:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08322 for ; Thu, 9 Jun 2005 10:50:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgOJs-000LaI-Tv for namedroppers-data@psg.com; Thu, 09 Jun 2005 14:47:44 +0000 Received: from [208.31.42.38] (helo=tom.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DgOJq-000La1-Ss for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 14:47:43 +0000 Received: (qmail 14890 invoked from network); 9 Jun 2005 14:47:38 -0000 Received: (ofmipd 208.31.42.47); 9 Jun 2005 14:47:16 -0000 Date: 9 Jun 2005 10:47:38 -0400 Message-ID: <20050609104607.R7592@simone.iecc.com> From: "John L" To: "Alex Bligh" Cc: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> <5A4F44F1B795B1AB905A9AED@[192.168.100.25]> <87wtp3smrv.fsf@deneb.enyo.de> <87is0npqr6.fsf@deneb.enyo.de> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > My guess (uninformed by any actual data) is that the latter set (don't > support new RR-Types) is much larger, especially given the "helpful" > nature of many firewalls. My understanding is that most Microsoft DNS software handles EDNS0, so big responses are less of a problem than new RR types. The question about firewalls is a good one, both industrial sized ones and the little ones that every DSL customer has in their $30 router. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 10:54:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08812 for ; Thu, 9 Jun 2005 10:54:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgOOS-000MAI-Sm for namedroppers-data@psg.com; Thu, 09 Jun 2005 14:52:28 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgOOQ-000M9Z-1j for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 14:52:26 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j59EqHgQ070789; Thu, 9 Jun 2005 10:52:18 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 9 Jun 2005 10:51:49 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: IAB DNS choices 02 Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Referring to http://www.ietf.org/internet-drafts/draft-iab-dns-choices-02.txt This is going to be a lengthy email, because I want to discuss this issue from an different perspective than I've seen from others on the mailing list. I saw the comments from wayne on this document. I have a different perspective, I think, in that I want to protect the future of the DNS. (I don't mean to say he's out to hurt the DNS, his objective is to meet the needs of application developers - also a worthy goal.) My stipulation is that the DNS is a developed, healthy protocol and system, positioned at the core of Internet operations. Although it is heavily used, it is not threatened (as much as some what to exclaim). Being at the core means that any change to it causes many ripples in the Internet, that a conservative approach to changes is wise. From this viewpoint, my conclusion about the paper is that it is making the correct recommendation, to rely on the use of new RR types to "extend" the DNS. This is in contrast with wayne's conclusion (somewhat) but like he, I agree the paper is somewhat "pollyanna-ish" in it's justifications. The paper reminds me of RFC 2826, "IAB Technical Comment on the Unique DNS Root", published in 2000. A unique DNS root is beneficial for the Internet. But because of this RFC, conducting large-scale DNS experiments, such as is needed for DNSSEC, has been hindered. The reality is that once a system becomes as crucial to operations as DNS has, you can no longer tinker with it without endangering it's stability. The moral here is that you need a test environment for experimentation, separate from the operational environment. Because of the cited RFC, there has been resistance and reluctance to set up and join in the needed large scale (time, distance, and volume) testing needed to safely introduce DNSSEC into the operational DNS. I bring this up because that situation and the situation wayne has been describing reflects what I think has been a large shift in the dynamics of innovation in the Internet over time, and in the past decade (plus). It used to be that people could afford the time to gab informally about what they wanted to accomplish, implement the ideas in quick manner and then document the experiences. At the time, the Internet could afford outages (it was not critical infrastructure in any way) although it was fairly sound. The stability arose from the higher per capita expertise in operations and a smaller workload. Today that is not the case. The IETF recognizes this as well as industry. The IETF has responded by formalizing the gab sessions into requirements documents and (say) formal processes for reserving IANA numbers. Industry has responded in different ways, by either implementing minimally what they need regardless of the full specification, innovating without consulting the IETF first, or rolling out contract and/or regulatory agreements presupposing the environment. Coming back to the document at hand, I think what needs to be examined is "how does someone, beginning from scratch, develop a new application that needs to put data in the DNS get this application to specified in a standard?" I'm not interested in "what it means to be a standard" but more about "how does the process get a proper DNS record type?" Skipping ahead to the day where the developer realizes "hey, I need to put this factiod in the DNS." Once the RR's RDATA contents are determined, there needs to be a place to put it (name), assume class IN, and a type code. For simplicity, let's say the name relates to either a host or zone, so it's fairly obvious where the factoid RR will be sitting in the DNS tree. What is done about the RR type? The relevant RFC, assuming that there is an obvious lead to this, is RFC 2929. In this, it says that the type code numbers from 65280 to 65535 are available for private use. Since the state of the work is early, that is the proper number to use. Getting a reserved RR type number requires "IETF consensus." That has is rumored to take a long time. ;) So, what is likely to happen is that implementation and testing will happen using what's at hand - the "private use" number. Eventually, IANA allocates a type code number. What happens next? Well, all of the new implementations should go out there with the new type code and that is where every one should move the records. This would work if there was ever a clean transition from testing to production. This clean break rarely happens in the Internet world. (Consider the discussion over the termination of ip6.int - we fear clean breaks because it might mean a disruption of service.) Instead of having a clean break, the thought has been to have the new software look in both the old and new place. Doing "new, if fails, old" lookups is not workable for applications because this would make the new stuff slower than the old - a disincentive to upgrade. Doing simultaneous lookups increases the burden and does not yield any incentive to upgrade. (This is the same as if the TXT record was used for initial work.) The document goes to lengths to say that name servers can handle unknown types. In fact, so long as a type is unknown, it will work better. This is because of the standardization of the "printable format." Until a name server can parse a resource record, it doesn't matter what the format of the the RDATA is, meaning it can be more easily dumped into a file format like that used by slave servers for zones they have received. I mention that because what we have is a bureaucratic problem whose source is RFC 2929. I don't mean to criticize the effort behind RFC 2929, but to say that we are learning something in hindsight here. And maybe some of what wayne has said applies to these lessons. I'll suggest two possibly radical notions for the assignment of new RR type codes. One is somewhat anarchic and is prompted by wayne's discussion of Unix file magic numbers. The other is a "number lease". We could state that IANA only reserves numbers upon consensus of the IETF, but encourage innovating implementers to reuse any number not otherwise reserved by IANA and not obiously in use. If two such innovators collide (as wayne mentions), the issue is somehow resolved. The IETF and IANA should be clear that unreserved type codes are open territory. A real conflict, not a bureaucratic one, will be settled. Alternatively, we could lower the bar for getting an IANA type code number reservation to just documenting it in an internet-draft with the caveat that the number is only reserved for two (X) years, by which time consensus is needed to give it "tenure." The latter would work so long as no name servers try to parse the RDATA of non-tenured RR types. Winding this all up, the problem of adding new RR types is not a problem for the DNS. It is a problem with the bureaucracy surrounding the DNS and for applications making use of the data. I've mentioned the bureaucratic problem (and I am not referring to the operations of the IANA registry, but the instructions in RFC 2929 given to IANA), but I haven't said much about the problem for applications. Assuming that name servers don't parse types until they are "permanent" - referring to the leased (non-tenured) numbers, then there shouldn't be a problem with the use of a RR type code 98 for one application from 2012 to 2013 and by another application from 2017 to 2019. The presumption is that the first application failed to win enough acceptance to gain a permanent hold on record 98 and has fallen by the wayside. It's not like a wrestling match between application #1 and application #2 would be too close to call. If, though, there is still some holdover data from one application to the other's era and if the name servers all treat 98 as unknown, the DNS will not have a problem. The problem will be within the (new) application. Implementers will have to be aware of that possibility. In summary, for a stable DNS the goal is to extend it via new RR types. Although this is the "right thing to do" in a conceptual world, the bureaucratic world works against this, given the environment of innovation. I hope that the IAB statement on this issue can be made more realistic, reflecting the reality of the day and not only on a theoretical view of the Internet (which is why I raised the side point about the unique root statement). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 10:55:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08943 for ; Thu, 9 Jun 2005 10:55:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgOPj-000MLV-OF for namedroppers-data@psg.com; Thu, 09 Jun 2005 14:53:47 +0000 Received: from [208.31.42.38] (helo=tom.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DgOPi-000ML8-Qv for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 14:53:47 +0000 Received: (qmail 17121 invoked from network); 9 Jun 2005 14:53:45 -0000 Received: (ofmipd 208.31.42.47); 9 Jun 2005 14:53:23 -0000 Date: 9 Jun 2005 10:53:46 -0400 Message-ID: From: "John R Levine" To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: <87zmtzu5de.fsf@deneb.enyo.de> References: <20050609021755.3641.qmail@xuxa.iecc.com> <87zmtzu5de.fsf@deneb.enyo.de> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> The claim that most DNS servers and clients handle unknown RR types >> is, unfortunately, just false. ... > > But you can't be considerate eternally and halt all protocol > improvements because you think that a single vendor won't feel any > market pressure. Quite true, but on the other hand, if you build software that half your users can't use, you're not going to get much traction. > I see two solutions to the mess: Either fix wildcards to handle > prefixes gracefully, or dynamically assign RR types on a per-domain > basis (reserve a range of RR types, and use a two-stage query scheme, > to obtain the RR number first and the actual data in a second query). We don't need dynamic RR types, there's plenty of them. We need to drastically lower the bar to assigning RR types. It's a 16 bit field, if they handed out a thousand numbers of which only two turned out to be useful, it wouldn't be a big deal, it's less than 2% of the address space. It might also be good to designate some chunk of the RR space as the experimental range where numbers will never be assigned so people can safely fool around with private types there. Well, except for the problem of getting DNS software to support new types. To date, there's been an unspoken assumption that new RR's will be rare enough that DNS software developers can just hand-code support for new types and ship updates, leading to another unfortunate circle of no new types. Something like my XML proposal to make new types a table update rather than a software upgrade oughta help there. I also agree with Vix that embedded wildcards would be a way out of this mess, but I perceive a strong sentiment in the DNS community that the current wildcards are just fine and the only problem is that people don't understand them, so I'm not holding my breath. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 12:06:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16396 for ; Thu, 9 Jun 2005 12:06:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgPU0-00039p-NB for namedroppers-data@psg.com; Thu, 09 Jun 2005 16:02:16 +0000 Received: from [66.163.169.222] (helo=smtp103.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DgPTx-00037t-Rd for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 16:02:13 +0000 Received: (qmail 77540 invoked from network); 9 Jun 2005 16:02:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Message-Id:X-Sender:X-Mailer:Date:To:From:Subject:In-Reply-To:Mime-Version:Content-Type; b=lGrhe6G7alDRqz9JkQfjyDNnZH7/hIwlH4PrNXTDC+BAFP/nU5nmgFPAoRdESLN0X7SiNIdfKviQ8I4rb7+WsQUg1SwWWyckUFQtqac4eI6/7NlzaoGVpNNIbMtUrntup6MUCpPuGkLrg54vm44+2Z/G18hiKlRQDsOZaT9BN0s= ; Received: from unknown (HELO phred.yahoo.com) (david?macquigg@216.183.69.58 with login) by smtp103.mail.sc5.yahoo.com with SMTP; 9 Jun 2005 16:02:13 -0000 Message-Id: <5.2.1.1.0.20050608184432.04a2ca68@pop.mail.yahoo.com> X-Sender: david_macquigg@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 09 Jun 2005 09:03:24 -0700 To: "IETF DNSEXT WG" From: David MacQuigg Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 07:58 PM 6/8/2005 -0500, wayne wrote: <...> >I believe what needs to be done is to allocate say, 100 new DNS RRs as >clones of TXT records (say, TXT0-TXT99). There are tens of thousands >of RR numbers sitting totally unused. This seems like a halfway step, like the old DOS database I used in the late 80's to run my business. It had a scripting language, but no variables!! After enough users screamed, they gave us a small number of variables with fixed names, like the above. It seems very odd that the design of DNS allowed records to have a "class" attribute, but not a much more useful "name" attribute. I don't like forcing the "type" attribute to serve as a "name". My current plans are to prepend the necessary record names to the domain name, like CSV is doing with _client._smtp.. TXT type is adequate for anything I will need. As I understand it, the only problem is that I can't use wildcards at the same time. So I can't have _client._smtp.*.. That is a limitation I can live with, but something that might be nice for a future extension of DNS. <...> >The only >problem with TXT is that their space is limited, but that can be fixed >as easily as it would take to create one single other new RR type. Sorry for a dumb question, but what will it take to raise the 512-byte limit, without a fallback to TCP, which would negate the UDP speed advantage, and make me want to use the more versatile HTTP for general queries? Even if we had to wait 10 years for some old machines to die, it would be a nice improvement in DNS. Meanwhile, we can continue to use multiple queries to linked records for anything over 512 bytes, and when the Internet is ready, make a smooth transition to a single, more streamlined record. -- Dave ************************************************************ * * David MacQuigg, PhD email: david_macquigg at yahoo.com * * * IC Design Engineer phone: USA 520-721-4583 * * * * Analog Design Methodologies * * * * 9320 East Mikelyn Lane * * * * VRS Consulting, P.C. Tucson, Arizona 85710 * ************************************************************ * -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 12:58:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21521 for ; Thu, 9 Jun 2005 12:58:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgQKR-0009Vc-HK for namedroppers-data@psg.com; Thu, 09 Jun 2005 16:56:27 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgQKP-0009Ub-9o for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 16:56:25 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 9629D24ACE; Thu, 9 Jun 2005 18:56:22 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6555224ACD for ; Thu, 9 Jun 2005 18:56:21 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j59GuKUU026497 for ; Thu, 9 Jun 2005 18:56:20 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j59GuKa1015584 for namedroppers@ops.ietf.org; Thu, 9 Jun 2005 18:56:20 +0200 Received: from [192.0.35.122] (helo=santee.icann.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgQAm-00085e-UE for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 16:46:29 +0000 Received: from newiana (g35-170.icann.org [192.0.35.170] (may be forged)) by santee.icann.org (8.11.6/8.11.6) with ESMTP id j59GkUb06905; Thu, 9 Jun 2005 09:46:30 -0700 Message-Id: <200506091646.j59GkUb06905@santee.icann.org> From: "IANA" To: "'Samuel Weiler'" , "'Roy Arends'" Cc: Subject: RE: where did all them bits go ? (dns-parameters/dns-header-flags/dnskey-flags) Date: Thu, 9 Jun 2005 08:29:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcVoR0zG+RY6dE8PR8C/cjcLmgfSowEv/0JQ X-RIPE-Spam-Tests: BAYES_00 X-RIPE-Spam-Status: N 0.000016 / -2.6 X-RIPE-Signature: 0659fa660580ba436cf53883aa02dd5b X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: This post needed manual approval. Either it was posted by a non-subscribed address, or the posting was too large ( > 20000bytes ) for this list. With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please use your subscribed address to post, or shorten your postings by using links instead of attachments. ] Following-up... The registries have been updated so that the approved dnssec I-Ds now shows as the published RFCs. Quick question.... You mention a citation to RFC2929, does this need to be added to any of these registries at this time? If so which ones and where? Or, will the -bis document make this update? Thanks, Michelle Cotton IANA -----Original Message----- From: Samuel Weiler [mailto:weiler@tislabs.com] Sent: Friday, June 03, 2005 7:18 AM To: Roy Arends Cc: namedroppers@ops.ietf.org; iana@iana.org Subject: Re: where did all them bits go ? On Fri, 3 Jun 2005, Roy Arends wrote: > I guess 4034 and 4035 are missing information on where exactly the CD > and AD bits reside in the DNS header. Its specified in rfc2535, but > omitted in the current drafts, which obsolete 2535. > > I'll send text. I concur that it's a good idea to mention this registry in draft-ietf-dnsext-dnssec-bis-updates just as 4034 section 7 mentioned, but did not change, (some of?) the other relevant ones. That said, since this is an IANA-managed registry[1] and the assignment is still documented in RFC2929 (BCP42), I don't think this is a big deal. A citation to 2929 is probably in order, too. Curiously, the IANA registry for those bits[1] still references the -protocol draft -- it was never updated to reflect the publication of RFC4035. It also doesn't mention 2929, which sets a threshhold for assigning a meaning to the Z bit (bit 9). The typecode registry [2] also still has refereces to -records and the ipseckey drafts. Sigh. I'm CC'ing this to IANA so they can fix both of these. Also, 4034 has an error in the IANA section (Section 7): the last paragraph claims that 3755 opened a registry [3] for KEY and DNSKEY flag values. That registry's applicablity was limited to only DNSKEY, not KEY, as noted in the registry. Since 4034 asserts that it's not making changes to IANA registries, I'll document this in bis-updates as an error in 4034, not a change to the registry. -- Sam, obsessive protocol geek [1] http://www.iana.org/assignments/dns-header-flags [2] http://www.iana.org/assignments/dns-parameters [3] http://www.iana.org/assignments/dnskey-flags -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 14:57:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03956 for ; Thu, 9 Jun 2005 14:57:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgSAj-000NKw-1K for namedroppers-data@psg.com; Thu, 09 Jun 2005 18:54:33 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgSAh-000NKa-1E for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 18:54:31 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j59IsNC3008250; Thu, 9 Jun 2005 14:54:25 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id j59Irs6u018124; Thu, 9 Jun 2005 14:53:54 -0400 (EDT) From: "Scott Rose" To: Cc: Subject: RE: where did all them bits go ? (dns-parameters/dns-header-flags/dnskey-flags) Date: Thu, 9 Jun 2005 14:53:54 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200506091646.j59GkUb06905@santee.icann.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I do not believe RFC 2929 should appear in any of the registries. I thought it was simply an RFC of the current IANA registry states. I doesn't actually seek to allocate anything that isn't already defined in some other DNS specification. It is a handy guide for people that don't check all the IANA registries to go to one RFC and get all the reserved values. If I'm wrong, someone correct me Scott > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of IANA > Sent: Thursday, June 09, 2005 11:29 AM > To: 'Samuel Weiler'; 'Roy Arends' > Cc: namedroppers@ops.ietf.org > Subject: RE: where did all them bits go ? > (dns-parameters/dns-header-flags/dnskey-flags) > > > [ Moderators note: This post needed manual approval. > > Either it was posted by a non-subscribed address, or the posting > was too large ( > 20000bytes ) for this list. > > With the massive amount of spam, it is easy to miss and therefore > delete posts that need manual approval. > > Please use your subscribed address to post, or shorten your > postings by using links instead of attachments. ] > > Following-up... > > The registries have been updated so that the approved dnssec I-Ds > now shows > as the published RFCs. > > Quick question.... > You mention a citation to RFC2929, does this need to be added to any of > these registries at this time? If so which ones and where? Or, will the > -bis document make this update? > > Thanks, > > Michelle Cotton > IANA > > > -----Original Message----- > From: Samuel Weiler [mailto:weiler@tislabs.com] > Sent: Friday, June 03, 2005 7:18 AM > To: Roy Arends > Cc: namedroppers@ops.ietf.org; iana@iana.org > Subject: Re: where did all them bits go ? > > On Fri, 3 Jun 2005, Roy Arends wrote: > > > I guess 4034 and 4035 are missing information on where exactly the CD > > and AD bits reside in the DNS header. Its specified in rfc2535, but > > omitted in the current drafts, which obsolete 2535. > > > > I'll send text. > > I concur that it's a good idea to mention this registry in > draft-ietf-dnsext-dnssec-bis-updates just as 4034 section 7 mentioned, but > did not change, (some of?) the other relevant ones. That said, since this > is an IANA-managed registry[1] and the assignment is still documented in > RFC2929 (BCP42), I don't think this is a big deal. A citation to 2929 is > probably in order, too. > > Curiously, the IANA registry for those bits[1] still references the > -protocol draft -- it was never updated to reflect the publication of > RFC4035. It also doesn't mention 2929, which sets a threshhold for > assigning a meaning to the Z bit (bit 9). The typecode registry [2] also > still has refereces to -records and the ipseckey drafts. Sigh. > I'm CC'ing this to IANA so they can fix both of these. > > Also, 4034 has an error in the IANA section (Section 7): the last > paragraph > claims that 3755 opened a registry [3] for KEY and DNSKEY flag > values. That > registry's applicablity was limited to only DNSKEY, not KEY, as > noted in the > registry. Since 4034 asserts that it's not making changes to IANA > registries, I'll document this in bis-updates as an error in 4034, not a > change to the registry. > > -- Sam, obsessive protocol geek > > [1] http://www.iana.org/assignments/dns-header-flags > [2] http://www.iana.org/assignments/dns-parameters > [3] http://www.iana.org/assignments/dnskey-flags > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 9 17:30:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21736 for ; Thu, 9 Jun 2005 17:30:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgUXo-000BTj-NT for namedroppers-data@psg.com; Thu, 09 Jun 2005 21:26:32 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgUXl-000BTS-4I for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 21:26:29 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j59LMW9f019952 for ; Thu, 9 Jun 2005 17:22:32 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAv3ay9M; Thu, 9 Jun 05 17:22:30 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j59LOLJi021609; Thu, 9 Jun 2005 17:24:21 -0400 (EDT) Date: Thu, 9 Jun 2005 17:24:21 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Scott Rose cc: iana@iana.org, namedroppers@ops.ietf.org Subject: RE: where did all them bits go ? (dns-parameters/dns-header-flags/dnskey-flags) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I do not believe RFC 2929 should appear in any of the registries. I thought > it was simply an RFC of the current IANA registry states. I doesn't actually > seek to allocate anything that isn't already defined in some other DNS > specification. > > It is a handy guide for people that don't check all the IANA registries to > go to one RFC and get all the reserved values. > > If I'm wrong, someone correct me You MAY be right that 2929 doesn't allocate anything, but, as I said previously, it does set at least one threshhold for assignment, which none of 1034, 1035, 2136, 2181, nor 2535 seem to do. I'd call that a modification to the registry. Whether IANA wants to note that in the registry file is up to them. > > It also doesn't mention 2929, which sets a threshhold for > > assigning a meaning to the Z bit (bit 9). I'm not sure what other changes are needed based on 2929, but if this one is missing, I suspect others might be as well. Perhaps IANA would be willing to go through 2929 with a fine-toothed comb -- it is, after all, an entire RFC/BCP of IANA Considerations, and not a very long one at that. To answer one of Michelle's direct question: no, the bis-updates doc will likely NOT make any changes to IANA registries, neither assignments nor threshholds for assignment. Also, this still needs to be fixed (see RFC4025): > > The typecode registry [2] also > > still has refereces to ... the ipseckey drafts. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 03:16:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20071 for ; Fri, 10 Jun 2005 03:16:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgdfA-000AsG-Vq for namedroppers-data@psg.com; Fri, 10 Jun 2005 07:10:44 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dgdf8-000Arr-Vs for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 07:10:43 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 6A75524B9E; Fri, 10 Jun 2005 09:10:27 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5E53424B32 for ; Fri, 10 Jun 2005 09:10:24 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j5A7AOUU010977 for ; Fri, 10 Jun 2005 09:10:24 +0200 Date: Fri, 10 Jun 2005 09:10:24 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Fw: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France Message-Id: <20050610091024.6e0e7097.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.018066 / -5.9 X-RIPE-Signature: df41029a636b17c870a2191400866fb9 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleages, Note that if you plan to publish a version 0 of a working group document you really should let this group know by the end of this month. Then we can let the secretariat know by July 5 that such draft is coming. As always when the material in personal submissions is relevant and within charter we'll allow it on the agenda. Note also that drafts will be bounced at submission if they do not contain the appropriate boilerplate material. When authoring in XML the following will do the trick: Also see: http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#ipr --Olaf ---------------------- Begin forwarded message ---------------------- Date: Fri, 10 Jun 2005 00:00:01 -0400 From: ietf-secretariat@ietf.org To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France There are two (2) Internet-Draft cutoff dates for the 63rd IETF Meeting in Paris, France: July 11th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, July 11th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Tuesday, July 5th at 9:00 AM ET. July 18th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, July 18th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, August 1st at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or revised Internet-Draft after their respective cutoff deadlines, then your document will be retained and posted when Internet-Draft processing resumes. You will no longer be required to resubmit the document. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ---------------------- End forwarded message ------------------------ -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC ---------------------------------| JID: olaf at jabber.secret-wg.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 12:55:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08048 for ; Fri, 10 Jun 2005 12:55:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dgmgb-000BkQ-Si for namedroppers-data@psg.com; Fri, 10 Jun 2005 16:48:49 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dgmga-000Bk4-UV for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 16:48:49 +0000 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 877AB719 for ; Fri, 10 Jun 2005 12:48:47 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DA199418D for ; Fri, 10 Jun 2005 12:48:46 -0400 (EDT) Date: Fri, 10 Jun 2005 12:48:46 -0400 From: Rob Austein To: "IETF DNSEXT WG" Subject: Re: draft-iab-dns-choices-02.txt comments: host names vs domain names In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050610164846.DA199418D@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 09 Jun 2005 08:03:03 -0500, 'wayne' wrote: > > So, in order to help this educational process, can someone give a > short paragraph that explains the differences between host names and > domain names, why the allowed characterset is different between the > two and when you should use one or the other? Really short answer: see RFC 1034 3.5 and RFC 1035 2.3.1. Slightly longer answer: Hostnames are a proper subset of DNS names. Hostnames have to fit the syntax defined in RFC 952 as amended by RFC 1123; DNS names only have to fit the much looser syntax defined in RFC 1035. You have to use hostnames when you're dealing with applications that say they're dealing with hostnames or which have their own syntax definitions which work out to be equivilent to the hostname syntax. Since most registries will not accept DNS names that don't comply with the hostname syntax, as a practical matter use of DNS names which are not hostnames is for the most part restricted to applications like the _prefix hack. Note that IDN deliberately encodes to DNS names which do fit the hostname syntax. As to "why?"...see the archives of the IDN WG for more details than you ever wanted, but I won't attempt to summarize because the opinion/fact ratio in this space is way too high. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 15:32:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24059 for ; Fri, 10 Jun 2005 15:32:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgpCP-0000Gw-9d for namedroppers-data@psg.com; Fri, 10 Jun 2005 19:29:49 +0000 Received: from [144.189.100.105] (helo=motgate5.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgpCN-0000Gg-Hx for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 19:29:47 +0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j5AJZJIP023739 for ; Fri, 10 Jun 2005 12:35:19 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j5AJXQtm006220 for ; Fri, 10 Jun 2005 14:33:27 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Jun 2005 15:29:45 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: draft-iab-dns-choices-02.txt comments Date: Fri, 10 Jun 2005 15:29:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Am I missing something? RFC 2929, as well as allocating RR Type numbers from 65280 - 65534 (0xFF00 - 0xFFFE) for private use also allocates almost half of all RR Type numbers, those from 32768 - 65280 (0x8000 - 0xFEFF), for use based on "Specification Required". That is, as defined in RFC 2434: Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. Isn't getting an RR Type based on just publicly documneting its use liberal enough? Donald -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of John R Levine Sent: Thursday, June 09, 2005 10:54 AM To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments ... We don't need dynamic RR types, there's plenty of them. We need to drastically lower the bar to assigning RR types. It's a 16 bit field, if they handed out a thousand numbers of which only two turned out to be useful, it wouldn't be a big deal, it's less than 2% of the address space. It might also be good to designate some chunk of the RR space as the experimental range where numbers will never be assigned so people can safely fool around with private types there. ... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 15:37:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24748 for ; Fri, 10 Jun 2005 15:37:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgpHq-0000oe-5b for namedroppers-data@psg.com; Fri, 10 Jun 2005 19:35:26 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgpHp-0000oP-Dq for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 19:35:25 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24448; Fri, 10 Jun 2005 15:35:22 -0400 (EDT) Message-Id: <200506101935.PAA24448@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc2538bis-03.txt Date: Fri, 10 Jun 2005 15:35:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 : Storing Certificates in the Domain Name System (DNS) Author(s) : S. Josefsson Filename : draft-ietf-dnsext-rfc2538bis-03.txt Pages : 14 Date : 2005-6-10 Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsolete RFC 2538. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2538bis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rfc2538bis-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-rfc2538bis-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: <2005-6-10154430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc2538bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc2538bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-10154430.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 15:45:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26284 for ; Fri, 10 Jun 2005 15:45:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgpOf-0001Wv-IM for namedroppers-data@psg.com; Fri, 10 Jun 2005 19:42:29 +0000 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgpOd-0001Wd-MB for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 19:42:27 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j5AJgPSO030937; Fri, 10 Jun 2005 12:42:25 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j5AJgP6U030934; Fri, 10 Jun 2005 12:42:25 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 10 Jun 2005 12:42:25 -0700 (PDT) From: "william(at)elan.net" To: Eastlake III Donald-LDE008 cc: namedroppers@ops.ietf.org Subject: RE: draft-iab-dns-choices-02.txt comments In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> Message-ID: References: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 10 Jun 2005, Eastlake III Donald-LDE008 wrote: > Am I missing something? > > RFC 2929, as well as allocating RR Type numbers from 65280 - 65534 (0xFF00 - 0xFFFE) for private use also allocates almost half of all RR Type numbers, those from 32768 - 65280 (0x8000 - 0xFEFF), for use based on "Specification Required". That is, as defined in RFC 2434: > > Specification Required - Values and their meaning must be > documented in an RFC or other permanent and readily available > reference, in sufficient detail so that interoperability > between independent implementations is possible. > > Isn't getting an RR Type based on just publicly documneting its use > liberal enough? I've not seen any RR types allocated except though IETF consensus and RFC. Perhaps if RFC2929 is already liberal enough then clarification from this WG would be good or establishing a better documented procedure for requesting new RR (documented in separate document released preferably as INFORMATIONAL RFC or BCP) would be good enough and allow those who are proposing new uses of DNS to get RR type numbers quickly though IANA that they could test their proposals and experiment with real-life deployment. -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 17:29:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14805 for ; Fri, 10 Jun 2005 17:29:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dgr0c-000BJQ-PB for namedroppers-data@psg.com; Fri, 10 Jun 2005 21:25:46 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Dgr0a-000BJA-JA for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 21:25:44 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j5ALPZeT001914 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 10 Jun 2005 17:25:42 -0400 Date: Fri, 10 Jun 2005 17:25:35 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: IETF DNSEXT WG Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Umm. This seems like a lot of work for no good reason. MARID failed for 15 reasons, none of which was the problem with adding a new RR type. SPF doesn't acheive its goals of stopping spam and creates more problems and more opportunities for abuse. I count so far 15 significant problems raised for SPF: 1.Abuser can still forge addresses at domain 2.Abuser can use stolen credential 3.DNS cache problems (more records per domain, same cache size) 4.DNS load (more records per domain) 5.Ongoing Maintenance issues 6.Migration issues 7.IP Renumbering issues 8.Lost non-spam emails 9.Lack of universal compliance.* 10.Not a basis for trust/reduced filtering 11.Makes forgery blowback problem much worse 12.Patent issues 13.spam-profiteering / charges for SPF services 14.Email Source Routing 15.Outbound SMTP Relay Identification I think if we have genuine need for a new RRtype, it can be accomodated. However, MARID wasn't a genuine need. --Dean On Thu, 9 Jun 2005, wayne wrote: > In <87wtp3smrv.fsf@deneb.enyo.de> Florian Weimer writes: > > >> Sure you can't query by it (today) by type, but you can get all the > >> information back anyway, and if we wanted at some stage to query > >> by 4-tuple rather than 3-tuple, it would be obvious how to do it. > > > > I'm not sure how such a transition would interact with DNSSEC. > > Yeah, I'm not sure how this would work either and I'm interested in > learning the answer. At one time, I pondered the idea of using an > EDNS0-type extension system to allow for a *small* magic number > selector to be sent with the query in order to limit the number of TXT > records that are returned. I think this would also cause problems > with conflicting TTLs. > > > > Just for clarity, I would propose something like this: > > > > foo IN RTYPE ("SPFv71", 1025) ("killspam3", 1026) > > foo IN TYPE1025 "Here's my SPF String" > > foo IN TYPE1026 "Here's my other string" > > > > (Everything is crammed into one RTYPE to cut down the protocol > > overhead. Another level of indirection (ahem) could be used to > > increase caching.) > > What happens if the list of mapped dynamic RR types exceeds the size > of a 512 byte UDP packet? > > > -wayne > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 18:16:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18977 for ; Fri, 10 Jun 2005 18:16:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dgrkx-000Fq1-Te for namedroppers-data@psg.com; Fri, 10 Jun 2005 22:13:39 +0000 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dgrkv-000Fpm-QJ for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 22:13:38 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j5AMDXam000674; Fri, 10 Jun 2005 15:13:33 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j5AMDXxV000671; Fri, 10 Jun 2005 15:13:33 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 10 Jun 2005 15:13:33 -0700 (PDT) From: "william(at)elan.net" To: Dean Anderson cc: IETF DNSEXT WG Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 10 Jun 2005, Dean Anderson wrote: > I think if we have genuine need for a new RRtype, it can be accomodated. > However, MARID wasn't a genuine need. Dean, I'm not going to go though your arguments, but from what I see the issue is that DNSEXT is not assigning new RR types in without very very substantial review and that creates other problems like that that proposals like SPF begin to use TXT as basis and then this may become widely used on the net. It should not be for DNSEXT people to decide if concept itself is bad or good and argue about it here, you should focus on providing stability for dns system and let others run experiments that use dns for specific applications and if experiment turns out to be usefull the requested RR assignment becomes permanent. But trying to shut down (or not letting it start) the experiment by not getting it RR is just wrong and exactly why proposals like SPF or DK which attempt to use TXT RR instead of getting new one from the start. -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 18:35:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21538 for ; Fri, 10 Jun 2005 18:35:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dgs4b-000Hba-HA for namedroppers-data@psg.com; Fri, 10 Jun 2005 22:33:57 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dgs4Z-000HbK-MV for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 22:33:55 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dgs4N-00030Y-LM for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 17:33:54 -0500 To: "IETF DNSEXT WG" References: From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jun 2005 17:33:42 -0500 In-Reply-To: (Dean Anderson's message of "Fri, 10 Jun 2005 17:25:35 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In Dean Anderson writes: > 1.Abuser can still forge addresses at domain > 2.Abuser can use stolen credential These are out of scope for this list. > 3.DNS cache problems (more records per domain, same cache size) This is a choice that receivers can decide on. If they don't think the additional DNS cache is worth it, then don't use SPF checks. > 4.DNS load (more records per domain) This, indeed, is a problem that I wish didn't exist. Domain owners that don't want to deal with SPF will still receive DNS queries. The only thing I can suggest is to publish an SPF record that has a very long TTL which says "v=spf1 ?all". For domain owners that do want to publish SPF records, then that is their choice to have more records. > 5.Ongoing Maintenance issues > 6.Migration issues > 7.IP Renumbering issues Again, this is up to the domain owners who choose to publish SPF records. SPF does have quite a few features that make these less of an issue, at the expense of increased DNS loads. The choice is up tothe domain owner. > 8.Lost non-spam emails > 9.Lack of universal compliance.* > 10.Not a basis for trust/reduced filtering > 11.Makes forgery blowback problem much worse > 12.Patent issues > 13.spam-profiteering / charges for SPF services > 14.Email Source Routing > 15.Outbound SMTP Relay Identification These are out of scope for this list. The things that are in scope for this list are reasons why I have twice, without being asked, asked for reviews of the SPF I-D here. If it was up to the IESG, no review would have been done here. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 18:40:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21886 for ; Fri, 10 Jun 2005 18:40:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dgs9q-000I7I-F6 for namedroppers-data@psg.com; Fri, 10 Jun 2005 22:39:22 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dgs9o-000I6w-Pc for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 22:39:20 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dgs9f-00039k-20 for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 17:39:19 -0500 To: "IETF DNSEXT WG" References: <20050610164846.DA199418D@thrintun.hactrn.net> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jun 2005 17:39:10 -0500 In-Reply-To: <20050610164846.DA199418D@thrintun.hactrn.net> (Rob Austein's message of "Fri, 10 Jun 2005 12:48:46 -0400") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments: host names vs domain names X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <20050610164846.DA199418D@thrintun.hactrn.net> Rob Austein writes: > At Thu, 09 Jun 2005 08:03:03 -0500, 'wayne' wrote: >> >> So, in order to help this educational process, can someone give a >> short paragraph that explains the differences between host names and >> domain names, why the allowed characterset is different between the >> two and when you should use one or the other? > > Really short answer: see RFC 1034 3.5 and RFC 1035 2.3.1. > > Slightly longer answer: [...] Thanks for the description. I understood it and it matches my understanding of the difference between a hostname and a domain name, but suspect that it would go right over the head of 99.9% of all domain owners. Heck, I suspect that it too many folks that run DNS hosting services wouldn't immediately understand it without reading the RFCs and such. My point remains that one problem with _prefix tricks is that many people can't create them due to software that restricts domain names to hostname characters. But, maybe I'm wrong. If you think so, let me know. I think that dns-choices should mention this problem. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 19:11:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23614 for ; Fri, 10 Jun 2005 19:11:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dgsbe-000LNs-Ow for namedroppers-data@psg.com; Fri, 10 Jun 2005 23:08:06 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dgsbd-000LNV-1d for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 23:08:05 +0000 Received: (qmail 8241 invoked by uid 100); 10 Jun 2005 23:08:03 -0000 Date: 10 Jun 2005 23:08:03 -0000 Message-ID: <20050610230803.8240.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> Organization: I.E.C.C., Trumansburg NY USA Cc: Donald.Eastlake@motorola.com Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Isn't getting an RR Type based on just publicly documneting its use > liberal enough? You're right, I misremembered 2929. My bad. This still leaves us with the question of why we see so few new RR types in practice. I guess it's a combination of the difficulty of getting them into zone files and the dismayingly large number of junkware clients that can't query them. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 19:18:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23977 for ; Fri, 10 Jun 2005 19:18:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgsjB-000MOF-W1 for namedroppers-data@psg.com; Fri, 10 Jun 2005 23:15:53 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dgsj9-000MNz-8P for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 23:15:51 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dgsiz-0003zi-Ev for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 18:15:50 -0500 To: "IETF DNSEXT WG" References: From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jun 2005 18:15:40 -0500 In-Reply-To: (Edward Lewis's message of "Thu, 9 Jun 2005 10:51:49 -0400") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: IAB DNS choices 02 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In Edward Lewis writes: > I saw the comments from wayne on this document. I > have a different perspective, I think, in that I want to protect the > future of the DNS. (I don't mean to say he's out to hurt the DNS, his > objective is to meet the needs of application developers - > also a worthy goal.) Indeed, if I thought my suggestions would hurt the DNS, I wouldn't have made them. > I bring this up because that situation and the situation wayne has > been describing reflects what I think has been a large shift in the > dynamics of innovation in the Internet over time, and in the past > decade (plus). I agree with this. > [...] So, what is likely to happen is > that implementation and testing will happen using what's at hand - > the "private use" number. > > Eventually, IANA allocates a type code number. What happens next? > [problems with migrating to a new RR number] Yes, there is no easy way of migrating RR numbers. Look how long it has been since MX records were created and people still depend on receiving email by publishing just an A record. > The document goes to lengths to say that name servers can handle > unknown types. In fact, so long as a type is unknown, it will work > better. This is because of the standardization of the "printable > format." Until a name server can parse a resource record, it doesn't > matter what the format of the the RDATA is, meaning it can be more > easily dumped into a file format like that used by slave servers for > zones they have received. This is why I think there should be a large block of "unclaimed" TXT RR clones. Plain text is *FAR* more useful than hex. Yes, text is is not as compact as binary encodings, but I don't think that is a huge problem. After you add in all the overhead from UDP packets and other DNS information, you the difference between text vs binary isn't going to ammount to much. As far as John Levine's idea of some downloadable parsing meta data to allow for proper display of "unknown" binary types, well, whether it is xml, asn.1, or java, the idea gives me the willies. In order to be effective, most things that deal with DNS would need to be able to automatically download this parsing meta data and "execute" it. I don't want to think about all the exploits that could be caused by a bad asn.1 parser, or incorrect/malicious meta data, etc. Plain text keeps everything simple. No special tools to convert hex to readable text and back, no special tools to convert binary to readable text and back. Just readable text. > I'll suggest two possibly radical notions for the assignment of new RR > type codes. One is somewhat anarchic and is prompted by wayne's > discussion of Unix file magic numbers. The other is a "number lease". I just don't think number lease will work, at least not without built in expiration data on the records. Of course, the expiration data is really just a limited version of Unix file magic numbers. Ok, if the protcol police get full funding, we could go around and enforce the number lease period, but I suspect that isn't going to happen and we will just end up with a lot of poluted numbers. > Winding this all up, the problem of adding new RR types is not a > problem for the DNS. It is a problem with the bureaucracy surrounding > the DNS and for applications making use of the data. Agreed. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 19:46:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25544 for ; Fri, 10 Jun 2005 19:46:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgtAE-000Oqr-CJ for namedroppers-data@psg.com; Fri, 10 Jun 2005 23:43:50 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgtAB-000Oqb-KO for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 23:43:47 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DgtA5-0004wS-Vj for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 18:43:46 -0500 To: "IETF DNSEXT WG" From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jun 2005 18:43:41 -0500 Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: more thoughts on a set of TXT record clones X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I was thinking a little more about my proposal to create a set of TXT record clones that use magic numbers. I think two things would help. First, the magic number should be restricted to be exactly the first substring in the TXT record. The TXT clone record could have any number of strings, but the first is reserved for being the magic number. Secondly, instead of letting people choose which TXT clone to use, we should hash the magic number down into the set size. This would reduce the chances of many people picking "easy to remember" numbers, and would reduce the amount of information that people have to enter. So, the records could look like this: foo.com. TEXT "SPFv71" "some cross between APL and perl" bar.com. TEXT "PGP" "your favorate PGP key" If we allocated a set of 32 TXT record clones, then the "SPFv71" and "PGP" keys would be hashed down into the range of 0 to 31, and then added to the base RR number for the set. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 22:05:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03641 for ; Fri, 10 Jun 2005 22:05:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgvIi-000Cin-7H for namedroppers-data@psg.com; Sat, 11 Jun 2005 02:00:44 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DgvId-000Ci4-Hq for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 02:00:39 +0000 Received: (qmail 3007 invoked by uid 100); 11 Jun 2005 02:00:36 -0000 Date: 11 Jun 2005 02:00:36 -0000 Message-ID: <20050611020036.3006.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: more thoughts on a set of TXT record clones In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >I was thinking a little more about my proposal to create a set of TXT >record clones that use magic numbers. I think two things would help. After thinking about it for a while, I've come to the conclusion that although your proposal isn't horrible, it involves about 90% of the work involved in fixing the RR type problem for about 30% of the result. A large part of the problem is software that doesn't handle any new RR types at all. For the most part, it's as easy to fix it to handle all possible types as to add one or two more. Sure, it's more code, but writing and debugging the new version is about 2% of the work, and getting it installed everywhere is 98% of the work. So if you're going to upgrade programs like bind and dig and nslookup and tinydns-data (from djbdns) to encode and decode a few new faux text types, why not do something like my XML trick so they can handle any new types and solve the problem once and for all? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 10 22:05:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03646 for ; Fri, 10 Jun 2005 22:05:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgvIi-000Cj2-Pe for namedroppers-data@psg.com; Sat, 11 Jun 2005 02:00:44 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DgvIi-000Cii-2Y for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 02:00:44 +0000 Received: (qmail 3007 invoked by uid 100); 11 Jun 2005 02:00:36 -0000 Date: 11 Jun 2005 02:00:36 -0000 Message-ID: <20050611020036.3006.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: more thoughts on a set of TXT record clones In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >I was thinking a little more about my proposal to create a set of TXT >record clones that use magic numbers. I think two things would help. After thinking about it for a while, I've come to the conclusion that although your proposal isn't horrible, it involves about 90% of the work involved in fixing the RR type problem for about 30% of the result. A large part of the problem is software that doesn't handle any new RR types at all. For the most part, it's as easy to fix it to handle all possible types as to add one or two more. Sure, it's more code, but writing and debugging the new version is about 2% of the work, and getting it installed everywhere is 98% of the work. So if you're going to upgrade programs like bind and dig and nslookup and tinydns-data (from djbdns) to encode and decode a few new faux text types, why not do something like my XML trick so they can handle any new types and solve the problem once and for all? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 00:01:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10339 for ; Sat, 11 Jun 2005 00:01:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dgx8d-000OzI-Td for namedroppers-data@psg.com; Sat, 11 Jun 2005 03:58:27 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dgx8b-000OwA-8b for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 03:58:25 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dgx8S-0001a4-L2 for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 22:58:24 -0500 To: "IETF DNSEXT WG" References: <20050611020036.3006.qmail@xuxa.iecc.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Fri, 10 Jun 2005 22:58:15 -0500 In-Reply-To: <20050611020036.3006.qmail@xuxa.iecc.com> (John Levine's message of "11 Jun 2005 02:00:36 -0000") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: more thoughts on a set of TXT record clones X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <20050611020036.3006.qmail@xuxa.iecc.com> John Levine writes: > So if you're going to upgrade programs like bind and dig and nslookup > and tinydns-data (from djbdns) to encode and decode a few new faux > text types, why not do something like my XML trick so they can handle > any new types and solve the problem once and for all? Well, as I mentioned in another post, I don't care if you use xml, asn.1 or java for the record description language, having things like dig download it in order to parse/print an new record type scares the heck out of me. It would be like activeX for DNS. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 00:20:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11764 for ; Sat, 11 Jun 2005 00:20:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DgxR4-0001Jx-9T for namedroppers-data@psg.com; Sat, 11 Jun 2005 04:17:30 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DgxR2-0001Jh-Mb for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 04:17:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 46A4013925 for ; Sat, 11 Jun 2005 04:17:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "IETF DNSEXT WG" Subject: Re: more thoughts on a set of TXT record clones In-Reply-To: Your message of "Fri, 10 Jun 2005 22:58:15 EST." References: <20050611020036.3006.qmail@xuxa.iecc.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 11 Jun 2005 04:17:28 +0000 Message-Id: <20050611041728.46A4013925@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > So if you're going to upgrade programs like bind and dig and nslookup > > and tinydns-data (from djbdns) to encode and decode a few new faux > > text types, why not do something like my XML trick so they can handle > > any new types and solve the problem once and for all? the reason rdata isn't self-describing isn't because in 1980 nobody had invented self-describing (ASN1-like or XML-like) data structures, nor is it that pvm had never heard of doing stuff this way. it's because there will always be devices who hope for simplicity in what they have to receive and parse and store and forward. true then, true now. probably true always. you want xml? stick an A RR or AAAA RR or both in the dns, use it to open a tcp session, and go get it. > Well, as I mentioned in another post, I don't care if you use xml, > asn.1 or java for the record description language, having things like > dig download it in order to parse/print an new record type scares the > heck out of me. It would be like activeX for DNS. yea, verily. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 03:07:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12592 for ; Sat, 11 Jun 2005 03:07:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dgzyv-000HWT-Oz for namedroppers-data@psg.com; Sat, 11 Jun 2005 07:00:37 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dgzyu-000HW3-Oa for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 07:00:37 +0000 Received: (qmail 16016 invoked by uid 100); 11 Jun 2005 07:00:31 -0000 Date: 11 Jun 2005 07:00:31 -0000 Message-ID: <20050611070031.16015.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: more thoughts on a set of TXT record clones In-Reply-To: <20050611041728.46A4013925@sa.vix.com> Organization: I.E.C.C., Trumansburg NY USA Cc: paul@vix.com Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >it's because there will always be devices who hope for simplicity in what >they have to receive and parse and store and forward. Of course. But it strikes me that we're only talking about the bits of DNS software that translate between RR's and zone-file-ese and have to display or read representations of arbitrary RR types. The caches and resolvers and most of the other stuff that's performance critical don't parse zone files so they aren't affected. The programs that use the data in new RR types are going to have the format hard coded, just like it is now, because they know what types they use. And it's just syntactic sugar. Any software that's going to handle new RR's has to do what RFC3597 says and handle \# for RRs that don't have any other format. This just makes the new types easier for humans to read or write. >> dig download it in order to parse/print an new record type scares the >> heck out of me. It would be like activeX for DNS. Ugh, that's not what I had in mind at all. Think of it as font files or stylesheets for bind and dig, e.g. $ dig argle.bargle.com any argle.bargle.com. IN TYPE497 \# 75 20390df02390a9d09d ... ^C # oh, look, it's a FOOB record, scruffle around on the web, find a # suitable 497-foob.xml file, stick it in the directory where dig and # friends look for them $ dig argle.bargle.com any argle.bargle.com. IN FOOB 93 "sasquatch" 42 jingle.jangle.org. My goal isn't to handle the semantics of every possible Turing-complete monstrosity that might come out of DNSSEC and dynamic updates and other stuff that extends the way that DNS works. It's to make it easier to add record types for new kinds of data for non-DNS applications that publish data in the DNS. R's, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 04:55:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19569 for ; Sat, 11 Jun 2005 04:55:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dh1gh-0002S0-4A for namedroppers-data@psg.com; Sat, 11 Jun 2005 08:49:55 +0000 Received: from [81.228.8.164] (helo=pne-smtpout2-sn2.hy.skanova.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dh1ge-0002Rf-Ty for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 08:49:53 +0000 Received: from arport2v (213.64.145.12) by pne-smtpout2-sn2.hy.skanova.net (7.2.059.6) id 429C53B600270F34; Sat, 11 Jun 2005 10:49:43 +0200 Message-ID: <009101c56e63$0e82fbd0$8217a8c0@arport2v> From: "Anders Rundgren" To: "John Levine" , Cc: References: <20050610230803.8240.qmail@xuxa.iecc.com> Subject: Re: draft-iab-dns-choices-02.txt comments Date: Sat, 11 Jun 2005 10:53:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >This still leaves us with the question of why we see so few new RR types >in practice. I guess it's a combination of the difficulty of getting >them into zone files and the dismayingly large number of junkware clients >that can't query them. Or maybe it is due to much simpler reason such as the fact that enterprises in contrast to ISPs use MSFT tools and GUIs and there is no way defined way of extending the GUI for supporting new RR types? And then we have the thing that people already have mentioned a zillion times. The development process is hindered by not being able to allocate an RR in an ad-hoc way without anyone judging if the RR is useful or not. To state like DomainKeys does, that they "intend" to register an RR when the things is ready is completely wacko as it leaves the users having to support TWO schemes. Indefinitely BTW. How smart is that? And then we have the fact that the scheme used in DomainKeys, prefixed TXT type actually works _perfect_ for the majority of applications and does not create any larger return set than a new RR type would. The only problem with the prefixscheme is that the prefixes are not registered. Using URI-encoded prefixes you can safely add a new "DNS data type" anytime and not even have to publish it! That the author of DNS-CHOICES did not invent a new RR for his famous ENUM stuff but overloaded NAPTR is a sure sign of that we need to do a reality check. In what way could a multivalued NAPTR be different to a multivalued TXT? Anders R ----- Original Message ----- From: "John Levine" To: Cc: Sent: Saturday, June 11, 2005 01:08 Subject: Re: draft-iab-dns-choices-02.txt comments > Isn't getting an RR Type based on just publicly documneting its use > liberal enough? You're right, I misremembered 2929. My bad. This still leaves us with the question of why we see so few new RR types in practice. I guess it's a combination of the difficulty of getting them into zone files and the dismayingly large number of junkware clients that can't query them. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 07:35:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29671 for ; Sat, 11 Jun 2005 07:35:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dh4BU-000J02-RB for namedroppers-data@psg.com; Sat, 11 Jun 2005 11:29:52 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dh4BT-000Izn-9w for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 11:29:51 +0000 Received: (qmail 165 invoked by uid 100); 11 Jun 2005 11:29:48 -0000 Date: 11 Jun 2005 11:29:48 -0000 Message-ID: <20050611112948.164.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: <009101c56e63$0e82fbd0$8217a8c0@arport2v> Organization: I.E.C.C., Trumansburg NY USA Cc: anders.rundgren@telia.com Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >The only problem with the prefixscheme is that the prefixes are >not registered. That's not much of a problem because the name space is so big. The more serious issue is that they don't work with wildcards. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 08:59:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07248 for ; Sat, 11 Jun 2005 08:59:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dh5Wj-0001uI-E0 for namedroppers-data@psg.com; Sat, 11 Jun 2005 12:55:53 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dh5Wh-0001ts-Nh for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 12:55:51 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dh5WP-0000xY-A2 for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 07:55:49 -0500 To: "IETF DNSEXT WG" References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Sat, 11 Jun 2005 07:55:32 -0500 In-Reply-To: <009101c56e63$0e82fbd0$8217a8c0@arport2v> (Anders Rundgren's message of "Sat, 11 Jun 2005 10:53:34 +0200") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <009101c56e63$0e82fbd0$8217a8c0@arport2v> "Anders Rundgren" writes: > The development process is hindered by not being able to allocate > an RR in an ad-hoc way without anyone judging if the RR is useful or not. > To state like DomainKeys does, that they "intend" to register an RR when > the things is ready is completely wacko as it leaves the users having > to support TWO schemes. Indefinitely BTW. How smart is that? Agreed. The spf-classic I-D also calls for the creation of a new RR. I don't ever see it being used in any significant way. There isn't any realistic migration plan. > That the author of DNS-CHOICES did not invent a new RR > for his famous ENUM stuff but overloaded NAPTR is a sure > sign of that we need to do a reality check. In what way could > a multivalued NAPTR be different to a multivalued TXT? Indeed. And it isn't just NAPTR that is being overloaded. Anti-spam DNSBLs have long overload A records in order to get a bit (or sometimes a few bits) for flags. The SPF system codifies this practice with the exists: mechanism, but I haven't heard any complaints about this overloading the meaning of A records by SPF. The CSV system overloads SRV records. It isn't just TXT records that are being overloaded and I don't recall dns-choices even mentioning this. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 09:36:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09798 for ; Sat, 11 Jun 2005 09:36:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dh67I-0005pd-IZ for namedroppers-data@psg.com; Sat, 11 Jun 2005 13:33:40 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dh67G-0005pN-KB for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 13:33:38 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dh676-0001dG-9Q for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 08:33:37 -0500 To: "IETF DNSEXT WG" References: <20050611070031.16015.qmail@xuxa.iecc.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Sat, 11 Jun 2005 08:33:27 -0500 In-Reply-To: <20050611070031.16015.qmail@xuxa.iecc.com> (John Levine's message of "11 Jun 2005 07:00:31 -0000") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: more thoughts on a set of TXT record clones X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <20050611070031.16015.qmail@xuxa.iecc.com> John Levine writes: > And it's just syntactic sugar. Any software that's going to handle > new RR's has to do what RFC3597 says and handle \# for RRs that don't > have any other format. This just makes the new types easier for > humans to read or write. Hex is not much easier for humans to read and write than binary. >>> dig download it in order to parse/print an new record type scares the >>> heck out of me. It would be like activeX for DNS. > > Ugh, that's not what I had in mind at all. Think of it as font files > or stylesheets for bind and dig, e.g. Yes, I know what you had in mind, it still gives me the willies. > $ dig argle.bargle.com any > > argle.bargle.com. IN TYPE497 \# 75 20390df02390a9d09d ... > > ^C > > # oh, look, it's a FOOB record, scruffle around on the web, find a > # suitable 497-foob.xml file, stick it in the directory where dig and > # friends look for them Is this "scruffling around on the web" going to be done automatically? If not, I don't see any real advantages to just downloading updated version of dig and friends. And by "friends", you are going to have to include a heck of a lot of GUIs and webforms. If not, then you are asking for automatically downloading description languages without user intervention. In either case, you have now opened up the wonderful world of record descriptions that either intentionally, or accidentally, trigger bugs in dig and friend. No. This is a complex solution for a simple problem. Again, one of the Unix file philosophies is that text files aren't really that much worse than binary files and the advantages of plain text greatly outweighs the disadvantages. How much do you really think is being saved by using binary encoded DNS records? Remember to include all the overhead of UDP/DNS packets in your calculations. SPF records have one most complex record formats of any DNS records, and they can also be very large. When I wrote the libspf2 implementation of SPF, I worked hard to create a compact, portable binary format for SPF records. The result, after a lot of study, is that in the vast majority of cases, there is no practical advantage of using binary encoded SPF records over plain text. Wow. I just rediscovered the same insight that the Ken, Brian, et al, figured out 30 years ago with Unix. What DNS records *really* need to be encoded in binary? Thirty years after Unix was created, what situation is parsing a text record *so* time critical that a binary encoding is justified? Even though binary records *really* don't decrease the size of the DNS packets significantly, if want to reduce the size of DNS packets, figure out a way of gzipping them the way you can gzip html files. Things should be kept as simple as possible, but no simpler.[*] -wayne [*] Yes, I think SPF is pretty close to being as simple as possible. Seriously. I understand that many people might find it ironic that I, an SPF proponent, am arguing for TXT records, while John, a FSV proponent, is arguing for arbitrary complex description languages. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 11:04:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19131 for ; Sat, 11 Jun 2005 11:04:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dh7Tl-000EvT-Bw for namedroppers-data@psg.com; Sat, 11 Jun 2005 15:00:57 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Dh7Tk-000Ev8-Lf for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 15:00:56 +0000 Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j5BF0t4m007798 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 11 Jun 2005 08:00:56 -0700 Subject: Re: more thoughts on a set of TXT record clones From: Douglas Otis To: IETF DNSEXT WG In-Reply-To: References: Content-Type: text/plain Date: Sat, 11 Jun 2005 08:00:54 -0700 Message-Id: <1118502055.11344.47.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2005-06-10 at 18:43 -0500, wayne wrote: > > First, the magic number should be restricted to be exactly the first > substring in the TXT record. The TXT clone record could have any > number of strings, but the first is reserved for being the magic > number. > > Secondly, instead of letting people choose which TXT clone to use, we > should hash the magic number down into the set size. This would > reduce the chances of many people picking "easy to remember" numbers, > and would reduce the amount of information that people have to enter. Without different prefixes, collisions will risk exceeding a response size. This would be more of a problem for SPF or any new key scheme with typically large RRs. Overloading is less of a problem when the RR is small. The idea of using XML increases the size of the RR type for SPF by another 20%, making size more of an issue. When dealing with large RRs, get a number for the application. Nothing is gained by encouraging use of potentially large overlaid RRs. To reduce the size, it also makes sense to convert text to a binary definition. For SPF, some have suggested compression. The problem faced in MARID concerning new RRs was push-back by Microsoft claiming they use pre-canned RPC to their firewall for DNS. A new RR type must be compelling enough to be accepted in service release. Lumping together new TXT records (to codify wasteful text) would be less useful than finding a solution where Microsoft uses RFC3597 in their scheme. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 17:53:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18489 for ; Sat, 11 Jun 2005 17:53:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhDqn-0004yj-2W for namedroppers-data@psg.com; Sat, 11 Jun 2005 21:49:09 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DhDqm-0004yD-9s for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 21:49:08 +0000 Received: (qmail 7588 invoked by uid 100); 11 Jun 2005 21:49:03 -0000 Date: 11 Jun 2005 21:49:03 -0000 Message-ID: <20050611214903.7587.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Indeed. And it isn't just NAPTR that is being overloaded. Anti-spam >DNSBLs have long overload A records in order to get a bit (or >sometimes a few bits) for flags. The SPF system codifies this >practice with the exists: mechanism, but I haven't heard any >complaints about this overloading the meaning of A records by SPF. >The CSV system overloads SRV records. I would say that DNSBLs and CSV reuse other record types, rather than overloading them. The important difference is that they have their own namespaces. Any A record returned from 1.2.3.4.somednsbl.org means the same thing, this IP is in this DNSBL. Wildcards work the way you'd want, and you can list a /24 witn *.2.3.4.somednsbl.org. Similarly, the SRV record you get back from _client.smtp.example.org is always a CSV record. Wildcards don't work, but that's a problem with all SRV records. A simple way to look at it is to say that the combination of the domain name and the record type identifies the data you want. If you do a lookup and you get something back, that's definitely the data you want. With TXT or TXT99 or whatever, you have to look inside the record to see what kind it is, and that's the problem. The data you get back might be what you want, and might be something completely irrelevant. R's, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 17:53:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18507 for ; Sat, 11 Jun 2005 17:53:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhDqm-0004yd-QU for namedroppers-data@psg.com; Sat, 11 Jun 2005 21:49:08 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DhDqj-0004vp-U9 for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 21:49:06 +0000 Received: (qmail 7588 invoked by uid 100); 11 Jun 2005 21:49:03 -0000 Date: 11 Jun 2005 21:49:03 -0000 Message-ID: <20050611214903.7587.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Indeed. And it isn't just NAPTR that is being overloaded. Anti-spam >DNSBLs have long overload A records in order to get a bit (or >sometimes a few bits) for flags. The SPF system codifies this >practice with the exists: mechanism, but I haven't heard any >complaints about this overloading the meaning of A records by SPF. >The CSV system overloads SRV records. I would say that DNSBLs and CSV reuse other record types, rather than overloading them. The important difference is that they have their own namespaces. Any A record returned from 1.2.3.4.somednsbl.org means the same thing, this IP is in this DNSBL. Wildcards work the way you'd want, and you can list a /24 witn *.2.3.4.somednsbl.org. Similarly, the SRV record you get back from _client.smtp.example.org is always a CSV record. Wildcards don't work, but that's a problem with all SRV records. A simple way to look at it is to say that the combination of the domain name and the record type identifies the data you want. If you do a lookup and you get something back, that's definitely the data you want. With TXT or TXT99 or whatever, you have to look inside the record to see what kind it is, and that's the problem. The data you get back might be what you want, and might be something completely irrelevant. R's, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 18:07:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19447 for ; Sat, 11 Jun 2005 18:07:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhE6D-0007X6-Tk for namedroppers-data@psg.com; Sat, 11 Jun 2005 22:05:05 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DhE6B-0007VQ-1b for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 22:05:03 +0000 Received: (qmail 17395 invoked by uid 100); 11 Jun 2005 22:05:02 -0000 Date: 11 Jun 2005 22:05:02 -0000 Message-ID: <20050611220502.17394.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: more thoughts on a set of TXT record clones In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> And it's just syntactic sugar. Any software that's going to handle >> new RR's has to do what RFC3597 says and handle \# for RRs that don't >> have any other format. This just makes the new types easier for >> humans to read or write. > >Hex is not much easier for humans to read and write than binary. Uh, this is not news. >> # oh, look, it's a FOOB record, scruffle around on the web, find a >> # suitable 497-foob.xml file, stick it in the directory where dig and >> # friends look for them > >Is this "scruffling around on the web" going to be done automatically? Not on any system that I run. >If not, I don't see any real advantages to just downloading updated >version of dig and friends. The crucial difference is that updated versions of dig and friends do not exist. > And by "friends", you are going to have to include a heck of a lot > of GUIs and webforms. Yeah, that's my point. The current situation where you have to patch a vast list of programs each time you add a new RR means that in practice the programs don't get patched and there's no new RRs. That's why I want a config file that doesn't require writing new C code. >In either case, you have now opened up the wonderful world of record >descriptions that either intentionally, or accidentally, trigger bugs >in dig and friend. I think you are imagining a much more complex description language than I am. I'm thinking of something that can describe a fixed list of fields of a small known set of types, perhaps with a special case for repeated fields at the end. That's it. The description of an SPF record would be that it's a repeated list of strings. If you thought that it would attempt to describe the syntax of the strings that are allowed inside an SPF record, I agree that would be nuts. XML is overkill for this kind of description by about two orders of magnitude, but since there are widely deployed tools to publish and parse XML already, I think it's easier to use them than to invent yet another special purpose language. (Well, actually, the special purpose language would be described by a DTD.) >How much do you really think is being saved by using binary encoded >DNS records? In terms of record size, nothing. In terms of code complexity in clients, not enough to be a big deal. The problem is the overloading of multiple kinds of data into TXT, not the bit encoding within the record. I would have thought that was obvious from the previous discussion on this topic. >[*] Yes, I think SPF is pretty close to being as simple as possible. We'll have to agree to disagree rather violently there, particularly in view of the vast number of published SPF records that are just plain wrong. R's, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 11 18:08:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19625 for ; Sat, 11 Jun 2005 18:08:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhE6H-0007Xy-Sx for namedroppers-data@psg.com; Sat, 11 Jun 2005 22:05:09 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DhE6G-0007XZ-7S for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 22:05:08 +0000 Received: (qmail 17395 invoked by uid 100); 11 Jun 2005 22:05:02 -0000 Date: 11 Jun 2005 22:05:02 -0000 Message-ID: <20050611220502.17394.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: more thoughts on a set of TXT record clones In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: namedroppers@ops.ietf.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> And it's just syntactic sugar. Any software that's going to handle >> new RR's has to do what RFC3597 says and handle \# for RRs that don't >> have any other format. This just makes the new types easier for >> humans to read or write. > >Hex is not much easier for humans to read and write than binary. Uh, this is not news. >> # oh, look, it's a FOOB record, scruffle around on the web, find a >> # suitable 497-foob.xml file, stick it in the directory where dig and >> # friends look for them > >Is this "scruffling around on the web" going to be done automatically? Not on any system that I run. >If not, I don't see any real advantages to just downloading updated >version of dig and friends. The crucial difference is that updated versions of dig and friends do not exist. > And by "friends", you are going to have to include a heck of a lot > of GUIs and webforms. Yeah, that's my point. The current situation where you have to patch a vast list of programs each time you add a new RR means that in practice the programs don't get patched and there's no new RRs. That's why I want a config file that doesn't require writing new C code. >In either case, you have now opened up the wonderful world of record >descriptions that either intentionally, or accidentally, trigger bugs >in dig and friend. I think you are imagining a much more complex description language than I am. I'm thinking of something that can describe a fixed list of fields of a small known set of types, perhaps with a special case for repeated fields at the end. That's it. The description of an SPF record would be that it's a repeated list of strings. If you thought that it would attempt to describe the syntax of the strings that are allowed inside an SPF record, I agree that would be nuts. XML is overkill for this kind of description by about two orders of magnitude, but since there are widely deployed tools to publish and parse XML already, I think it's easier to use them than to invent yet another special purpose language. (Well, actually, the special purpose language would be described by a DTD.) >How much do you really think is being saved by using binary encoded >DNS records? In terms of record size, nothing. In terms of code complexity in clients, not enough to be a big deal. The problem is the overloading of multiple kinds of data into TXT, not the bit encoding within the record. I would have thought that was obvious from the previous discussion on this topic. >[*] Yes, I think SPF is pretty close to being as simple as possible. We'll have to agree to disagree rather violently there, particularly in view of the vast number of published SPF records that are just plain wrong. R's, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From JuliaLooney@asian-hardcore.co.uk Sat Jun 11 21:05:12 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26282 for ; Sat, 11 Jun 2005 21:05:11 -0400 (EDT) Received: from [69.62.139.22] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DhHGV-0002ea-2H for dnsext-archive@ietf.org; Sat, 11 Jun 2005 21:27:56 -0400 Received: from Yel@localhost by 6KTf.int (8.11.6/8.11.6); Sat, 11 Jun 2005 17:55:47 -0500 Message-ID: <2X5Ja7WWooNRPzr2o2wx@yorkish.com> From: "Neal Tillman" Reply-To: "Neal Tillman" To: dnsext-archive@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 AutoCAD Date: Sun, 12 Jun 2005 00:53:47 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JuliaLooney@asian-hardcore.co.uk Content-Type: multipart/mixed; boundary="--H0g7ElOlPQiO4KPgaig" X-Spam-Score: 19.6 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 S4Z ----H0g7ElOlPQiO4KPgaig Content-Type: text/html; Content-Transfer-Encoding: quoted-printable C
Opt-in Email Special Offer &n= bsp;   unsubscribe me
= <= /tbody>
<= td width=3D5 bgcolor=3D#000080>
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
= <= /tr>=

 = ON SALE NOW!

 1 Of= fice Pro 2003
 2 Windows= XP Pro
 3 Adobe Creat= ive Suite Premium
 4 Nort= on Antivirus 2005
 5 F= lash MX 2004
 6 Corel D= raw 12
 7 Adobe Acrobat= 7.0
 8 Windows 2003 S= erver
 9 Alias Maya 6 = Wavefrt
 10 Adobe Prem= iere
  See more by = this manufacturer
   Microsoft
  = Apple Software
  Customers also bought
   t= hese other items...



Microsoft Office Prof= essional Edition *2003*
Microsoft <= /span>
Choose:
 <= /td>
= = =
List Price:$899.0= 0
Price:$69.99
You Save:$830.01 (92%)



Availability: Available for = INSTANT download!
Coupon Code: ISe229
Media: CD-ROM = / Download

System requirements  |  Accessories  |  Other Ve= rsions

Features: =

  • Analyze and manage busine= ss information using Access databases
  • Exchange data with other systems using enhanced XML technology <= /font>
  • Control information sharing r= ules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters and printed marketi= ng materials
  • More than 20 pr= eformatted business reports
Sales Rank: #1
Shipping: International/US or = via instant download
Date Coupon Expires: June 30th, 2005
<= /span>Average Customer Review: 3D"5 Based on= 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longho= rn Edition
Mi= crosoft
Choo= se: 

List Price:$279.00
Price:$49.99<= /b>
You Save:$229.01 (85= %)



Availability: Av= ailable for INSTANT download!
Coupon Code: ISe229
Media:= CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:=

  • Designed f= or businesses of all sizes
  • M= anage digital pictures, music, video, DVDs, and more
  • More security with the ability to encrypt files a= nd folders
  • Built-in voice, v= ideo, and instant messaging support
  • Integration with Windows servers and management solutions <= /li>

Sales Rank: #2
S= hipping: International/US or via instant download
Date Coupon E= xpires: June 30th, 2005
Average Custo= mer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9.0<= br> Adobe
=
Choose:
 

List Price: $599.00
Price:$69.99
You Save:$529.01 (90%)



Availabi= lity: Available for INSTANT download!
Coupon Code: ISe229 Media: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features= :

  • Customized workspace; save personalized workspace and tool settings; cre= ate customized shortcuts
  • Un= paralleled efficiency--automate production tasks with built-in or customiz= ed scripts
  • Improved file man= agement, new design possibilities, and a more intuitive way to create for = the Web
  • Support for 16-bit i= mages, digital camera raw data, and non-square pixels
  • Create or modify photos using painting, drawing,= and retouching tools

Sal= es Rank: #3
Shipping: International/US or via = instant download
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D= Based on 498 r= eviews. Write a review.

----H0g7ElOlPQiO4KPgaig-- From TerriCote@spiraltail.com Sun Jun 12 11:29:09 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13978; Sun, 12 Jun 2005 11:29:09 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhUkh-0006pD-Mw; Sun, 12 Jun 2005 11:52:02 -0400 Received: from cm222-167-8-92.hkcable.com.hk ([222.167.8.92]) by mx2.foretec.com with smtp (Exim 4.24) id 1DhUOM-0007U2-Vn; Sun, 12 Jun 2005 11:29:04 -0400 Received: from 5CqF@localhost by TjK.int (8.11.6/8.11.6); Sun, 12 Jun 2005 17:32:28 +0100 Message-ID: From: "Sally Nussbaum" Reply-To: "Sally Nussbaum" To: 15@ietf.org, diptel@ietf.org, sip-admin@ietf.org, ec@ietf.org, dnsext-archive@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 Symantec Date: Sun, 12 Jun 2005 14:28:28 -0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: TerriCote@spiraltail.com Content-Type: multipart/mixed; boundary="--nupUkw1jPppWZptO" X-Spam-Score: 4.2 (++++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 iRY1 ----nupUkw1jPppWZptO Content-Type: text/html; Content-Transfer-Encoding: quoted-printable J
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
5

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Window= s XP Pro
 3 Adobe Cre= ative Suite Premium
 4 Norton Antivirus 2005
  Flash MX 2004
 6 Corel Draw 12
 7 Adobe = Acrobat 7.0
 8 Window= s 2003 Server
 9 Alias = Maya 6 Wavefrt
 10 Adobe = Premiere
  See more= by this manufacturer
 <= /td>  Microsoft<= /td>
   Apple Software
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...
<= /td>



Microsoft Offi= ce Professional Edition *2003*
Microsoft
Choose= :
&= nbsp;
=
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze= and manage business information using Access databases
  • Exchange data with other systems using enhance= d XML technology
  • Control inf= ormation sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters a= nd printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: Int= ernational/US or via instant download
Date Coupon Expires: June= 30th, 2005
Average Customer Review: = 3D"5 Based on 1,768 reviews. Write a= review.
Microsoft Windows XP Professional or = Longhorn Edition
Microsoft =
Choose:
<= /td> <= /a>

List Price:$279.00
Price:$49.99
You Save:<= /td>$229.01 (= 85%)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Desi= gned for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt f= iles and folders
  • Built-in vo= ice, video, and instant messaging support
  • <= font size=3D1>Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Co= upon Expires: June 30th, 2005
Average= Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9= 0
Adobe=
Choose:=
 

List Price:<= /td> $599.00
Price:$69.99
You Save:$529.01 (90%)



= Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |&nb= sp; Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.=

----nupUkw1jPppWZptO-- From owner-namedroppers@ops.ietf.org Sun Jun 12 14:16:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24700 for ; Sun, 12 Jun 2005 14:16:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhWsl-000JoS-RM for namedroppers-data@psg.com; Sun, 12 Jun 2005 18:08:27 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DhWsk-000Jo3-1V for namedroppers@ops.ietf.org; Sun, 12 Jun 2005 18:08:26 +0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2005 20:08:25 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5CI8H7H006195; Sun, 12 Jun 2005 20:08:20 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 12 Jun 2005 20:08:19 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 12 Jun 2005 20:08:19 +0200 In-Reply-To: <009101c56e63$0e82fbd0$8217a8c0@arport2v> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> Mime-Version: 1.0 (Apple Message framework v730) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> Cc: "John Levine" , , Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: draft-iab-dns-choices-02.txt comments Date: Sun, 12 Jun 2005 20:08:14 +0200 To: Anders Rundgren X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 12 Jun 2005 18:08:19.0283 (UTC) FILETIME=[B675DA30:01C56F79] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jun 11, 2005, at 10:53, Anders Rundgren wrote: > That the author of DNS-CHOICES did not invent a new RR > for his famous ENUM stuff but overloaded NAPTR is a sure > sign of that we need to do a reality check. I wrote the draft specifically with experience from ENUM in mind. Reusing NAPTR is one of the big problems with ENUM. I would never do it again, and I don't want anyone else to make the same mistake. But, you should also know that at the day of ENUM origin (1998) the view in the DNS community was that addition of a new RR (i.e. handling of unknown RR types) was hard. It is not anymore. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 12 14:47:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26838 for ; Sun, 12 Jun 2005 14:47:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhXRn-000Mmv-6J for namedroppers-data@psg.com; Sun, 12 Jun 2005 18:44:39 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DhXRm-000Mmi-Eq for namedroppers@ops.ietf.org; Sun, 12 Jun 2005 18:44:38 +0000 Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j5CIiXkn014523 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 12 Jun 2005 11:44:33 -0700 Subject: Re: more thoughts on a set of TXT record clones From: Douglas Otis To: John Levine Cc: namedroppers@ops.ietf.org In-Reply-To: <20050611220502.17394.qmail@xuxa.iecc.com> References: <20050611220502.17394.qmail@xuxa.iecc.com> Content-Type: text/plain Date: Sun, 12 Jun 2005 11:44:32 -0700 Message-Id: <1118601872.2160.83.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2005-06-11 at 22:05 +0000, John Levine wrote: > I think you are imagining a much more complex description language > than I am. I'm thinking of something that can describe a fixed list > of fields of a small known set of types, perhaps with a special case > for repeated fields at the end. That's it. The description of an SPF > record would be that it's a repeated list of strings. If you thought > that it would attempt to describe the syntax of the strings that are > allowed inside an SPF record, I agree that would be nuts. > > XML is overkill for this kind of description by about two orders of > magnitude, but since there are widely deployed tools to publish and > parse XML already, I think it's easier to use them than to invent > yet another special purpose language. (Well, actually, the special > purpose language would be described by a DTD.) RFC3597 standardizes a text representation handled by the various DNS tools to bridge between the text entry of unknown structures into their true binary form. A token of '\#', followed by an unsigned decimal integer byte length, declares the use of this convention. It represents a binary format with two hexadecimal characters for each actual byte. This mirrors a very common convention of a binary Tag/Length/Value (TLV) format. As most problems occur with ill-formed data, adding a checksum would also be good practice. Defining a new RR type, that comprises a complex structure, should be a matter of defining a byte Tag value list for this RR type. This list would enable an extensible TLV format by defining the content of each tagged element. The tools for this new RR type should generate text compatible with RFC3597 text representations. Cut and paste this RFC3597 format between these tools that specifically generate or interpret the binary information between the human friendly forms. DNS is not well suited for XML. The benefits derived from DNS relate largely to speed and efficiency. DNS is a translation between a human friendly name into a machine friendly response. By machine friendly, this is largely a matter of size. Speed depends upon this information being cached in dynamic memory, rather than hard storage. Here size matters. XML on the other hand is designed to be human friendly. As we have seen, humans make mistakes and need tools anyway when generating complex structures. It is going down a slippery slope to suggest there is little difference between data structures suitable for web pages, and that used for DNS RRs. This strikes me as a bad idea, although I concede your point about these text parsers being ubiquitous. One should still use generation tools which will result in the same cut and paste operation. TLV for binary structures does not represents an obstacle at all, and why this method is so widely used. XML allows far greater complexity, but this is not warranted. The path registration scheme being utilized by SPF already demands a minimum of more than one hundred subsequent references to other DNS records. This already creates a significant size concern. Without proficient use of often overly broad CIDR notation, path registration can easily exceed even these limits. Having a publication process made easy, while ignoring the aspects of reading overlooks the value of DNS. If the new RR type becomes popular, and people want to view the content of these structures, conversion tools will merge with DNS utilities, perhaps by way of simple scripts. DNS should not be seen as a UDP version of HTTP. As was the conclusion of a lengthy debate in MARID, XML will add 20% in size to an already overly large amount of data, from the perspective of DNS. Of course, this would not be true for HTTP. The paradigms are vastly different, hard storage caching of unlimited record sizes exchanged using TCP. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 12 17:16:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11631 for ; Sun, 12 Jun 2005 17:16:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhZkM-000AAb-6X for namedroppers-data@psg.com; Sun, 12 Jun 2005 21:11:58 +0000 Received: from [208.31.42.38] (helo=tom.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DhZkJ-000AAK-6A for namedroppers@ops.ietf.org; Sun, 12 Jun 2005 21:11:55 +0000 Received: (qmail 13188 invoked from network); 12 Jun 2005 21:11:51 -0000 Received: (ofmipd 127.0.0.1); 12 Jun 2005 21:11:29 -0000 Date: 12 Jun 2005 17:11:51 -0400 Message-ID: From: "John R Levine" To: "=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=" Cc: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > the view in the DNS community was that addition of a new RR (i.e. > handling of unknown RR types) was hard. > > It is not anymore. Considering how hard it is now, it must have been truly stupefying then. In any event, it's pretty clear that we need to start assigning new RRs to new applications to create the demand for upgrades to DNS software that can use it. Maybe as a band-aid we could use temporary proxies that accept encoded TXT requests and fetch the real data. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 12 20:17:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22515 for ; Sun, 12 Jun 2005 20:17:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhcYX-00004i-7h for namedroppers-data@psg.com; Mon, 13 Jun 2005 00:11:57 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhcYW-00004U-3H for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 00:11:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A297013925 for ; Mon, 13 Jun 2005 00:11:55 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "12 Jun 2005 17:11:51 -0400." References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 13 Jun 2005 00:11:55 +0000 Message-Id: <20050613001155.A297013925@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > the view in the DNS community was that addition of a new RR (i.e. > > handling of unknown RR types) was hard. > > > > It is not anymore. > > Considering how hard it is now, it must have been truly stupefying then. adding an rrtype isn't all that hard. there's an experimental numbering space, and also, BIND (even late model bind8) can handle opaque rrtypes including transferring and querying and even updating them. the difficulty SPF is encountering is not related to the new rrtypes they want to propose, but rather that community's insistence that the size of their installed base means they shouldn't be subject to ietf consensus. > In any event, it's pretty clear that we need to start assigning new RRs to > new applications to create the demand for upgrades to DNS software that > can use it. this is a fine approach. any middlebox or authority server who upgrades to late-model bind8/bind9, or nominum ans/cns, or microsoft's dns server, will become friendly to rrtypes that did not exist at compile time, and that upgrade would be a fine thing to push for, for a variety of reasons. however, new rrtypes are almost certainly the wrong way to solve most of the problems i've seen discussed on this thread. what we need is fixed format rrtypes (like we have, other than TXT or various self-describing proposals like XML or ASN1), and useful subclassing for application names. the fact that RP and MX have the same rdata format is a botch. there ought to be one rrtype for "has a 16-bit unsigned number, and a domain name" and the application should be a subdomain (RP._app.VIX.COM, MX._app.VIX.COM, or even responsible_person._app.VIX.COM and mail_exchanger._app.VIX.COM). (note that to get this working, we'll need nonterminal wildcards, and we'll need to shift the wildcard processing from the authority servers to the endsystem clients.) > Maybe as a band-aid we could use temporary proxies that accept encoded TXT > requests and fetch the real data. that turns out to be a bad idea. in dns, only the authority can synthesize, which is completely nonhelpful in the case you're describing. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 12 21:30:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26765 for ; Sun, 12 Jun 2005 21:30:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dhdiy-0006es-5k for namedroppers-data@psg.com; Mon, 13 Jun 2005 01:26:48 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dhdiw-0006ec-AD for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 01:26:46 +0000 Received: from [10.29.41.119] (gmp-inet7-152.gmpexpress.net [72.9.7.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by goose.ehsco.com (Postfix ) with ESMTP id DFAC820E0B for ; Sun, 12 Jun 2005 20:26:43 -0500 (CDT) Message-ID: <42ACE0DB.4020101@ehsco.com> Date: Sun, 12 Jun 2005 21:26:51 -0400 From: "Eric A. Hall" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> In-Reply-To: <20050613001155.A297013925@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,MISSING_HEADERS autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 6/12/2005 8:11 PM, Paul Vixie wrote: > there ought to be one rrtype for "has a 16-bit unsigned number, and a > domain name" and the application should be a subdomain > (RP._app.VIX.COM, MX._app.VIX.COM, or even > responsible_person._app.VIX.COM and mail_exchanger._app.VIX.COM). I agree that there should be well-defined data-types (a four-byte "addr" record wouldd be considerably better than the 17-byte sequence of textual octets we have now), but I disagree with the rest of your proposal for sevearl reasons. Biggest problem is that the namespace is infinitely wide but it's not infinitely deep, and the use of prefixes in the namespace is a negative wrt the shallowness of the namespace. Second is that code values require less computation. But we absolutely need strong data-typing. It's always kind of seemed silly to me that the most structured of application protocols is also the one that has the least amount of formal typing. -- 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. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 03:08:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13201 for ; Mon, 13 Jun 2005 03:08:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhiyL-000Bx6-NL for namedroppers-data@psg.com; Mon, 13 Jun 2005 07:03:01 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DhiyK-000Bwd-Jm for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 07:03:00 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 95324246B2; Mon, 13 Jun 2005 09:02:57 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 555F0240BB for ; Mon, 13 Jun 2005 09:02:56 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id j5D72tUU008843 for ; Mon, 13 Jun 2005 09:02:55 +0200 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id j5D72ttE021398 for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 09:02:55 +0200 Received: from [66.163.169.227] (helo=smtp107.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dh3c0-000FDR-Tl for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 10:53:13 +0000 Received: (qmail 58270 invoked from network); 11 Jun 2005 10:53:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Message-Id:X-Sender:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type; b=CM/zS1zHfHrdjyMulMKwE50rRqqUawqoDzWuKo7Fv7qnao7gzhjp6Qk4eNXQpQV3LmT3sD2e3DhGwU00suuhFzer2vrfcbPBP1ODa5It/lEO0hJYUBIKz1dFmUj9iD0euZPYKwBvEZV1C8WyMpyz77KhyLaUvhvj4zWu1WgrNeA= ; Received: from unknown (HELO phred.yahoo.com) (david?macquigg@216.183.69.45 with login) by smtp107.mail.sc5.yahoo.com with SMTP; 11 Jun 2005 10:53:12 -0000 Message-Id: <5.2.1.1.0.20050611034407.03495358@pop.mail.yahoo.com> X-Sender: david_macquigg@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 11 Jun 2005 03:54:08 -0700 To: John Levine , namedroppers@ops.ietf.org From: David MacQuigg Subject: Re: more thoughts on a set of TXT record clones Cc: paul@vix.com In-Reply-To: <20050611070031.16015.qmail@xuxa.iecc.com> References: <20050611041728.46A4013925@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: BAYES_50 X-RIPE-Spam-Status: U 0.403273 / 0.0 X-RIPE-Signature: b588a183c2e017b896a56b3f8ddd6755 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: This post needed manual approval. Either it was posted by a non-subscribed address, or the posting was too large ( > 20000bytes ) for this list. With the massive amount of spam, it is easy to miss and therefore delete posts that need manual approval. Please use your subscribed address to post, or shorten your postings by using links instead of attachments. ] At 07:00 AM 6/11/2005 +0000, John Levine wrote: > >it's because there will always be devices who hope for simplicity in what > >they have to receive and parse and store and forward. > >Of course. But it strikes me that we're only talking about the bits >of DNS software that translate between RR's and zone-file-ese and have >to display or read representations of arbitrary RR types. Exactly. Maybe we could even define a default format for these displays - similar to what is used in bvi, hex on the left, ASCII on the right. This would involve no special-purpose activeX plugins. -- Dave ************************************************************ * * David MacQuigg, PhD email: david_macquigg at yahoo.com * * * IC Design Engineer phone: USA 520-721-4583 * * * * Analog Design Methodologies * * * * 9320 East Mikelyn Lane * * * * VRS Consulting, P.C. Tucson, Arizona 85710 * ************************************************************ * -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 05:16:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22677 for ; Mon, 13 Jun 2005 05:16:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dhkzd-000Or3-3j for namedroppers-data@psg.com; Mon, 13 Jun 2005 09:12:29 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dhkza-000Oqj-0p for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 09:12:26 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 82F92C2DA6; Mon, 13 Jun 2005 10:12:24 +0100 (BST) Date: Mon, 13 Jun 2005 10:12:23 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: <6E5603E8D6D2321E4342E311@[192.168.100.25]> In-Reply-To: <20050613001155.A297013925@sa.vix.com> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 13 June 2005 00:11 +0000 Paul Vixie wrote: > the fact that RP and MX have the same rdata format is a botch. there > ought to be one rrtype for "has a 16-bit unsigned number, and a domain > name" and the application should be a subdomain (RP._app.VIX.COM, > MX._app.VIX.COM, or even responsible_person._app.VIX.COM and > mail_exchanger._app.VIX.COM). > > (note that to get this working, we'll need nonterminal wildcards, and > we'll need to shift the wildcard processing from the authority servers to > the endsystem clients.) That sounds an awful lot more pain than either * one new RR type per _app; or * one new RR type in total, with _app in the data in sensible form, and handle large queries right for not very much gain. Either of the above work with "any middlebox or authority server who upgrades to late-model bind8/bind9, or nominum ans/cns, or microsoft's dns server," (your words!) right now and don't require reinventing wildcards. If you are going to rewrite the matching algorithm, I would suggest looking at the whole thing as a 4-Tuple (with the additional field having an RRType dependent meaning) rather than a 3-Tuple might be worth looking at. A 4-Tuple query with the additional field set to "any" would have the same meaning as a current 3-tuple query. That, after all, is "doing it right" (which is presumably what you are trying to achieve with your proposal). How's that for invasive? :-) Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 09:00:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08112 for ; Mon, 13 Jun 2005 09:00:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhoUi-000LCq-TG for namedroppers-data@psg.com; Mon, 13 Jun 2005 12:56:48 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhoUh-000LCZ-T8 for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 12:56:48 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5DCuJ0R091719; Mon, 13 Jun 2005 08:56:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> Date: Mon, 13 Jun 2005 08:46:52 -0400 To: "william(at)elan.net" From: Edward Lewis Subject: RE: draft-iab-dns-choices-02.txt comments Cc: Eastlake III Donald-LDE008 , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:42 -0700 6/10/05, william(at)elan.net wrote: >On Fri, 10 Jun 2005, Eastlake III Donald-LDE008 wrote: >> >> Specification Required - Values and their meaning must be >> documented in an RFC or other permanent and readily available >> reference, in sufficient detail so that interoperability >> between independent implementations is possible. >> >> Isn't getting an RR Type based on just publicly documneting its >>use liberal enough? > >I've not seen any RR types allocated except though IETF consensus and RFC. Prior to RFC 2929, one example, to pick a flawed one, was the OPT RR. The OPT RR process was flawed in that it received the wrong number. (It was thought that it would have a number with the meta-types, instead it got #41.) The problem was that no one informed IANA that the OPT record deserved a special type number. This mishap was one reason for the production of RFC 2929. As far as "isn't ... just publicly documenting" in an RFC or other permanent reference "liberal enough?" I would say no. These are the type codes defined by documents post RFC 2929: APL 42 APL [RFC3123] DS 43 Delegation Signer [RFC3658] SSHFP 44 SSH Key Fingerprint [RFC-ietf-secsh-dns-05.txt] IPSECKEY 45 IPSECKEY [RFC-ietf-ipseckey-rr-11.txt] RRSIG 46 RRSIG [RFC3755] NSEC 47 NSEC [RFC3755] DNSKEY 48 DNSKEY [RFC3755] Note that two of them are in pending RFC's, which kind of violates the instructions in RFC 2929. Some may say that these are "special cases" and the rules ought to be bent for these instances. I'd agree, but when we start with unwritten bending of the rules, it's a sign we've build a bad bureaucracy. Note that all of the types listed also originated within the DNSEXT WG. The SSH and IPSEK key work did come from other WG's but that was not until the work was expelled in December 2001. (RFC 2929 is dated September 2000.) Since RFC 2929, no application-driven RR type code number has been assigned by IANA. I would say that this is a sign that the policy is not liberal enough. PS - For an added bit of irony, the numbers preceding that list are 41 (the incorrectly assigned OPT RR) and 40, the SINK record. There is no permanently archived document describing the SINK record. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 09:00:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08131 for ; Mon, 13 Jun 2005 09:00:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhoUV-000L9D-27 for namedroppers-data@psg.com; Mon, 13 Jun 2005 12:56:35 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhoUR-000L8h-TN for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 12:56:32 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5DCuJ0T091719; Mon, 13 Jun 2005 08:56:24 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20050610164846.DA199418D@thrintun.hactrn.net> Date: Mon, 13 Jun 2005 08:56:21 -0400 To: "IETF DNSEXT WG" From: Edward Lewis Subject: Re: draft-iab-dns-choices-02.txt comments: host names vs domain names Cc: "IETF DNSEXT WG" , wayne Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:39 -0500 6/10/05, wayne wrote: >In <20050610164846.DA199418D@thrintun.hactrn.net> Rob Austein > writes: > >> At Thu, 09 Jun 2005 08:03:03 -0500, 'wayne' wrote: >>> >>> So, in order to help this educational process, can someone give a >>> short paragraph that explains the differences between host names and >>> domain names, why the allowed characterset is different between the >>> two and when you should use one or the other? >> >> Really short answer: see RFC 1034 3.5 and RFC 1035 2.3.1. >> >> Slightly longer answer: [...] > >Thanks for the description. I understood it and it matches my >understanding of the difference between a hostname and a domain name, >but suspect that it would go right over the head of 99.9% of all >domain owners. Heck, I suspect that it too many folks that run DNS >hosting services wouldn't immediately understand it without reading >the RFCs and such. In 1998 I taught Intro to Networking and had a student that already owned his own successful hosting service. At the end of the class he thanked me saying that he didn't expect to learn anything but instead now understood what all the "knobs" were for - like what an MTU was, etc. It's always going to be that way. There are a lot of service providers that don't fully comprehend the technology they use. How many cab drivers could assemble a carburetor blindfolded? (Even if no car built recently has one?) This is one of the eternal problems. There will always be someone who thinks there is a simple solution who has only an incomplete understanding of the technology. This tests the patience of both those who do have a complete understanding of the technology and an incomplete understanding of the problem space and those for whom the vice versa is true. >My point remains that one problem with _prefix tricks is that many >people can't create them due to software that restricts domain names >to hostname characters. But, maybe I'm wrong. If you think so, let >me know. > >I think that dns-choices should mention this problem. I agree with this. The issue in many cases is that "X is not a problem for DNS because DNS software is cool" and "X is a problem for the users [app writers] of DNS because the software surrounding the DNS is a problem." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 09:23:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10453 for ; Mon, 13 Jun 2005 09:23:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhorS-000OA0-OQ for namedroppers-data@psg.com; Mon, 13 Jun 2005 13:20:18 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhorS-000O9m-2v for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 13:20:18 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A740913925 for ; Mon, 13 Jun 2005 13:20:17 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Mon, 13 Jun 2005 10:12:23 +0100." <6E5603E8D6D2321E4342E311@[192.168.100.25]> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 13 Jun 2005 13:20:17 +0000 Message-Id: <20050613132017.A740913925@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > mail_exchanger._app.VIX.COM). > ... > > That sounds an awful lot more pain than either > * one new RR type per _app; or total number of rdata parsers would go up; this is expensive. > * one new RR type in total, with _app in the data in sensible form, and > handle large queries right complexity of that one rdata parser would be high; this is expensive. > for not very much gain. as a one-time implementor, i took the pain/gain tradeoff directly into account when making that proposal. > Either of the above work with "any middlebox or authority server who > upgrades to late-model bind8/bind9, or nominum ans/cns, or microsoft's > dns server," (your words!) right now i guess almost any rrtype related change can finally make that claim. yay! > and don't require reinventing wildcards. you're right. neither does this one. it would just be a kindness to the dnssec effort to move ALL synthesis to the requestor, in a backward compatible kind of way of course. > If you are going to rewrite the matching algorithm, I would suggest > looking at the whole thing as a 4-Tuple (with the additional field > having an RRType dependent meaning) rather than a 3-Tuple might be > worth looking at. A 4-Tuple query with the additional field set to > "any" would have the same meaning as a current 3-tuple query. That, > after all, is "doing it right" (which is presumably what you are > trying to achieve with your proposal). How's that for invasive? :-) the type-covered field in RRSIG functions effectively as a subtype, and when we were discussing it we didn't try to generalize it. very sad, but not too late. if you think a subtype would be easier to shoehorn in than a subdomain, i'm listening. frankly, i'd like to have both, but i consider the subtype or any other change to the q-tuple to be even more violent than moving the synthesis processing would be. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 09:35:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12490 for ; Mon, 13 Jun 2005 09:35:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dhp46-000Pcl-KD for namedroppers-data@psg.com; Mon, 13 Jun 2005 13:33:22 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dhp44-000PcO-Sl for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 13:33:21 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id B5623C2DFD; Mon, 13 Jun 2005 14:33:19 +0100 (BST) Date: Mon, 13 Jun 2005 14:33:17 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: In-Reply-To: <20050613132017.A740913925@sa.vix.com> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, >> and don't require reinventing wildcards. > > you're right. neither does this one. I'm having imagination failure. How can your scheme work with traditional wildcards? (i.e. without rewriting the wildcard semantics). > the type-covered field in RRSIG functions effectively as a subtype, and > when we were discussing it we didn't try to generalize it. very sad, > but not too late. if you think a subtype would be easier to shoehorn > in than a subdomain, i'm listening. frankly, i'd like to have both, but > i consider the subtype or any other change to the q-tuple to be even > more violent than moving the synthesis processing would be. Agree - that's what I meant by invasive. But it is probably "the right thing to do" (tm). Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 09:55:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13887 for ; Mon, 13 Jun 2005 09:55:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhpMV-0001ny-T9 for namedroppers-data@psg.com; Mon, 13 Jun 2005 13:52:23 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhpMV-0001nk-5q for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 13:52:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C5DE2139B5 for ; Mon, 13 Jun 2005 13:52:22 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Mon, 13 Jun 2005 14:33:17 +0100." References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 13 Jun 2005 13:52:22 +0000 Message-Id: <20050613135222.C5DE2139B5@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > you're right. neither does this one. > > I'm having imagination failure. How can your scheme work with traditional > wildcards? (i.e. without rewriting the wildcard semantics). since noone is currently querying for names under _app.$DOMAIN, we have the opportunity to require multiple queries. therefore to simulate the effect of a nonterminal wildcard such as: mail_exchanger._app.**.VIX.COM. we can put in nodes of the form: mail_exchanger._app.VIX.COM. *.mail_exchanger._app.VIX.COM. and clients can be told that if they're looking for a mail_exchanger._app for a service name of FOO.VIX.COM, they should look up two DNS names: mail_exchange._app.FOO.VIX.COM. FOO.mail_exchange._app.VIX.COM. this is NOT AS CLEAN and relies heavily on negative caching, which is ill supported in the current dns ecosphere. but it would work using current wildcard semantics. i'd rather add nonterminal wildcards, move all wildcard and other synthesis to clients, and add subtypes. but that's a ten year project and we probably have a one month budget, just like always. > > the type-covered field in RRSIG functions effectively as a subtype, > > and when we were discussing it we didn't try to generalize it. very > > sad, but not too late. if you think a subtype would be easier to > > shoehorn in than a subdomain, i'm listening. frankly, i'd like to > > have both, but i consider the subtype or any other change to the > > q-tuple to be even more violent than moving the synthesis processing > > would be. > > Agree - that's what I meant by invasive. But it is probably "the right > thing to do" (tm). if we succeed in injecting some money and coherency into this field, using MODA and perhaps other efforts, then we could reasonably "do both". we all know that DNS could never have been designed under a regime like the current IETF, nor SMTP or NNTP or probably TCP or IP. i recommend that we work toward putting more boats in the water to see which ones really float, and that we put better boats in the water to get a better idea of "why". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 10:24:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17455 for ; Mon, 13 Jun 2005 10:24:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dhpod-0005Y2-Us for namedroppers-data@psg.com; Mon, 13 Jun 2005 14:21:27 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dhpoc-0005Xf-TY for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 14:21:27 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 399462435B; Mon, 13 Jun 2005 16:21:26 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5462F23FF3 for ; Mon, 13 Jun 2005 16:21:25 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j5DELPUU020419 for ; Mon, 13 Jun 2005 16:21:25 +0200 Date: Mon, 13 Jun 2005 16:21:25 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments Message-Id: <20050613162125.5ad12e39.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000000 / -5.9 X-RIPE-Signature: d54a29bbb6f7a52ff7f12e487bd3bede X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues. One of the arguments that is currently being used against trying to "design" a new RR for use with ones application, is that it is apparently difficult to get one's specification reviewed, processed and the typecode assigned. This should not be an argument. The DNSEXT working group has the following statement in its charter: The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. It is the intentention that the DNSEXT WG will review that: o The proposed RR does _not_ need special processing by DNS servers or clients. o Your RR does not use name compression for the domain names in the RDATA section. o Your RDATA specification is correct and unambiguous. o Your specification does not make unreasonable assumptions about the working of the DNS The group may give recommendations about the use of the DNS for the protocol of application. The DNSEXT WG is not supposed to review the protocol that uses the RR (but may sometimes be tempted). For a well written specification this review should not take more than a couple of weeks to a few months. The specification then follows normal IETF process and hits IETF last call. We, chairs, can, in cooperation with the document editors the shepherd the the process to speed up the review in the group and immediately after IETF last call get an IANA type code assignment. We hope to facilitate that the "two years get a type code" argument will be irrelevant. It is probably a good idea to document the process for this "fast track" above a bit more thorough then the above 4 bullet points. The rusulting document could update the assignment rules. I should mention that we are already trying to practice in this mode. Some RR specifications have passed the group and received some recommendations and review. Examples are SSHFP, IPSECKEY. I am not sure if the authors of these specifications are happy with the speed and quality of the feedback they received but I do not think the DNSEXT group was the bottle neck in getting an RR type assigned. Currently the NFS4ID RR proposal is following this route and deserves your review. -- Olaf Kolkman, Olafur Gudmundsson. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 10:26:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17613 for ; Mon, 13 Jun 2005 10:26:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhprF-0005rf-Pc for namedroppers-data@psg.com; Mon, 13 Jun 2005 14:24:09 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DhprC-0005qz-ID for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 14:24:06 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 01DE32435B; Mon, 13 Jun 2005 16:24:06 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CBAFA24334 for ; Mon, 13 Jun 2005 16:24:03 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j5DEO3UU021196 for ; Mon, 13 Jun 2005 16:24:03 +0200 Date: Mon, 13 Jun 2005 16:24:03 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Milestone reached: draft-ietf-dnsext-rfc2538bis-03 Message-Id: <20050613162403.35cf00df.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000268 / -5.9 X-RIPE-Signature: 221213bbc89a3db3ab977705e9250221 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, Today we submitted a request for publications of draft-ietf-dnsext-rfc2538bis-03 to the IESG (included for archival purposes below). We, and I am sure I speak for the WG as a whole, would like to acknowledge Simon for the thorough job he did on editing the document. Thanks for a job well done! -- Olaf and Olafur -- > Dear Margaret, > > > Hereby a request to publish the following document. > > Title : Storing Certificates in the Domain Name System (DNS) > Author(s) : S. Josefsson > Filename : draft-ietf-dnsext-rfc2538bis-03.txt > Pages : 14 > Date : 2005-6-10 > > It the intention to be "recycle" RFC2538 as proposed standard. > > > Below is the questionaire, please contact me if there are any > remaining questions. > > 1) Have the chairs personally reviewed this version of the ID and do > they believe this ID is sufficiently baked to forward to the IESG > for publication? > > The shepherding chair has reviewed the document. And believes the > document is ready for IESG submission. > > > 2) Has the document had adequate review from both key WG members and > key non-WG members? Do you have any concerns about the depth or > breadth of the reviews that have been performed? > > > The editor has solicited feedback from the openPGP working group and > from the PKIX WG. > See: > http://thread.gmane.org/gmane.ietf.openpgp/5458 > http://thread.gmane.org/gmane.ietf.x509/21349 > > Some feedback was received. > > > 3) Do you have concerns that the document needs more review from a > particular (broader) perspective (e.g., security, operational > complexity, someone familiar with AAA, etc.)? > > I cannot assess if the review by the above mentioned groups has been > thorough enough. On the other hand I do not have the concern that the > document needs more review. > > > 4) Do you have any specific concerns/issues with this document that > you believe the ADs and/or IESG should be aware of? For example, > perhaps you are uncomfortable with certain parts of the document, > or whether there really is a need for it, etc., but at the same > time these issues have been discussed in the WG and the WG has > indicated it wishes to advance the document anyway. > > > During the last call it was noted that the IANA registry for DNSSEC > algorithm identifiers does not have an "applicability column" for CERT > RRs. The editor claims that "experience is that the key tag and > algorithm fields of CERT RRs are rarely useful, nor consistently > populated.". After explicitly asking the list if not adding an > applicability column to the IANA registry would cause interoperability > issues (and not getting confirmation that it would) we decided to not > address this issue in the document. > > See: > http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00633.html, > which is the seminal message in the thread about this issue. > > (In the same thread there was another issue about the IANA > considerations too but that has been addressed.) > > 5) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with > it? > > Only a few individuals participated in the discussion. > > (How does one define "the WG as a whole"?) > > 6) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize what are they upset about. > > No. The document is not contentious. > > 7) Have the chairs verified that the document adheres to _all_ of the > ID nits? (see http://www.ietf.org/ID-nits.html). > > idnits 1.69 (09 Apr 2005) does not complain. > I checked the content issues of ID-Checklist revision 1.2 > > > On specific IPR (Checklist item 3.4): > > The editor has added in Appendix A a section of the copying > conditions as granted by the author. As far as I understand these > extend the standard copyright statement. I do not see these as > contentious but I am not sure if they need to be reviewed elsewhere > in the process. > > > On the example addresses (Checklist item 3.6): > > In section 3.1 example 2 an address in RFC1918 space is used instead > of an address from RFC3330. Also other domain names than > "example.com" and relatives were used. This is because this example > is a verbatim copy from RFC2538. > > To maintain as much consistency between this document and 2538 it > was chosen not to change these examples. > > > 8) For Standards Track and BCP documents, the IESG approval > announcement includes a writeup section with the following > sections: > > - Technical Summary > - Working Group Summary > - Protocol Quality > > > Technical Summary. > > This document describes how to store cryptographic public keys in RR > records. It updates RFC2538 by clarifying the format and handling of > OpenPGP public keys, clarifying representation issues, aligning the > document with DNSSECbis terminology and clarifying how owner names need > to be (re)constructed for specific types of public keys. > > Working group summary. > > See above. > > For IESG review it may be useful to know that the document Editor > clearly documented the editorial history of the document on: > http://josefsson.org/rfc2538bis/ > > > Protocol Quality. > > RFC2538 has been implemented. Some of the problems discovered during > implementation of RFC2538 have been addressed in this document. > > It was the intention of the working group to also supply an > interoperability report so that this document could advance RFC2538 up > the standards track. Unfortunately the WG could not draft volunteers. > > It is the intention that this document updates 2538 and that the > specification remains at proposed standard. > > --end-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 11:18:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21452 for ; Mon, 13 Jun 2005 11:18:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dhqf6-000Bxx-Tc for namedroppers-data@psg.com; Mon, 13 Jun 2005 15:15:40 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dhqf5-000BxR-43 for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 15:15:39 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 2DED7C2DA6; Mon, 13 Jun 2005 16:15:38 +0100 (BST) Date: Mon, 13 Jun 2005 16:15:36 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: <88BA84A491E507F8B728DBCA@[192.168.100.25]> In-Reply-To: <20050613135222.C5DE2139B5@sa.vix.com> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 13 June 2005 13:52 +0000 Paul Vixie wrote: >> I'm having imagination failure. How can your scheme work with traditional >> wildcards? (i.e. without rewriting the wildcard semantics). > > since noone is currently querying for names under _app.$DOMAIN, we have > the opportunity to require multiple queries. therefore to simulate the > effect of a nonterminal wildcard such as: > > mail_exchanger._app.**.VIX.COM. > > we can put in nodes of the form: > > mail_exchanger._app.VIX.COM. > *.mail_exchanger._app.VIX.COM. > > and clients can be told that if they're looking for a mail_exchanger._app > for a service name of FOO.VIX.COM, they should look up two DNS names: > > mail_exchange._app.FOO.VIX.COM. > FOO.mail_exchange._app.VIX.COM. I have visions of sendmail and MX processing circa 1994 here :-) So if the client is looking for a mail_exchange._app for foo.bar.baz.example.com. then technically to get all the appropriate wildcards it's going to have to query for mail_exchange._app.FOO.BAR.BAZ.EXAMPLE.COM. FOO.mail_exchange._app.BAR.BAZ.EXAMPLE.COM. FOO.BAR.mail_exchange._app.BAZ.EXAMPLE.COM. FOO.BAR.BAZ.mail_exchange._app.EXAMPLE.COM. FOO.BAR.BAZ.EXAMPLE.mail_exchange._app.COM. FOO.BAR.BAZ.EXAMPLE.COM.mail_exchange._app. because conceivably the non-terminal wildcard could appear anywhere. After all, we all know wildcards CAN appear in .com, don't we... Note the latter two may have unpopular scaling problems I'm pretty sure the above is undesirable even with negative caching. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 11:54:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24122 for ; Mon, 13 Jun 2005 11:54:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhrDw-000FY5-HK for namedroppers-data@psg.com; Mon, 13 Jun 2005 15:51:40 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhrDv-000FXg-SE for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 15:51:39 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 74CDC13925 for ; Mon, 13 Jun 2005 15:51:37 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Mon, 13 Jun 2005 16:15:36 +0100." <88BA84A491E507F8B728DBCA@[192.168.100.25]> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 13 Jun 2005 15:51:37 +0000 Message-Id: <20050613155137.74CDC13925@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So if the client is looking for a mail_exchange._app for > > foo.bar.baz.example.com. > > then technically to get all the appropriate wildcards it's going to have > to query for > > mail_exchange._app.FOO.BAR.BAZ.EXAMPLE.COM. > FOO.mail_exchange._app.BAR.BAZ.EXAMPLE.COM. > FOO.BAR.mail_exchange._app.BAZ.EXAMPLE.COM. > FOO.BAR.BAZ.mail_exchange._app.EXAMPLE.COM. > FOO.BAR.BAZ.EXAMPLE.mail_exchange._app.COM. > FOO.BAR.BAZ.EXAMPLE.COM.mail_exchange._app. > > because conceivably the non-terminal wildcard could appear anywhere. After > all, we all know wildcards CAN appear in .com, don't we... > > Note the latter two may have unpopular scaling problems it is very safe to set ndots:2 in a case like this, to prevent the latter two. > I'm pretty sure the above is undesirable even with negative caching. with ndots:2 and existing negative caching, life would be bearable. i'm not saying that in-protocol nonterminal wildcards wouldn't be better; it would. for that matter, in-protocol nonterminal wildcards that were still evaluated on the authority servers are practical in general, if painful to dnssec. so, moving wildcard processing into the requestor is not a strict requirement for nonterminal wildcards. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 12:16:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26630 for ; Mon, 13 Jun 2005 12:16:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhrZa-000ITP-Lv for namedroppers-data@psg.com; Mon, 13 Jun 2005 16:14:02 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DhrZY-000ISB-V6 for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 16:14:01 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 0E020C2DFD; Mon, 13 Jun 2005 17:14:00 +0100 (BST) Date: Mon, 13 Jun 2005 17:13:58 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: In-Reply-To: <20050613155137.74CDC13925@sa.vix.com> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 13 June 2005 15:51 +0000 Paul Vixie wrote: >> Note the latter two may have unpopular scaling problems > > it is very safe to set ndots:2 in a case like this, to prevent the latter > two. > >> I'm pretty sure the above is undesirable even with negative caching. > > with ndots:2 and existing negative caching, life would be bearable. Now try with foo.bar.baz.example.co.uk where you need ndots:3 to be bearable. But then that would break example.com. I'm sure there was some discussion about tree traversing lookups on namedroppers about 6 months ago, quite possibly also SPF inspired (though I forget), and it was in general thought a "bad thing". Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 12:30:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27907 for ; Mon, 13 Jun 2005 12:30:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dhrn7-000Jvd-HP for namedroppers-data@psg.com; Mon, 13 Jun 2005 16:28:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dhrn7-000JvS-0F for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 16:28:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9A85313A76 for ; Mon, 13 Jun 2005 16:28:00 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Mon, 13 Jun 2005 17:13:58 +0100." References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 13 Jun 2005 16:28:00 +0000 Message-Id: <20050613162800.9A85313A76@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > with ndots:2 and existing negative caching, life would be bearable. > > Now try with foo.bar.baz.example.co.uk where you need ndots:3 to be > bearable. But then that would break example.com. understood. > I'm sure there was some discussion about tree traversing lookups on > namedroppers about 6 months ago, quite possibly also SPF inspired > (though I forget), and it was in general thought a "bad thing". there was and it was. i was one of those arguing against it, in fact. i'm not sure if anything has changed. so it's nonterminal wildcards or nothing, huh? anybody else got a way out? anybody else got a preferred zone file syntax other than ** ? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 12:58:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29614 for ; Mon, 13 Jun 2005 12:58:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhsDa-000MfC-Vd for namedroppers-data@psg.com; Mon, 13 Jun 2005 16:55:22 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DhsDZ-000Mei-8Y for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 16:55:21 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 4E67FC2DA6; Mon, 13 Jun 2005 17:55:20 +0100 (BST) Date: Mon, 13 Jun 2005 17:55:18 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: In-Reply-To: <20050613162800.9A85313A76@sa.vix.com> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 13 June 2005 16:28 +0000 Paul Vixie wrote: > there was and it was. i was one of those arguing against it, in fact. > i'm not sure if anything has changed. so it's nonterminal wildcards or > nothing, huh? anybody else got a way out? Well there is always my straw-man subclassed RR proposal (i.e. 2 fields) with client doing the whole of the subclass matching. Yes, it increases average size of response, but if intelligently designed it *might* be able to be made compatible with 4-tuple queries later. And it works in every environment that supports new RR types (that's everywhere right Paul? :-) ), though may occasionally require support of large responses. The main criticism I have of it is that it isn't MUCH different from just using TXT with some magic string at the front identifying what type of field it is, other than the possibility 4-tuple forward compatibility. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 13:17:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00886 for ; Mon, 13 Jun 2005 13:17:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhsVm-000P2m-PL for namedroppers-data@psg.com; Mon, 13 Jun 2005 17:14:10 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhsVl-000P24-6Y for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 17:14:09 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C751113925 for ; Mon, 13 Jun 2005 17:14:08 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Mon, 13 Jun 2005 17:55:18 +0100." References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 13 Jun 2005 17:14:08 +0000 Message-Id: <20050613171408.C751113925@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The main criticism I have of it is that it isn't MUCH different from > just using TXT with some magic string at the front identifying what type > of field it is, other than the possibility 4-tuple forward compatibility. considering activation energy budgets, it's a fatal flaw to be able to say of a protocol change that "it's not much different from what we have now." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 13:33:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02268 for ; Mon, 13 Jun 2005 13:33:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhskR-0000bZ-3k for namedroppers-data@psg.com; Mon, 13 Jun 2005 17:29:19 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhskM-0000au-0q for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 17:29:14 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dhsk9-0002G0-QI for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 12:29:10 -0500 To: "IETF DNSEXT WG" References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Mon, 13 Jun 2005 12:29:00 -0500 In-Reply-To: <20050613001155.A297013925@sa.vix.com> (Paul Vixie's message of "Mon, 13 Jun 2005 00:11:55 +0000") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <20050613001155.A297013925@sa.vix.com> Paul Vixie writes: >> > the view in the DNS community was that addition of a new RR (i.e. >> > handling of unknown RR types) was hard. >> > >> > It is not anymore. >> >> Considering how hard it is now, it must have been truly stupefying then. > > adding an rrtype isn't all that hard. there's an experimental numbering > space, and also, BIND (even late model bind8) can handle opaque rrtypes > including transferring and querying and even updating them. > > the difficulty SPF is encountering is not related to the new rrtypes they > want to propose, but rather that community's insistence that the size of > their installed base means they shouldn't be subject to ietf consensus. I don't recall the argument that there were too many installed SPF records back when we were discussing using a new RR type (ca Oct 2003). Instead the concerns were whether a new RR type could be deployed easily and quickly. I did not do an exhaustive search on the subject, but I did find the following posts that I think are relevant: The earliest reference to using a new RR type that I could find was from Oct 8, 2003: http://archives.listbox.com/spf-discuss@v2.listbox.com/200310/0066.html This reply by Meng Wong to a message from Paul Wouters, where Meng asks: "does using a new RRtype mean that nameservers everywhere must be upgraded?" This thread also brought up the subject of using SRV records instead of TXT records. A much more serious concern about using a new RR type was raised discussed on Oct 19, 2003: http://archives.listbox.com/spf-discuss@v2.listbox.com/200310/0287.html In this message Meng received a reply from Hadmut Danisch, whose RMX proposal *did* define a new RR type. His response was not at all positive. I had read his comments about the problems with using new RR types before, and they are still available at: http://www.danisch.de/software/rmx/ Basically, Hadmut claimed that bind could not work with RR numbers greater than 255. I never verified this claim, but all in all, the problems that Hadmut ran into convinced me that there would be large deployment problems if we used a new RR type. Another interesting post from Mark Lentczner (former editor of the SPF I-D) can be found here: http://archives.listbox.com/spf-discuss@v2.listbox.com/200310/0291.html Here MarkL makes several claims that I think are still true today. People are not going to be interested in upgrading their DNS software. If you want quick deployment, you need to use an existing DNS RR type. MarkL also argues that the size savings of using a binary record type isn't relevant. Finally, MarkL argues for the use of the _prefix trick. I haven't bothered to hunt down the threads, but the _prefix trick was removed from the SPF draft later on once a survey of DNS hosting services showed that underscores were not allowed on many of them. Ok, so here we are, 18 months later, and we are still discussing the same issues that lead the SPF community to choose TXT over a new RR type. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 14:25:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05876 for ; Mon, 13 Jun 2005 14:25:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhtYL-0006VM-0r for namedroppers-data@psg.com; Mon, 13 Jun 2005 18:20:53 +0000 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhtYK-0006V5-6X for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 18:20:52 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j5DIKiWv027034; Mon, 13 Jun 2005 11:20:44 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j5DIKXTa027030; Mon, 13 Jun 2005 11:20:44 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 13 Jun 2005 11:20:33 -0700 (PDT) From: "william(at)elan.net" To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: <20050613135222.C5DE2139B5@sa.vix.com> Message-ID: References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 13 Jun 2005, Paul Vixie wrote: >>> you're right. neither does this one. >> >> I'm having imagination failure. How can your scheme work with traditional >> wildcards? (i.e. without rewriting the wildcard semantics). > > since noone is currently querying for names under _app.$DOMAIN, we have the > opportunity to require multiple queries. therefore to simulate the effect > of a nonterminal wildcard such as: > > mail_exchanger._app.**.VIX.COM. > > we can put in nodes of the form: > > mail_exchanger._app.VIX.COM. > *.mail_exchanger._app.VIX.COM. > > and clients can be told that if they're looking for a mail_exchanger._app > for a service name of FOO.VIX.COM, they should look up two DNS names: > > mail_exchange._app.FOO.VIX.COM. > FOO.mail_exchange._app.VIX.COM. The problem with this approach is determining which name is a host and which is a parent domain in FOO.VIX.COM, i.e. you could have zone my.really.weird.host.vix.com Would you then look at it as: mail_exchange._app.my.really.weird.host.vix.com my.really.weird.host.mail_exchange._app.vix.com OR: mail_exchange._app.my.really.weird.host.vix.com my.mail_exchange._app.really.weird.host.vix.com And why would you prefer one over the other? And if you chose the first one then why did you choose vix.com and what if if twas vix.co.uk, would you have looked at ....mail_exchange._app.co.uk? So saying that its not clean underestimates the issue. Its simply not easily doable without non-terminal wildcards in dns. -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 14:43:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07349 for ; Mon, 13 Jun 2005 14:43:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dhtrg-0008wM-99 for namedroppers-data@psg.com; Mon, 13 Jun 2005 18:40:52 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dhtrb-0008tU-Po for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 18:40:47 +0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 13 Jun 2005 20:40:46 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5DIeZ7N001158; Mon, 13 Jun 2005 20:40:44 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Jun 2005 20:40:40 +0200 Received: from [127.0.0.1] ([144.254.226.40]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 20:40:40 +0200 In-Reply-To: References: <20050610164846.DA199418D@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A834955-AF71-473E-A52F-3D855D38A985@cisco.com> Cc: "IETF DNSEXT WG" , wayne Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: draft-iab-dns-choices-02.txt comments: host names vs domain names Date: Mon, 13 Jun 2005 20:40:33 +0200 To: Edward Lewis X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 13 Jun 2005 18:40:40.0488 (UTC) FILETIME=[65EBFA80:01C57047] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jun 13, 2005, at 14:56, Edward Lewis wrote: >> My point remains that one problem with _prefix tricks is that many >> people can't create them due to software that restricts domain names >> to hostname characters. But, maybe I'm wrong. If you think so, let >> me know. >> >> I think that dns-choices should mention this problem. >> > > I agree with this. The issue in many cases is that "X is not a > problem for DNS because DNS software is cool" and "X is a problem > for the users [app writers] of DNS because the software surrounding > the DNS is a problem." Ack. I will add this. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 15:43:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16789 for ; Mon, 13 Jun 2005 15:43:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhunX-000Fqq-Ia for namedroppers-data@psg.com; Mon, 13 Jun 2005 19:40:39 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DhunW-000FqP-No for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 19:40:38 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j5DJeYOI023280 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 13 Jun 2005 15:40:36 -0400 Date: Mon, 13 Jun 2005 15:40:33 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: IETF DNSEXT WG Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 10 Jun 2005, wayne wrote: > In Dean Anderson writes: > > > 1.Abuser can still forge addresses at domain > > 2.Abuser can use stolen credential > > These are out of scope for this list. No, actually, they aren't. A protocol that doesn't work isn't suitable for standardization. But there is little point to arguing the details of why SPF doesn't work, now. --Dean > > > 3.DNS cache problems (more records per domain, same cache size) > > This is a choice that receivers can decide on. If they don't think > the additional DNS cache is worth it, then don't use SPF checks. > > > 4.DNS load (more records per domain) > > This, indeed, is a problem that I wish didn't exist. Domain owners > that don't want to deal with SPF will still receive DNS queries. The > only thing I can suggest is to publish an SPF record that has a very > long TTL which says "v=spf1 ?all". > > For domain owners that do want to publish SPF records, then that is > their choice to have more records. > > > 5.Ongoing Maintenance issues > > 6.Migration issues > > 7.IP Renumbering issues > > Again, this is up to the domain owners who choose to publish SPF > records. SPF does have quite a few features that make these less of > an issue, at the expense of increased DNS loads. The choice is up > tothe domain owner. > > > 8.Lost non-spam emails > > 9.Lack of universal compliance.* > > 10.Not a basis for trust/reduced filtering > > 11.Makes forgery blowback problem much worse > > 12.Patent issues > > 13.spam-profiteering / charges for SPF services > > 14.Email Source Routing > > 15.Outbound SMTP Relay Identification > > These are out of scope for this list. > > > > The things that are in scope for this list are reasons why I have > twice, without being asked, asked for reviews of the SPF I-D here. If > it was up to the IESG, no review would have been done here. > > > -wayne > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 15:43:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16839 for ; Mon, 13 Jun 2005 15:43:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhumG-000Ffu-D5 for namedroppers-data@psg.com; Mon, 13 Jun 2005 19:39:20 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DhumD-000Ffe-Fm for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 19:39:17 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j5DJcwiu023186 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 13 Jun 2005 15:39:00 -0400 Date: Mon, 13 Jun 2005 15:38:58 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: "william(at)elan.net" cc: IETF DNSEXT WG Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 10 Jun 2005, william(at)elan.net wrote: > > On Fri, 10 Jun 2005, Dean Anderson wrote: > > > I think if we have genuine need for a new RRtype, it can be accomodated. > > However, MARID wasn't a genuine need. > but from what I see the issue is that DNSEXT is not assigning new RR > types in without very very substantial review and that creates other > problems like that that proposals like SPF begin to use TXT as basis and > then this may become widely used on the net. It is supposed to be IETF policy not to standardize hypothetical protocols. That is, there should be working code. It should be tested and proven to work as documented. I think the problem here is methodology. The SPF folks came in and said, essentially, "standardize and deploy this new protocol without any proof that it works. Its too urgent to actually test before deployment." But, it didn't work, and they didn't get their standards, and they've been mad ever since, claiming the IETF is irrelevant. I don't see any problem with developing new RRtypes, showing that the protocols work and perform some useful service, and then getting standard RRtype codes. > It should not be for DNSEXT people to decide if concept itself is bad or > good and argue about it here, you should focus on providing stability for > dns system and let others run experiments that use dns for specific > applications and if experiment turns out to be usefull the requested RR > assignment becomes permanent. Experiments don't require standard codes. The SPF folks didn't do any real experiments. SPF was "too urgent" for such "nonsense". > But trying to shut down (or not letting it start) the experiment by not > getting it RR is just wrong and exactly why proposals like SPF or DK > which attempt to use TXT RR instead of getting new one from the start. No experiments were shutdown. Only production deployment was affected. Those are different matters, entirely. Indeed, SPF supporters are currently asking sites to enter production SPF TXT records, without telling those sites that they are participating in an experiment. I've already suggested that this is misleading. The SPF promoters are unconcerned and unfettered by ethical standards for experimentation. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 16:24:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03597 for ; Mon, 13 Jun 2005 16:24:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhvRF-000L00-6x for namedroppers-data@psg.com; Mon, 13 Jun 2005 20:21:41 +0000 Received: from [81.228.11.98] (helo=pne-smtpout1-sn1.fre.skanova.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DhvRA-000Kzd-7F for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 20:21:36 +0000 Received: from arport2v (212.181.176.215) by pne-smtpout1-sn1.fre.skanova.net (7.2.059.6) id 429C5421002D49E0; Mon, 13 Jun 2005 22:20:31 +0200 Message-ID: <00e401c57055$b4b57890$8217a8c0@arport2v> From: "Anders Rundgren" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Edward Lewis" Cc: "IETF DNSEXT WG" , "wayne" References: <20050610164846.DA199418D@thrintun.hactrn.net> <8A834955-AF71-473E-A52F-3D855D38A985@cisco.com> Subject: Re: draft-iab-dns-choices-02.txt comments: host names vs domain names Date: Mon, 13 Jun 2005 22:23:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BIZ_TLD, RCVD_IN_SORBS_WEB autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit >> My point remains that one problem with _prefix tricks is that many >> people can't create them due to software that restricts domain names This problem is a bit exaggerated. Using a simple conversion scheme I managed to convert any URI into a valid host (prefix) including dividing it in 63-byte chunks. By doing that I got URI-space of unique DNS data types and I did not have to tell IANA either! Who BTW, refused me some RRs as there was no RFC. Anders ----- Original Message ----- From: "Patrik Fältström" To: "Edward Lewis" Cc: "IETF DNSEXT WG" ; "wayne" Sent: Monday, June 13, 2005 20:40 Subject: Re: draft-iab-dns-choices-02.txt comments: host names vs domain names On Jun 13, 2005, at 14:56, Edward Lewis wrote: >> My point remains that one problem with _prefix tricks is that many >> people can't create them due to software that restricts domain names >> to hostname characters. But, maybe I'm wrong. If you think so, let >> me know. >> >> I think that dns-choices should mention this problem. >> > > I agree with this. The issue in many cases is that "X is not a > problem for DNS because DNS software is cool" and "X is a problem > for the users [app writers] of DNS because the software surrounding > the DNS is a problem." Ack. I will add this. paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 13 16:52:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05493 for ; Mon, 13 Jun 2005 16:52:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DhvrV-000NrR-I9 for namedroppers-data@psg.com; Mon, 13 Jun 2005 20:48:49 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DhvrS-000NrC-Sg for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 20:48:46 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DhvrK-0007Bg-HW for namedroppers@ops.ietf.org; Mon, 13 Jun 2005 15:48:45 -0500 To: "IETF DNSEXT WG" References: <20050610164846.DA199418D@thrintun.hactrn.net> <8A834955-AF71-473E-A52F-3D855D38A985@cisco.com> <00e401c57055$b4b57890$8217a8c0@arport2v> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Mon, 13 Jun 2005 15:48:36 -0500 In-Reply-To: <00e401c57055$b4b57890$8217a8c0@arport2v> (Anders Rundgren's message of "Mon, 13 Jun 2005 22:23:03 +0200") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments: host names vs domain names X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <00e401c57055$b4b57890$8217a8c0@arport2v> "Anders Rundgren" writes: >>> My point remains that one problem with _prefix tricks is that many >>> people can't create them due to software that restricts domain names > > This problem is a bit exaggerated. Using a simple conversion scheme I managed > to convert any URI into a valid host (prefix) including dividing it in 63-byte chunks. > > By doing that I got URI-space of unique DNS data types and I did not > have to tell IANA either! Who BTW, refused me some RRs as there > was no RFC. The problem isn't as much in the applications as in things like DNS hosters. For example, GoDaddy (which recently passed NSI to become the largest registrar) does not allow me to create a TXT record with the name of _underscore_test.unified-spf.org. The inclusion of the underscore causes the webform to reject it. They also don't allow the creation of SRV records, let alone unknown types. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 04:14:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20699 for ; Tue, 14 Jun 2005 04:14:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Di6SJ-000Fh5-OV for namedroppers-data@psg.com; Tue, 14 Jun 2005 08:07:31 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Di6SI-000FgC-1A for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 08:07:30 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 2413D249BC; Tue, 14 Jun 2005 10:07:13 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 3BF4F24979 for ; Tue, 14 Jun 2005 10:07:12 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j5E87CUU011183 for ; Tue, 14 Jun 2005 10:07:12 +0200 Date: Tue, 14 Jun 2005 10:07:11 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Reminder of Working Group Last Calls Message-Id: <20050614100711.3d9b232b.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 1.0.3 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000045 / -5.9 X-RIPE-Signature: 51d20a306a19e7cdd895d6a96c711255 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear *Working Group*, Please be reminded of the two Last calls currently in progress. One on "Wildcards Clarify" and one on "LLMNR" http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00848.html http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00849.html Please review the document. Please state you reviewed the document with your objections and support. Send your statement to the mailing list or to both chairs directly. Statements that the documents has been thoroughly reviewed by working group members do help in writing a summary for the IESG and to further shepherd the document. If no support or objections have been received the default action will be to forward this document to the IESG with a request to publish on the standards track. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 05:01:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23978 for ; Tue, 14 Jun 2005 05:01:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Di7Fc-000LPK-9A for namedroppers-data@psg.com; Tue, 14 Jun 2005 08:58:28 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Di7Fb-000LNh-4k for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 08:58:27 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Di7FG-0006NC-1c for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 03:58:25 -0500 To: "IETF DNSEXT WG" From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Tue, 14 Jun 2005 03:58:05 -0500 Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: draft-delany-nullmx-00.txt good? bad? ugly? X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The following I-D has been floating around on the various anti-spam lists: http://www.ietf.org/internet-drafts/draft-delany-nullmx-00.txt Basically it proposes that people should publish records such as: example.com. MX . This would signify that example.com never receives any email. Looking at the I-D, I can't see where it mentions the impact on the root name servers caused by software that doesn't understand this special convention and goes off and tries to do an SMTP connection to them. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 05:08:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24603 for ; Tue, 14 Jun 2005 05:08:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Di7Mx-000MWb-BL for namedroppers-data@psg.com; Tue, 14 Jun 2005 09:06:03 +0000 Received: from [64.142.16.245] (helo=a.mail.sonic.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Di7Mt-000MVb-FJ for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 09:05:59 +0000 Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j5E95wYq005691 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 14 Jun 2005 02:05:58 -0700 Subject: Re: draft-iab-dns-choices-02.txt comments From: Douglas Otis To: IETF DNSEXT WG In-Reply-To: References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> Content-Type: text/plain Date: Tue, 14 Jun 2005 02:05:56 -0700 Message-Id: <1118739956.2160.229.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2005-06-13 at 12:29 -0500, wayne wrote: > MarkL also argues that the size savings of using a binary record type > isn't relevant. The complexity and resulting size of many of these email path registration RRs are creating overly broad declarations when collapsing this into fewer records. Here is an SPF record published by a provider after extensive reduction efforts. This was done by listing large address blocks. This still required 236 bytes plus overhead to define this rather crude list. A list that may collide with a different SPF revision, adding just scope, for more than double the response size. : ( TXT RR for SPF: v=spf1 ip4:24.30.203.0/24 ip4:24.28.200.0/24 ip4:24.28.204.0/24 ip4:24.30.218.0/24 ip4:24.93.47.0/24 ip4:24.25.9.0/24 ip4:65.24.5.0/24 ip4:24.94.166.0/24 ip4:24.29.1 09.0/24 ip4:66.75.162.0/24 ip4:24.24.2.0/24 ip4:65.32.5.0/24 +mx ~all This record could be done using a binary SPF TLV structure. Assume a TLV tag list of the following: 0 = next name marker 1 = a 2 = cidr+a 3 = mx 4 = cidr+mx 5 = ip4+cidr 6 = ip6+cidr 7 = ptr 8 = include 9 = redirect 10 = exist 11 = strict-path mfrom (-all) Ending tags could include a checksum. 12 = test-path mfrom (~all) 13 = neutral-path mfrom (?all) 14 = open-path mfrom (+all) 15 = strict-path pra (-all) 16 = test-path pra (~all) 17 = neutral-path pra (?all) 18 = open-path pra (+all) 19 = strict-path mfrom+pra (-all) 20 = test-path mfrom+pra (~all) 21 = neutral-path mfrom+pra (?all) 22 = open-path mfrom+pra (+all) 23 = white-listing only This list could be extended at anytime, where a recipient which does not understand the content of the tag could skip over the element. Some formats use a scheme where a range of tags will not allow this behavior, such as 192-255 for example. There may also be a range of tags that would always appear last, such as 11-48. Where length permits, elements are repeated. Have a rule for tags that use names, where the related entries are separated by a zero. This use of a zero permits creation of name lists. Names would also allow the same SPF macros, if needed. Perhaps even add a DNS style name compression confined solely within the RR. The ip4, ip6 tags would use a single byte CIDR notation, where when the most significant bit is set in the mask, this would indicate this range of addresses are excluded (without modifying the nature of the path declaration as currently implemented). With Tag and Length values defined as octets, the example file given becomes: +---+---+---+---+---+---+---+---+ | SPF-TAG | +---+---+---+---+---+---+---+---+ | Element Length | +---+---+---+---+---+---+---+---+ / Element / +---+---+---+---+---+---+---+---+ Binary RR possible: 5,60,24,30,203,0,24, 24,28,200,0,24, 24,28,204,0,24, 24,30,218,0,24, 24,93,47,0,24, 24,25,9,0,24, 65,24,5,0,24, 24,94,166,0,24, 24,29,109,0,24, 66,75,162,0,24, 24,24,2,0,24, 65,32,5,0,24, 3,0, 12,0 This TLV binary approach reduces the RR size for _exactly_ the same data goes from 236 byte to 65 bytes. This approaches a 4 times reduction in the RR size. How can this not be relevant? This reduction would allow either better path declarations or reduced cache consumption. When SPF limits already expect 11 TXT record fetches, size matters. Employ the approach RFC3597 standardizes. A text representation handled by the various DNS tools to permit text entry of unknown structures into their true binary form. A token of '\#', followed by an unsigned decimal integer byte length, declares the use of this convention. It represents a binary format with two hexadecimal characters for each actual byte. DNS entry is not the greatest hurdle anyway. A practice of using intelligent entry forms to generate RFC3597 text outputs would help overcome barriers to implementing new RR types. The APL RR, RFC3123, already provides a suitable RR to define paths. Some considerations to improve this RR type: http://www.techfak.uni-bielefeld.de/~pk/dns/draft-koch-dns-apl-domainname-01.html -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 05:09:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24648 for ; Tue, 14 Jun 2005 05:09:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Di7OI-000Mhu-No for namedroppers-data@psg.com; Tue, 14 Jun 2005 09:07:26 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Di7OE-000MgH-Aj for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 09:07:22 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id E745BC2DA5; Tue, 14 Jun 2005 09:48:26 +0100 (BST) Date: Tue, 14 Jun 2005 09:48:23 +0100 From: Alex Bligh Reply-To: Alex Bligh To: IETF DNSEXT WG Cc: Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments: host names vs domain names Message-ID: <06C10095E8598BB12246E048@[192.168.100.25]> In-Reply-To: References: <20050610164846.DA199418D@thrintun.hactrn.net> <8A834955-AF71-473E-A52F-3D855D38A985@cisco.com> <00e401c57055$b4b57890$8217a8c0@arport2v> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 13 June 2005 15:48 -0500 wayne wrote: > The problem isn't as much in the applications as in things like DNS > hosters. For example, GoDaddy (which recently passed NSI to become > the largest registrar) does not allow me to create a TXT record with > the name of _underscore_test.unified-spf.org. The inclusion of the > underscore causes the webform to reject it. They also don't allow the > creation of SRV records, let alone unknown types. Isn't this argument a bit backwards? IE don't these DNS hosting services prohibit use of underscores precisely because there is no standards-based protocol that mandates their use (and banning them for A records etc. eliminates a lot of tech support calls from the clue deprived). Neither do they support RR Types which have no standards-based definition. If you design the protocol right, vendors (software and hardware) will support it. Case in point: most of these DNS vendors previously did not support SRV & NAPTR records. I am betting, now these are becoming more useful, you will see a roll-out (clearly they are already in Bind, and will over time get into hosted DNS products). Should these have been implemented by TXT too, because n years ago no vendors supported them? Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 06:05:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29285 for ; Tue, 14 Jun 2005 06:05:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Di8F0-000301-8G for namedroppers-data@psg.com; Tue, 14 Jun 2005 10:01:54 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Di8Ex-0002zg-Pt for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 10:01:51 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Di8Ep-0007al-Aw for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 05:01:50 -0500 To: "IETF DNSEXT WG" References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <1118739956.2160.229.camel@bash.adsl-64-142-13-68> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Tue, 14 Jun 2005 05:01:42 -0500 In-Reply-To: <1118739956.2160.229.camel@bash.adsl-64-142-13-68> (Douglas Otis's message of "Tue, 14 Jun 2005 02:05:56 -0700") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <1118739956.2160.229.camel@bash.adsl-64-142-13-68> Douglas Otis writes: > On Mon, 2005-06-13 at 12:29 -0500, wayne wrote: >> MarkL also argues that the size savings of using a binary record type >> isn't relevant. > > [...] Here is an SPF record published by a provider > after extensive reduction efforts. This was done by listing large > address blocks. This still required 236 bytes plus overhead to define > this rather crude list. [...] > > This record could be done using a binary SPF TLV structure. Assume a > TLV tag list of the following: > > [snip] > > This TLV binary approach reduces the RR size for _exactly_ the same data > goes from 236 byte to 65 bytes. Using the libspf2 encoding, the record is reduced to 80 bytes. I know that the libspf2 encoding is not ambigious and handles all SPF records, and includes support for versioning and such. Your encoding can't handle things like -ip4 and such. I suspect that if you fleshed out your idea to fully support SPF records, you would have to add a few bytes to your 65 count. Be that as it may, I don't think the difference between 65 bytes and 80 bytes is significant. > This approaches a 4 times reduction in > the RR size. How can this not be relevant? The reduction is only a factor of 4 when you don't take into account IP, UDP and DNS packet overhead. Currently the rr.com TXT record uses a 411 byte DNS packet, IP packet overhead is 20 bytes and UDP adds 8 bytes, giving a total of 439 bytes. If you reduce the SPF information to 65 bytes, that drops it down to 268 bytes. This isn't even a factor of 2 reduction. Ok, now take into account that the ip4: mechanism gets the best compression of all SPF mechanisms. IPv4 addresses can use up to 15 bytes in text, but only require 4 bytes in binary. IPv6 addresses use hex and are therefore much more compact. All other mechanisms get almost no benefit from binary encoding. So, yes, when you are talking about some of the very largest SPF records that have been published, there is some savings, but not even a factor of 2. I don't think this savings is worth that much compared with the advantages of not having to update all the DNS software in the world to be able to deal with a new format. Now, consider whether the typical new DNS record type is going to be anywhere near the size of SPF record you gave. I suspect that the size savings for most new DNS records will be only a few percent. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 06:40:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01669 for ; Tue, 14 Jun 2005 06:40:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Di8nZ-0006wo-NE for namedroppers-data@psg.com; Tue, 14 Jun 2005 10:37:37 +0000 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Di8nW-0006wZ-Q0 for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 10:37:34 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from virgo.cus.cam.ac.uk ([131.111.8.20]:63063) by ppsw-7.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtp id 1Di8nR-00041I-Nm (Exim 4.51) for namedroppers@ops.ietf.org (return-path ); Tue, 14 Jun 2005 11:37:29 +0100 Received: from cet1 by virgo.cus.cam.ac.uk with local (Exim 4.51) id 1Di8nR-0007gC-8x for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 11:37:29 +0100 Subject: Re: draft-delany-nullmx-00.txt good? bad? ugly? To: namedroppers@ops.ietf.org Date: Tue, 14 Jun 2005 11:37:29 +0100 (BST) In-Reply-To: from "wayne" at Jun 14, 5 03:58:05 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Chris Thompson X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Wayne writes: > > The following I-D has been floating around on the various anti-spam > lists: > > http://www.ietf.org/internet-drafts/draft-delany-nullmx-00.txt > > Basically it proposes that people should publish records such as: > > example.com. MX . > > This would signify that example.com never receives any email. > > > Looking at the I-D, I can't see where it mentions the impact on the > root name servers caused by software that doesn't understand this > special convention and goes off and tries to do an SMTP connection to > them. They wouldn't do that, surely? They would try to look up A (and maybe AAAA) records records for ".", find there aren't any, and do whatever their MTA does in that situation ("ignore the MX record and fall back on the A/AAAA record for the mail domain name" being one obvious possibility, which would subvert the intention of the I-D). The NODATA result for the lookup(s) should be cachable by sufficiently clueful nameservers, but it certainly doesn't seem like a desirable thing to have happening. -- Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 06:42:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01821 for ; Tue, 14 Jun 2005 06:42:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Di8pi-000772-1L for namedroppers-data@psg.com; Tue, 14 Jun 2005 10:39:50 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Di8pf-00076Y-UR for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 10:39:48 +0000 Received: from zacatecas.TechFak.Uni-Bielefeld.DE (zacatecas.TechFak.Uni-Bielefeld.DE [129.70.137.4]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j5EAdhwQ013464 for ; Tue, 14 Jun 2005 12:39:43 +0200 (MEST) Received: from localhost (pk@localhost) by zacatecas.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j5EAdht04320 for ; Tue, 14 Jun 2005 12:39:43 +0200 (MEST) Message-Id: <200506141039.j5EAdht04320@zacatecas.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: zacatecas.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: zacatecas.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: "IETF DNSEXT WG" Subject: Re: draft-delany-nullmx-00.txt good? bad? ugly? In-reply-to: Your message of "Tue, 14 Jun 2005 03:58:05 CDT." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4315.1118745582.1@zacatecas.TechFak.Uni-Bielefeld.DE> Date: Tue, 14 Jun 2005 12:39:43 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk wayne wrote. > Basically it proposes that people should publish records such as: > > example.com. MX . > > This would signify that example.com never receives any email. this is another bad example of publishing explict "NO" data points, although in this case it is based on too liberal decisions in the past. > Looking at the I-D, I can't see where it mentions the impact on the > root name servers caused by software that doesn't understand this > special convention and goes off and tries to do an SMTP connection to > them. First, as an operational matter this might be better discussed on the DNSOP list. Second, it's not SMTP connections that would cause a traffic increase ("." does not have any A/AAAA RRs associated with it, so there's no address to connect to), but the additional section processing that would try to resolve addresses for ".". These resolution attempts would not (or not only) happen in the MTA but also in the name servers. Adding logic to MX handling that deprecates ASP for specific targets, "." in this case, doesn't seem convincing. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 10:09:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20239 for ; Tue, 14 Jun 2005 10:09:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiC1u-000BSU-HE for namedroppers-data@psg.com; Tue, 14 Jun 2005 14:04:38 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiC1s-000BMs-OK for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 14:04:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C35D013A7A; Tue, 14 Jun 2005 14:04:13 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Douglas Otis cc: IETF DNSEXT WG Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Tue, 14 Jun 2005 02:05:56 MST." <1118739956.2160.229.camel@bash.adsl-64-142-13-68> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <1118739956.2160.229.camel@bash.adsl-64-142-13-68> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 14 Jun 2005 14:04:13 +0000 Message-Id: <20050614140413.C35D013A7A@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk since spf isn't a tlv but is rather a mini programming language, txt is no longer the wrong choice (as it was earlier, when a simple cidr-block RR would have been better). note that we should still have a cidr-block RR. but don't put the whole list in one rr, that's what rrsets are for. if order matters, put in a priority field like MX has. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 10:33:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22663 for ; Tue, 14 Jun 2005 10:33:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiCQS-000EUs-Np for namedroppers-data@psg.com; Tue, 14 Jun 2005 14:30:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DiCQQ-000EUZ-Ud for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 14:29:59 +0000 Received: (qmail 47726 invoked from network); 14 Jun 2005 15:42:25 -0000 Received: from yahoobb219001188020.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.1.188.20) by necom830.hpcl.titech.ac.jp with SMTP; 14 Jun 2005 15:42:25 -0000 Message-ID: <42AEE9CB.3040701@necom830.hpcl.titech.ac.jp> Date: Tue, 14 Jun 2005 23:29:31 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en MIME-Version: 1.0 To: Paul Vixie CC: Douglas Otis , IETF DNSEXT WG Subject: Re: draft-iab-dns-choices-02.txt comments References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <1118739956.2160.229.camel@bash.adsl-64-142-13-68> <20050614140413.C35D013A7A@sa.vix.com> In-Reply-To: <20050614140413.C35D013A7A@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: > since spf isn't a tlv but is rather a mini programming language, txt is > no longer the wrong choice (as it was earlier, when a simple cidr-block > RR would have been better). Let's use TXT RRs and BASIC with line numbers to overcome the deficiency of DNS that RRs are not orderd. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 11:31:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27406 for ; Tue, 14 Jun 2005 11:31:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiDHs-000Ljd-FE for namedroppers-data@psg.com; Tue, 14 Jun 2005 15:25:12 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiDHq-000LjB-OS for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 15:25:10 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j5EFOvKN027106; Tue, 14 Jun 2005 15:24:57 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j5EFOvKT027105; Tue, 14 Jun 2005 15:24:57 GMT Date: Tue, 14 Jun 2005 15:24:57 +0000 From: bmanning@vacation.karoshi.com To: Masataka Ohta Cc: Paul Vixie , Douglas Otis , IETF DNSEXT WG Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: <20050614152457.GA25285@vacation.karoshi.com.> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <1118739956.2160.229.camel@bash.adsl-64-142-13-68> <20050614140413.C35D013A7A@sa.vix.com> <42AEE9CB.3040701@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42AEE9CB.3040701@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Jun 14, 2005 at 11:29:31PM +0900, Masataka Ohta wrote: > Paul Vixie wrote: > > > since spf isn't a tlv but is rather a mini programming language, txt is > > no longer the wrong choice (as it was earlier, when a simple cidr-block > > RR would have been better). > > Let's use TXT RRs and BASIC with line numbers to overcome the > deficiency of DNS that RRs are not orderd. > > Masataka Ohta a powerful extention to the DNS... i think that ohta-san is on to something. --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. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 11:58:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29431 for ; Tue, 14 Jun 2005 11:58:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiDlm-000PbX-HQ for namedroppers-data@psg.com; Tue, 14 Jun 2005 15:56:06 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiDli-000Pat-O3 for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 15:56:02 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id C94C4C2DA5; Tue, 14 Jun 2005 16:56:00 +0100 (BST) Date: Tue, 14 Jun 2005 16:55:58 +0100 From: Alex Bligh Reply-To: Alex Bligh To: bmanning@vacation.karoshi.com, Masataka Ohta Cc: Paul Vixie , Douglas Otis , IETF DNSEXT WG , Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: In-Reply-To: <20050614152457.GA25285@vacation.karoshi.com.> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <1118739956.2160.229.camel@bash.adsl-64-142-13-68> <20050614140413.C35D013A7A@sa.vix.com> <42AEE9CB.3040701@necom830.hpcl.titech.ac.jp> <20050614152457.GA25285@vacation.karoshi.com.> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 14 June 2005 15:24 +0000 bmanning@vacation.karoshi.com wrote: >> Let's use TXT RRs and BASIC with line numbers to overcome the >> deficiency of DNS that RRs are not orderd. >> >> Masataka Ohta > > a powerful extention to the DNS... i think > that ohta-san is on to something. Perhaps we could subtype the TXT RR by the first character of the label, for instance labels beginning i, j, k, l, m or n, could correspond to TXT fields containing integers. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 12:27:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02052 for ; Tue, 14 Jun 2005 12:27:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiEDZ-0003Mz-5A for namedroppers-data@psg.com; Tue, 14 Jun 2005 16:24:49 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiEDX-0003Mi-7h for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 16:24:47 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j5EGKnpn008382 for ; Tue, 14 Jun 2005 12:20:49 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAmNayxq; Tue, 14 Jun 05 12:20:45 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j5EGMicp013945 for ; Tue, 14 Jun 2005 12:22:44 -0400 (EDT) Date: Tue, 14 Jun 2005 12:22:44 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: New type code assignments (was: Re: draft-iab-dns-choices-02.txt comments) In-Reply-To: <20050613162125.5ad12e39.olaf@ripe.net> Message-ID: References: <20050613162125.5ad12e39.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 13 Jun 2005, Olaf M. Kolkman wrote: > One of the arguments that is currently being used against trying to > "design" a new RR for use with ones application, is that it is > apparently difficult to get one's specification reviewed, processed > and the typecode assigned. > > This should not be an argument. ... > o Reviewing and providing recommendations about the > specification, by other working groups, of RR types that do not > require any special processing and that do not require any > special naming conventions. Note that this charter item only applied to RRs requested "by other working groups". Presumably those looking for assignments in the "specification required" part of the number space wouldn't even need DNSEXT review. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 12:27:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02084 for ; Tue, 14 Jun 2005 12:27:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiEDO-0003MF-4M for namedroppers-data@psg.com; Tue, 14 Jun 2005 16:24:38 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiEDM-0003M1-2w for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 16:24:36 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j5EGKcWq008369 for ; Tue, 14 Jun 2005 12:20:38 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4naWvq; Tue, 14 Jun 05 12:20:35 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j5EGMYJf013940 for ; Tue, 14 Jun 2005 12:22:34 -0400 (EDT) Date: Tue, 14 Jun 2005 12:22:34 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) In-Reply-To: Message-ID: References: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 10 Jun 2005, william(at)elan.net wrote: > > Isn't getting an RR Type based on just publicly documneting its use > > liberal enough? > > I've not seen any RR types allocated except though IETF consensus and RFC. IANA has repeatedly told me that they've never gotten requests for 'specification required' type codes. Yesterday Anders Rundgren claimed that IANA had turned him down for lack of an RFC, and I'm be curious to know if he had any other permanent reference. (Per the Specification Required definition below, an i-d shouldn't be sufficient, because it's not permanent.) Unfortunately, IANA has refused to give an unequivocal answer to the question of what sort of document might be sufficient to meet the threshhold of: "Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible." Perhaps DNSEXT could tell them what that answer should be? I've discussed this before on this list, too: http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00243.html -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 12:28:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02110 for ; Tue, 14 Jun 2005 12:27:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiEEN-0003S4-9T for namedroppers-data@psg.com; Tue, 14 Jun 2005 16:25:39 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiEEI-0003Qb-P2 for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 16:25:37 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j5EGLWMq008436 for ; Tue, 14 Jun 2005 12:21:32 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfsaqEq; Tue, 14 Jun 05 12:21:29 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j5EGNO4E013962; Tue, 14 Jun 2005 12:23:24 -0400 (EDT) Date: Tue, 14 Jun 2005 12:23:23 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org cc: iana@iana.org Subject: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) In-Reply-To: Message-ID: References: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 13 Jun 2005, Edward Lewis wrote: > SSHFP 44 SSH Key Fingerprint [RFC-ietf-secsh-dns-05.txt] > IPSECKEY 45 IPSECKEY [RFC-ietf-ipseckey-rr-11.txt] > > Note that two of them are in pending RFC's, which kind of violates > the instructions in RFC 2929. I disagree. IANA has to do the assignment at some point in time, and, per the RFC Editor's processes, that's during the editing process[1]. That process has happened for SSHFP -- SSHFP is just waiting for a normative reference to be cleared up. And IPSECKEY (RFC4025) was published in February -- IANA just hasn't updated their registry (despite two notes on this list urging them to). Perhaps the IANA's processes need to include reviewing all published RFCs to remove these temporary citations in the registries. -- Sam [1] ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-process.gif -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 13:59:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11641 for ; Tue, 14 Jun 2005 13:59:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiFdf-000FEx-Bc for namedroppers-data@psg.com; Tue, 14 Jun 2005 17:55:51 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiFdd-000FEe-Pp for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 17:55:50 +0000 Received: from [10.31.32.153] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5EHtgQp099963; Tue, 14 Jun 2005 13:55:42 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> Date: Tue, 14 Jun 2005 13:55:48 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:23 -0400 6/14/05, Samuel Weiler wrote: >... IANA has to do the assignment at some point in time, and, >per the RFC Editor's processes, that's during the editing process[1]. By the time an effort is in the "editing process" it is already too late to assign a type code. If I had my druthers, I would have at least mocked up the application, tested it in a workshop environment before trotting out a formal document. Whatever happened to running code and rough consensus? Remember the days when code ruled? We are letting regulation get ahead of technology. >And IPSECKEY (RFC4025) was published in February -- IANA just hasn't >updated their registry (despite two notes on this list urging them >to). Perhaps the IANA's processes need to include reviewing all >published RFCs to remove these temporary citations in the registries. Ok, but which came first - the RFC number or the type code number? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 14:44:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17604 for ; Tue, 14 Jun 2005 14:44:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiGLH-000L3X-JB for namedroppers-data@psg.com; Tue, 14 Jun 2005 18:40:55 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiGLD-000L3D-Mp for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 18:40:51 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j5EIar2I019799 for ; Tue, 14 Jun 2005 14:36:53 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfaayQM; Tue, 14 Jun 05 14:36:50 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j5EIckrQ018286; Tue, 14 Jun 2005 14:38:46 -0400 (EDT) Date: Tue, 14 Jun 2005 14:38:45 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) In-Reply-To: Message-ID: References: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 14 Jun 2005, Edward Lewis wrote: > By the time an effort is in the "editing process" it is already too > late to assign a type code. If I had my druthers, I would have at > least mocked up the application, tested it in a workshop environment > before trotting out a formal document. I'm confused. First I heard what sounded like a complaint that these two type codes were issued based only on I-D's instead of RFCs, now the text above. Perhaps they're not incongruous after all -- I suppose one could want the process to change while still complaining that the current process isn't being followed closely enough. In any case, I agree with your point that we need the type codes earlier. It's particularly galling that it might be easier to get a type code for something that's happening completely outside IETF processes than something inside (since an i-d isn't a permanent reference). Then, too, no one has tested that premise. > >And IPSECKEY (RFC4025) was published in February -- IANA just hasn't > >updated their registry (despite two notes on this list urging them > >to). Perhaps the IANA's processes need to include reviewing all > >published RFCs to remove these temporary citations in the registries. > > Ok, but which came first - the RFC number or the type code number? Per [1], the type code. As it happened, that was the actual order, too. -- Sam [1] ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-process.gif -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 15:24:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22369 for ; Tue, 14 Jun 2005 15:24:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiGyF-0000cQ-1j for namedroppers-data@psg.com; Tue, 14 Jun 2005 19:21:11 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiGy9-0000br-H9 for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 19:21:10 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j5EJH8Ut024449 for ; Tue, 14 Jun 2005 15:17:08 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAMaGVV; Tue, 14 Jun 05 15:17:05 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j5EJJ0ZP019511; Tue, 14 Jun 2005 15:19:00 -0400 (EDT) Date: Tue, 14 Jun 2005 15:19:00 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: paf@cisco.com cc: namedroppers@ops.ietf.org Subject: editorial comments on draft-iab-dns-choices-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Since these are mostly comments on the text of the doc, not the idea it's pushing, I'm starting yet another thread. Overview: I agree with this document's recommendation, but, as is evident from the discussion on this list, it needs to be rewritten so as to be more compelling. Both for that reason and to make it easier to read, I'd like to see this document tightened up substantially, perhaps by adding more structure to the summary of choices. A grid cross-referencing techniques to known benefits/problems might be particularly handy. It could also use some more compelling text on how easy it is to get typecodes (or how easy it should be, given that no one has tested the 'specification required' assignments). Specific comments (written before the above summary, so they may be redundant): Section 1, paragraph 5: I'm finding this paragraph confusing, particularly: "...an analysis should be made as to whether having (for example) A record and SSH key information in different zones is a problem, and if it is, whether the owner for the records by design must be the same for both records." I tend to read "owner" as "owner name", and having the same "owner name" in two zones is inviting trouble (see RFC3658 and the discussions that led to it). Perhaps you meant something else. ------------- Section 2 Citing 2929 for the query packet format just seems wrong. Yes, it's in 2929, but 2929 is otherwise pretty irrelevant. How about dropping the 2929 reference? ------------- Section 3.1, last paragraph Rewrite for grammar. You might also want to summarize, with one sentence in this last paragraph, why subtyping is bad -- make it easier for someone skimming the doc to at least extract a clear disrecommendation. ----------- Section 3.2 The section (and maybe the one before) would improve with a clearer structure -- tell the reader what you're going to tell them: "Another inferior way to store new data...." Move the mention of wildcard-clarify up to just after "...leftmost token in the domain name." and tell folks why wildcards may surprise them: The below "this implies" confuses me: .... This RR type can either be a record type that can store arbitrary data or a new RR type. This implies that some other selection mechanism has to be applied as well, such as ability to distinguish between the records in an RR set given they have the same RR type (see also draft-ietf-dnsext-wcard-clarify [wcardclarify] regarding use of wildcards and DNS). You first mention a choice (generic RR or new RR) and then say this implies a selection mechanism -- does a new RR type imply a selection mechanism? And to the extent you're talking about selection, how about a reference to the previous section? The last bit of this section, re: things being in different zones, may confuse readers. Consider including examples or at least "it's possible for the prefixed name to be a delegation point, which would put the special RR (or generic RR) in the child zone" ----------------------- Section 3.3 Again, tell the reader clearly, up front and at the end, that this method is inferior. Again, consider a cite in the 2nd paragraph to 3.1 The last paragraph doesn't tell me what the IAB thinks of 2163. It's an example, but is it "this is okay"? Maybe move this up into the description as an example (of the bad thing), and then add a read closing paragraph briefly warning people off of this method. ----------------------- Section 3.4 Again, tell the reader clearly, up front and at the end, that this method is inferior. Again, consider a cite in the last paragraph to 3.1 Also add that resolvers would need hints to find the new class, making it not globally accessible. ----------------------- Section 3.5 This section doesn't parallel the others in Section 3, which disturbs me as a reader. Either have the others include this sort of breakdown (who has to grok what) or restructure this one. Again, there's little intro or conclusion in this section. Make it easier to skim, please. ----------------------- Section 4 "Using one of the naming modifications discussed in Section 3.2 and Section 3.3 would address the subtyping problem,..." Maybe I misunderstood what 3.2 and 3.3 were saying when they talked about another selection mechanism being needed. This sounds like an internal inconsistency, whether it is or not. This section is amazingly long -- I suspect it could be tightened up pretty easily. In the paragraph mentioning 2929, consider telling folks why this should make them happy in a little more detail: "getting a new type code assignment does not require the delay of RFC publication -- 2929 set aside part of the type code space as "Specification Required"", and consider repeating and citing the current definition of "specification required". -------------- Section 5 I find having two "conclusion" sections confusing and distracting -- rename Section 4, please. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 15:54:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25120 for ; Tue, 14 Jun 2005 15:54:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiHS3-0004PI-W5 for namedroppers-data@psg.com; Tue, 14 Jun 2005 19:51:59 +0000 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiHS3-0004Ox-G1; Tue, 14 Jun 2005 19:51:59 +0000 To: Samuel Weiler cc: namedroppers@ops.ietf.org, iana@iana.org Subject: Re: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) In-Reply-To: Message from Samuel Weiler of "Tue, 14 Jun 2005 12:23:23 EDT." Date: Tue, 14 Jun 2005 12:51:59 -0700 From: Allison Mankin X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: To Sam's point: RFC 2434 and RFC 2929 (and the IETF IANA practice) cause the allocation to appear in the registry when the document is approved, and then IANA updates the registry reference to the RFC number when the RFC is published. To Ed's point: There is a BCP providing for an early allocation practice for cases where the working group makes a careful justification (it also explains revocation if anything goes wrong). It has conditions; it can only be used for Standards Action policy codepoints (this woudl work for the kind of type code assignments being discussed here) and there are documentation requirements. Take a look at RFC 4020 (BCP 100). Allison -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 16:39:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04028 for ; Tue, 14 Jun 2005 16:39:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiI8b-000AGS-Gr for namedroppers-data@psg.com; Tue, 14 Jun 2005 20:35:57 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiI8a-000AG2-Gv for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 20:35:56 +0000 Received: from [10.31.32.153] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5EKZija000858; Tue, 14 Jun 2005 16:35:48 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 14 Jun 2005 16:35:52 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:51 -0700 6/14/05, Allison Mankin wrote: >Take a look at RFC 4020 (BCP 100). I agree with the premise of the document - especially that interoperability of implementations is the goal, and this is helped by number assignments. But I don't see the process in the document as a solution. Setting aside a segment of space for "early assignment" is not operationally tenable. E.g., what if one assignment from that space becomes a Full Standard - the space is now "polluted" by a real assignment. I've seen similar ideas in network address assignments. Segmenting number space (whether for addressing or coding) isn't that beneficial once you have "cross overs." By a cross-over, I mean a successful early assignment and a failed late assignment. I also think that requiring "standards track" is too high of a bar, or even getting WG consensus. What about things like the DNS A6 RR, which started as a standards track item and then slipped to experimental? For non-WG activities, i.e., those that sometimes lead to a BoF and then a WG, counting on finding a sympathetic ear of an Area Director sounds like a subjective process. Bureaucracies that rely on subjective processes don't scale well. Finally, a lot of us have thrown RFC 2929 around as the definition of the process IANA is to follow. How would I have navigated from RFC 2929 to RFC 4020 to see these new "rules?" -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 16:39:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04092 for ; Tue, 14 Jun 2005 16:39:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiI8Y-000AFw-WA for namedroppers-data@psg.com; Tue, 14 Jun 2005 20:35:54 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiI8X-000AFR-FP for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 20:35:54 +0000 Received: from [10.31.32.153] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5EKZijY000858; Tue, 14 Jun 2005 16:35:45 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> Date: Tue, 14 Jun 2005 16:15:48 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:38 -0400 6/14/05, Samuel Weiler wrote: >I'm confused. First I heard what sounded like a complaint that these >two type codes were issued based only on I-D's instead of RFCs, now >the text above. Perhaps they're not incongruous after all -- I >suppose one could want the process to change while still complaining >that the current process isn't being followed closely enough. Both appear to be problems. If the rules say "RFC or other permanent record" then any pre-assignment is out of order. It's not healthy if "but that's the way it works." If the rules are making "doing the right thing" hard or worse - encouraging short cutting the proces, then the rules ought to be changed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 17:04:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06224 for ; Tue, 14 Jun 2005 17:04:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiIXC-000Dqq-MM for namedroppers-data@psg.com; Tue, 14 Jun 2005 21:01:22 +0000 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiIXB-000Dqa-Tx; Tue, 14 Jun 2005 21:01:21 +0000 To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) In-Reply-To: Message from Edward Lewis of "Tue, 14 Jun 2005 16:35:52 EDT." Date: Tue, 14 Jun 2005 14:01:21 -0700 From: Allison Mankin X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Ed, > Setting aside a segment of space for "early assignment" is not > operationally tenable. E.g., what if one assignment from that space > becomes a Full Standard - the space is now "polluted" by a real > assignment. Perhaps you read a little fast. The space just becomes eligible for Early Assignment - it is not set aside en bloc foro early assignment. The normal Standards Track space is "amended to permit Early Allocation" so it has both early and normal allocations out of it. > I also think that requiring "standards track" is too high of a bar, > or even getting WG consensus. What about things like the DNS A6 RR, > which started as a standards track item and then slipped to > experimental? The point about making these assignments before the document is finished by the working group is make sure that the codepoint is for something stable and expected to need the acceleration of the deployment of the early allocation. The working group judges that. Did the A6 RR need that? If the working group and Chair had figured out a case for that, they'd ask the AD for that, and it would get the type early. We're only talking about time here, after all. It would get the codepoint later if not. > Finally, a lot of us have thrown RFC 2929 around as the definition of > the process IANA is to follow. How would I have navigated from RFC > 2929 to RFC 4020 to see these new "rules?" They're not yet new "rules" that update 2929 unless a given WG goes through the process of updating its space. At that point, the WG needs to have the knowledge, but also, we probably need to mark the RFC Index to say that RFC 4020 updates some other document (I'm not sure of this - I haven't brought this up with others). I brought up RFC 4020 because I guessed it hadn't crossed most WGs' paths, and because the IANA process interests me. Allison -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 17:09:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06409 for ; Tue, 14 Jun 2005 17:09:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiIcC-000ElN-VW for namedroppers-data@psg.com; Tue, 14 Jun 2005 21:06:32 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiIc9-000EgW-4F for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 21:06:29 +0000 Received: from [10.31.32.153] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5EL6Ifd001009; Tue, 14 Jun 2005 17:06:18 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Tue, 14 Jun 2005 17:06:20 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: some thoughts on name prefixes and new types Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk One of the most sacred tenets of DNS is that a query has three degrees of freedom - the qname, the qclass, and the qtype. One way to look at this is to melt all three into one field and call this the address of the desired information. In this perspective, using a new type code is functionally equivalent to requiring a prefix to the object name. (Where the object name refers to the name of what the application seeks data about, the qname remains the prefix.object name.) The difference between approaches relying on name prefixes and type codes lays in the mechanics of the system, by that I mean DNS and the surrounding software (shims). My hypothesis is that if adding new type codes is made the path of least resistance (including bureaucratically), then there is no need for name prefix approaches and hence no need for non-terminal wild cards. Breaking this down: 1) Getting a new and stable type code allotment ("leased" or "tenured") in the early stages of software development is a must. 2) Shim software is always type agnostic until the last moment of the code path. 3) DNS software is type agnostic except for the DNS special types, e.g., NS and others. 4) Fixing the terminology about "object names" - the "name" in the SRV record definition is not the same as the qname when a lookup is done. 5) Patience with the limited abilities of the record synthesis capability (known as wildcards), recalling that the mission of DNS is for lookups and not a directory or search mechanism. I think that #1 may be the only item in the list that needs original energy to be expended. By that I mean I think the fundamental definition of the how IANA is supposed to run the DNS type code registry needs to be overhauled. (Not the fault of IANA, not the fault of the editors of RFC 2929, this is a statement that we have learned lessons in the last 4+ years. Items 2-5 are statements of what should already be true. I concede that they may not be, that is why I referred to "original" energy in the previous paragraph. Item 1 After I sent a message that concluded from the lack of new non-DNSEXT type codes since RFC 2929 that the bureaucracy was the broken component, I realized it was possible that there had been no requests for new numbers. (I.e., going 0-for-0 is not an indication of a problem.) A post from says he was denied on the basis of not having an RFC. That's one instance, true. But it means that we are at least 0-for-1. Okay, still not a crime wave. If I were to begin an effort now and needed to put something in DNS, I would need access to a type code number that would be permanent. We are all aware of how code "goes operational" without anyone noticing - it's happened to all of us, so we shouldn't expect that it won't happen to the next generation of developers. I think that we need to lower the barrier to getting a number. This may leak numbers, so we also need to have a recall mechanism. This will work against careful planning, so I think we need to also let go of the idea that we should be allocating numbers in a nice orderly sequence. (Yeah, the NSEC record will suffer.) Item 2 Shim software has to be encouraged to be type-agnostic up until the shim is providing some application-data specific service. Especially if we expect to lease type codes to developers during development - kind of a rent-to-own program. (You own it when you have a referred document describing the type.) As long as the shim software is agnostic, it won't be in the way of changing definitions of type codes. Item 3 DNS has to peek into the RDATA of some types, but for other types there is no need. SOA, NS, address, are needed for lookups, CNAME and DNAME for processing lookups, and security records are needed too. MX isn't - as well as a bunch of other now defunct types. (Unless MX requires additional processing - adding the A records, for instance.) There is no reason that these have to be dumped in a XFR file in anything other than ugly hex notation. See a note later about viewing the hex as pretty-print. Item 4 Applications can think of entities as objects. Putting my SSH information for host singsing.prison.ny at "_ssh._tcp.singsing.prison.ny, qtype=TXT" or at "singsing.prison.ny, qtype=SSHDATA" is the same (functionally) to the application. I forget exactly what my point here is, I guess it is that the clinging to prefixes as a solution is a red herring. And I think that an update to the SRV definition document ought to fix the terminology bug. Item 5 One of the most forgotten but important tenets of my DNS religion is that the DNS is a meager beast and it needs to remain so. DNS is a lookup - you give it a query and it gives you the answer - and not much more. With the exception of some acid-trip ideas like CNAME, DNAME, and wild cards, it's a strictly what you put in is what you get out system. DNS is also the epicenter of the upper layers of the Internet. Using the old OSI reference model, layers 5-7 all need the DNS. It's even seeping downward, into things like VOIP and secure routing. Cutting to the chase, the simpler the DNS is, the simpler it's code is, and the more likely it won't suffer software bugs. Let's make it so that only bad disks, power outages, etc., are the reason servers go off line. Given it's simplicity and the need to make is as robust as possible, there is a need to build up management tools around it to make administration possible. The important thing to keep in mind is that these tools can be layered upon lowest common aspects - like hex dumps of records. When the A6 was designated an experimental record, "knocked down" from standards track, one of the concerns was that this meant DNS wasn't as agile for network renumbering. Someone pointed out that it would be trivial to write a PERL-like script to substitute the old network prefix with the new in all of the AAAA records, or to submit a series of dynamic updates to change them. Moral of the story is - move the management of the network up out of the DNS. CNAME, DNAME, and wildcards are three overly complicated yet underpowered features that have crept into the DNS. Okay, I'm being harsh on CNAME, but I think the three give a taste of a vastly more functional system and deliver on a part of the promise. The "holes" they don't fill trip up many folks, so much so that I wouldn't recommend the use of them in general. The five items may not be as simple as I have described, maybe there is a reason that name prefixes with generic data types will remain a desirable goal. If that happens, I think it's an accident of history and the times we live in and not something in the fundamental design and architecture of a name lookup system. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 17:19:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07079 for ; Tue, 14 Jun 2005 17:19:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiImQ-000GJZ-R8 for namedroppers-data@psg.com; Tue, 14 Jun 2005 21:17:06 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiImP-000GJ8-8j; Tue, 14 Jun 2005 21:17:06 +0000 Received: from [10.31.32.153] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5ELGuiC001058; Tue, 14 Jun 2005 17:16:57 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200506142101.j5EL1Ms3007365@willow.neustar.com> References: <200506142101.j5EL1Ms3007365@willow.neustar.com> Date: Tue, 14 Jun 2005 17:17:04 -0400 To: Allison Mankin From: Edward Lewis Subject: Re: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:01 -0700 6/14/05, Allison Mankin wrote: >Ed, > >> Setting aside a segment of space for "early assignment" is not >> operationally tenable. E.g., what if one assignment from that space >> becomes a Full Standard - the space is now "polluted" by a real >> assignment. > >Perhaps you read a little fast. The space just becomes >eligible for Early Assignment - it is not set aside en bloc >foro early assignment. The normal Standards Track space is "amended >to permit Early Allocation" so it has both early and normal >allocations out of it. " This memo only addresses the early allocation of code points from spaces whose allocation policy is "Standards Action" [2434] AND that have been amended to permit early allocation. This permission must" I interpreted "spaces whose policy" "have been amended to permit early allocation" to mean that only some of the "Standards Action" space is so designated. >> I also think that requiring "standards track" is too high of a bar, >> or even getting WG consensus. What about things like the DNS A6 RR, >> which started as a standards track item and then slipped to >> experimental? > >The point about making these assignments before the document is >finished by the working group is make sure that the codepoint is >for something stable and expected to need the acceleration of >the deployment of the early allocation. The working >group judges that. Did the A6 RR need that? If the working >group and Chair had figured out a case for that, they'd ask the >AD for that, and it would get the type early. We're only talking >about time here, after all. It would get the codepoint later >if not. I don't recall the how A6 got it's type code assignment. I'd also be curious of the case studies of SINK and OPT - as cases of a mature proposal that was ultimately killed and a successful proposal that got a wrong number. My interest isn't in trying to find blame, guilt, etc., but in finding out how we can do better in the future. I.e., why don't we have a document that says "don't try to use the SINK record because it proved to be an arguably bad idea and oh, by the way, here was the definition it had when it sunk (no pun intended)." By this I mean no disrespect to the people behind the effort to make the SINK record work, but I also wish we wouldn't mind documenting bad ideas as signposts for the future. >> Finally, a lot of us have thrown RFC 2929 around as the definition of >> the process IANA is to follow. How would I have navigated from RFC >> 2929 to RFC 4020 to see these new "rules?" > >They're not yet new "rules" that update 2929 unless a given WG >goes through the process of updating its space. At that point, >the WG needs to have the knowledge, but also, we probably need to >mark the RFC Index to say that RFC 4020 updates some other document >(I'm not sure of this - I haven't brought this up with others). >I brought up RFC 4020 because I guessed it hadn't crossed most WGs' >paths, and because the IANA process interests me. It sounds then like 4020 is an invitation to revisit 2929, to consider loosening our recommendations to IANA. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 19:06:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16808 for ; Tue, 14 Jun 2005 19:06:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiKQ2-00048w-Et for namedroppers-data@psg.com; Tue, 14 Jun 2005 23:02:06 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiKQ0-00048G-1W for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 23:02:04 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5EN1pNN001416 for ; Tue, 14 Jun 2005 19:01:51 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j5EN1pbW001415 for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 19:01:51 -0400 (EDT) (envelope-from namedroppers) Received: from [192.0.35.122] (helo=santee.icann.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgQAm-00085e-UE for namedroppers@ops.ietf.org; Thu, 09 Jun 2005 16:46:29 +0000 Received: from newiana (g35-170.icann.org [192.0.35.170] (may be forged)) by santee.icann.org (8.11.6/8.11.6) with ESMTP id j59GkUb06905; Thu, 9 Jun 2005 09:46:30 -0700 Message-Id: <200506091646.j59GkUb06905@santee.icann.org> From: "IANA" To: "'Samuel Weiler'" , "'Roy Arends'" Cc: Subject: RE: where did all them bits go ? (dns-parameters/dns-header-flags/dnskey-flags) Date: Thu, 9 Jun 2005 08:29:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcVoR0zG+RY6dE8PR8C/cjcLmgfSowEv/0JQ X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Following-up... The registries have been updated so that the approved dnssec I-Ds now shows as the published RFCs. Quick question.... You mention a citation to RFC2929, does this need to be added to any of these registries at this time? If so which ones and where? Or, will the -bis document make this update? Thanks, Michelle Cotton IANA -----Original Message----- From: Samuel Weiler [mailto:weiler@tislabs.com] Sent: Friday, June 03, 2005 7:18 AM To: Roy Arends Cc: namedroppers@ops.ietf.org; iana@iana.org Subject: Re: where did all them bits go ? On Fri, 3 Jun 2005, Roy Arends wrote: > I guess 4034 and 4035 are missing information on where exactly the CD > and AD bits reside in the DNS header. Its specified in rfc2535, but > omitted in the current drafts, which obsolete 2535. > > I'll send text. I concur that it's a good idea to mention this registry in draft-ietf-dnsext-dnssec-bis-updates just as 4034 section 7 mentioned, but did not change, (some of?) the other relevant ones. That said, since this is an IANA-managed registry[1] and the assignment is still documented in RFC2929 (BCP42), I don't think this is a big deal. A citation to 2929 is probably in order, too. Curiously, the IANA registry for those bits[1] still references the -protocol draft -- it was never updated to reflect the publication of RFC4035. It also doesn't mention 2929, which sets a threshhold for assigning a meaning to the Z bit (bit 9). The typecode registry [2] also still has refereces to -records and the ipseckey drafts. Sigh. I'm CC'ing this to IANA so they can fix both of these. Also, 4034 has an error in the IANA section (Section 7): the last paragraph claims that 3755 opened a registry [3] for KEY and DNSKEY flag values. That registry's applicablity was limited to only DNSKEY, not KEY, as noted in the registry. Since 4034 asserts that it's not making changes to IANA registries, I'll document this in bis-updates as an error in 4034, not a change to the registry. -- Sam, obsessive protocol geek [1] http://www.iana.org/assignments/dns-header-flags [2] http://www.iana.org/assignments/dns-parameters [3] http://www.iana.org/assignments/dnskey-flags -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 19:06:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16831 for ; Tue, 14 Jun 2005 19:06:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiKQs-0004DT-Fo for namedroppers-data@psg.com; Tue, 14 Jun 2005 23:02:58 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiKQr-0004D4-EE for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 23:02:57 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5EN2n6R001429 for ; Tue, 14 Jun 2005 19:02:49 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j5EN2neq001428 for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 19:02:49 -0400 (EDT) (envelope-from namedroppers) Received: from [66.163.169.227] (helo=smtp107.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dh3c0-000FDR-Tl for namedroppers@ops.ietf.org; Sat, 11 Jun 2005 10:53:13 +0000 Received: (qmail 58270 invoked from network); 11 Jun 2005 10:53:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Message-Id:X-Sender:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type; b=CM/zS1zHfHrdjyMulMKwE50rRqqUawqoDzWuKo7Fv7qnao7gzhjp6Qk4eNXQpQV3LmT3sD2e3DhGwU00suuhFzer2vrfcbPBP1ODa5It/lEO0hJYUBIKz1dFmUj9iD0euZPYKwBvEZV1C8WyMpyz77KhyLaUvhvj4zWu1WgrNeA= ; Received: from unknown (HELO phred.yahoo.com) (david?macquigg@216.183.69.45 with login) by smtp107.mail.sc5.yahoo.com with SMTP; 11 Jun 2005 10:53:12 -0000 Message-Id: <5.2.1.1.0.20050611034407.03495358@pop.mail.yahoo.com> X-Sender: david_macquigg@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 11 Jun 2005 03:54:08 -0700 To: John Levine , namedroppers@ops.ietf.org From: David MacQuigg Subject: Re: more thoughts on a set of TXT record clones Cc: paul@vix.com In-Reply-To: <20050611070031.16015.qmail@xuxa.iecc.com> References: <20050611041728.46A4013925@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] At 07:00 AM 6/11/2005 +0000, John Levine wrote: > >it's because there will always be devices who hope for simplicity in what > >they have to receive and parse and store and forward. > >Of course. But it strikes me that we're only talking about the bits >of DNS software that translate between RR's and zone-file-ese and have >to display or read representations of arbitrary RR types. Exactly. Maybe we could even define a default format for these displays - similar to what is used in bvi, hex on the left, ASCII on the right. This would involve no special-purpose activeX plugins. -- Dave ************************************************************ * * David MacQuigg, PhD email: david_macquigg at yahoo.com * * * IC Design Engineer phone: USA 520-721-4583 * * * * Analog Design Methodologies * * * * 9320 East Mikelyn Lane * * * * VRS Consulting, P.C. Tucson, Arizona 85710 * ************************************************************ * -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 19:53:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16832 for ; Tue, 14 Jun 2005 19:06:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiKQI-0004AJ-Ia for namedroppers-data@psg.com; Tue, 14 Jun 2005 23:02:22 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiKQF-00049t-6u for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 23:02:19 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5EN2BCU001423 for ; Tue, 14 Jun 2005 19:02:11 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j5EN2Bsh001422 for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 19:02:11 -0400 (EDT) (envelope-from namedroppers) Received: from [195.66.31.72] (helo=paf.se) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DgjtN-000LVL-6A for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 13:49:49 +0000 Received: from [64.100.238.233] (account paf HELO [192.168.1.100]) by paf.se (CommuniGate Pro SMTP 4.2.6) with ESMTP id 2487851 for namedroppers@ops.ietf.org; Fri, 10 Jun 2005 15:49:43 +0200 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D88CFE9-9D9B-4C6E-BEC4-EABCD6B70027@paf.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Re: draft-iab-dns-choices-02.txt comments Date: Fri, 10 Jun 2005 09:49:40 -0400 To: "IETF DNSEXT WG" X-Mailer: Apple Mail (2.730) X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] On Jun 8, 2005, at 20:58, wayne wrote: > Instead of using TXT, it is using a binary format called KR. That's > what dns-choices says to do, right? So this is good, right? Well, > they have used used RR type number 1010 (decimal), which isn't in the > range that RFC2929 says to use. Ooops. So now there are people out > there deploying 1010 RR numbers and if IIM dies, that RR number will > be polluted for many years to come. > What is the difference between this and pullute by having used TXT4711 for the same thing? paf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 19:53:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16833 for ; Tue, 14 Jun 2005 19:06:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiKRM-0004G5-SY for namedroppers-data@psg.com; Tue, 14 Jun 2005 23:03:28 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiKRK-0004Fh-Pb for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 23:03:27 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5EN3JB7001435 for ; Tue, 14 Jun 2005 19:03:19 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.12.11/8.12.11/Submit) id j5EN3J9B001434 for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 19:03:19 -0400 (EDT) (envelope-from namedroppers) Received: from [192.0.35.122] (helo=santee.icann.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiEUp-0005ux-UM for namedroppers@ops.ietf.org; Tue, 14 Jun 2005 16:42:40 +0000 Received: from newiana (g35-170.icann.org [192.0.35.170] (may be forged)) by santee.icann.org (8.11.6/8.11.6) with ESMTP id j5EGggb32419; Tue, 14 Jun 2005 09:42:42 -0700 Message-Id: <200506141642.j5EGggb32419@santee.icann.org> From: "IANA" To: "'Samuel Weiler'" , Subject: RE: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) Date: Tue, 14 Jun 2005 08:25:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcVw/a60Pww5G8nbRkqUsAi1Zssw5QACOP0g In-Reply-To: X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] Regarding the second paragraph in Sam's message: IANA has a process to update the reference in the registry after the RFC-Editor notifies the IANA what the RFC number is and the date of publication. We are a bit behind in updating these in efforts to get documents awaiting IANA actions for publication to the RFC-Editor, however we have already begun updating references where the document has been published as an RFC. I'll go ahead and take care of the (RFC4025) reference update today. Thanks, Michelle -----Original Message----- From: Samuel Weiler [mailto:weiler@tislabs.com] Sent: Tuesday, June 14, 2005 9:23 AM To: namedroppers@ops.ietf.org Cc: iana@iana.org Subject: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) On Mon, 13 Jun 2005, Edward Lewis wrote: > SSHFP 44 SSH Key Fingerprint [RFC-ietf-secsh-dns-05.txt] > IPSECKEY 45 IPSECKEY [RFC-ietf-ipseckey-rr-11.txt] > > Note that two of them are in pending RFC's, which kind of violates the > instructions in RFC 2929. I disagree. IANA has to do the assignment at some point in time, and, per the RFC Editor's processes, that's during the editing process[1]. That process has happened for SSHFP -- SSHFP is just waiting for a normative reference to be cleared up. And IPSECKEY (RFC4025) was published in February -- IANA just hasn't updated their registry (despite two notes on this list urging them to). Perhaps the IANA's processes need to include reviewing all published RFCs to remove these temporary citations in the registries. -- Sam [1] ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-process.gif -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 14 21:41:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25738 for ; Tue, 14 Jun 2005 21:41:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiMqT-000PiA-Dn for namedroppers-data@psg.com; Wed, 15 Jun 2005 01:37:33 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiMqQ-000PdX-JW for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 01:37:31 +0000 Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id B04DF414F0 for ; Tue, 14 Jun 2005 18:37:27 -0700 (PDT) Subject: Re: draft-iab-dns-choices-02.txt comments From: Douglas Otis To: IETF DNSEXT WG In-Reply-To: References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <1118739956.2160.229.camel@bash.adsl-64-142-13-68> Content-Type: text/plain Date: Tue, 14 Jun 2005 18:37:26 -0700 Message-Id: <1118799446.7922.150.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2005-06-14 at 05:01 -0500, wayne wrote: > Douglas Otis writes: > > > On Mon, 2005-06-13 at 12:29 -0500, wayne wrote: > >> MarkL also argues that the size savings of using a binary record type > >> isn't relevant. > > > > [...] Here is an SPF record published by a provider > > after extensive reduction efforts. This was done by listing large > > address blocks. This still required 236 bytes plus overhead to define > > this rather crude list. [...] > > > > This record could be done using a binary SPF TLV structure. Assume a > > TLV tag list of the following: > > > > [snip] > > > > This TLV binary approach reduces the RR size for _exactly_ the same data > > goes from 236 byte to 65 bytes. > > Using the libspf2 encoding, the record is reduced to 80 bytes. I know > that the libspf2 encoding is not ambiguous and handles all SPF > records, and includes support for versioning and such. Your encoding > can't handle things like -ip4 and such. I suspect that if you fleshed > out your idea to fully support SPF records, you would have to add a > few bytes to your 65 count. You missed inclusion of the technique used in the APL RR. ,--- | The ip4, ip6 tags would use a single byte CIDR notation, where when | the most significant bit is set in the mask, this would indicate this | range|of addresses are excluded. '--- The hurdle facing SPF is imposing a change to the typical scale of DNS answers. Normally a query provides information regarding a single service, where even a partial answer is often acceptable. With SPF, a query must scale to offering full results for potentially hundreds of discrete services. SPF uses a minimum of more than one hundred DNS lookups to achieve this. In one approach, you advocate text because people can read it. When confronting the size issue, you suggest compressed text. How does converting an entry form to a text script, then to compressed text, be better than a single conversion of an entry form into a TLV binary data? At least there are people that can read TLV binary data, whereas compressed information is more challenging. I was not suggesting the binary TLV example to make execution faster, although this would entail far less code and would be more extensible. I was attempting to illustrate how SPF scaling issues demand greater consideration of size constraints. SPF is already challenging the scalability, or for that matter, the suitability of DNS for this purpose. While Paul Vixie is right that DNS allows elements to be expressed as individual RRs, even this approach carries an overhead which works very much against the Herculean scaling goal of SPF. While SPF could be described as a script language, it is primarily attempting to authorize paths for a mailbox identity, with some term added to define the severity of a path authorization failure. The example TLV structure offers that capability. A process that demands recipients seek information in secession from perhaps more than one hundred domain name servers, makes defending this task difficult. With the inclusion of pointers, exists, and exp macros for somewhat related features, come at the expense of security. > The reduction is only a factor of 4 when you don't take into account > IP, UDP and DNS packet overhead. Currently the rr.com TXT record uses a > 411 byte DNS packet, IP packet overhead is 20 bytes and UDP adds 8 > bytes, giving a total of 439 bytes. If you reduce the SPF information > to 65 bytes, that drops it down to 268 bytes. > > This isn't even a factor of 2 reduction. Have you considered the problem created by the collision of subsequent RR reversions in this scripting scheme? The overhead remains relatively static, which returns focus on the actual RR size once again. Of course, the SPF draft also expects some cases will need many more than just one TXT record to resolve the authorized paths as well. > Ok, now take into account that the ip4: mechanism gets the best > compression of all SPF mechanisms. IPv4 addresses can use up to 15 > bytes in text, but only require 4 bytes in binary. IPv6 addresses use > hex and are therefore much more compact. All other mechanisms get > almost no benefit from binary encoding. The assumptions of benefits for other elements with names could be advantaged by DNS style binary techniques for name compression confined to the RR, as I have suggested. Even names include CIDR notation that also shrink by the same amount as seen in the ip4 example. Binary has served DNS well, yet you seem to insist only text is a valid choice. Adding scripts and compression, the ability to ensure secure code is made much more difficult. > I don't think this savings is worth that much compared with the > advantages of not having to update all the DNS software in > the world to be able to deal with a new format. Ensuring that RFC3597 allows implementation of new RR types could happen in less time, than changing the way email is handled to support SPF. SPF may eventually improve upon a repudiation process to some extent, depending upon odd schemes to daisy-chain bounce-addresses. However, SPF's authorization will never provide validations useful as a basis for reputation accrual, or even offering safe recipient assurances. Those advocating a filtering paradigm based upon SPF authorization as sufficient grounds for accruing reputations, have not considered how this may seriously hurt the average domain owner. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 15 07:09:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02341 for ; Wed, 15 Jun 2005 07:09:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiVfI-000PsJ-9N for namedroppers-data@psg.com; Wed, 15 Jun 2005 11:02:36 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiVfE-000Pmg-9w for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 11:02:32 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 8DEFE33C1A; Wed, 15 Jun 2005 12:02:32 +0100 (BST) Message-ID: <42B00B42.4020303@algroup.co.uk> Date: Wed, 15 Jun 2005 12:04:34 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> In-Reply-To: <20050613162800.9A85313A76@sa.vix.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>with ndots:2 and existing negative caching, life would be bearable. >> >>Now try with foo.bar.baz.example.co.uk where you need ndots:3 to be >>bearable. But then that would break example.com. > > > understood. > > >>I'm sure there was some discussion about tree traversing lookups on >>namedroppers about 6 months ago, quite possibly also SPF inspired >>(though I forget), and it was in general thought a "bad thing". > > > there was and it was. i was one of those arguing against it, in fact. > i'm not sure if anything has changed. so it's nonterminal wildcards or > nothing, huh? anybody else got a way out? anybody else got a preferred > zone file syntax other than ** ? I don't have another suggestion, but it seems to me that nonterminal wildcards are going to make nonexistence proofs in DNSSEC very hard indeed. -- >>>ApacheCon Europe<<< http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 15 07:47:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05041 for ; Wed, 15 Jun 2005 07:47:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiWJG-0005MA-CR for namedroppers-data@psg.com; Wed, 15 Jun 2005 11:43:54 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiWJE-0005Ll-8R for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 11:43:52 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id D2F84C2DA4; Wed, 15 Jun 2005 12:43:49 +0100 (BST) Date: Wed, 15 Jun 2005 12:43:45 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie , Paul Vixie Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: In-Reply-To: <42B00B42.4020303@algroup.co.uk> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 15 June 2005 12:04 +0100 Ben Laurie wrote: > I don't have another suggestion, but it seems to me that nonterminal > wildcards are going to make nonexistence proofs in DNSSEC very hard > indeed. Hmmm... yes. To be specific, because DNSSEC non-existence proofs fundamentally rely on a single canonical ordering of the zonefile, and the concept of a single closest encloser, we have a problem when the closest encloser can only be synthetic. We don't see this with RR-Type because non-existence applies to ANY RR, not the specific RR queried for. $ORIGIN example.com bar IN A 1.2.3.4 foo IN A 2.3.4.5 mail.** IN A 3.4.5.6 mail.foo IN A 4.5.6.7 mail.zag IN NS 5.6.7.8 mail.zap IN TXT "blah" zip IN A 6.7.8.9 And I query xyzzy.example.com, then there is no obvious closest encloser, because mail.xyxxx.example.com exists, as does mail.xyxxx.example.com (which in NSEC-classic each enclose xyzzy.example.com). To throw more rocks, what does a QTYPE=A query do for mail.bar.example.com mail.foo.example.com mail.zag.example.com mail.zap.example.com The same problem will, I think, occur with 4-Tuple-type queries or RR "subclasses" (assuming the server doesn't return all subclasses) unless the NSEC record is adapted to to indicate which subclasses are present and which are not (just as it does with RR-Types). Yuck. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 15 11:19:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25882 for ; Wed, 15 Jun 2005 11:19:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiZb1-000AlU-ME for namedroppers-data@psg.com; Wed, 15 Jun 2005 15:14:27 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiZb0-000Al6-Id for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 15:14:26 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j5FFASbF020252 for ; Wed, 15 Jun 2005 11:10:28 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYfaaIN; Wed, 15 Jun 05 11:10:25 -0400 Received: from localhost (weiler@localhost) by tislabs.com (8.12.9/8.12.9) with ESMTP id j5FFCLjW027985; Wed, 15 Jun 2005 11:12:21 -0400 (EDT) Date: Wed, 15 Jun 2005 11:12:21 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@filbert To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org Subject: Re: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07 In-Reply-To: <20050601162917.3444dc5b.olaf@ripe.net> Message-ID: References: <20050601162917.3444dc5b.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm glad I finally overcame my apprehensions about tackling this document. This doc is important, and I have very few issues with its technical content, but I think it needs some better intro/summary text in order to be read by the people who need it and perhaps a more uniform discussion of what does and doesn't work in order to be more useful for reference. In particular, the first couple of pages need a summary of the main things we expect implementers to miss, and we need a roadmap to the doc. That roadmap might suggest reading sections 3 and 4 first, then going back to the painful details in section 2. To me, the most useful parts were 1.3, 2.2.1, and section 4. Section 3 was a mixed bag. I'd really like to see 3 and 4 tightened up, and the items in 4 made more uniform and unambiguous. You may even want to reorder the doc, pulling the above-listed sections higher up and pushing details down. Here are some specific suggestions, starting from the back of the doc (since I found it to be the most valuable). Minor textual stuff has been sent to Ed privately. I do think these issues are worth delaying the doc for. I'm also worried that we haven't given enough consideration to sections 4.6 and 4.7 (wildcard DS and NSEC RRs). 4.3 (CNAME) Go ahead and put details here -- make all of these subparts of 4 tell the reader the same things: whether it makes sense to publish such RR's, whether they cause synthesis, and whether something weird happens. Go ahead and say them here, even if another section goes into greater detail. ----------- 4.4 (DNAME) Although verbose, this section is extremely clear -- it says what not to do, tells you why, and keeps repeating the mantra that this idea is stupid. I really like it. ---- 4.5 (SRV) This is not clear to me. Can we just say "this SRV record, since ..., does not cause anything to be synthesized"? Again, say "you can publish it, but it won't do what you're thinking". Possibly write about what would happen to *_tcp_.example., which might actually be useful. ---- 4.6 (DS) Meaningless and harmless, yes, but does it synthesize things? Generally, I would think so. But it's worth pointing out that a DS should normally only appear at a parent side zone cut, and refer back to the NS discussion. ------- 4.7 (NSEC) This is more the kind of description I was looking for, but I'm not sure it's correct. Does "query exactly matches the record" mean that QTYPE matches? If so, say that. And I'm not sure about the non-dangerous bit, either. This needs a little more thought. ----- 4.9 (empty non-terminals) Add an example? I don't follow this on a first read. --------------- 3.3.3 I got lost here, too -- I really want (I know I'm dreaming) something as simple as "wildcard CNAMEs work". Sadly, even 4.3 doesn't just come out and say something brief and understandable. I want something brief and understandable. For instance, for SOA's "yes, you can have a wildcard domain name owning an SOA, but it can't be used as a source of synthesis (or, even better, it doesn't lead to synthesis)" ------- 3.3.1 I didn't follow this section on this reading (much like 1.2) -- maybe I'll be able to say more next time. In general, though, Section 3 needs to do the same thing I'm suggesting for section 4 and the doc as a whole -- it needs an intro/summary in very plain language. Precise is good, too, but add a summary in plainer language. ------ Section 2.3 I'm wondering if there should be other cases included here, too. (Dynamic update messages, etc.) ----- Section 2.1.3 "A wild card domain name can have subdomains." this is also unclear to the casual reader -- can you have a zone cut at a wildcard label or not? Clarify here, referring to the relevant section (4.2) later. ------ Section 1.2 is where I started getting lost in the details. I suggest moving it somewhere else or even removing it. If it moves to section 2, add a warning at the end of section 1 and tell folks about the good things come in the later sections. In any case, move it below the definition of the #-convention. Speaking of the #-convention, I think it's ugly. Perhaps ask the RFC Editor now if they have a preference for what to use? ---- Section 1 As before, can we put a few gotchas here and some other reasons to read the whole thing? Maybe pulling the list from 1.3 higher up and adding a couple of examples? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 15 11:35:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27001 for ; Wed, 15 Jun 2005 11:35:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiZt9-000DOs-4V for namedroppers-data@psg.com; Wed, 15 Jun 2005 15:33:11 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiZt5-000DOF-Bw for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 15:33:07 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DiZsw-0004T4-0J for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 10:33:04 -0500 To: "IETF DNSEXT WG" References: <2D88CFE9-9D9B-4C6E-BEC4-EABCD6B70027@paf.se> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In-Reply-To: <2D88CFE9-9D9B-4C6E-BEC4-EABCD6B70027@paf.se> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) Date: Wed, 15 Jun 2005 10:32:57 -0500 Message-ID: MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable In <2D88CFE9-9D9B-4C6E-BEC4-EABCD6B70027@paf.se> Patrik writes: > On Jun 8, 2005, at 20:58, wayne wrote: > >> Instead of using TXT, it is using a binary format called KR. That's >> what dns-choices says to do, right? So this is good, right? Well, >> they have used used RR type number 1010 (decimal), which isn't in the >> range that RFC2929 says to use. Ooops. So now there are people out >> there deploying 1010 RR numbers and if IIM dies, that RR number will >> be polluted for many years to come. > > What is the difference between this and pullute by having used > TXT4711 for the same thing? The TXT4711 would hopefully have a magic number to allow us to distinguish the different uses of the same RR number. Right now, if we assign RR number 1010 to someone else, and you get a query, you have a binary glob that may or may not be the IIM KR record. Ok, we can probably tell KR records from the other records by looking at the size of the record and the format of the data. But, that is just a "really bad magic number". -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 15 11:46:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27515 for ; Wed, 15 Jun 2005 11:46:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dia3U-000F8l-LT for namedroppers-data@psg.com; Wed, 15 Jun 2005 15:43:52 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dia3S-000F4c-Px for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 15:43:50 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dia3H-0004f2-V5 for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 10:43:48 -0500 To: "IETF DNSEXT WG" References: <20050610164846.DA199418D@thrintun.hactrn.net> <8A834955-AF71-473E-A52F-3D855D38A985@cisco.com> <00e401c57055$b4b57890$8217a8c0@arport2v> <06C10095E8598BB12246E048@[192.168.100.25]> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Jun 2005 10:43:39 -0500 In-Reply-To: <06C10095E8598BB12246E048@[192.168.100.25]> (Alex Bligh's message of "Tue, 14 Jun 2005 09:48:23 +0100") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments: host names vs domain names X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <06C10095E8598BB12246E048@[192.168.100.25]> Alex Bligh writes: > --On 13 June 2005 15:48 -0500 wayne wrote: > >> The problem isn't as much in the applications as in things like DNS >> hosters. For example, GoDaddy (which recently passed NSI to become >> the largest registrar) does not allow me to create a TXT record with >> the name of _underscore_test.unified-spf.org. The inclusion of the >> underscore causes the webform to reject it. They also don't allow the >> creation of SRV records, let alone unknown types. > > Isn't this argument a bit backwards? IE don't these DNS hosting services > prohibit use of underscores precisely because there is no standards-based > protocol that mandates their use (and banning them for A records etc. > eliminates a lot of tech support calls from the clue deprived). Neither do > they support RR Types which have no standards-based definition. > > If you design the protocol right, vendors (software and hardware) will > support it. Ok, yes, you have a point. The problem with DNS hosting services only supporting hostnames and not domainnames will be solved if there is ever a compelling enough reason for them to accept the customer support headaches and customer education that they will have to do. Once DNS hosting services update their software, future _prefix schemes won't have to blaze that particular path. They will still have to educate the general public though about their protocol's usage of _prefix. > Case in point: most of these DNS vendors previously did not support SRV & > NAPTR records. I am betting, now these are becoming more useful, you will > see a roll-out (clearly they are already in Bind, and will over time get > into hosted DNS products). Should these have been implemented by TXT too, > because n years ago no vendors supported them? I think that the deployment of both the SRV and NAPTR records would have happened faster if they were based on the TXT## RR clone idea. Last year I think IETF-59, the subject of SRV record usage came up in conjunction with MARID. The Jabber folks were queried about their use of SRV records and they reported that there are still lots of deployment problems with them. SRV records may be used a lot in intranets because a single company/organization controls all the parts, but for an internet-wide protocol like Jabber is still running into problems. Of course, I we could probably easily start a flame war just by asking "should NAPTR records have been done?" instead of why kind of records they should use. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 15 11:55:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28071 for ; Wed, 15 Jun 2005 11:55:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiaBe-000GVv-6f for namedroppers-data@psg.com; Wed, 15 Jun 2005 15:52:18 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiaBb-000GV2-Op for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 15:52:16 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5FFq4NF005352; Wed, 15 Jun 2005 11:52:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20050601162917.3444dc5b.olaf@ripe.net> Date: Wed, 15 Jun 2005 11:52:09 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07 Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:12 -0400 6/15/05, Samuel Weiler wrote: >I'm glad I finally overcame my apprehensions about tackling this >document. I wish I could overcome my apprehensions about the document as well. >This doc is important, and I have very few issues with its technical >content, but I think it needs some better intro/summary text in order >to be read by the people who need it and perhaps a more uniform >discussion of what does and doesn't work in order to be more useful >for reference. In particular, the first couple of pages need a >summary of the main things we expect implementers to miss, and we need >a roadmap to the doc. That roadmap might suggest reading sections 3 >and 4 first, then going back to the painful details in section 2. I find it difficult to provide "a summary of" what "we expect implementers to miss" especially as this is a supplemental document and not introducing a new idea. >To me, the most useful parts were 1.3, 2.2.1, and section 4. Section >3 was a mixed bag. I'd really like to see 3 and 4 tightened up, and >the items in 4 made more uniform and unambiguous. You may even want >to reorder the doc, pulling the above-listed sections higher up and >pushing details down. 1.3 is a roadmap, 2.2.1 are examples, and I consider (as editor) section 4 to be the least important part of the document. The document is about the commentary on RFC 1034 - in the spirit of clarifying it - so section 3 is the heart of the effort. Section 4 is "how the rubber meets the road" so to speak. >Here are some specific suggestions, starting from the back of the doc >(since I found it to be the most valuable). Minor textual stuff has >been sent to Ed privately. I do think these issues are worth delaying >the doc for. I'm also worried that we haven't given enough >consideration to sections 4.6 and 4.7 (wildcard DS and NSEC RRs). Now's the time to consider them (DS and NSEC). Keep in mind that this is not meant to be a tutorial on wild cards for the benefit of implementers nor for the benefit of operators. The goal of the document is to fill in gaps in the description of RFC 1034. The goal of IETF documents is to be clear enough that diverse sets of readers can arrive at interoperable understandings. Interoperable understandings does not mean "do it the same way." This document has already been in the making for sometime. Please make comments now that are complete. I want to move on from editing this, there are other things to do. There's something to be said for "if it were really important, it would have come up in time." I'm not going to address the remainder of the comment. I invite other members of the WG to do so - I'm just editing. I will add this - the style of the document is to dive into details of the "science" and then back out to the impacts on records. This is not the only style for a technical document. If I were writing this as a "marketing the idea" I would put the features and conclusions first, followed by successive detail justifying the previous point. But that isn't the purpose of the document, the purpose is to bolster RFC 1034. As far as uneven detail, yes, the document has that, but this is not a standalone document. The lack of clarity evident in the original varies, this document is filling in. The document is not a great literary work - partly because it has taken so long to get to where it is. >4.3 (CNAME) > >Go ahead and put details here -- make all of these subparts of 4 tell >the reader the same things: whether it makes sense to publish such >RR's, whether they cause synthesis, and whether something weird >happens. Go ahead and say them here, even if another section goes >into greater detail. > >----------- > >4.4 (DNAME) > >Although verbose, this section is extremely clear -- it says what not >to do, tells you why, and keeps repeating the mantra that this idea is >stupid. I really like it. > >---- > >4.5 (SRV) > >This is not clear to me. Can we just say "this SRV record, since ..., >does not cause anything to be synthesized"? Again, say "you can >publish it, but it won't do what you're thinking". Possibly write >about what would happen to *_tcp_.example., which might actually be >useful. > >---- > >4.6 (DS) > >Meaningless and harmless, yes, but does it synthesize things? >Generally, I would think so. But it's worth pointing out that a DS >should normally only appear at a parent side zone cut, and refer back >to the NS discussion. > >------- > >4.7 (NSEC) > >This is more the kind of description I was looking for, but I'm not >sure it's correct. Does "query exactly matches the record" mean that >QTYPE matches? If so, say that. > >And I'm not sure about the non-dangerous bit, either. This needs a >little more thought. > >----- > >4.9 (empty non-terminals) > >Add an example? I don't follow this on a first read. > >--------------- > >3.3.3 > >I got lost here, too -- I really want (I know I'm dreaming) something >as simple as "wildcard CNAMEs work". Sadly, even 4.3 doesn't just >come out and say something brief and understandable. I want something >brief and understandable. For instance, for SOA's "yes, you can have >a wildcard domain name owning an SOA, but it can't be used as a source >of synthesis (or, even better, it doesn't lead to synthesis)" > >------- > >3.3.1 > >I didn't follow this section on this reading (much like 1.2) -- maybe >I'll be able to say more next time. In general, though, Section 3 >needs to do the same thing I'm suggesting for section 4 and the doc >as a whole -- it needs an intro/summary in very plain language. >Precise is good, too, but add a summary in plainer language. > >------ > >Section 2.3 > >I'm wondering if there should be other cases included here, too. >(Dynamic update messages, etc.) > >----- > >Section 2.1.3 > > "A wild card domain name can have subdomains." this is also unclear >to the casual reader -- can you have a zone cut at a wildcard label or >not? Clarify here, referring to the relevant section (4.2) later. > >------ > >Section 1.2 is where I started getting lost in the details. I suggest >moving it somewhere else or even removing it. If it moves to section >2, add a warning at the end of section 1 and tell folks about the good >things come in the later sections. In any case, move it below the >definition of the #-convention. > >Speaking of the #-convention, I think it's ugly. Perhaps ask the RFC >Editor now if they have a preference for what to use? > >---- > >Section 1 > >As before, can we put a few gotchas here and some other reasons to >read the whole thing? Maybe pulling the list from 1.3 higher up and >adding a couple of examples? > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 15 16:08:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22406 for ; Wed, 15 Jun 2005 16:08:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Die6H-0001SL-Ev for namedroppers-data@psg.com; Wed, 15 Jun 2005 20:03:01 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Die6F-0001S2-Qy for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 20:02:59 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 2346D13925 for ; Wed, 15 Jun 2005 20:02:59 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Wed, 15 Jun 2005 12:43:45 +0100." References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 15 Jun 2005 20:02:59 +0000 Message-Id: <20050615200259.2346D13925@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I don't have another suggestion, but it seems to me that nonterminal > > wildcards are going to make nonexistence proofs in DNSSEC very hard > > indeed. > > Hmmm... yes. To be specific, because DNSSEC non-existence proofs > fundamentally rely on a single canonical ordering of the zonefile, and the > concept of a single closest encloser, we have a problem when the closest > encloser can only be synthetic. We don't see this with RR-Type because > non-existence applies to ANY RR, not the specific RR queried for. indeed, this is why moving the wildcard processing to the requestor, and not doing any responder-side synthesis at all, seems strongly indicated. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 15 18:09:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10415 for ; Wed, 15 Jun 2005 18:09:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dig0J-000JO3-8k for namedroppers-data@psg.com; Wed, 15 Jun 2005 22:04:59 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dig0G-000JNc-7U for namedroppers@ops.ietf.org; Wed, 15 Jun 2005 22:04:56 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id E593EC2DA4; Wed, 15 Jun 2005 23:04:54 +0100 (BST) Date: Wed, 15 Jun 2005 23:04:54 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: In-Reply-To: <20050615200259.2346D13925@sa.vix.com> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 15 June 2005 20:02 +0000 Paul Vixie wrote: >> Hmmm... yes. To be specific, because DNSSEC non-existence proofs >> fundamentally rely on a single canonical ordering of the zonefile, and >> the concept of a single closest encloser, we have a problem when the >> closest encloser can only be synthetic. We don't see this with RR-Type >> because non-existence applies to ANY RR, not the specific RR queried for. > > indeed, this is why moving the wildcard processing to the requestor, and > not doing any responder-side synthesis at all, seems strongly indicated. How does that work? I presume something like, with every query, return any wildcard record that might match it OR a proof of nonexistence illustrating there is no such wildcard (else there is a MiM attack in stripping wildcards from responses). In which case aren't you back with the same problem with non-terminal wildcards, in that you they are "not in order"? Clearly one can return the whole zone in response to each query, but that's presumably not a desirable form of requester processing :-) Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 00:35:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15579 for ; Thu, 16 Jun 2005 00:35:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dilyo-000DqF-Jn for namedroppers-data@psg.com; Thu, 16 Jun 2005 04:27:50 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dilyn-000Dpz-1H for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 04:27:49 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 185A713925 for ; Thu, 16 Jun 2005 04:27:47 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Wed, 15 Jun 2005 23:04:54 +0100." References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 16 Jun 2005 04:27:47 +0000 Message-Id: <20050616042747.185A713925@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ..., this is why moving the wildcard processing to the requestor, and > > not doing any responder-side synthesis at all, seems strongly indicated. > > How does that work? I presume something like, with every query, return > any wildcard record that might match it OR a proof of nonexistence > illustrating there is no such wildcard (else there is a MiM attack > in stripping wildcards from responses). yes. and in the case of a nonterminal wildcard, that's one NSEC RR. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 03:23:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21483 for ; Thu, 16 Jun 2005 03:23:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DioeX-0005Ee-G8 for namedroppers-data@psg.com; Thu, 16 Jun 2005 07:19:05 +0000 Received: from [81.228.8.164] (helo=pne-smtpout2-sn2.hy.skanova.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DioeT-0005E3-Ar for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 07:19:01 +0000 Received: from arport2v (212.181.176.157) by pne-smtpout2-sn2.hy.skanova.net (7.2.059.6) id 429C53B6003813EF for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 09:18:56 +0200 Message-ID: <002901c57244$22483fb0$8217a8c0@arport2v> From: "Anders Rundgren" To: References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> Subject: IANA is NOT the problem. Was: draft-iab-dns-choices-02.txt Date: Thu, 16 Jun 2005 09:22:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The problem with adding new DNS data types is often associated with the IANA registration process for new RR types. Although this is indeed a problem (I have tried it myself so I should know), the fundamental problem is that this way of allocating/defining a new data type differs from most (if not all), other Internet-related extension schemes. For instance, anybody can within a URI-space they have control of, define a new XML schema and immediately begin to use it in an arbitrary small or large community. The same is valid for adding an X.509v3 certificate extension, as long as you do it on your own OID ARC, you may add an extension without interfering with other peoples' extensions. Both of these extension schemes are independent of a central extension registry like IANA, as domain and OID registries have no opinion on the what you actually use your domain or OID for. The "publishing" of a particular extension may due to that span from being in the head of the developer, to being a part of an internationally acclaimed standard. ========================================= The only existing DNS extension scheme that meets the requirement that a "user community" may go from one person to the entire planet, is using translated, URI-encoded, host-prefixes linked to a universal container-type such as TXT. ========================================= That is, if there are any thoughts (can't really see why it is needed) of creating a new DNS data type extension scheme, it MUST allow fully distributed development and definitions, preferably by building on already existing name-space schemes. Just my 2 cents Anders Rundgren -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 04:56:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27927 for ; Thu, 16 Jun 2005 04:56:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Diq5y-000Eti-FT for namedroppers-data@psg.com; Thu, 16 Jun 2005 08:51:30 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Diq5u-000Ese-It for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 08:51:26 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id CB72233C1B; Thu, 16 Jun 2005 09:51:25 +0100 (BST) Message-ID: <42B13E08.2040102@algroup.co.uk> Date: Thu, 16 Jun 2005 09:53:28 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> In-Reply-To: <20050616042747.185A713925@sa.vix.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Vixie wrote: >>>..., this is why moving the wildcard processing to the requestor, and >>>not doing any responder-side synthesis at all, seems strongly indicated. >> >>How does that work? I presume something like, with every query, return >>any wildcard record that might match it OR a proof of nonexistence >>illustrating there is no such wildcard (else there is a MiM attack >>in stripping wildcards from responses). > > > yes. and in the case of a nonterminal wildcard, that's one NSEC RR. At least one per dot, surely? Plus one for the terminal wildcard. -- >>>ApacheCon Europe<<< http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 05:39:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01342 for ; Thu, 16 Jun 2005 05:39:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiqnX-000JJB-54 for namedroppers-data@psg.com; Thu, 16 Jun 2005 09:36:31 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DiqnT-000JIu-M9 for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 09:36:27 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 73D86C2DA7; Thu, 16 Jun 2005 10:36:26 +0100 (BST) Date: Thu, 16 Jun 2005 10:36:25 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Paul Vixie , namedroppers@ops.ietf.org Cc: Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: <149F1464A2400B7D173C32C5@[192.168.100.25]> In-Reply-To: <20050616042747.185A713925@sa.vix.com> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 16 June 2005 04:27 +0000 Paul Vixie wrote: >> How does that work? I presume something like, with every query, return >> any wildcard record that might match it OR a proof of nonexistence >> illustrating there is no such wildcard (else there is a MiM attack >> in stripping wildcards from responses). > > yes. and in the case of a nonterminal wildcard, that's one NSEC RR. I'm still being dumb (or alternatively it's really ugly and you're OK with that!). The whole principle of NSEC is that it proves non-existence of all names between the closest enclosers of the QNAME. Whilst obviously one can still canonically order QNAMEs, with non-terminal wildcards, isn't the concept of a single closest encloser ill-defined (or to be more accurate multi-valued)? What I mean by the above is that if wildcard processing is being done client (requester) side, don't you now have to prove (putting traditional wildcards aside for a minute) a) that the QNAME itself doesn't exist b) that no non-terminal wildcard covers the QNAME in question. I'm interested in how one might prove (b), because non-terminal wildcards can appear anywhere in the ordering. If I restrict the names-space to 3 character alpha to illustrate the point (because successor and predecessor are easier to calculate): $ORIGIN example.com ghi.** IN A 1.1.1.1 jlk.** IN A 2.2.2.2 abc IN A 1.2.3.4 def IN A 2.3.4.5 jkl IN A 3.4.5.6 IF I send a query for aaa.ddd.example.com, I need to prove not only that aaa.ddd does not exist. With client (requester) side processing, sending an interval like def NSEC jkl is not sufficient to prove it, because it doesn't tell me there is no non-terminal wildcard that might match - for instance there might have been a record like aaa.** IN A 7.7.7.7 So I will have to tell the requester client about EVERY non-terminal wildcard. So I will have to do something like . NSEC ghi.** ghi.** NSEC jkl.** jkl.** NSEC abc (and that's enough, because abc has no ** in, I can now assure the sender they've got all the non-terminal wildcards). If we don't do this, the requester cannot securely prove the non-existence of aaa.ddd.example.com because there might HAVE been the 7.7.7.7 non-terminal wildcard there, and the reply only proving the non-existence of the record itself might have been replayed by a man in the middle. Aside from the fact every answer size is now multiplied by the number of non-terminal wildcards, the situation would seem to get even hairier when non-terminal wildcards can exist at multiple levels to the left of the zone-cut, for instance foo.**.bar and foo.baz.**. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From DebbiePinkus@bovinity.net Thu Jun 16 05:51:44 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02023; Thu, 16 Jun 2005 05:51:44 -0400 (EDT) Received: from cpe-24-28-154-227.satx.res.rr.com ([24.28.154.227]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DirP7-0008J7-1H; Thu, 16 Jun 2005 06:15:28 -0400 Received: from IEkj@localhost by siZX.int (8.11.6/8.11.6); Thu, 16 Jun 2005 13:49:58 +0300 Message-ID: <0Jfq6pP3LGlMwzXpE27p@openbills.net> From: "Helen Nunez" Reply-To: "Helen Nunez" To: 15@ietf.org Subject: Windows XP Pro $49.95 Windows XP Date: Thu, 16 Jun 2005 04:57:58 -0600 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: DebbiePinkus@bovinity.net Content-Type: multipart/mixed; boundary="--eCT7ZUnWKfU8N8oM" X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Rbi ----eCT7ZUnWKfU8N8oM Content-Type: text/html; Content-Transfer-Encoding: quoted-printable P
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH
=

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>

 = ON SALE NOW!

 1 Off= ice Pro 2003
 2 Windows = XP Pro
 3 Adobe Creativ= e Suite Premium
 4 Norto= n Antivirus 2005
 5 Fla= sh MX 2004
 = 6 Corel Dra= w 12
 7 Adobe Acrobat 7.= 0
 8 Windows 2003 Serve= r
 9 Alias Maya 6 Wavef= rt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   A= pple Software
 <= /td> Customers also bought
   these other= items...
=



Microsoft Office Professional E= dition *2003*
= Microsoft
<= table border=3D0>Choose:
<= a href=3Dhttp://ipoemed.com/?B> 
<= /tr>
List Price:$899.00
Price:$69.99
Y= ou Save:$830.01 (92%)


Availability: Available for INSTANT download= !
Coupon Code: ISe229
Media: CD-ROM / Download
<= /span>
System requ= irements  |  Accessories=   |  Other Versions

Features:

    Analyze and manage business information usin= g Access databases
  • Exchange = data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced = IRM technology
  • Easy-to-use w= izards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business= reports
Sales Rank: #1=
Shipping: International/US or via instant downloa= d
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft

=
Choose:
 
List Price:$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download
System requirements=   |  Accessories  |=   Other Versions

= Features:

  • Designed for businesses of all sizes
    • =
  • Manage digital pictures, music, video, D= VDs, and more
  • More security = with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows server= s and management solutions

Sales= Rank: #2
Shipping: International/US or via in= stant download
Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe
=
Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D44 width=3D190><= tr>		 List Price: $599.00
Price:$69.99
Yo= u Save:$529.01 (90%)


Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
Media: CD-ROM / Download

System requir= ements  |  Accessories&n= bsp; |  Other Versions

=

Features:

    <= li class=3Dsmall>Customized workspace; save personalized wo= rkspace and tool settings; create customized shortcuts
  • Unparalleled efficiency--automate production t= asks with built-in or customized scripts
  • Improved file management, new design possibilities, and a mor= e intuitive way to create for the Web
  • Support for 16-bit images, digital camera raw data, and non-squa= re pixels
  • Create or modify p= hotos using painting, drawing, and retouching tools

Sales Rank: #3
Shipping= : International/US or via instant download
Date Coupon Expires:= June 30th, 2005
Average Customer Rev= iew: 3D"5 Based on 498 reviews. Wr= ite a review.

= ----eCT7ZUnWKfU8N8oM-- From owner-namedroppers@ops.ietf.org Thu Jun 16 08:25:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13593 for ; Thu, 16 Jun 2005 08:25:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DitLc-0005mN-9g for namedroppers-data@psg.com; Thu, 16 Jun 2005 12:19:52 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DitLa-0005m5-Er for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 12:19:50 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j5GCJnDh006473 for ; Thu, 16 Jun 2005 05:19:49 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 16 Jun 2005 05:19:48 -0700 Received: from [17.219.196.130] ([17.219.196.130]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id j5GCJlaG026125; Thu, 16 Jun 2005 05:19:47 -0700 (PDT) Message-Id: <200506161219.j5GCJlaG026125@relay3.apple.com> Subject: Re: [dhcwg] dhc WG last call on Date: Thu, 16 Jun 2005 13:19:46 +0100 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >This message announces a WG last call on "Resolution of DNS Name >Conflicts among DHCP Clients" . I just took a look at this, and it appears to have a trivial race condition: 6.3.1 Initial DHCID RR Query When a DHCP client or server intends to update an A or AAAA RR, it performs a DNS query with QNAME of the target name and with QTYPE of DHCID. If the query returns NXDOMAIN, the updater can conclude that the name is not in use and proceeds to Section 6.3.2. What if two clients do this at the same time? Surely this non-existence of the DHCID record needs to be expressed as a required precondition in the DNS UPDATE, so that it's performed conceptually as an atomic test-and-set operation? In fact, that's exactly what Section 6.3.2 says, making Section 6.3.1 completely redundant. Since the protocol has to work even when the Section 6.3.1 test yields the wrong result, Section 6.3.1 serves no purpose and should just be deleted. Also, while I like the idea of DNS UPDATE clients being able effectively to tag their records to help identify later who was responsible for creating the record, I think the proposed DHCID solution is too DHCP-centric. IPv6 clients using stateless address autoconfiguration want to use DNS UPDATE too, and in order to be good citizens, they want to be able to tell whether the records they're about to stomp all over belong to them or to a different DNS UPDATE client. We need a tagging solution that works for both v4 and v6, without pre-supposing DHCP. This is more than a passing academic interest. Starting in Mac OS X 10.4 Tiger, Apple now ships a Secure DNS UPDATE client: We face exactly the problems raised in this draft. Some sites configure per-user keys, in which case there's no problem because conflicts are simply not possible, because a user cannot update another's name. However, for the sake of similicity many sites configure a single site key for DNS update, trusting the users to cooperate with each other. Trusting users to cooperate is fine when the users are trustworthy and willing to cooperate, but even willing trustworthy users can't cooperate when the mechanisms for cooperation don't exist. Most people are willing to avoid stomping over someone else's name, but you can't expect them to do that if they have no reasonable way to know that the name is someone else's. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 09:35:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19967 for ; Thu, 16 Jun 2005 09:35:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DiuT0-000BM4-JP for namedroppers-data@psg.com; Thu, 16 Jun 2005 13:31:34 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DiuSx-000BLa-Ek for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 13:31:31 +0000 Received: from [192.168.1.100] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5GDVKem010732; Thu, 16 Jun 2005 09:31:21 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <002901c57244$22483fb0$8217a8c0@arport2v> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> <002901c57244$22483fb0$8217a8c0@arport2v> Date: Thu, 16 Jun 2005 09:29:57 -0400 To: "Anders Rundgren" From: Edward Lewis Subject: Re: IANA is NOT the problem. Was: draft-iab-dns-choices-02.txt Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:22 +0200 6/16/05, Anders Rundgren wrote: >The problem with adding new DNS data types is often associated >with the IANA registration process for new RR types. Although >this is indeed a problem (I have tried it myself so I should know), >the fundamental problem is that this way of allocating/defining >a new data type differs from most (if not all), other Internet-related >extension schemes. > >For instance, anybody can within a URI-space they have control >of, define a new XML schema and immediately begin to use it >in an arbitrary small or large community. > >The same is valid for adding an X.509v3 certificate extension, as long >as you do it on your own OID ARC, you may add an extension without >interfering with other peoples' extensions. But you have to get an OID from a central location. There are many, including IANA, that do this. The bureaucratic burden is negligible. The difference between the URI and x509v3 environments is that you are not dealing with a fixed length field as is the case DNS. You can't run out of OID's, for instance. >Both of these extension schemes are independent of a central extension >registry like IANA, as domain and OID registries have no opinion on the >what you actually use your domain or OID for. The "publishing" of a >particular extension may due to that span from being in the head of the >developer, to being a part of an internationally acclaimed standard. > >========================================= >The only existing DNS extension scheme that meets the requirement >that a "user community" may go from one person to the entire >planet, is using translated, URI-encoded, host-prefixes linked to a >universal container-type such as TXT. >========================================= But is that the role of DNS? Is that only because the label space is less regulated than the type code space? The label space is size-limited, and when you get into multi-byte-per-glyph scripts, it shrinks up fast. >That is, if there are any thoughts (can't really see why it is needed) of >creating a new DNS data type extension scheme, it MUST allow fully distributed >development and definitions, preferably by building on already existing name- >space schemes. > >Just my 2 cents DNS is supposed to be lightweight and simple. That has translated into fixed size boundaries of fields - to simplify parsing code - with fixed semantics. Self-describing data is great, but it take the end pieces longer to process it. Plus, more moving parts are needed, which may (may) break. I'm not debating the benefits of the extensibility of URI's or X509v3 against DNS. The extensibility of the two are very useful but do come at a cost. That cost *was* not affordable in the days of the design of the DNS. That cost may still not be affordable at the architectural level of the DNS today. (I.e., DNS is under applications.) Had the extensibility of URI's/x509v3/et.al. been affordable a decade ago, we would be seeing a lot more LDAP, x500, and ASN.1 deployment. I think that's the pragmatic demonstration of my contention. (I won't say proof.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 11:07:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29524 for ; Thu, 16 Jun 2005 11:07:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Divu7-000ImQ-S6 for namedroppers-data@psg.com; Thu, 16 Jun 2005 15:03:39 +0000 Received: from [81.228.11.159] (helo=pne-smtpout2-sn1.fre.skanova.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Divu4-000Ilh-PV for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 15:03:36 +0000 Received: from arport2v (195.252.44.73) by pne-smtpout2-sn1.fre.skanova.net (7.2.059.6) id 42930AA900542265; Thu, 16 Jun 2005 17:03:30 +0200 Message-ID: <006f01c57285$0742c3c0$8217a8c0@arport2v> From: "Anders Rundgren" To: "Edward Lewis" Cc: References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> <002901c57244$22483fb0$8217a8c0@arport2v> Subject: Re: IANA is NOT the problem. Was: draft-iab-dns-choices-02.txt Date: Thu, 16 Jun 2005 17:06:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ed, >But is that the role of DNS? Is that only because the label space is >less regulated than the type code space? Absolutely. That was a nice way of expressing it BTW :-) >The label space is size-limited, and when you get into multi-byte-per-glyph >scripts, it shrinks up fast. I don't understand why this is fact if you allow multi-label prefixes. Today's de-facto DNS data type extension standard: _shortprefix.example.com TXT "blah" This works perfect in most cases except in this list :-| A slightly cleaner version of the de-facto standard could spell: http_2_4_4xmlns_1b2bstandards_1org_42005-01-01_4_registry.example.com TXT "blah" which using a URI translation scheme[*] declares a data object of the type: http://xmlns.b2bstandards.org/2005-01-01/Registry in "example.com". >DNS is supposed to be lightweight and simple. That has translated >into fixed size boundaries of fields - to simplify parsing code - >with fixed semantics. Self-describing data is great, but it take the >end pieces longer to process it. Plus, more moving parts are needed, >which may (may) break. For DNS servers this adds no extra work AFAIK. It is just another label. Long URIs would produce dot-separated labels but that does not hurt either. I would not call this self-describing data. It is only a GUID scheme for defining data types. The actual data type definition is held by each GUID definer and may be in any shape. Anders *] Any agreed-upon will do fine. ----- Original Message ----- From: "Edward Lewis" To: "Anders Rundgren" Cc: Sent: Thursday, June 16, 2005 15:29 Subject: Re: IANA is NOT the problem. Was: draft-iab-dns-choices-02.txt At 9:22 +0200 6/16/05, Anders Rundgren wrote: >The problem with adding new DNS data types is often associated >with the IANA registration process for new RR types. Although >this is indeed a problem (I have tried it myself so I should know), >the fundamental problem is that this way of allocating/defining >a new data type differs from most (if not all), other Internet-related >extension schemes. > >For instance, anybody can within a URI-space they have control >of, define a new XML schema and immediately begin to use it >in an arbitrary small or large community. > >The same is valid for adding an X.509v3 certificate extension, as long >as you do it on your own OID ARC, you may add an extension without >interfering with other peoples' extensions. But you have to get an OID from a central location. There are many, including IANA, that do this. The bureaucratic burden is negligible. The difference between the URI and x509v3 environments is that you are not dealing with a fixed length field as is the case DNS. You can't run out of OID's, for instance. >Both of these extension schemes are independent of a central extension >registry like IANA, as domain and OID registries have no opinion on the >what you actually use your domain or OID for. The "publishing" of a >particular extension may due to that span from being in the head of the >developer, to being a part of an internationally acclaimed standard. > >========================================= >The only existing DNS extension scheme that meets the requirement >that a "user community" may go from one person to the entire >planet, is using translated, URI-encoded, host-prefixes linked to a >universal container-type such as TXT. >========================================= But is that the role of DNS? Is that only because the label space is less regulated than the type code space? The label space is size-limited, and when you get into multi-byte-per-glyph scripts, it shrinks up fast. >That is, if there are any thoughts (can't really see why it is needed) of >creating a new DNS data type extension scheme, it MUST allow fully distributed >development and definitions, preferably by building on already existing name- >space schemes. > >Just my 2 cents DNS is supposed to be lightweight and simple. That has translated into fixed size boundaries of fields - to simplify parsing code - with fixed semantics. Self-describing data is great, but it take the end pieces longer to process it. Plus, more moving parts are needed, which may (may) break. I'm not debating the benefits of the extensibility of URI's or X509v3 against DNS. The extensibility of the two are very useful but do come at a cost. That cost *was* not affordable in the days of the design of the DNS. That cost may still not be affordable at the architectural level of the DNS today. (I.e., DNS is under applications.) Had the extensibility of URI's/x509v3/et.al. been affordable a decade ago, we would be seeing a lot more LDAP, x500, and ASN.1 deployment. I think that's the pragmatic demonstration of my contention. (I won't say proof.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 13:02:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11071 for ; Thu, 16 Jun 2005 13:02:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dixi1-0001ZE-Nt for namedroppers-data@psg.com; Thu, 16 Jun 2005 16:59:17 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dixhz-0001Yx-WE for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 16:59:16 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5717313925 for ; Thu, 16 Jun 2005 16:59:15 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments In-Reply-To: Your message of "Thu, 16 Jun 2005 09:53:28 +0100." <42B13E08.2040102@algroup.co.uk> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> <42B13E08.2040102@algroup.co.uk> X-Mailer: MH-E 7.82; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 16 Jun 2005 16:59:15 +0000 Message-Id: <20050616165915.5717313925@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > yes. and in the case of a nonterminal wildcard, that's one NSEC RR. > > At least one per dot, surely? Plus one for the terminal wildcard. that depends on the encoding and power given to the nonterminal wildcard feature. for example, we might decide to permit ** zero or more labels *?* zero or one label *-* exactly one label *+* one or more labels or we might only allow the *?* and *-* forms and require that zone files concatenate several of them to build the other forms. that's more likely. but you're right, it could be one NSEC per label, depending. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 21:17:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02771 for ; Thu, 16 Jun 2005 21:17:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dj5Qd-000AId-Oi for namedroppers-data@psg.com; Fri, 17 Jun 2005 01:13:51 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dj5Qb-000AIB-1c for namedroppers@ops.ietf.org; Fri, 17 Jun 2005 01:13:49 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dj5QO-0006DZ-LE for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 20:13:44 -0500 To: "IETF DNSEXT WG" References: <62173B970AE0A044AED8723C3BCF238109316CDF@ma19exm01.e6.bcs.mot.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Jun 2005 20:13:35 -0500 In-Reply-To: (Edward Lewis's message of "Tue, 14 Jun 2005 13:55:48 -0400") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: New type code assignments (was: RE: draft-iab-dns-choices-02.txt comments) X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In Edward Lewis writes: > At 12:23 -0400 6/14/05, Samuel Weiler wrote: > >>... IANA has to do the assignment at some point in time, and, >>per the RFC Editor's processes, that's during the editing process[1]. > > By the time an effort is in the "editing process" it is already too > late to assign a type code. I strongly agree. In the case of SPF, as I documented in a reply to Paul a while back, we were discussing the various options of TXT vs a new RR type back in Oct 2003. I suspect that if we couldn't have had a fully functional and stable RR type assigned by Nov or Dec of 2003, we would have made the same choice of going with TXT. The SPF I-D still isn't in the RFC Editor's queue. > If I had my druthers, I would have at > least mocked up the application, tested it in a workshop environment > before trotting out a formal document. > > Whatever happened to running code and rough consensus? Remember the > days when code ruled? We are letting regulation get ahead of > technology. I'm not sure what happened to running code and rough consensus. I was complaining about the lack of running code and test results all during the MARID WG lifetime. Only in the last few weeks were a couple of very small tests made, and I'm not convinced they actually implemented the spec. The IESG is currently saying that they think that the 1.5 years of SPF deployment and testing needs to be ignored in order to be "fair" to SID, since SID doesn't have any (real?) deployment yet. It appears that creating running code is now a waste of time, as far as the IETF is concerned. I stated several times during MARID that I thought that running code was needed in order to get a rough consensus. We spent far too much time arguing theoretical stuff, with no test results. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 21:19:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02935 for ; Thu, 16 Jun 2005 21:19:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dj5Uf-000AZt-HI for namedroppers-data@psg.com; Fri, 17 Jun 2005 01:18:01 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dj5Ue-000AZg-VV for namedroppers@ops.ietf.org; Fri, 17 Jun 2005 01:18:01 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dj5UY-0006Lg-0J for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 20:18:00 -0500 To: "IETF DNSEXT WG" References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> <002901c57244$22483fb0$8217a8c0@arport2v> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Jun 2005 20:17:53 -0500 In-Reply-To: (Edward Lewis's message of "Thu, 16 Jun 2005 09:29:57 -0400") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: IANA is NOT the problem. Was: draft-iab-dns-choices-02.txt X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In Edward Lewis writes: >>That is, if there are any thoughts (can't really see why it is needed) of >>creating a new DNS data type extension scheme, it MUST allow fully distributed >>development and definitions, preferably by building on already existing name- >>space schemes. >> >>Just my 2 cents > > DNS is supposed to be lightweight and simple. That has translated > into fixed size boundaries of fields - to simplify parsing code - > with fixed semantics. Self-describing data is great, but it take the > end pieces longer to process it. Can you give me an example of something that is *SO* time critical that a little processing on the end pieces would make a difference? I don't believe this is a problem now a days. Really. And I think this mindset needs to go. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 21:40:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03807 for ; Thu, 16 Jun 2005 21:40:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dj5oN-000BqD-30 for namedroppers-data@psg.com; Fri, 17 Jun 2005 01:38:23 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dj5oL-000Bpj-7v for namedroppers@ops.ietf.org; Fri, 17 Jun 2005 01:38:21 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Dj5oA-0006hS-H6 for namedroppers@ops.ietf.org; Thu, 16 Jun 2005 20:38:19 -0500 To: "IETF DNSEXT WG" References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <1118739956.2160.229.camel@bash.adsl-64-142-13-68> <1118799446.7922.150.camel@SJC-Office-DHCP-156.mail-abuse.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Jun 2005 20:38:09 -0500 In-Reply-To: <1118799446.7922.150.camel@SJC-Office-DHCP-156.mail-abuse.org> (Douglas Otis's message of "Tue, 14 Jun 2005 18:37:26 -0700") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: draft-iab-dns-choices-02.txt comments X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <1118799446.7922.150.camel@SJC-Office-DHCP-156.mail-abuse.org> Douglas Otis writes: > You missed inclusion of the technique used in the APL RR. I don't think that solves the problem of expressing -ip4:, but I also think that is irrelevant. Whether the SPF record is 65 or 80 bytes doesn't make much difference compared with the other overhead that is involved. > In one approach, you advocate text because people can read it. When > confronting the size issue, you suggest compressed text. How does > converting an entry form to a text script, then to compressed text, be > better than a single conversion of an entry form into a TLV binary data? My suggestion for compressed DNS data was that it would be compressed when sent across the network, much like compressed HTML is done right now. The end points wouldn't see the compressed data. > I was not suggesting the binary TLV example to make execution faster, > although this would entail far less code and would be more extensible. > I was attempting to illustrate how SPF scaling issues demand greater I don't think this is the appropriate list to discuss this aspect of SPF. >> The reduction is only a factor of 4 when you don't take into account >> IP, UDP and DNS packet overhead. Currently the rr.com TXT record uses a >> 411 byte DNS packet, IP packet overhead is 20 bytes and UDP adds 8 >> bytes, giving a total of 439 bytes. If you reduce the SPF information >> to 65 bytes, that drops it down to 268 bytes. >> >> This isn't even a factor of 2 reduction. > > Have you considered the problem created by the collision of subsequent > RR reversions in this scripting scheme? The overhead remains relatively > static, which returns focus on the actual RR size once again. Yes, this is true, multiple records will change the ratio. I still don't think it will change the ratio enough to justify binary encodings. >> Ok, now take into account that the ip4: mechanism gets the best >> compression of all SPF mechanisms. IPv4 addresses can use up to 15 >> bytes in text, but only require 4 bytes in binary. IPv6 addresses use >> hex and are therefore much more compact. All other mechanisms get >> almost no benefit from binary encoding. > > The assumptions of benefits for other elements with names could be > advantaged by DNS style binary techniques for name compression confined > to the RR, as I have suggested. Even names include CIDR notation that > also shrink by the same amount as seen in the ip4 example. Binary has > served DNS well, yet you seem to insist only text is a valid choice. > Adding scripts and compression, the ability to ensure secure code is > made much more difficult. Coding in assembler servered the computing world well for many decades too. The insight that the Unix folks had is that, yes, you recould code most of the OS and apps in a high level language. They also realized that plain text files had a lot of advantages. Times have changed. -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 16 23:50:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15862 for ; Thu, 16 Jun 2005 23:50:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dj7pU-000KTr-1T for namedroppers-data@psg.com; Fri, 17 Jun 2005 03:47:40 +0000 Received: from [168.61.5.27] (helo=harry.mail-abuse.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dj7pR-000KTS-H7 for namedroppers@ops.ietf.org; Fri, 17 Jun 2005 03:47:38 +0000 Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id F0F86414F8 for ; Thu, 16 Jun 2005 20:47:34 -0700 (PDT) Subject: Re: draft-iab-dns-choices-02.txt comments From: Douglas Otis To: IETF DNSEXT WG In-Reply-To: References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <1118739956.2160.229.camel@bash.adsl-64-142-13-68> <1118799446.7922.150.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain Date: Thu, 16 Jun 2005 20:47:34 -0700 Message-Id: <1118980054.7678.182.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2005-06-16 at 20:38 -0500, wayne wrote: > Douglas Otis writes: > > > You missed inclusion of the technique used in the APL RR. > > I don't think that solves the problem of expressing -ip4:, but I also > think that is irrelevant. Whether the SPF record is 65 or 80 bytes > doesn't make much difference compared with the other overhead that is > involved. If you want to bifurcate results into three sets: unknown, authorized, and not authorized, then that would require another tag definition. Whether it is 360% or 24%, your approach requires more processing complexity and uses more packet allocation. By compressing the script, this makes it extremely difficult to identify errors. Network level examination is likely the only tool available initially for any new RR type, where a binary TLV structure would be much simpler to evaluate. > > In one approach, you advocate text because people can read it. When > > confronting the size issue, you suggest compressed text. How does > > converting an entry form to a text script, then to compressed text, be > > better than a single conversion of an entry form into a TLV binary data? > > My suggestion for compressed DNS data was that it would be compressed > when sent across the network, much like compressed HTML is done right > now. The end points wouldn't see the compressed data. Do you expect to see a compression layer added to DNS? > > Have you considered the problem created by the collision of subsequent > > RR reversions in this scripting scheme? The overhead remains relatively > > static, which returns focus on the actual RR size once again. > > Yes, this is true, multiple records will change the ratio. I still > don't think it will change the ratio enough to justify binary encodings. >From 236 byte to 65 bytes represents the difference between surviving a a collision, or needing to re-engineer a highly record-limit sensitive structure. Adding "includes" as a work around goes against the scaling concern. > Coding in assembler served the computing world well for many decades > too. The insight that the Unix folks had is that, yes, you could > code most of the OS and apps in a high level language. They also > realized that plain text files had a lot of advantages. > > Times have changed. This appears to be stilted justification for using script in DNS. Scripts are often fraught with security issues due to their evaluation complexity, and are forever growing due to their propensity for feature creep. The UDP packet size has not substantially changed with respect to ensuring compatibility. This has been true and will remain true for some time. Physical aspects of memory work against justifications for increasing the size of DNS data structures, or the use of scripts. Memory bandwidth does not pace with Moore's law. The performance for hard storage random access is largely limited by the rotational speed of the disc. This physical limitation has changed little in several decades! These limitations are reasons for retaining lean data structures for DNS. DNS runs out of limited memory to meet increasing performance requirements for sustaining this critical service as the network grows. Time is relentless and inexorable. -Doug -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From MelanieBouchard@amitone.co.uk Fri Jun 17 02:14:19 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09106; Fri, 17 Jun 2005 02:14:18 -0400 (EDT) Received: from 82-38-121-191.cable.ubr01.hali.blueyonder.co.uk ([82.38.121.191]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DjAU4-0007Mm-1c; Fri, 17 Jun 2005 02:38:09 -0400 Received: from O7K@localhost by UYZ9.int (8.11.6/8.11.6); Fri, 17 Jun 2005 01:16:28 -0600 Message-ID: From: "Vivian Duke" Reply-To: "Vivian Duke" To: sip-admin@ietf.org, ec@ietf.org, dnsext-archive@ietf.org Subject: Windows XP Pro $49.95 MS 2003 Date: Fri, 17 Jun 2005 08:17:28 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MelanieBouchard@amitone.co.uk Content-Type: multipart/mixed; boundary="--yJdOolAw0giFTeiXG" X-Spam-Score: 14.8 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 BKM ----yJdOolAw0giFTeiXG Content-Type: text/html; Content-Transfer-Encoding: quoted-printable s
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH
=

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>

 = ON SALE NOW!

 1 Off= ice Pro 2003
 2 Windows = XP Pro
 3 Adobe Creativ= e Suite Premium
 4 Norto= n Antivirus 2005
 5 Fla= sh MX 2004
 = 6 Corel Dra= w 12
 7 Adobe Acrobat 7.= 0
 8 Windows 2003 Serve= r
 9 Alias Maya 6 Wavef= rt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   A= pple Software
 <= /td> Customers also bought
   these other= items...
=



Microsoft Office Professional E= dition *2003*
= Microsoft
<= table border=3D0>Choose:
<= a href=3Dhttp://ipoemed.com/?8> 
<= /tr>
List Price:$899.00
Price:$69.99
Y= ou Save:$830.01 (92%)


Availability: Available for INSTANT download= !
Coupon Code: ISe229
Media: CD-ROM / Download
<= /span>
System requ= irements  |  Accessories=   |  Other Versions

Features:

    Analyze and manage business information usin= g Access databases
  • Exchange = data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced = IRM technology
  • Easy-to-use w= izards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business= reports
Sales Rank: #1=
Shipping: International/US or via instant downloa= d
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft

=
Choose:
 
List Price:$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download
System requirements=   |  Accessories  |=   Other Versions

= Features:

  • Designed for businesses of all sizes
    • =
  • Manage digital pictures, music, video, D= VDs, and more
  • More security = with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows server= s and management solutions

Sales= Rank: #2
Shipping: International/US or via in= stant download
Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe
=
Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D44 width=3D190><= tr>		 List Price: $599.00
Price:$69.99
Yo= u Save:$529.01 (90%)


Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
Media: CD-ROM / Download

System requir= ements  |  Accessories&n= bsp; |  Other Versions

=

Features:

    <= li class=3Dsmall>Customized workspace; save personalized wo= rkspace and tool settings; create customized shortcuts
  • Unparalleled efficiency--automate production t= asks with built-in or customized scripts
  • Improved file management, new design possibilities, and a mor= e intuitive way to create for the Web
  • Support for 16-bit images, digital camera raw data, and non-squa= re pixels
  • Create or modify p= hotos using painting, drawing, and retouching tools

Sales Rank: #3
Shipping= : International/US or via instant download
Date Coupon Expires:= June 30th, 2005
Average Customer Rev= iew: 3D"5 Based on 498 reviews. Wr= ite a review.

= ----yJdOolAw0giFTeiXG-- From owner-namedroppers@ops.ietf.org Fri Jun 17 10:14:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21028 for ; Fri, 17 Jun 2005 10:14:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DjHVb-000CSG-AW for namedroppers-data@psg.com; Fri, 17 Jun 2005 14:07:47 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DjHVZ-000CRb-1s for namedroppers@ops.ietf.org; Fri, 17 Jun 2005 14:07:45 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j5HE7fQ6015511 for ; Fri, 17 Jun 2005 07:07:41 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 17 Jun 2005 07:07:41 -0700 Received: from [17.219.197.139] ([17.219.197.139]) by relay1.apple.com (8.12.11/8.12.11) with SMTP id j5HE7bZW023914 for ; Fri, 17 Jun 2005 07:07:39 -0700 (PDT) Message-Id: <200506171407.j5HE7bZW023914@relay1.apple.com> Subject: Re: DNSEXT WGLC LLMNR-40 (Link-Local Multicast Name Resolution) Date: Fri, 17 Jun 2005 15:07:37 +0100 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >This message starts a WGLC for LLMNR ending on June 17'th. Reading draft-ietf-dnsext-mdns-40.txt, the problem I ran into was trying to understand what problem it is trying to solve. The abstract states that it is for "ad-hoc networks operating without a Domain Name System (DNS) server." Superficially that sounds all well and good, but what does it really mean? When it says, "DNS server", does it mean "authoritative name server", or "recursive name server"? The document needs to say clearly which it is talking about, because they are very different problems. One scenario is a device that has a name, but no authoritative server to answer for that name. The other is a resolver client that wants to look up a name, but has no recursive server to ask. There are several problems I can imagine this document *might* be trying to solve: 1. A device that has a conventionally allocated, properly delegated, fully-qualified domain name, but there is no (authoritative) name server to answer for that name. 2. A device that has *no* conventionally allocated, properly delegated, fully-qualified domain name, because the user doesn't know how to do that, or doesn't want to pay the annual fee to register a domain, or simply because the device has just shipped from the factory, and doesn't even have a human owner yet to go through the steps of allocating and assigning a unique FQDN for it. 3. A client that wants to look up a host name, but there is no authoritative name server for that name. 4. A client that wants to look up a host name, but there is no recursive name server available for the client to talk to. 5. A client that wants to look up a host name, and there is an authoritative name server for that name, but for whatever reason it's not responding right now. These are all very different scenarios, and the document needs to state clearly which, if any (or all) of them it is addressing. Right now reading the document feels a bit like playing the shell game, where you try (usually unsuccessfully) to keep track of which shell has the pea underneath as they slide around. Reading the document, I kept finding things that didn't work for one or more of the above scenarios, but it wasn't clear if that was a problem because it wasn't clear if the document was seeking to solve that particular problem. Some other general comments and questions: IPv4 administratively scoped multicast usage is specified in "Administratively Scoped IP Multicast" [RFC2365]. Does LLMNR use Administratively Scoped IP Multicast? The IPv4 link- scope multicast address a given responder listens to, and to which a sender sends queries, is 224.0.0.252. Why this address? My mDNS protocol uses link-local address 224.0.0.251 for consistency with Administratively Scoped Multicast addresses, which are allocated from the top down. 239.x.x.251 was the Administratively Scoped address group originally allocated for mDNS; for consistency I picked 224.0.0.251 as its link-local counterpart. The Administratively Scoped address group 239.x.x.252 is allocated for MZAP, which does not (as far as I know) have anything to do with LLMNR. An LLMNR sender may send a request for any name. However, by default, LLMNR requests SHOULD be sent only when one of the following conditions are met: [3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. This seems to imply that *every* single failed name lookup on a LLMNR-enabled host has to suffer the full LLMNR timeout before returning to the caller. For example, when I look up "foo" today, the DNS resolver client rapidly runs through my searchlist getting authoritative no-answer or NXDOMAIN responses for each one. With LLMNR, *every* single one of those failed lookups would have to wait a second or two for LLMNR to time out. What used to take mere milliseconds could now take 5-10 seconds to complete. Is this rule intended to solve scenario (2), for users who have no domain in which they can legitimately register names? It certainly seems like it. This rule means I can call my laptop "wibble.amazon.com.", and after getting an authoritative NXDOMAIN error from amazon.com, your LLMNR client will then successfully resolve it via link-local multicast. This seems to be declaring open season on domain names. It says to users, "if you have no domain name, just take someone else's." On the home network, this cavalier hijacking of names will apparently work successfully, giving users the dubious impression that domain names are free for the taking. LLMNR implementations MUST accept UDP queries and responses as large as the smaller of the link MTU or 8192 octets. I suggest 9000 bytes, the Ethernet jumbo frame size, as a natural packet size to pick. Allowing 40 bytes for IPv6 header and 8 for UDP header, that leaves 8952 for the DNS message, which allows for an 8K resource record to be carried (should such a thing ever be needed in future). T Tentative. The 'T'entative bit is set in a response if the responder is authoritative for the name, but has not yet verified the uniqueness of one or more of the resource record(s) in the answer section. A responder MUST ignore the 'T' bit in a query, if set. When a response with the 'T' bit set is received in response to a uniqueness query, a conflict has been detected and a responder MUST resolve the conflict as described in Section 4.1. The document says nothing about how response with the 'T' bit set are to be interpreted by senders. Should they be ignored, or used in answer to the question? If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. What kind of error is this anticipating? Either the responder knows the answer, or it does not. Some example of a plausible error would motivate this section. Since LLMNR responders only respond to LLMNR queries for names for which they are authoritative... Is this NAMES for which they are authoritative, or RRSETs (i.e. name+type+class) for which they are authoritative? In some places the document implies that a responder 'owns' a name exclusively, for all types and classes with that name, and in others it seems to assume that the unit of logical ownership is the RRSET. The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would. This means that, even when a query is successfully answered in (say) just 10ms, the sender has to wait for the full LLMNR timeout before returning results to the caller, in case there are other responses coming? Upon configuring an IP address, responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR as well Another RR in addition to A, AAAA and PTR? For example, a host configured to have computer name "host1" and to be a member of the "example.com" domain, and with IPv4 address 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the following records: host1. IN A 192.0.2.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 This seems to be the most egregious pollution of the top level of the DNS namespace. If I call my television "tv.myhouse.", then that means it answers for the name "tv." How does that coexist with the global DNS records for Tuvalu? If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). If TCP connection setup cannot be completed after how long? 2.5. "Off link" Detection For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. How does a given device *know* what subnets are on the local link? To know this, a device has to have perfectly accurate configuration information, but the whole point of LLMNR is for scenarios where configuration infrastructure has failed, and the device is left to fend for itself as best it can. To be useful, the device has to be able to operate even if some or all of its configuration information is wrong. Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the response to one (1). The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder. A common enterprise configuration is to have two or more IP subnets overlayed on the same physical link. (You can argue that this is misconfiguration, but it is still common.) This means that two laptops sitting next to each other on the same Ethernet hub can be apparently two hops from each other. Setting the TTL to 1 means that half of the LAN becomes unreachable from the other half. Also, how does this interact with multi-link subnets? For UDP queries and responses, the Hop Limit field in the IPv6 header and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Bonjour [Bonjour]. Has this compatibility been tested? I don't have access to any LLMNR implementation. (I don't even know if there are any LLMNR implementations). Windows users can easily test this by just downloaded Bonjour for Windows. If one of the LLMNR supporters could try it, that would be very useful information. An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT for each transmission. For example, the algorithms described in RFC 2988 [RFC2988] (including exponential backoff) compute an RTO, which is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). For this computation, does it use the first or last response received? Or the average? Is the RTO value computed as a single global? Per interface? Per responding device? (Some devices are slower than others.) In any case, this approach has the flaw that the computed RTT estimate converges to zero. Suppose you wait for t seconds before giving up. All responses you get necessarily arrive in less than t seconds (ones that arrive later are not seen). The average arrival time is therefore always less than t, so on the next iteration you compute a smaller RTT estimate. As RTT shrinks, more and more of the slower responses are lost, causing RTT to be estimated only from the fast-responding set. A specification of how to do dynamic RTT estimation in a multicast scenario like this needs much more than just a reference to RFC 2988. If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response, interpreted as an unsigned integer, is less than the source IP address in the query. This suffers from auto-immune response, in the case where a machine has both Ethernet and wireless connections, and (unknown to the machine) the Ethernet and wireless networks are bridged together. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 19 17:42:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08478 for ; Sun, 19 Jun 2005 17:42:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dk7SL-000BiO-1M for namedroppers-data@psg.com; Sun, 19 Jun 2005 21:35:53 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Dk7SI-000Bi3-RR for namedroppers@ops.ietf.org; Sun, 19 Jun 2005 21:35:51 +0000 Received: from zeder.TechFak.Uni-Bielefeld.DE (zeder.TechFak.Uni-Bielefeld.DE [129.70.128.80]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j5JLZlCs005684 for ; Sun, 19 Jun 2005 23:35:48 +0200 (MEST) Received: from localhost (pk@localhost) by zeder.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j5JLZla19029 for ; Sun, 19 Jun 2005 23:35:47 +0200 (MEST) Message-Id: <200506192135.j5JLZla19029@zeder.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: zeder.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07 In-reply-to: Your message of "Wed, 01 Jun 2005 16:29:17 +0200." <20050601162917.3444dc5b.olaf@ripe.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19024.1119216944.1@zeder.TechFak.Uni-Bielefeld.DE> Date: Sun, 19 Jun 2005 23:35:47 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is the second WGLC for the "Wildcard clarification document" > Please review the document. Please state you reviewed the document > with your objections and support. Send your statement to the > mailing list or to both chairs directly. The document is well written and clear in its intent. The points raised below do not criticise the general direction but should be dealt with before the draft is sent to the IESG. The comments affect some wording issues, one request for declaration of the scope of the draft (start of section 3). and the "* NS" and "* DS" subsections. > DNSEXT Working Group E. Lewis > INTERNET DRAFT NeuStar > Expiration Date: November 16, 2005 May 16, 2005 The list of to be updated RFCs (1034, SRV, DNAME, DNSSEC) is missing. > 1 Introduction > In addition, consideration has been given to minimize any > backwards compatibility with implementations that have complied > with RFC 1034's definition. That might be a "maximize"? > 1.1 Motivation > Many DNS implementations have diverged with respect to wildcards > in different ways from the original definition, or at from least "from at least"? > This document is intended to limit changes, only those based on > implementation experience, and to remain as close to the original missing verb? > 1.3.2 Changed Text > Only the latter change represents an impact to implementations. > The definition of existence is not a protocol impact. The change > to the restriction on names is unlikely to have an impact, as > there was no discussion of how to enforce the restriction. Not sure what "there" references to. Is it the discussion of this spec or is it the old spec itself? > 2.1.2 Asterisks and Other Characters > > No label values other than that in section 2.1.1 are asterisk > labels, hence names beginning with other labels are never wild > card domain names. Labels such as 'the*' and '**' are not > asterisk labels, they do not start wild card domain names. 'so' after the last comma makes this easier to read. > NXDOMAIN is introduced in RFC 2308, section 2.1 says "In this No objection, but 'NXDOMAIN' resulted in an IESG DISCUSS for another draft recently. > 2.2.1 An Example > The following queries would be synthesized from one of the s/queries/responses/, occurs twice > QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN > because *.example. exists This I really like; may we add a sentence below the examles like "Note that the second example above illustrates that the wildcard never matches all names below the closest encloser. Any descendants of the wildcard domain name are shadowed by the wildcard itself."? > 2.2.3 Yet Another Definition of Existence > The domain name space is a tree structure. Nodes in the tree > either own at least one RRSet and/or have descendants that > collectively own at least on RRSet. A node may have no RRSets > if it has descendents that do, this node is a empty non-terminal. s/ a / an / > A node may have its own RRSets and have descendants with RRSets s/$/,/ > including the NS RR set. At the delegating server, the NS RR Purist again. Servers don't delegate. change to "At the delegating zone's servers" or "In the delegating zone" > 2.3 When does a Wild Card Domain Name is not Special s/does // > When a wild card domain name appears in a message's query section, > no special processing occurs. An asterisk label in a query name > only (label) matches an asterisk label in the existing zone tree > when the 4.3.2 algorithm is being followed. Should "(label)" be deleted? > 3. Impact of a Wild Card Domain Name On a Response > The algorithm in RFC 1034, section 4.3.2. is not intended to be > pseudo code, i.e., its steps are not intended to be followed in > strict order. The "algorithm" is a suggestion. As such, in > step 3, parts a, b, and c, do not have to be implemented in > that order. This is a clarification that has not been made in any RFC before. While I agree with the intent (it's not that bad, alphabetical order is fine, although some rollback is needed), this statement has side effects beyond the definition and application of wildcards. That's fine, but it's more than the introduction declares, so that should be changed. > 3.2 Step 3 > The process of label matching a query name ends in exactly one of > three choices, the parts 'a', 'b', and 'c'. Either the name is > found, the name is below a cut point, or the name is not found. > > Once one of the parts is chosen, the other parts are not > considered. (E.g., do not execute part 'c' and then change > the execution path to finish in part 'b'.) The process of label > matching is also done independent of the query type (QTYPE). > > Parts 'a' and 'b' are not an issue for this clarification as they > do not relate to record synthesis. Part 'a' is an exact match > that results in an answer, part 'b' is a referral. It is > possible, from the description given, that a query might fit > into both part a and part b, this is not within the scope of > this document. The first and the third paragraph above seem to collide. While the first promises a clear decision, the last says it might be 'a' and 'b'. IMHO the promise is wrong since a name may be matched and still be below the zone cut ("cut point" is yet undefined). > 3.3.3 Type Matching > > RFC 1034 concludes part 'c' with this: > > # If the "*" label does not exist, check whether the name > # we are looking for is the original QNAME in the query > # or a name we have followed due to a CNAME. If the name > # is original, set an authoritative name error in the > # response and exit. Otherwise just exit. > # > # If the "*" label does exist, match RRs at that node > # against QTYPE. If any match, copy them into the answer > # section, but set the owner of the RR to be QNAME, and > # not the node with the "*" label. Go to step 6. > > The final paragraph covers the role of the QTYPE in the lookup > process. > > Based on implementation feedback and similarities between step > 'a' and step 'c' a change to this passage has been made. > > The change is to add the following text to step 'c': > > If the data at the source of synthesis is a CNAME, and > QTYPE doesn't match CNAME, copy the CNAME RR into the > answer section of the response changing the owner name > to the QNAME, change QNAME to the canonical name in the > CNAME RR, and go back to step 1. Strictly speaking, if we just add this to step 'c', it's a noop since the paragraphs above cover '* exists' and '* doesn't exist'. Avoiding the logic we applied to step 3 as a whole (choose the order that best fits) seems sensible, so the text has to be inserted before "Go to step 6" in the second paragraph. > 4.2 NS RRSet at a Wild Card Domain Name > After some lengthy discussions, there has been no clear "best > answer" on how to document the semantics of such a situation. When the chairs asked for comments on this approach I responded that we lost part of the discussion with this text. Giving no "best answer" is OK, but we could more explicitly list the answers we don't give. > Combining these observations with thought that a wild card > domain name owning an NS record is an operationally uninteresting > scenario, i.e., it won't happen in the normal course of events, > accomodating this situation in the specification would also be > categorized as "needless complication." Further, expending more > effort on this topic has proven to be an exercise in diminishing > returns. Just for the record these are wildcard NS RRSets found in the "wild": *.AC. *.IO. *.MP. *.SH. *.TM. > 4.4 DNAME RRSet at a Wild Card Domain Name > > Ownership of a DNAME RRSet by a wild card domain name > represents a threat to the coherency of the DNS and is to be > avoided or outright rejected. Such a DNAME RRSet represents > non-deterministic synthesis of rules fed to different caches. > As caches are fed the different rules (in an unpredictable > manner) the caches will cease to be coherent. ("As caches > are fed" refers to the storage in a cache of records obtained > in responses by recursive or iterative servers.) s/iterative/non-recursive/ There are "iterative resolvers", but those are the ones actually offering "recursive service". > For example, assume one cache, responding to a recursive request, > obtains the record "a.b.example. DNAME foo.bar.tld." and another > cache obtains "b.example. DNAME foo.bar.tld.", both generated > from the record "*.example. DNAME foo.bar.tld." by an > authoritative server. Ceterum censeo RFC 2606 should have reserved mor distinct example TLDs. Not sure what to do here. > The DNAME specification is not clear on whether DNAME records > in a cache are used to rewrite queries. In some interpretations, > the rewrite occurs, in some, it is not. Allowing for the s/ is / does / > 4.5 SRV RRSet at a Wild Card Domain Name > *.example is a wild card domain name and although it it the Name > of the SRV RR, it is not the owner (domain name). The owner > domain name is "_foo._udp.*.example." which is not a wild card > domain name. "owner domain name" is new lingo, "owner name" has been more common. Rephrased: *.example is a wild card domain name and although it is the Name of the SRV RR, it is not its owner (name). The owner name is "_foo._udp.*.example." which is not a wild card domain name. > 4.6 DS RRSet at a Wild Card Domain Name > > A DS RRSet owned by a wild card domain name is meaningless and > harmless. Does meaningless mean it cannot be a source of synthesis? What about the "*" subdomain, could it be secured by the "*" DS RR? This will have implications for the interpretation of "* NS", won't it? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From boleyz@converti.com Sun Jun 19 19:22:06 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14335; Sun, 19 Jun 2005 19:22:06 -0400 (EDT) Received: from c-24-34-67-63.hsd1.nh.comcast.net ([24.34.67.63]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dk9Uk-0000G4-UR; Sun, 19 Jun 2005 19:46:33 -0400 Received: from 24.34.67.63 (unverified [200.180.200.96]) by iseedouble.clayberg.com (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 20 Jun 2005 01:15:51 +0100 Message-ID: <7TJBPQpnhkuV1710b@clayberg.com> From: "Raul Oneill" To: dnsext-archive@ietf.org Subject: Second Mortgage? Date: Mon, 20 Jun 2005 03:20:51 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9997-28362-88167" X-Spam-Score: 20.3 (++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 ----9997-28362-88167 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Want to Save on Your mortga ge? Get Free Help! -- Let one of our local mortg age experts save you time, money, & effort. Quick & easy form, no cost or obligation. http://thmbrannan.home-financial.net/3/index/pfd/igambling These e-mails aren't of interest http://kaminskicards.home-financial.net/rem.php He was a verray, parfit gentil knyght. ----9997-28362-88167-- From owner-namedroppers@ops.ietf.org Mon Jun 20 15:18:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00825 for ; Mon, 20 Jun 2005 15:18:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkRi6-000CYT-5o for namedroppers-data@psg.com; Mon, 20 Jun 2005 19:13:30 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DkRi3-000CYC-W6 for namedroppers@ops.ietf.org; Mon, 20 Jun 2005 19:13:28 +0000 Received: from [10.31.32.105] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5KJDJjR041299; Mon, 20 Jun 2005 15:13:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> <002901c57244$22483fb0$8217a8c0@arport2v> Date: Mon, 20 Jun 2005 15:11:21 -0400 To: "IETF DNSEXT WG" From: Edward Lewis Subject: Re: IANA is NOT the problem. Was: draft-iab-dns-choices-02.txt Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:17 -0500 6/16/05, wayne wrote: >Can you give me an example of something that is *SO* time critical >that a little processing on the end pieces would make a difference? The DNS lookup process itself. Delays in it are amplified by applications. >I don't believe this is a problem now a days. Really. And I think >this mindset needs to go. You should really also look at replacing the DNS then. I'm all for layering more complex and functional look up systems over the top of the DNS. I'm just leery of trying to extend the creaking base and the possible unintended consequences on applications that like it just fine as it is. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 20 16:03:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05149 for ; Mon, 20 Jun 2005 16:03:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkSQi-000FWQ-6K for namedroppers-data@psg.com; Mon, 20 Jun 2005 19:59:36 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DkSQg-000FW3-Ht for namedroppers@ops.ietf.org; Mon, 20 Jun 2005 19:59:35 +0000 Received: from [10.31.32.105] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5KJxPTB041417; Mon, 20 Jun 2005 15:59:26 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200506192135.j5JLZla19029@zeder.TechFak.Uni-Bielefeld.DE> References: <200506192135.j5JLZla19029@zeder.TechFak.Uni-Bielefeld.DE> Date: Mon, 20 Jun 2005 15:59:38 -0400 To: Peter Koch From: Edward Lewis Subject: Re: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07 Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'll address only the points that beg, umm, clarification. At 23:35 +0200 6/19/05, Peter Koch wrote: > Quotes from the draft: >> When a wild card domain name appears in a message's query section, >> no special processing occurs. An asterisk label in a query name >> only (label) matches an asterisk label in the existing zone tree >> when the 4.3.2 algorithm is being followed. > >Should "(label)" be deleted? I'll have to see if I defined "label match" to try and clear up what is meant when "matching label by label". This might be something that has time pass it by. >> 3. Impact of a Wild Card Domain Name On a Response > >> The algorithm in RFC 1034, section 4.3.2. is not intended to be >> pseudo code, i.e., its steps are not intended to be followed in >> strict order. The "algorithm" is a suggestion. As such, in >> step 3, parts a, b, and c, do not have to be implemented in >> that order. > >This is a clarification that has not been made in any RFC before. While >I agree with the intent (it's not that bad, alphabetical order is fine, >although some rollback is needed), this statement has side effects beyond >the definition and application of wildcards. That's fine, but it's more >than the introduction declares, so that should be changed. Interesting call. That statement has been made by Rob Austein a few times. That's where I got it from and have used it in other threads. >> 3.2 Step 3 > >> The process of label matching a query name ends in exactly one of >> three choices, the parts 'a', 'b', and 'c'. Either the name is >> found, the name is below a cut point, or the name is not found. >> >> Once one of the parts is chosen, the other parts are not >> considered. (E.g., do not execute part 'c' and then change >> the execution path to finish in part 'b'.) The process of label >> matching is also done independent of the query type (QTYPE). >> >> Parts 'a' and 'b' are not an issue for this clarification as they >> do not relate to record synthesis. Part 'a' is an exact match >> that results in an answer, part 'b' is a referral. It is >> possible, from the description given, that a query might fit >> into both part a and part b, this is not within the scope of >> this document. > >The first and the third paragraph above seem to collide. While the first >promises a clear decision, the last says it might be 'a' and 'b'. IMHO >the promise is wrong since a name may be matched and still be below the >zone cut ("cut point" is yet undefined). For example, a query for type=DS or NSEC for delegation point could arguably be in a or b, but still only one of 'a' or 'b' or even 'c' will hold. Maybe (I'll) just drop the last sentence. >> 3.3.3 Type Matching >> ... >> The change is to add the following text to step 'c': >> >> If the data at the source of synthesis is a CNAME, and >> QTYPE doesn't match CNAME, copy the CNAME RR into the >> answer section of the response changing the owner name >> to the QNAME, change QNAME to the canonical name in the >> CNAME RR, and go back to step 1. > >Strictly speaking, if we just add this to step 'c', it's a noop since the >paragraphs above cover '* exists' and '* doesn't exist'. Avoiding the >logic we applied to step 3 as a whole (choose the order that best fits) >seems sensible, so the text has to be inserted before "Go to step 6" in the >second paragraph. Okay, okay. >> 4.2 NS RRSet at a Wild Card Domain Name > >> After some lengthy discussions, there has been no clear "best >> answer" on how to document the semantics of such a situation. > >When the chairs asked for comments on this approach I responded that we >lost part of the discussion with this text. Giving no "best answer" is OK, >but we could more explicitly list the answers we don't give. It's hard to do that because part of the reason for not giving a "good" answer is that so some a "good answer" is a "bad answer" to others, if you follow my meaning. Hmmm. >> Combining these observations with thought that a wild card >> domain name owning an NS record is an operationally uninteresting >> scenario, i.e., it won't happen in the normal course of events, >> accomodating this situation in the specification would also be >> categorized as "needless complication." Further, expending more >> effort on this topic has proven to be an exercise in diminishing >> returns. > >Just for the record these are wildcard NS RRSets found in the "wild": > > *.AC. *.IO. *.MP. *.SH. *.TM. Well, the IETF doesn't do enforcement...;) >> For example, assume one cache, responding to a recursive request, >> obtains the record "a.b.example. DNAME foo.bar.tld." and another >> cache obtains "b.example. DNAME foo.bar.tld.", both generated >> from the record "*.example. DNAME foo.bar.tld." by an >> authoritative server. > >Ceterum censeo RFC 2606 should have reserved mor distinct example TLDs. >Not sure what to do here. I suppose I could just switch tld to example.net. Cognito ergo cerveza. (I think therefore I drink.) I have to admit I had to figure out what Ceterum censeo meant. ;) >> 4.6 DS RRSet at a Wild Card Domain Name >> >> A DS RRSet owned by a wild card domain name is meaningless and >> harmless. > >Does meaningless mean it cannot be a source of synthesis? What about the >"*" subdomain, could it be secured by the "*" DS RR? This will have >implications for the interpretation of "* NS", won't it? Meaningless - if I did synthesize a DS RRSet, there isn't a reliable NS RRSet to correspond to it (therefore no DNSKEY RRSet) to make it worthwhile. I admit to running out of steam when I wrote that part, but a DS RRSet without a corresponding DNSKEY RRSet is pretty meaningless in the larger scheme of the world. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 20 17:01:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10022 for ; Mon, 20 Jun 2005 17:01:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkTKm-000JPV-S3 for namedroppers-data@psg.com; Mon, 20 Jun 2005 20:57:32 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DkTKj-000JP7-RP for namedroppers@ops.ietf.org; Mon, 20 Jun 2005 20:57:30 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id 60F01C2DA4; Mon, 20 Jun 2005 21:57:28 +0100 (BST) Date: Mon, 20 Jun 2005 21:57:26 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Edward Lewis , Peter Koch Cc: namedroppers@ops.ietf.org, Alex Bligh Subject: Re: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07 Message-ID: <955FFD63C793615E7F12E1EA@[192.168.100.25]> In-Reply-To: References: <200506192135.j5JLZla19029@zeder.TechFak.Uni-Bielefeld.DE> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 20 June 2005 15:59 -0400 Edward Lewis wrote: >>> 3. Impact of a Wild Card Domain Name On a Response >> >>> The algorithm in RFC 1034, section 4.3.2. is not intended to be >>> pseudo code, i.e., its steps are not intended to be followed in >>> strict order. The "algorithm" is a suggestion. As such, in >>> step 3, parts a, b, and c, do not have to be implemented in >>> that order. >> >> This is a clarification that has not been made in any RFC before. While >> I agree with the intent (it's not that bad, alphabetical order is fine, >> although some rollback is needed), this statement has side effects beyond >> the definition and application of wildcards. That's fine, but it's more >> than the introduction declares, so that should be changed. > > Interesting call. That statement has been made by Rob Austein a few > times. That's where I got it from and have used it in other threads. The question here is whether such statements mean: a) that the algorithm presented is merely an example of a mechanism for reliably obtaining the correct result, and that an implementation need not necessarily duplicate the pseudocode exactly; any implementation is acceptable provided it produces the results required by the RFCs, and (as the pseudocode is compliant in this respect) as the pseudocode. However, code which produces differing output for any one input set is not compliant; OR b) that the algorithm presented is merely an example of a mechanism for implementing the RFCs, and that it includes design choices beyond those specified by the RFCs. Thus whilst producing an implementation which duplicates the pseudocode exactly will result in compliance, it would equally be possible to produce another interpretation, which might give different output in a subset of input cases, which would be equally compliant, because the RFC's leave some choices as to behaviour to the implementer, who might not choose the same implementation as the pseudocode. If (a) is the case, then this is indeed merely a clarification, in that it is saying that RFC's define protocols, not implementation, and (in essence), the algorithm is there to show how the protocol should respond. For instance, an algorithm which used a hash cache of the query tuple would be a valid implementation, in that it would always produce the same results as the algorithm. If (b) is the case, that's a bit surprising, and more than a clarification. It's also possibly rather unhelpful, as the next question is "well, what assumptions does the algorithm presented make that need not be made for conformance with the mandatory terms of the RFC". In that respect, it's the opposite of a clarification, because it introduces doubt (obviously not Ed's fault!). I have always thought the statement (made not only by Rob, but also others) meant (a) above - IE "it doesn't matter how you do it, just so long as it produces the same results, because we are in the business of defining protocols not implications". To which I say "well duh", but I suppose it needs stating. If I'm right, the text in -clarify should probably have appended "provided that same result is produced" after "in that order". Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 20 17:22:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11478 for ; Mon, 20 Jun 2005 17:22:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkTg3-000L3v-Lh for namedroppers-data@psg.com; Mon, 20 Jun 2005 21:19:31 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DkTfz-000L3a-QR for namedroppers@ops.ietf.org; Mon, 20 Jun 2005 21:19:27 +0000 Received: from dakota.av8.net (dakota.av8.net [130.105.19.131]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j5KLJOnU023652 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 20 Jun 2005 17:19:25 -0400 Date: Mon, 20 Jun 2005 17:19:22 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@localhost.localdomain To: Edward Lewis cc: IETF DNSEXT WG Subject: Re: IANA is NOT the problem. Was: draft-iab-dns-choices-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 20 Jun 2005, Edward Lewis wrote: > At 20:17 -0500 6/16/05, wayne wrote: > > >Can you give me an example of something that is *SO* time critical > >that a little processing on the end pieces would make a difference? > > The DNS lookup process itself. Delays in it are amplified by applications. And this makes a lot of difference. There were studies done back in the 80's about mainframe vs workstation response latencies and impact on users. It is truly remarkable how much difference a little latency makes. But it's not just latency. Its also resolver code size. TCP stacks are winding up on smaller and smaller systems, in larger and larger numbers. And its also upgrade/replacement cycles. ROM'd stacks are hard to upgrade, and last a long time. That's why you can't think of adding new RRs trivially. You can easily conduct experiements on lab systems; there is plenty of open source software and cheap pc systems. But its much, much different when people start to talk about changes to millions and millions of production systems. And sometimes its not just the large numbers. Anycast DNS roots was a good example of a bad choice that once taken, can't be "un-taken", for even a small number of systems. Carelessness has lasting impact. Its not at all like a software program or company that might be hot for a few years, and in a couple years hence, no one even remembers it. Making a bad choice on DNS will have a long lasting impact. The "Dot-com" mindset is bad for DNS: It can't just go bust and be forgotten. Bad DNS choices will have to be fixed. Those who think of DNS as a distributed database simply have no understanding of what DNS is, nor what role it plays. > >I don't believe this is a problem now a days. Really. And I think > >this mindset needs to go. Not only is it a "problem", but its much worse than it used to be. The "cement" is deep and broad. Shifting it is very dangerous and needs to be done with great care. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From d2269acruz@nihs.net Tue Jun 21 00:35:51 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15204; Tue, 21 Jun 2005 00:35:51 -0400 (EDT) Received: from [218.27.90.234] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dkas8-0008UR-Kg; Tue, 21 Jun 2005 01:00:33 -0400 Received: from 218.27.90.234 ([200.120.215.138]) by www.screamingpower.com (8.10.2/8.10.2) with SMTP id iA83nbL15755 for ; Tue, 21 Jun 2005 03:31:24 -0200 Message-ID: <8XTNNtlvwkW699022n@screamingpower.com> From: "Rodrick Jernigan" To: dnsext-archive@ietf.org Subject: Stop Searching For Lenders Date: Tue, 21 Jun 2005 10:35:24 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--64GP0711.1TO6%X" X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-Spam-Score: 10.2 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 ----64GP0711.1TO6%X Content-Type: text/plain; Content-Transfer-Encoding: 7Bit When looking for a home equity loan or equity line of credit, you may be wondering, "how much loan do I qualify for" and "can I qualify for enough to pay off those debts that have been piling up? http://imacowgirl26nc.usa-home-loans.net/4/index/pfd/thegmjeff Stop all future contacts http://aasjn.usa-home-loans.net/rem.php Revenge is a kind of wild justice. ----64GP0711.1TO6%X-- From owner-namedroppers@ops.ietf.org Tue Jun 21 11:37:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01576 for ; Tue, 21 Jun 2005 11:37:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dkkif-000EGo-HY for namedroppers-data@psg.com; Tue, 21 Jun 2005 15:31:21 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dkkie-000EGP-CN for namedroppers@ops.ietf.org; Tue, 21 Jun 2005 15:31:21 +0000 Received: from [10.31.32.105] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5LFVCIJ045726; Tue, 21 Jun 2005 11:31:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <955FFD63C793615E7F12E1EA@[192.168.100.25]> References: <200506192135.j5JLZla19029@zeder.TechFak.Uni-Bielefeld.DE> <955FFD63C793615E7F12E1EA@[192.168.100.25]> Date: Tue, 21 Jun 2005 11:31:27 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07 Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 21:57 +0100 6/20/05, Alex Bligh wrote: >I have always thought the statement (made not only by Rob, but also others) >meant (a) above - IE "it doesn't matter how you do it, just so long as >it produces the same results, because we are in the business of defining >protocols not implications". To which I say "well duh", but I suppose >it needs stating. If I'm right, the text in -clarify should probably >have appended "provided that same result is produced" after "in that order". I think it's a also. So the extra words are probably a good idea. ("Probably" because I'm reacting to the email and not looking at the draft right now. ;)) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From KateAyers@200kph.co.uk Tue Jun 21 13:01:44 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07901; Tue, 21 Jun 2005 13:01:44 -0400 (EDT) Received: from [211.243.70.104] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkmW6-0002eO-Ij; Tue, 21 Jun 2005 13:26:32 -0400 Received: from Avm@localhost by 3KMj.int (8.11.6/8.11.6); Tue, 21 Jun 2005 22:08:26 +0400 Message-ID: From: "Tori Hilton" Reply-To: "Tori Hilton" To: 15@ietf.org Subject: Windows XP Pro $49.95 XP Pro Date: Tue, 21 Jun 2005 19:07:26 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: KateAyers@200kph.co.uk Content-Type: multipart/mixed; boundary="--g3NZRqNp33T7NhXhH7" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 m0Eh ----g3NZRqNp33T7NhXhH7 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable U
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH
=

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>

 = ON SALE NOW!

 1 Off= ice Pro 2003
 2 Windows = XP Pro
 3 Adobe Creativ= e Suite Premium
 4 Norto= n Antivirus 2005
 5 Fla= sh MX 2004
 = 6 Corel Dra= w 12
 7 Adobe Acrobat 7.= 0
 8 Windows 2003 Serve= r
 9 Alias Maya 6 Wavef= rt
 10 Adobe Premiere
  See more by this m= anufacturer
   Microsoft
   A= pple Software
 <= /td> Customers also bought
   these other= items...
=



Microsoft Office Professional E= dition *2003*
= Microsoft
<= table border=3D0>Choose:
<= a href=3Dhttp://ipoemed.com/?P> 
<= /tr>
List Price:$899.00
Price:$69.99
Y= ou Save:$830.01 (92%)


Availability: Available for INSTANT download= !
Coupon Code: ISe229
Media: CD-ROM / Download
<= /span>
System requ= irements  |  Accessories=   |  Other Versions

Features:

    Analyze and manage business information usin= g Access databases
  • Exchange = data with other systems using enhanced XML technology
  • Control information sharing rules with enhanced = IRM technology
  • Easy-to-use w= izards to create e-mail newsletters and printed marketing materials
  • More than 20 preformatted business= reports
Sales Rank: #1=
Shipping: International/US or via instant downloa= d
Date Coupon Expires: June 30th, 2005
Average Customer Review: 3D"5 Based on 1,768 reviews. Write a review.
Microsoft Windows XP Professional or Longhorn Edition
Microsoft

=
Choose:
 
List Price:$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download
System requirements=   |  Accessories  |=   Other Versions

= Features:

  • Designed for businesses of all sizes
    • =
  • Manage digital pictures, music, video, D= VDs, and more
  • More security = with the ability to encrypt files and folders
  • Built-in voice, video, and instant messaging support
  • Integration with Windows server= s and management solutions

Sales= Rank: #2
Shipping: International/US or via in= stant download
Date Coupon Expires: June 30th, 2005
= Average Customer Review: 3D= Based on 868 r= eviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe
=
Choose:
 

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D44 width=3D190><= tr>		 List Price: $599.00
Price:$69.99
Yo= u Save:$529.01 (90%)


Availability: Available for INSTANT download!<= br> Coupon Code: ISe229
Media: CD-ROM / Download

System requir= ements  |  Accessories&n= bsp; |  Other Versions

=

Features:

    <= li class=3Dsmall>Customized workspace; save personalized wo= rkspace and tool settings; create customized shortcuts
  • Unparalleled efficiency--automate production t= asks with built-in or customized scripts
  • Improved file management, new design possibilities, and a mor= e intuitive way to create for the Web
  • Support for 16-bit images, digital camera raw data, and non-squa= re pixels
  • Create or modify p= hotos using painting, drawing, and retouching tools

Sales Rank: #3
Shipping= : International/US or via instant download
Date Coupon Expires:= June 30th, 2005
Average Customer Rev= iew: 3D"5 Based on 498 reviews. Wr= ite a review.

= ----g3NZRqNp33T7NhXhH7-- From owner-namedroppers@ops.ietf.org Tue Jun 21 23:22:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13985 for ; Tue, 21 Jun 2005 23:22:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkvkB-0007PH-9D for namedroppers-data@psg.com; Wed, 22 Jun 2005 03:17:39 +0000 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dkvk9-0007Oy-FK for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 03:17:37 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j5M3QDW9013003 for ; Tue, 21 Jun 2005 20:26:13 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j5M3M43Q017331 for ; Tue, 21 Jun 2005 22:22:04 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Jun 2005 23:17:35 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316D47@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Date: Tue, 21 Jun 2005 23:17:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, I have produced draft draft-eastlake-dnsext-2929bis-00.txt which is now in the ID directories. It continues to have about half the RR Type Code and CALSS space allocated by "Specification Required" but most of the instances of "IETF Consensus" and "IETF Standards Action" have been changed to "IETF Standards Action modified by [RFC 4020]". What do people think about making this a WG draft and possibly putting it through to enable the early allocation provisions of RFC 4020, particularly for Type Codes? Thanks, Donald ========================================================= Donald E. Eastlake III Donald.Eastlake@Motorola.com Motorola Laboratories +1-508-786-7554 (work) 111 Locke Drive +1-508-634-2066 (home) Marlboro, MA 01752 USA -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 21 23:22:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14003 for ; Tue, 21 Jun 2005 23:22:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dkvle-0007Th-Ks for namedroppers-data@psg.com; Wed, 22 Jun 2005 03:19:10 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dkvlc-0007TP-Nr for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 03:19:08 +0000 Received: (qmail 17400 invoked by uid 100); 22 Jun 2005 03:19:03 -0000 Date: 22 Jun 2005 03:19:03 -0000 Message-ID: <20050622031903.17399.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Seven of nine? Organization: I.E.C.C., Trumansburg NY USA Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let's say I have an RRset like this with a whole lot of records of the same type: foo.example.com IN A 10.1.2.3 IN A 10.1.2.4 ... IN A 10.1.2.99 I know that a lot of DNS servers will shuffle the record order around when they answer queries for low-rent load sharing. Will they always return all of the records, or can they return a subset, either to make the response fit in a UDP packet, or just because? I'm wondering because applications like SPF will break in mysterious non-reproducible ways if they get some but not all records in an A or MX rrset. R's, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 21 23:58:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16734 for ; Tue, 21 Jun 2005 23:58:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkwLb-0009we-H2 for namedroppers-data@psg.com; Wed, 22 Jun 2005 03:56:19 +0000 Received: from [216.151.192.200] (helo=sokol.elan.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DkwLZ-0009wH-Oz for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 03:56:17 +0000 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j5M3uFkm030011; Tue, 21 Jun 2005 20:56:15 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j5M3uFw0030008; Tue, 21 Jun 2005 20:56:15 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Tue, 21 Jun 2005 20:56:15 -0700 (PDT) From: "william(at)elan.net" To: Eastlake III Donald-LDE008 cc: namedroppers@ops.ietf.org Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316D47@ma19exm01.e6.bcs.mot.com> Message-ID: References: <62173B970AE0A044AED8723C3BCF238109316D47@ma19exm01.e6.bcs.mot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 21 Jun 2005, Eastlake III Donald-LDE008 wrote: > Hi, > > I have produced draft draft-eastlake-dnsext-2929bis-00.txt which is now > in the ID directories. > > It continues to have about half the RR Type Code and CALSS space > allocated by "Specification Required" but most of the instances of "IETF > Consensus" and "IETF Standards Action" have been changed to "IETF > Standards Action modified by [RFC 4020]". http://www.faqs.org/rfcs/rfc4020.html | 2. Conditions for Early Allocation | | The following conditions must hold before a request may be made for | early allocation of code points: | | a) The code points must be from a space designated as "Standards | Action", amended by IESG approval to permit Early Allocation. | | b) The format, semantics, processing, and other rules related to | handling the protocol entities defined by the code points | (henceforth called "specifications") must be adequately described | in an Internet draft that is proposed as Standards Track. | | c) The specifications of these code points must be stable; i.e., if | there is a change, implementations based on the earlier and later | specifications must be seamlessly interoperable. | | d) There is sufficient interest in early (pre-RFC) implementation and | deployment in the community. | | If conditions (a) or (b) are not met, then the processes in this memo | do not apply. Unless I'm mistaken this would not allow allocation of RR codes for experimental track drafts (it specifically says "Standard Track"). "c" and "d" may also be problematic for those who want to experiment with new RR types. So I do not believe just referencing RFC4020 will adequately address need for easy procedure of getting new RR types assigned. That is not to say that I think referencing RFC4020 for Standard Track documents is bad, just that we still need separate procedure for provisional allocation of RR types for experimental purposes. -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 00:02:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16874 for ; Wed, 22 Jun 2005 00:02:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkwPi-000AN2-4g for namedroppers-data@psg.com; Wed, 22 Jun 2005 04:00:34 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DkwPg-000AMd-I3 for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 04:00:32 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id C1123677FA for ; Wed, 22 Jun 2005 04:00:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.3/8.13.1) with ESMTP id j5M40NLH058885; Wed, 22 Jun 2005 14:00:23 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200506220400.j5M40NLH058885@drugs.dv.isc.org> To: John Levine Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Seven of nine? In-reply-to: Your message of "22 Jun 2005 03:19:03 GMT." <20050622031903.17399.qmail@xuxa.iecc.com> Date: Wed, 22 Jun 2005 14:00:23 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Let's say I have an RRset like this with a whole lot of > records of the same type: > > foo.example.com IN A 10.1.2.3 > IN A 10.1.2.4 > ... > IN A 10.1.2.99 > > I know that a lot of DNS servers will shuffle the record order around > when they answer queries for low-rent load sharing. Will they always > return all of the records, or can they return a subset, either to make > the response fit in a UDP packet, or just because? > > I'm wondering because applications like SPF will break in mysterious > non-reproducible ways if they get some but not all records in an A or > MX rrset. > > R's, > John RFC 2181 Section 5 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 00:51:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20422 for ; Wed, 22 Jun 2005 00:51:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkxAS-000DgF-Jr for namedroppers-data@psg.com; Wed, 22 Jun 2005 04:48:52 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DkxAO-000Dfw-Sv for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 04:48:48 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.51) id 1DkxAI-0002LT-BI for namedroppers@ops.ietf.org; Tue, 21 Jun 2005 23:48:47 -0500 To: "IETF DNSEXT WG" References: <200506220400.j5M40NLH058885@drugs.dv.isc.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Tue, 21 Jun 2005 23:48:11 -0500 In-Reply-To: <200506220400.j5M40NLH058885@drugs.dv.isc.org> (Mark Andrews's message of "Wed, 22 Jun 2005 14:00:23 +1000") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: Seven of nine? X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In <200506220400.j5M40NLH058885@drugs.dv.isc.org> Mark Andrews writes: >> I know that a lot of DNS servers will shuffle the record order around >> when they answer queries for low-rent load sharing. Will they always >> return all of the records, or can they return a subset, either to make >> the response fit in a UDP packet, or just because? >> >> I'm wondering because applications like SPF will break in mysterious >> non-reproducible ways if they get some but not all records in an A or >> MX rrset. Interesting that John mentioned SPF, but this subject actually came up with CSV and the Additional section of SRV records... Hmmmm... > RFC 2181 Section 5 Thanks, I knew I remembered reading this somewhere, but doing a search of the RFCs for "RR set" didn't turn up anything. (The correct search is "RRset".) Now, in the http://www.pool.ntp.org project, we have something like 300-400 NTP servers that need to be rotated through. We do this by regenerating the zone file periodically with only 15 or so hosts at a time. For a while, we had a djbdns secondary NS for the pool, but we found that it wasn't giving complete RR sets. Is this a known problem with djbdns? Are there other name servers that have this problem? -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 01:59:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25458 for ; Wed, 22 Jun 2005 01:59:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkyEJ-000J9W-QY for namedroppers-data@psg.com; Wed, 22 Jun 2005 05:56:55 +0000 Received: from [208.31.42.38] (helo=tom.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DkyEH-000J99-VH for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 05:56:54 +0000 Received: (qmail 15573 invoked from network); 22 Jun 2005 05:56:53 -0000 Received: (ofmipd 127.0.0.1); 22 Jun 2005 05:56:31 -0000 Date: 22 Jun 2005 01:56:53 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" Cc: namedroppers@ops.ietf.org Subject: Re: Seven of nine? In-Reply-To: <200506220400.j5M40NLH058885@drugs.dv.isc.org> References: <200506220400.j5M40NLH058885@drugs.dv.isc.org> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Will they always return all of the records, or can they return a > > subset, either to make the response fit in a UDP packet, or just > > because? > RFC 2181 Section 5 Um, we all know about the TC bit. The question is not whether servers will set the TC bit if they have to send a response that's too big, it's whether they'll edit down the rrset before trying to send it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 02:15:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10995 for ; Wed, 22 Jun 2005 02:15:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkyTq-000Kfc-D5 for namedroppers-data@psg.com; Wed, 22 Jun 2005 06:12:58 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DkyTn-000KfG-Ph for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 06:12:55 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 1B431677EF for ; Wed, 22 Jun 2005 06:12:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.3/8.13.1) with ESMTP id j5M6CnFg029183; Wed, 22 Jun 2005 16:12:49 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200506220612.j5M6CnFg029183@drugs.dv.isc.org> To: "John R Levine" Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Seven of nine? In-reply-to: Your message of "22 Jun 2005 01:56:53 -0400." Date: Wed, 22 Jun 2005 16:12:49 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > Will they always return all of the records, or can they return a > > > subset, either to make the response fit in a UDP packet, or just > > > because? > > > RFC 2181 Section 5 > > Um, we all know about the TC bit. The question is not whether servers > will set the TC bit if they have to send a response that's too big, it's > whether they'll edit down the rrset before trying to send it. 5.1. Sending RRs from an RRSet A query for a specific (or non-specific) label, class, and type, will always return all records in the associated RRSet - whether that be one or more RRs. The response must be marked as "truncated" if the entire RRSet will not fit in the response. There is a "all" in the first sentence. Does that answer your question? If TC is not set then the answer is complete. Note: MX record processing also depends upon complete RRset to be returned. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 02:17:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13380 for ; Wed, 22 Jun 2005 02:17:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DkyWp-000KuS-9u for namedroppers-data@psg.com; Wed, 22 Jun 2005 06:16:03 +0000 Received: from [208.31.42.38] (helo=tom.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DkyWn-000Ku9-IM for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 06:16:01 +0000 Received: (qmail 20280 invoked from network); 22 Jun 2005 06:16:00 -0000 Received: (ofmipd 127.0.0.1); 22 Jun 2005 06:15:38 -0000 Date: 22 Jun 2005 02:16:00 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" Cc: namedroppers@ops.ietf.org Subject: Re: Seven of nine? In-Reply-To: <200506220612.j5M6CnFg029183@drugs.dv.isc.org> References: <200506220612.j5M6CnFg029183@drugs.dv.isc.org> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > There is a "all" in the first sentence. Does that answer your > question? If TC is not set then the answer is complete. Yes, thanks. > Note: MX record processing also depends upon complete RRset > to be returned. I don't see why. If there's a bunch of MXes at the same distance it wouldn't be a disaster if a client didn't see all of them. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 02:38:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03686 for ; Wed, 22 Jun 2005 02:38:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dkyq5-000MPE-Vb for namedroppers-data@psg.com; Wed, 22 Jun 2005 06:35:57 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dkyq4-000MOS-CO for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 06:35:56 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id C6262677F9 for ; Wed, 22 Jun 2005 06:35:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.3/8.13.1) with ESMTP id j5M6Zm6F029304; Wed, 22 Jun 2005 16:35:48 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200506220635.j5M6Zm6F029304@drugs.dv.isc.org> To: "John R Levine" Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: Seven of nine? In-reply-to: Your message of "22 Jun 2005 02:16:00 -0400." Date: Wed, 22 Jun 2005 16:35:48 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > There is a "all" in the first sentence. Does that answer your > > question? If TC is not set then the answer is complete. > > Yes, thanks. > > > Note: MX record processing also depends upon complete RRset > > to be returned. > > I don't see why. If there's a bunch of MXes at the same distance it > wouldn't be a disaster if a client didn't see all of them. You just qualified the contents of the MX RRset. I said "MX record processing" not "MX record processing when all the MX preferences are equal". As MX RRsets can and do have different preference values you just might want to look at the error conditions that are caused when you don't have a complete MX RRset. Try running as each of the MX's in turn then drop various RR's and see what errors you trigger especially when some of the MX's can see a different set of MX records. example.net. MX 0 mx1.example.net. example.net. MX 2 mx2.example.net. example.net. MX 3 mx3.example.net. Trust me when I tell you that you will get mail bouncing and/or looping depending upon what records are missing and which MX's are running. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 02:42:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04196 for ; Wed, 22 Jun 2005 02:42:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dkyuz-000Mnv-9u for namedroppers-data@psg.com; Wed, 22 Jun 2005 06:41:01 +0000 Received: from [208.31.42.38] (helo=tom.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dkyux-000MnM-HZ for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 06:40:59 +0000 Received: (qmail 26187 invoked from network); 22 Jun 2005 06:40:56 -0000 Received: (ofmipd 127.0.0.1); 22 Jun 2005 06:40:34 -0000 Date: 22 Jun 2005 02:40:56 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" Cc: namedroppers@ops.ietf.org Subject: Re: Seven of nine? In-Reply-To: <200506220635.j5M6Zm6F029304@drugs.dv.isc.org> References: <200506220635.j5M6Zm6F029304@drugs.dv.isc.org> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > As MX RRsets can and do have different preference values > you just might want to look at the error conditions that > are caused when you don't have a complete MX RRset. If the distances are different, sure, all sorts of bad things can happen. But if the rrset had a bunch of MXes all at the same distance, any subset should do at the possible cost of delaying mail if all of the servers in the subset are unavailable but ones dropped from the set are live. This is all moot since the language is pretty clear that a server can return the entire rrset or nothing, but not part of it. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 06:48:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23672 for ; Wed, 22 Jun 2005 06:48:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dl2i1-000Epz-Nb for namedroppers-data@psg.com; Wed, 22 Jun 2005 10:43:53 +0000 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dl2hy-000EpQ-9H for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 10:43:50 +0000 Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4658B33C1C; Wed, 22 Jun 2005 11:43:53 +0100 (BST) Message-ID: <42B9406A.8030704@algroup.co.uk> Date: Wed, 22 Jun 2005 11:41:46 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Bligh CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: draft-iab-dns-choices-02.txt comments References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> <149F1464A2400B7D173C32C5@[192.168.100.25]> In-Reply-To: <149F1464A2400B7D173C32C5@[192.168.100.25]> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Bligh wrote: > > > --On 16 June 2005 04:27 +0000 Paul Vixie wrote: > >>> How does that work? I presume something like, with every query, return >>> any wildcard record that might match it OR a proof of nonexistence >>> illustrating there is no such wildcard (else there is a MiM attack >>> in stripping wildcards from responses). >> >> >> yes. and in the case of a nonterminal wildcard, that's one NSEC RR. > > > I'm still being dumb (or alternatively it's really ugly and you're OK with > that!). The whole principle of NSEC is that it proves non-existence of all > names between the closest enclosers of the QNAME. Whilst obviously one can > still canonically order QNAMEs, with non-terminal wildcards, isn't the > concept of a single closest encloser ill-defined (or to be more accurate > multi-valued)? > > What I mean by the above is that if wildcard processing is being done > client (requester) side, don't you now have to prove (putting traditional > wildcards aside for a minute) > a) that the QNAME itself doesn't exist > b) that no non-terminal wildcard covers the QNAME in question. > > I'm interested in how one might prove (b), because non-terminal wildcards > can appear anywhere in the ordering. > > If I restrict the names-space to 3 character alpha to illustrate > the point (because successor and predecessor are easier to calculate): > > $ORIGIN example.com > > ghi.** IN A 1.1.1.1 > jlk.** IN A 2.2.2.2 > abc IN A 1.2.3.4 > def IN A 2.3.4.5 > jkl IN A 3.4.5.6 > > IF I send a query for aaa.ddd.example.com, I need to prove not only that > aaa.ddd does not exist. > > With client (requester) side processing, sending an interval like > def NSEC jkl > is not sufficient to prove it, because it doesn't tell me there > is no non-terminal wildcard that might match - for instance there > might have been a record like > aaa.** IN A 7.7.7.7 > > So I will have to tell the requester client about EVERY non-terminal > wildcard. So I will have to do something like > . NSEC ghi.** > ghi.** NSEC jkl.** > jkl.** NSEC abc > (and that's enough, because abc has no ** in, I can now assure the > sender they've got all the non-terminal wildcards). > > If we don't do this, the requester cannot securely prove the non-existence > of aaa.ddd.example.com because there might HAVE been the 7.7.7.7 > non-terminal wildcard there, and the reply only proving the non-existence > of the record itself might have been replayed by a man in the middle. This sounds wrong to me. . NSEC ghi.** proves nonexistence of aaa.**. Cheers, Ben. -- >>>ApacheCon Europe<<< http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 07:08:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25231 for ; Wed, 22 Jun 2005 07:08:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dl34P-000HGQ-Bd for namedroppers-data@psg.com; Wed, 22 Jun 2005 11:07:01 +0000 Received: from [195.82.114.197] (helo=shed.alex.org.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dl34M-000HG2-2D for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 11:06:58 +0000 Received: from [192.168.100.25] (localhost [127.0.0.1]) by shed.alex.org.uk (Postfix) with ESMTP id BC3E0C2DAA; Wed, 22 Jun 2005 12:06:56 +0100 (BST) Date: Wed, 22 Jun 2005 12:06:54 +0100 From: Alex Bligh Reply-To: Alex Bligh To: Ben Laurie Cc: Paul Vixie , namedroppers@ops.ietf.org, Alex Bligh Subject: Re: draft-iab-dns-choices-02.txt comments Message-ID: <22404AA386E712FEAEC52300@[192.168.100.25]> In-Reply-To: <42B9406A.8030704@algroup.co.uk> References: <20050610230803.8240.qmail@xuxa.iecc.com> <009101c56e63$0e82fbd0$8217a8c0@arport2v> <551F5DC6-EC29-4C0E-A7E4-A4DAA68F28A2@cisco.com> <20050613001155.A297013925@sa.vix.com> <6E5603E8D6D2321E4342E311@[192.168.100.25]> <20050613132017.A740913925@sa.vix.com> <20050613135222.C5DE2139B5@sa.vix.com> <88BA84A491E507F8B728DBCA@[192.168.100.25]> <20050613155137.74CDC13925@sa.vix.com> <20050613162800.9A85313A76@sa.vix.com> <42B00B42.4020303@algroup.co.uk> <20050615200259.2346D13925@sa.vix.com> <20050616042747.185A713925@sa.vix.com> <149F1464A2400B7D173C32C5@[192.168.100.25]> <42B9406A.8030704@algroup.co.uk> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 22 June 2005 11:41 +0100 Ben Laurie wrote: > This sounds wrong to me. > > . NSEC ghi.** > > proves nonexistence of aaa.**. Hmmm... yes. I now don't understand my own point :-) I'm sure it made sense at the time. Alex -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 09:12:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07257 for ; Wed, 22 Jun 2005 09:12:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dl4xv-000148-1b for namedroppers-data@psg.com; Wed, 22 Jun 2005 13:08:27 +0000 Received: from [131.111.8.130] (helo=ppsw-0.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dl4xr-00013O-5j for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 13:08:23 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39097) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1Dl4xk-0001Ny-0V (Exim 4.51) for namedroppers@ops.ietf.org (return-path ); Wed, 22 Jun 2005 14:08:16 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Dl4xj-0002r4-SW (Exim 4.43) for namedroppers@ops.ietf.org (return-path ); Wed, 22 Jun 2005 14:08:16 +0100 Date: Wed, 22 Jun 2005 14:08:15 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: IETF DNSEXT WG Subject: Re: Seven of nine? In-Reply-To: Message-ID: References: <200506220400.j5M40NLH058885@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 21 Jun 2005, wayne wrote: > > Now, in the http://www.pool.ntp.org project, we have something like > 300-400 NTP servers that need to be rotated through. We do this by > regenerating the zone file periodically with only 15 or so hosts at a > time. For a while, we had a djbdns secondary NS for the pool, but we > found that it wasn't giving complete RR sets. > > Is this a known problem with djbdns? Are there other name servers > that have this problem? Our hostmasters tell me that djbdns has a limit of 8 records per RRset. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 10:40:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17720 for ; Wed, 22 Jun 2005 10:40:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dl6MD-0008Pi-8B for namedroppers-data@psg.com; Wed, 22 Jun 2005 14:37:37 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dl6MA-0008P6-GZ for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 14:37:34 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.51) id 1Dl6M3-00082v-Lh for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 09:37:33 -0500 To: "IETF DNSEXT WG" References: <200506220400.j5M40NLH058885@drugs.dv.isc.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 22 Jun 2005 09:36:56 -0500 In-Reply-To: (Tony Finch's message of "Wed, 22 Jun 2005 14:08:15 +0100") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: Seven of nine? X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In Tony Finch writes: > On Tue, 21 Jun 2005, wayne wrote: >> >> Now, in the http://www.pool.ntp.org project, we have something like >> 300-400 NTP servers that need to be rotated through. We do this by >> regenerating the zone file periodically with only 15 or so hosts at a >> time. For a while, we had a djbdns secondary NS for the pool, but we >> found that it wasn't giving complete RR sets. >> >> Is this a known problem with djbdns? Are there other name servers >> that have this problem? > > Our hostmasters tell me that djbdns has a limit of 8 records per RRset. That matches my recollection of the problems that the NTP Pool project found. (e.g. it was about half the correct RRset size.) If I recall correctly, even though djbdns truncated the RRset, it didn't set the TC bit. Can anyone confirm this? -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 11:06:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20976 for ; Wed, 22 Jun 2005 11:06:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dl6lP-000B9w-9T for namedroppers-data@psg.com; Wed, 22 Jun 2005 15:03:39 +0000 Received: from [67.52.51.34] (helo=backbone.schlitt.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dl6lL-000B9X-KT for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 15:03:35 +0000 Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.51) id 1Dl6lF-0000Gy-VG for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 10:03:34 -0500 To: "IETF DNSEXT WG" References: <200506220400.j5M40NLH058885@drugs.dv.isc.org> From: wayne Mail-Copies-To: nobody Reply-To: "IETF DNSEXT WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 22 Jun 2005 10:02:59 -0500 In-Reply-To: (Tony Finch's message of "Wed, 22 Jun 2005 14:08:15 +0100") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: namedroppers@ops.ietf.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: Seven of nine? X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In Tony Finch writes: > On Tue, 21 Jun 2005, wayne wrote: >> >> Is this a known problem with djbdns? Are there other name servers >> that have this problem? > > Our hostmasters tell me that djbdns has a limit of 8 records per RRset. Also, is giving incomplete RRsets a bug in just djbdns, or is the DJB caching thing also broken? -wayne -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 11:49:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25464 for ; Wed, 22 Jun 2005 11:49:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dl7OW-000EL2-K2 for namedroppers-data@psg.com; Wed, 22 Jun 2005 15:44:04 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1Dl7OT-000EKb-7Q for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 15:44:01 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id j5MFhwYm010120 for ; Wed, 22 Jun 2005 17:43:58 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id j5MFhwV11359 for ; Wed, 22 Jun 2005 17:43:58 +0200 (MEST) Message-Id: <200506221543.j5MFhwV11359@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07 In-reply-to: Your message of "Mon, 20 Jun 2005 15:59:38 EDT." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11353.1119455033.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 22 Jun 2005 17:43:58 +0200 From: Peter Koch X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis > >> no special processing occurs. An asterisk label in a query name > >> only (label) matches an asterisk label in the existing zone tree > >> when the 4.3.2 algorithm is being followed. > > > >Should "(label)" be deleted? > > I'll have to see if I defined "label match" to try and clear up what is turns out to have been a parsing problem on my side, but the clarification might also assist others. > >This is a clarification that has not been made in any RFC before. While > >I agree with the intent (it's not that bad, alphabetical order is fine, > >although some rollback is needed), this statement has side effects beyond > >the definition and application of wildcards. That's fine, but it's more > >than the introduction declares, so that should be changed. > > Interesting call. That statement has been made by Rob Austein a few > times. That's where I got it from and have used it in other threads. Violent agreement here, the clarification itself is fine. It just influences more than wildcards, but also e.g. whether the NS RRs for a delegated zone will end up in the answer or authority section when asking the parent's servers). > For example, a query for type=DS or NSEC for delegation point could > arguably be in a or b, but still only one of 'a' or 'b' or even 'c' > will hold. OK, so there's a degree of freedom to choose between 'a' and 'b'. It is possible, from the description given, that a query might fit equally well into both part a and part b. Directing the final decision is not within the scope of this document. > Maybe (I'll) just drop the last sentence. Your clarification helped and I think it's useful to explicitly state that an implementation may decide (or may have to consult other documents for a guided decision) here. > > *.AC. *.IO. *.MP. *.SH. *.TM. > > Well, the IETF doesn't do enforcement...;) Not advocating in that direction, nor defending the setup. Just a heads up in response to "this is a corner case of no practical relevance". > >"*" subdomain, could it be secured by the "*" DS RR? This will have > >implications for the interpretation of "* NS", won't it? > > Meaningless - if I did synthesize a DS RRSet, there isn't a reliable > NS RRSet to correspond to it (therefore no DNSKEY RRSet) to make it > worthwhile. I admit to running out of steam when I wrote that part, > but a DS RRSet without a corresponding DNSKEY RRSet is pretty > meaningless in the larger scheme of the world. Agreed, but that assumes that "* NS" doesn't even work literally, i.e. for the "*" subdomain without being a source of synthesis. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 14:29:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl9yI-0005Ib-W3 for dnsext-archive@megatron.ietf.org; Wed, 22 Jun 2005 14:29:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14010 for ; Wed, 22 Jun 2005 14:29:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dl9uN-0002c4-4B for namedroppers-data@psg.com; Wed, 22 Jun 2005 18:25:07 +0000 Received: from [144.189.100.106] (helo=motgate6.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dl9uL-0002bO-5N for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 18:25:05 +0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id j5MIP3G5015980 for ; Wed, 22 Jun 2005 11:25:04 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j5MISNiO010621 for ; Wed, 22 Jun 2005 13:28:24 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Jun 2005 14:25:01 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316D4D@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Date: Wed, 22 Jun 2005 14:25:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Well, I'm open to suggestions as to what forumulation we want for these allocation decisions. I could replace all occurances of "IETF Standards Action modified by [RFC 4020]" in the new draft with "the DNS Special Allocation policy" and then add a section defining that policy as "1. IETF Standards Action or 2. Approval as an an Experimental Protocol or 3. As provided in RFC 4020, or its successor, for Early Allocation except that the crieria in Section 2 of RFC 4020 are replaced by the following: 3.a: The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet draft that is intended to become Standards Track or Expeirmental. 3.b: There is sufficient interest in early (pre-RFC) implementation and deployment in the community as determined by working group consensus." The above is just off the top of my head and could be made tighter or looser. Particularly the stability criterion in RFC 4020 could be added. It seems to me there will always be tension between the idea that unstable usage/experimentation should use values from the private usage range so avoid using up regular numbers for things that may never be deployed and the idea that such things may stabilize and become popular resulting in deployment with a private usage value that might conflict with other private usage, etc. Given how many type codes are available, I think wasting a few on experiments that end up going nowhere isn't that much of a problem. So I don't see the need for added a stability criterion to item 3 above. Thanks, Donald -----Original Message----- From: william(at)elan.net [mailto:william@elan.net] Sent: Tuesday, June 21, 2005 11:56 PM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt On Tue, 21 Jun 2005, Eastlake III Donald-LDE008 wrote: > Hi, > > I have produced draft draft-eastlake-dnsext-2929bis-00.txt which is now > in the ID directories. > > It continues to have about half the RR Type Code and CALSS space > allocated by "Specification Required" but most of the instances of "IETF > Consensus" and "IETF Standards Action" have been changed to "IETF > Standards Action modified by [RFC 4020]". http://www.faqs.org/rfcs/rfc4020.html | 2. Conditions for Early Allocation | | The following conditions must hold before a request may be made for | early allocation of code points: | | a) The code points must be from a space designated as "Standards | Action", amended by IESG approval to permit Early Allocation. | | b) The format, semantics, processing, and other rules related to | handling the protocol entities defined by the code points | (henceforth called "specifications") must be adequately described | in an Internet draft that is proposed as Standards Track. | | c) The specifications of these code points must be stable; i.e., if | there is a change, implementations based on the earlier and later | specifications must be seamlessly interoperable. | | d) There is sufficient interest in early (pre-RFC) implementation and | deployment in the community. | | If conditions (a) or (b) are not met, then the processes in this memo | do not apply. Unless I'm mistaken this would not allow allocation of RR codes for experimental track drafts (it specifically says "Standard Track"). "c" and "d" may also be problematic for those who want to experiment with new RR types. So I do not believe just referencing RFC4020 will adequately address need for easy procedure of getting new RR types assigned. That is not to say that I think referencing RFC4020 for Standard Track documents is bad, just that we still need separate procedure for provisional allocation of RR types for experimental purposes. -- William Leibzon Elan Networks william@elan.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 14:34:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlA3l-0008I1-Pt for dnsext-archive@megatron.ietf.org; Wed, 22 Jun 2005 14:34:49 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14453 for ; Wed, 22 Jun 2005 14:34:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlA1b-0003E0-2h for namedroppers-data@psg.com; Wed, 22 Jun 2005 18:32:35 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DlA1Y-0003Dg-Pg for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 18:32:33 +0000 Received: from [10.31.37.51] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5MIWKLE057772; Wed, 22 Jun 2005 14:32:20 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316D4D@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF238109316D4D@ma19exm01.e6.bcs.mot.com> Date: Wed, 22 Jun 2005 14:32:19 -0400 To: Eastlake III Donald-LDE008 From: Edward Lewis Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks for starting this...I'm just busy at the moment. If I had time at the moment, I'd certainly be contributing. At 14:25 -0400 6/22/05, Eastlake III Donald-LDE008 wrote: >Well, I'm open to suggestions as to what forumulation we want for >these allocation decisions. > >I could replace all occurances of "IETF Standards Action modified by >[RFC 4020]" in the new draft with "the DNS Special Allocation >policy" and then add a section defining that policy as > >"1. IETF Standards Action or > 2. Approval as an an Experimental Protocol or > 3. As provided in RFC 4020, or its successor, for Early Allocation >except that the crieria in Section 2 of RFC 4020 are replaced by the >following: > 3.a: The format, semantics, processing, and other rules related to > handling the protocol entities defined by the code points > (henceforth called "specifications") must be adequately described > in an Internet draft that is intended to become Standards Track or > Expeirmental. > 3.b: There is sufficient interest in early (pre-RFC) implementation and > deployment in the community as determined by working group > consensus." > >The above is just off the top of my head and could be made tighter >or looser. Particularly the stability criterion in RFC 4020 could be >added. > >It seems to me there will always be tension between the idea that >unstable usage/experimentation should use values from the private >usage range so avoid using up regular numbers for things that may >never be deployed and the idea that such things may stabilize and >become popular resulting in deployment with a private usage value >that might conflict with other private usage, etc. Given how many >type codes are available, I think wasting a few on experiments that >end up going nowhere isn't that much of a problem. So I don't see >the need for added a stability criterion to item 3 above. > >Thanks, >Donald > > > > > >-----Original Message----- >From: william(at)elan.net [mailto:william@elan.net] >Sent: Tuesday, June 21, 2005 11:56 PM >To: Eastlake III Donald-LDE008 >Cc: namedroppers@ops.ietf.org >Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt > > > >On Tue, 21 Jun 2005, Eastlake III Donald-LDE008 wrote: > >> Hi, >> >> I have produced draft draft-eastlake-dnsext-2929bis-00.txt which is now >> in the ID directories. >> >> It continues to have about half the RR Type Code and CALSS space >> allocated by "Specification Required" but most of the instances of "IETF >> Consensus" and "IETF Standards Action" have been changed to "IETF >> Standards Action modified by [RFC 4020]". > >http://www.faqs.org/rfcs/rfc4020.html > >| 2. Conditions for Early Allocation >| >| The following conditions must hold before a request may be made for >| early allocation of code points: >| >| a) The code points must be from a space designated as "Standards >| Action", amended by IESG approval to permit Early Allocation. >| >| b) The format, semantics, processing, and other rules related to >| handling the protocol entities defined by the code points >| (henceforth called "specifications") must be adequately described >| in an Internet draft that is proposed as Standards Track. >| >| c) The specifications of these code points must be stable; i.e., if >| there is a change, implementations based on the earlier and later >| specifications must be seamlessly interoperable. >| >| d) There is sufficient interest in early (pre-RFC) implementation and >| deployment in the community. >| >| If conditions (a) or (b) are not met, then the processes in this memo >| do not apply. > >Unless I'm mistaken this would not allow allocation of RR codes for >experimental track drafts (it specifically says "Standard Track"). > >"c" and "d" may also be problematic for those who want to experiment >with new RR types. > >So I do not believe just referencing RFC4020 will adequately address >need for easy procedure of getting new RR types assigned. That is not >to say that I think referencing RFC4020 for Standard Track documents >is bad, just that we still need separate procedure for provisional >allocation of RR types for experimental purposes. > >-- >William Leibzon >Elan Networks >william@elan.net > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 15:54:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBIe-0008TE-Be for dnsext-archive@megatron.ietf.org; Wed, 22 Jun 2005 15:54:16 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23781 for ; Wed, 22 Jun 2005 15:54:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlBEZ-000A82-97 for namedroppers-data@psg.com; Wed, 22 Jun 2005 19:50:03 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DlBEY-000A7Z-I1 for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 19:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DlBEX-0004Wk-LR; Wed, 22 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tsig-sha-04.txt Message-Id: Date: Wed, 22 Jun 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 : HMAC SHA TSIG Algorithm Identifiers Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tsig-sha-04.txt Pages : 10 Date : 2005-6-22 Use of the TSIG DNS resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-tsig-sha-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-tsig-sha-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: <2005-6-22144625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-tsig-sha-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-tsig-sha-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-22144625.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 19:03:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlEGC-0005Kq-07 for dnsext-archive@megatron.ietf.org; Wed, 22 Jun 2005 19:03:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15672 for ; Wed, 22 Jun 2005 19:03:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlECQ-00014i-Ua for namedroppers-data@psg.com; Wed, 22 Jun 2005 23:00:02 +0000 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DlECO-00013P-4L for namedroppers@ops.ietf.org; Wed, 22 Jun 2005 23:00:00 +0000 Received: from drugs.dv.isc.org (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 3943E677F6 for ; Wed, 22 Jun 2005 22:59:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.3/8.13.1) with ESMTP id j5MMxuNM082044 for ; Thu, 23 Jun 2005 08:59:56 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200506222259.j5MMxuNM082044@drugs.dv.isc.org> To: "IETF DNSEXT WG" From: Mark Andrews Subject: Re: Seven of nine? In-reply-to: Your message of "Wed, 22 Jun 2005 10:02:59 EST." Date: Thu, 23 Jun 2005 08:59:56 +1000 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In Tony Finch @dotat.at> writes: > > > On Tue, 21 Jun 2005, wayne wrote: > >> > >> Is this a known problem with djbdns? Are there other name servers > >> that have this problem? > > > > Our hostmasters tell me that djbdns has a limit of 8 records per RRset. > > Also, is giving incomplete RRsets a bug in just djbdns, or is the DJB > caching thing also broken? > > > -wayne RFC's are clear on what should happen. Report the bug to the author. Don't hold up development plans because of buggy implementations. Having things break is actually the fastest way to get rid of buggy implementations. People will replace them when they are not happy. This applies whether the vendor is Microsoft, us or DJB. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 23:05:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlI1f-0000Pt-Rn for dnsext-archive@megatron.ietf.org; Wed, 22 Jun 2005 23:05:12 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02759 for ; Wed, 22 Jun 2005 23:05:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlHxJ-000L5E-Dx for namedroppers-data@psg.com; Thu, 23 Jun 2005 03:00:41 +0000 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DlHxH-000L46-Cx for namedroppers@ops.ietf.org; Thu, 23 Jun 2005 03:00:39 +0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j5N39CW9001403 for ; Wed, 22 Jun 2005 20:09:14 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j5N35bmn010286 for ; Wed, 22 Jun 2005 22:05:37 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Jun 2005 23:00:33 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316D54@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-dnsext-tsig-sha-04.txt Date: Wed, 22 Jun 2005 23:00:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, The main change in draft-ietf-dnsext-tsig-sha-04.txt is to incorporate a reference to draft-eastlake-sha2-00.txt which Tony Hansen and I wrote and which contains source code for all of the SHA hash algorithms. A few other references have also been corrected. There is no change to any substantive text. Thanks, Donald ========================================================= Donald E. Eastlake III Donald.Eastlake@Motorola.com Motorola Laboratories +1-508-786-7554 (work) 111 Locke Drive +1-508-634-2066 (home) Marlboro, MA 01752 USA -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, June 22, 2005 3:50 PM To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-tsig-sha-04.txt 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 : HMAC SHA TSIG Algorithm Identifiers Author(s) : D. Eastlake 3rd Filename : draft-ietf-dnsext-tsig-sha-04.txt Pages : 10 Date : 2005-6-22 Use of the TSIG DNS resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-tsig-sha-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-tsig-sha-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. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 22 23:14:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlIAv-0001j9-Rx for dnsext-archive@megatron.ietf.org; Wed, 22 Jun 2005 23:14:46 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03279 for ; Wed, 22 Jun 2005 23:14:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlI9I-000MNp-Al for namedroppers-data@psg.com; Thu, 23 Jun 2005 03:13:04 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DlI9H-000MNW-FM for namedroppers@ops.ietf.org; Thu, 23 Jun 2005 03:13:03 +0000 Received: (qmail 5834 invoked by uid 100); 23 Jun 2005 03:12:57 -0000 Date: 23 Jun 2005 03:12:57 -0000 Message-ID: <20050623031257.5833.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: Seven of nine? In-Reply-To: <200506222259.j5MMxuNM082044@drugs.dv.isc.org> Organization: I.E.C.C., Trumansburg NY USA Cc: Mark_Andrews@isc.org Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Our hostmasters tell me that djbdns has a limit of 8 records per RRset. I took a look at the code, and found that tinydns, the server for authoritative DNS data, has special case code so that if a name has more than 8 A records, it serves a random set of 8 of them. I verified both from examining the code and by experiment that it only applies to A records. Yes, it's an impressively bad idea. >> Also, is giving incomplete RRsets a bug in just djbdns, or is the >> DJB caching thing also broken? I don't think so. The main complaint about dnscache is that it doesn't report SOAs in the authority section so that clients can't do negative cacheing. R's, John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 23 16:41:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlYWG-00040q-QB for dnsext-archive@megatron.ietf.org; Thu, 23 Jun 2005 16:41:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29661 for ; Thu, 23 Jun 2005 16:41:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlY4E-000780-6R for namedroppers-data@psg.com; Thu, 23 Jun 2005 20:12:54 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DlY4D-00077k-6s for namedroppers@ops.ietf.org; Thu, 23 Jun 2005 20:12:53 +0000 Received: (qmail 92019 invoked by uid 1016); 23 Jun 2005 20:13:17 -0000 Date: 23 Jun 2005 20:13:17 -0000 Message-ID: <20050623201317.92018.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Seven of nine? References: <200506222259.j5MMxuNM082044@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sending a huge number of A records is pretty close to the worst possible load-balancing technique. That's why DNS servers have evolved to provide better load-balancing techniques. Mark Andrews writes: > RFC's are clear on what should happen. Report the bug to the author. Changing a DNS record set does not violate the DNS protocol. Changing a DNS record set at high speed does not violate the DNS protocol. > Don't hold up development plans because of buggy implementations. If an experimental DNS client can't deal with modern load-balancing techniques then that DNS client obviously needs to be fixed. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 23 19:46:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlbOS-0005uk-2x for dnsext-archive@megatron.ietf.org; Thu, 23 Jun 2005 19:46:02 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16823 for ; Thu, 23 Jun 2005 19:45:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlbKM-000NAM-NF for namedroppers-data@psg.com; Thu, 23 Jun 2005 23:41:46 +0000 Received: from [131.111.8.131] (helo=ppsw-1.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DlbKI-000NA5-VK for namedroppers@ops.ietf.org; Thu, 23 Jun 2005 23:41:43 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:42923) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1DlbKD-0001H3-6B (Exim 4.51) (return-path ); Fri, 24 Jun 2005 00:41:37 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1DlbKD-0008P4-SV (Exim 4.43) (return-path ); Fri, 24 Jun 2005 00:41:37 +0100 Date: Fri, 24 Jun 2005 00:41:37 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: Seven of nine? In-Reply-To: <20050623201317.92018.qmail@cr.yp.to> Message-ID: References: <200506222259.j5MMxuNM082044@drugs.dv.isc.org> <20050623201317.92018.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 23 Jun 2005, D. J. Bernstein wrote: > > Changing a DNS record set does not violate the DNS protocol. Changing a > DNS record set at high speed does not violate the DNS protocol. However it does mean that tinydns can't be used as a secondary for zones with large RRsets because it will serve the wrong data. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 24 04:39:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dljid-0001ro-M8 for dnsext-archive@megatron.ietf.org; Fri, 24 Jun 2005 04:39:23 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16605 for ; Fri, 24 Jun 2005 04:39:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dljbx-0009cB-C3 for namedroppers-data@psg.com; Fri, 24 Jun 2005 08:32:29 +0000 Received: from [192.96.22.18] (helo=citadel.cequrux.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1Dljbu-0009bN-OJ for namedroppers@ops.ietf.org; Fri, 24 Jun 2005 08:32:27 +0000 Received: (from nobody@localhost) by citadel.cequrux.com (8.12.11/8.12.11) id j5O8WAFK061066 for ; Fri, 24 Jun 2005 10:32:10 +0200 (SAST) (envelope-from apb@cequrux.com) Received: by citadel.cequrux.com via recvmail id 61059; Fri, 24 Jun 2005 10:32:08 +0200 (SAST) X-Authentication-Warning: apb-laptoy.apb.alt.za: apb set sender to apb@cequrux.com using -f Date: Fri, 24 Jun 2005 10:32:03 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: Seven of nine? Message-ID: <20050624083203.GI1255@apb-laptoy.apb.alt.za> References: <200506222259.j5MMxuNM082044@drugs.dv.isc.org> <20050623201317.92018.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050623201317.92018.qmail@cr.yp.to> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 23 Jun 2005, D. J. Bernstein wrote: > Changing a DNS record set does not violate the DNS protocol. Changing a > DNS record set at high speed does not violate the DNS protocol. True, provided you change the SOA serial number every time you change anything else, and provided you never allow different servers to give different information with the same SOA serial number, and provided you do not allow the SOA serial number to increment so fast that it wraps around before the time specified in various other SOA parameters. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 24 11:26:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlq4Z-0006x3-G5 for dnsext-archive@megatron.ietf.org; Fri, 24 Jun 2005 11:26:27 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17466 for ; Fri, 24 Jun 2005 11:26:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dlpze-000OPo-3x for namedroppers-data@psg.com; Fri, 24 Jun 2005 15:21:22 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DlpzZ-000OPR-QS for namedroppers@ops.ietf.org; Fri, 24 Jun 2005 15:21:18 +0000 Received: (qmail 25683 invoked by uid 100); 24 Jun 2005 15:21:14 -0000 Date: 24 Jun 2005 15:21:14 -0000 Message-ID: <20050624152114.25682.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: Seven of nine? In-Reply-To: <20050623201317.92018.qmail@cr.yp.to> Organization: I.E.C.C., Trumansburg NY USA Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Sending a huge number of A records is pretty close to the worst >possible load-balancing technique. That's why DNS servers have >evolved to provide better load-balancing techniques. Quite true. But it shows an uncharacteristic lack of imagination to assume that the only reason a client would fetch A records is to choose a server to connect to. >If an experimental DNS client can't deal with modern load-balancing >techniques then that DNS client obviously needs to be fixed. I use this program called tcpserver. One of the things it does as it sets up a TCP session is to do a rDNS lookup to get a PTR record, and then it does a forward lookup on the name and checks so see if one of the A records it gets matches the original IP address. If that name has more than eight addresses and is served by tinydns, that check will fail randomly. Could you fix it, please? I realize that one could put a band-aid on this situation by assigning each IP a unique alias and using that alias as the rDNS PTR, but that seems like a lot of special case work to avoid a misfeature if I really do have more than eight servers in a load-sharing group. R's, John -- Regards, John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711 johnl@iecc.com, Mayor, http://johnlevine.com, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 24 15:56:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluHh-0006iK-Kg for dnsext-archive@megatron.ietf.org; Fri, 24 Jun 2005 15:56:17 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09921 for ; Fri, 24 Jun 2005 15:56:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DluAo-0000iT-HI for namedroppers-data@psg.com; Fri, 24 Jun 2005 19:49:10 +0000 Received: from [144.189.100.102] (helo=motgate4.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DluAl-0000iE-1e for namedroppers@ops.ietf.org; Fri, 24 Jun 2005 19:49:07 +0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j5OJtiSS012239 for ; Fri, 24 Jun 2005 12:55:45 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j5OJskOk019830 for ; Fri, 24 Jun 2005 14:54:47 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Jun 2005 15:49:03 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316D5F@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Cc: "'Ed.Lewis@neustar.biz'" Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Date: Fri, 24 Jun 2005 15:49:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks Ed. General comment: the purpose of RFC 2929 was to provide IANA considerations for the parts of DNS for which they did not exist. For those who were not active then, in the earlier days of the IETF, all IANA allocation was by default "Expert Review" and Jon Postel was the universal expert (not that he didn't seek advice from others on occasion). So RFC 2929 is the first place where any specific allocation policy was ever stated for DNS Type codes and a variety of other DNS parameters. I've notice one DNS parameter which still, as far as I can tell, has no IANA policy and which I should have caught when RFC 2929 was written. That's the AFSDB RR subtype field. I'll revise the 2929bis draft to liberalize most assignments along the lines of my message below and to add a policy for the AFSDB RR subtype field. Thanks, Donald -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Wednesday, June 22, 2005 2:32 PM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Thanks for starting this...I'm just busy at the moment. If I had time at the moment, I'd certainly be contributing. At 14:25 -0400 6/22/05, Eastlake III Donald-LDE008 wrote: >Well, I'm open to suggestions as to what forumulation we want for >these allocation decisions. > >I could replace all occurances of "IETF Standards Action modified by >[RFC 4020]" in the new draft with "the DNS Special Allocation >policy" and then add a section defining that policy as > >"1. IETF Standards Action or > 2. Approval as an an Experimental Protocol or > 3. As provided in RFC 4020, or its successor, for Early Allocation >except that the crieria in Section 2 of RFC 4020 are replaced by the >following: > 3.a: The format, semantics, processing, and other rules related to > handling the protocol entities defined by the code points > (henceforth called "specifications") must be adequately described > in an Internet draft that is intended to become Standards Track or > Expeirmental. > 3.b: There is sufficient interest in early (pre-RFC) implementation and > deployment in the community as determined by working group > consensus." > >The above is just off the top of my head and could be made tighter >or looser. Particularly the stability criterion in RFC 4020 could be >added. > >It seems to me there will always be tension between the idea that >unstable usage/experimentation should use values from the private >usage range so avoid using up regular numbers for things that may >never be deployed and the idea that such things may stabilize and >become popular resulting in deployment with a private usage value >that might conflict with other private usage, etc. Given how many >type codes are available, I think wasting a few on experiments that >end up going nowhere isn't that much of a problem. So I don't see >the need for added a stability criterion to item 3 above. > >Thanks, >Donald > > > > > >-----Original Message----- >From: william(at)elan.net [mailto:william@elan.net] >Sent: Tuesday, June 21, 2005 11:56 PM >To: Eastlake III Donald-LDE008 >Cc: namedroppers@ops.ietf.org >Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt > > > >On Tue, 21 Jun 2005, Eastlake III Donald-LDE008 wrote: > >> Hi, >> >> I have produced draft draft-eastlake-dnsext-2929bis-00.txt which is now >> in the ID directories. >> >> It continues to have about half the RR Type Code and CALSS space >> allocated by "Specification Required" but most of the instances of "IETF >> Consensus" and "IETF Standards Action" have been changed to "IETF >> Standards Action modified by [RFC 4020]". > >http://www.faqs.org/rfcs/rfc4020.html > >| 2. Conditions for Early Allocation >| >| The following conditions must hold before a request may be made for >| early allocation of code points: >| >| a) The code points must be from a space designated as "Standards >| Action", amended by IESG approval to permit Early Allocation. >| >| b) The format, semantics, processing, and other rules related to >| handling the protocol entities defined by the code points >| (henceforth called "specifications") must be adequately described >| in an Internet draft that is proposed as Standards Track. >| >| c) The specifications of these code points must be stable; i.e., if >| there is a change, implementations based on the earlier and later >| specifications must be seamlessly interoperable. >| >| d) There is sufficient interest in early (pre-RFC) implementation and >| deployment in the community. >| >| If conditions (a) or (b) are not met, then the processes in this memo >| do not apply. > >Unless I'm mistaken this would not allow allocation of RR codes for >experimental track drafts (it specifically says "Standard Track"). > >"c" and "d" may also be problematic for those who want to experiment >with new RR types. > >So I do not believe just referencing RFC4020 will adequately address >need for easy procedure of getting new RR types assigned. That is not >to say that I think referencing RFC4020 for Standard Track documents >is bad, just that we still need separate procedure for provisional >allocation of RR types for experimental purposes. > >-- >William Leibzon >Elan Networks >william@elan.net > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 24 17:34:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlvoe-0003pf-Lt for dnsext-archive@megatron.ietf.org; Fri, 24 Jun 2005 17:34:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27160 for ; Fri, 24 Jun 2005 17:34:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dlvlg-0008nT-H2 for namedroppers-data@psg.com; Fri, 24 Jun 2005 21:31:20 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dlvle-0008nD-L1 for namedroppers@ops.ietf.org; Fri, 24 Jun 2005 21:31:18 +0000 Received: (qmail 46862 invoked by uid 1016); 24 Jun 2005 21:31:44 -0000 Date: 24 Jun 2005 21:31:44 -0000 Message-ID: <20050624213144.46861.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Seven of nine? References: <20050623201317.92018.qmail@cr.yp.to> <20050624152114.25682.qmail@xuxa.iecc.com> <200506222259.j5MMxuNM082044@drugs.dv.isc.org> <20050623201317.92018.qmail@cr.yp.to> <20050624083203.GI1255@apb-laptoy.apb.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk John Levine writes: > I realize that one could put a band-aid on this situation by assigning > each IP a unique alias and using that alias as the rDNS PTR That isn't a band-aid. It's eliminating a harmful misconfiguration and replacing it with accurate DNS information. In djbdns terms, you should run add-host exactly once for each IP address; the documentation talks about this in detail, and unless you go digging into obscure tinydns features then add-host won't let you screw up. Alan Barrett writes: [ regarding fast changes in DNS records ] > provided you change the SOA serial number AXFR has bigger problems than its difficulties handling fast-changing records. For example, it has no way to communicate ``foo.bar has address 1.2.3.4 if this client asks, and address 5.6.7.8 if that client asks,'' even though both BIND 9 and tinydns support that feature. Fortunately, AXFR is optional, and modern DNS-replication tools do a much better job of handling the new world of DNS features. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 24 18:15:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlwRx-0005kI-Ap for dnsext-archive@megatron.ietf.org; Fri, 24 Jun 2005 18:15:01 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00595 for ; Fri, 24 Jun 2005 18:14:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlwPf-000CWg-Jg for namedroppers-data@psg.com; Fri, 24 Jun 2005 22:12:39 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DlwPe-000CWU-NZ for namedroppers@ops.ietf.org; Fri, 24 Jun 2005 22:12:39 +0000 Received: (qmail 8496 invoked by uid 100); 24 Jun 2005 22:12:37 -0000 Date: 24 Jun 2005 22:12:37 -0000 Message-ID: <20050624221237.8495.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: Seven of nine? In-Reply-To: <20050624213144.46861.qmail@cr.yp.to> Organization: I.E.C.C., Trumansburg NY USA Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I realize that one could put a band-aid on this situation by assigning >> each IP a unique alias and using that alias as the rDNS PTR > >That isn't a band-aid. It's eliminating a harmful misconfiguration and >replacing it with accurate DNS information. I don't get it. Let's say I have a rack with nine machines for my outgoing SMTP mail. They're all similarly configured, and I have a mail generating back end with a whizzo load balancer that doesn't depend on DNS. Why, other than working around this DNS server peculiarity, would it be important that they each have a different name? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 24 18:25:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlwcM-0000SC-U2 for dnsext-archive@megatron.ietf.org; Fri, 24 Jun 2005 18:25:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01939 for ; Fri, 24 Jun 2005 18:25:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlwaH-000DVI-2X for namedroppers-data@psg.com; Fri, 24 Jun 2005 22:23:37 +0000 Received: from [129.9.40.81] (helo=odvirpr4.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DlwaF-000DUv-3J for namedroppers@ops.ietf.org; Fri, 24 Jun 2005 22:23:35 +0000 Received: from odnavip4-hme0.oddc.chrysler.com (unknown [53.231.71.96]) by odvirpr4.extra.daimlerchrysler.com (Postfix) with SMTP id 73D3C46FB for ; Fri, 24 Jun 2005 18:23:34 -0400 (EDT) Received: from wokcdts1.is.chrysler.com ([53.230.102.56]) by odnavip4-hme0.oddc.chrysler.com (SMSSMTP 4.1.0.19) with SMTP id M2005062418233317240 for ; Fri, 24 Jun 2005 18:23:34 -0400 Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.252]) by wokcdts1.is.chrysler.com (8.11.7+Sun/8.9.1) with ESMTP id j5OMNXn11717 for ; Fri, 24 Jun 2005 18:23:34 -0400 (EDT) Message-ID: <42BC87E5.9000101@daimlerchrysler.com> Date: Fri, 24 Jun 2005 18:23:33 -0400 From: Kevin Darcy User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-wcard-clarify-07.txt References: <200505161937.PAA29472@ietf.org> In-Reply-To: <200505161937.PAA29472@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A couple of minor proof-reading-type edits: >2.2.3 Yet Another Definition of Existence > > RFC1034's wording is fixed by the following paragraph: > > The domain name space is a tree structure. Nodes in the tree > either own at least one RRSet and/or have descendants that > collectively own at least on RRSet. ^^ should be "one" > 2.3 When does a Wild Card Domain Name is not Special Improper grammar. Should probably be "When Is a Wild Card Domain Name Not Special?" or "When Does a Wild Card Domain Name Not Invoke [or "Incur"?] Special Processing?" - 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. archive: From owner-namedroppers@ops.ietf.org Fri Jun 24 19:07:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlxGo-00035t-HM for dnsext-archive@megatron.ietf.org; Fri, 24 Jun 2005 19:07:34 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06141 for ; Fri, 24 Jun 2005 19:07:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlxDy-000GpM-Kr for namedroppers-data@psg.com; Fri, 24 Jun 2005 23:04:38 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1DlxDx-000Goz-Qq for namedroppers@ops.ietf.org; Fri, 24 Jun 2005 23:04:38 +0000 Received: (qmail 49127 invoked by uid 1016); 24 Jun 2005 23:05:04 -0000 Date: 24 Jun 2005 23:05:04 -0000 Message-ID: <20050624230504.49126.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Seven of nine? References: <20050624213144.46861.qmail@cr.yp.to> <20050624221237.8495.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk John Levine writes: > I don't get it. Let's say that X University wants to spread its load among 100 hosts. Here's the misconfiguration, failing to declare the separate hosts: x.edu A 6.7.8.1; x.edu A 6.7.8.2; etc.; 1.8.7.6.in-addr.arpa PTR x.edu; 2.8.7.6.in-addr.arpa PTR x.edu; etc. Any client connecting to x.edu, or trying to check the PTR for 73.8.7.6, has to inspect all 100 A records, even though it cares about only a tiny fraction of the 100 hosts. Here's the correct configuration: host1.x.edu A 6.7.8.1; host2.x.edu A 6.7.8.2; etc.; 1.8.7.6.in-addr.arpa PTR host1.x.edu; etc.; and a virtual x.edu selecting a small random set of addresses. The accurate list of hosts, together with the random selection, means that the client never has to look at more than a few A records. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 24 19:28:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlxas-0000xI-Q9 for dnsext-archive@megatron.ietf.org; Fri, 24 Jun 2005 19:28:18 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08096 for ; Fri, 24 Jun 2005 19:28:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DlxYo-000IZN-RJ for namedroppers-data@psg.com; Fri, 24 Jun 2005 23:26:10 +0000 Received: from [130.105.36.66] (helo=cirrus.av8.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1DlxYm-000IZ2-4f for namedroppers@ops.ietf.org; Fri, 24 Jun 2005 23:26:08 +0000 Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j5ONQ427002676 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 24 Jun 2005 19:26:04 -0400 Date: Fri, 24 Jun 2005 19:26:04 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@cirrus.av8.net To: John Levine cc: namedroppers@ops.ietf.org Subject: Re: Seven of nine? In-Reply-To: <20050624152114.25682.qmail@xuxa.iecc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 24 Jun 2005, John Levine wrote: > I use this program called tcpserver. One of the things it does as it > sets up a TCP session is to do a rDNS lookup to get a PTR record, and > then it does a forward lookup on the name and checks so see if one of > the A records it gets matches the original IP address. The method of looking up reverse IP addresses and checking their forward names for a match is itself invalid. You should not use this check. It will fail in many more cases than you've listed. It also opens security holes that can be easily exploited. I suggest you fix your security vulnerablity. That seems more important than RRsets. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 24 22:44:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm0f1-0002d7-Q5 for dnsext-archive@megatron.ietf.org; Fri, 24 Jun 2005 22:44:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22787 for ; Fri, 24 Jun 2005 22:44:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dm0aE-0009Ef-Hm for namedroppers-data@psg.com; Sat, 25 Jun 2005 02:39:50 +0000 Received: from [208.31.42.42] (helo=xuxa.iecc.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dm0aD-0009EQ-O0 for namedroppers@ops.ietf.org; Sat, 25 Jun 2005 02:39:49 +0000 Received: (qmail 26942 invoked by uid 100); 25 Jun 2005 02:39:47 -0000 Date: 25 Jun 2005 02:39:47 -0000 Message-ID: <20050625023947.26941.qmail@xuxa.iecc.com> From: John Levine To: namedroppers@ops.ietf.org Subject: Re: Seven of nine? In-Reply-To: <20050624230504.49126.qmail@cr.yp.to> Organization: I.E.C.C., Trumansburg NY USA Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Here's the correct configuration: host1.x.edu A 6.7.8.1; host2.x.edu A >6.7.8.2; etc.; 1.8.7.6.in-addr.arpa PTR host1.x.edu; etc.; and a virtual >x.edu selecting a small random set of addresses. I can see how you might want a special purpose DNS server to do that for load sharing, although if I had a hundred servers, I suspect I would want something more sophisticated than a random number generator to even out the load. But I don't see why that makes it a good idea for a nominally general purpose DNS server to refuse to serve nine A records, or why if it's a good idea for A records, it's not an equally good idea for MX records. I don't have 100 servers. I might have a dozen, and since they're SMTP clients, nobody's going to use the A record for load sharing anyway. R's, John PS: If tinydns limits the answer section to eight A records, why doesn't it do the same thing in the additional section? $ dnsq mx y.services.net sdn.iecc.com 15 y.services.net: 412 bytes, 1+1+1+21 records, response, authoritative, noerror query: 15 y.services.net answer: y.services.net 86400 MX 42 x.services.net authority: services.net 259200 NS sdn.iecc.com additional: x.services.net 86400 A 10.0.0.0 additional: x.services.net 86400 A 10.0.0.1 additional: x.services.net 86400 A 10.0.0.10 additional: x.services.net 86400 A 10.0.0.11 additional: x.services.net 86400 A 10.0.0.12 additional: x.services.net 86400 A 10.0.0.13 additional: x.services.net 86400 A 10.0.0.14 additional: x.services.net 86400 A 10.0.0.15 additional: x.services.net 86400 A 10.0.0.16 additional: x.services.net 86400 A 10.0.0.17 additional: x.services.net 86400 A 10.0.0.18 additional: x.services.net 86400 A 10.0.0.19 additional: x.services.net 86400 A 10.0.0.2 additional: x.services.net 86400 A 10.0.0.3 additional: x.services.net 86400 A 10.0.0.4 additional: x.services.net 86400 A 10.0.0.5 additional: x.services.net 86400 A 10.0.0.6 additional: x.services.net 86400 A 10.0.0.7 additional: x.services.net 86400 A 10.0.0.8 additional: x.services.net 86400 A 10.0.0.9 additional: sdn.iecc.com 86400 A 208.31.42.94 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From NorahRitter@elearningforlegal.com Sat Jun 25 23:32:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmNsI-0006yB-2x; Sat, 25 Jun 2005 23:32:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01625; Sat, 25 Jun 2005 23:31:59 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmOH7-00004s-ET; Sat, 25 Jun 2005 23:57:43 -0400 Received: from [218.18.52.111] (helo=SZITELL) by mx2.foretec.com with smtp (Exim 4.24) id 1DmNrv-0001AL-F5; Sat, 25 Jun 2005 23:31:41 -0400 Received: from Kq0@localhost by hAlX.int (8.11.6/8.11.6); Sun, 26 Jun 2005 03:31:11 -0100 Message-ID: From: "Helen Salter" Reply-To: "Helen Salter" To: ietf-123-outbound.06@ietf.org, ietf-announce@ietf.org, ieprep-web-archive@ietf.org, dnsext-archive@ietf.org Subject: Windows & Adobe Software Starting at $29 Date: Sun, 26 Jun 2005 03:30:11 -0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NorahRitter@elearningforlegal.com Content-Type: multipart/mixed; boundary="--Fx8qEOFwyONnTt7ftNYG" X-Spam-Score: 3.6 (+++) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 5ea ----Fx8qEOFwyONnTt7ftNYG Content-Type: text/html; Content-Transfer-Encoding: quoted-printable X
Opt-in Email Special Offer &n= bsp;   unsubscribe me
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
5

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Window= s XP Pro
 3 Adobe Cre= ative Suite Premium
 4 Norton Antivirus 2005
  Flash MX 2004
 6 Corel Draw 12
 7 Adobe = Acrobat 7.0
 8 Window= s 2003 Server
 9 Alias = Maya 6 Wavefrt
 10 Adobe = Premiere
  See more= by this manufacturer
 <= /td>  Microsoft<= /td>
   Apple Software
  Customers also bought
   <= font face=3Dverdana,arial,helvetica size=3D1> these other items...
<= /td>



Microsoft Offi= ce Professional Edition *2003*
Microsoft
Choose= :
&= nbsp;
=
List Price:$899.00
Price:$69.99<= /b>
You Save:$830.01 (92= %)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Analyze= and manage business information using Access databases
  • Exchange data with other systems using enhance= d XML technology
  • Control inf= ormation sharing rules with enhanced IRM technology
  • Easy-to-use wizards to create e-mail newsletters a= nd printed marketing materials
  • More than 20 preformatted business reports
Sales Rank: #1
Shipping: Int= ernational/US or via instant download
Date Coupon Expires: June= 30th, 2005
Average Customer Review: = 3D"5 Based on 1,768 reviews. Write a= review.
Microsoft Windows XP Professional or = Longhorn Edition
Microsoft =
Choose:
<= /td> <= /a>

List Price:$279.00
Price:$49.99
You Save:<= /td>$229.01 (= 85%)



Availability:= Available for INSTANT download!
Coupon Code: ISe229
Med= ia: CD-ROM / Download

System requirements  |  Accessories  |  Other Versions

Features:

  • Desi= gned for businesses of all sizes
  • Manage digital pictures, music, video, DVDs, and more
    • More security with the ability to encrypt f= iles and folders
  • Built-in vo= ice, video, and instant messaging support
  • <= font size=3D1>Integration with Windows servers and management solutions

Sales Rank: #2
Shipping: International/US or via instant download
Date Co= upon Expires: June 30th, 2005
Average= Customer Review: 3D"5 Based on 868 reviews. Write a review.

Adobe Photoshop CS2 V 9= 0
Adobe=
Choose:=
 

List Price:<= /td> $599.00
Price:$69.99
You Save:$529.01 (90%)



= Availability: Available for INSTANT download!
Coupon Code: ISe229
Media: CD-ROM / Download

System requirements  |&nb= sp; Accessories  |  Other Versions

Features:

  • Customized workspace; save personalized workspace and tool se= ttings; create customized shortcuts
  • Unparalleled efficiency--automate production tasks with built-in = or customized scripts
  • Improv= ed file management, new design possibilities, and a more intuitive way to = create for the Web
  • Support f= or 16-bit images, digital camera raw data, and non-square pixels
  • Create or modify photos using paintin= g, drawing, and retouching tools

Sales Rank: #3
Shipping: International= /US or via instant download
Date Coupon Expires: June 30th, 200= 5
Average Customer Review: 3D"5 B= ased on 498 reviews. Write a review.=

----Fx8qEOFwyONnTt7ftNYG-- From owner-namedroppers@ops.ietf.org Mon Jun 27 04:07:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmoeK-0005z9-KU for dnsext-archive@megatron.ietf.org; Mon, 27 Jun 2005 04:07:24 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21840 for ; Mon, 27 Jun 2005 04:07:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DmoX1-0005mk-Ot for namedroppers-data@psg.com; Mon, 27 Jun 2005 07:59:51 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DmoWy-0005lz-Do for namedroppers@ops.ietf.org; Mon, 27 Jun 2005 07:59:48 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 52C5E24AF5; Mon, 27 Jun 2005 09:59:47 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6DF96249BB; Mon, 27 Jun 2005 09:59:44 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j5R7xi37023024; Mon, 27 Jun 2005 09:59:44 +0200 Date: Mon, 27 Jun 2005 09:59:44 +0200 From: "Olaf M. Kolkman" To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Message-Id: <20050627095944.3bef3106.olaf@ripe.net> In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316D4D@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF238109316D4D@ma19exm01.e6.bcs.mot.com> Organization: RIPE NCC X-Mailer: Sylpheed version 2.0.0beta3 (GTK+ 2.6.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.011623 / -5.9 X-RIPE-Signature: 3e30d4d7a24e9eeee7f270c8163e2cd9 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Jun 2005 14:25:01 -0400 Eastlake III Donald-LDE008 wrote: > Well, I'm open to suggestions as to what forumulation we want for these allocation decisions. Thanks, Donald! > I could replace all occurances of "IETF Standards Action modified by [RFC 4020]" in the new draft with "the DNS Special Allocation policy" and then add a section defining that policy as > > "1. IETF Standards Action or > 2. Approval as an an Experimental Protocol or > 3. As provided in RFC 4020, or its successor, for Early Allocation except that the crieria in Section 2 of RFC 4020 are replaced by the following: > 3.a: The format, semantics, processing, and other rules related to > handling the protocol entities defined by the code points > (henceforth called "specifications") must be adequately described > in an Internet draft that is intended to become Standards Track or > Expeirmental. > 3.b: There is sufficient interest in early (pre-RFC) implementation and > deployment in the community as determined by working group > consensus." > I like this line of thought. One detail in 3.b above; which working group? What if the I-D is a personnal submission that falls between working group cracks. I also think that you should add that the RR does not required special processing for DNS servers and clients, name compression, is case-insensitive, &c, &c. In another message you wrote: > I'll revise the 2929bis draft to liberalize most assignments along > the lines of my message below and to add a policy for the AFSDB RR > subtype field. Donald, will you be in Paris? I'd like to have this on the DNSEXT's meeting's agenda. --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 27 11:28:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvWn-0002S9-Sy for dnsext-archive@megatron.ietf.org; Mon, 27 Jun 2005 11:28:05 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03158 for ; Mon, 27 Jun 2005 11:28:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DmvQP-000EbK-TW for namedroppers-data@psg.com; Mon, 27 Jun 2005 15:21:29 +0000 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DmvQM-000EZq-M4 for namedroppers@ops.ietf.org; Mon, 27 Jun 2005 15:21:26 +0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j5RFUAW9013781 for ; Mon, 27 Jun 2005 08:30:10 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j5RFQ324004455 for ; Mon, 27 Jun 2005 10:26:03 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Jun 2005 11:21:23 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316D69@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Cc: "'Olaf M. Kolkman'" Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Date: Mon, 27 Jun 2005 11:21:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, See below at @@@ -----Original Message----- From: Olaf M. Kolkman [mailto:olaf@ripe.net] Sent: Monday, June 27, 2005 4:00 AM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt On Wed, 22 Jun 2005 14:25:01 -0400 Eastlake III Donald-LDE008 wrote: > Well, I'm open to suggestions as to what forumulation we want for these allocation decisions. Thanks, Donald! @@@ You're welcome. > I could replace all occurances of "IETF Standards Action modified by [RFC 4020]" in the new draft with "the DNS Special Allocation policy" and then add a section defining that policy as > > "1. IETF Standards Action or > 2. Approval as an an Experimental Protocol or > 3. As provided in RFC 4020, or its successor, for Early Allocation except that the crieria in Section 2 of RFC 4020 are replaced by the following: > 3.a: The format, semantics, processing, and other rules related to > handling the protocol entities defined by the code points > (henceforth called "specifications") must be adequately described > in an Internet draft that is intended to become Standards Track or > Expeirmental. > 3.b: There is sufficient interest in early (pre-RFC) implementation and > deployment in the community as determined by working group > consensus." I like this line of thought. One detail in 3.b above; which working group? What if the I-D is a personnal submission that falls between working group cracks. @@@ There are always the Specification Required and the Private Use spaces of parameter values. Given that those avenues are also available for RR Types, I'm not all that worried about personal submissions. I guess it wouldn't hurt to say "... as determined by working group consensus (or the IESG in the case of individual submissions)." I also think that you should add that the RR does not required special processing for DNS servers and clients, name compression, is case-insensitive, &c, &c. @@@ I suppose some narrow additional restrictions could be added but I'm worried about making it too complex and restrictive. The idea is to be lax :-) In another message you wrote: > I'll revise the 2929bis draft to liberalize most assignments along > the lines of my message below and to add a policy for the AFSDB RR > subtype field. Donald, will you be in Paris? I'd like to have this on the DNSEXT's meeting's agenda. @@@ Yes, I will be in Paris and would be happy to have this on the DNSEXT agenda but I may have to leave around the middle of the day Thursday so it would work best if this was scheduled to be before that. @@@ I have gone ahead and submitted a revision -01 of the 2929bis draft but would be happy to further modify it. --Olaf @@@ Thanks, @@@ Donald -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 27 13:40:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmxav-0002uh-Kf for dnsext-archive@megatron.ietf.org; Mon, 27 Jun 2005 13:40:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17421 for ; Mon, 27 Jun 2005 13:40:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DmxWg-000ASU-He for namedroppers-data@psg.com; Mon, 27 Jun 2005 17:36:06 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DmxWd-000AR4-9N for namedroppers@ops.ietf.org; Mon, 27 Jun 2005 17:36:03 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5RHZqrB082985; Mon, 27 Jun 2005 13:35:53 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316D69@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF238109316D69@ma19exm01.e6.bcs.mot.com> Date: Mon, 27 Jun 2005 13:35:52 -0400 To: Eastlake III Donald-LDE008 From: Edward Lewis Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Cc: namedroppers@ops.ietf.org, "'Olaf M. Kolkman'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk comments interleaved... At 11:21 -0400 6/27/05, Eastlake III Donald-LDE008 wrote: >Hi, > >See below at @@@ > >-----Original Message----- >From: Olaf M. Kolkman [mailto:olaf@ripe.net] >Sent: Monday, June 27, 2005 4:00 AM >To: Eastlake III Donald-LDE008 >Cc: namedroppers@ops.ietf.org >Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt > >On Wed, 22 Jun 2005 14:25:01 -0400 >Eastlake III Donald-LDE008 wrote: > >> Well, I'm open to suggestions as to what forumulation we want for >>these allocation decisions. > >Thanks, Donald! > >@@@ You're welcome. > >> I could replace all occurances of "IETF Standards Action modified >>by [RFC 4020]" in the new draft with "the DNS Special Allocation >>policy" and then add a section defining that policy as >> >> "1. IETF Standards Action or >> 2. Approval as an an Experimental Protocol or >> 3. As provided in RFC 4020, or its successor, for Early >>Allocation except that the crieria in Section 2 of RFC 4020 are >>replaced by the following: >> 3.a: The format, semantics, processing, and other rules related to >> handling the protocol entities defined by the code points >> (henceforth called "specifications") must be adequately described >> in an Internet draft that is intended to become Standards Track or >> Expeirmental. >> 3.b: There is sufficient interest in early (pre-RFC) implementation and >> deployment in the community as determined by working group >> consensus." > >I like this line of thought. > >One detail in 3.b above; which working group? What if >the I-D is a personnal submission that falls between working group >cracks. > >@@@ There are always the Specification Required and the Private Use spaces >@@@ of parameter values. Given that those avenues are also available for RR >@@@ Types, I'm not all that worried about personal submissions. I guess it >@@@ wouldn't hurt to say "... as determined by working group consensus (or >@@@ the IESG in the case of individual submissions)." Given the direction of the IESG workload, I question laying more on that group. Also, this doesn't really address the "which WG" that gives consensus. It's possible that DNSEXT WG will someday close (looking at the 6 work items listed on the charter - they are [very arguably] nearly done or languishing). If that happens we wind up with a situation similar to EPP - a WG-less protocol with about 4 or so extensions passed since the end of its group. (EPP has an IANA registry. No "standards action" or "specification required" is needed to update it - although the nature of the registry means that its an "unfair" comparison.) Perhaps I'm barking up the wrong tree. Getting a reserved spot in an IANA administered registry ought to take a lot of work. You can accomplish that while still address the needs of "early allocations" via another means. For example, we could suggest that "early" implementers choose a number (as appropriate) consistent with the number range they want to fit into - and use that in their documents. If there is no conflict, they get the number once they pass the high hurdles. If there is, well, they get another number and will have to re-code anyway. If the number selection comes from the WG, then it's possible two post-DNSEXT WGs could assume the same number. If IANA chooses, then individual submitters will be gated on IESG action. >I also think that you should add that the RR does not required special >processing for DNS servers and clients, name compression, is >case-insensitive, &c, &c. > >@@@ I suppose some narrow additional restrictions could be added but I'm >@@@ worried about making it too complex and restrictive. The idea is to be >@@@ lax :-) Lax for getting implementers what they need, not so lax (maybe) in what gets into the registry. Certainly not vice versa. ;) >In another message you wrote: > >> I'll revise the 2929bis draft to liberalize most assignments along >> the lines of my message below and to add a policy for the AFSDB RR >> subtype field. > >Donald, will you be in Paris? I'd like to have this on the DNSEXT's >meeting's agenda. > >@@@ Yes, I will be in Paris and would be happy to have this on the DNSEXT >@@@ agenda but I may have to leave around the middle of the day Thursday so >@@@ it would work best if this was scheduled to be before that. > >@@@ I have gone ahead and submitted a revision -01 of the 2929bis draft but >@@@ would be happy to further modify it. > >--Olaf > >@@@ Thanks, >@@@ Donald -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 28 03:21:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnAPd-0003yy-96 for dnsext-archive@megatron.ietf.org; Tue, 28 Jun 2005 03:21:41 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07924 for ; Tue, 28 Jun 2005 03:21:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DnAIr-0001zl-7L for namedroppers-data@psg.com; Tue, 28 Jun 2005 07:14:41 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DnAIp-0001zX-EJ for namedroppers@ops.ietf.org; Tue, 28 Jun 2005 07:14:39 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 91937245A4; Tue, 28 Jun 2005 09:14:38 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id AFA6D247E1 for ; Tue, 28 Jun 2005 09:14:37 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j5S7Eb37011572; Tue, 28 Jun 2005 09:14:37 +0200 Date: Tue, 28 Jun 2005 09:14:37 +0200 From: "Olaf M. Kolkman" To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Conclussion of Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07 Message-Id: <20050628091437.47941365.olaf@ripe.net> In-Reply-To: <20050601162917.3444dc5b.olaf@ripe.net> References: <20050601162917.3444dc5b.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 2.0.0beta3 (GTK+ 2.6.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000427 / -5.9 X-RIPE-Signature: ba3343c38d33cb6e1aeda439ccad5c16 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The last call has been completed and there is as far as I can tell one issue that is non-editorial and needs some addressing. The issue starts with Peter's message and relates to this comment. > 3. Impact of a Wild Card Domain Name On a Response > The algorithm in RFC 1034, section 4.3.2. is not intended to be > pseudo code, i.e., its steps are not intended to be followed in > strict order. The "algorithm" is a suggestion. As such, in > step 3, parts a, b, and c, do not have to be implemented in > that order. This is a clarification that has not been made in any RFC before. While I agree with the intent (it's not that bad, alphabetical order is fine, although some rollback is needed), this statement has side effects beyond the definition and application of wildcards. That's fine, but it's more than the introduction declares, so that should be changed. There is an active thread on this issue that deserves your attention. Once this issue and the editorial issues are addressed satisfactory we will allow the last sets of diffs to be reviewed ( on the diffs only ) for about 1-2 weeks and then send off the document to the IESG. At that time I will also CC the working group on the form that is send to the sheparding AD. -- Olaf Kolkman DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 28 10:52:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHSJ-0006xA-Ab for dnsext-archive@megatron.ietf.org; Tue, 28 Jun 2005 10:52:55 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16522 for ; Tue, 28 Jun 2005 10:52:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DnHNb-000EMZ-Fn for namedroppers-data@psg.com; Tue, 28 Jun 2005 14:48:03 +0000 Received: from [64.233.182.205] (helo=nproxy.gmail.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DnHNY-000ELq-M6 for namedroppers@ops.ietf.org; Tue, 28 Jun 2005 14:48:00 +0000 Received: by nproxy.gmail.com with SMTP id o25so235904nfa for ; Tue, 28 Jun 2005 07:47:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A+UKzsa0gWnIM/rtrpvRJPseMtRIMoLqhJpaAkoEdFgw3pCte29LG994Tf6ODTYUG63244G/gTaxH+bEmZXzUZhzixfclRpw6fhdBoVHDvMkoW6EHtW/sFrD9MwirOMUJDjYr4va4BwLhpp/gTLZwyGchXarbxDDkcHM6c6X7ow= Received: by 10.48.237.12 with SMTP id k12mr160884nfh; Tue, 28 Jun 2005 07:47:58 -0700 (PDT) Received: by 10.48.248.15 with HTTP; Tue, 28 Jun 2005 07:47:58 -0700 (PDT) Message-ID: <487354f105062807476d5cec32@mail.gmail.com> Date: Tue, 28 Jun 2005 16:47:58 +0200 From: Robert Martin-Legene Reply-To: Robert Martin-Legene To: "D. J. Bernstein" Subject: Re: Seven of nine? Cc: namedroppers@ops.ietf.org In-Reply-To: <20050623201317.92018.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200506222259.j5MMxuNM082044@drugs.dv.isc.org> <20050623201317.92018.qmail@cr.yp.to> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_BY_IP autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On 23 Jun 2005 20:13:17 -0000, D. J. Bernstein wrote: > Sending a huge number of A records is pretty close to the worst possible > load-balancing technique. Indeed. > Changing a DNS record set does not violate the DNS protocol. Changing a > DNS record set at high speed does not violate the DNS protocol. I don't think I understand what you specifically mean here. Maybe it's written between the lines because everyone else seems to have understood it, but my logic says it's not allowed. Would be be kind enough to explain it in further detail? -- Robert Martin-Leg=E8ne, .dk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 28 21:02:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnQyc-0001Bt-Nd for dnsext-archive@megatron.ietf.org; Tue, 28 Jun 2005 21:02:54 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18566 for ; Tue, 28 Jun 2005 21:02:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DnQuK-000LxM-T2 for namedroppers-data@psg.com; Wed, 29 Jun 2005 00:58:28 +0000 Received: from [144.189.100.103] (helo=motgate3.mot.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DnQuH-000Lwr-Ts for namedroppers@ops.ietf.org; Wed, 29 Jun 2005 00:58:26 +0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id j5T1A2ZH026599 for ; Tue, 28 Jun 2005 18:10:02 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id j5T12noa004816 for ; Tue, 28 Jun 2005 20:02:49 -0500 (CDT) Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 28 Jun 2005 20:58:22 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238109316D7E@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Cc: "'Ed.Lewis@neustar.biz'" Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Date: Tue, 28 Jun 2005 20:58:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,BIZ_TLD autolearn=no version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk See below at ### -----Original Message----- From: Edward Lewis [mailto:Ed.Lewis@neustar.biz] Sent: Monday, June 27, 2005 1:36 PM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org; 'Olaf M. Kolkman' Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt comments interleaved... At 11:21 -0400 6/27/05, Eastlake III Donald-LDE008 wrote: >Hi, > >See below at @@@ > >-----Original Message----- >From: Olaf M. Kolkman [mailto:olaf@ripe.net] >Sent: Monday, June 27, 2005 4:00 AM >To: Eastlake III Donald-LDE008 >Cc: namedroppers@ops.ietf.org >Subject: Re: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt > >On Wed, 22 Jun 2005 14:25:01 -0400 >Eastlake III Donald-LDE008 wrote: > >> Well, I'm open to suggestions as to what forumulation we want for >>these allocation decisions. > >Thanks, Donald! > >@@@ You're welcome. > >> I could replace all occurances of "IETF Standards Action modified >>by [RFC 4020]" in the new draft with "the DNS Special Allocation >>policy" and then add a section defining that policy as >> >> "1. IETF Standards Action or >> 2. Approval as an an Experimental Protocol or >> 3. As provided in RFC 4020, or its successor, for Early >>Allocation except that the crieria in Section 2 of RFC 4020 are >>replaced by the following: >> 3.a: The format, semantics, processing, and other rules related to >> handling the protocol entities defined by the code points >> (henceforth called "specifications") must be adequately described >> in an Internet draft that is intended to become Standards Track or >> Expeirmental. >> 3.b: There is sufficient interest in early (pre-RFC) implementation and >> deployment in the community as determined by working group >> consensus." > >I like this line of thought. > >One detail in 3.b above; which working group? What if >the I-D is a personnal submission that falls between working group >cracks. > >@@@ There are always the Specification Required and the Private Use spaces >@@@ of parameter values. Given that those avenues are also available for RR >@@@ Types, I'm not all that worried about personal submissions. I guess it >@@@ wouldn't hurt to say "... as determined by working group consensus (or >@@@ the IESG in the case of individual submissions)." Given the direction of the IESG workload, I question laying more on that group. Also, this doesn't really address the "which WG" that gives consensus. ### Well, the current criteria for these parameters in RFC 2929 is "IETF Consensus". RFC 2434 defines that as "new assignments are made via RFCs approved by the IESG". So any change is likely to *reduce* the theoretic load on the IESG. As to which wokring group the intent is the working group whose protocol needs the value. It's possible that DNSEXT WG will someday close (looking at the 6 work items listed on the charter - they are [very arguably] nearly done or languishing). If that happens we wind up with a situation similar to EPP - a WG-less protocol with about 4 or so extensions passed since the end of its group. (EPP has an IANA registry. No "standards action" or "specification required" is needed to update it - although the nature of the registry means that its an "unfair" comparison.) ### Indeed, it is specifically prohibited to have anything in a standard or any IANA allocation process depend on the perpetual existence of any working group. If you are worried about some random working group approving some RR Type without it going through DNSEXT you are asking for something not possible within IETF procedure. It would be reasonable to add a provision that the early allocation request also be approved by the WG's AD. Perhaps I'm barking up the wrong tree. Getting a reserved spot in an IANA administered registry ought to take a lot of work. You can ### That depends on supply and demand. Some registries are essentially infinte and first come first served works fine as the allocation rule. The great benefit of having Jon Postel be the judge of all these things was that he generally had reasonable judgement and could apply varying back pressure to assignment requests depending on the code point space left and how rapidly requests were arriving. We now have to guess and establish rules. But what people were complaining about was that it was too hard to get an RR Type. So whatever we adopt had better be easier than "Specification Required" has worked out to be in practice. accomplish that while still address the needs of "early allocations" via another means. For example, we could suggest that "early" implementers choose a number (as appropriate) consistent with the number range they want to fit into - and use that in their documents. If there is no conflict, they get the number once they pass the high hurdles. If there is, well, they get another number and will have to re-code anyway. ### But the problem I thought we were trying to address is that after people implement with a number they choose, their code escapes and/or they are too lazy to ever doing anything else about allocation, so you end up with deployed code with random code and no central record and, sooner-or-later, conflicts. If the number selection comes from the WG, then it's possible two post-DNSEXT WGs could assume the same number. If IANA chooses, then individual submitters will be gated on IESG action. >I also think that you should add that the RR does not required special >processing for DNS servers and clients, name compression, is >case-insensitive, &c, &c. > >@@@ I suppose some narrow additional restrictions could be added but I'm >@@@ worried about making it too complex and restrictive. The idea is to be >@@@ lax :-) Lax for getting implementers what they need, not so lax (maybe) in what gets into the registry. Certainly not vice versa. ;) ### Perhaps not laxer for permanent registry entries but the Early Allocation idea is basicaly a temporary registry entry. Quoting from RFC 4020: 5) IANA makes an allocation from the appropriate registry, marking it as "temporary", valid for a period of one year from the date of allocation. The date of allocation should also be recorded in the registry and made visible to the public. >In another message you wrote: > >> I'll revise the 2929bis draft to liberalize most assignments along >> the lines of my message below and to add a policy for the AFSDB RR >> subtype field. > >Donald, will you be in Paris? I'd like to have this on the DNSEXT's >meeting's agenda. > >@@@ Yes, I will be in Paris and would be happy to have this on the DNSEXT >@@@ agenda but I may have to leave around the middle of the day Thursday so >@@@ it would work best if this was scheduled to be before that. > >@@@ I have gone ahead and submitted a revision -01 of the 2929bis draft but >@@@ would be happy to further modify it. > >--Olaf ### Thanks, ### Donald -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 29 04:38:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnY5z-0005Md-3C for dnsext-archive@megatron.ietf.org; Wed, 29 Jun 2005 04:38:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22820 for ; Wed, 29 Jun 2005 04:38:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DnY17-000AGe-TW for namedroppers-data@psg.com; Wed, 29 Jun 2005 08:33:57 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DnY16-000AGR-1h for namedroppers@ops.ietf.org; Wed, 29 Jun 2005 08:33:56 +0000 Received: by postman.ripe.net (Postfix, from userid 4008) id 58EC72471C; Wed, 29 Jun 2005 10:33:55 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6A5F02470B; Wed, 29 Jun 2005 10:33:54 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id j5T8Xs37027599; Wed, 29 Jun 2005 10:33:54 +0200 Date: Wed, 29 Jun 2005 10:33:54 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Cc: Margaret Wasserman , Mark Townsley Subject: Work Item: draft-eastlake-dnsext-2929bis? Message-Id: <20050629103354.6f04d5de.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 2.0.0beta3 (GTK+ 2.6.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000940 / -5.9 X-RIPE-Signature: fdb70f1938c201aa54b56210bbc5ae3e X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Colleagues, draft-eastlake-dnsext-2929bis-01.txt is now getting some attention from members of this list. Since this I-D is targeted to update RFC2929, the output of a distant predecessor of this group, it seems that to me that this document should become a WG item. Please let us know if there are objections. Since this is "on the edge" of our Charter I CC-ed our ADs. If I've heard no objections by Monday I'll inform that secretariat that they will have to accept draft-ietf-dnsext-2929bis as a version 00 submission. -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 29 10:37:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dndh6-00046r-F2 for dnsext-archive@megatron.ietf.org; Wed, 29 Jun 2005 10:37:40 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26974 for ; Wed, 29 Jun 2005 10:37:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DndaR-0009gi-AZ for namedroppers-data@psg.com; Wed, 29 Jun 2005 14:30:47 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DndaQ-0009g7-2H for namedroppers@ops.ietf.org; Wed, 29 Jun 2005 14:30:46 +0000 Received: from [10.31.32.195] (ns.ogud.com [66.92.146.160]) by ogud.com (8.12.11/8.12.11) with ESMTP id j5TEUW5F094267; Wed, 29 Jun 2005 10:30:33 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <62173B970AE0A044AED8723C3BCF238109316D7E@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF238109316D7E@ma19exm01.e6.bcs.mot.com> Date: Wed, 29 Jun 2005 10:30:34 -0400 To: Eastlake III Donald-LDE008 From: Edward Lewis Subject: RE: DNS IANA Considerations, draft-eastlake-dnsext-2929bis-00.txt Cc: namedroppers@ops.ietf.org, "'Ed.Lewis@neustar.biz'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.51 on 66.92.146.160 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message demarcation thing is a pain ;) so I've taken the liberty of removing the old context... At 20:58 -0400 6/28/05, Eastlake III Donald-LDE008 wrote: >Well, the current criteria for these parameters in RFC 2929 is "IETF >Consensus". RFC 2434 defines that as "new assignments are made via RFCs >approved by the IESG". So any change is likely to *reduce* the theoretic >load on the IESG. As to which working group the intent is the working group >whose protocol needs the value. Either way, I think we ought to be shielding the IESG from having to make operational (in the sense of moving the bureaucracy along) decisions. OTOH, if there is no DNS WG, I am not sure the other WGs are really prepared to make DNS related decisions - and in that case it falls to the shepherding AD anyway. >Indeed, it is specifically prohibited to have anything in a standard or any >IANA allocation process depend on the perpetual existence of any working >group. If you are worried about some random working group approving some RR >Type without it going through DNSEXT you are asking for something not possible >within IETF procedure. It would be reasonable to add a provision that the >early allocation request also be approved by the WG's AD. The way I see it, there are two options in the event of there being no sitting DNS WG. 1) With or without DNS WG, IANA is given clear instructions and guidance for situations that have not been anticipated in the allocation of parameters. This is moving the bureaucracy out of the engineering department and into the operational registry function. I'm sure we can quantify some criteria for "innocuous" RR definitions that we will be confident can be easily, transparently, and clearly followed by someone without having to get involved in a debate. 2) In the absence of a DNS WG, recognize that the WG's AD, or maybe the document's shepherding AD, is the ombudsman that will make sure suitable DNS expertise is called in. The big trouble I have with this is that the calling of an expert is rarely an open process and doesn't tend to scale very well in engineering situations. >That depends on supply and demand. Some registries are essentially infinte and >first come first served works fine as the allocation rule. The great benefit >of having Jon Postel be the judge of all these things was that he generally >had reasonable judgement and could apply varying back pressure to assignment >requests depending on the code point space left and how rapidly requests were >arriving. We now have to guess and establish rules. But what people were >complaining about was that it was too hard to get an RR Type. So whatever we >adopt had better be easier than "Specification Required" has worked out to be >in practice. I didn't know Jon Postel personally, but I know he made a strong impression on many folks still active on this list. From anecdotal evidence, I'll proffer that he was a unique person in a unique era. Would someone of his talents, entering the Internet today, be available for the same post? Back in the day, the IANA function was a place to be a pioneer. Nowadays, the chains (and budget) on it make it a place where pioneering is not to be encouraged. I'll reiterate this - I am not commenting on the way IANA's staff is operating. I am commenting on the position the community places the "critical infrastructure staffs" in - that of a place where we want them to do "the job" in a fair manner above all else. This tends to discourage staff members from sticking their necks out at a conformant by unwise request. Relying on a personality (as opposed to a person) to do a job does not scale - not in volume nor in time. >But the problem I thought we were trying to address is that after people >implement with a number they choose, their code escapes and/or they are too >lazy to ever doing anything else about allocation, so you end up with deployed >code with random code and no central record and, sooner-or-later, conflicts. I don't think the dynamic works that way, and, above that, I don't think that is the problem we face today. I think the problem is that implementers are rightfully choosing the path of least resistance to adding data to the DNS. And that path goes right through the TXT RR and name prefixes because doing the "right thing" is a pain becuase of the bureaucratic rules *we* have laid down. I do think that implementers, seeing their code fly off the FTP servers, do want to make an official record of it. That's the early RFCs. And I think of the time the original coder of SSH came to the SSH WG meeting and pleaded for them to change the name so he could get a trademark on SSH. Successful efforts to get capped off. OTOH, it is the unsuccessful (or limited success) cases that are a pain. For this reason, all code ought to follow the "liberal in accept, conservative on transmit" bon mot. >Perhaps not laxer for permanent registry entries but the Early Allocation >idea is basicaly a temporary registry entry. Quoting from RFC 4020: > 5) IANA makes an allocation from the appropriate registry, marking it > as "temporary", valid for a period of one year from the date of > allocation. The date of allocation should also be recorded in the > registry and made visible to the public. I missed the one year term. But, requiring a high bar (like IESG consent) might work out to getting a one year lease two years after the code is first developed. I would suggest that getting a one-year lease be done with a simple request to IANA (subject to denial of registry service and subscriber fraud checks), that renewal of a lease take something more - maybe even an IESG ok. (But I'd prefer to give two year leases as some engineering cycles will take longer. That's conjecture on my part.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 29 14:03:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnguj-0002dr-U9 for dnsext-archive@megatron.ietf.org; Wed, 29 Jun 2005 14:03:57 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19041 for ; Wed, 29 Jun 2005 14:03:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DngrY-0001gQ-2a for namedroppers-data@psg.com; Wed, 29 Jun 2005 18:00:40 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DngrW-0001fm-EM for namedroppers@ops.ietf.org; Wed, 29 Jun 2005 18:00:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j5TI0ap03821 for ; Wed, 29 Jun 2005 21:00:36 +0300 Date: Wed, 29 Jun 2005 21:00:36 +0300 (EEST) From: Pekka Savola To: namedroppers@ops.ietf.org Subject: RFC2181 section 9.1: TC bit handling and additional data Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi, In the process of finalizing draft-ietf-dnsop-ipv6-issues-xx.txt, we've had off-list discussion about TC bit handling when the criticial/courtesy additional data section should include both A and AAAA records. We would like to get some additional feedback especially on what's in the implementations out there (the recommendations in the specification seem clear enough). Specific questions (offlist responses are also fine): 1. how does your implementation (or the implementations you're familiar with) handle the case of critical additional data (example below) when the response doesn't fit. a) set TC bit and remove all the additional data RRsets b) set TC bit and remove some additional data RRsets so the size is small enough c) something else, what? 2. how does your implementation (or the implementations you're familiar with) handle the case of courtesy additional data (e.g., CNAME) when the response doesn't fit. a) remove the all the additional data RRsets if some of them don't fit, don't set TC bit. b) remove some of the additional data RRsets if the response then fits, don't set TC bit. c) set TC bit and [do something, what?] d) something else, what? 3. if your implementation (or the implemenations you're familiar with) receives a response with TC bit set and an additional section, what does it do? a) ignore everything in the response, and re-query using TCP. b) keep some or all of the data in the response, re-query using TCP (additional details would be welcome). c) something else, what? 4. do you know of any implementations which either do not set the TC bit when all the critical additional data RRsets don't fit, or do not ignore the whole response when the TC bit was set? RFC2181 states: 9. The TC (truncated) header bit The TC bit should be set in responses only when an RRSet is required as a part of the response, but could not be included in its entirety. The TC bit should not be set merely because some extra information could have been included, but there was insufficient room. This includes the results of additional section processing. In such cases the entire RRSet that will not fit in the response should be omitted, and the reply sent as is, with the TC bit clear. If the recipient of the reply needs the omitted data, it can construct a query for that data and send that separately. 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. An example of the critical additional data is shown below (where getting both the A and AAAA RRsets is critical w.r.t. to the NS RR): child.example.com. IN NS ns.child.example.com. ns.child.example.com. IN A 192.0.2.1 ns.child.example.com. IN AAAA 2001:db8::1 -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 29 15:53:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnid0-0003Z9-Ub for dnsext-archive@megatron.ietf.org; Wed, 29 Jun 2005 15:53:47 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04573 for ; Wed, 29 Jun 2005 15:53:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DniZR-000AfM-2o for namedroppers-data@psg.com; Wed, 29 Jun 2005 19:50:05 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DniZP-000AeI-BY for namedroppers@ops.ietf.org; Wed, 29 Jun 2005 19:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DniZO-0000gA-Bd; Wed, 29 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec3-02.txt Message-Id: Date: Wed, 29 Jun 2005 15:50:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 Hash Authenticated Denial of Existence Author(s) : B. Laurie, et al. Filename : draft-ietf-dnsext-nsec3-02.txt Pages : 37 Date : 2005-6-29 The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be used to provide authenticated denial of existence of DNS ownernames and types; however, it permits any user to traverse a zone and obtain a listing of all ownernames. A complete zone file can be used either directly as a source of probable e-mail addresses for spam, or indirectly as a key for multiple WHOIS queries to reveal registrant data which many registries (particularly in Europe) may be under strict legal obligations to protect. Many registries therefore prohibit copying of their zone file; however the use of NSEC RRs renders policies unenforceable. This document proposes a scheme which obscures original ownernames while permitting authenticated denial of existence of non-existent names. Non-authoritative delegation point NS RR types may be excluded. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-nsec3-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec3-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-29144510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec3-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec3-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-29144510.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: