From owner-namedroppers@ops.ietf.org Thu May 1 04:16:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02038 for ; Thu, 1 May 2003 04:16:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B95g-000F9r-00 for namedroppers-data@psg.com; Thu, 01 May 2003 08:06:52 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19B95c-000F9b-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 08:06:49 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h417kjb28816 for ; Thu, 1 May 2003 00:46:46 -0700 Date: Thu, 1 May 2003 00:46:45 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Minutes of the 4/30/03 LLMNR Conference Call Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Attendees: Erik Guttman, Randy Bush, Christian Huitema, Bernard Aboba Bernard Aboba gave a summary of the currently open issues on the LLMNR Issues page: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html These include Issue 36 which is purely editorial, as well as Issue 33, which deals with sending PTR via unicast. Issue 34 deals with sending of unicast queries via TCP. Issue 35 deals with the TTL of all queries, multicast and unicast. Issue 33 is the parent of Issues 34 and 35 in that prior to introducing the concept of a unicast query, all LLMNR queries had been done via link-scope multicast with a unicast UDP response, unless a cached NS RR existed, in which case a unicast UDP query is feasible. If the unicast response had the TC bit set, then the query would be resent using TCP. Because of this it is necessary for all responders to listen on the TCP LLMNR port, as well as the UDP LLMNR port (in the case of cached NS RRs). Erik Guttman suggested that the only way a responder might get away with not implementing a TCP listener would be if it knew that it would *never* set the TC bit. That might be hard to know in practice, given every possible query that could be answered. But if the query support were restricted (say, A/AAAA only) then this might be knowable. Issue 33 proposes that PTR queries be sent via unicast. Assuming that unicast queries are sent via UDP, this translates to a requirement for the responder to implement a UDP unicast listener. It was felt that this increases the level of vulnerability, and so is undesirable. Randy Bush asked about the situations in which PTR queries would be sent via LLMNR. Section 3 of the specification states that "LLMNR requests SHOULD be sent only when no manual or automatic DNS configuration has been performed, when DNS servers do not respond, or when they respond to a query with RCODE=3 (Authoritative Name Error) or RCODE=0 and an empty answer section." There was a question about whether in the case where RCODE=0 and the answer section is empty, whether it is appropriate to send an LLMNR query. It was noted that where IPv6 hosts are concerned, currently DNS servers respond to AAAA and IPV6 PTR RR queries with lots of different errors, including RCODE=3 and RCODE=0. So in practice, it may be necessary to use LLMNR in both cases. It was noted that it is not believed that DNSSEC will be very usable with LLMNR, although it might be possible for LLMNR responses to be validated in situations where the proper cache entries have been built up. It was noted that PTR RR queries are typically not required, since quite a few applications that use PTR RR queries don't do much with the information anyway, and in fact can handle teh failure to resolve the PTR RR gracefully. As a result, Christian Huitema suggested that implementation of PTR RR queries be optional. The first level of support for LLMNR is to send and respond to A/AAAA queries; this is the most typical use. If it was certain that the TC bit would never be set in a response, then in this case the responder might not need to implement TCP. Randy Bush pointed out that TCP support was required in RFC 1034-1035, so that the precedent was clear: omitting this functionality because you are *sure* it can't be used only leads to breakage when it turns out that ooops, it can happen after all. Beyond this, the next level of support would be SRV and other RRs. Such a responder implementation would need to implement a TCP listener. Overall, the recommendation was to accept Issue 33 (unicast PTR query); and Issue 36 (editorial), as well as Issue 35 (TTL=1). On Issue 34, possible compromise language was suggested: a. TCP listener is required for any implementation in which the TC bit can be set in a response. b. All LLMNR queries and responses MUST be sent with TTL=1. (Issue 35) c. Unicast queries SHOULD be sent via TCP. A responder with a unicast UDP listener MAY sent back an empty response with the TC bit set automatically in response to a unicast UDP query in order to force use of TCP. That implies that a sender probably needs to implement TCP anyway. d. PTR RR queries SHOULD be sent via unicast. -- 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 May 1 04:54:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02695 for ; Thu, 1 May 2003 04:54:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B9lg-000JgD-00 for namedroppers-data@psg.com; Thu, 01 May 2003 08:50:17 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 19B9le-000Jfz-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 08:50:14 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id B563993; Thu, 1 May 2003 17:50:10 +0900 (JST) To: Bernard Aboba Cc: namedroppers@ops.ietf.org In-reply-to: aboba's message of Thu, 01 May 2003 00:46:45 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Minutes of the 4/30/03 LLMNR Conference Call From: itojun@iijlab.net Date: Thu, 01 May 2003 17:50:10 +0900 Message-Id: <20030501085010.B563993@coconut.itojun.org> X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >Overall, the recommendation was to accept Issue 33 (unicast PTR query); >and Issue 36 (editorial), as well as Issue 35 (TTL=1). On Issue 34, >possible compromise language was suggested: with TCP query/response it is difficult to enforce TTL=1. do you drop TCP connection if one of packets within a TCP stream has non-1 TTL? itojun -- 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 May 1 07:56:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05996 for ; Thu, 1 May 2003 07:56:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BCau-0009nS-00 for namedroppers-data@psg.com; Thu, 01 May 2003 11:51:20 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19BCas-0009nC-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 11:51:18 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05654; Thu, 1 May 2003 07:48:23 -0400 (EDT) Message-Id: <200305011148.HAA05654@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-insensitive-03.txt Date: Thu, 01 May 2003 07:48:23 -0400 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Domain Name System (DNS) Case Insensitivity Clarification Author(s) : D. Eastlake Filename : draft-ietf-dnsext-insensitive-03.txt Pages : 10 Date : 2003-4-30 Domain Name System (DNS) names are 'case insensitive'. This document explains exactly what that means and provides a clear specification of the rules. This clarification should not have any interoperability consequences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-insensitive-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-insensitive-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-insensitive-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: <2003-4-30150752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-insensitive-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-insensitive-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-30150752.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 Thu May 1 10:36:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14017 for ; Thu, 1 May 2003 10:36:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BEz0-00021B-00 for namedroppers-data@psg.com; Thu, 01 May 2003 14:24:22 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19BEyx-00020v-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 14:24:19 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HE700FH7PD0BX@eListX.com> for namedroppers@ops.ietf.org; Thu, 01 May 2003 10:24:36 -0400 (EDT) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h41EK0QZ065819; Thu, 01 May 2003 10:20:00 -0400 (EDT envelope-from ogud@ogud.com) Date: Thu, 01 May 2003 10:23:49 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Advance: Opcode Discover X-Sender: (Unverified) To: Erik Nordmark Cc: namedroppers@ops.ietf.org, iesg-secretary@ietf.org Message-id: <5.1.1.6.2.20030501101308.022c0e90@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,RCVD_IN_RFCI version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA14017 Erik DNSEXT recommends the advance following document to experimental status: www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-01.txt Background: We had a last call concluded on this in November, the last call required some minor changes in the document. The editors concluded the edits in December. Subsequently one of the editors sent in a request to have his name taken off the draft, chairs waited for this to happen in a new version. This particular editor has rescinded the request. Thus the document can now be advanced. Olafur & Randy > From: Ólafur Gudmundsson/DNSEXT co-chair > Date: Wed, 13 Nov 2002 12:33:40 -0500 > Subject: DNSEXT WGLC Summary: Opcode-discover-00 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed > Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-UIDL: [0'"!C\S!!Dca!!(h[!! > > > This working group last call has concluded. > This work meets the technical criteria to be to be published as EXPERIMENTAL. > > Authors are requested to make the following changes before the document > is advanced to the IESG. > > 0. Number all sections that have titles. > 1. In the last paragraph before IANA consideration: > Add a comment that a responder to DISCOVER, in some cases is not a > traditional DNS server, it could be a special purpose software. > 2. References section needs to be broken into two "Normative References" > and "Informational References", please fill out references fully. > > Olafur > > >This starts a 2 week last call for this document, the document is >slated to be published as EXPERIMENTAL. > >http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-00.txt > >This document specifies a new opcode that is used to discover DNS servers >within the multicast scope of the address sent to. > >The authors main focus is to get a IANA assigned opcode for experimentation, >does this document provide enough technical details for the framework to be >experimented with. > >This working group last call completes on August 30'th 2002. > > Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 1 11:56:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18823 for ; Thu, 1 May 2003 11:56:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BGK8-000C3l-00 for namedroppers-data@psg.com; Thu, 01 May 2003 15:50:16 +0000 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 19BGK5-000C3U-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 15:50:13 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 1 May 2003 08:50:12 -0700 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 01 May 2003 08:50:12 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 1 May 2003 08:50:12 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 May 2003 08:50:11 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 1 May 2003 08:50:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Minutes of the 4/30/03 LLMNR Conference Call Date: Thu, 1 May 2003 08:50:10 -0700 Message-ID: Thread-Topic: Minutes of the 4/30/03 LLMNR Conference Call Thread-Index: AcMPwPWhLT2KlsOCSkiLKN1OIQfIcgAOB7aQ From: "Christian Huitema" To: , "Bernard Aboba" Cc: X-OriginalArrivalTime: 01 May 2003 15:50:10.0743 (UTC) FILETIME=[58CA4470:01C30FF9] X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA18823 > >Overall, the recommendation was to accept Issue 33 (unicast PTR query); > >and Issue 36 (editorial), as well as Issue 35 (TTL=1). On Issue 34, > >possible compromise language was suggested: > > with TCP query/response it is difficult to enforce TTL=1. > do you drop TCP connection if one of packets within a TCP stream > has non-1 TTL? No, you don't. However, you set TCP to send your own packets with TTL=1. The three-ways handshake guarantees that if at least one of the two hosts sets TTL=1, then both hosts are protected. -- Christian Huitema -- 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 May 1 12:19:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20399 for ; Thu, 1 May 2003 12:19:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BGjS-000EeT-00 for namedroppers-data@psg.com; Thu, 01 May 2003 16:16:26 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19BGjO-000Ee2-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 16:16:22 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by peacock.verisign.com (8.12.9/) with ESMTP id h41GGE4w001467; Thu, 1 May 2003 09:16:20 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Apr 2003 13:49:02 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Sam Weiler'" , namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Wed, 30 Apr 2003 13:48:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-8.0 required=5.0 tests=BAYES_01,OPT_IN,OPT_IN_CAPS,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sam, If someone is going to go to the trouble of deploying an IDS that is intelligent enough to do what you propose and they are going to have someone monitor it at minimum wage then they are going to be able to afford whatever it ends up costing in time, effort and so on to enable DNSSEC. Phill > -----Original Message----- > From: Sam Weiler [mailto:weiler@tislabs.com] > Sent: Wednesday, April 30, 2003 10:15 AM > To: namedroppers@ops.ietf.org > Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN > > > On Wed, 30 Apr 2003, Hallam-Baker, Phillip wrote: > > > > What value do you claim there is to securing the > delegation without > > any security on the delegated zone? > > > > There has been a lot of security analysis on this > issue, the only > > security issue that has been raised is that of preventing > an insertion > > attack, a risk that is not relevant to a domain where > anyone can buy a > > domain. > > There's also the deletion ("spoof a zone out of existence") attack. > You can still replace the NS and make the zone unreachable, but you > could have done that just by stomping on the whole answer; DNSSEC > doesn't guarantee that packets get through. Without opt-in, assuming > you get an answer at all, you at least get a verifiable statement of > existence -- you know that such a delegation exists and that something > is preventing you from reaching it. That could trigger an IDS's alarm > bells, or it could tell you that you need to try harder to get the > answer. > > Assuming that methods for "trying harder" are developed, you probably > don't want clients trying them all the time -- they'll probably be > bandwidth intensive or they'll try to get around caches and end up > pounding authoritative servers into the ground. As an operator of > authoritative servers, your employer may be interested in minimizing > those events. One way of doing that is to provide a very clear > trigger for when it's required. You don't want all NXDOMAINS to turn > into a "flail on the auth servers" fest. > > -- 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 Thu May 1 13:10:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23111 for ; Thu, 1 May 2003 13:10:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BH39-000GQs-00 for namedroppers-data@psg.com; Thu, 01 May 2003 16:36:47 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19BH2s-000GQ0-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 16:36:30 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h41GGKU25315; Thu, 1 May 2003 09:16:20 -0700 Date: Thu, 1 May 2003 09:16:20 -0700 (PDT) From: Bernard Aboba To: Christian Huitema cc: itojun@iijlab.net, namedroppers@ops.ietf.org Subject: RE: Minutes of the 4/30/03 LLMNR Conference Call In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > with TCP query/response it is difficult to enforce TTL=1. > > do you drop TCP connection if one of packets within a TCP stream > > has non-1 TTL? The strawman draft -18 doesn't mandate any TTL checks: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-18.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 1 17:13:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11321 for ; Thu, 1 May 2003 17:12:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BLI9-0001Im-00 for namedroppers-data@psg.com; Thu, 01 May 2003 21:08:33 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19BLHr-0001Hw-00; Thu, 01 May 2003 21:08:15 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19BLHq-000B5m-2g; Thu, 01 May 2003 14:08:14 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 1 May 2003 14:08:13 -0700 To: Mika Liljeberg Cc: llmnr-design@internaut.com, namedroppers@ops.ietf.org Subject: Re: [llmnr-design] Strawman -18 draft References: <1051820922.26422.381.camel@devil> Message-Id: X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_10,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit in dns, it is legal for a client to send a tcp request without first having sent udp and received a tc bit. -- 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 May 1 17:31:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12195 for ; Thu, 1 May 2003 17:31:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BKeB-000M73-00 for namedroppers-data@psg.com; Thu, 01 May 2003 20:27:15 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 19BKdT-000Lw8-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 20:26:31 +0000 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h41KShnZ028655; Thu, 1 May 2003 23:28:44 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h41KShJ7028654; Thu, 1 May 2003 23:28:43 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [llmnr-design] Strawman -18 draft From: Mika Liljeberg To: llmnr-design@internaut.com Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1051820922.26422.381.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 01 May 2003 23:28:42 +0300 X-Spam-Status: No, hits=-39.4 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-05-01 at 16:19, Bernard Aboba wrote: > In order to resolve Issues 33-36, I've put together a strawman -18 draft, > including the potential fixes described in the minutes of the last > conference call. Comments welcome: > > http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-18.txt I'm almost sorry I brought up issue 33. :-) I wanted to make things simpler and they got more complex. Anyway, a few comments follow. Sections 2.1 and 2.2 do not explicitly state what to do with received unicast UDP query/response packets. Presumably they should be discarded (except for the special optional empty response with TC bit set, described in section 2.3)? This implies destination address checks for all received UDP packets. Section 2.2: "A responder listens on UDP port TBD on the link-scope multicast address(es) and on ports TBD on the unicast address(es) that could be set as the source address(es) when the responder responds to the LLMNR query. A responder MUST listen on both the UDP and TCP ports TBD unless it is impossible for a response to be sent with the TC bit set, in which case the responder MAY listen only on UDP port TBD. The host configured as a responder MUST act as a sender to verify the uniqueness of names as described in Section 4." Only one port number is needed, since UDP and TCP can share the same port number. Section 2.3: "In composing a response to a unicast LLMNR query, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to 1. Since unicast LLMNR queries and responses to those queries MUST be sent using TCP, spoofing a response would require hijacking a TCP connection on the local link." With the TCP listener, the TTL=1 setting should be set on the listen socket so that the SYN-ACK packets will have TTL=1. This prevents an incoming connection from being formed if someone tries to connect from off-link, since the sender will not receive any SYN-ACK packets. "Senders MUST support sending TCP queries, and Responders MUST listen on TCP port TBD, unless it is impossible for a response to the supported queries to be sent with the TC bit set." Does this mean that TCP is optional in both sender and responder or just responder? The wording is not quite clear on this. Note that, since TCP is optional in the responder, it is more efficient to just send all queries with multicast in the first place, rather than try TCP first and fall back on multicast if responder does not support TCP. (No, I don't propose to make TCP mandatory. Simple devices might not implement the TCP protocol at all.) "If an ICMP "Time Exceeded" message is received in response to a unicast 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)." Careful here. The UDP sender should verify that the ICMP error payload contains a valid DNS query packet, which matches a query that is currently in progress. Otherwise this can be turned into a DoS attack. I'm not sure if the last bit is worth mentioning but it's good to realize that if the ICMP error response doesn't have enough payload to identify the query the sender will have to fall back on a timeout. The same thing will happen with TCP implementations that follow RFC1122 to the letter and ignore the "ICMP Time Exceeded" error also during the TCP connect phase, rather than aborting the connection immediately. MikaL -- 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 May 1 17:45:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13004 for ; Thu, 1 May 2003 17:45:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BLn9-0004rR-00 for namedroppers-data@psg.com; Thu, 01 May 2003 21:40:35 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 19BLn5-0004qy-00; Thu, 01 May 2003 21:40:32 +0000 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h41LgjnZ029032; Fri, 2 May 2003 00:42:45 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h41Lgi56029031; Fri, 2 May 2003 00:42:44 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [llmnr-design] Strawman -18 draft From: Mika Liljeberg To: Randy Bush Cc: llmnr-design@internaut.com, namedroppers@ops.ietf.org In-Reply-To: References: <1051820922.26422.381.camel@devil> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1051825364.26425.383.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 May 2003 00:42:44 +0300 X-Spam-Status: No, hits=-40.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy, On Fri, 2003-05-02 at 00:08, Randy Bush wrote: > in dns, it is legal for a client to send a tcp request without first > having sent udp and received a tc bit. I'm not sure I understand your point. Is that a response to one of my comments? MikaL -- 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 May 1 18:06:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14575 for ; Thu, 1 May 2003 18:06:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BM7I-00081P-00 for namedroppers-data@psg.com; Thu, 01 May 2003 22:01:24 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 19BM7E-00081C-00; Thu, 01 May 2003 22:01:21 +0000 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h41M3XnZ029149; Fri, 2 May 2003 01:03:33 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h41M3Vlj029148; Fri, 2 May 2003 01:03:31 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [llmnr-design] Strawman -18 draft From: Mika Liljeberg To: Randy Bush Cc: llmnr-design@internaut.com, namedroppers@ops.ietf.org In-Reply-To: References: <1051820922.26422.381.camel@devil> <1051825364.26425.383.camel@devil> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1051826611.26426.389.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 May 2003 01:03:31 +0300 X-Spam-Status: No, hits=-40.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-05-02 at 00:46, Randy Bush wrote: > >> in dns, it is legal for a client to send a tcp request without first > >> having sent udp and received a tc bit. > > > > I'm not sure I understand your point. Is that a response to one of my > > comments? > > > >>> Section 2.2: > >>> > >>> "A responder listens on UDP port TBD on the link-scope multicast > >>> address(es) and on ports TBD on the unicast address(es) that > >>> could be set as the source address(es) when the responder > >>> responds to the LLMNR query. A responder MUST listen on both > >>> the UDP and TCP ports TBD unless it is impossible for a response > >>> to be sent with the TC bit set, in which case the responder MAY > >>> listen only on UDP port TBD. The host configured as a responder > >>> MUST act as a sender to verify the uniqueness of names as > >>> described in Section 4." > > note that this would allow a server to be udp only Sure. That was a direct quote from draft-18. I still don't know which part of my comments you're responding to, though. :-) MikaL -- 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 May 1 18:15:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15682 for ; Thu, 1 May 2003 18:15:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BLt6-0005uB-00 for namedroppers-data@psg.com; Thu, 01 May 2003 21:46:44 +0000 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19BLt2-0005tp-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 21:46:40 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19BLsz-000Gqo-0m; Thu, 01 May 2003 14:46:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 1 May 2003 14:46:36 -0700 To: Mika Liljeberg Cc: llmnr-design@internaut.com, namedroppers@ops.ietf.org Subject: Re: [llmnr-design] Strawman -18 draft References: <1051820922.26422.381.camel@devil> <1051825364.26425.383.camel@devil> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> in dns, it is legal for a client to send a tcp request without first >> having sent udp and received a tc bit. > > I'm not sure I understand your point. Is that a response to one of my > comments? > >>> Section 2.2: >>> >>> "A responder listens on UDP port TBD on the link-scope multicast >>> address(es) and on ports TBD on the unicast address(es) that >>> could be set as the source address(es) when the responder >>> responds to the LLMNR query. A responder MUST listen on both >>> the UDP and TCP ports TBD unless it is impossible for a response >>> to be sent with the TC bit set, in which case the responder MAY >>> listen only on UDP port TBD. The host configured as a responder >>> MUST act as a sender to verify the uniqueness of names as >>> described in Section 4." note that this would allow a server to be udp only randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 1 18:31:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16646 for ; Thu, 1 May 2003 18:31:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BMGO-0009Il-00 for namedroppers-data@psg.com; Thu, 01 May 2003 22:10:48 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19BMGK-0009HC-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 22:10:44 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h41M8tab059464; Fri, 2 May 2003 08:08:55 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h41M8t1G008267; Fri, 2 May 2003 08:08:55 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305012208.h41M8t1G008267@drugs.dv.isc.org> To: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Cc: Erik Nordmark , namedroppers@ops.ietf.org, iesg-secretary@ietf.org From: Mark.Andrews@isc.org Subject: Re: Advance: Opcode Discover In-reply-to: Your message of "Thu, 01 May 2003 10:23:49 -0400." <5.1.1.6.2.20030501101308.022c0e90@localhost> Date: Fri, 02 May 2003 08:08:55 +1000 X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Erik > > DNSEXT recommends the advance following document to experimental status: > www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-01.txt > > Background: > We had a last call concluded on this in November, the last call > required some minor changes in the document. > The editors concluded the edits in December. > Subsequently one of the editors sent in a request to have his name taken > off the draft, chairs waited for this to happen in a new version. > This particular editor has rescinded the request. Thus the document can > now be advanced. > > Olafur & Randy > > > From: Ólafur Gudmundsson/DNSEXT co-chair > > Date: Wed, 13 Nov 2002 12:33:40 -0500 > > Subject: DNSEXT WGLC Summary: Opcode-discover-00 > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > > Sender: owner-namedroppers@ops.ietf.org > Precedence: bulk > X-UIDL: [0'"!C\S!!Dca!!(h[!! > > > > > > This working group last call has concluded. > > This work meets the technical criteria to be to be published as > EXPERIMENTAL. > > > > Authors are requested to make the following changes before the document > > is advanced to the IESG. > > > > 0. Number all sections that have titles. > > 1. In the last paragraph before IANA consideration: > > Add a comment that a responder to DISCOVER, in some cases is not a > > traditional DNS server, it could be a special purpose software. > > 2. References section needs to be broken into two "Normative References" > > and "Informational References", please fill out references fully. > > > > Olafur > > > > > >This starts a 2 week last call for this document, the document is > >slated to be published as EXPERIMENTAL. > > > >http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-00.txt > > > >This document specifies a new opcode that is used to discover DNS servers > >within the multicast scope of the address sent to. > > > >The authors main focus is to get a IANA assigned opcode for experimentation, > >does this document provide enough technical details for the framework to be > >experimented with. > > > >This working group last call completes on August 30'th 2002. > > > > Olafur > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: Paul ask me to look at implementing this and I found that it was unimplementable as specified. e.g. DISCOVER works like QUERY except: ... 3. if QDCOUNT==0 then only servers willing to do recursion should answer. Other servers must silently discard the DISCOVER request. Well QDCOUNT==0 results in FORMERR for QUERY. I don't think we want FORMERR returned in this case. e.g. "Compute the zone name of the enclosing in-addr.arpa, ip6.int, or ip6.arpa domain." How do you determine this? Are you expected to compute the full reverse name then remove labels after each probe fails. Mark -- Mark Andrews, Internet Software Consortium 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 Thu May 1 21:27:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21328 for ; Thu, 1 May 2003 21:27:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BPEe-00072C-00 for namedroppers-data@psg.com; Fri, 02 May 2003 01:21:12 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 19BPEb-00071l-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 01:21:09 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3601793; Fri, 2 May 2003 10:21:05 +0900 (JST) To: Bernard Aboba Cc: Christian Huitema , namedroppers@ops.ietf.org In-reply-to: aboba's message of Thu, 01 May 2003 09:16:20 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Minutes of the 4/30/03 LLMNR Conference Call From: itojun@iijlab.net Date: Fri, 02 May 2003 10:21:05 +0900 Message-Id: <20030502012105.3601793@coconut.itojun.org> X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> > with TCP query/response it is difficult to enforce TTL=1. >> > do you drop TCP connection if one of packets within a TCP stream >> > has non-1 TTL? >The strawman draft -18 doesn't mandate any TTL checks: >http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-18.txt >2.3. Unicast queries and responses > >Unicast LLMNR queries SHOULD be sent using TCP, with the TTL (IPv4) or >Hop Limit (IPv6) fields set to one (1). Responses to TCP unicast LLMNR ... i see, it talks about sender rule, but not receiver rule. itojun -- 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 May 2 00:38:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24426 for ; Fri, 2 May 2003 00:38:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BSDR-000Hyk-00 for namedroppers-data@psg.com; Fri, 02 May 2003 04:32:09 +0000 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 19BSDM-000HyM-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 04:32:04 +0000 Received: (qmail 51063 invoked by uid 1016); 2 May 2003 04:32:34 -0000 Date: 2 May 2003 04:32:34 -0000 Message-ID: <20030502043234.51062.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: llmnr-design@internaut.com, namedroppers@ops.ietf.org Subject: Re: [llmnr-design] Strawman -18 draft References: <1051820922.26422.381.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy Bush writes: > in dns, it is legal for a client to send a tcp request without first > having sent udp and received a tc bit. False. Your suggested behavior violates the following crystal-clear requirement in RFC 1123, section 6.1.3.2: ``A DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first.'' TCP is for truncated packets and zone transfers. ---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 May 2 00:39:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24455 for ; Fri, 2 May 2003 00:39:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BSES-000I3Y-00 for namedroppers-data@psg.com; Fri, 02 May 2003 04:33:12 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19BSEP-000I2u-00; Fri, 02 May 2003 04:33:09 +0000 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h424WtfP010779; Fri, 2 May 2003 00:32:55 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h424Wsd5018366; Fri, 2 May 2003 00:32:54 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h424WpU8014694; Fri, 2 May 2003 00:32:51 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id AAA23305; Fri, 2 May 2003 00:32:51 -0400 (EDT) To: Mika Liljeberg Cc: Randy Bush , llmnr-design@internaut.com, namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: [llmnr-design] Strawman -18 draft References: <1051820922.26422.381.camel@devil> <1051825364.26425.383.camel@devil> <1051826611.26426.389.camel@devil> Date: 02 May 2003 00:32:50 -0400 In-Reply-To: <1051826611.26426.389.camel@devil> Message-ID: Lines: 46 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-35.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mika Liljeberg writes: > On Fri, 2003-05-02 at 00:46, Randy Bush wrote: > > >> in dns, it is legal for a client to send a tcp request without first > > >> having sent udp and received a tc bit. > > > > > > I'm not sure I understand your point. Is that a response to one of my > > > comments? > > > > > >>> Section 2.2: > > >>> > > >>> "A responder listens on UDP port TBD on the link-scope multicast > > >>> address(es) and on ports TBD on the unicast address(es) that > > >>> could be set as the source address(es) when the responder > > >>> responds to the LLMNR query. A responder MUST listen on both > > >>> the UDP and TCP ports TBD unless it is impossible for a response > > >>> to be sent with the TC bit set, in which case the responder MAY > > >>> listen only on UDP port TBD. The host configured as a responder > > >>> MUST act as a sender to verify the uniqueness of names as > > >>> described in Section 4." > > > > note that this would allow a server to be udp only > > Sure. That was a direct quote from draft-18. I still don't know which > part of my comments you're responding to, though. :-) I suspect the comment is about the part that states "unless it is impossible for a response to be sent with the TC bit set, in which case the responder MAY listen only on UDP port TBD." My reading of this (which concurs with Randy's) is that it makes it possible to create a server that ONLY listens on UDP, which would violate the existing dns spec which allows a client to make its initial request using TCP (even if the response would not have the TC bit set). In this particular case, the client would make a TCP request, and TCP would fail -- what does/should it do? IMHO you should remove the text I quoted above. > MikaL -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri May 2 02:32:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07605 for ; Fri, 2 May 2003 02:32:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BU2V-0001Qe-00 for namedroppers-data@psg.com; Fri, 02 May 2003 06:28:59 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19BU2Q-0001QM-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 06:28:54 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4268kY06513 for ; Thu, 1 May 2003 23:08:46 -0700 Date: Thu, 1 May 2003 23:08:45 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 34 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The proposed resolution to Issue 34 (see http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue%2034 for details) is to replace Section 2.3 and 2.6 with the following: "2.3. Unicast queries and responses Unicast queries SHOULD be sent when: a. A sender repeats a query after it received a response with the TC bit set to the previous LLMNR multicast query, or b. The sender's LLMNR cache contains an NS resource record that enables the sender to send a query directly to the hosts authoritative for the name in the query, or c. The sender queries for a PTR RR. If a TC (truncation) bit is set in the response, then the sender MAY use the response if it contains all necessary information, or the sender MAY discard the response and resend the query over TCP using the unicast address of the responder. The RA (Recursion Available) bit in the header of the response MUST NOT be set. If the RA bit is set in the response header, the sender MUST ignore the RA bit. Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP unicast LLMNR queries MUST be sent using TCP, using the same connection as the query. If the sender of a TCP query receives a response not using TCP, the response MUST be silently discarded. Unicast UDP queries MAY be responded to with an empty answer section and the TC bit set, so as to require the sender to resend the query using TCP. Senders MUST support sending TCP queries, and Responders MUST support listening for TCP queries. 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. If an ICMP "Time Exceeded" message is received in response to a unicast UDP query, or 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). The UDP sender receiving an ICMP "Time Exceeded" message SHOULD verify that the ICMP error payload contains a valid LLMNR query packet, which matches a query that is currently in progress, so as to guard against a potential Denial of Service (DoS) attack. If a match cannot be made, then the sender relies on the retransmission and timeout behavior described in Section 2.6." 2.6. Retransmissions In order to avoid synchronization, LLMNR queries and responses are delayed by a time uniformly distributed between 0 and 200 ms. If an LLMNR query sent over UDP is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) based on the last response received, on a per-interface basis, using the algorithms described in [RFC2988], with a minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer." -- 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 May 2 10:50:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16797 for ; Fri, 2 May 2003 10:50:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bbl0-000GOb-00 for namedroppers-data@psg.com; Fri, 02 May 2003 14:43:26 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19Bbkx-000GNA-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 14:43:23 +0000 Received: from lapdancer (gorilla.antd.nist.gov [129.6.55.20]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h42Egxbd000788 for ; Fri, 2 May 2003 10:42:59 -0400 (EDT) Message-ID: <000a01c310b8$b6c50d20$14370681@lapdancer> From: "Scott Rose" To: Subject: Wrapup: DNSSECbis Q-8: Non-zone KEY RR at the apex. Date: Fri, 2 May 2003 10:40:01 -0400 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 5.50.4920.2300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Considering I have not heard any negative replies to this message, I assume there is consensus to change the wording to disallow non-zone KEY RRs at the apex. Unless some late comments come in. Scott > Q: Should a secure (signed) zone be allowed to have non-zone KEY RRs in the > apex? > > Discussion: > > "Section 2.1 of draft-ietf-dnsext-dnssec-protocol-01 > > To sign a zone, the zone's administrator generates one or more > public/private key pairs and uses the private key(s) to sign authoritative > RRsets in the zone. For each private key used to create SIG RRs, there > SHOULD be a corresponding KEY RR stored at the zone apex. All KEY RRs at the > zone apex MUST be zone keys. (A zone key KEY RR has the Zone Key bit of the > Flags RDATA field set to one. See Section 2.1.1 of [10].) Zone key KEY RRs > MUST appear only at the > zone apex." > > > > "Other public keys associated with other DNS operations can be stored in KEY > RRs that are not marked as zone keys. Non-zone key KEY RRs MUST NOT appear > at delegation names. Non-zone key KEY RRs also SHOULD NOT appear at the zone > apex, because large KEY RRsets add processing time at resolvers. Non-zone > key KEY RRs MAY appear at any other name in the zone." > > /end > > The first paragraph quoted above states that only DNSSEC zone KEY RRs can > appear at the > zone apex. The second quoted paragraph, states that non-zone KEYs SHOULD > NOT appear. > > It is possible that an admin may wish to put a non-zone key (e.g. SIG(0) > KEY) at the apex, which would be unwise, and result in a larger apex KEY > RRset. However, there are better ways to store such KEY RRs. > > Should the SHOULD NOT in the above (third) paragraph be changed to "Non-zone > key KEY RRs also MUST NOT appear at the zone apex, ..." ? > > Scott > > -- 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 May 2 11:56:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18639 for ; Fri, 2 May 2003 11:56:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bckh-0001mp-00 for namedroppers-data@psg.com; Fri, 02 May 2003 15:47:11 +0000 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 19Bckc-0001mS-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 15:47:06 +0000 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h42FkmbU012897 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 2 May 2003 17:46:54 +0200 To: "Scott Rose" Cc: Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. References: <000701c30daf$77c171b0$14370681@lapdancer> From: Simon Josefsson X-Payment: hashcash 1.2 0:030502:scottr@antd.nist.gov:6d2cf6ac71896541 X-Hashcash: 0:030502:scottr@antd.nist.gov:6d2cf6ac71896541 X-Payment: hashcash 1.2 0:030502:namedroppers@ops.ietf.org:ce6c802ebbadb5bc X-Hashcash: 0:030502:namedroppers@ops.ietf.org:ce6c802ebbadb5bc Date: Fri, 02 May 2003 17:46:48 +0200 In-Reply-To: <000701c30daf$77c171b0$14370681@lapdancer> (Scott Rose's message of "Mon, 28 Apr 2003 13:56:17 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" writes: > Q: Should a secure (signed) zone be allowed to have non-zone KEY RRs in the > apex? Yes. The only disadvantage presented as a consequence of putting non-zone KEY RRs at the apex is that such usage may add processing time to resolvers. First, I question the amount of processing time wasted. We are talking about one IF statement, that checks if the Zone Key Flag is set, for each KEY RR. Secondly, if a zone administrator see a benefit of putting a non-zone KEY RR at the apex, after having considered that it make resolvers slower, she should be allowed to do so. RFC 2535 do not include the SHOULD NOT you are referring to, as far as I can tell. When was it discussed on this list to introduce it? > It is possible that an admin may wish to put a non-zone key (e.g. SIG(0) > KEY) at the apex, which would be unwise, and result in a larger apex KEY > RRset. However, there are better ways to store such KEY RRs. Such as? -- 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 May 2 13:05:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21132 for ; Fri, 2 May 2003 13:05:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BdmT-000Dse-00 for namedroppers-data@psg.com; Fri, 02 May 2003 16:53:05 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19BdmP-000DsM-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 16:53:01 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 69406361; Fri, 2 May 2003 12:52:58 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id A8B72353; Fri, 2 May 2003 12:52:57 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 222666; Fri, 02 May 2003 12:42:26 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <000a01c310b8$b6c50d20$14370681@lapdancer> References: <000a01c310b8$b6c50d20$14370681@lapdancer> Date: Fri, 2 May 2003 12:53:09 -0400 To: "Scott Rose" From: Edward Lewis Subject: Re: Wrapup: DNSSECbis Q-8: Non-zone KEY RR at the apex. Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Well, since you are prodding for comments... First question, what non-zone keys can sit at the apex? Answer: SIG(0) keys, well, that's all I can think of. If I'm missing something, then I'm missing something. Second question, is there a reason to have a SIG(0) at the apex? Answer: Perhaps... ...for zone transfer. However, for zone transfers, SIG(0) authentication has not been implemented and looks like it maybe next to impossible. (TSIG is configured into the server, so the secret is there, the SIG(0) public key might be in the zone being transferred, a catch-22.) ...if there is a host who's name is the same as the apex. This could happen, a lot of web sites wanted to drop "www." from the "usual" domain name convention. I'm not sure how useful SIG(0) would be here, I don't have the right experience. ...if you want to dynamically update the apex with a policy requiring that the name to be updated can only be changed with a same-named key. I'd rather use an administrative key for the entire zone and not have anything special at the apex - but that's a personal preference, not a reason to legislate away the possibility. So, when it comes to writing the spec, I might lean to the less restrictive "SHOULD NOT" than a "MUST NOT". It seems to me that maybe there is a clear rationale for allowing SIG(0) at the apex, but no real need to exclude or include it. Third question, did I miss something, is there a reason to bar SIG(0) use at the apex I haven't seen? At 10:40 -0400 5/2/03, Scott Rose wrote: >Considering I have not heard any negative replies to this message, I assume >there is consensus to change the wording to disallow non-zone KEY RRs at the >apex. > >Unless some late comments come in. >Scott > >> Q: Should a secure (signed) zone be allowed to have non-zone KEY RRs in >the >> apex? >> >> Discussion: >> >> "Section 2.1 of draft-ietf-dnsext-dnssec-protocol-01 >> >> To sign a zone, the zone's administrator generates one or more >> public/private key pairs and uses the private key(s) to sign authoritative >> RRsets in the zone. For each private key used to create SIG RRs, there >> SHOULD be a corresponding KEY RR stored at the zone apex. All KEY RRs at >the >> zone apex MUST be zone keys. (A zone key KEY RR has the Zone Key bit of >the >> Flags RDATA field set to one. See Section 2.1.1 of [10].) Zone key KEY RRs >> MUST appear only at the >> zone apex." >> >> >> >> "Other public keys associated with other DNS operations can be stored in >KEY >> RRs that are not marked as zone keys. Non-zone key KEY RRs MUST NOT appear >> at delegation names. Non-zone key KEY RRs also SHOULD NOT appear at the >zone >> apex, because large KEY RRsets add processing time at resolvers. Non-zone >> key KEY RRs MAY appear at any other name in the zone." >> >> /end >> >> The first paragraph quoted above states that only DNSSEC zone KEY RRs can >> appear at the >> zone apex. The second quoted paragraph, states that non-zone KEYs SHOULD >> NOT appear. >> >> It is possible that an admin may wish to put a non-zone key (e.g. SIG(0) >> KEY) at the apex, which would be unwise, and result in a larger apex KEY >> RRset. However, there are better ways to store such KEY RRs. >> >> Should the SHOULD NOT in the above (third) paragraph be changed to >"Non-zone >> key KEY RRs also MUST NOT appear at the zone apex, ..." ? >> >> Scott >> >> > > >-- >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-703-227-9854 ARIN Research Engineer It's true, my last college class really was "Introduction to Ada." -- 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 May 2 13:55:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23072 for ; Fri, 2 May 2003 13:55:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Beg3-000OoC-00 for namedroppers-data@psg.com; Fri, 02 May 2003 17:50:31 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19Befx-000Onm-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 17:50:26 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h42HoIbd024591 for ; Fri, 2 May 2003 13:50:18 -0400 (EDT) Message-ID: <004b01c310d3$4bfc0fa0$b9370681@barnacle> From: "Scott Rose" To: References: <000701c30daf$77c171b0$14370681@lapdancer> Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. Date: Fri, 2 May 2003 13:50:19 -0400 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.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The restriction would primarily be to reduce the KEY RRset size. Since SIG(0) KEYs are usually for a host/entity it would seem that having an update/zone transfer key with the same name as the zone might not be a good idea. Having another name "primary.zone" or "updatekey.zone" seems more logical. While most implementations would see the flags, a human admin may make mistakes if they manually edit a zone file. RFC2535 does not place any restrictions on KEY RRs at all. Updating RFCs (restrict KEY, etc.) have. So it was brought up in the DNSSECbis writing that some distinction should be made one way or the other. Either disallow non-zone KEY RRs or allow them. Scott ----- Original Message ----- From: "Simon Josefsson" To: "Scott Rose" Cc: Sent: Friday, May 02, 2003 11:46 AM Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. > "Scott Rose" writes: > > > Q: Should a secure (signed) zone be allowed to have non-zone KEY RRs in the > > apex? > > Yes. > > The only disadvantage presented as a consequence of putting non-zone > KEY RRs at the apex is that such usage may add processing time to > resolvers. > > First, I question the amount of processing time wasted. We are > talking about one IF statement, that checks if the Zone Key Flag is > set, for each KEY RR. > > Secondly, if a zone administrator see a benefit of putting a non-zone > KEY RR at the apex, after having considered that it make resolvers > slower, she should be allowed to do so. > > RFC 2535 do not include the SHOULD NOT you are referring to, as far as > I can tell. When was it discussed on this list to introduce it? > > > It is possible that an admin may wish to put a non-zone key (e.g. SIG(0) > > KEY) at the apex, which would be unwise, and result in a larger apex KEY > > RRset. However, there are better ways to store such KEY RRs. > > Such as? -- 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 May 2 14:22:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24172 for ; Fri, 2 May 2003 14:22:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bf8Q-0004Wu-00 for namedroppers-data@psg.com; Fri, 02 May 2003 18:19:50 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19Bf8N-0004Wi-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 18:19:48 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23848; Fri, 2 May 2003 14:16:38 -0400 (EDT) Message-Id: <200305021816.OAA23848@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-18.txt Date: Fri, 02 May 2003 14:16:37 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-18.txt Pages : 21 Date : 2003-5-2 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name Service (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-18.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mdns-18.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-mdns-18.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: <2003-5-2142448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-2142448.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 May 2 14:48:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25292 for ; Fri, 2 May 2003 14:48:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BfRz-0008SQ-00 for namedroppers-data@psg.com; Fri, 02 May 2003 18:40:03 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19BfRv-0008Rl-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 18:40:00 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 5585343D; Fri, 2 May 2003 14:39:59 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id DFCF53C9; Fri, 2 May 2003 14:39:58 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 222777; Fri, 02 May 2003 14:29:28 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <004b01c310d3$4bfc0fa0$b9370681@barnacle> References: <000701c30daf$77c171b0$14370681@lapdancer> <004b01c310d3$4bfc0fa0$b9370681@barnacle> Date: Fri, 2 May 2003 14:40:13 -0400 To: "Scott Rose" From: Edward Lewis Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:50 -0400 5/2/03, Scott Rose wrote: >The restriction would primarily be to reduce the KEY RRset size. I can understand that desire, but can the problem of KEY RRset size be quantified? I want to be able to compare the cost of the extra size versus the cost of the lost flexibility. Not that all lost functionality is bad, but it's bad if it is lost for little or no gain. If we are going to specify away some otherwise legal configurations, there should be a rock-solid rationale in the accompanying text. ...Of course, I'm picking on perhaps just one aspect of the question here - whether or not SIG(0) KEY RR's are allowed at the apex. There may be others I don't see. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer It's true, my last college class really was "Introduction to Ada." -- 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 May 2 15:01:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26204 for ; Fri, 2 May 2003 15:01:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bfgp-000Bci-00 for namedroppers-data@psg.com; Fri, 02 May 2003 18:55:23 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19Bfgl-000BbK-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 18:55:19 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h42ItDbd024844 for ; Fri, 2 May 2003 14:55:13 -0400 (EDT) Message-ID: <000701c310dc$5d44def0$b9370681@barnacle> From: "Scott Rose" To: References: <000701c30daf$77c171b0$14370681@lapdancer> <004b01c310d3$4bfc0fa0$b9370681@barnacle> Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. Date: Fri, 2 May 2003 14:55:13 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit That's pretty much it. No one has quantified it fully. Large KEY RR set sizes is mostly FUD unless you're talking VERY large keys. Even then, the problem was with DSA more than RSA. Transaction authentication keys would be the only class of keys restricted by it. Unless some new use of the KEY RR for DNSSEC is adopted. Zone and KEY signing keys are still allowed. Scott ----- Original Message ----- From: "Edward Lewis" To: "Scott Rose" Cc: Sent: Friday, May 02, 2003 2:40 PM Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. > At 13:50 -0400 5/2/03, Scott Rose wrote: > >The restriction would primarily be to reduce the KEY RRset size. > > I can understand that desire, but can the problem of KEY RRset size > be quantified? I want to be able to compare the cost of the extra > size versus the cost of the lost flexibility. Not that all lost > functionality is bad, but it's bad if it is lost for little or no > gain. > > If we are going to specify away some otherwise legal configurations, > there should be a rock-solid rationale in the accompanying text. > > ...Of course, I'm picking on perhaps just one aspect of the question > here - whether or not SIG(0) KEY RR's are allowed at the apex. There > may be others I don't see. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > It's true, my last college class really was "Introduction to Ada." -- 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 May 2 15:18:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28048 for ; Fri, 2 May 2003 15:18:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bg0T-000FqZ-00 for namedroppers-data@psg.com; Fri, 02 May 2003 19:15:41 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19Bg0Q-000FqI-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 19:15:38 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 6D2CC37C; Fri, 2 May 2003 15:15:38 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 07A0A4C2; Fri, 2 May 2003 15:15:38 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 222818; Fri, 02 May 2003 15:05:06 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <000701c310dc$5d44def0$b9370681@barnacle> References: <000701c30daf$77c171b0$14370681@lapdancer> <004b01c310d3$4bfc0fa0$b9370681@barnacle> <000701c310dc$5d44def0$b9370681@barnacle> Date: Fri, 2 May 2003 15:15:52 -0400 To: "Scott Rose" From: Edward Lewis Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm against placing any restrictions or rules to counter FUD. I'd rather let the suspected "badness" happen and then assess whether it needs to be corrected. I'm not saying that there should be no restrictions - just no restrictions to counter FUD. At 14:55 -0400 5/2/03, Scott Rose wrote: >That's pretty much it. No one has quantified it fully. Large KEY RR set >sizes is mostly FUD unless you're talking VERY large keys. Even then, the >problem was with DSA more than RSA. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer It's true, my last college class really was "Introduction to Ada." -- 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 May 2 15:18:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28078 for ; Fri, 2 May 2003 15:18:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bg0A-000Fgh-00 for namedroppers-data@psg.com; Fri, 02 May 2003 19:15:22 +0000 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 19Bg07-000FfD-00 for namedroppers@ops.ietf.org; Fri, 02 May 2003 19:15:19 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA24891 for ; Fri, 2 May 2003 13:15:18 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h42JFFL11171 for ; Fri, 2 May 2003 21:15:15 +0200 (MEST) Date: Fri, 2 May 2003 21:14:51 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: opt-in and decision making To: namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,OPT_IN version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Folks on the mailing list have started to wonder what happened with the opt-in WG last call, and rightly so. The reason for the delay is that the chairs wanted to check with the ADs to make sure they were not misreading things and that they are following the documented processes etc - especially given that opt-in has been quite contentious in the WG. Some vacations and travel of the chairs and ADs have drawn out these discussions. In highsight I should have let the WG know that this was going on. Also in hindsight, I think the debate around opt-in has been unnessarily polarized. I think there have been actions increasing polarization as well as trying to decrease polarization on both sides of the issue and I sure hope we all (in the WG and in the larger sense the IETF) can can do a better job at avoiding polarization in the future. After all, we all would like to see DNSSEC deployed thus at that level the WG has a shared goal; it is when we drill down that we end up with different views. Looking at the range of issues around opt-in it seems to me personally that the factors on the table are very hard to compare; it seems to be a comparison of very different types of fruit (complexity vs. flexibility, etc) combined with honest attempts to guess the future, that need to be taking into account to come to a good decision. Thus I'm not surprised that people have weighed things differently in order to come up with a single, one-bit answer. And if you asked me for my personal opinion I would honestly suggesting tossing a coin even though that might seem irresponsible; I don't feel I personally have a mechanism to weigh the factors together to come up with a good answer. Perhaps that is because I don't have much experience in the evolution, implementation and deployment of DNS. But the WG needs to make a decision and per our processes it is up to the chairs to guage the consensus, or lack thereof, in the WG. Erik -- 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 May 2 21:38:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08829 for ; Fri, 2 May 2003 21:38:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Blql-0004nn-00 for namedroppers-data@psg.com; Sat, 03 May 2003 01:30:03 +0000 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 19Blqg-0004mw-00 for namedroppers@ops.ietf.org; Sat, 03 May 2003 01:29:59 +0000 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h42MsObU022778 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 3 May 2003 00:54:24 +0200 To: "Scott Rose" Cc: Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. References: <000701c30daf$77c171b0$14370681@lapdancer> <004b01c310d3$4bfc0fa0$b9370681@barnacle> From: Simon Josefsson X-Payment: hashcash 1.2 0:030502:scottr@nist.gov:0b44c532ddec9cab X-Hashcash: 0:030502:scottr@nist.gov:0b44c532ddec9cab X-Payment: hashcash 1.2 0:030502:namedroppers@ops.ietf.org:494665292a744d02 X-Hashcash: 0:030502:namedroppers@ops.ietf.org:494665292a744d02 Date: Sat, 03 May 2003 00:54:24 +0200 In-Reply-To: <004b01c310d3$4bfc0fa0$b9370681@barnacle> (Scott Rose's message of "Fri, 2 May 2003 13:50:19 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" writes: > The restriction would primarily be to reduce the KEY RRset size. The document says "add processing time at resolvers". Is the document incorrect? Is the reason the KEY RRset size now? If so, why forbid this scenario for an administrator that has considered the consequences? It is not like it destroys interoperability, or add any negative consequences for anyone. Resolvers doesn't have to implement anything extra to support it. It just works, but wastes a few bytes of bandwidth. Only the administrators using it will suffer. Those administrator can chose to not use it if they suffer too much. > Since SIG(0) KEYs are usually for a host/entity it would seem that > having an update/zone transfer key with the same name as the zone > might not be a good idea. Having another name "primary.zone" or > "updatekey.zone" seems more logical. Is there consensus about this? If so, explain the solution in the document, so people that were using valid RFC 2535 constructions can migrate to the new solution. Don't forget to discuss the migration issues. > While most implementations would see the flags, Any implementation that didn't would be insecure. > a human admin may make mistakes if they manually edit a zone file. Humans should use tools if they don't know what they are doing. A human admin may make mistake today, mistakes that have more severe consequences than forcing resolvers to execute an IF statement, that must be executed anyway for security reasons. > RFC2535 does not place any restrictions on KEY RRs at all. Updating RFCs > (restrict KEY, etc.) have. So it was brought up in the DNSSECbis writing > that some distinction should be made one way or the other. Either disallow > non-zone KEY RRs or allow them. I think they should be allowed. Non-zone KEY RR's should be allowed at delegation points too, which the current update says MUST NOT about, whereas RFC 2535 didn't, as far as I can tell. This also wasn't discussed on the list, also as far as I can tell. Please raise this an issue to the list or revert the modification, or point me to where this has also been discussed. Thanks. -- 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 May 2 22:58:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10173 for ; Fri, 2 May 2003 22:58:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BnA8-000Mvv-00 for namedroppers-data@psg.com; Sat, 03 May 2003 02:54:08 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19BnA5-000Mve-00 for namedroppers@ops.ietf.org; Sat, 03 May 2003 02:54:05 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 1D828362; Fri, 2 May 2003 22:54:05 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3F22034D; Fri, 2 May 2003 22:54:04 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 223177; Fri, 02 May 2003 22:43:31 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <000701c30daf$77c171b0$14370681@lapdancer> <004b01c310d3$4bfc0fa0$b9370681@barnacle> Date: Fri, 2 May 2003 22:53:56 -0400 To: Simon Josefsson From: Edward Lewis Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. Cc: "Scott Rose" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 0:54 +0200 5/3/03, Simon Josefsson wrote: >"Scott Rose" writes: > >> The restriction would primarily be to reduce the KEY RRset size. > >The document says "add processing time at resolvers". Is the document >incorrect? Is the reason the KEY RRset size now? > >If so, why forbid this scenario for an administrator that has >considered the consequences? Before we get caught in another contentiously toned thread, let's all just have a little understanding about the different perspectives that we have here. First, it is important to get any rationale for any restriction clearly documented, or we will wind up with perfectly understandable questions such as Simon's. It's not that I want to squelch Simon, but we should make as much as possible crystal clear. Second, the reason to forbid a "scenario for an administrator who has considered the consequences" is that at times, what is good locally is bad globally. E.g., allowing all users on the Internet to have portable addresses is good for them, but bad for the routing tables. Doing the reverse - relying solely on provider based addressing can optimize routing but has nasty consequences when a provider goes out of business. It's a valid question to ask - do SIG(0) KEYs have a negative impact? The cost of carrying them is not borne (just) by the administrator that adds them, if is borne by the intermediate caches, the router buffers, and the end resolvers that have to deal with them. I'm not saying that I'm for the restriction, but is perfectly acceptable to ask about it. >bandwidth. Only the administrators using it will suffer. Those >administrator can chose to not use it if they suffer too much. As I said before, I think that's untrue - the administrator is the one who suffers the least - if suffering means expending CPU cycles. >> Since SIG(0) KEYs are usually for a host/entity it would seem that >> having an update/zone transfer key with the same name as the zone >> might not be a good idea. Having another name "primary.zone" or >> "updatekey.zone" seems more logical. > >Is there consensus about this? No, but not every thing Scott says is intended as a consensus statement. We are all entitled to make statements - even statements of conjecture. As far as SIG(0) for zone transfers - I think that it is not promising at all - no matter what the key is called. I've thought about it, tried a few things, but never documented my failed attempts. With Scott's words, at least he out did me - getting it mentioned in the archives. >If so, explain the solution in the document, so people that were using >valid RFC 2535 constructions can migrate to the new solution. Don't >forget to discuss the migration issues. When folks can volunteer, this is done. Remember that all input is volunteered here. If you want more things to be said, make it known and better yet, help by contributing text. Believe me, as one who is dragging his sorry carcass around the globe attending workshops and trying to document as much as is possible, folks are trying to do just that. It's a lot of work. If only I could write more...I would. >Humans should use tools if they don't know what they are doing. This is always true. More tools are always helpful. >I think they should be allowed. > >Non-zone KEY RR's should be allowed at delegation points too, which >the current update says MUST NOT about, whereas RFC 2535 didn't, as >far as I can tell. This also wasn't discussed on the list, also as >far as I can tell. Please raise this an issue to the list or revert >the modification, or point me to where this has also been discussed. I'm inclined to agree with Simon, given the limited knowledge I have. (I.e., I haven't spent time studying the problem beyond the thread here.) "Point me to where" - I'd just send a link to your own message. The documents are available for comments, read them, comment. The editors have been begging for comments. Think of the situation the editors are in. They are trying to clarify a bunch of documents, starting with an original that was lacking in many areas. Since the original a lot of patchwork was done. In applying the patches, they've discovered holes and overlaps - should they just cut and paste or try to stitch them together? Assuming the latter, you're going to get things that slip in without an explicit adoption by the WG. Your chance to stop this is to make comments, as you have here, and call attention to issues. But keep in mind that this is all done by volunteers... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer It's true, my last college class really was "Introduction to Ada." -- 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 May 3 00:59:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11507 for ; Sat, 3 May 2003 00:59:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Bp2I-000N03-00 for namedroppers-data@psg.com; Sat, 03 May 2003 04:54:10 +0000 Received: from shell-ng.nominum.com ([81.200.64.181]) by psg.com with esmtp (Exim 3.36 #1) id 19Bp2E-000Mzd-00 for namedroppers@ops.ietf.org; Sat, 03 May 2003 04:54:06 +0000 Received: from STJOHNS-LAPTOP.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 199F45686F; Fri, 2 May 2003 21:54:05 -0700 (PDT) Message-Id: <5.1.0.14.2.20030503004008.00ac6748@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 03 May 2003 00:54:38 -0400 To: "Scott Rose" , From: Michael StJohns Subject: Re: Wrapup: DNSSECbis Q-8: Non-zone KEY RR at the apex. In-Reply-To: <000a01c310b8$b6c50d20$14370681@lapdancer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've read Ed et als comments on this so am up to date: Without making any comment on whether or not non-zone KEY RRs are useful/bad, if the restriction is adopted, it should probably be stated as a protocol restriction rather than a data content restriction. E.g. "A DNS server compliant with this specification MUST NOT serve a KEY RR which has the Zone Key bit set unless that KEY RR is at the zone apex. A DNS server MUST set the Zone Key bit for all KEY RRs which are at the zone apex." The proposed language depends on the operator doing the right thing, the above requires the server or protocol engine to do the right thing. Possibly the right thing to do is take the proposed language and put it into a document which describes a BCP for operating a secure DNS server rather than placing it in the protocol document. Mike At 10:40 AM 5/2/2003 -0400, Scott Rose wrote: >Considering I have not heard any negative replies to this message, I assume >there is consensus to change the wording to disallow non-zone KEY RRs at the >apex. > >Unless some late comments come in. >Scott > > > Q: Should a secure (signed) zone be allowed to have non-zone KEY RRs in >the > > apex? > > > > Discussion: > > > > "Section 2.1 of draft-ietf-dnsext-dnssec-protocol-01 > > > > To sign a zone, the zone's administrator generates one or more > > public/private key pairs and uses the private key(s) to sign authoritative > > RRsets in the zone. For each private key used to create SIG RRs, there > > SHOULD be a corresponding KEY RR stored at the zone apex. All KEY RRs at >the > > zone apex MUST be zone keys. (A zone key KEY RR has the Zone Key bit of >the > > Flags RDATA field set to one. See Section 2.1.1 of [10].) Zone key KEY RRs > > MUST appear only at the > > zone apex." > > > > > > > > "Other public keys associated with other DNS operations can be stored in >KEY > > RRs that are not marked as zone keys. Non-zone key KEY RRs MUST NOT appear > > at delegation names. Non-zone key KEY RRs also SHOULD NOT appear at the >zone > > apex, because large KEY RRsets add processing time at resolvers. Non-zone > > key KEY RRs MAY appear at any other name in the zone." > > > > /end > > > > The first paragraph quoted above states that only DNSSEC zone KEY RRs can > > appear at the > > zone apex. The second quoted paragraph, states that non-zone KEYs SHOULD > > NOT appear. > > > > It is possible that an admin may wish to put a non-zone key (e.g. SIG(0) > > KEY) at the apex, which would be unwise, and result in a larger apex KEY > > RRset. However, there are better ways to store such KEY RRs. > > > > Should the SHOULD NOT in the above (third) paragraph be changed to >"Non-zone > > key KEY RRs also MUST NOT appear at the zone apex, ..." ? > > > > Scott > > > > > > >-- >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 May 3 11:43:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02045 for ; Sat, 3 May 2003 11:43:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Byyl-000AS5-00 for namedroppers-data@psg.com; Sat, 03 May 2003 15:31:11 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19Byyj-000ARt-00 for namedroppers@ops.ietf.org; Sat, 03 May 2003 15:31:09 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 5E64B3C6; Sat, 3 May 2003 11:31:06 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id C446F3C2; Sat, 3 May 2003 11:31:05 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 223580; Sat, 03 May 2003 11:20:31 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20030503004008.00ac6748@localhost> References: <5.1.0.14.2.20030503004008.00ac6748@localhost> Date: Sat, 3 May 2003 11:30:55 -0400 To: Michael StJohns From: Edward Lewis Subject: Re: Wrapup: DNSSECbis Q-8: Non-zone KEY RR at the apex. Cc: "Scott Rose" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 0:54 -0400 5/3/03, Michael StJohns wrote: >Without making any comment on whether or not non-zone KEY RRs are useful/bad, >if the restriction is adopted, it should probably be stated as a protocol > restriction rather than a data content restriction. That's certainly true, we have to discipline ourselves into thinking in terms of the protocol, not what is held. >E.g. "A DNS server compliant with this specification MUST NOT serve a KEY RR >which has the Zone Key bit set unless that KEY RR is at the zone apex. A DNS >server MUST set the Zone Key bit for all KEY RRs which are at the zone apex." The first MUST (NOT) - I suppose that is true, but isn't related to the original question. I guess that there's no place for a zone key anywhere other than in the root. I.e., a validator must not make use of a zone key that is not owned by the apex of a zone. The second MUST - one important factor is that no DNS server is ever allowed to change any part of a zone, not even set a bit in the matter described. The place where the bits are set are in the key generator or what ever prepares the zone data for signing. (Once signed, changing a bit in the key flags would invalidate the signature on the key and would also change the footprint/keytag of the key.) But I also don't see any discussion that proves that "only zone keys at the apex" is a defendable restriction. >The proposed language depends on the operator doing the right thing, the above >requires the server or protocol engine to do the right thing. > >Possibly the right thing to do is take the proposed language and put it into a >document which describes a BCP for operating a secure DNS server >rather than >placing it in the protocol document. Such a BCP has been boiling for about 5 years. I feel that it won't happen until we have good protocol specs written first. The reason is that each time the BCP was written, a protocol flaw was found, upending all the work in the BCP. The challenge is to write the protocol specification without folding in the BCP material. I'm not saying that that it is easy to do. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer It's true, my last college class really was "Introduction to Ada." -- 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 May 3 15:57:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07400 for ; Sat, 3 May 2003 15:56:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C315-000CBC-00 for namedroppers-data@psg.com; Sat, 03 May 2003 19:49:51 +0000 Received: from [2002:421e:68aa:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 19C313-000BiK-00 for namedroppers@ops.ietf.org; Sat, 03 May 2003 19:49:50 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 36C2918EE for ; Sat, 3 May 2003 15:49:17 -0400 (EDT) Date: Sat, 03 May 2003 15:49:17 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Wrapup: DNSSECbis Q-8: Non-zone KEY RR at the apex. In-Reply-To: <5.1.0.14.2.20030503004008.00ac6748@localhost> References: <000a01c310b8$b6c50d20$14370681@lapdancer> <5.1.0.14.2.20030503004008.00ac6748@localhost> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030503194917.36C2918EE@thrintun.hactrn.net> X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sat, 03 May 2003 00:54:38 -0400, Michael StJohns wrote: > > Without making any comment on whether or not non-zone KEY RRs are > useful/bad, if the restriction is adopted, it should probably be stated as > a protocol restriction rather than a data content restriction. > > E.g. "A DNS server compliant with this specification MUST NOT serve a KEY > RR which has the Zone Key bit set unless that KEY RR is at the zone > apex. A DNS server MUST set the Zone Key bit for all KEY RRs which are at > the zone apex." Er, no. The zone content is the zone content, and the name server doesn't get to modify it on the fly (among other reasons, because doing so would invalidate the signatures). -- 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 May 3 16:13:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07816 for ; Sat, 3 May 2003 16:13:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C3Ly-000J8N-00 for namedroppers-data@psg.com; Sat, 03 May 2003 20:11:26 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19C3Lx-000J7j-00 for namedroppers@ops.ietf.org; Sat, 03 May 2003 20:11:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 168011390E for ; Sat, 3 May 2003 20:11:12 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Wrapup: DNSSECbis Q-8: Non-zone KEY RR at the apex. In-Reply-To: Message from Rob Austein of "Sat, 03 May 2003 15:49:17 -0400." <20030503194917.36C2918EE@thrintun.hactrn.net> X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 03 May 2003 20:11:12 +0000 Message-Id: <20030503201112.168011390E@sa.vix.com> X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, SATISFACTION autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > E.g. "A DNS server compliant with this specification MUST NOT serve a KEY > > RR which has the Zone Key bit set unless that KEY RR is at the zone > > apex. A DNS server MUST set the Zone Key bit for all KEY RRs which are at > > the zone apex." > > Er, no. The zone content is the zone content, and the name server > doesn't get to modify it on the fly (among other reasons, because > doing so would invalidate the signatures). i took this to mean "shall refuse to serve a zone without this property, for example issuing an error and refusing to load or reload a zone if this condition is not satisfied." -- 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 May 3 16:35:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08372 for ; Sat, 3 May 2003 16:35:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C3cw-000OJG-00 for namedroppers-data@psg.com; Sat, 03 May 2003 20:28:58 +0000 Received: from [2002:421e:68aa:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 19C3cu-000OH7-00 for namedroppers@ops.ietf.org; Sat, 03 May 2003 20:28:56 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 76EA818E1 for ; Sat, 3 May 2003 16:28:24 -0400 (EDT) Date: Sat, 03 May 2003 16:28:24 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Wrapup: DNSSECbis Q-8: Non-zone KEY RR at the apex. In-Reply-To: <20030503201112.168011390E@sa.vix.com> References: <20030503194917.36C2918EE@thrintun.hactrn.net> <20030503201112.168011390E@sa.vix.com> User-Agent: Wanderlust/2.8.1 (Something) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030503202824.76EA818E1@thrintun.hactrn.net> X-Spam-Status: No, hits=-31.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SATISFACTION,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sat, 03 May 2003 20:11:12 +0000, Paul Vixie wrote: > > > > E.g. "A DNS server compliant with this specification MUST NOT serve a KEY > > > RR which has the Zone Key bit set unless that KEY RR is at the zone > > > apex. A DNS server MUST set the Zone Key bit for all KEY RRs which are at > > > the zone apex." > > > > Er, no. The zone content is the zone content, and the name server > > doesn't get to modify it on the fly (among other reasons, because > > doing so would invalidate the signatures). > > i took this to mean "shall refuse to serve a zone without this property, > for example issuing an error and refusing to load or reload a zone if this > condition is not satisfied." Right, I don't have a problem with that interpretation, but if that's what we mean, it's probably what we should say :). -- 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 May 3 16:34:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08326 for ; Sat, 3 May 2003 16:34:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C3dP-000OO4-00 for namedroppers-data@psg.com; Sat, 03 May 2003 20:29:27 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19C3dL-000ONk-00 for namedroppers@ops.ietf.org; Sat, 03 May 2003 20:29:23 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEB00BEIVLJEK@eListX.com> for namedroppers@ops.ietf.org; Sat, 03 May 2003 16:29:43 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h43KOlQZ076256; Sat, 03 May 2003 16:24:47 -0400 (EDT envelope-from ogud@ogud.com) Date: Sat, 03 May 2003 16:29:12 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Summary: Q-03: inclusion of KEY records in additional records section In-reply-to: <5.1.1.6.2.20030212134348.0254be98@localhost> X-Sender: post@localhost To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030503162538.023ca338@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=iso-8859-1 X-Spam-Status: No, hits=-15.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_RFCI autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA08326 At 15:21 2003-02-12, Ólafur Guđmundsson wrote: > > > >Issue: Is there need to specify that KEY records be placed in additional >section on certain queries/responses. > >Q: Can the DS document outlaw the rules from 2535 that requires >inclusion of KEY in additional section ? I take that there is "consensus" to direct the editor to specify this. The DS document will specify that all requirements for inclusion of KEY RR in additional section are obsoleted. Olafur (as DS editor) -- 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 Derek.Olson@smileatyou.com Sun May 4 11:16:31 2003 Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01704 for ; Sun, 4 May 2003 11:16:00 -0400 (EDT) Received: from h-69-3-126-144.dnvtco56.covad.net ([69.3.126.144] helo=Derek.Olson) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19CLFx-0003lh-00 for dnsext-archive@lists.ietf.org; Sun, 04 May 2003 08:18:25 -0700 From: To: "dnsext-archive@lists.ietf.org" Subject: Confirmation Message-Id: Date: Sun, 04 May 2003 08:18:25 -0700 Confirmation for dnsext-archive@lists.ietf.org Please confirm that you would like updates of my work. We have decided to add this 'double opt-in' system because some prankster decided it would be fun to add a bunch of people without their permission or knowledge. This event has led me to answer angry emails all week instead of carving. All I want to do is carve and share my work with those who can feel it and receive the light. Nobody wants more useless email, and I certainly have no desire to share my work and ideas with anyone who has no interest. Reply to this email and type 'Yes Please' in the body and you will be added. Do nothing and you will be forgotten. Derek Olson Tristan Woodworks http://www.SmileAtYou.com Highlands Ranch, Colorado From owner-namedroppers@ops.ietf.org Sun May 4 14:45:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03938 for ; Sun, 4 May 2003 14:45:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19COGo-000H09-00 for namedroppers-data@psg.com; Sun, 04 May 2003 18:31:30 +0000 Received: from shell-ng.nominum.com ([81.200.64.181]) by psg.com with esmtp (Exim 3.36 #1) id 19COGm-000Gzx-00 for namedroppers@ops.ietf.org; Sun, 04 May 2003 18:31:28 +0000 Received: from STJOHNS-LAPTOP.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 068695685F; Sun, 4 May 2003 11:31:27 -0700 (PDT) Message-Id: <5.1.0.14.2.20030504143053.02fd8268@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 04 May 2003 14:31:33 -0400 To: Rob Austein , namedroppers@ops.ietf.org From: Michael StJohns Subject: Re: Wrapup: DNSSECbis Q-8: Non-zone KEY RR at the apex. In-Reply-To: <20030503202824.76EA818E1@thrintun.hactrn.net> References: <20030503201112.168011390E@sa.vix.com> <20030503194917.36C2918EE@thrintun.hactrn.net> <20030503201112.168011390E@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-31.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SATISFACTION autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 04:28 PM 5/3/2003 -0400, Rob Austein wrote: >At Sat, 03 May 2003 20:11:12 +0000, Paul Vixie wrote: > > > > > > E.g. "A DNS server compliant with this specification MUST NOT > serve a KEY > > > > RR which has the Zone Key bit set unless that KEY RR is at the zone > > > > apex. A DNS server MUST set the Zone Key bit for all KEY RRs which > are at > > > > the zone apex." > > > > > > Er, no. The zone content is the zone content, and the name server > > > doesn't get to modify it on the fly (among other reasons, because > > > doing so would invalidate the signatures). > > > > i took this to mean "shall refuse to serve a zone without this property, > > for example issuing an error and refusing to load or reload a zone if this > > condition is not satisfied." > >Right, I don't have a problem with that interpretation, but if that's >what we mean, it's probably what we should say :). Hey, give me a break - I spent all of 5 minutes word smithing this stuff....:-) -- 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 May 4 15:07:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04597 for ; Sun, 4 May 2003 15:07:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19COku-000MD1-00 for namedroppers-data@psg.com; Sun, 04 May 2003 19:02:36 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19COks-000MCk-00 for namedroppers@ops.ietf.org; Sun, 04 May 2003 19:02:34 +0000 Received: from lapdancer (asynce042.nist.gov [129.6.31.42]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h44J1pbd024337; Sun, 4 May 2003 15:01:52 -0400 (EDT) Message-ID: <007801c3126f$3728b3b0$2a1f0681@lapdancer> From: "Scott Rose" To: "Simon Josefsson" Cc: References: <000701c30daf$77c171b0$14370681@lapdancer><004b01c310d3$4bfc0fa0$b9370681@barnacle> Subject: Re: DNSSECbis Q-8: Non-zone KEY RR at the apex. Date: Sun, 4 May 2003 14:58:55 -0400 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 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Status: No, hits=-19.1 required=5.0 tests=BAYES_20,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Simon Josefsson" > > It is not like it destroys interoperability, or add any negative > consequences for anyone. Resolvers doesn't have to implement anything > extra to support it. It just works, but wastes a few bytes of > bandwidth. Only the administrators using it will suffer. Those > administrator can chose to not use it if they suffer too much. > > > Since SIG(0) KEYs are usually for a host/entity it would seem that > > having an update/zone transfer key with the same name as the zone > > might not be a good idea. Having another name "primary.zone" or > > "updatekey.zone" seems more logical. > > Is there consensus about this? > > If so, explain the solution in the document, so people that were using > valid RFC 2535 constructions can migrate to the new solution. Don't > forget to discuss the migration issues. > > > While most implementations would see the flags, > > Any implementation that didn't would be insecure. > > > a human admin may make mistakes if they manually edit a zone file. > > Humans should use tools if they don't know what they are doing. > There is no consensus about naming keys for non-zone signing purpose. There was a question in the protocol draft about this. I do think it is not as severe as problem to warrent a special rule (i.e. saying "MUST NOT include a non-zone KEY RR at the apex"), but since it was a big enough issue to warrent a seperate note in the draft, I felt it should go through namedroppers. It seems so far in the discussion that most seem to think it does no harm to the protocol in allow non-zone KEYs to have the same name as the apex. Scott -- 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 May 4 21:41:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10539 for ; Sun, 4 May 2003 21:41:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CUrr-0004td-00 for namedroppers-data@psg.com; Mon, 05 May 2003 01:34:11 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19CUrp-0004tP-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 01:34:09 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19CUro-000E8B-GG for namedroppers@ops.ietf.org; Sun, 04 May 2003 18:34:08 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 4 May 2003 18:34:08 -0700 To: namedroppers Subject: chairs' message on opt-in Message-Id: X-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_20,OPT_IN version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit the wg last call on [ds-only] opt-in is over. it's a tough issue and the wg discussion has been muddy, to be kind. 1 - there seems to be consensus that the spec is complete and correct. this was determined in a separate last call. 2 - is there consensus that opt-in adds complexity? probably yes, but folk disagree on how much and disagree on the impact of that complexity on dns operation and on security. 3 - is there consensus that opt-in changes the security model from 'simple dnssec'? yes. is that change bad? opinions differ. 4 - is there consensus that deployment of dnssec is important? yes. 5 - is there consensus that opt-in may help deployment of dnssec? yes, for a few very large zones. 6 - it might not be obvious how to come to a decision here - or even whether we can come to a decision. the question asked of the WG was: "is there consensus in the wg, to allow ds-only opt-in in zones?" the way this is phrased the default action, which is what applies should there not be rough consensus, is to not add the opt-in feature to the protocol. one might argue that the question was asked in a biased manner and the question should instead have been asked as: "should we allow or not allow opt-in zones?" first, it is traditional and reasonable to place the onus of consensus on *additions* to protocols, since it is likely to lead to less features in protocols if each added feature needs wg rough consensus. i.e., this was normal wg procedure. second, and possibly more important, had the question been asked that way, we would have the equivalent of a hung jury with no process for how to move forward at all. 7 - is there consensus that consensus-5 should override consensus-2 and consensus-3? discussion varied, folk had opinions on both sides. underneath the flamage, there was actual disagreement, with knowledgeable parties on both sides of the fence. this is not consensus. given that we all want to move forward the chairs, given the process, have no choice but to come to the following conclusion: there is no consensus to add opt-in. randy & olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun May 4 22:29:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11508 for ; Sun, 4 May 2003 22:29:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CVdm-0007wB-00 for namedroppers-data@psg.com; Mon, 05 May 2003 02:23:42 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19CVdi-0007vp-00; Mon, 05 May 2003 02:23:38 +0000 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h452Nadv017650; Sun, 4 May 2003 19:23:37 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 4 May 2003 19:23:37 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , namedroppers Subject: RE: chairs' message on opt-in Date: Sun, 4 May 2003 19:23:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-7.8 required=5.0 tests=BAYES_10,OPT_IN,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It seems somewhat strange to place the burden of proof on changes to a protocol that has been undeployable for ten years. The bias in favor of the status quo is understandable in the case of a protocol that is deployed. A bias in favor of inaction when a protocol has been undeployed for a decade is a farce. A bias in favor of inaction when the chairs choose to put the question repeatedly until they receive the answer they want is a farce. The chairs and the group will therefore understand why discussion of this matter must now move to other forums, starting with the IESG. Phill > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Sunday, May 04, 2003 9:34 PM > To: namedroppers > Subject: chairs' message on opt-in > > > the wg last call on [ds-only] opt-in is over. it's a tough issue > and the wg discussion has been muddy, to be kind. > > 1 - there seems to be consensus that the spec is complete and > correct. this was determined in a separate last call. > > 2 - is there consensus that opt-in adds complexity? probably yes, > but folk disagree on how much and disagree on the impact of > that complexity on dns operation and on security. > > 3 - is there consensus that opt-in changes the security model from > 'simple dnssec'? yes. is that change bad? opinions differ. > > 4 - is there consensus that deployment of dnssec is important? > yes. > > 5 - is there consensus that opt-in may help deployment of dnssec? > yes, for a few very large zones. > > 6 - it might not be obvious how to come to a decision here - or > even whether we can come to a decision. > > the question asked of the WG was: > > "is there consensus in the wg, to allow ds-only opt-in in > zones?" > > the way this is phrased the default action, which is what > applies should there not be rough consensus, is to not add the > opt-in feature to the protocol. > > one might argue that the question was asked in a biased manner > and the question should instead have been asked as: > > "should we allow or not allow opt-in zones?" > > first, it is traditional and reasonable to place the onus of > consensus on *additions* to protocols, since it is likely to > lead to less features in protocols if each added feature needs > wg rough consensus. i.e., this was normal wg procedure. > > second, and possibly more important, had the question been > asked that way, we would have the equivalent of a hung jury > with no process for how to move forward at all. > > 7 - is there consensus that consensus-5 should override consensus-2 > and consensus-3? discussion varied, folk had opinions on both > sides. underneath the flamage, there was actual disagreement, > with knowledgeable parties on both sides of the fence. this is > not consensus. > > given that we all want to move forward the chairs, given the > process, have no choice but to come to the following conclusion: > > there is no consensus to add opt-in. > > randy & olafur > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > 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 May 5 05:07:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27390 for ; Mon, 5 May 2003 05:07:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Cbqw-000G72-00 for namedroppers-data@psg.com; Mon, 05 May 2003 09:01:42 +0000 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 19Cbqs-000G6e-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 09:01:39 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.6) with ESMTP id h4591YBd070847; Mon, 5 May 2003 11:01:34 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h4591Xih070846; Mon, 5 May 2003 11:01:33 +0200 (CEST) Message-Id: <200305050901.h4591Xih070846@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Mon, 5 May 2003 11:01:33 +0200 In-Reply-To: ""Hallam-Baker, Phillip"'s message as of May 5, 4:34" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Hallam-Baker, Phillip" , namedroppers Subject: RE: chairs' message on opt-in X-Spam-Status: No, hits=-7.8 required=5.0 tests=BAYES_10,IN_REP_TO,OPT_IN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting "Hallam-Baker, Phillip", on May 5, 4:34, in "RE: chairs' message ..."] > It seems somewhat strange to place the burden of proof on > changes to a protocol that has been undeployable for ten > years. I have a problem with this statement in the context of the opt-in discussion: it seems to imply that it is impossible to deploy DNSSEC in its current state, but that it can be deployed when opt-in is added. If this is what Phillip indeed intends to say, then I would like to remind him of the following: 1. It took until 1999/2000 before an implementation was ready for test, in fact, two implementations became available short after each other: BIND8.2.2p5 and BIND9. That is three years ago, not ten years. 2. Immediately after these implementations became available, a number of organisations, among which was NLnet Labs in collaboration with CENTR (European ccTLDs), started deploying DNSSEC in various scale test situations. TLD zones were signed, loaded, and queried in test-nameservers to check the deployability. 3. In contrast to what many feared, it turned out that there was NO problem in signing and running even the largest zones, like .de and .com. For .de and .com one needs a system with a 64-bit architecture, but 64-bit systems are available and affordable nowadays. 4. However, these early experiments did reviel, that having the child's KEY present and signed in the parent's zone would lead to a very big organizational problem for TLDs. (The most optimized scheme we could devise to perform a scheduled key roll-over needed 11 steps between Registry and Registrant, while we could not devise a workable scheme to perform an emergency key roll-over). Thanks to other WG-members, the DS RR was developed as a solution. 5. Since DS is available, there are a number of TLDs (at least .nl, .se, and .fr, but probably more) that deploy DNSSEC in a test- environment. These tests run stable. There has been some discussion on the size of a signed non-optin .com zonefile, but both theoretical analysis and real experiments have shown that deployment of RFC2535+DS is quite possible in .com, with or without the opt-in addition. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 5 07:40:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29405 for ; Mon, 5 May 2003 07:40:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CeFh-000A7z-00 for namedroppers-data@psg.com; Mon, 05 May 2003 11:35:25 +0000 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 19CeFd-000A7g-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 11:35:22 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA13316; Mon, 5 May 2003 05:35:20 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h45BZJL03859; Mon, 5 May 2003 13:35:19 +0200 (MEST) Date: Mon, 5 May 2003 13:34:54 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Appeal against decision of DNSEXT working group chairs to prevent progess of OPT-IN To: "Hallam-Baker, Phillip" Cc: "'namedroppers@ops.ietf.org'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_10,IN_REP_TO,OPT_IN,OPT_IN_CAPS,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The last call on OPT-IN having expired on March 31st and the chairs > having not responded to the clear consensus of the working group to allow > the drafts to go forward, I hereby appeal against the apparent decision of > the chairs to prevent the progress of the OPT-IN proposal. Phillip, The above note added additional motivation to get the opt-in last call summary out. As I explained in an earlier message there was discussion between the co-chairs and ADs about the process of guaging concensus on this thorny issue combined with vacations and travel that lead to the delay. As I said in that emai I should have let the WG know this was the reason for the delay. Given that the co-chairs have now announced their guage of the WG on this topic I'm trying to understand the status of the appeal. I note that there are additional topics of your email beyond the delay. Should the destination (see next question) of the appeal process the other issues of the appeal at this point in time, or will you submit a modified appeal? I also note that it isn't immediately obvious to whom you are appealing: the WG? (the email was sent to namedroppers and nobody else), the co-chairs, the ADs, the IESG? (the email mentions the IESG as "It is now time for the IESG to consider ...") Per RFC 2026 section 6.5 you should first discuss the "incorrect technical choice" aspects of the appeal with the WG chairs. Once that has been exhausted bring it to the ADs and after that to the IESG, etc. It would be helpful if you can make it clearer where you are in this process by being explicit at whom you are directing an appeal. Thanks, Erik -- 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 May 5 11:28:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05531 for ; Mon, 5 May 2003 11:28:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Chjb-000IkM-00 for namedroppers-data@psg.com; Mon, 05 May 2003 15:18:31 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19ChjZ-000Ik8-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 15:18:29 +0000 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h45FILdv021158; Mon, 5 May 2003 08:18:21 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 May 2003 08:18:21 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'ted@NLnetLabs.nl'" , "Hallam-Baker, Phillip" , namedroppers Subject: RE: chairs' message on opt-in Date: Mon, 5 May 2003 08:18:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-8.6 required=5.0 tests=BAYES_01,OPT_IN,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 1. It took until 1999/2000 before an implementation was ready > for test, in fact, two implementations became available short > after each other: BIND8.2.2p5 and BIND9. That is three years > ago, not ten years. I said that the protocol has been undeployable for ten years. If Ted can tell me how the protocol could have been deployed without code I am interested to hear it. As Ted points out the trial deployments uncovered a large number of problems, including the large zone issue. If one of the chairs had not chosen to behave in the way he did the large zone issue would also have been addressed by the group. As it is the chairs have decided that this group did not decide. Therefore the proposal moves onto another forum. Phill -- 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 May 5 12:04:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06417 for ; Mon, 5 May 2003 12:03:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CiKW-000PEv-00 for namedroppers-data@psg.com; Mon, 05 May 2003 15:56:40 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19CiKT-000PEd-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 15:56:38 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 29B7636A; Mon, 5 May 2003 11:56:35 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B06FD33E; Mon, 5 May 2003 11:56:34 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 224931; Mon, 05 May 2003 11:45:53 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 5 May 2003 11:56:30 -0400 To: Randy Bush From: Edward Lewis Subject: Re: chairs' message on opt-in Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:34 -0700 5/4/03, Randy Bush wrote: > there is no consensus to add opt-in. "Add" it to the standards track? My question is about the word "add." From the chairs' message, it seems to me that the only negative comments on opt-in involve such words as "probably" and "opinions differ." Given that I don't see any definitive statement that opt-in is a detriment to network operations and that it seems that the negative statements are founded in uncertainty, I feel compelled to suggest that perhaps opt-in be declared experimental. I'm basing this suggestion on the document's maturity and completeness, albeit about a potentially risky proposition. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 5 12:45:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07387 for ; Mon, 5 May 2003 12:45:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Cj3T-0007H9-00 for namedroppers-data@psg.com; Mon, 05 May 2003 16:43:07 +0000 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 19Cj3Q-0007DL-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 16:43:04 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.6) with ESMTP id h45Gh2Bd073832 for ; Mon, 5 May 2003 18:43:02 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h45Gh2am073831 for namedroppers@ops.ietf.org; Mon, 5 May 2003 18:43:02 +0200 (CEST) Message-Id: <200305051643.h45Gh2am073831@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Mon, 5 May 2003 18:43:02 +0200 In-Reply-To: ""Hallam-Baker, Phillip"'s message as of May 5, 17:39" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers Subject: RE: chairs' message on opt-in X-Spam-Status: No, hits=-11.0 required=5.0 tests=BAYES_10,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting "Hallam-Baker, Phillip", on May 5, 17:39, in "RE: chairs' message ..."] > > > 1. It took until 1999/2000 before an implementation was ready > > for test, in fact, two implementations became available short > > after each other: BIND8.2.2p5 and BIND9. That is three years > > ago, not ten years. > > I said that the protocol has been undeployable for ten years. > > If Ted can tell me how the protocol could have been deployed > without code I am interested to hear it. It could not, that was my statement: trail deployments take place for three years now, much too long, but not ten years. > As Ted points out the trial deployments uncovered a large number > of problems, including the large zone issue. If one of the chairs > ....... 1. I certainly never pointed out anything like that. On the contrairy: the trial deployments uncovered surprisingly few problems. Especially they uncovered that the much feared "large zone" problem, was a non-issue: we showed that even with an entry-level desktop computer, a Compaq DS-10, we could sign and run the .de and .com zonefiles. Of course the .com zone was smaller at that time, but computer-power has grown an order of magnitude more than the .com zone has grown since. Phillip must have missed large parts of the DNSSEC development since 2000, so I'll repeat: The one and only serious deployment problem we uncovered was the maintenance of the registrants KEY in the registry's zonefile. This problem has been fixed by the DS RR. As a side-effect, with the DS RR we also got rid of the null-key, and this further reduced the already manageable "large zone" issue by a factor of two for large zones with few secured delegations. 2. Please stop this childish "chair bashing" game. -- ted -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 5 12:46:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07439 for ; Mon, 5 May 2003 12:46:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Civo-000621-00 for namedroppers-data@psg.com; Mon, 05 May 2003 16:35:12 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19Civl-00061j-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 16:35:09 +0000 Received: from lapdancer (gorilla.antd.nist.gov [129.6.55.20]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h45GZ4bd017396 for ; Mon, 5 May 2003 12:35:04 -0400 (EDT) Message-ID: <008101c31323$decd5e90$14370681@lapdancer> From: "Scott Rose" To: "namedroppers" References: Subject: Re: chairs' message on opt-in Date: Mon, 5 May 2003 12:32:07 -0400 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 5.50.4920.2300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Status: No, hits=-20.8 required=5.0 tests=BAYES_01,OPT_IN,OPT_IN_CAPS,ORIGINAL_MESSAGE, QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Edward Lewis" > At 18:34 -0700 5/4/03, Randy Bush wrote: > > there is no consensus to add opt-in. > does this mean there is a consensus to not add opt-in? Given some recent traffic, my opinion is that some still want to see it in some form. > "Add" it to the standards track? My question is about the word "add." > > From the chairs' message, it seems to me that the only negative > comments on opt-in involve such words as "probably" and "opinions > differ." Given that I don't see any definitive statement that opt-in > is a detriment to network operations and that it seems that the > negative statements are founded in uncertainty, I feel compelled to > suggest that perhaps opt-in be declared experimental. > > I'm basing this suggestion on the document's maturity and > completeness, albeit about a potentially risky proposition. If it is declared experimental, will there be a mechanism to alert a resolver that the zone uses OPT-IN? Scott > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Note to pilots: a three-point landing SHOULD NOT include a wing. > > -- > 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 May 5 13:15:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08392 for ; Mon, 5 May 2003 13:15:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CjSd-000CUt-00 for namedroppers-data@psg.com; Mon, 05 May 2003 17:09:07 +0000 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 19CjSY-000CTm-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 17:09:02 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.3) with ESMTP id h45H8vNj031445 for ; Mon, 5 May 2003 19:08:57 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) with ESMTP id h45H8vXk031442 for ; Mon, 5 May 2003 19:08:57 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 5 May 2003 19:08:57 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers Subject: RE: chairs' message on opt-in In-Reply-To: <200305051643.h45Gh2am073831@open.nlnetlabs.nl> Message-ID: References: <200305051643.h45Gh2am073831@open.nlnetlabs.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-38.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 5 May 2003, Ted Lindgreen wrote: > the trial deployments uncovered surprisingly few problems. Especially > they uncovered that the much feared "large zone" problem, was a > non-issue: we showed that even with an entry-level desktop computer, a > Compaq DS-10, we could sign and run the .de and .com zonefiles. Of > course the .com zone was smaller at that time, but computer-power has > grown an order of magnitude more than the .com zone has grown since. Sure, with a reliable, secure and homogeneous network, zero latency, infinite bandwith, stable topology, zero transport cost and a single administrator [1], I can imagine it is quite possible, today, but only today, with 64 bit, no crypto-certified hardware, meanwhile hoping that IPv6, IDN and ENUM never takes off, since the .com zone might grow, and the argument will not hold sway. It took 3 years before moore's law projected on todays hw with 3 yr old stats would become valid. Applying Moore's law is valid when applied to all variables, including data size, not just the ones that fits the argument. Today's DNSSEC just doesn't scale. Roy [1] The Eight Fallacies of Distributed Computing. http://java.sun.com/people/jag/fallacies.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 Mon May 5 13:42:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09116 for ; Mon, 5 May 2003 13:42:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CjsU-000HQJ-00 for namedroppers-data@psg.com; Mon, 05 May 2003 17:35:50 +0000 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 19CjsD-000HPi-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 17:35:33 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.3) with ESMTP id h45HZQNj031850; Mon, 5 May 2003 19:35:26 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) with ESMTP id h45HZQ5i031847; Mon, 5 May 2003 19:35:26 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 5 May 2003 19:35:26 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Scott Rose cc: namedroppers Subject: Re: chairs' message on opt-in In-Reply-To: <008101c31323$decd5e90$14370681@lapdancer> Message-ID: References: <008101c31323$decd5e90$14370681@lapdancer> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-37.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 5 May 2003, Scott Rose wrote: > If it is declared experimental, will there be a mechanism to alert a > resolver that the zone uses OPT-IN? Well, the resolver can flag through edns its compliance with opt-in. 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 Mon May 5 13:55:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09548 for ; Mon, 5 May 2003 13:55:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ck82-000KTD-00 for namedroppers-data@psg.com; Mon, 05 May 2003 17:51:54 +0000 Received: from adsl-64-174-59-161.dsl.snfc21.pacbell.net ([64.174.59.161] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 19Ck80-000KT0-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 17:51:52 +0000 Received: from spratly.wl.nominum.com (spratly [127.0.0.1]) by spratly.wl.nominum.com (8.12.8/8.12.8) with ESMTP id h45Hp5kG015653; Mon, 5 May 2003 10:51:05 -0700 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h45Hp4Bb015650; Mon, 5 May 2003 10:51:04 -0700 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Mon, 5 May 2003 10:51:04 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Roy Arends cc: Scott Rose , namedroppers Subject: Re: chairs' message on opt-in In-Reply-To: Message-ID: References: <008101c31323$decd5e90$14370681@lapdancer> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-37.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 5 May 2003, Roy Arends wrote: > On Mon, 5 May 2003, Scott Rose wrote: > > > If it is declared experimental, will there be a mechanism to alert a > > resolver that the zone uses OPT-IN? > > Well, the resolver can flag through edns its compliance with opt-in. This would involve adding such a flag to the opt-in spec. I remember suggesting this years ago. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 5 14:47:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11064 for ; Mon, 5 May 2003 14:47:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ckru-0003oR-00 for namedroppers-data@psg.com; Mon, 05 May 2003 18:39:18 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19Ckrq-0003g4-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 18:39:14 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B23D81390E; Mon, 5 May 2003 18:39:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Roy Arends Cc: namedroppers Subject: Re: chairs' message on opt-in In-Reply-To: Message from Roy Arends of "Mon, 05 May 2003 19:08:57 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 05 May 2003 18:39:01 +0000 Message-Id: <20030505183901.B23D81390E@sa.vix.com> X-Spam-Status: No, hits=-24.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk roy, among other things, you wrote: > It took 3 years before moore's law projected on todays hw with 3 yr old > stats would become valid. > > Applying Moore's law is valid when applied to all variables, including > data size, not just the ones that fits the argument. > > Today's DNSSEC just doesn't scale. > > [1] The Eight Fallacies of Distributed Computing. > http://java.sun.com/people/jag/fallacies.html i have two observations. 1. you're not going to convince anybody to change their mind about opt-in using this approach, or indeed any other approach. the debate is polarized and no minds will change now. 2. dnssec can be made to scale. its nondeployability due to lack of opt-in is an L9 issue not an L1 issue. (a compelling L9 issue, to be sure, but the point is, this isn't a hardware problem.) paul -- 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 May 5 14:48:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11128 for ; Mon, 5 May 2003 14:48:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ckxk-0004xF-00 for namedroppers-data@psg.com; Mon, 05 May 2003 18:45:20 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19Ckxh-0004tb-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 18:45:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7D5801394B for ; Mon, 5 May 2003 18:45:04 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: chairs' message on opt-in In-Reply-To: Message from Roy Arends of "Mon, 05 May 2003 19:35:26 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 05 May 2003 18:45:04 +0000 Message-Id: <20030505184504.7D5801394B@sa.vix.com> X-Spam-Status: No, hits=-11.8 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,OPT_IN_CAPS,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > If it is declared experimental, will there be a mechanism to alert a > > resolver that the zone uses OPT-IN? an experimental rfc will still reserve the encoding (NXT bit not set in NXT bitmask) and this condition would be enough to signal opt-in to those validators who understood it. it would be treated as either a format error or a no-op by those validators who did not understand it. in no case does the zone need to alert anybody of its intentions. > Well, the resolver can flag through edns its compliance with opt-in. that would be expensive, since the NXT mask would then have to be signed both with and without the "NXT bit is zero in the NXT bitmask" condition. -- 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 May 5 15:04:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11815 for ; Mon, 5 May 2003 15:04:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ClDf-0008LC-00 for namedroppers-data@psg.com; Mon, 05 May 2003 19:01:47 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19ClDa-0008K9-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 19:01:42 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id B3DAD3B9; Mon, 5 May 2003 15:01:39 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 23D9C3C2 for ; Mon, 5 May 2003 15:01:39 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 225126 for namedroppers@ops.ietf.org; Mon, 05 May 2003 14:50:57 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <008101c31323$decd5e90$14370681@lapdancer> Date: Mon, 5 May 2003 15:01:24 -0400 To: namedroppers From: Edward Lewis Subject: Re: chairs' message on opt-in Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 19:35 +0200 5/5/03, Roy Arends wrote: >Well, the resolver can flag through edns its compliance with opt-in. Roy, I hope you just forgot the ';)' on that one. ;) I don't think it would be easy to make opt-in a 'versioned' feature due to the nature of opt-in. I think that if the resolver were to say 'I do opt-in' it is really just asking the server if there is a DS for the referral, even if the referral is part of an unsigned zone. That sounds ugly. I also cringe every time we consider adding option negotiation to the DNS protocol. (I've had this out with Paul already. ;)) If we went back to the start, we ought to have used extra types and relied strictly on the three Q's for how an answer was prepared instead of EDNS0. We can't go back and right that wrong, but we can try to stop it from happening again. Still, if opt-in were to be on the experimental track, then maybe we'd want the DNSSECbis documents to specify that the NXT bit in the NXT would be set to 1 by the signer (the data preparer) and ignored in the verifier. DNSSECbis would also have to say that if the QNAME is between the NXT's owner name and its next name, then the QNAME should be considered not to exist - and that causes a problem for an experimental opt-in zone. Or maybe we could say that if the NXT bit is 0 in an NXT, then the verifier is to treat the NXT as existing (I've got it), but ignore any proof of non-existence it yields. E.g., if the bit is 1 as it should be, then the rigid semantics hold. If the bit is 0, then something else is going on - Akin to bit for RR type 0, the extended format bit. Then, when DNSSECbis gets to proposed standard, if the opt-in experiment fails, the bit value of 0 is considered obsolete. If the opt-in experiment succeeds, then the experiment specification is rolled into the proposed standard. Sorry if I seem like someone who is just trying to string along opt-in after it has been declared to be whatever it has been declared to be, but 1) I'm not clear on what the chairs mean and 2) think that it's not too late to find a consensus. (Especially here, where there's no consensus for opt-in, no consensus against opt-in, just no consensus yet, as far as I can tell from the chairs' message.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 5 15:23:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13275 for ; Mon, 5 May 2003 15:22:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ClSc-000BKS-00 for namedroppers-data@psg.com; Mon, 05 May 2003 19:17:14 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19ClSZ-000BKC-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 19:17:11 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 553C13E4; Mon, 5 May 2003 15:17:11 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id E7BA43CF for ; Mon, 5 May 2003 15:17:10 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 225146; Mon, 05 May 2003 15:06:29 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <008101c31323$decd5e90$14370681@lapdancer> Date: Mon, 5 May 2003 15:17:07 -0400 To: Edward Lewis From: Edward Lewis Subject: Re: chairs' message on opt-in Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk sed "s/proposed/draft/g" At 15:01 -0400 5/5/03, Edward Lewis wrote: >Then, when DNSSECbis gets to proposed standard, if the opt-in >experiment fails, >the bit value of 0 is considered obsolete. If the opt-in experiment succeeds, >then the experiment specification is rolled into the proposed standard. ^D -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 5 18:53:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20675 for ; Mon, 5 May 2003 18:53:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CofA-0002ZF-00 for namedroppers-data@psg.com; Mon, 05 May 2003 22:42:24 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19Cof7-0002Yz-00 for namedroppers@ops.ietf.org; Mon, 05 May 2003 22:42:21 +0000 Received: by sentry.rv.nailabs.com; id SAA22936; Mon, 5 May 2003 18:43:30 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma022882; Mon, 5 May 03 18:42:35 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6/8.11.6) with ESMTP id h45MfNZ22235; Mon, 5 May 2003 18:41:23 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Mon, 5 May 2003 18:41:23 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Roy Arends cc: namedroppers Subject: Re: chairs' message on opt-in In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_PINE, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 5 May 2003, Roy Arends wrote: > Well, the resolver can flag through edns its compliance with opt-in. Except that client signaling doesn't achieve opt-in's goals -- the onus would be on the server to support non-opt-in clients, which means signing everything anyway. -- 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 Mon May 5 23:34:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25623 for ; Mon, 5 May 2003 23:34:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ct6k-0006vf-00 for namedroppers-data@psg.com; Tue, 06 May 2003 03:27:10 +0000 Received: from gro.dd.org ([209.198.103.200]) by psg.com with esmtp (Exim 3.36 #1) id 19Ct6a-0006uw-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 03:27:00 +0000 Received: by gro.dd.org (Postfix, from userid 102) id D85566A0; Mon, 5 May 2003 23:26:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16055.11136.791170.822938@gro.dd.org> Date: Mon, 5 May 2003 23:26:56 -0400 From: tale@nominum.com (David C Lawrence) To: namedroppers@ops.ietf.org Subject: Re: RFC 2181: What is the maximum length of a domain name? In-Reply-To: References: <200304301918.h3UJIoQ14406@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edward Lewis writes: > It looks to me 4*(63+63+63+61)+5 = 1005 octets for the [maximum > standard text representation] is possible Only four labels means only four dots when written with the root label dot. 1004 total. -- 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 May 6 08:40:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18540 for ; Tue, 6 May 2003 08:40:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D1YB-0007CJ-00 for namedroppers-data@psg.com; Tue, 06 May 2003 12:28:03 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19D1Y8-000797-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 12:28:00 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 97C123C2; Tue, 6 May 2003 08:27:57 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 343FD3B7; Tue, 6 May 2003 08:27:57 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 225806; Tue, 06 May 2003 08:17:13 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <16055.11136.791170.822938@gro.dd.org> References: <200304301918.h3UJIoQ14406@grimsvotn.TechFak.Uni-Bielefeld.DE> <16055.11136.791170.822938@gro.dd.org> Date: Tue, 6 May 2003 08:27:51 -0400 To: tale@nominum.com (David C Lawrence) From: Edward Lewis Subject: Re: RFC 2181: What is the maximum length of a domain name? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:26 -0400 5/5/03, David C Lawrence wrote: >Edward Lewis writes: >> It looks to me 4*(63+63+63+61)+5 = 1005 octets for the [maximum >> standard text representation] is possible > >Only four labels means only four dots when written with the root label >dot. 1004 total. D'oh. I keep forgetting that 5 length octets = 4 dots. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 6 08:55:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19100 for ; Tue, 6 May 2003 08:55:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D1wB-000AVm-00 for namedroppers-data@psg.com; Tue, 06 May 2003 12:52:51 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19D1w7-000AVV-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 12:52:48 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 63C81373; Tue, 6 May 2003 08:52:47 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id C2BD534F for ; Tue, 6 May 2003 08:52:46 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 225845; Tue, 06 May 2003 08:42:02 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Tue, 6 May 2003 08:52:40 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: proposed definition for the NXT Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_01,OPT_IN,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm proposing this for the NXT in the DNSSECbis document... After properly validating the NXT's authenticity: If the NXT-position bit is 1, then the NXT is processed as per RFC 2535 or the DS RR (I don't recall any difference). If the bit is 0, then the verifier treats the zone as unsigned, ergo, all the subzones are unsigned. (Yeah, yeah, secure entry points, yadda, yadda.) (See note 1 below.) With that definition, non-opt-in (I'll call them 2535) zones will work, as they will either have only 1's in the NXT (bit position of the NXT) or no NXT's. Zones that do the funny stuff will be treated as the old experimental zones, which defaults to unsigned. This let's server operators play with funny stuff (e.g., the current opt-in proposal) while not breaking themselves off the net. For resolvers, which is what DNSSEC is all about protecting, the older resolvers are fine with 2535 and pre-2535 zones, and buffered against the funny stuff. Once the funny stuff is acceptable, hits the standards track, then it becomes cool to define what the funny stuff is. On the other hand, if the funny stuff never gets accepted, then the operators doing the funny stuff will have a reason to just sign the whole zone. This lets us proceed without the presumption that the opt-in detractors are wrong because opt-in isn't being put into the resolver right out. It respects the fact that consensus hasn't been reached, at least in the chairs' eyes. Also, those who want to press forward stamping out the apparent uncertainty and doubt (omitting fear) have a sandbox area to make medium scale deployments for the sake of testing. ...For the time being, a compliant DNSSECbis signer MUST set the bit to 1. Note 1 - Yes, any '0' bit in the NXT will make the resolver see the whole zone as unsigned - for the duration of the query at least, at most the ttl of the NXT it is looking at. The burden is not on the resolver to seek out all the NXT's and look for '0' bits, but only if the query stumbles on it. Treating the zone as unsigned means ignoring any DS records, KEY records, SIG records, NXT records, etc. By tainting the whole zone you "punish" the operator for doing this on the large scale, if that is your desire. I think just treating spans of the zone as unsigned would be an over complication and too much like the current opt-in. Perhaps we should always require a server to load only zones that have one kind of NXT - with the 1 or with the 0, and no combinations. This will make it easier to decide of a zone is doing funny stuff. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 6 08:55:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19115 for ; Tue, 6 May 2003 08:55:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D1tf-000AEl-00 for namedroppers-data@psg.com; Tue, 06 May 2003 12:50:15 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19D1tO-000AA6-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 12:49:58 +0000 Received: from lapdancer (gorilla.antd.nist.gov [129.6.55.20]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h46CnWbd025115 for ; Tue, 6 May 2003 08:49:33 -0400 (EDT) Message-ID: <002c01c313cd$88be9280$14370681@lapdancer> From: "Scott Rose" To: Subject: Summary: DNSSECbis Q-8: Non zone KEYs at the apex Date: Tue, 6 May 2003 08:46:37 -0400 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 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The language in the protocol document will remain as is: namely, non-zone KEY RRs SHOULD NOT be placed in the zone apex, but are not expressly forbidden. There is no consensus to make this a more stringent restriction ("SHOULD NOT/MUST NOT"). The view seems to be that there is no harm in having non-zone DNSSEC keys at the apex as part of the KEY RR set. There may be some benefit to allowing them and no really reason to make the language read "MUST NOT be placed at the zone apex". Scott -- 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 May 6 10:07:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22526 for ; Tue, 6 May 2003 10:07:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D31p-000KKW-00 for namedroppers-data@psg.com; Tue, 06 May 2003 14:02:45 +0000 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 19D318-000KEy-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 14:02:02 +0000 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h46E1lB4002138 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 6 May 2003 16:01:48 +0200 To: "Scott Rose" Cc: Subject: Re: Summary: DNSSECbis Q-8: Non zone KEYs at the apex References: <002c01c313cd$88be9280$14370681@lapdancer> From: Simon Josefsson X-Payment: hashcash 1.2 0:030506:scottr@antd.nist.gov:ac8a02c5ef07d201 X-Hashcash: 0:030506:scottr@antd.nist.gov:ac8a02c5ef07d201 X-Payment: hashcash 1.2 0:030506:namedroppers@ops.ietf.org:a946761e3788d48c X-Hashcash: 0:030506:namedroppers@ops.ietf.org:a946761e3788d48c Date: Tue, 06 May 2003 16:01:47 +0200 In-Reply-To: <002c01c313cd$88be9280$14370681@lapdancer> (Scott Rose's message of "Tue, 6 May 2003 08:46:37 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" writes: > The language in the protocol document will remain as is: The document currently says: "All KEY RRs at the zone apex MUST be zone keys." and "Non-zone key KEY RRs MUST NOT appear at delegation names." (Btw, use "delegation point" instead of "delegation name".) > namely, non-zone KEY RRs SHOULD NOT be placed in the zone apex, but > are not expressly forbidden. There is no consensus to make this a > more stringent restriction ("SHOULD NOT/MUST NOT"). The view seems > to be that there is no harm in having non-zone DNSSEC keys at the > apex as part of the KEY RR set. > > There may be some benefit to allowing them and no really reason to make the > language read "MUST NOT be placed at the zone apex". Introducing either "SHOULD NOT" or "MUST NOT" is a change from RFC 2535, which allowed non-zone keys at the apex. I don't see consensus for any of them, rather the contrary. Consider a department, example.org, which runs DNS for people in the department. However, one machine is run by a person with DNS clue, so they delegate host.example.org to his machine. Now, this person may want to publish a SIG(0) for his host, to enable zone transfers from his machine, but the current document forbids this (MUST NOT) and your suggestion (SHOULD NOT) suggests this is a bad idea. Recall that 2119 defines SHOULD NOT == NOT RECOMMENDED. If there really has to be a 2119 statement about this, use MAY, which is consistent with RFC 2535. -- 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 May 6 10:28:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24248 for ; Tue, 6 May 2003 10:28:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D3NJ-000Ni9-00 for namedroppers-data@psg.com; Tue, 06 May 2003 14:24:57 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19D3NG-000Ngv-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 14:24:54 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 190F21390E for ; Tue, 6 May 2003 14:24:41 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: proposed definition for the NXT In-Reply-To: Message from Edward Lewis of "Tue, 06 May 2003 08:52:40 -0400." X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 06 May 2003 14:24:41 +0000 Message-Id: <20030506142441.190F21390E@sa.vix.com> X-Spam-Status: No, hits=-11.8 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm proposing this for the NXT in the DNSSECbis document... > > After properly validating the NXT's authenticity: > > If the NXT-position bit is 1, then the NXT is processed as per RFC 2535 > or the DS RR (I don't recall any difference). > > If the bit is 0, then the verifier treats the zone as unsigned, > ergo, all the subzones are unsigned. (Yeah, yeah, secure entry > points, yadda, yadda.) at first glance, i like this approach. > (See note 1 below.) ... > Note 1 - Yes, any '0' bit in the NXT will make the resolver see the whole > zone as unsigned - for the duration of the query at least, at most the ttl > of the NXT it is looking at. The burden is not on the resolver to seek out > all the NXT's and look for '0' bits, but only if the query stumbles on it. > Treating the zone as unsigned means ignoring any DS records, KEY records, > SIG records, NXT records, etc. By tainting the whole zone you "punish" the > operator for doing this on the large scale, if that is your desire. I > think just treating spans of the zone as unsigned would be an over > complication and too much like the current opt-in. Perhaps we should > always require a server to load only zones that have one kind of NXT - with > the 1 or with the 0, and no combinations. This will make it easier to > decide of a zone is doing funny stuff. since it's unenforceable, let's not specify that. that is, your rule about interpreting a "0" bit is the same thing, and would have to be done no matter what requirements were stated for zone operators. so let's just note that so that zone operators can understand that the significance of a single "0" bit is the same, to what you're calling 2535-style (but is really DS-style) validators, as if all NXT.maskbit(NXT)'s in the zone were zero. if a zone operator wants to mix their 0's and 1's in spite of this notation, then it's possible they'll have a reason they consider good and sufficient. -- 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 May 6 10:43:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24748 for ; Tue, 6 May 2003 10:43:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D3cd-000PtS-00 for namedroppers-data@psg.com; Tue, 06 May 2003 14:40:47 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19D3cZ-000Pst-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 14:40:43 +0000 Received: from lapdancer (gorilla.antd.nist.gov [129.6.55.20]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h46Ee8bd008957; Tue, 6 May 2003 10:40:09 -0400 (EDT) Message-ID: <00bb01c313dc$fbeb2390$14370681@lapdancer> From: "Scott Rose" To: "Simon Josefsson" Cc: References: <002c01c313cd$88be9280$14370681@lapdancer> Subject: Re: Summary: DNSSECbis Q-8: Non zone KEYs at the apex Date: Tue, 6 May 2003 10:37:12 -0400 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 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Simon Josefsson" > "Scott Rose" writes: > > > The language in the protocol document will remain as is: > > The document currently says: > > "All KEY RRs at the zone apex MUST be zone keys." > Changed to "All KEY RRs at the zone apex SHOULD be zone keys." to make the section consistant. > and > > "Non-zone key KEY RRs MUST NOT appear at delegation names." > I think this wording may be murky. I think this might be a left over from 2535/KEY@parent days, but not sure. A KEY RR really should not be placed with the glue records of a delegation, since we are using DS for zone keys, and all other KEY RRs should be at the apex of the delegated zone. Is this the trouble spot? Scott > (Btw, use "delegation point" instead of "delegation name".) > > > namely, non-zone KEY RRs SHOULD NOT be placed in the zone apex, but > > are not expressly forbidden. There is no consensus to make this a > > more stringent restriction ("SHOULD NOT/MUST NOT"). The view seems > > to be that there is no harm in having non-zone DNSSEC keys at the > > apex as part of the KEY RR set. > > > > There may be some benefit to allowing them and no really reason to make the > > language read "MUST NOT be placed at the zone apex". > > Introducing either "SHOULD NOT" or "MUST NOT" is a change from RFC > 2535, which allowed non-zone keys at the apex. I don't see consensus > for any of them, rather the contrary. > > Consider a department, example.org, which runs DNS for people in the > department. However, one machine is run by a person with DNS clue, so > they delegate host.example.org to his machine. Now, this person may > want to publish a SIG(0) for his host, to enable zone transfers from > his machine, but the current document forbids this (MUST NOT) and your > suggestion (SHOULD NOT) suggests this is a bad idea. Recall that 2119 > defines SHOULD NOT == NOT RECOMMENDED. > > If there really has to be a 2119 statement about this, use MAY, which > is consistent with RFC 2535. -- 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 May 6 12:06:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27413 for ; Tue, 6 May 2003 12:06:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D4vY-000C3z-00 for namedroppers-data@psg.com; Tue, 06 May 2003 16:04:24 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19D4vS-000C39-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 16:04:19 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEH007133BRXD@eListX.com> for namedroppers@ops.ietf.org; Tue, 06 May 2003 12:04:40 -0400 (EDT) Received: from hlid.dc.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h46FxLQY085457; Tue, 06 May 2003 11:59:21 -0400 (EDT envelope-from ogud@ogud.com) Received: from localhost (ogud@localhost) by hlid.dc.ogud.com (8.12.3p2/8.12.3/Submit) with ESMTP id h46FxKjJ085454; Tue, 06 May 2003 11:59:20 -0400 (EDT) Date: Tue, 06 May 2003 11:59:20 -0400 (EDT) From: Olafur Gudmundsson Subject: Re: DS-13: record ordering In-reply-to: X-X-Sender: ogud@hlid.dc.ogud.com To: Sam Weiler Cc: namedroppers@ops.ietf.org Message-id: <20030506115706.W85388@hlid.dc.ogud.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: X-Authentication-warning: hlid.dc.ogud.com: ogud owned process doing -bs X-Spam-Status: No, hits=-32.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 11 Mar 2003, Sam Weiler wrote: > DS-13 section 2.2 says "...MUST include the following RRsets ... in > this order..." Does the order really matter? Is there something that > will break if they're reordered? Should the "in this order" be > dropped? > No, this is to protect old resolvers, they see NS before DS. We had some experiance with this when NXT was originally introduced, in order to not kill old resolvers the NXT had to have a SOA in the Authority section. The SOA is redundant to the resolvers that understand NXT. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 6 12:06:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27428 for ; Tue, 6 May 2003 12:06:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D4sc-000BMt-00 for namedroppers-data@psg.com; Tue, 06 May 2003 16:01:22 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19D4sV-000BJW-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 16:01:15 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HEH0073436NA3@eListX.com> for namedroppers@ops.ietf.org; Tue, 06 May 2003 12:01:35 -0400 (EDT) Received: from hlid.dc.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h46FuGQY085448; Tue, 06 May 2003 11:56:17 -0400 (EDT envelope-from ogud@ogud.com) Received: from localhost (ogud@localhost) by hlid.dc.ogud.com (8.12.3p2/8.12.3/Submit) with ESMTP id h46FuGc4085445; Tue, 06 May 2003 11:56:16 -0400 (EDT) Date: Tue, 06 May 2003 11:56:16 -0400 (EDT) From: Olafur Gudmundsson Subject: Re: comments on ds-13 In-reply-to: <20030312193746.C6ECF379EF4@as.vix.com> X-X-Sender: ogud@hlid.dc.ogud.com To: Paul Vixie Cc: namedroppers@ops.ietf.org Message-id: <20030506115210.A85388@hlid.dc.ogud.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <20030312193746.C6ECF379EF4@as.vix.com> X-Authentication-warning: hlid.dc.ogud.com: ogud owned process doing -bs X-Spam-Status: No, hits=-33.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 12 Mar 2003, Paul Vixie wrote: > > The robustness principal probably applies here. > > i'm sure it does but i think i interpret it in the opposite way. > > > DS is a DNS infrastructure RR type, we know of no useful purpose that > > DS RRs anywhere other than at delegation points would serve, and at > > least some of us think that reusing existing RR types for > > fundamentally different purposes is a risky thing to do > > others of us think that putting in feel-good restrictions whose implementation > status is unlikely to be rigourously tested (either for operability reasons or > interoperability reasons) ultimately does no good (ever) and some harm (often). > > > ... therefore: > > > > a) Zones either SHOULD NOT or MUST NOT include DS RRs anywhere but at > > delegation points; > > > > b) Software MUST cope if a zone violates (a). > > > > I tend to think that (a) should be MUST NOT, on the grounds that it > > probably simplifies the implementation of (b) slightly (software must > > not fall on its face, full stop, but don't expect an implementation to > > do anything useful with a non-delegation DS RR). > > i humbly disagree. we should define what we mean and say that other uses are > undefined. if we some day think of a reason to use these at non-delegation > points, it'll be wonderful to know that authority servers (both master and > slave) and caching forwarders are willing to pass the data through even though > they have reason to believe that it wasn't at a delegation point. As you ask for a reason why I will not make the change. I worry about allowing DS at non delegation will/may cause similar harm as DNAME creating delegations that are only reachable via the DNAME chain. Thus the text in DS-14 will be unchanged. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 6 13:07:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29643 for ; Tue, 6 May 2003 13:07:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D5o2-000HnU-00 for namedroppers-data@psg.com; Tue, 06 May 2003 17:00:42 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19D5o0-000Hmr-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 17:00:40 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 918671390E for ; Tue, 6 May 2003 17:00:27 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: comments on ds-13 In-Reply-To: Message from Olafur Gudmundsson of "Tue, 06 May 2003 11:56:16 -0400." <20030506115210.A85388@hlid.dc.ogud.com> X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 06 May 2003 17:00:27 +0000 Message-Id: <20030506170027.918671390E@sa.vix.com> X-Spam-Status: No, hits=-13.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... disagree. we should define what we mean and say that other uses > > are undefined. if we some day think of a reason to use these at > > non-delegation points, it'll be wonderful to know that authority > > servers (both master and slave) and caching forwarders are willing > > to pass the data through even though they have reason to believe > > that it wasn't at a delegation point. > > As you ask for a reason why I will not make the change. > I worry about allowing DS at non delegation will/may cause similar > harm as DNAME creating delegations that are only reachable via the > DNAME chain. > > Thus the text in DS-14 will be unchanged. that's good news. for the record, non-delegation DS RR's might be part of an "islands of security" proposal i'm doodling. i'm not sure how realistic the "dnssec in 2003" plan is any more, but it may require that authentication not follow delegation chains. knowing that a DS RR that's not at a delegation point won't be considered a protocol or data error might be very helpful. -- 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 May 6 13:29:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00453 for ; Tue, 6 May 2003 13:29:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D6An-000K1A-00 for namedroppers-data@psg.com; Tue, 06 May 2003 17:24:13 +0000 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 19D6Aj-000K0t-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 17:24:09 +0000 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h46HO2B4005589 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 6 May 2003 19:24:03 +0200 To: "Scott Rose" Cc: Subject: Re: Summary: DNSSECbis Q-8: Non zone KEYs at the apex References: <002c01c313cd$88be9280$14370681@lapdancer> <00bb01c313dc$fbeb2390$14370681@lapdancer> From: Simon Josefsson X-Payment: hashcash 1.2 0:030506:scottr@antd.nist.gov:50786cd42472b78e X-Hashcash: 0:030506:scottr@antd.nist.gov:50786cd42472b78e X-Payment: hashcash 1.2 0:030506:namedroppers@ops.ietf.org:542f059d797df78a X-Hashcash: 0:030506:namedroppers@ops.ietf.org:542f059d797df78a Date: Tue, 06 May 2003 19:24:02 +0200 In-Reply-To: <00bb01c313dc$fbeb2390$14370681@lapdancer> (Scott Rose's message of "Tue, 6 May 2003 10:37:12 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" writes: > ----- Original Message ----- > From: "Simon Josefsson" > >> "Scott Rose" writes: >> >> > The language in the protocol document will remain as is: >> >> The document currently says: >> >> "All KEY RRs at the zone apex MUST be zone keys." >> > > Changed to "All KEY RRs at the zone apex SHOULD be zone keys." to make the > section consistant. I must be unclear, let me reiterate: I object to any restriction (in the DNS protocol) of the kind of KEY RRs allowed at the zone apex. As I understand RFC 2535, there is no restriction of the kind of KEY RRs allowed at zone apex nor delegation points. Thus, adding SHOULD/MUST requirements to the DNSSEC rewrite should only be done after consensus, if I understand the process of the rewrite correctly. What I've been asking for is if there is consensus about this. Edward answered that question (thanks!) but pointed at this thread only, and I don't see consensus about adding MUST/SHOULD here. >> and >> >> "Non-zone key KEY RRs MUST NOT appear at delegation names." >> > I think this wording may be murky. I think this might be a left over from > 2535/KEY@parent days, but not sure. A KEY RR really should not be placed > with the glue records of a delegation, since we are using DS for zone keys, > and all other KEY RRs should be at the apex of the delegated zone. _Why_ shouldn't they? If you believe they shouldn't be permitted, I'd like to see the explaination. I'm looking for more than your yes/no opinion. The current document says they add processing time, but this is false (the wasteful IF statement must be present for security reasons). I can only see operational considerations that may justify adding this restriction, such as size/roundtrip/cachesize that Edward mentioned. But that belong in an operational document, not in the protocol definition. The DNS protocol should be applicable to more than the public Internet. -- 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 May 6 15:38:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05704 for ; Tue, 6 May 2003 15:38:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D88g-000EuN-00 for namedroppers-data@psg.com; Tue, 06 May 2003 19:30:10 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19D88c-000Etg-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 19:30:06 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h46JTibd013545 for ; Tue, 6 May 2003 15:29:44 -0400 (EDT) Message-ID: <001701c31405$d94e3880$b9370681@barnacle> From: "Scott Rose" To: Subject: REOPEN: DNSSECbis-Q-8: non-zone KEY RRs at apex Date: Tue, 6 May 2003 15:29:44 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This matter is still open. Taking Simon Josefsson's comments: Q: Should the language in Section 2 of the protocol draft allow non-zone KEY RRs at a zone's apex? Discussion: Section 2 of the protocol draft states: "Other public keys associated with other DNS operations can be stored in KEY RRs that are not marked as zone keys. Non-zone key KEY RRs MUST NOT appear at delegation names. Non-zone key KEY RRs also SHOULD NOT appear at the zone apex, because large KEY RRsets add processing time at resolvers. Non-zone key KEY RRs MAY appear at any other name in the zone. " However, there is no clear documentation as to where this was updated from RFC 2535 before. RFC 3445 (Restrict KEY) only restricts KEY to DNSSEC protocol uses, but not their location. This was present in -00 version of draft and unmentioned until recently on namedroppers. Should the wording be changed to say that "non-zone KEY RRs MAY appear at a zone apex"? NOTE: This discussion should be restricted to the apex. Restricting/allowing KEY RRs at delegation points will be the subject of a different discussion thread. Scott -- 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 May 6 18:51:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13152 for ; Tue, 6 May 2003 18:51:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DBBm-0004Hp-00 for namedroppers-data@psg.com; Tue, 06 May 2003 22:45:34 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19DBBj-0004HX-00 for namedroppers@ops.ietf.org; Tue, 06 May 2003 22:45:31 +0000 Received: by sentry.rv.nailabs.com; id SAA21174; Tue, 6 May 2003 18:46:41 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma021162; Tue, 6 May 03 18:46:08 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6/8.11.6) with ESMTP id h46MitK14402; Tue, 6 May 2003 18:44:55 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Tue, 6 May 2003 18:44:55 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Edward Lewis cc: namedroppers Subject: Re: chairs' message on opt-in In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_PINE, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 5 May 2003, Edward Lewis wrote: > (Especially here, where there's no consensus for opt-in, no consensus > against opt-in, just no consensus yet, as far as I can tell from the > chairs' message.) Independent of the working group's (lack of) consensus, the IETF process on opt-in hasn't finished. For AD/IESG/IAB appeals to be meaningful, we have to retain the ability to implement what is decided, which may include adding opt-in. Unlike adding new RR types and many other DNS changes, opt-in is not backward compatible -- a non-opt-in resolver should refuse an opt-in (unsigned, unsecure) referral. If enough of those resolvers get deployed, then opt-in is dead in the water, and the remaining IETF process becomes irrelevant. In keeping with the grand tradition of "be liberal in what you accept", the safe course of action is to include something that is forward-compatible with opt-in. Ed's on the right track, but architecting that change is likely to take a while. I'd rather just require that clients that understand DS and the new type codes also have opt-in support, at least for the time being. It's already been implemented and tested extensively -- we know it works, and while it adds (minimal) complexity, it does not impact security unless zones are signed with opt-in. Anything else done to make the existing protocol forwarders-compatible is likely to be just as complex and require new work. And if/when we reach consensus that opt-in is bad, we can remove the resolver support. This keeps the door open for opt-in and allows client code to ship today (or as soon as DS and the type code roll advance), which satisfies my top goal: rapid deployment. The alternatives are shipping code that doesn't allow for opt-in at all, which slams the door on the appeals process, or holding off on shipping code until the process concludes, which I REALLY don't want. Yes, this is an opt-in opponent saying "any clients that ship today need to have opt-in support". Given that the process hasn't concluded, I think that's the only safe way to move forward. -- 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 May 6 21:59:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17524 for ; Tue, 6 May 2003 21:59:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DE7m-0002RW-00 for namedroppers-data@psg.com; Wed, 07 May 2003 01:53:38 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19DE7j-0002OJ-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 01:53:35 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h471qsab069775; Wed, 7 May 2003 11:52:54 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h471qq1G041166; Wed, 7 May 2003 11:52:53 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305070152.h471qq1G041166@drugs.dv.isc.org> To: Olafur Gudmundsson Cc: Sam Weiler , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DS-13: record ordering In-reply-to: Your message of "Tue, 06 May 2003 11:59:20 -0400." <20030506115706.W85388@hlid.dc.ogud.com> Date: Wed, 07 May 2003 11:52:52 +1000 X-Spam-Status: No, hits=-12.6 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > On Tue, 11 Mar 2003, Sam Weiler wrote: > > > DS-13 section 2.2 says "...MUST include the following RRsets ... in > > this order..." Does the order really matter? Is there something that > > will break if they're reordered? Should the "in this order" be > > dropped? > > > > No, this is to protect old resolvers, they see NS before DS. How does this protect them? > We had some experiance with this when NXT was originally introduced, > in order to not kill old resolvers the NXT had to have a SOA in > the Authority section. The SOA is redundant to the resolvers that > understand NXT. It is the presence of the SOA record not the order that was important here. Remember that you got DNSSEC style answers initially regardless of whether you requested them or not. > Olafur -- Mark Andrews, Internet Software Consortium 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 Tue May 6 23:06:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18670 for ; Tue, 6 May 2003 23:06:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DFDd-00070a-00 for namedroppers-data@psg.com; Wed, 07 May 2003 03:03:45 +0000 Received: from gro.dd.org ([209.198.103.200]) by psg.com with esmtp (Exim 3.36 #1) id 19DFDT-000705-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 03:03:35 +0000 Received: by gro.dd.org (Postfix, from userid 102) id 8655F44; Tue, 6 May 2003 23:03:34 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16056.30598.465972.115213@gro.dd.org> Date: Tue, 6 May 2003 23:03:34 -0400 From: tale@nominum.com (David C Lawrence) To: Subject: Re: REOPEN: DNSSECbis-Q-8: non-zone KEY RRs at apex In-Reply-To: <001701c31405$d94e3880$b9370681@barnacle> References: <001701c31405$d94e3880$b9370681@barnacle> X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose writes: > Should the wording be changed to say that "non-zone KEY RRs MAY appear at a > zone apex"? I'm in favour of this change. Outlawing it is an unnecessary restriction of extremely little practical benefit. -- 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 May 6 23:44:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19256 for ; Tue, 6 May 2003 23:44:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DFmb-0009d6-00 for namedroppers-data@psg.com; Wed, 07 May 2003 03:39:53 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19DFlw-0009YM-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 03:39:12 +0000 Received: by shell.nominum.com (Postfix, from userid 1411) id 0AFAB137F15; Tue, 6 May 2003 20:39:11 -0700 (PDT) To: namedroppers@ops.ietf.org Subject: draft-lewis-dns-wildcard-clarify-00.tx and DNSSEC From: Bob Halley Date: 06 May 2003 20:39:11 -0700 Message-ID: Lines: 219 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_20,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk INTRODUCTION I read draft-lewis-dns-wildcard-clarify-00.txt and was very intrigued by the idea of using the "closest encloser" in DNSSEC wildcard proofs, but I didn't think that the draft established a critical thing, namely: How do you know, and (more importantly) *prove* using NXT records, what the closest encloser of a given QNAME is? This paper aims to answer that question. Because security is involved, I have tried to be fairly rigorous in my proof below. SOME BACKGROUND We'd like to have empty nonterminals provably exist in secure zones. In other words, if someone has: a.b.c 3600 IN A 10.0.0.1 in their zone, but does not have any records with owner names "c" or "b.c", we'd like to be able to say (with proof) that "nodes 'c' and 'b.c' exist and yet have no RRs." We want this because it is the behavior mandated by the nameserver algorithm in section 4.3.2 of RFC 1034, and because it is regarded by most as a better, more "natural" behavior than the alternative of treating such empty nonterminals as being nonexistent. There are two ways to achieve this. One way is to instantiate all the implied empty nonterminals, and then add NXT and SIG(NXT) to them. This works, but is a burden to the server in storage and computation resources. It especially complicates updates, since any deletion of the last record at a node necessitates a computation to determine which empty nonterminals are no longer relevant and thus must also be deleted. The second way is to infer the existence of the empty nonterminals from the names of the nodes with real data (i.e. the names in the NXT chain). Using this technique, the "deepest existing ancestor" a.k.a. the "most enclosing name" of any query name Q can be easily found, and proved to exist. This allows great efficiency in the wildcard matching algorithm as well, since only one wildcard possibility exists and must subsequently be either proven to exist or proven not to exist. This is a big improvement on the "empty non-terminals do not exist" approach, which has many more possible candidate wildcard names which must be proven not to exist. DEFINITIONS AND PRELIMINARIES When we say "subdomain" anywhere below, we mean "is contained within the domain (in the sense that RFC 1034 describes), or is equal to the domain". I.e., we're treating it like "subset" in mathematics. X is a "superdomain" of Y iff. Y is a subdomain of X. A name is an "owner name in zone Z" if it is an owner name, is a subdomain of the origin of zone Z, and is not glue (or otherwise beneath a zone cut of zone Z). A name N is "directly in zone Z" iff. there is some owner name in Z equal to N. A name N is "inferred to be in zone Z", if it is not directly in zone Z, but is a superdomain of some direct name of Z and is still a subdomain of Z. I.e., it is an "empty nonterminal" required to make the path from the zone origin to some name directly in Z. A name is "in zone Z" if it is directly in zone Z, or is inferred to be in zone Z. Let "<" denote the DNSSEC name order relation. The "greatest common superdomain" of names A and B, denoted GCS(A,B), is the greatest (according to the DNSSEC ordering) name X such that X is a superdomain of both A and B. I.e. it is the "deepest common ancestor" of A and B. GCS(A,B) always exists, because the root name is a superdomain of all names. Let Q be a name which is a subdomain of the origin of zone Z. BOUNDS OF Q IN Z There is always a name directly in Z, call it "GLB(Q,Z)", which is the greatest lower bound of Q. I.e. GLB(Q,Z) <= Q, and for all N in Z where N <= Q, N <= GLB(Q,Z). There may or may not be a name directly in Z, call it "LUB(Q,Z)", which is the least upper bound of Q. If there is no N directly in Z such that N >= Q, then there is no LUB(Q,Z). If there is some N directly in Z where N >= Q, then there is an LUB(Q,Z) >= Q such that if N >= Q, then LUB(Q,Z) <= N. GLB(Q,Z) will have a NXT record which: If GLB(Q,Z) = Q, proves that Q is directly in Z If GLB(Q,Z) != Q, proves that Q is not directly in Z The "next domain name" field of this NXT record is the LUB, unless it is the zone origin (the DNSSEC "end of chain" marker) and Q != the origin of Z, in which case there is no LUB. THEOREM 1: Let A, B, and Q be subdomains of Z. Let A <= B and B <= Q. Then GCS(Q, A) <= GCS(Q, B) Proof: Assume GCS(Q, A) > GCS(Q, B). Then A must have more labels in common with Q than B, but since A and B are less than Q, that means that A > B by the DNSSEC ordering, which is a contradiction since A <= B. THEOREM 2: Let A, B, and Q be subdomains of Z. Let A >= B and B >= Q. Then GCS(Q, A) <= GCS(Q, B) Proof: Assume GCS(Q, A) > GCS(Q, B). Then A must have more labels in common with Q than B, but since A and B are greater than Q, that means that A < B by the DNSSEC ordering, which is a contradiction since A >= B. GREATEST ANCESTOR OF Q IN Z The "greatest ancestor of Q in Z", denoted GA(Q,Z), is the greatest N in Z, directly or inferred, such that Q is a subdomain of N. GA(Q,Z) is also called the "most enclosing name of Q in Z" or the "deepest ancestor of Q in Z". GA(Q,Z) always exists. Since Q is a subdomain of the origin of Z, and the origin of Z is "directly in zone Z", so there's always at least one N in Z such that Q is a subdomain of N. THEOREM 3: Let Q be a subdomain of the origin of zone Z. If LUB(Q,Z) exists, then: GA(Q,Z) = the greater of GCS(Q, GLB(Q,Z)) and GCS(Q, LUB(Q,Z)) otherwise GA(Q,Z) = GCS(Q, GLB(Q,Z)) Proof: We can eliminate the trivial case where Q is directly in Z, since in that case GA(Q,Z) is obviously Q. For notational convenience, let L = GCS(Q, GLB(Q,Z)) U = GCS(Q, LUB(Q,Z)) Assume L and U both exist. Assume there is an M in Z that is greater than both L and U, and is a superdomain of Q. If M is directly in Z, then M > GLB(Q,Z). This is because if M were <= GLB(Q,Z), then GCS(Q,M) would be <= L by Theorem 1. If M is directly in Z, it cannot be >= Q since it is a superdomain of Q and M != Q. So, we have GLB(Q,Z) < M < Q, which implies that GLB(Q,Z) is not the greatest lower bound, which is a contradiction. If M is inferred to be in Z, then there is some N directly in Z and M is a superdomain of N. Either N < Q or N > Q (since Q is not directly in Z). If N < Q, then N > GLB(Q,Z). If N were <= GLB(Q,Z), then the GCS(Q,N) would be <= L by Theorem 1, but GCS(Q,N) = M, and M > L. We thus have a contradiction, since this implies that GLB(Q,Z) is not the greatest lower bound. If N > Q, then N < LUB(Q,Z). If N were >= LUB(Q,Z), then the GCS(Q,N) would be <= U by Theorem 2, but GCS(Q,N) = M, and M > U. We thus have a contradiction, since this implies that LUB(Q,Z) is not the least upper bound. Now we deal with the case where U doesn't exist. Again, assume M in Z that is greater than L, and is a superdomain of Q. The cases where M is directly in Z, or where M is inferred and N < Q are as above. Now we deal with the case where N > Q. First we note that since < is a well-ordering of the names in Z, if there are any upper bounds to Q in Z, then there must be a least upper bound. Now, if N existed, it would be an upper bound of Q in Z, and hence a least upper bound would have to exist, but there is no least upper bound of Q in Z by assumption, so we again have a contradiction. Q.E.D. CONCLUSION We've shown how to find the "closest encloser" of any given QNAME by looking at the QNAME along with the owner name and "next domain name" field of the NXT record which proves the QNAME doesn't exist. The technique works even when the closest encloser is an inferred name. Knowing the closest encloser lets us do very simple wildcard checking in secure zones, since the only possible matching wildcard is *. We simply lookup that name, and if found proceed accordingly, and if not, we add the NXT record which proves it doesn't exist to the authority section. /Bob -- 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 May 7 07:26:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24194 for ; Wed, 7 May 2003 07:26:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DMux-0008Na-00 for namedroppers-data@psg.com; Wed, 07 May 2003 11:16:59 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19DMut-0008NF-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 11:16:55 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23549; Wed, 7 May 2003 07:13:56 -0400 (EDT) Message-Id: <200305071113.HAA23549@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-delegation-signer-14.txt Date: Wed, 07 May 2003 07:13:56 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Delegation Signer Resource Record Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-14.txt Pages : 16 Date : 2003-5-6 The delegation signer (DS) resource record is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and the implications of this record on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC1035, RFC2535, RFC3008 and RFC3090. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-delegation-signer-14.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-delegation-signer-14.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: <2003-5-6153210.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-6153210.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 May 7 08:24:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27522 for ; Wed, 7 May 2003 08:24:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DNst-000Ii2-00 for namedroppers-data@psg.com; Wed, 07 May 2003 12:18:55 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19DNsi-000Ih8-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 12:18:45 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 3B10A35A; Wed, 7 May 2003 08:18:44 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 32824350; Wed, 7 May 2003 08:18:43 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 226339; Tue, 06 May 2003 15:34:06 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <002c01c313cd$88be9280$14370681@lapdancer> <00bb01c313dc$fbeb2390$14370681@lapdancer> Date: Tue, 6 May 2003 15:34:02 -0400 To: Simon Josefsson From: Edward Lewis Subject: Re: Summary: DNSSECbis Q-8: Non zone KEYs at the apex Cc: "Scott Rose" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-26.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>> "Non-zone key KEY RRs MUST NOT appear at delegation names." >>> >> I think this wording may be murky. I think this might be a left over from >> 2535/KEY@parent days, but not sure. A KEY RR really should not be placed >> with the glue records of a delegation, since we are using DS for zone keys, >> and all other KEY RRs should be at the apex of the delegated zone. > >_Why_ shouldn't they? The comment is that the wording is murky. What is a "delegation name?" If it is meant to be "a zone cut," well, there ought to be no keys period at the name - no data except for the DS RR and NXT RR is authoritative there, and the NS RR is just a hint. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 7 08:26:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27646 for ; Wed, 7 May 2003 08:26:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DNsl-000IhP-00 for namedroppers-data@psg.com; Wed, 07 May 2003 12:18:47 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19DNsh-000Igt-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 12:18:43 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 7241634A; Wed, 7 May 2003 08:18:42 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 65E4B2EF; Wed, 7 May 2003 08:18:41 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 226332; Tue, 06 May 2003 15:22:25 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <002c01c313cd$88be9280$14370681@lapdancer> Date: Tue, 6 May 2003 15:21:04 -0400 To: Simon Josefsson From: Edward Lewis Subject: Re: Summary: DNSSECbis Q-8: Non zone KEYs at the apex Cc: "Scott Rose" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:01 +0200 5/6/03, Simon Josefsson wrote: >Consider a department, example.org, which runs DNS for people in the >department. However, one machine is run by a person with DNS clue, so >they delegate host.example.org to his machine. Now, this person may >want to publish a SIG(0) for his host, to enable zone transfers from >his machine, but the current document forbids this (MUST NOT) and your >suggestion (SHOULD NOT) suggests this is a bad idea. Recall that 2119 >defines SHOULD NOT == NOT RECOMMENDED. I'd like to ask about whether SIG(0) can be used to support zone transfers. I've tried to think of a way to get this to work but haven't been successful. BIND doesn't have the ability to do it in any current incarnation. Looking at TSIG zone transfers, the process requires the hard coding of the TSIG secret and name in the configuration file (in situ or via include), instructing the server to only allow transfers signed by the key (by name), and then instructing any transfer request to use the key (by name). The step I want to highlight in the TSIG description is that the servers each must have the shared secret hard coded in their own configuration. For SIG(0), there is a need to transfer the crucial data - the public key - via DNS lookups. What happens if the server slaving the zone has a copy of the zone already and goes to pull the new one - which has unceremoniously rolled the SIG(0) public key? We get stuck... I don't see zone transfer protection via SIG(0) ever being deployable. 'Course I'm wrong a lot, but no one has gotten it to work. Note that zone transfers are not the only use of SIG(0), but I'd like to put zone transfers with it to rest. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 7 08:27:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27729 for ; Wed, 7 May 2003 08:27:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DNsq-000Iho-00 for namedroppers-data@psg.com; Wed, 07 May 2003 12:18:52 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19DNsm-000IhU-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 12:18:48 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 1D4C034F; Wed, 7 May 2003 08:18:48 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 9131835F; Wed, 7 May 2003 08:18:44 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 226465; Tue, 06 May 2003 16:48:35 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <001701c31405$d94e3880$b9370681@barnacle> References: <001701c31405$d94e3880$b9370681@barnacle> Date: Tue, 6 May 2003 16:48:31 -0400 To: "Scott Rose" From: Edward Lewis Subject: Re: REOPEN: DNSSECbis-Q-8: non-zone KEY RRs at apex Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:29 -0400 5/6/03, Scott Rose wrote: >This matter is still open. Taking Simon Josefsson's comments: > >Q: Should the language in Section 2 of the protocol draft allow non-zone >KEY RRs at a zone's apex? The language in 2.1 should not make any restrictions at all on the data being held. (Ref. Mike St. John's message.) In addition, I find a lot of the wording there to be hard to follow. So much so I'm getting a headache trying to comment on it. Perhaps we should start by recognizing the kinds of keys. Zone keys have the zone bit set to 1. All other keys have the zone bit set to 0. This isn't why we call them SIG(0) keys, though, but it might as well be. In fact, there is really no such thing as a SIG(0) key - there are KEY RR's that hold the public component of a key that generated the signature in a SIG RR whose type covered is 0. So it seems to me that there are zone keys, keys that validate sig(0)'s, and useless keys - SIG(0) keys that aren't in use in a SIG(0) RR. I point this out because it is only a bit more precise than "other public keys associated with other DNS operations." I am against requiring that there be a zone key at the apex of a signed zone. (Do we still have the notion of a zone being "signed?") It's possible to configure keys in all relevant resolvers. If there's a parent-held DS RR, why can't a resolver see that and feel justified in using the configured key that is indicated by the DS RR? I can't think of a reason to have tailored restrictions on KEY RR ownership. I can think of reasons to restrict how the keys are used in the validator. That's a different story. >Discussion: > >Section 2 of the protocol draft states: > >"Other public keys associated with other DNS operations can be stored >in KEY RRs that are not marked as zone keys. Non-zone key KEY RRs >MUST NOT appear at delegation names. Non-zone key KEY RRs also >SHOULD NOT appear at the zone apex, because large KEY RRsets add >processing time at resolvers. Non-zone key KEY RRs MAY appear at any >other name in the zone. " > > >However, there is no clear documentation as to where this was updated from >RFC 2535 before. RFC 3445 (Restrict KEY) only restricts KEY to DNSSEC >protocol uses, but not their location. This was present in -00 version of >draft and unmentioned until recently on namedroppers. > >Should the wording be changed to say that "non-zone KEY RRs MAY appear at a >zone apex"? > >NOTE: This discussion should be restricted to the apex. >Restricting/allowing KEY RRs at delegation points will be the subject of a >different discussion thread. > >Scott > > >-- >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-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 7 08:53:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28521 for ; Wed, 7 May 2003 08:53:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DOMa-000ONq-00 for namedroppers-data@psg.com; Wed, 07 May 2003 12:49:36 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19DOMW-000OLd-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 12:49:33 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h47CnEbd026651 for ; Wed, 7 May 2003 08:49:15 -0400 (EDT) Message-ID: <00b701c31497$115b28f0$b9370681@barnacle> From: "Scott Rose" To: References: <002c01c313cd$88be9280$14370681@lapdancer> <00bb01c313dc$fbeb2390$14370681@lapdancer> Subject: Re: Summary: DNSSECbis Q-8: Non zone KEYs at the apex Date: Wed, 7 May 2003 08:49:15 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Edward Lewis" To: "Simon Josefsson" Cc: "Scott Rose" ; Sent: Tuesday, May 06, 2003 3:34 PM Subject: Re: Summary: DNSSECbis Q-8: Non zone KEYs at the apex > >>> "Non-zone key KEY RRs MUST NOT appear at delegation names." > >>> > >> I think this wording may be murky. I think this might be a left over from > >> 2535/KEY@parent days, but not sure. A KEY RR really should not be placed > >> with the glue records of a delegation, since we are using DS for zone keys, > >> and all other KEY RRs should be at the apex of the delegated zone. > > > >_Why_ shouldn't they? > > The comment is that the wording is murky. What is a "delegation name?" > Poor wording choice at the time (but that is the text as it is written for now). I think it should be "delegation point" or "zone cut". Allowing a KEY RR there would get messy. > If it is meant to be "a zone cut," well, there ought to be no keys > period at the name - no data except for the DS RR and NXT RR is > authoritative there, and the NS RR is just a hint. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 7 10:16:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02530 for ; Wed, 7 May 2003 10:15:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DPam-000DAG-00 for namedroppers-data@psg.com; Wed, 07 May 2003 14:08:20 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19DPZc-000D84-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 14:07:08 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 967B0392; Wed, 7 May 2003 10:07:07 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 27E3B38F; Wed, 7 May 2003 10:07:07 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 227317; Wed, 07 May 2003 10:07:03 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 7 May 2003 10:07:02 -0400 To: Bob Halley From: Edward Lewis Subject: Re: draft-lewis-dns-wildcard-clarify-00.tx and DNSSEC Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:39 -0700 5/6/03, Bob Halley wrote: >INTRODUCTION > >I read draft-lewis-dns-wildcard-clarify-00.txt and was very intrigued I've given an update (-01-beta) to the chairs (about two weeks ago) but haven't heard anything recently. (They wanted a review from Paul Mockapetris.) I think I also strengthened what you mention as the weakness, so if the next version appears to have strengthened, it's a coincidence. ;) I really like the text on the first read. If nothing else, what you have here is well suited to be a section unto itself, for those who don't get weak in the knees at the sight of mathematics. If the text I already have written contradicts what's in here, or can be filled in from here, that should happen. One issue, and it's in the vein of "it depends on what is is." >A name N is "directly in zone Z" iff. there is some owner name in >Z equal to N. "In" really is "under the authority of". Probably more significant is another nagging thought of mine. Although you're discussion is right, I had been going to lengths to stress that what is pertinent to the specifications is what is exchanged in the messages and not what is "in" a zone. I got this idea from the word "synthesis" in 1034 when talking about what wild cards. But, still your perspective is important for the proof, which isn't the same as the specification of the protocol. That makes it a valuable addition standing on its own. I don't see anything I'd change in the text, I certainly wouldn't change all the "in"s to the longer phrase. And I wouldn't try to reword it to put it into the protocol perspective. Perhaps, at most, an intro to the text that mentions the shift in perspective. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 7 10:23:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02837 for ; Wed, 7 May 2003 10:23:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DPkO-000FP4-00 for namedroppers-data@psg.com; Wed, 07 May 2003 14:18:16 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19DPjs-000FNl-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 14:17:44 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id DF55A393; Wed, 7 May 2003 10:17:43 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 7C7D7391 for ; Wed, 7 May 2003 10:17:43 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 227348; Wed, 07 May 2003 10:17:40 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 7 May 2003 10:17:34 -0400 To: Edward Lewis From: Edward Lewis Subject: Re: proposed definition for the NXT Cc: namedroppers@ops.ietf.org, Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Since I have proposed this I've had a number of comments come to me. I will post an update sooner or later to address what I consider to be rather constructive comments: 1) Might just want to consider the zone unsigned for the purposes of the current query. 2) Might want to have the same behavior with the SIG bit as it is in the same class as the NXT. 3) My own intention - address what happens if the group decides to roll the type codes. (Not pushing it, but anticipating.) If anyone has any other comments to share, I'll take them into consideration when I send an update to this. (Note: I'm not measuring a consensus here, just making and editing a proposal. The text would go into the DNSSECbis documents.) At 8:52 -0400 5/6/03, Edward Lewis wrote: >I'm proposing this for the NXT in the DNSSECbis document... > > After properly validating the NXT's authenticity: > > If the NXT-position bit is 1, then the NXT is processed as per RFC 2535 > or the DS RR (I don't recall any difference). > > If the bit is 0, then the verifier treats the zone as unsigned, ergo, all > the subzones are unsigned. (Yeah, yeah, secure entry points, yadda, yadda.) > (See note 1 below.) > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 7 13:40:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09645 for ; Wed, 7 May 2003 13:40:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DSkF-0004Co-00 for namedroppers-data@psg.com; Wed, 07 May 2003 17:30:19 +0000 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 19DSkC-0004Am-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 17:30:16 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA12225; Wed, 7 May 2003 11:30:14 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h47HUAL07348; Wed, 7 May 2003 19:30:10 +0200 (MEST) Date: Wed, 7 May 2003 19:28:06 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: chairs' message on opt-in To: Sam Weiler Cc: Edward Lewis , namedroppers In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-11.8 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Yes, this is an opt-in opponent saying "any clients that ship today > need to have opt-in support". Given that the process hasn't > concluded, I think that's the only safe way to move forward. Sam, I'm trying to understand your suggestion. At what point in time do you think we can declare that the process has concluded? AFAIK there isn't a time limit for when an appeal can be filed, and there isn't anything that prevents a WG from changing a previous decision any time it wants to. Erik -- 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 May 7 15:19:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14194 for ; Wed, 7 May 2003 15:19:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DUOF-0003Un-00 for namedroppers-data@psg.com; Wed, 07 May 2003 19:15:43 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19DUNx-0003PX-00 for namedroppers@ops.ietf.org; Wed, 07 May 2003 19:15:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3AF0D1397D; Wed, 7 May 2003 19:15:12 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Erik Nordmark Cc: namedroppers Subject: Re: chairs' message on opt-in In-Reply-To: Message from Erik Nordmark of "Wed, 07 May 2003 19:28:06 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 07 May 2003 19:15:12 +0000 Message-Id: <20030507191512.3AF0D1397D@sa.vix.com> X-Spam-Status: No, hits=-11.8 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk erik, you wrote, in a reply to sam: > At what point in time do you think we can declare that the process has > concluded? when deployment begins. note that as a significant provider of dnssec technology, isc is waiting to hear from some significant potential consumers of dnssec technology, as to whether they're willing to deploy without opt-in. there'd be no use in our shipping technology that folks wouldn't be using. (isc's opt-in position has been neutral except as it relates to deployment.) > AFAIK there isn't a time limit for when an appeal can be filed, and > there isn't anything that prevents a WG from changing a previous > decision any time it wants to. after deployment begins, any appeal will be rendered moot, and this would be just as true had consensus been determinable in favour of opt-in. paul -- 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 May 8 10:00:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22845 for ; Thu, 8 May 2003 10:00:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dlkg-0009QU-00 for namedroppers-data@psg.com; Thu, 08 May 2003 13:48:02 +0000 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 19Dlkc-0009Ki-00 for namedroppers@ops.ietf.org; Thu, 08 May 2003 13:47:58 +0000 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.3) with ESMTP id h48DluXa014198 for ; Thu, 8 May 2003 16:47:56 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.3) id h48DlusG014194; Thu, 8 May 2003 16:47:56 +0300 Date: Thu, 8 May 2003 16:47:56 +0300 Message-Id: <200305081347.h48DlusG014194@burp.tkv.asdf.org> From: Markku Savela To: namedroppers@ops.ietf.org Subject: Some comments on draft-ietf-dnsext-mdns-18.txt X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In ... > 4. Conflict resolution > ... > Where a host is configured to respond to LLMNR queries on more than > one interface, each interface should have its own independent LLMNR > cache. For each UNIQUE resource record in a given interface's > cache, ... I have a minor problem with the term "cache" in above. Normally, I would associate the term "cache" in connection with resolver as a place to store answers to the queries this node has sent. (And when a node needs resolve some name, it first would check this cache, and only do the real query if answer is not already cached). Above paragraph seems to use "cache" as a place for storing the set RR's "owned" by this node. A real recursive DNS server might use cached values in answering queries, but the LLMNR only answers for explicitly configured names, never for anything it has cached as a result of a query. Confused me, at least on first reading. Could perhaps read: Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR configuration. For each UNIQUE resource record in a given interface's configuration, the host MUST verify resource record uniqueness on that interface.... > 4.1. Considerations for Multiple Interfaces > ... > ---------- ---------- > | | | | > [A] [myhost] [A] > > > Figure 2. Off-segment name conflict > If host myhost is configured to use LLMNR on both interfaces, it > will send LLMNR queries on both interfaces. When host myhost sends > a query for the host RR for name "A" it will receive a response from > hosts on both interfaces. > > Host myhost will then forward a response from the first responder to > the second responder, who will attempt to verify the uniqueness of > host RR for its name, but will not discover a conflict, since the > conflicting host resides on a different link. Therefore it will > continue using its name. I think the latter paragraph may be misleading, at least on first reading I was startled: "Am I supposed to do conflict resolution across interfaces!!?" If LLMNR can detect it, it should not do any forwarding, if responces come from different interfaces. (E.g. in above case, "clever" LLMNR at "myhost" would not forward the responce!). -- 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 May 8 10:02:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22969 for ; Thu, 8 May 2003 10:02:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DlmM-0009ZO-00 for namedroppers-data@psg.com; Thu, 08 May 2003 13:49:46 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19DlmA-0009YD-00 for namedroppers@ops.ietf.org; Thu, 08 May 2003 13:49:35 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 7EB3C31A; Thu, 8 May 2003 09:49:34 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 305E2318 for ; Thu, 8 May 2003 09:49:34 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 228676; Thu, 08 May 2003 09:49:27 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 8 May 2003 09:49:27 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: request to move opt-in to experimental Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_01,OPT_IN,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'd like to raise the issue of moving the following document to experimental: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt I'm just throwing out the suggestion, based on what was in the "chair's message on opt-in". Would making opt-in experimental be desirable? Should the WG approach the chairs and request this? (I'm not even a person with an opinion on opt-in, much less a proponent. It just seems to me that the comments indicate that this should be experimental.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 8 10:03:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23119 for ; Thu, 8 May 2003 10:03:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DlmE-0009Yf-00 for namedroppers-data@psg.com; Thu, 08 May 2003 13:49:38 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19DlmA-0009YC-00 for namedroppers@ops.ietf.org; Thu, 08 May 2003 13:49:34 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 04A45316; Thu, 8 May 2003 09:49:34 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 65853312 for ; Thu, 8 May 2003 09:49:33 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 228675; Thu, 08 May 2003 09:49:26 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 8 May 2003 09:44:50 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: revised proposal for defining the NXT Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_01,OPT_IN,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This proposal is intended to fit into the appropriate DNSSEC document as part of the definition of the NXT record. The motivation for this proposal is buried in the opt-in discussion, but the proposal is not centered around the promotion or dismissal of the opt-in proposal. The philosophical underpinning of this proposal is based on the observation that the NXT RR, which needs the SIG RR to have any meaning, could claim that it itself and or the accompanying SIG RR (set) does not exist. This would qualify as a "silly state." Furthermore, there is a sound reason to define the reaction to the resolver or verifier to the possibility of such a "silly state" and this proposal chooses one. (Silly = saying that I don't exist, or that the one who is needed to vouch for my existence doesn't exist.) This proposal is informal, it is not cast into RFC 2119 language to reinforce the need for discussion on this. First rule. (Speaker-side) A compliant signing application will always set the values of the NXT and SIG positions of the NXT RR type code bit map to 1. This silly state is not to be seen in normal protocol operations. (Nor are any others, but that's not my concern right now.) Second rule. (Listener-side) When a verifier sees 1's in BOTH the NXT and SIG positions, processing of the NXT follows the stated rules as we have already documented them. When a verifier sees a 0 in EITHER the NXT OR the SIG positions, the verifier will take corrective action. This proposal recommends the following action be specified as a MUST: the verifier will first validate the NXT according to local policy, with the intent that the presence of the DS RR at the parent points eventually to a zone key that verifies the SIG (NXT). Once the NXT is proven valid, the verifier then treats the remainder of the query as if the DS RR did not exist - essentially treating the query as traversing through or being answered from an unsigned zone. Into the Future. If the type codes for NXT and SIG are changed, the rules for the bits move with the type codes. I.e., if, say, an NXTbis RR is used to prove non-existence, then the NXTbis position has this special meaning AND NOT the NXT position. I.e., we are only protecting against silly states, not creating flags in the NXT bit map. Discussion. There are four options I have considered for a reaction to a silly state NXT. One is to "fall back" to unsecured DNS, which is what I have chosen to propose. The rationale is that this permits enhancements to happen, if they prove to be beneficial. I did not pick this because it resembles opt-in, as some have noted. Although it resembles opt-in, it is not opt-in as that has more rules and considerations to follow. I.e., this proposal does not cover the rules of generating silly state NXT's - they are forbidden in the First Rule. The other three options are: 2) (1 is the above) Instruct the verifier to ignore the bit positions NXT and SIG. This is viable, two less bit tests, but obviates any chance of making use of these bits as a means to experiment. 3) Instruct the resolver to treat the silly state as a resource record format error. This kind of response will cut off the network anyone trying to experiment. 4) Not issue any statement on the silly state reaction. Because of the First Rule, there really isn't an immediate interoperability rule, but by allowing implementers to not respond in a harmonious way, interoperability into the future is endangered. Aside. Case 4 is already used in 2535 - the 0th bit position is used to define an unspecified new format for the NXT bitmap. A 1 there is a declared silly state (the opposite value of the 0's for the NXT and SIG silly states). Perhaps we should also specify some standard melt down for the time being. Perhaps not the same - but we should make sure that implementers don't vary in undesirable ways. PS - thanks to the bunch of folks that have replied to me privately on this. But, please, let's keep the discussion on namedroppers - my finger hurt from replying to so many contributors...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 8 11:16:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26218 for ; Thu, 8 May 2003 11:16:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dn3L-000KVh-00 for namedroppers-data@psg.com; Thu, 08 May 2003 15:11:23 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19Dn3I-000KVV-00 for namedroppers@ops.ietf.org; Thu, 08 May 2003 15:11:20 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h48F9wpo004329; Thu, 8 May 2003 11:11:16 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h48F6D9O001433; Thu, 8 May 2003 11:07:18 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h48F4pU8003873; Thu, 8 May 2003 11:04:51 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id LAA09694; Thu, 8 May 2003 11:04:51 -0400 (EDT) To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: revised proposal for defining the NXT References: Date: 08 May 2003 11:04:51 -0400 In-Reply-To: Message-ID: Lines: 54 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-35.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > When a verifier sees a 0 in EITHER the NXT OR the SIG positions, the > verifier will take corrective action. This proposal recommends the > following action be specified as a MUST: the verifier will first > validate the NXT according to local policy, with the intent that the > presence of the DS RR at the parent points eventually to a zone key > that verifies the SIG (NXT). Once the NXT is proven valid, the > verifier then treats the remainder of the query as if the DS RR did > not exist - essentially treating the query as traversing through or > being answered from an unsigned zone. This is problematic. Unless I misunderstand you, this would imply that a silly-state NXT could potentially invalidate a DS handoff to a secure zone. I don't think that's what you want to happen. If you have an NXT with the DS and NS bits set, why should you ignore the DS? The issue here is more than just the bits in the NXT bitmap, but also the name of the NXT record. If the name of the DS and NXT matches, then you should NOT ignore the DS. Indeed, if the QNAME matches, you should probably treat the silly-state NXT as a normal NXT. The only time you should treat a silly-state NXT differently is if the name of the NXT != name of the query (or other responses). To give a concrete example, suppose I make a query for a.example.com and I get back: a.example.com ns ... ds ... sig(ds) nxt b.example.com ... sig(nxt) Clearly you should NOT ignore the DS in this case, regardless of the silly-state of the NXT. However, if I make the same query and I get back: a.example.com ns ... ds ... example.com nxt b.example.com ... sig(nxt) now we've got a condition where a silly-state NXT matters. In this case, a silly-state NXT should fall back to client policy in terms of whether to ignore the NS, ignore the DS, or ignore the whole response. But I think you need to be clear about silly-state and the node names. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 8 12:02:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28072 for ; Thu, 8 May 2003 12:02:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dni6-0000wZ-00 for namedroppers-data@psg.com; Thu, 08 May 2003 15:53:30 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19Dni3-0000w8-00 for namedroppers@ops.ietf.org; Thu, 08 May 2003 15:53:27 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 31CB438F; Thu, 8 May 2003 11:53:27 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id A915F380; Thu, 8 May 2003 11:53:26 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 240071; Thu, 08 May 2003 11:53:24 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 8 May 2003 11:53:24 -0400 To: Derek Atkins From: Edward Lewis Subject: Re: revised proposal for defining the NXT Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:04 -0400 5/8/03, Derek Atkins wrote: >This is problematic. Unless I misunderstand you, this would imply >that a silly-state NXT could potentially invalidate a DS handoff to a >secure zone. That's exactly what I am proposing, within some conditions. 1) The NXT has to be valid, so no one is slipping in an invalid NXT to downgrade the security. 2) The NXT has to be pertinent to the query. That is part of the following local policy. > I don't think that's what you want to happen. If you >have an NXT with the DS and NS bits set, why should you ignore the DS? Remember that by the first rule, if the silly state appears, we are essentially in an error condition. When you are in an error condition, you do what you need to handle it. My proposal is to assume pre-DNSSEC DNS semantics, as they are already understood. >The issue here is more than just the bits in the NXT bitmap, but also >the name of the NXT record. If the name of the DS and NXT matches, >then you should NOT ignore the DS. Indeed, if the QNAME matches, you >should probably treat the silly-state NXT as a normal NXT. The only >time you should treat a silly-state NXT differently is if the name of >the NXT != name of the query (or other responses). I assume that a valid NXT is an NXT that is pertinent to the query triplet, along with all the other checks. > >To give a concrete example, suppose I make a query for a.example.com >and I get back: When you give an example for a query, please include the QTYPE along with the QNAME. (We can assume QCLASS for the most part, but we need the QTYPE to know what you seek.) > a.example.com ns ... > ds ... > sig(ds) > nxt b.example.com ... > sig(nxt) > >Clearly you should NOT ignore the DS in this case, regardless of >the silly-state of the NXT. However, if I make the same query and Your point is not obvious from the example. You don't show the values of the bits involved. With out the QTYPE, I can't tell if this is a proper response. >I get back: > > a.example.com ns ... > ds ... > example.com nxt b.example.com ... > sig(nxt) > >now we've got a condition where a silly-state NXT matters. In this >case, a silly-state NXT should fall back to client policy in terms of >whether to ignore the NS, ignore the DS, or ignore the whole response. > Again, without the QTYPE, I can't tell why you would see this under normal protocol operations. >But I think you need to be clear about silly-state and the node names. The NXT has to be pertinent. It will be if the server is following the protocol rules. If the NXT is not pertinent, well, we need to define those semantics anyway. (Where?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 8 13:30:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00917 for ; Thu, 8 May 2003 13:30:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Dp5r-000ExB-00 for namedroppers-data@psg.com; Thu, 08 May 2003 17:22:07 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19Dp5o-000Ewz-00 for namedroppers@ops.ietf.org; Thu, 08 May 2003 17:22:04 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h48HM3m8025344; Thu, 8 May 2003 13:22:03 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h48HM26G024440; Thu, 8 May 2003 13:22:02 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h48HM2U8027677; Thu, 8 May 2003 13:22:02 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id NAA09928; Thu, 8 May 2003 13:22:02 -0400 (EDT) To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: revised proposal for defining the NXT References: Date: 08 May 2003 13:22:01 -0400 In-Reply-To: Message-ID: Lines: 119 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-36.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_NJABL, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 11:04 -0400 5/8/03, Derek Atkins wrote: > >This is problematic. Unless I misunderstand you, this would imply > >that a silly-state NXT could potentially invalidate a DS handoff to a > >secure zone. > > That's exactly what I am proposing, within some conditions. Then I think this is a bad idea. See below... > 1) The NXT has to be valid, so no one is slipping in an invalid NXT to > downgrade the security. > > 2) The NXT has to be pertinent to the query. That is part of the > following local policy. > > > I don't think that's what you want to happen. If you > >have an NXT with the DS and NS bits set, why should you ignore the DS? > > Remember that by the first rule, if the silly state appears, we are > essentially in an error condition. When you are in an error > condition, you do what you need to handle it. My proposal is to > assume pre-DNSSEC DNS semantics, as they are already understood. And I disagree with this, specifically because it disallows opt-in. Note that I'm not an opt-in proponent either, but following this strategy means that you can't experiment with opt-in... Let me restate my examples. > >The issue here is more than just the bits in the NXT bitmap, but also > >the name of the NXT record. If the name of the DS and NXT matches, > >then you should NOT ignore the DS. Indeed, if the QNAME matches, you > >should probably treat the silly-state NXT as a normal NXT. The only > >time you should treat a silly-state NXT differently is if the name of > >the NXT != name of the query (or other responses). > > I assume that a valid NXT is an NXT that is pertinent to the query > triplet, along with all the other checks. Can you define what you mean by "pertinent to the query triplet"? > >To give a concrete example, suppose I make a query for a.example.com > >and I get back: > > When you give an example for a query, please include the QTYPE along > with the QNAME. (We can assume QCLASS for the most part, but we need > the QTYPE to know what you seek.) *grumble* I think it's unimportant (I don't see why it matters if I'm asking for A, AAAA, AFSDB, IPSECKEY, or whatever...) but fine, I'll humor you. Can we at least assume class IN? Query: a.example.com. A Answer: a.example.com. ns ... ds ... sig(ds) nxt b.example.com ... sig(nxt) > > Your point is not obvious from the example. You don't show the values > of the bits involved. With out the QTYPE, I can't tell if this is a > proper response. It doesn't matter what the QTYPE is; if I get this response back it is clearly a referral to another zone. Similarly, it shouldn't matter what the bits are in the NXT (within reason). Assume the NXT _does_ have the DS bit set. If the signature validates on the DS and the signature validates on the NXT then you should ignore the NXT, accept the DS, and traverse into the secure zone. It shouldn't matter what the NXT or SIG bits say. One could argue that this is a bogus response -- a real server would never respond with a ds/sig(ds) and an nxt/sig(nxt). While true, an attacker could give you this response, and IMHO the resolver should deal "properly" (which is, IMHO, to ignore the NXT and use the DS). Your proposal means any attacker could insert the nxt/sig(nxt) into a response and potentially cause a resolver to ignore the real data. Now, my other example: Query: a.example.com. A Answer: a.example.com ns ... ds ... example.com nxt b.example.com ... sig(nxt) > Again, without the QTYPE, I can't tell why you would see this under > normal protocol operations. Well, this is obviously a broken response -- DS is authoritative data, so it should be signed. OTOH, you have an nxt in the answer which might imply an opt-in (if the nxt bit isn't set) or it could imply a 'no data here' (nxt bit is set). > >But I think you need to be clear about silly-state and the node names. > > The NXT has to be pertinent. It will be if the server is following > the protocol rules. If the NXT is not pertinent, well, we need to > define those semantics anyway. (Where?) Please define pertinent. If we assume opt-in, then my second example *IS* pertinent; but without opt-in it implies an attacker added the ns and ds. I'm not so worried about this particular case -- I'm worried about my first example. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 8 14:14:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02285 for ; Thu, 8 May 2003 14:14:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DpqV-000NUO-00 for namedroppers-data@psg.com; Thu, 08 May 2003 18:10:19 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19DpqK-000NTN-00 for namedroppers@ops.ietf.org; Thu, 08 May 2003 18:10:08 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id C20A53BA; Thu, 8 May 2003 14:10:05 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 4FC653B3; Thu, 8 May 2003 14:10:05 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 250049; Thu, 08 May 2003 14:10:03 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 8 May 2003 13:47:42 -0400 To: Derek Atkins From: Edward Lewis Subject: Re: revised proposal for defining the NXT Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:22 -0400 5/8/03, Derek Atkins wrote: >And I disagree with this, specifically because it disallows opt-in. >Note that I'm not an opt-in proponent either, but following this >strategy means that you can't experiment with opt-in... Let me >restate my examples. It says nothing about opt-in. The proposal defines the correct behavior to be 1's in the places where there should be 1's. If there's a deviation, then we run back to old semantics. Why this isn't a barrier to experimenting with, e.g., opt-in, is hidden this logic: Assuming a pre-DNSSEC configured zone: An old resolver has no problem understanding the responses A DNSSEC-pure resolver has no problem A DNSSECw/Opt-In experimental resolver has no problem Assuming a DNSSEC-pure configured zone: An old resolver is oblivious (no DNSSEC OK bit) to the new records A DNSSEC-pure resolver has no problem A DNSSECw/Opt-In experimental resolver follows -pure rules Assuming a DNSSECw/Opt-In experimental configured zone: An old resolver is oblivious (no DNSSEC OK bit) to the new records A DNSSEC-pure resolver treats the zone as if it were unsigned A DNSSECw/Opt-In expt. resolver is able to grok the exp'm'tal extension The experiment can lay transparently over the -pure without cutting off service to the zones participating in the experiment. >Can you define what you mean by "pertinent to the query triplet"? Pertinent means - helps in answering the question. (CNAME, referral, answer, negative answer, all are pertinent.) From www.m-w.com: "having a clear decisive relevance to the matter in hand" It's like this. You ask me what is my telephone number. I respond with "blue." My answer is not pertinent. Or I could say "its at the bottom of my mail." Pertinent - a referral. >*grumble* I think it's unimportant (I don't see why it matters if I'm >asking for A, AAAA, AFSDB, IPSECKEY, or whatever...) but fine, I'll >humor you. Can we at least assume class IN? DNS is founded on the concept of asking for QNAME, QTYPE, QCLASS. It matters. A protocol is all about the specifying the response to a message. >One could argue that this is a bogus response Before we wind up rat holing, let's stick to messages that actually exist in the protocol. And stick to examples that are pertinent to the proposal I am laying on the table. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Note to pilots: a three-point landing SHOULD NOT include a wing. -- 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 May 8 21:08:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18450 for ; Thu, 8 May 2003 21:08:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DwEc-000LRM-00 for namedroppers-data@psg.com; Fri, 09 May 2003 00:59:38 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19DwEZ-000LR9-00 for namedroppers@ops.ietf.org; Fri, 09 May 2003 00:59:35 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h490co901178 for ; Thu, 8 May 2003 17:38:50 -0700 Date: Thu, 8 May 2003 17:38:50 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 37: Conflict Detection Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-14.7 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 37 is included below. The proposed resolution is as follows: In Section 4, change: "Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache. For each UNIQUE resource record in a given interface's cache..." To: "Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR resolver cache. For each UNIQUE resource record in a given interface's configuration, the host MUST verify resource record uniqueness on that interface..." In Section 4.1, change: "If host myhost is configured to use LLMNR on both interfaces, it will send LLMNR queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. Host myhost will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different link. Therefore it will continue using its name. Indeed, host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists." To: "If host myhost is configured to use LLMNR on both interfaces, it will send LLMNR queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. Host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists." -------------------------------------------------------- Issue 37: Conflict detection issues Submitter: Markku Savela Submitter email address: msa@burp.tkv.asdf.org Date first submitted: May 8, 2003 Reference: <200305081347.h48DlusG014194@burp.tkv.asdf.org> Document: LLMNR-18 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: In ... > 4. Conflict resolution > ... > Where a host is configured to respond to LLMNR queries on more than > one interface, each interface should have its own independent LLMNR > cache. For each UNIQUE resource record in a given interface's > cache, ... I have a minor problem with the term "cache" in above. Normally, I would associate the term "cache" in connection with resolver as a place to store answers to the queries this node has sent. (And when a node needs resolve some name, it first would check this cache, and only do the real query if answer is not already cached). Above paragraph seems to use "cache" as a place for storing the set RR's "owned" by this node. A real recursive DNS server might use cached values in answering queries, but the LLMNR only answers for explicitly configured names, never for anything it has cached as a result of a query. Confused me, at least on first reading. Could perhaps read: Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR configuration. For each UNIQUE resource record in a given interface's configuration, the host MUST verify resource record uniqueness on that interface.... > 4.1. Considerations for Multiple Interfaces > ... > ---------- ---------- > | | | | > [A] [myhost] [A] > > > Figure 2. Off-segment name conflict > If host myhost is configured to use LLMNR on both interfaces, it > will send LLMNR queries on both interfaces. When host myhost sends > a query for the host RR for name "A" it will receive a response from > hosts on both interfaces. > > Host myhost will then forward a response from the first responder to > the second responder, who will attempt to verify the uniqueness of > host RR for its name, but will not discover a conflict, since the > conflicting host resides on a different link. Therefore it will > continue using its name. I think the latter paragraph may be misleading, at least on first reading I was startled: "Am I supposed to do conflict resolution across interfaces!!?" If LLMNR can detect it, it should not do any forwarding, if responses come from different interfaces. (E.g. in above case, "clever" LLMNR at "myhost" would not forward the response!). -- 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 May 9 04:31:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09295 for ; Fri, 9 May 2003 04:31:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19E3AD-0004uO-00 for namedroppers-data@psg.com; Fri, 09 May 2003 08:23:33 +0000 Received: from mta06ps.bigpond.com ([144.135.25.138]) by psg.com with esmtp (Exim 3.36 #1) id 19E3AA-0004u9-00 for namedroppers@ops.ietf.org; Fri, 09 May 2003 08:23:30 +0000 Received: from rachel ([144.135.25.75]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15 mta06ps May 23 2002 23:53:28) with SMTP id HEM1Z200.C1A; Fri, 9 May 2003 18:23:26 +1000 Received: from CPE-203-51-30-237.nsw.bigpond.net.au ([203.51.30.237]) by psmam03bpa.bigpond.com(MAM V3.3.2 89/1774948); 09 May 2003 18:23:26 From: Brad Hards To: Bernard Aboba , namedroppers@ops.ietf.org Subject: Re: Proposed Resolution to LLMNR Issue 37: Conflict Detection Issues Date: Fri, 9 May 2003 18:19:40 +1000 User-Agent: KMail/1.5.9 References: In-Reply-To: MIME-Version: 1.0 Content-Description: clearsigned data Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Message-Id: <200305091819.41162.bhards@bigpond.net.au> X-Spam-Status: No, hits=-44.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA09295 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 9 May 2003 10:38 am, Bernard Aboba wrote: > "Where a host is configured to respond to LLMNR queries on more than > one interface, each interface should have its own independent LLMNR > resolver cache. For each UNIQUE resource record in a given > interface's configuration, the host MUST verify resource record > uniqueness on that interface..." I'd actually prefer to see a behavioural description, rather than something that pre-supposes a particular implementation. That is, something of the form: If a Host is configured to respond to LLMNR queries on more than one interface, queries to an interface (must / must not) have X effect on replies to other interfaces. Brad BTW: I assume that "interface" means "logical interface" if we have 801.1q VLAN in operation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+u2SdW6pHgIdAuOMRAvDpAKCGFKzeuHrzApZOkmcSUx8mrwJthgCfbQIS IlFDaNnQ7LfzbRvtYUnJvf8= =DgSD -----END PGP SIGNATURE----- -- 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 May 9 20:46:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08508 for ; Fri, 9 May 2003 20:46:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EI7c-0006JM-00 for namedroppers-data@psg.com; Sat, 10 May 2003 00:21:52 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 3.36 #1) id 19EI7a-0006JA-00 for namedroppers@ops.ietf.org; Sat, 10 May 2003 00:21:51 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h4A0Llh1002536; Fri, 9 May 2003 17:21:48 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h4A0LmBK009365; Fri, 9 May 2003 17:21:48 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h4A0Ljhh009362; Fri, 9 May 2003 17:21:45 -0700 (PDT) Date: Fri, 9 May 2003 17:21:45 -0700 (PDT) Message-Id: <200305100021.h4A0Ljhh009362@guava.araneus.fi> To: namedroppers@ops.ietf.org CC: llmnr-editors@internaut.com Subject: LLMNR issue: use of the term "DNS proxy" without definition From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,RCVD_IN_RFCI version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The term "DNS proxy" is used in the draft without definition Submitter name: Andreas Gustafsson Submitter email address: gson@nominum.com Date first submitted: May 9, 2003 Reference: Document: LLMNR-18 Comment type: T Priority: S Section: 1, 3.2 Rationale/Explanation of issue: draft-ietf-dnsext-mdns-18.txt makes repeated references to an entity called a "DNS proxy". The term "DNS proxy" is not defined in the draft, and there is no DNS standard or RFC defining the behavior of such a device. Requested change: Remove all references to a "DNS proxy". -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat May 10 22:45:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14086 for ; Sat, 10 May 2003 22:45:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Egbv-000I3p-00 for namedroppers-data@psg.com; Sun, 11 May 2003 02:30:47 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19Egbt-000I3Z-00 for namedroppers@ops.ietf.org; Sun, 11 May 2003 02:30:45 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4B29nM26867 for ; Sat, 10 May 2003 19:09:49 -0700 Date: Sat, 10 May 2003 19:09:49 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 38: DNS proxy undefined Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 38 is given below. The proposed resolution is to substitute "DNS server" for "DNS proxy" wherever it appears in the document. Any objections? --------------------------------------------------------------------- Issue 38: DNS proxy undefined Submitter: Andreas Gustafsson Submitter email address: gson@nominum.com Date first submitted: May 9, 2003 Reference: <200305100021.h4A0Ljhh009362@guava.araneus.fi> Document: LLMNR-18 Comment type: T Priority: S Section: 1, 3.2 Rationale/Explanation of issue: draft-ietf-dnsext-mdns-18.txt makes repeated references to an entity called a "DNS proxy". The term "DNS proxy" is not defined in the draft, and there is no DNS standard or RFC defining the behavior of such a device. Requested change: Remove all references to a "DNS proxy". [BA] Proposed resolution is to substitute "DNS server" for "DNS proxy" throughout. -- 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 May 10 22:47:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14132 for ; Sat, 10 May 2003 22:47:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Egj7-000IYb-00 for namedroppers-data@psg.com; Sun, 11 May 2003 02:38:13 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19Egj4-000IYL-00 for namedroppers@ops.ietf.org; Sun, 11 May 2003 02:38:11 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4B2HFR27314 for ; Sat, 10 May 2003 19:17:15 -0700 Date: Sat, 10 May 2003 19:17:15 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to Issue 37: Conflict detection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 37 is included below. The proposed resolution is as follows: In Section 4, change: "Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache. For each UNIQUE resource record in a given interface's cache..." To: "Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR resolver cache. For each UNIQUE resource record in a given interface's configuration, the host MUST verify resource record uniqueness on that interface..." In Section 4.1, change: "If host myhost is configured to use LLMNR on both interfaces, it will send LLMNR queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. Host myhost will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different link. Therefore it will continue using its name. Indeed, host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists." To: "If host myhost is configured to use LLMNR on both interfaces, it will send LLMNR queries on both interfaces. When host myhost sends a query for the host RR for name "A" it will receive a response from hosts on both interfaces. Host myhost will then send the first responder's response to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different link. Therefore it will continue using its name. Host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists." ----------------------------------------------------------------- Issue 37: Conflict detection issues Submitter: Markku Savela Submitter email address: msa@burp.tkv.asdf.org Date first submitted: May 8, 2003 Reference: <200305081347.h48DlusG014194@burp.tkv.asdf.org> Document: LLMNR-18 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: In ... > 4. Conflict resolution > ... > Where a host is configured to respond to LLMNR queries on more than > one interface, each interface should have its own independent LLMNR > cache. For each UNIQUE resource record in a given interface's > cache, ... I have a minor problem with the term "cache" in above. Normally, I would associate the term "cache" in connection with resolver as a place to store answers to the queries this node has sent. (And when a node needs resolve some name, it first would check this cache, and only do the real query if answer is not already cached). Above paragraph seems to use "cache" as a place for storing the set RR's "owned" by this node. A real recursive DNS server might use cached values in answering queries, but the LLMNR only answers for explicitly configured names, never for anything it has cached as a result of a query. Confused me, at least on first reading. Could perhaps read: Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR configuration. For each UNIQUE resource record in a given interface's configuration, the host MUST verify resource record uniqueness on that interface.... > 4.1. Considerations for Multiple Interfaces > ... > ---------- ---------- > | | | | > [A] [myhost] [A] > > > Figure 2. Off-segment name conflict > If host myhost is configured to use LLMNR on both interfaces, it > will send LLMNR queries on both interfaces. When host myhost sends > a query for the host RR for name "A" it will receive a response from > hosts on both interfaces. > > Host myhost will then forward a response from the first responder to > the second responder, who will attempt to verify the uniqueness of > host RR for its name, but will not discover a conflict, since the > conflicting host resides on a different link. Therefore it will > continue using its name. I think the latter paragraph may be misleading, at least on first reading I was startled: "Am I supposed to do conflict resolution across interfaces!!?" If LLMNR can detect it, it should not do any forwarding, if responses come from different interfaces. (E.g. in above case, "clever" LLMNR at "myhost" would not forward the response!). -- 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 May 11 01:06:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15931 for ; Sun, 11 May 2003 01:06:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19EivX-0003Ng-00 for namedroppers-data@psg.com; Sun, 11 May 2003 04:59:11 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19EivV-0003NT-00 for namedroppers@ops.ietf.org; Sun, 11 May 2003 04:59:09 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4B4cDC02659 for ; Sat, 10 May 2003 21:38:13 -0700 Date: Sat, 10 May 2003 21:38:13 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Strawman LLMNR-19 available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A strawman version of LLMNR-19 is available for inspection here, including the proposed resolutions to Issues 37 and 38: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-19.tt -- 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 May 12 11:09:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18081 for ; Mon, 12 May 2003 11:09:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FElR-000KEQ-00 for namedroppers-data@psg.com; Mon, 12 May 2003 14:58:53 +0000 Received: from patan.sun.com ([192.18.98.43] helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 3.36 #1) id 19FElN-000KDC-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 14:58:49 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4CEwkiY011060 for ; Mon, 12 May 2003 08:58:47 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4CEwjL02964 for ; Mon, 12 May 2003 16:58:45 +0200 (MEST) Date: Mon, 12 May 2003 16:58:13 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: What is "service name" in SRV records? To: namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk RFC 2782 says Currently, the translation from service name to port number happens at the client, often using a file such as /etc/services. I've been assuming that "service name" was the same as "keyword" in http://www.iana.org/assignments/port-numbers but the keywords are not unique within the registry. Somebody else found http://www.iana.org/assignments/service-names which has unique service names. What is the correct answer? Erik -- 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 May 12 11:44:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21447 for ; Mon, 12 May 2003 11:44:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FFEV-0000kD-00 for namedroppers-data@psg.com; Mon, 12 May 2003 15:28:55 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19FFES-0000k1-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 15:28:52 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h4CFSpai001744; Mon, 12 May 2003 11:28:51 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h4CFSo9C014385; Mon, 12 May 2003 11:28:50 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h4CFSnFJ020789; Mon, 12 May 2003 11:28:50 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id LAA14443; Mon, 12 May 2003 11:28:49 -0400 (EDT) To: Erik Nordmark Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: What is "service name" in SRV records? References: Date: 12 May 2003 11:28:49 -0400 In-Reply-To: Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-35.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > RFC 2782 says > Currently, the translation from service name to port number happens > at the client, often using a file such as /etc/services. > > I've been assuming that "service name" was the same as "keyword" in > http://www.iana.org/assignments/port-numbers > but the keywords are not unique within the registry. > > Somebody else found > http://www.iana.org/assignments/service-names > which has unique service names. > > What is the correct answer? I think it refers to the former (assignments/port-numbers). As for the keyword uniqueness, the only duplicate I saw in a cursory glance of the file was compressnet, which was asiggned both ports 2 and 3. I didn't notice any other duplicates through about 4500 (which is where I stopped looking). > Erik -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 12 11:48:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21627 for ; Mon, 12 May 2003 11:48:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FFPm-0003GW-00 for namedroppers-data@psg.com; Mon, 12 May 2003 15:40:34 +0000 Received: from patan.sun.com ([192.18.98.43] helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 3.36 #1) id 19FFPb-0003G9-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 15:40:24 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4CFeCiY011300 for ; Mon, 12 May 2003 09:40:12 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4CFeBL06273 for ; Mon, 12 May 2003 17:40:11 +0200 (MEST) Date: Mon, 12 May 2003 17:39:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: draft-ietf-secsh-dns-04.txt To: namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk If you haven't looked at this draft from the DNS perspective (how the RDATA is specified; zone file syntax etc) now would be a good time to do that. It is on the IESG's agenda for this Thursday. Erik -- 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 May 12 11:51:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21726 for ; Mon, 12 May 2003 11:51:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FFUM-00040n-00 for namedroppers-data@psg.com; Mon, 12 May 2003 15:45:18 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 19FFUJ-00040V-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 15:45:15 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h4CFjCuv010019; Mon, 12 May 2003 08:45:12 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 May 2003 08:45:13 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Erik Nordmark'" , namedroppers@ops.ietf.org Subject: RE: What is "service name" in SRV records? Date: Mon, 12 May 2003 08:45:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I prefer to avoid port numbers since Web Services such as XKMS don't have them but are usefully identified in SRV records. I don't think we want people writing web services to have an incentive to start burning port numbers just to get an SRV record. Web Services are not designed to be firewalled on port number, they are designed to be firewalled by XML aware gateways. So the port number they run on is not relevant. Most are going to work over either HTTP or DIME. Phill > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Monday, May 12, 2003 10:58 AM > To: namedroppers@ops.ietf.org > Subject: What is "service name" in SRV records? > > > RFC 2782 says > Currently, the translation from service name to port number happens > at the client, often using a file such as /etc/services. > > I've been assuming that "service name" was the same as "keyword" in > http://www.iana.org/assignments/port-numbers > but the keywords are not unique within the registry. > > Somebody else found > http://www.iana.org/assignments/service-names > which has unique service names. > > What is the correct answer? > > Erik > > > -- > 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 May 12 13:00:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24026 for ; Mon, 12 May 2003 13:00:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FGaC-000IIh-00 for namedroppers-data@psg.com; Mon, 12 May 2003 16:55:24 +0000 Received: from 98.in-addr.ehsco.com ([207.65.203.98] helo=goose.ehsco.com) by psg.com with esmtp (Exim 3.36 #1) id 19FGa9-000IIU-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 16:55:21 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0) with ESMTP-TLS id 206441; Mon, 12 May 2003 11:54:43 -0500 Message-ID: <3EBFD1F5.7010608@ehsco.com> Date: Mon, 12 May 2003 11:55:17 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Erik Nordmark CC: namedroppers@ops.ietf.org Subject: Re: What is "service name" in SRV records? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 5/12/2003 9:58 AM Erik Nordmark wrote: > RFC 2782 says > Currently, the translation from service name to port number happens > at the client, often using a file such as /etc/services. > > I've been assuming that "service name" was the same as "keyword" in > http://www.iana.org/assignments/port-numbers > but the keywords are not unique within the registry. > > Somebody else found > http://www.iana.org/assignments/service-names > which has unique service names. > > What is the correct answer? No service name is valid for use with SRV until it has been documented in a specification which has credible authority over that service. EG, neither _whois._tcp.domain.dom nor _nicname._tcp.domain.dom are meaningful until one or the other has been explicitly declared as meaningful within the context of using SRV RRs to locate the servers associated with a specific service. Once an authoritative specification has been written, the service name is whatever the specification defines it to be. Whether or not that name has been used anywhere else is simply a matter of convenience. -- 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 May 12 13:22:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24599 for ; Mon, 12 May 2003 13:22:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FGxS-000NX1-00 for namedroppers-data@psg.com; Mon, 12 May 2003 17:19:26 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19FGxP-000NWN-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 17:19:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AAE3213960 for ; Mon, 12 May 2003 17:19:10 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: What is "service name" in SRV records? In-Reply-To: Message from Erik Nordmark of "Mon, 12 May 2003 16:58:13 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 12 May 2003 17:19:10 +0000 Message-Id: <20030512171910.AAE3213960@sa.vix.com> X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > RFC 2782 says > Currently, the translation from service name to port number happens > at the client, often using a file such as /etc/services. > > I've been assuming that "service name" was the same as "keyword" in > http://www.iana.org/assignments/port-numbers > but the keywords are not unique within the registry. > > Somebody else found > http://www.iana.org/assignments/service-names > which has unique service names. > > What is the correct answer? the authors of that rfc didn't know there was a difference. certainly the WKS RR is not used any more, and the second url points to a list which is very short and out of date. i think the first url referenced above is a better choice in the modern era. but, for the record, there was no intent one way or the other at the time this experimental rfc was submitted. -- 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 May 12 13:28:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24807 for ; Mon, 12 May 2003 13:28:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FH2P-000Ocr-00 for namedroppers-data@psg.com; Mon, 12 May 2003 17:24:33 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19FH2M-000OcD-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 17:24:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E27D313960 for ; Mon, 12 May 2003 17:24:17 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: What is "service name" in SRV records? In-Reply-To: Message from "Eric A. Hall" of "Mon, 12 May 2003 11:55:17 EST." <3EBFD1F5.7010608@ehsco.com> X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 12 May 2003 17:24:17 +0000 Message-Id: <20030512172417.E27D313960@sa.vix.com> X-Spam-Status: No, hits=-13.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > What is the correct answer? > > No service name is valid for use with SRV until it has been documented in > a specification which has credible authority over that service. EG, > neither _whois._tcp.domain.dom nor _nicname._tcp.domain.dom are meaningful > until one or the other has been explicitly declared as meaningful within > the context of using SRV RRs to locate the servers associated with a > specific service. i'm not sure whether that's true. at least, that wasn't the authors' intent. > Once an authoritative specification has been written, the service name is > whatever the specification defines it to be. Whether or not that name has > been used anywhere else is simply a matter of convenience. i'm sure that that is not true. there has to be a single authoritative list of "service names", and the above proposal would cause IANA to have to keep two such lists, neither of which would be authoritative. -- 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 May 12 13:49:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25501 for ; Mon, 12 May 2003 13:49:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FHO8-0003cO-00 for namedroppers-data@psg.com; Mon, 12 May 2003 17:47:00 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19FHO3-0003c2-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 17:46:55 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h4CHklbd020942 for ; Mon, 12 May 2003 13:46:47 -0400 (EDT) Message-ID: <006a01c318ae$762777a0$b9370681@barnacle> From: "Scott Rose" To: References: Subject: Re: draft-ietf-secsh-dns-04.txt Date: Mon, 12 May 2003 13:46:48 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.9 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Making a quick look over of the draft - I don't see anything that could be an issue at first. RDATA format is pretty standard (2 bytes and a hex string). There are no given restrictions on zone file placement. The draft requests new IANA registries for algorithm and fingerprint codes and does not use the DNSSEC algorithm/digest codes. There might be a need to list some security considerations about relying on message authentication schemes like TSIG if no SIG RR covers the SSHFP RRset in a zone. Scott ----- Original Message ----- From: "Erik Nordmark" To: Sent: Monday, May 12, 2003 11:39 AM Subject: draft-ietf-secsh-dns-04.txt > > If you haven't looked at this draft from the DNS perspective (how the RDATA > is specified; zone file syntax etc) now would be a good time to do that. > It is on the IESG's agenda for this Thursday. > > Erik > > > -- > 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 May 12 14:27:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26708 for ; Mon, 12 May 2003 14:27:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FHvg-000AZE-00 for namedroppers-data@psg.com; Mon, 12 May 2003 18:21:40 +0000 Received: from 98.in-addr.ehsco.com ([207.65.203.98] helo=goose.ehsco.com) by psg.com with esmtp (Exim 3.36 #1) id 19FHvV-000AYZ-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 18:21:30 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0) with ESMTP-TLS id 206454 for namedroppers@ops.ietf.org; Mon, 12 May 2003 13:20:51 -0500 Message-ID: <3EBFE626.1020509@ehsco.com> Date: Mon, 12 May 2003 13:21:26 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: What is "service name" in SRV records? References: <20030512172417.E27D313960@sa.vix.com> In-Reply-To: <20030512172417.E27D313960@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 5/12/2003 12:24 PM Paul Vixie wrote: >>> What is the correct answer? >> >> No service name is valid for use with SRV until it has been >> documented in a specification which has credible authority over that >> service. EG, neither _whois._tcp.domain.dom nor >> _nicname._tcp.domain.dom are meaningful until one or the other has >> been explicitly declared as meaningful within the context of using >> SRV RRs to locate the servers associated with a specific service. > > i'm not sure whether that's true. at least, that wasn't the authors' > intent. I have no doubt that it wasn't your intention but that's the practical result. Historically, a spec had to detail the usage before a service can be mapped with SRV in a standardized way, and whatever service name the spec defined was the service name that got used. We could argue over whether or not a spec must be written first, and I won't hold out very long, but that's the way it's shaping up. -- 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 May 12 16:14:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02272 for ; Mon, 12 May 2003 16:14:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FJZy-000Cma-00 for namedroppers-data@psg.com; Mon, 12 May 2003 20:07:22 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19FJZu-000Cm0-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 20:07:18 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4CJkCs07883 for ; Mon, 12 May 2003 12:46:12 -0700 Date: Mon, 12 May 2003 12:46:12 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 39: Name conflict detection algorithm Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: May 12, 2003 Reference: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 39 Document: LLMNR-18 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: It isn't clear to me that the name conflict detection mechanism defined in Section 4 makes sense. Here is what it says: "The name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In such a situation, name conflicts are detected when a sender receives more than one response to its LLMNR multicast query. In this case, the sender sends the first response that it received to all responders that responded to this query except the first one, using UDP unicast. A host that receives a query response containing a UNIQUE resource record that it owns, even if it didn't send such a query, MUST verify that no other host within the LLMNR scope is authoritative for the same name, using the mechanism described above. Based on the result, the host detects whether there is a name conflict and acts accordingly." I don't like the idea of sending unsolicited UDP responses. The goal here is to enable hosts involved in a conflict to become aware of it more quickly. A potential alternative is to mandate that hosts send an LLMNR query for their own name at some convenient interval (every 30 seconds?) -- 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 May 12 17:31:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04536 for ; Mon, 12 May 2003 17:31:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FKiM-0004SJ-00 for namedroppers-data@psg.com; Mon, 12 May 2003 21:20:06 +0000 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #1) id 19FKiJ-0004Rd-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 21:20:03 +0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h4CLK24m014150 for ; Mon, 12 May 2003 14:20:02 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 12 May 2003 14:20:02 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h4CLK1Ub024264 for ; Mon, 12 May 2003 14:20:01 -0700 (PDT) Date: Mon, 12 May 2003 14:20:02 -0700 Subject: Re: LLMNR Issue 39: Name conflict detection algorithm Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Joshua Graessley To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <7E6B2303-84BF-11D7-BAAC-000A959D832C@apple.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, May 12, 2003, at 12:46 US/Pacific, Bernard Aboba wrote: > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: May 12, 2003 > Reference: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue > 39 > Document: LLMNR-18 > Comment type: T > Priority: S > Section: 4 > Rationale/Explanation of issue: > > It isn't clear to me that the name conflict detection mechanism > defined in Section 4 makes sense. Here is what it says: > > "The name conflict detection mechanism doesn't prevent name > conflicts when previously partitioned segments are connected by a > bridge. In such a situation, name conflicts are detected when a sender > receives more than one response to its LLMNR multicast query. > In this case, the sender sends the first response that it received to > all > responders that responded to this query except the first one, using UDP > unicast. A host that receives a query response containing a UNIQUE > resource record that it > owns, even if it didn't send such a query, MUST verify that no other > host within the LLMNR scope is authoritative for the same name, using > the mechanism described above. Based on the result, the host detects > whether there is a name conflict and acts accordingly." > > I don't like the idea of sending unsolicited UDP responses. The > goal here is to enable hosts involved in a conflict to become > aware of it more quickly. > > A potential alternative is to mandate that hosts send an LLMNR query > for their own name at some convenient interval (every 30 seconds?) It seems another alternative might be to send all responses using multicast instead of unicast. This would give hosts a chance to detect conflicts much quicker. The same trick is used with IPv4LL and ARP. The ARP responses are broadcast to facilitate in quicker discovery of conflicts. The multicast responses could be used to populate a local LLMNR cache on all hosts possibly reducing the number of queries that must be sent. -josh -- 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 May 12 17:50:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05023 for ; Mon, 12 May 2003 17:50:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FL9E-0009as-00 for namedroppers-data@psg.com; Mon, 12 May 2003 21:47:52 +0000 Received: from cs180132.pp.htv.fi ([213.243.180.132] helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 19FL9A-0009ad-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 21:47:48 +0000 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4CLo3HZ014096; Tue, 13 May 2003 00:50:03 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4CLo2Kr014095; Tue, 13 May 2003 00:50:02 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR Issue 39: Name conflict detection algorithm From: Mika Liljeberg To: Bernard Aboba Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1052776201.13437.16.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 13 May 2003 00:50:02 +0300 X-Spam-Status: No, hits=-40.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-05-12 at 22:46, Bernard Aboba wrote: > Submitter: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: May 12, 2003 > Reference: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 39 > Document: LLMNR-18 > Comment type: T > Priority: S > Section: 4 > Rationale/Explanation of issue: > > It isn't clear to me that the name conflict detection mechanism > defined in Section 4 makes sense. Here is what it says: > > "The name conflict detection mechanism doesn't prevent name > conflicts when previously partitioned segments are connected by a > bridge. In such a situation, name conflicts are detected when a sender > receives more than one response to its LLMNR multicast query. > In this case, the sender sends the first response that it received to all > responders that responded to this query except the first one, using UDP > unicast. We no longer need to do this, since responses are now sent to a single multicast group. All responders will hear the responses from all other responders. > A host that receives a query response containing a UNIQUE resource record that it > owns, even if it didn't send such a query, MUST verify that no other > host within the LLMNR scope is authoritative for the same name, using > the mechanism described above. Based on the result, the host detects > whether there is a name conflict and acts accordingly." > > I don't like the idea of sending unsolicited UDP responses. The > goal here is to enable hosts involved in a conflict to become > aware of it more quickly. A conflict won't matter until someone queries a name. Once that happens, conflict detection occurs pretty much immediately, since all responders hear the responses from all other responders. > A potential alternative is to mandate that hosts send an LLMNR query > for their own name at some convenient interval (every 30 seconds?) That would be wasteful. MikaL -- 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 May 12 17:59:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05279 for ; Mon, 12 May 2003 17:59:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FLDT-000Ab7-00 for namedroppers-data@psg.com; Mon, 12 May 2003 21:52:15 +0000 Received: from cs180132.pp.htv.fi ([213.243.180.132] helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 19FLDR-000Aau-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 21:52:13 +0000 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4CLsTHZ014109; Tue, 13 May 2003 00:54:29 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4CLsScv014108; Tue, 13 May 2003 00:54:28 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR Issue 39: Name conflict detection algorithm From: Mika Liljeberg To: Bernard Aboba Cc: namedroppers@ops.ietf.org In-Reply-To: <1052776201.13437.16.camel@devil> References: <1052776201.13437.16.camel@devil> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1052776468.13430.20.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 13 May 2003 00:54:28 +0300 X-Spam-Status: No, hits=-39.4 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-05-13 at 00:50, Mika Liljeberg wrote: > We no longer need to do this, since responses are now sent to a single > multicast group. All responders will hear the responses from all other > responders. Oops, looks like I jumped ahead of things, responses are currently sent using unicast. But as Joshua also suggested, we could just use multicast. MikaL -- 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 May 12 18:36:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07207 for ; Mon, 12 May 2003 18:36:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FLn4-000J8k-00 for namedroppers-data@psg.com; Mon, 12 May 2003 22:29:02 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19FLn2-000J8U-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 22:29:00 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4CM7oA15908; Mon, 12 May 2003 15:07:50 -0700 Date: Mon, 12 May 2003 15:07:50 -0700 (PDT) From: Bernard Aboba To: Mika Liljeberg cc: namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 39: Name conflict detection algorithm In-Reply-To: <1052776201.13437.16.camel@devil> Message-ID: References: <1052776201.13437.16.camel@devil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > We no longer need to do this, since responses are now sent to a single > multicast group. All responders will hear the responses from all other > responders. It is *requests* that are sent to a single multicast group, not responses -- which are sent unicast. So all responders will *not* hear the responses. > A conflict won't matter until someone queries a name. Once that happens, > conflict detection occurs pretty much immediately, since all responders > hear the responses from all other responders. That isn't the way the protocol works. -- 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 May 12 18:43:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07349 for ; Mon, 12 May 2003 18:43:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FLvQ-000M4q-00 for namedroppers-data@psg.com; Mon, 12 May 2003 22:37:40 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19FLvN-000M46-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 22:37:37 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4CMGUc16433; Mon, 12 May 2003 15:16:30 -0700 Date: Mon, 12 May 2003 15:16:30 -0700 (PDT) From: Bernard Aboba To: Mika Liljeberg cc: namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 39: Name conflict detection algorithm In-Reply-To: <1052776201.13437.16.camel@devil> Message-ID: References: <1052776201.13437.16.camel@devil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > A potential alternative is to mandate that hosts send an LLMNR query > > for their own name at some convenient interval (every 30 seconds?) > > That would be wasteful. Wouldn't it also be wasteful to send all responses to the same multicast group? -- 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 May 12 19:08:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08091 for ; Mon, 12 May 2003 19:08:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FMLa-0002Vz-00 for namedroppers-data@psg.com; Mon, 12 May 2003 23:04:42 +0000 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #1) id 19FMLY-0002UO-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 23:04:40 +0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h4CN4e4m008552 for ; Mon, 12 May 2003 16:04:40 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 12 May 2003 16:04:39 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id h4CN4dRM015172 for ; Mon, 12 May 2003 16:04:39 -0700 (PDT) Date: Mon, 12 May 2003 16:04:40 -0700 Subject: Re: LLMNR Issue 39: Name conflict detection algorithm Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Joshua Graessley To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <1C182BC8-84CE-11D7-BAAC-000A959D832C@apple.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, May 12, 2003, at 15:16 US/Pacific, Bernard Aboba wrote: >>> A potential alternative is to mandate that hosts send an LLMNR query >>> for their own name at some convenient interval (every 30 seconds?) >> >> That would be wasteful. > > Wouldn't it also be wasteful to send all responses to the same > multicast group? The response packet has to be sent. If it's sent using multicast instead of unicast it will reach more machines but at least a packet wouldn't be sent when it isn't needed. Sending every 30 seconds is a precaution, in case something is wrong. If two hosts are configured to respond differently to LLMNR requests, there is no problem until another host actually queries for the conflicting record. If no host ever queries for that record, what do we gain by spewing traffic every 30 seconds? The multicast response could be used to build a cache on hosts implementing LLMNR resolvers. This cache could be hit before a query packet is generated on the wire, potentially eliminating additional traffic. -- 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 May 12 19:33:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08649 for ; Mon, 12 May 2003 19:33:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FMkO-0009fP-00 for namedroppers-data@psg.com; Mon, 12 May 2003 23:30:20 +0000 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #1) id 19FMkK-0009em-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 23:30:16 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id h4CNUBW0019448 for ; Mon, 12 May 2003 19:30:11 -0400 (EDT) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAwfa4_L; Mon, 12 May 03 19:30:11 -0400 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003051219301027542 for ; Mon, 12 May 2003 19:30:10 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h4CNUAg0002843 for ; Mon, 12 May 2003 19:30:11 -0400 (EDT) Received: from daimlerchrysler.com (localhost [127.0.0.1]) by wokcdts1.is.chrysler.com (8.12.8/8.9.1) with ESMTP id h4CNTRTF022303 for ; Mon, 12 May 2003 19:29:27 -0400 (EDT) Message-ID: <3EC02E57.1864B05C@daimlerchrysler.com> Date: Mon, 12 May 2003 19:29:27 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Proposed resolution to LLMNR Issue 38: DNS proxy undefined References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think "recursive resolver" would be more precise. "DNS server" could be mistaken for "authoritative server". Speaking of which, I think you use the term "DNS server" sometimes to mean an authoritative server, and at other times, to mean a recursive resolver. You should probably audit that usage simultaneously. - Kevin Bernard Aboba wrote: > The text of Issue 38 is given below. > > The proposed resolution is to substitute "DNS server" for "DNS proxy" > wherever it appears in the document. > > Any objections? > > --------------------------------------------------------------------- > Issue 38: DNS proxy undefined > Submitter: Andreas Gustafsson > Submitter email address: gson@nominum.com > Date first submitted: May 9, 2003 > Reference: <200305100021.h4A0Ljhh009362@guava.araneus.fi> > Document: LLMNR-18 > Comment type: T > Priority: S > Section: 1, 3.2 > Rationale/Explanation of issue: > draft-ietf-dnsext-mdns-18.txt makes repeated references to an entity > called a "DNS proxy". The term "DNS proxy" is not defined in the > draft, and there is no DNS standard or RFC defining the behavior of > such a device. > > Requested change: > > Remove all references to a "DNS proxy". > > [BA] Proposed resolution is to substitute "DNS server" for "DNS proxy" > throughout. > > -- > 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 May 12 19:45:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08842 for ; Mon, 12 May 2003 19:45:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FMwJ-000CF9-00 for namedroppers-data@psg.com; Mon, 12 May 2003 23:42:39 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19FMwG-000BxN-00 for namedroppers@ops.ietf.org; Mon, 12 May 2003 23:42:36 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4CNg1ab081197; Tue, 13 May 2003 09:42:01 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4CNg0g9049710; Tue, 13 May 2003 09:42:01 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305122342.h4CNg0g9049710@drugs.dv.isc.org> To: "Scott Rose" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: draft-ietf-secsh-dns-04.txt In-reply-to: Your message of "Mon, 12 May 2003 13:46:48 -0400." <006a01c318ae$762777a0$b9370681@barnacle> Date: Tue, 13 May 2003 09:42:00 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Making a quick look over of the draft - I don't see anything that could be > an issue at first. RDATA format is pretty standard (2 bytes and a hex > string). There are no given restrictions on zone file placement. > > The draft requests new IANA registries for algorithm and fingerprint codes > and does not use the DNSSEC algorithm/digest codes. DS also uses SHA-1. Also the draft needs to be clear about whether mnemonics can be use or not in the presentation format for the record. > There might be a need to list some security considerations about relying on > message authentication schemes like TSIG if no SIG RR covers the SSHFP RRset > in a zone. > > Scott -- Mark Andrews, Internet Software Consortium 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 Mon May 12 21:45:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11074 for ; Mon, 12 May 2003 21:45:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FOm8-000NYI-00 for namedroppers-data@psg.com; Tue, 13 May 2003 01:40:16 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 3.36 #1) id 19FOm4-000NXY-00 for namedroppers@ops.ietf.org; Tue, 13 May 2003 01:40:13 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h4D1e5h1014622; Mon, 12 May 2003 18:40:06 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h4D1e6BK005939; Mon, 12 May 2003 18:40:06 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h4D1e5Kc005936; Mon, 12 May 2003 18:40:05 -0700 (PDT) Date: Mon, 12 May 2003 18:40:05 -0700 (PDT) Message-Id: <200305130140.h4D1e5Kc005936@guava.araneus.fi> To: Kevin Darcy Cc: namedroppers@ops.ietf.org Subject: Re: Proposed resolution to LLMNR Issue 38: DNS proxy undefined In-Reply-To: <3EC02E57.1864B05C@daimlerchrysler.com> References: <3EC02E57.1864B05C@daimlerchrysler.com> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-37.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kevin Darcy writes: > I think "recursive resolver" would be more precise. "DNS server" could be > mistaken for "authoritative server". Speaking of which, I think you use > the term "DNS server" sometimes to mean an authoritative server, and at > other times, to mean a recursive resolver. You should probably audit that > usage simultaneously. The -18 draft also talked about the DNS proxy "supporting dynamic update", which makes no sense if it was indeed referring to a recursive resolver. In the scenario involving a "home gateway", DHCP, and dynamic DNS, there actually needs to be both a caching server (aka recursive resolver) and an authoritative server (where names are registered using DDNS), but each of these can independently be on the local wire, integrated into the gateway, or anywhere else on the Internet reachable through the gateway. Since the location of these servers is entirely immaterial, any time the draft mentions them being in a specific location or claiming that a "proxy" is needed to reach them, it is only confusing the issue. This is why I requested that any mention of a proxy be removed, not changed. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 12 23:31:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12722 for ; Mon, 12 May 2003 23:31:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FQPY-00049o-00 for namedroppers-data@psg.com; Tue, 13 May 2003 03:25:04 +0000 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 19FQPU-00048c-00 for namedroppers@ops.ietf.org; Tue, 13 May 2003 03:25:00 +0000 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 67A3A6193; Tue, 13 May 2003 05:24:59 +0200 (CEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id 27D651D99; Tue, 13 May 2003 05:24:59 +0200 (MEST) Date: Tue, 13 May 2003 05:24:58 +0200 (CEST) From: Jakob Schlyter To: Mark.Andrews@isc.org Cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: draft-ietf-secsh-dns-04.txt In-Reply-To: <200305122342.h4CNg0g9049710@drugs.dv.isc.org> Message-ID: References: <200305122342.h4CNg0g9049710@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-38.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 13 May 2003 Mark.Andrews@isc.org wrote: > Also the draft needs to be clear about whether mnemonics can be use > or not in the presentation format for the record. the draft says nothing about mnemonics and I have no intention to support them. should I make this non-support explicit? jakob -- 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 May 12 23:31:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12737 for ; Mon, 12 May 2003 23:31:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FQNe-00045i-00 for namedroppers-data@psg.com; Tue, 13 May 2003 03:23:06 +0000 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 19FQNc-00045W-00 for namedroppers@ops.ietf.org; Tue, 13 May 2003 03:23:04 +0000 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 637B76193; Tue, 13 May 2003 05:23:03 +0200 (CEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id 285411D99; Tue, 13 May 2003 05:23:03 +0200 (MEST) Date: Tue, 13 May 2003 05:23:02 +0200 (CEST) From: Jakob Schlyter To: Scott Rose Cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-secsh-dns-04.txt In-Reply-To: <006a01c318ae$762777a0$b9370681@barnacle> Message-ID: References: <006a01c318ae$762777a0$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-35.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 12 May 2003, Scott Rose wrote: > There might be a need to list some security considerations about relying on > message authentication schemes like TSIG if no SIG RR covers the SSHFP RRset > in a zone. the draft requires that each SSHFP are covered by a SIG RR. jakob -- 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 May 12 23:38:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13238 for ; Mon, 12 May 2003 23:38:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FQa8-0005Cl-00 for namedroppers-data@psg.com; Tue, 13 May 2003 03:36:00 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19FQa5-0005BP-00 for namedroppers@ops.ietf.org; Tue, 13 May 2003 03:35:57 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4D3Y1ab081384; Tue, 13 May 2003 13:34:01 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4D3Y1g9051243; Tue, 13 May 2003 13:34:01 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305130334.h4D3Y1g9051243@drugs.dv.isc.org> To: Jakob Schlyter Cc: Scott Rose , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: draft-ietf-secsh-dns-04.txt In-reply-to: Your message of "Tue, 13 May 2003 05:24:58 +0200." Date: Tue, 13 May 2003 13:34:01 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Tue, 13 May 2003 Mark.Andrews@isc.org wrote: > > > Also the draft needs to be clear about whether mnemonics can be use > > or not in the presentation format for the record. > > the draft says nothing about mnemonics and I have no intention to support > them. should I make this non-support explicit? > > jakob Yes. -- Mark Andrews, Internet Software Consortium 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 Mon May 12 23:50:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13580 for ; Mon, 12 May 2003 23:50:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FQjV-00064r-00 for namedroppers-data@psg.com; Tue, 13 May 2003 03:45:41 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19FQjR-00064d-00 for namedroppers@ops.ietf.org; Tue, 13 May 2003 03:45:37 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4D3OUa00949 for ; Mon, 12 May 2003 20:24:30 -0700 Date: Mon, 12 May 2003 20:24:30 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Revised resolution Proposal for LLMNR Issue 38: DNS Proxy undefined Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In Section 1, Change: "Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a home gateway, then the network either has a DNS server or the home gateway can function as a DNS proxy. By implementing Dynamic Host Configuration Service for IPv4 (DHCPv4) as well as a DNS proxy and dynamic DNS, home gateways can provide name resolution for the names of hosts over IPv4 on the local network. For small IPv6 networks, equivalent functionality can be provided by a home gateway implementing Dynamic Host Configuration Service for IPv6 (DHCPv6) for DNS configuration [DHCPv6DNS], as well as a DNS proxy supporting AAAA RRs and dynamic DNS, providing name resolution for the names of hosts over IPv6 on the local network. This should be adequate as long as home gateways implementing DNS configuration also support dynamic DNS in some form." To: "Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a home gateway, then the network either has DNS and DHCPv4 servers or the home gateway provides DHCPv4 and DNS server functionality. By providing Dynamic Host Configuration Service for IPv4 (DHCPv4), as well as a DNS server with support for dynamic DNS, which is also authoritative for the A RRs of local hosts, it is possible to support resolution of local host names over IPv4. For small IPv6 networks, equivalent functionality can be provided by implementing Dynamic Host Configuration Service for IPv6 (DHCPv6) for DNS configuration [DHCPv6DNS], as well providing a DNS server with support for dynamic DNS, which is also authoritative for the AAAA RRs of local hosts, it is possible to support the resolution of local host names over IPv6 as well as IPv4. " In Section 3.2, change: "LLMNR usage MAY be configured manually or automatically on a per interface basis. By default, LLMNR responders SHOULD be enabled on all interfaces, at all times. Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server over IPv4, while remaining unconfigured with a DNS server suitable for use over IPv6. In these situations, a dual stack host will send AAAA queries to the configured DNS server over IPv4. However, an IPv6-only host unconfigured with a DNS server suitable for use over IPv6 will be unable to resolve names using DNS. Since automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and [DNSDisc]) are not yet widely deployed, and not all DNS servers support IPv6, lack of IPv6 DNS configuration may be a common problem in the short term, and LLMNR may prove useful in enabling linklocal name resolution over IPv6. For example, a home gateway may implement a DNS proxy and DHCPv4, but not DHCPv6 for DNS configuration [DHCPv6DNS]. In such a circumstance, IPv6-only hosts will not be configured with a DNS server. Where the DNS proxy does not support dynamic client update over IPv6 or DHCPv6-based dynamic update of the DNS proxy, the home gateway will not be able to dynamically register the names of IPv6 hosts. As a result, the DNS proxy will respond to AAAA RR queries sent over IPv4 or IPv6 with an authoritative name error (RCODE=3). This prevents hosts from resolving the names of IPv6-only hosts on the local link. In this situation, LLMNR over IPv6 can be used for resolution of dynamic names." To: "LLMNR usage MAY be configured manually or automatically on a per interface basis. By default, LLMNR responders SHOULD be enabled on all interfaces, at all times. Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server over IPv4, while remaining unconfigured with a DNS server suitable for use over IPv6. In these situations, a dual stack host will send AAAA queries to the configured DNS server over IPv4. However, an IPv6-only host unconfigured with a DNS server suitable for use over IPv6 will be unable to resolve names using DNS. Since automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and [DNSDisc]) are not yet widely deployed, and not all DNS servers support IPv6, lack of IPv6 DNS configuration may be a common problem in the short term, and LLMNR may prove useful in enabling linklocal name resolution over IPv6. For example, a home network may provide a DHCPv4 server but may not support DHCPv6 for DNS configuration [DHCPv6DNS]. In such a circumstance, IPv6-only hosts will not be configured with a DNS server. Where a DNS server is configured but does not support dynamic client update over IPv6 or DHCPv6-based dynamic update, hosts on the home network will not be able to dynamically register or resolve the names of local IPv6 hosts. If the configured DNS server responds to AAAA RR queries sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then it will not be possible to resolve the names of IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for local name resolution. " ----------------------------------------------------------------- Issue 38: DNS proxy undefined Submitter: Andreas Gustafsson Submitter email address: gson@nominum.com Date first submitted: May 9, 2003 Reference: <200305100021.h4A0Ljhh009362@guava.araneus.fi> Document: LLMNR-18 Comment type: T Priority: S Section: 1, 3.2 Rationale/Explanation of issue: draft-ietf-dnsext-mdns-18.txt makes repeated references to an entity called a "DNS proxy". The term "DNS proxy" is not defined in the draft, and there is no DNS standard or RFC defining the behavior of such a device. Requested change: Remove all references to a "DNS proxy". [BA] Proposed resolution is to substitute "DNS server" for "DNS proxy" throughout. Kevin Darcy : I think "recursive resolver" would be more precise. "DNS server" could be mistaken for "authoritative server". Speaking of which, I think you use the term "DNS server" sometimes to mean an authoritative server, and at other times, to mean a recursive resolver. You should probably audit that usage simultaneously. Andreas Gustafsson, gson@nominum.com: The -18 draft also talked about the DNS proxy "supporting dynamic update", which makes no sense if it was indeed referring to a recursive resolver. In the scenario involving a "home gateway", DHCP, and dynamic DNS, there actually needs to be both a caching server (aka recursive resolver) and an authoritative server (where names are registered using DDNS), but each of these can independently be on the local wire, integrated into the gateway, or anywhere else on the Internet reachable through the gateway. Since the location of these servers is entirely immaterial, any time the draft mentions them being in a specific location or claiming that a "proxy" is needed to reach them, it is only confusing the issue. This is why I requested that any mention of a proxy be removed, not changed. -- 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 May 13 02:32:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28787 for ; Tue, 13 May 2003 02:32:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FTH9-000LJw-00 for namedroppers-data@psg.com; Tue, 13 May 2003 06:28:35 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 19FTH6-000LJg-00 for namedroppers@ops.ietf.org; Tue, 13 May 2003 06:28:32 +0000 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4D6UmHZ017739; Tue, 13 May 2003 09:30:48 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4D6UlPL017738; Tue, 13 May 2003 09:30:47 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR Issue 39: Name conflict detection algorithm From: Mika Liljeberg To: Joshua Graessley Cc: namedroppers@ops.ietf.org In-Reply-To: <1C182BC8-84CE-11D7-BAAC-000A959D832C@apple.com> References: <1C182BC8-84CE-11D7-BAAC-000A959D832C@apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1052807446.17101.12.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 13 May 2003 09:30:46 +0300 X-Spam-Status: No, hits=-39.4 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-05-13 at 02:04, Joshua Graessley wrote: > On Monday, May 12, 2003, at 15:16 US/Pacific, Bernard Aboba wrote: > > >>> A potential alternative is to mandate that hosts send an LLMNR query > >>> for their own name at some convenient interval (every 30 seconds?) > >> > >> That would be wasteful. > > > > Wouldn't it also be wasteful to send all responses to the same > > multicast group? > > The response packet has to be sent. If it's sent using multicast > instead of unicast it will reach more machines but at least a packet > wouldn't be sent when it isn't needed. Sending every 30 seconds is a > precaution, in case something is wrong. If two hosts are configured to > respond differently to LLMNR requests, there is no problem until > another host actually queries for the conflicting record. If no host > ever queries for that record, what do we gain by spewing traffic every > 30 seconds? I agree. There is no need to detect conflicts proactively. If people are worried about the CPU usage (and that is certainly a valid point), we can just leave the unicast responses as they are, but using multicast would simplify the code. > The multicast response could be used to build a cache on hosts > implementing LLMNR resolvers. This cache could be hit before a query > packet is generated on the wire, potentially eliminating additional > traffic. I'm not sure I'm comfortable with this one. This might make cache poisoning a bit too easy. Note that, for UDP unicast responses, comparing received responses to pending queries is currently our only defence against spoofed UDP unicast responses from off-link, since we no longer test TTL=255 for responses. MikaL -- 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 May 13 14:14:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23245 for ; Tue, 13 May 2003 14:14:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fe3u-00093W-00 for namedroppers-data@psg.com; Tue, 13 May 2003 17:59:38 +0000 Received: from mail-out2.apple.com ([17.254.0.51]) by psg.com with esmtp (Exim 3.36 #1) id 19Fe3p-000933-00 for namedroppers@ops.ietf.org; Tue, 13 May 2003 17:59:33 +0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h4DHxWnB007339 for ; Tue, 13 May 2003 10:59:32 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 13 May 2003 10:59:32 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h4DHxVUb017521 for ; Tue, 13 May 2003 10:59:31 -0700 (PDT) Date: Tue, 13 May 2003 10:59:32 -0700 Subject: Re: LLMNR Issue 39: Name conflict detection algorithm Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Joshua Graessley To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <1052807446.17101.12.camel@devil> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, May 12, 2003, at 23:30 US/Pacific, Mika Liljeberg wrote: >> The multicast response could be used to build a cache on hosts >> implementing LLMNR resolvers. This cache could be hit before a query >> packet is generated on the wire, potentially eliminating additional >> traffic. > > I'm not sure I'm comfortable with this one. This might make cache > poisoning a bit too easy. > > Note that, for UDP unicast responses, comparing received responses to > pending queries is currently our only defence against spoofed UDP > unicast responses from off-link, since we no longer test TTL=255 for > responses. Using multicast can help with this. If only multicast responses to multicast queries are accepted then cache poisoning becomes difficult. Any attempt to poison the cache using multicast would result in the detection of a conflict. The host with the "real" information would see the "spoofed" multicast response and likely handle it as a conflict. -josh -- 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 May 13 15:11:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25684 for ; Tue, 13 May 2003 15:11:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ff7T-000J78-00 for namedroppers-data@psg.com; Tue, 13 May 2003 19:07:23 +0000 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 19Ff7Q-000J6v-00 for namedroppers@ops.ietf.org; Tue, 13 May 2003 19:07:20 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 13 May 2003 12:07:20 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 May 2003 12:07:20 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 12:07:20 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 12:07:20 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 13 May 2003 12:07:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: LLMNR Issue 39: Name conflict detection algorithm Date: Tue, 13 May 2003 12:07:14 -0700 Message-ID: Thread-Topic: LLMNR Issue 39: Name conflict detection algorithm thread-index: AcMZgG6/LdZvpGSGQ1yWR6n0WEpcbgAAUggA From: "Christian Huitema" To: "Joshua Graessley" , X-OriginalArrivalTime: 13 May 2003 19:07:19.0656 (UTC) FILETIME=[E0542680:01C31982] X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA25684 > > Note that, for UDP unicast responses, comparing received responses to > > pending queries is currently our only defence against spoofed UDP > > unicast responses from off-link, since we no longer test TTL=255 for > > responses. > > Using multicast can help with this. If only multicast responses to > multicast queries are accepted then cache poisoning becomes difficult. Caching responses to someone else's queries does indeed open the gate to cache poisoning. An attacker can first forge a query, multicast it, and then send a forged multicast response. > Any attempt to poison the cache using multicast would result in the > detection of a conflict. The host with the "real" information would see > the "spoofed" multicast response and likely handle it as a conflict. In practice, that is not true. It is possible to send an IP multicast packet to a unicast link layer address, and it is very hard for the receiver to notice. I would agree however that sending the replies over UDP multicast is somewhat more secure than sending them over UDP unicast, as it is hard to send packets to a link-scope multicast address from a remote location. -- Christian Huitema -- 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 May 13 20:29:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05057 for ; Tue, 13 May 2003 20:29:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fk0h-0002V3-00 for namedroppers-data@psg.com; Wed, 14 May 2003 00:20:43 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 3.36 #1) id 19Fk0e-0002Ul-00 for namedroppers@ops.ietf.org; Wed, 14 May 2003 00:20:40 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h4E0KTh1019183; Tue, 13 May 2003 17:20:29 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h4E0KTBK026862; Tue, 13 May 2003 17:20:29 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h4E0KRIm026859; Tue, 13 May 2003 17:20:27 -0700 (PDT) Date: Tue, 13 May 2003 17:20:27 -0700 (PDT) Message-Id: <200305140020.h4E0KRIm026859@guava.araneus.fi> To: Bernard Aboba Cc: namedroppers@ops.ietf.org, llmnr-editors@internaut.com Subject: Re: Revised resolution Proposal for LLMNR Issue 38: DNS Proxy undefined In-Reply-To: References: X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-37.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bernard Aboba writes: > "Propagation of LLMNR packets on the local link is considered sufficient > to enable name resolution in small networks. The assumption is that if a > network has a home gateway, then the network either has DNS and DHCPv4 > servers or the home gateway provides DHCPv4 and DNS server functionality. > By providing Dynamic Host Configuration Service for IPv4 (DHCPv4), as > well as a DNS server with support for dynamic DNS, which is also > authoritative for the A RRs of local hosts, it is possible to support > resolution of local host names over IPv4. At the risk of repeating myself: there is no requirement that the DNS server is on the local network or the DNS functionality is provided by the home gateway. If a network has a gateway, it can use DNS servers anywhere on the Internet. > For small IPv6 networks, equivalent functionality can be provided by > implementing Dynamic Host Configuration Service for IPv6 (DHCPv6) for DNS > configuration [DHCPv6DNS], as well providing a DNS server with support for dynamic DNS, > which is also authoritative for the AAAA RRs of local hosts, it is > possible to support the resolution of local > host names over IPv6 as well as IPv4. " I'm unable to parse this sentence. > This should be adequate as long as home gateways implementing DNS > configuration also support dynamic DNS in some form." Again, there is no need for dynamic DNS to be supported specifically by the gateway. I suggest replacing the three quoted paragraphs above with the following single paragraph, which purposely omits any text implying that home gateway is the specific entity that provides DHCPv4, DHCPv6, recursive DNS, or dynamic authoritative DNS service: "Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a home gateway, DHCP and DNS are also available, and A and/or AAAA RRs of local hosts can be registered using dynamic DNS." > For example, a home network may provide a DHCPv4 server but may not > support DHCPv6 for DNS configuration [DHCPv6DNS]. In > such a circumstance, IPv6-only hosts will not be configured with a DNS > server. Where a DNS server is configured but > does not support dynamic client update > over IPv6 or DHCPv6-based dynamic update, hosts on the home network > will not be able to dynamically register or resolve the names of > local IPv6 hosts. If the configured DNS server > responds to AAAA RR queries sent over IPv4 or IPv6 with an authoritative > name error (RCODE=3), then it will not be possible to resolve the names > of IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for > local name resolution. " The above paragraph is hopelessly confused with regards to recursive versus authoritative servers. When a host is "configured with a DNS server" using DHCP, it is configured with a *recursive* server, while the server that needs to support dynamic update is the server authoritative for the host's domain name. These are two completely separate servers, but the text seems to imply that they are one and the same. I suggest this paragraph be removed. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 13 20:34:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05189 for ; Tue, 13 May 2003 20:34:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fk9S-000353-00 for namedroppers-data@psg.com; Wed, 14 May 2003 00:29:46 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19Fk9Q-00034n-00 for namedroppers@ops.ietf.org; Wed, 14 May 2003 00:29:44 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4E08Wq06329; Tue, 13 May 2003 17:08:32 -0700 Date: Tue, 13 May 2003 17:08:31 -0700 (PDT) From: Bernard Aboba To: Andreas Gustafsson cc: namedroppers@ops.ietf.org, llmnr-editors@internaut.com Subject: Re: Revised resolution Proposal for LLMNR Issue 38: DNS Proxy undefined In-Reply-To: <200305140020.h4E0KRIm026859@guava.araneus.fi> Message-ID: References: <200305140020.h4E0KRIm026859@guava.araneus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At the risk of repeating myself: there is no requirement that the DNS > server is on the local network or the DNS functionality is provided by > the home gateway. If a network has a gateway, it can use DNS servers > anywhere on the Internet. Not sure why you've chosen to comment on the old text rather than the new proposed text. -- 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 May 13 20:58:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05683 for ; Tue, 13 May 2003 20:58:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FkUk-0004Ui-00 for namedroppers-data@psg.com; Wed, 14 May 2003 00:51:46 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 3.36 #1) id 19FkUi-0004US-00 for namedroppers@ops.ietf.org; Wed, 14 May 2003 00:51:44 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h4E0pfh1019323; Tue, 13 May 2003 17:51:41 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h4E0pfBK026898; Tue, 13 May 2003 17:51:41 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h4E0pfYk026895; Tue, 13 May 2003 17:51:41 -0700 (PDT) Date: Tue, 13 May 2003 17:51:41 -0700 (PDT) Message-Id: <200305140051.h4E0pfYk026895@guava.araneus.fi> To: Bernard Aboba CC: namedroppers@ops.ietf.org, llmnr-editors@internaut.com Subject: Re: Revised resolution Proposal for LLMNR Issue 38: DNS Proxy undefined In-Reply-To: Re: References: <200305140020.h4E0KRIm026859@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-37.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bernard Aboba writes: > Not sure why you've chosen to comment on the old text rather than the new > proposed text. Pardon me, I didn't notice the following piece of text had been removed and commented on it accidentally: > This should be adequate as long as home gateways implementing DNS > configuration also support dynamic DNS in some form." The rest of the text I quoted and commented on was, as far as I can see, the new proposed text. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 14 06:18:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11158 for ; Wed, 14 May 2003 06:18:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ft5x-0003yd-00 for namedroppers-data@psg.com; Wed, 14 May 2003 10:02:45 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Ft5v-0003yQ-00 for namedroppers@ops.ietf.org; Wed, 14 May 2003 10:02:43 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19Ft5u-0002uw-MQ for namedroppers@ops.ietf.org; Wed, 14 May 2003 12:02:42 +0200 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 14 May 2003 11:12:02 +0200 (CEST) From: Erik Guttman To: Bernard Aboba cc: namedroppers@ops.ietf.org Subject: llmnr issue 39 Name conflict detection algorithm X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,IN_REP_TO,USER_AGENT_PINE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Bernard, I agree that multicasting the name with the conflict would be easier to implement (and specify correctly). If this multicast occurs to a link local multicast group destination, it would be hard for an attacker send it to another link. This mitigates the security risk of caching. I assume the host (llmnr responder) receiving these multicast unsolicited replies can distinguish the difference between a message sent to multicast and unicast destinations. Either a separate listener (socket, or whatever) should be used to listen for unicast requests, to differentiate them from multicast requests - or the 'destination address' of the received datagram should be examined. Erik -- 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 May 14 07:31:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13078 for ; Wed, 14 May 2003 07:31:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FuLs-000Fd8-00 for namedroppers-data@psg.com; Wed, 14 May 2003 11:23:16 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19FuLp-000Fct-00 for namedroppers@ops.ietf.org; Wed, 14 May 2003 11:23:13 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12608; Wed, 14 May 2003 07:20:08 -0400 (EDT) Message-Id: <200305141120.HAA12608@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-19.txt Date: Wed, 14 May 2003 07:20:07 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-19.txt Pages : 21 Date : 2003-5-13 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name Service (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-19.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mdns-19.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-mdns-19.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: <2003-5-13132927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-13132927.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 May 14 11:43:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22568 for ; Wed, 14 May 2003 11:43:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FyEv-0001HV-00 for namedroppers-data@psg.com; Wed, 14 May 2003 15:32:21 +0000 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 19FyEt-0001HJ-00 for namedroppers@ops.ietf.org; Wed, 14 May 2003 15:32:19 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Wed, 14 May 2003 08:32:18 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 May 2003 08:32:18 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 14 May 2003 08:32:18 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 14 May 2003 08:32:17 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 14 May 2003 08:32:16 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Wed, 14 May 2003 08:32:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: llmnr issue 39 Name conflict detection algorithm Date: Wed, 14 May 2003 08:32:15 -0700 Message-ID: Thread-Topic: llmnr issue 39 Name conflict detection algorithm thread-index: AcMaBAVz+HUepqMqTzG4hzCm5inbmQAJyhiA From: "Christian Huitema" To: "Erik Guttman" , "Bernard Aboba" Cc: X-OriginalArrivalTime: 14 May 2003 15:32:16.0743 (UTC) FILETIME=[00019F70:01C31A2E] X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA22568 I am afraid that there is no good solution to this problem. I don't like the idea of multicasting all replies, as it is either wasteful or dangerous; and I also really don't like anything that relies on periodic broadcast by all hosts on a network, as it has obvious potential for melt-down. Let's expand on why multicast replies are wasteful or dangerous. There is a proposed design in which hosts listen to all replies, even those to queries they did not issue, and cache the response. The idea is that multicast may be costly, but this cost would be compensated by more extensive caching. The problem is that such design is a powerful tool for an on-link attacker: the attacker can issue a spoofed query and then broadcast spoofed responses, effectively polluting the caches of all on-link hosts. In practice, a responsible host will only accept responses to its own queries. It will ignore the other broadcast responses. The multicast will just be wasteful. My real issue with name conflict detection is whether it is actually needed. Take the IETF network. Suppose that two attendees come in with the laptops "zeus.example1.com" and "zeus.example2.net". There will be a conflict for the unqualified name "zeus", but is that a bug that needs be fixed? None of the two laptops is going to change its name, as that would probably invalidate various security credentials and other certificates. I guess we will just have to live with it. If names are picked at random, then we can just as well pick them from a space large enough to avoid the birthday paradox, and periodic checks will not be particularly useful. If we assume that names are configured, then periodic checks are not needed either. The administrator may perform the check during the configuration procedure, or compare to a master file kept somewhere, on a computer or a notebook. The administrator may also at a later stage perform inventories of the network, e.g. by listening to traffic, collecting IP addresses and performing reverse look-ups. In summary, I would rather rely on occasional checks triggered by an administrative action, rather than increase the amount of broadcast on the network. -- Christian Huitema -- 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 May 15 03:59:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00220 for ; Thu, 15 May 2003 03:59:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GDU8-0001LH-00 for namedroppers-data@psg.com; Thu, 15 May 2003 07:49:04 +0000 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 19GDU6-0001L4-00 for namedroppers@ops.ietf.org; Thu, 15 May 2003 07:49:02 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4F7n0sa023064 for ; Thu, 15 May 2003 01:49:01 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4F7n0L01959 for ; Thu, 15 May 2003 09:49:00 +0200 (MEST) Date: Thu, 15 May 2003 09:48:25 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: rfc1886bis - need updated implementation report To: namedroppers@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The discussion about rfc1886bis on the mailing list resulted (as far as I remember) in that the I-D is fine but that the implementation report should be made more clear regarding additional section processing. Once I have an updated implementation report I can start the IETF last call for draft standard. Erik -- 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 May 15 12:20:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14153 for ; Thu, 15 May 2003 12:20:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GLHp-000Fm3-00 for namedroppers-data@psg.com; Thu, 15 May 2003 16:08:53 +0000 Received: from host98-203-65-207.isd.net ([207.65.203.98] helo=goose.ehsco.com) by psg.com with esmtp (Exim 3.36 #1) id 19GLHC-000Fcj-00 for namedroppers@ops.ietf.org; Thu, 15 May 2003 16:08:14 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0) with ESMTP-TLS id 206803; Thu, 15 May 2003 11:07:35 -0500 Message-ID: <3EC3BB69.4000607@ehsco.com> Date: Thu, 15 May 2003 11:08:09 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Christian Huitema CC: Erik Guttman , Bernard Aboba , namedroppers@ops.ietf.org Subject: Re: llmnr issue 39 Name conflict detection algorithm References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Another option is to stick the client name into the request message, perhaps using a special RR in the authority or additional-data sections. Other clients which are monitoring the multicast channel can watch for collisions and take whatever recovery steps are needed. That would only increase the request size by a small percentage, and wouldn't generate any additional messages. on 5/14/2003 10:32 AM Christian Huitema wrote: > I am afraid that there is no good solution to this problem. I don't like > the idea of multicasting all replies, as it is either wasteful or > dangerous; and I also really don't like anything that relies on periodic > broadcast by all hosts on a network, as it has obvious potential for > melt-down. > > Let's expand on why multicast replies are wasteful or dangerous. There > is a proposed design in which hosts listen to all replies, even those to > queries they did not issue, and cache the response. The idea is that > multicast may be costly, but this cost would be compensated by more > extensive caching. The problem is that such design is a powerful tool > for an on-link attacker: the attacker can issue a spoofed query and then > broadcast spoofed responses, effectively polluting the caches of all > on-link hosts. In practice, a responsible host will only accept > responses to its own queries. It will ignore the other broadcast > responses. The multicast will just be wasteful. > > My real issue with name conflict detection is whether it is actually > needed. Take the IETF network. Suppose that two attendees come in with > the laptops "zeus.example1.com" and "zeus.example2.net". There will be a > conflict for the unqualified name "zeus", but is that a bug that needs > be fixed? None of the two laptops is going to change its name, as that > would probably invalidate various security credentials and other > certificates. I guess we will just have to live with it. > > If names are picked at random, then we can just as well pick them from a > space large enough to avoid the birthday paradox, and periodic checks > will not be particularly useful. If we assume that names are configured, > then periodic checks are not needed either. The administrator may > perform the check during the configuration procedure, or compare to a > master file kept somewhere, on a computer or a notebook. The > administrator may also at a later stage perform inventories of the > network, e.g. by listening to traffic, collecting IP addresses and > performing reverse look-ups. > > In summary, I would rather rely on occasional checks triggered by an > administrative action, rather than increase the amount of broadcast on > the network. > > -- Christian Huitema > > > -- > 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: -- 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 Thu May 15 15:22:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20483 for ; Thu, 15 May 2003 15:22:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GO88-000BeU-00 for namedroppers-data@psg.com; Thu, 15 May 2003 19:11:04 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19GO7M-000BVd-00 for namedroppers@ops.ietf.org; Thu, 15 May 2003 19:10:16 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FImsj20259 for ; Thu, 15 May 2003 11:48:55 -0700 Date: Thu, 15 May 2003 11:48:54 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Another shot at LLMNR Issue 38: DNS Proxy Undefined Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A little background on why IMO some additional text is required. The issue is that there are a number of potential IPv6 DNS configuration mechanisms, and not all of them guarantee availability of local name resolution. For example, if an anycast DNS server address is configured, but there is no DNS server listening on that address, then LLMNR queries will be restricted (only unqualified names or names in the default domain), even though this situation is not very different from the case in which no DNS server is configured. However if DHCPv6 is used to configure the DNS server, then it is more likely that the DNS server actually exists. Also, on a home network it is most likely that dynamic DNS will be supported via DHCP/DDNS update, not client update. This would imply a need for DHCPv6 support. In Section 1, Change text to: "Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. The assumption is that if a network has a home gateway, then the network has DNS and DHCP servers. If a DHCPv4 server is available, as well as a DNS server authoritative for the A RRs of local hosts which also supports dynamic DNS, it is possible to support resolution of local host names over IPv4 without LLMNR. For small IPv6 networks, if a DHCPv6 server is available, as well as a DNS server authoritative for the AAAA RRs of local hosts which also supports dynamic DNS, it is possible to support resolution of local host names over IPv6 as well as IPv4 without LLMNR." In Section 3.2, change text to: "LLMNR usage MAY be configured manually or automatically on a per interface basis. By default, LLMNR responders SHOULD be enabled on all interfaces, at all times. Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual stack host to be configured with the address of a DNS server over IPv4, while remaining unconfigured with a DNS server suitable for use over IPv6. In these situations, a dual stack host will send AAAA queries to the configured DNS server over IPv4. However, an IPv6-only host unconfigured with a DNS server suitable for use over IPv6 will be unable to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and [DNSDisc]) are not yet widely deployed, and not all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration may be a common problem in the short term, and LLMNR may prove useful in enabling linklocal name resolution over IPv6. For example, a DHCPv4 server may be available but not a DHCPv6 server [DHCPv6DNS]. As a result, IPv6-only hosts would not be configured with a DNS server. Where a DNS server is configured, but there is either no DNS server authoritative for the names of hosts on the local network or the authoritative DNS server does not support dynamic client update over IPv6 or DHCPv6-based dynamic update, then hosts on the home network will not be able to dynamically register or resolve the names of local IPv6 hosts. For example, if the configured DNS server responds to AAAA RR queries sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then it will not be possible to resolve the names of IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for local name resolution. Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to configure LLMNR on an interface. The LLMNR Enable Option, described in [LLMNREnable], can be used to explicitly enable or disable use of LLMNR on an interface. The LLMNR Enable Option does not determine whether or in which order DNS itself is used for name resolution. The order in which various name resolution mechanisms should be used can be specified using the Name Service Search Option for DHCP [RFC2937]." -- 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 May 15 18:05:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24651 for ; Thu, 15 May 2003 18:05:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GQkQ-000C96-00 for namedroppers-data@psg.com; Thu, 15 May 2003 21:58:46 +0000 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #1) id 19GQju-000C82-00 for namedroppers@ops.ietf.org; Thu, 15 May 2003 21:58:14 +0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h4FLwBx6028420 for ; Thu, 15 May 2003 14:58:11 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 15 May 2003 14:57:56 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id h4FLw9Gd028989 for ; Thu, 15 May 2003 14:58:10 -0700 (PDT) Date: Thu, 15 May 2003 14:58:10 -0700 Subject: Re: llmnr issue 39 Name conflict detection algorithm Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Joshua Graessley To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <5155500D-8720-11D7-A3A2-000A959D832C@apple.com> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, May 14, 2003, at 08:32 US/Pacific, Christian Huitema wrote: > I am afraid that there is no good solution to this problem. I don't > like > the idea of multicasting all replies, as it is either wasteful or > dangerous; and I also really don't like anything that relies on > periodic > broadcast by all hosts on a network, as it has obvious potential for > melt-down. We have operational experience with a wide deployment of an implementation of something similar to LLMNR that uses multicasts for responses to quickly detect conflicts and to implement caching. We have received no reports of melt-downs nor have we experienced any such problems here at Apple. > Let's expand on why multicast replies are wasteful or dangerous. There > is a proposed design in which hosts listen to all replies, even those > to > queries they did not issue, and cache the response. The idea is that > multicast may be costly, but this cost would be compensated by more > extensive caching. The problem is that such design is a powerful tool > for an on-link attacker: the attacker can issue a spoofed query and > then > broadcast spoofed responses, effectively polluting the caches of all > on-link hosts. In practice, a responsible host will only accept > responses to its own queries. It will ignore the other broadcast > responses. The multicast will just be wasteful. A node can do the wrong thing and wreck havoc on the local network. In the case you note, the multicast would be detected by anyone advertising conflict data and the conflict detection would kick in. Someone could use a unicast hardware address with a multicast IP address to spoof a response to just one node. The network is a shared resource, unless encryption and authentication is used, it can not be made secure. -josh -- 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 May 15 18:37:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26490 for ; Thu, 15 May 2003 18:37:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GREu-000HSp-00 for namedroppers-data@psg.com; Thu, 15 May 2003 22:30:16 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19GREO-000HOz-00 for namedroppers@ops.ietf.org; Thu, 15 May 2003 22:29:44 +0000 Received: by sentry.rv.nailabs.com; id SAA27682; Thu, 15 May 2003 18:30:57 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma027669; Thu, 15 May 03 18:30:16 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6/8.11.6) with ESMTP id h4FMT0h15372 for ; Thu, 15 May 2003 18:29:00 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Thu, 15 May 2003 18:29:00 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Subject: draft-ietf-dnsext-dnssec-2535typecode-change-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_PINE, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk A new version of the typecode draft has been published. http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-00.txt Changes since the last version: Suggested specific type codes and mnemonics. Clarified interactions between the old and new types. Reordered the document. Added sections on incrementing the EDNS version number, doing nothing, and specific protocol changes, as well as an acknowledgements section. Substantially rewrote the introduction. -- Sam On Sun, 2 Mar 2003, Sam Weiler wrote: > This document describes a solution to a backwards incompatibility > problem between DS and resolvers that understand RFC2535. The > proposed solution of rolling the DNSSEC RR type codes has been > implemented and received some testing at the opt-in workshop at RIPE > in January (see Olaf's message of 5 Feburary and the ensuing > discussion). The same problem may be triggered when legacy resolvers > see proofs of delegations being in insecure spans using opt-in, > but this has not been tested. > > This problem was diagnosed by Jakob Schlyter and Mark Andrews earlier > this year, though it probably caused some of the misbehavior seen on > testbeds and in workshops last year. -- 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 May 16 06:43:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18689 for ; Fri, 16 May 2003 06:43:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GcVm-0003Zt-00 for namedroppers-data@psg.com; Fri, 16 May 2003 10:32:26 +0000 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 19GcV0-0003OX-00 for namedroppers@ops.ietf.org; Fri, 16 May 2003 10:31:38 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4GAVaY9005793 for ; Fri, 16 May 2003 04:31:36 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4GAVVL26102 for ; Fri, 16 May 2003 12:31:32 +0200 (MEST) Date: Fri, 16 May 2003 10:15:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknown DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown-rrs-05 To: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <0449D80A0E9B614A83FA9031B07E8D3B257A77@stntexch2.va.neustar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document was discussed by the IESG yesterday. Based on the comment from the IANA (below) I think it makes sense to say in the IANA considerations section that the IANA will request expert review (by an expert designated by the IESG) for all RR types that they are asked to allocate in order to check the compression issue. We could either designate an expert now or wait until the first such request arrives from the IANA. Erik >----- Begin Included Message -----< Date: Thu, 15 May 2003 08:03:58 -0700 From: "Michelle S. Cotton" Subject: FW: Last Call: Handling of Unknown DNS Resource Record Types to Proposed Standard To: "Erik Nordmark" Cc: IESG@ietf.org Erik, Sorry for being late on this. Jon's recent comment reminded me of the outstanding issue. The IANA Consideratios says the following: 9. IANA Considerations The IANA is hereby requested to verify that specifications for new RR types requesting an RR type number comply with this specification. In particular, the IANA MUST NOT assign numbers to new RR types whose specification allows embedded domain names to be compressed. This is not quite clear yet. If we receive a request for a RR type number, I understand the specification for the RR type should comply with this specification. I'm worried about haveing the expertise to be able to review the spec and make sure that it complies with this doc and to decide whether or not the spec allows embedded domain names. Will there be an expert for these types of requests to assist the IANA? Hope that makes my concerns clear. Thanks, Michelle -----Original Message----- From: iesg-admin@ietf.org [mailto:iesg-admin@ietf.org]On Behalf Of Erik Nordmark Sent: Friday, April 11, 2003 6:45 AM To: Andreas Gustafsson Cc: Erik Nordmark; IANA; iesg@ietf.org; Randy Bush; ogud@ogud.com Subject: RE: Last Call: Handling of Unknown DNS Resource Record Types to Proposed Standard > The draft does not ask IANA to enforce anything in the case of private > use. It says "The IANA is hereby requested to verify that > specifications for new RR types *requesting an RR type number* comply > with this specification" (my emphasis). In the case of private use, > no RR type is being requested, and therefore IANA is not asked to > verify compliance - in fact, IANA is not involved at all. Good point. IANA, is there something which needs to be clarified? Erik >----- End Included Message -----< -- 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 May 16 07:29:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19759 for ; Fri, 16 May 2003 07:29:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GdKb-000C5h-00 for namedroppers-data@psg.com; Fri, 16 May 2003 11:24:57 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19GdK5-000C4x-00 for namedroppers@ops.ietf.org; Fri, 16 May 2003 11:24: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 HAA19231; Fri, 16 May 2003 07:21:19 -0400 (EDT) Message-Id: <200305161121.HAA19231@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-2535typecode-change-00.txt Date: Fri, 16 May 2003 07:21:18 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Legacy Resolver Compatibility for Delegation Signer Author(s) : S. Weiler Filename : draft-ietf-dnsext-dnssec-2535typecode-change-00.txt Pages : 5 Date : 2003-5-15 As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document proposes that these interactions be avoided by changing the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-dnssec-2535typecode-change-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-15145515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-2535typecode-change-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-15145515.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 May 16 07:39:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20069 for ; Fri, 16 May 2003 07:39:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GdUC-000DaB-00 for namedroppers-data@psg.com; Fri, 16 May 2003 11:34:52 +0000 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 19GdTg-000DYy-00 for namedroppers@ops.ietf.org; Fri, 16 May 2003 11:34:20 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id h4GBYIm18260; Fri, 16 May 2003 13:34:18 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h4GBYHK02399; Fri, 16 May 2003 13:34:17 +0200 (MEST) Message-Id: <200305161134.h4GBYHK02399@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: Erik Nordmark Cc: namedroppers@ops.ietf.org Subject: Re: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknown DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown-rrs-05 In-reply-to: Your message of "Fri, 16 May 2003 10:15:56 +0200." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Fri, 16 May 2003 13:34:17 +0200 From: Peter Koch X-Spam-Status: No, hits=-14.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > request expert review (by an expert designated by the IESG) for all > RR types that they are asked to allocate in order to check the > compression issue. That expert should also evaluate the per RR versioning issue. -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 Sat May 17 12:49:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11170 for ; Sat, 17 May 2003 12:49:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19H4jE-000JeL-00 for namedroppers-data@psg.com; Sat, 17 May 2003 16:40:12 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19H4jC-000JZc-00 for namedroppers@ops.ietf.org; Sat, 17 May 2003 16:40:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 076B21390E for ; Sat, 17 May 2003 16:39:57 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: regarding ed lewis' proposal to make opt-in experimental X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 17 May 2003 16:39:57 +0000 Message-Id: <20030517163957.076B21390E@sa.vix.com> X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,OPT_IN version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i think this is the right compromise under the new circumstances. -- 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 May 18 13:52:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13461 for ; Sun, 18 May 2003 13:52:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HS7n-000P1U-00 for namedroppers-data@psg.com; Sun, 18 May 2003 17:39:07 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 3.36 #1) id 19HS7j-000P13-00 for namedroppers@ops.ietf.org; Sun, 18 May 2003 17:39:03 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h4IHd1h1010957; Sun, 18 May 2003 10:39:02 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h4IHd0BK005045; Sun, 18 May 2003 10:39:00 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h4IHd0pq005037; Sun, 18 May 2003 10:39:00 -0700 (PDT) Date: Sun, 18 May 2003 10:39:00 -0700 (PDT) Message-Id: <200305181739.h4IHd0pq005037@guava.araneus.fi> To: Erik Nordmark Cc: namedroppers@ops.ietf.org Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknown DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown-rrs-05 In-Reply-To: References: <0449D80A0E9B614A83FA9031B07E8D3B257A77@stntexch2.va.neustar.com> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-37.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > This document was discussed by the IESG yesterday. > > Based on the comment from the IANA (below) I think it makes sense > to say in the IANA considerations section that the IANA will > request expert review (by an expert designated by the IESG) for all > RR types that they are asked to allocate in order to check the > compression issue. > > We could either designate an expert now or wait until the first such request > arrives from the IANA. The IANA considerations section of unknown-rrs predates RFC2929, and many of the concerns that led to the existing wording are now adequately covered by RFC2929. RFC2929 allows for three types of allocation in separate RR type number ranges: IETF Consensus, Specification Required, and Private Use. When an allocation is made based on IETF consensus, the RR type specification has already received extensive review in the working group, the IETF last call, and the IESG; therefore, I don't see a need for an additional step of expert review in this case. In the case of Private Use, no review is possible since neither IETF nor IANA is involved. This leaves Specification Required as a case where expert review could potentially be useful. However, since the reason for having a separate Specification Required policy in the first place would be to provide a more streamlined option for registering new types, it would seem that introducing a mandatory step of expert review would diminish the utility of having multiple policies. Therefore, my suggestion is to simply remove the IANA Considerations section from the draft. Any objections? -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon May 19 06:18:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14094 for ; Mon, 19 May 2003 06:18:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HhQq-000Jlj-00 for namedroppers-data@psg.com; Mon, 19 May 2003 09:59:48 +0000 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 19HhQm-000JlU-00 for namedroppers@ops.ietf.org; Mon, 19 May 2003 09:59:44 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4J9xgHN019366; Mon, 19 May 2003 02:59:42 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4J9xaL14560; Mon, 19 May 2003 11:59:36 +0200 (MEST) Date: Mon, 19 May 2003 11:14:44 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknown DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown-rrs-05 To: Andreas Gustafsson Cc: Erik Nordmark , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200305181739.h4IHd0pq005037@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > RFC2929 allows for three types of allocation in separate RR type > number ranges: IETF Consensus, Specification Required, and Private > Use. When an allocation is made based on IETF consensus, the RR type > specification has already received extensive review in the working > group, the IETF last call, and the IESG; therefore, I don't see a need > for an additional step of expert review in this case. In the case of > Private Use, no review is possible since neither IETF nor IANA is > involved. Just a note that your interpretation of IETF consensus doesn't quite match RFC 2434 - that RFC doesn't mention an IETF last call: IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). > This leaves Specification Required as a case where expert review could > potentially be useful. However, since the reason for having a > separate Specification Required policy in the first place would be to > provide a more streamlined option for registering new types, it would > seem that introducing a mandatory step of expert review would diminish > the utility of having multiple policies. > > Therefore, my suggestion is to simply remove the IANA Considerations > section from the draft. Any objections? As long as the WG is ok with the implications of that I don't see a problem. For clarity if makes sense to retina the section and say explicitly that there are no IANA actions associated with this document. Erik -- 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 May 19 09:27:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20317 for ; Mon, 19 May 2003 09:27:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HkZe-000HCN-00 for namedroppers-data@psg.com; Mon, 19 May 2003 13:21:06 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19HkZb-000HBy-00 for namedroppers@ops.ietf.org; Mon, 19 May 2003 13:21:03 +0000 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h4JDL153025641; Mon, 19 May 2003 06:21:01 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 May 2003 06:21:01 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Erik Nordmark'" , Andreas Gustafsson Cc: namedroppers@ops.ietf.org Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknow n DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown- rrs-05 Date: Mon, 19 May 2003 06:20:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rather than delete the section entirely why not point it to the RFCs where the IANA considerations are considered? I agree that there is no need to have an expert review to make sure that extensions work with the deployed infrastructure, those that do not comply will not deploy, problem solved. Phill > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Monday, May 19, 2003 5:15 AM > To: Andreas Gustafsson > Cc: Erik Nordmark; namedroppers@ops.ietf.org > Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of > Unknown DNS Resource Record Types to Proposed > Standardraft-ietf-dnsext-unknown-rrs-05 > > > > RFC2929 allows for three types of allocation in separate RR type > > number ranges: IETF Consensus, Specification Required, and Private > > Use. When an allocation is made based on IETF consensus, > the RR type > > specification has already received extensive review in the working > > group, the IETF last call, and the IESG; therefore, I don't > see a need > > for an additional step of expert review in this case. In > the case of > > Private Use, no review is possible since neither IETF nor IANA is > > involved. > > Just a note that your interpretation of IETF consensus doesn't quite > match RFC 2434 - that RFC doesn't mention an IETF last call: > IETF Consensus - New values are assigned through the IETF > consensus process. Specifically, new assignments > are made via > RFCs approved by the IESG. Typically, the IESG will seek > input on prospective assignments from appropriate persons > (e.g., a relevant Working Group if one exists). > > > This leaves Specification Required as a case where expert > review could > > potentially be useful. However, since the reason for having a > > separate Specification Required policy in the first place > would be to > > provide a more streamlined option for registering new > types, it would > > seem that introducing a mandatory step of expert review > would diminish > > the utility of having multiple policies. > > > > Therefore, my suggestion is to simply remove the IANA Considerations > > section from the draft. Any objections? > > As long as the WG is ok with the implications of that I don't > see a problem. > For clarity if makes sense to retina the section and say explicitly > that there are no IANA actions associated with this document. > > Erik > > > -- > 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 May 19 20:47:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11749 for ; Mon, 19 May 2003 20:47:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Hv5Q-000Jre-00 for namedroppers-data@psg.com; Tue, 20 May 2003 00:34:36 +0000 Received: from mail-out2.apple.com ([17.254.0.51]) by psg.com with esmtp (Exim 3.36 #1) id 19Hv5O-000JrR-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 00:34:34 +0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h4K0YVBx010025 for ; Mon, 19 May 2003 17:34:31 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 19 May 2003 17:34:31 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.12.9/8.12.9) with SMTP id h4K0YSI2029392; Mon, 19 May 2003 17:34:31 -0700 (PDT) Message-Id: <200305200034.h4K0YSI2029392@scv3.apple.com> Subject: Finding server for Dynamic Update? Date: Mon, 19 May 2003 17:34:30 -0700 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-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Question: To do a DNS Update, you need to know the DNS server to which the Update packet should be sent. My intended algorithm would simply be to find the parent zone name of the name being updated (e.g. from the SOA record), and then look up the NS records for that zone name, and then send the Update to one of those DNS servers. Unfortunately, some sites have Update enabled on only *one* server, and that server is *not* listed in the NS records. One solution would be simply to make the end user manually configure the name of the Update server, but I'd rather not put that additional configuration burden on the end user. The established DNS mechanism for locating an instance of some service is SRV records. Perhaps this offers a solution for discovering a domain's update servers? The problem here is that the SRV name "_domain._udp.apple.com." doesn't make any distinction between the two different services "DNS Update" and "DNS Query". Both Update and Query use DNS protocol on port 53, but semantically they are quite different services. The solution I have in mind is to use some other name, such as "_domainupdate._udp.apple.com." Even though the port number is usually still 53, this SRV record would denote a semantically different service. When a client looks up this SRV record, it is conveying that it is seeking the entity that handles DNS updates for that domain, not just any old DNS server that only handles queries. An alternative naming, which reflects the status of "update" servers as a subset of all DNS servers, might be "_update._domain._udp.apple.com." This naming is logical, but it doesn't follow the strict "_application-protocol._transport-protocol." structure recommended in RFC 2782. Of course, the DNS server doesn't care whether the name follows the RFC 2782 convention -- the question is whether human operators think it is important. It really doesn't matter what name we pick, as long as we can pick one name and agree on it. Comments? 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 Mon May 19 21:59:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12867 for ; Mon, 19 May 2003 21:59:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HwGl-000Ok8-00 for namedroppers-data@psg.com; Tue, 20 May 2003 01:50:23 +0000 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 19HwGj-000Ojv-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 01:50:21 +0000 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id DFB121B2003; Mon, 19 May 2003 19:48:08 -0500 (CDT) Date: Mon, 19 May 2003 20:50:19 -0500 Subject: Re: Finding server for Dynamic Update? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: Stuart Cheshire From: Ted Lemon In-Reply-To: <200305200034.h4K0YSI2029392@scv3.apple.com> Message-Id: <696B069A-8A65-11D7-BBB3-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit What I did to solve this problem was to look up the SOA record. Say you're trying to update gnorf.foo.example.com. So you look for an SOA record on gnorf.foo.example.com., and if it's there, you send the update there. If there's no SOA record there, you look for one on foo.example.com., and then example.com., and then com., and then '.'. (You can probably skip the last two... :') In any case, it's unlikely that a name server is going to accept an update without a signature, so you're going to have to put some configuration goo on the client anyway. So why not include the IP address of the real primary for the zone? Since the client is probably updating its home server wherever it is, this isn't a collection of data that's going to have to change with any frequency, so it's not as bad as requiring someone to, for example, type in the IP address of a DNS resolver. -- 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 May 19 22:23:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13351 for ; Mon, 19 May 2003 22:23:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Hwgy-0001IT-00 for namedroppers-data@psg.com; Tue, 20 May 2003 02:17:28 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19Hwgv-0001Cu-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 02:17:25 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4K2Gpab094446; Tue, 20 May 2003 12:16:51 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4K2Gpsc001653; Tue, 20 May 2003 12:16:51 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305200216.h4K2Gpsc001653@drugs.dv.isc.org> To: Stuart Cheshire Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Finding server for Dynamic Update? In-reply-to: Your message of "Mon, 19 May 2003 17:34:30 MST." <200305200034.h4K0YSI2029392@scv3.apple.com> Date: Tue, 20 May 2003 12:16:51 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Question: > > To do a DNS Update, you need to know the DNS server to which the Update > packet should be sent. > > My intended algorithm would simply be to find the parent zone name of the > name being updated (e.g. from the SOA record), and then look up the NS > records for that zone name, and then send the Update to one of those DNS > servers. That is how update is designed to work. You send to the listed nameservers and it is their job to get it to the primary master. The only optimisation the client is supposed to make is to use the SOA MNAME first if it is in the NS set. This allows UPDATE to work through firewalls is a controlled manned. If a given server doesn't support UPDATE forwarding then NOTIMP should be returned (early named's got this wrong). We query for SOA and don't cache NXDOMAIN responses to SOA queries. We also generate uncachable responses to SOA queries. This allows you to discover the zone without negative side effects. Note with reverse lookups the client may want to re-write the ownername to deal with RFC 2317 style delegations. > Unfortunately, some sites have Update enabled on only *one* server, and > that server is *not* listed in the NS records. This is a misconfiguration. > One solution would be simply to make the end user manually configure the > name of the Update server, but I'd rather not put that additional > configuration burden on the end user. > > The established DNS mechanism for locating an instance of some service > is SRV records. Perhaps this offers a solution for discovering > a domain's update servers? The problem here is that the SRV name > "_domain._udp.apple.com." doesn't make any distinction between the two > different services "DNS Update" and "DNS Query". Both Update and Query > use DNS protocol on port 53, but semantically they are quite different > services. > > The solution I have in mind is to use some other name, such as > "_domainupdate._udp.apple.com." Even though the port number is usually > still 53, this SRV record would denote a semantically different service. > When a client looks up this SRV record, it is conveying that it is > seeking the entity that handles DNS updates for that domain, not > just any old DNS server that only handles queries. > > An alternative naming, which reflects the status of "update" servers as > a subset of all DNS servers, might be "_update._domain._udp.apple.com." > This naming is logical, but it doesn't follow the strict > "_application-protocol._transport-protocol." structure recommended in > RFC 2782. Of course, the DNS server doesn't care whether the name > follows the RFC 2782 convention -- the question is whether human > operators think it is important. > > It really doesn't matter what name we pick, as long as we can pick one > name and agree on it. > > Comments? > > 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: -- Mark Andrews, Internet Software Consortium 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 Tue May 20 10:29:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15520 for ; Tue, 20 May 2003 10:29:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I7x3-00090P-00 for namedroppers-data@psg.com; Tue, 20 May 2003 14:18:49 +0000 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 19I7x1-00090C-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 14:18:47 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4KEIhsa024730; Tue, 20 May 2003 08:18:44 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4KEIhL04386; Tue, 20 May 2003 16:18:43 +0200 (MEST) Date: Tue, 20 May 2003 16:18:00 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknow n DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown- rrs-05 To: "Hallam-Baker, Phillip" Cc: "'Erik Nordmark'" , Andreas Gustafsson , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Rather than delete the section entirely why not point it to the RFCs where > the IANA considerations are considered? Works for me. Thomas has some additional requests for clarifications that I'll forward when I receive them. Erik -- 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 May 20 11:32:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17851 for ; Tue, 20 May 2003 11:32:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I8wT-0006EA-00 for namedroppers-data@psg.com; Tue, 20 May 2003 15:22:17 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19I8wR-0006Dj-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 15:22:15 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19I8wQ-0005QS-KV for namedroppers@ops.ietf.org; Tue, 20 May 2003 08:22:14 -0700 Message-ID: <3EC4FBA2.9060909@sun.com> MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 16 May 2003 16:54:26 +0200 From: Erik Guttman To: Christian Huitema CC: Bernard Aboba , namedroppers@ops.ietf.org, erik.guttman@sun.com Subject: Re: llmnr issue 39 Name conflict detection algorithm X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Christian, Christian Huitema wrote: > I am afraid that there is no good solution to this problem. The real question is - what is the problem? Early on in the work on this protocol it was asserted that it would be unacceptable to allow multiple hosts to respond to the same name. (I do not remember who asserted this.) If we accept it is necessary to detect and correct the situation where more than one llmnr responder responds authoritatively to the same name we need either a proactive or reactive approach. But do we really need to accept this requirement? There are for example cases where we *want* multiple responders to answer to the same name (if the hosts support redundant identical services, for example.) It could be inconvenient and confusing for a user to get inconsistent results to a request. But in this case, can't the user intervene? The host had to have *gotten* its name somehow. If this was a manual administrative assignment, only a similar assignment should be done to change the name. The name may have been assigned automatically , by a program which attempted to assign a unique name. This same program could periodically test to see if the name is still unique. I argue that duplicate name detection and suppresion does not need to be part of the base LLMNR protocol. > I don't like > the idea of multicasting all replies, as it is either wasteful or > dangerous; and I also really don't like anything that relies on periodic > broadcast by all hosts on a network, as it has obvious potential for > melt-down. I agree both are undesirable and with your argument. > In summary, I would rather rely on occasional checks triggered by an > administrative action, rather than increase the amount of broadcast on > the network. That is basicly what I am suggesting above. Best regards, Erik -- 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 May 20 12:37:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20621 for ; Tue, 20 May 2003 12:37:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IA06-000IQi-00 for namedroppers-data@psg.com; Tue, 20 May 2003 16:30:06 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19I9zu-000IOq-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 16:29:54 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h4KGTIbd026127 for ; Tue, 20 May 2003 12:29:18 -0400 (EDT) Message-ID: <002001c31eec$f6c88f40$b9370681@barnacle> From: "Scott Rose" To: Subject: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response. Date: Tue, 20 May 2003 12:29:19 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Q: Should the space restriction for a SIG RR covering a NXT RR in a negative response cause the response to be truncated? Should the "MUST set the TC bit" language be dropped or changed? Discussion: When a DNSSEC aware server sends a negative or positive wildcard response, the NXT RRs that are included are similar. In the Authority section, a NXT showing that the exact response does not exist, and a NXT showing the closest encloser status are included along with their respective SIGs. However, if the space does not permit their inclusion without truncation, should the TC bit be set and the response truncated? In RFC2535: 1. when an RRset is placed in a response, its SIG RR has a higher priority for inclusion than additional RRs that may need to be included. If space does not permit its inclusion, the response MUST be considered truncated except as provided in 2 below. 2. When a SIG RR is present in the zone for an additional information section RR, the response MUST NOT be considered truncated merely because space does not permit the inclusion of the SIG RR with the additional information. Taken as is, NXT RRs in the authority section in which there is no room for SIG RRs would cause truncation. In the DS draft, it also states that if there is not room for a NXT and SIG(NXT) to be included in the authority section (to signal lack of DS RR), the response must be truncated. Current text in -01 version of protocol draft: If space does not permit inclusion of these NXT RRs, the response MUST be considered truncated, and the TC bit MUST be set. Any SIG RRs associated with the NXT RRsets MUST also be included in the response. And a sample of possible replacement text if dropping the SIGs is agreed upon (Please suggest corrections if desired): If space does not permit inclusion of these NXT RRs, the response MUST be considered truncated, and the TC bit MUST be set. Any SIG RRs associated with the NXT RRsets SHOULD also be included in the response. If space does not allow the inclusion of the SIG RRs without causing truncation, all NXT RRs have a higher priority in the response over any accompanying SIG RRs. If space does not permit the inclusion of the necessary SIG RRs, the response MUST NOT be considered truncated and the TC bit MUST NOT be set. ... Reasoning for keeping the current language: NXT RRs are the only RRs that have the same name in both delegating and delegated zones, but with different RDATA, yet are both authoritative. So if a validator did not get the accompanying SIG, it will have to know which authoritative server to get the correct NXT RR to attempt to verify the SIG. This would only happen at delegation points. Resoning to change the current langauge to something else: It is more important to get the NXT RRs, which the validator cannot predict, than the SIGs that accompany it. It is possible to get the SIGs by a second UDP query for the NXT RR in question to get the accompanying SIG RR. Or a query for the SIG RRset of the query name. For not delegation points, this would work. Scott -- 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 May 20 14:44:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24662 for ; Tue, 20 May 2003 14:44:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IBwa-000KGd-00 for namedroppers-data@psg.com; Tue, 20 May 2003 18:34:36 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 3.36 #1) id 19IBwX-000K74-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 18:34:33 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h4KIYLh1020365; Tue, 20 May 2003 11:34:21 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h4KIYLBK021593; Tue, 20 May 2003 11:34:21 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h4KIYJ7u021590; Tue, 20 May 2003 11:34:19 -0700 (PDT) Date: Tue, 20 May 2003 11:34:19 -0700 (PDT) Message-Id: <200305201834.h4KIYJ7u021590@guava.araneus.fi> To: "Hallam-Baker, Phillip" Cc: "'Erik Nordmark'" , namedroppers@ops.ietf.org Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknow n DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown- rrs-05 In-Reply-To: Re: References: X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-33.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hallam-Baker, Phillip writes: > Rather than delete the section entirely why not point it to the RFCs where > the IANA considerations are considered? Do you mean the IANA Considerations section should contain a reference to RFC2929? I'm afraid I don't quite see the point of this. If the IANA Considerations section explicitly states that are no IANA actions associated with the document, as Erik Nordmark suggested, wouldn't it be confusing if also pointed to a document defining such actions? -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 20 17:02:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00263 for ; Tue, 20 May 2003 17:02:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IE3z-00071q-00 for namedroppers-data@psg.com; Tue, 20 May 2003 20:50:23 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19IE3x-00071W-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 20:50:21 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h4KKoB53000376; Tue, 20 May 2003 13:50:16 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 May 2003 13:50:11 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'gson@nominum.com'" , "Hallam-Baker, Phillip" Cc: "'Erik Nordmark'" , namedroppers@ops.ietf.org Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknow n DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown - rrs-05 Date: Tue, 20 May 2003 13:50:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The reason I suggest this is because of my experience of dealing with engineers and RFCs. Finding the RFC that relates to a particular issue is very hard unless you know precisely what you are looking for. Unless you know that there is an RFC on IANA requirements you are likely to not bother looking for it. If your objective is to persuade engineers to actually follow an RFC you will find it more likely they will comply if you make it easier for them to do so. Otherwise you will find that the guy writing the code is actually reading the O'Riley Nutshell book rather than the RFC. The point of the draft is to make extension RRs usable. I think it is rather better if people who are going to start defining such records know that there is a defined process to get a RR record number assigned and where to find it. Phill > -----Original Message----- > From: gson@nominum.com [mailto:gson@nominum.com] > Sent: Tuesday, May 20, 2003 2:34 PM > To: Hallam-Baker, Phillip > Cc: 'Erik Nordmark'; namedroppers@ops.ietf.org > Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of > Unknow n DNS Resource Record Types to Proposed > Standardraft-ietf-dnsext-unknown- rrs-05 > > > Hallam-Baker, Phillip writes: > > Rather than delete the section entirely why not point it to > the RFCs where > > the IANA considerations are considered? > > Do you mean the IANA Considerations section should contain a reference > to RFC2929? I'm afraid I don't quite see the point of this. > > If the IANA Considerations section explicitly states that are no IANA > actions associated with the document, as Erik Nordmark suggested, > wouldn't it be confusing if also pointed to a document defining such > actions? > -- > Andreas Gustafsson, gson@nominum.com > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 20 17:40:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01375 for ; Tue, 20 May 2003 17:40:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IEkB-0009ej-00 for namedroppers-data@psg.com; Tue, 20 May 2003 21:33:59 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19IEk9-0009eW-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 21:33:57 +0000 Received: by shell.nominum.com (Postfix, from userid 1411) id 15982137F10; Tue, 20 May 2003 14:33:56 -0700 (PDT) To: "Scott Rose" Cc: Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response. References: <002001c31eec$f6c88f40$b9370681@barnacle> From: Bob Halley Date: 20 May 2003 14:33:56 -0700 In-Reply-To: <002001c31eec$f6c88f40$b9370681@barnacle> Message-ID: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I support keeping the current language. Given that we have EDNS0, I don't expect that cases where a SIG(NXT) causes truncation will be that common. If we don't think that the switch to TCP is going to happen frequently, I don't think we need to worry about it. More importantly, separating SIGs from what they sign is something to avoid. Whenever you separate a SIG, you run into the possibility that the SIG you subsequently fetch will be for another version of the data. When the SIG doesn't verify, the validator must not treat that as a failure of validation, but instead must refetch both data and its SIG and try again. /Bob -- 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 May 20 19:05:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04953 for ; Tue, 20 May 2003 19:05:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IG3n-000G6L-00 for namedroppers-data@psg.com; Tue, 20 May 2003 22:58:19 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 3.36 #1) id 19IG3k-000G5x-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 22:58:16 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h4KMwCh1021044; Tue, 20 May 2003 15:58:12 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h4KMwCBK021802; Tue, 20 May 2003 15:58:12 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h4KMwBBW021799; Tue, 20 May 2003 15:58:11 -0700 (PDT) Date: Tue, 20 May 2003 15:58:11 -0700 (PDT) Message-Id: <200305202258.h4KMwBBW021799@guava.araneus.fi> To: "Hallam-Baker, Phillip" Cc: "'Erik Nordmark'" , namedroppers@ops.ietf.org Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknow n DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown - rrs-05 In-Reply-To: Re: References: X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-36.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hallam-Baker, Phillip writes: > The reason I suggest this is because of my experience of dealing with > engineers and RFCs. > > Finding the RFC that relates to a particular issue is very hard unless you > know precisely what you are looking for. Unless you know that there is an > RFC on IANA requirements you are likely to not bother looking for it. > > If your objective is to persuade engineers to actually follow an RFC you > will find it more likely they will comply if you make it easier for them to > do so. Helping engineers find RFC2929 and persuading them to follow it are laudable goals, but they are not within the scope of the unknown-rrs specification. Even if they were, such text would not belong in the IANA Considerations section since its audience is IANA, not the RR type specification author. If you think there is a need for additional guidelines for RR type specification authors (and there probably is), feel free to write a separate "Considerations for DNS RR Type Specification Authors" draft pointing them to RFC2929 and any other relevant, hard-to-find RFCs. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue May 20 20:01:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06538 for ; Tue, 20 May 2003 20:01:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IGwv-000KxF-00 for namedroppers-data@psg.com; Tue, 20 May 2003 23:55:17 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19IGws-000Kuv-00 for namedroppers@ops.ietf.org; Tue, 20 May 2003 23:55:15 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4KNshab095837 for ; Wed, 21 May 2003 09:54:43 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4KNshbg001103 for ; Wed, 21 May 2003 09:54:43 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305202354.h4KNshbg001103@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response. In-reply-to: Your message of "20 May 2003 14:33:56 MST." Date: Wed, 21 May 2003 09:54:43 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I support keeping the current language. > > Given that we have EDNS0, I don't expect that cases where a SIG(NXT) > causes truncation will be that common. If we don't think that the > switch to TCP is going to happen frequently, I don't think we need to > worry about it. > > More importantly, separating SIGs from what they sign is something to > avoid. Whenever you separate a SIG, you run into the possibility that > the SIG you subsequently fetch will be for another version of the > data. When the SIG doesn't verify, the validator must not treat that > as a failure of validation, but instead must refetch both data and its > SIG and try again. > > /Bob > I concur. -- Mark Andrews, Internet Software Consortium 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 May 21 12:34:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27510 for ; Wed, 21 May 2003 12:34:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IWKp-0005Tf-00 for namedroppers-data@psg.com; Wed, 21 May 2003 16:20:59 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19IWKH-0005Iv-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 16:20:26 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4LFwVT05423 for ; Wed, 21 May 2003 08:58:31 -0700 Date: Wed, 21 May 2003 08:58:30 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 39: Name Conflict Detection Algorithm Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 39 (and the ensuing discussion) is enclosed below. The proposed fix is to delete the text relating to detection of conflicts on healing of a network partition. It was noted that the partition healing problem is not considered serious in cases where the probability of conflict is low. For example, partition healing is not addressed in IPv6 neighbor discovery, whereas it is addressed in IPv4 linklocal addressing (via broadcasting of ARP replies) because the probability of conflicts is much higher. In the case of LLMNR, it is possible to choose hostnames in such a way that the conflict probability is relatively low, so that it is not clear that conflict detection on partition healing is a real requirement. In any case, the algorithm suggested for use in -19 is inappropriate for several reasons: a. It requires the processing of responses for which no query was sent. This is not sensible from a security perspective. b. Carrying out the algorithm becomes unwieldly in the case where a cluster name is queried. In this case the algorithm would require the sender to forward cluster name responses to each member of the cluster, requiring the sending of N(N-1) packets. c. The algorithm appears to violate the rule that hosts should only respond to queries for names over which they are authoritative. The proposed fixes are as follows: In Section 2.2, change: "Responders MUST NOT respond to LLMNR queries for names they are not authoritative for, except in the event of a discovered conflict, as described in Section 4. Responders SHOULD respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." To: "Responders MUST NOT respond to LLMNR queries for names they are not authoritative for. Responders SHOULD respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." In Section 4, change: "The name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In such a situation, name conflicts are detected when a sender receives more than one response to its LLMNR multicast query. In this case, the sender sends the first response that it received to all responders that responded to this query except the first one, using UDP unicast. A host that receives a query response containing a UNIQUE resource record that it owns, even if it didn't send such a query, MUST verify that no other host within the LLMNR scope is authoritative for the same name, using the mechanism described above. Based on the result, the host detects whether there is a name conflict and acts accordingly." To: "The name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In order to minimize the chance of conflicts in such a situation, it is recommended that steps be taken to ensure hostname uniqueness. For example, the hostname could be chosen randomly from a large pool of potential names, or the hostname could be assigned via a process designed to guarantee uniqueness." In Section 4.1, delete: "Host myhost will then send the first responder's response to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, since the conflicting host resides on a different link. Therefore it will continue using its name." ------------------------------------------------------------------------ Issue 39: Name conflict detection algorithm Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: May 12, 2003 Reference: Document: LLMNR-18 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: It isn't clear to me that the name conflict detection mechanism defined in Section 4 makes sense. Here is what it says: "The name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In such a situation, name conflicts are detected when a sender receives more than one response to its LLMNR multicast query. In this case, the sender sends the first response that it received to all responders that responded to this query except the first one, using UDP unicast. A host that receives a query response containing a UNIQUE resource record that it owns, even if it didn't send such a query, MUST verify that no other host within the LLMNR scope is authoritative for the same name, using the mechanism described above. Based on the result, the host detects whether there is a name conflict and acts accordingly." I don't like the idea of sending unsolicited UDP responses. The goal here is to enable hosts involved in a conflict to become aware of it more quickly. Joshua Graessley : It seems another alternative might be to send all responses using multicast instead of unicast. This would give hosts a chance to detect conflicts much quicker. The same trick is used with IPv4LL and ARP. The ARP responses are broadcast to facilitate in quicker discovery of conflicts. The multicast responses could be used to populate a local LLMNR cache on all hosts possibly reducing the number of queries that must be sent. > Wouldn't it be wasteful to send all responses to the same > multicast group? The response packet has to be sent. If it's sent using multicast instead of unicast it will reach more machines but at least a packet wouldn't be sent when it isn't needed. Sending every 30 seconds is a precaution, in case something is wrong. If two hosts are configured to respond differently to LLMNR requests, there is no problem until another host actually queries for the conflicting record. If no host ever queries for that record, what do we gain by spewing traffic every 30 seconds? The multicast response could be used to build a cache on hosts implementing LLMNR resolvers. This cache could be hit before a query packet is generated on the wire, potentially eliminating additional traffic. [MikaL]: I agree. There is no need to detect conflicts proactively. If people are worried about the CPU usage (and that is certainly a valid point), we can just leave the unicast responses as they are, but using multicast would simplify the code. > The multicast response could be used to build a cache on hosts > implementing LLMNR resolvers. This cache could be hit before a query > packet is generated on the wire, potentially eliminating additional > traffic. I'm not sure I'm comfortable with this one. This might make cache poisoning a bit too easy. Note that, for UDP unicast responses, comparing received responses to pending queries is currently our only defence against spoofed UDP unicast responses from off-link, since we no longer test TTL=255 for responses. [Erik Guttman]: I agree that multicasting the name with the conflict would be easier to implement (and specify correctly). If this multicast occurs to a link local multicast group destination, it would be hard for an attacker send it to another link. This mitigates the security risk of caching. I assume the host (llmnr responder) receiving these multicast unsolicited replies can distinguish the difference between a message sent to multicast and unicast destinations. Either a separate listener (socket, or whatever) should be used to listen for unicast requests, to differentiate them from multicast requests - or the 'destination address' of the received datagram should be examined. Erik [Christian Huitema]: I am afraid that there is no good solution to this problem. I don't like the idea of multicasting all replies, as it is either wasteful or dangerous; and I also really don't like anything that relies on periodic broadcast by all hosts on a network, as it has obvious potential for melt-down. Let's expand on why multicast replies are wasteful or dangerous. There is a proposed design in which hosts listen to all replies, even those to queries they did not issue, and cache the response. The idea is that multicast may be costly, but this cost would be compensated by more extensive caching. The problem is that such design is a powerful tool for an on-link attacker: the attacker can issue a spoofed query and then broadcast spoofed responses, effectively polluting the caches of all on-link hosts. In practice, a responsible host will only accept responses to its own queries. It will ignore the other broadcast responses. The multicast will just be wasteful. My real issue with name conflict detection is whether it is actually needed. Take the IETF network. Suppose that two attendees come in with the laptops "zeus.example1.com" and "zeus.example2.net". There will be a conflict for the unqualified name "zeus", but is that a bug that needs be fixed? None of the two laptops is going to change its name, as that would probably invalidate various security credentials and other certificates. I guess we will just have to live with it. If names are picked at random, then we can just as well pick them from a space large enough to avoid the birthday paradox, and periodic checks will not be particularly useful. If we assume that names are configured, then periodic checks are not needed either. The administrator may perform the check during the configuration procedure, or compare to a master file kept somewhere, on a computer or a notebook. The administrator may also at a later stage perform inventories of the network, e.g. by listening to traffic, collecting IP addresses and performing reverse look-ups. In summary, I would rather rely on occasional checks triggered by an administrative action, rather than increase the amount of broadcast on the network. [Eric Hall]: Another option is to stick the client name into the request message, perhaps using a special RR in the authority or additional-data sections. Other clients which are monitoring the multicast channel can watch for collisions and take whatever recovery steps are needed. That would only increase the request size by a small percentage, and wouldn't generate any additional messages. [Joshua Graessley]: > I am afraid that there is no good solution to this problem. I don't > like the idea of multicasting all replies, as it is either wasteful or > dangerous; and I also really don't like anything that relies on > periodic broadcast by all hosts on a network, as it has obvious > potential for melt-down. We have operational experience with a wide deployment of an implementation of something similar to LLMNR that uses multicasts for responses to quickly detect conflicts and to implement caching. We have received no reports of melt-downs nor have we experienced any such problems here at Apple. > Let's expand on why multicast replies are wasteful or dangerous. There > is a proposed design in which hosts listen to all replies, even those > to queries they did not issue, and cache the response. The idea is that > multicast may be costly, but this cost would be compensated by more > extensive caching. The problem is that such design is a powerful tool > for an on-link attacker: the attacker can issue a spoofed query and > then broadcast spoofed responses, effectively polluting the caches of > all on-link hosts. In practice, a responsible host will only accept > responses to its own queries. It will ignore the other broadcast > responses. The multicast will just be wasteful. A node can do the wrong thing and wreck havoc on the local network. In the case you note, the multicast would be detected by anyone advertising conflict data and the conflict detection would kick in. Someone could use a unicast hardware address with a multicast IP address to spoof a response to just one node. The network is a shared resource, unless encryption and authentication is used, it can not be made secure. [Erik Guttman]: The real question is - what is the problem? Early on in the work on this protocol it was asserted that it would be unacceptable to allow multiple hosts to respond to the same name. (I do not remember who asserted this.) If we accept it is necessary to detect and correct the situation where more than one LLMNR responder responds authoritatively to the same name we need either a proactive or reactive approach. But do we really need to accept this requirement? There are for example cases where we *want* multiple responders to answer to the same name (if the hosts support redundant identical services, for example.) It could be inconvenient and confusing for a user to get inconsistent results to a request. But in this case, can't the user intervene? The host had to have *gotten* its name somehow. If this was a manual administrative assignment, only a similar assignment should be done to change the name. The name may have been assigned automatically , by a program which attempted to assign a unique name. This same program could periodically test to see if the name is still unique. I argue that duplicate name detection and suppression does not need to be part of the base LLMNR protocol. > I don't like > the idea of multicasting all replies, as it is either wasteful or > dangerous; and I also really don't like anything that relies on periodic > broadcast by all hosts on a network, as it has obvious potential for > melt-down. I agree both are undesirable and with your argument. > In summary, I would rather rely on occasional checks triggered by an > administrative action, rather than increase the amount of broadcast on > the network. That is basically what I am suggesting above. -- 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 May 21 13:26:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29081 for ; Wed, 21 May 2003 13:26:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IXDM-000DPE-00 for namedroppers-data@psg.com; Wed, 21 May 2003 17:17:20 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19IXCK-000DJZ-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 17:16:16 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 0620C3DF; Wed, 21 May 2003 13:16:14 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id AE4A23AE for ; Wed, 21 May 2003 13:16:14 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 267224 for namedroppers@ops.ietf.org; Wed, 21 May 2003 13:15:10 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <002001c31eec$f6c88f40$b9370681@barnacle> Date: Wed, 21 May 2003 13:16:22 -0400 To: From: Edward Lewis Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response. Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:33 -0700 5/20/03, Bob Halley wrote: >More importantly, separating SIGs from what they sign is something to >avoid. Very true. Do not make separation of SIG and data an acceptable behavior by a sender. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. -- 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 May 21 14:11:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00273 for ; Wed, 21 May 2003 14:11:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IXss-000KMk-00 for namedroppers-data@psg.com; Wed, 21 May 2003 18:00:14 +0000 Received: from maya40.nic.fr ([192.134.4.151]) by psg.com with esmtp (Exim 3.36 #1) id 19IXsM-000KCz-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 17:59:42 +0000 Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h4LHwZNl604096; Wed, 21 May 2003 19:58:35 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h4LHwXZ29593; Wed, 21 May 2003 19:58:33 +0200 Date: Wed, 21 May 2003 19:58:33 +0200 From: Mohsen Souissi To: Erik Nordmark Cc: namedroppers@ops.ietf.org, Vladimir Ksinant Subject: Re: rfc1886bis - need updated implementation report Message-ID: <20030521195833.F2927@kerkenna.nic.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Erik.Nordmark@sun.com on Thu, May 15, 2003 at 09:48:25AM +0200 X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Erik & all, On 15 May, Erik Nordmark wrote: | | The discussion about rfc1886bis on the mailing list resulted (as far as I | remember) in that the I-D is fine but that the implementation report | should be made more clear regarding additional section processing. | | Once I have an updated implementation report I can start the IETF last call | for draft standard. ==> We updated the interop report on March, the 20th. It is available online at: http://w6.afnic.fr/RFC1886/testRFC1886.html (dual-stack) The I-D will be updated since a new reference has to be taken into account: RFC3513 (IPv6 Addressing Architecture). The new I-D version will be buplished soon. Regards, Vladimir & Mohsen. -- 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 May 21 15:02:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02101 for ; Wed, 21 May 2003 15:02:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IYh3-0003Zk-00 for namedroppers-data@psg.com; Wed, 21 May 2003 18:52:05 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19IYgU-0003Pk-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 18:51:30 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01424; Wed, 21 May 2003 14:51:26 -0400 (EDT) Message-Id: <200305211851.OAA01424@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-20.txt Date: Wed, 21 May 2003 14:51:26 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-20.txt Pages : 21 Date : 2003-5-21 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name Service (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-20.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mdns-20.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-mdns-20.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: <2003-5-21144430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-21144430.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 May 21 15:22:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04536 for ; Wed, 21 May 2003 15:21:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IZ1b-0007SS-00 for namedroppers-data@psg.com; Wed, 21 May 2003 19:13:19 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19IZ15-0007RC-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 19:12:47 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 7393C38E; Wed, 21 May 2003 15:12:46 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id C7B60389 for ; Wed, 21 May 2003 15:12:45 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 267433; Wed, 21 May 2003 15:11:41 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 21 May 2003 15:12:54 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: revised proposal for defining the NXT Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Below is a proposal I put on the list about 2 weeks ago. Should this be handed to the DNSSEC editors for preparation as a question/text/etc.? I'm curious what the chairs want to do with this. At 9:44 -0400 5/8/03, Edward Lewis wrote: >This proposal is intended to fit into the appropriate DNSSEC >document as part of the definition of the NXT record. The >motivation for this proposal is buried in the opt-in discussion, but >the proposal is not centered around the promotion or dismissal of >the opt-in proposal. > >The philosophical underpinning of this proposal is based on the >observation that the NXT RR, which needs the SIG RR to have any >meaning, could claim that it itself and or the accompanying SIG RR >(set) does not exist. This would qualify as a "silly state." >Furthermore, there is a sound reason to define the reaction to the >resolver or verifier to the possibility of such a "silly state" and >this proposal chooses one. > >(Silly = saying that I don't exist, or that the one who is needed to >vouch for my existence doesn't exist.) > >This proposal is informal, it is not cast into RFC 2119 language to >reinforce the need for discussion on this. > >First rule. (Speaker-side) > >A compliant signing application will always set the values of the >NXT and SIG positions of the NXT RR type code bit map to 1. This >silly state is not to be seen in normal protocol operations. (Nor >are any others, but that's not my concern right now.) > >Second rule. (Listener-side) > >When a verifier sees 1's in BOTH the NXT and SIG positions, >processing of the NXT follows the stated rules as we have already >documented them. > >When a verifier sees a 0 in EITHER the NXT OR the SIG positions, the >verifier will take corrective action. This proposal recommends the >following action be specified as a MUST: the verifier will first >validate the NXT according to local policy, with the intent that the >presence of the DS RR at the parent points eventually to a zone key >that verifies the SIG (NXT). Once the NXT is proven valid, the >verifier then treats the remainder of the query as if the DS RR did >not exist - essentially treating the query as traversing through or >being answered from an unsigned zone. > >Into the Future. > >If the type codes for NXT and SIG are changed, the rules for the >bits move with the type codes. I.e., if, say, an NXTbis RR is used >to prove non-existence, then the NXTbis position has this special >meaning AND NOT the NXT position. I.e., we are only protecting >against silly states, not creating flags in the NXT bit map. > >Discussion. > >There are four options I have considered for a reaction to a silly >state NXT. One is to "fall back" to unsecured DNS, which is what I >have chosen to propose. The rationale is that this permits >enhancements to happen, if they prove to be beneficial. I did not >pick this because it resembles opt-in, as some have noted. Although >it resembles opt-in, it is not opt-in as that has more rules and >considerations to follow. I.e., this proposal does not cover the >rules of generating silly state NXT's - they are forbidden in the >First Rule. > >The other three options are: > >2) (1 is the above) Instruct the verifier to ignore the bit >positions NXT and SIG. This is viable, two less bit tests, but >obviates any chance of making use of these bits as a means to >experiment. > >3) Instruct the resolver to treat the silly state as a resource >record format error. This kind of response will cut off the network >anyone trying to experiment. > >4) Not issue any statement on the silly state reaction. Because of >the First Rule, there really isn't an immediate interoperability >rule, but by allowing implementers to not respond in a harmonious >way, interoperability into the future is endangered. > >Aside. > >Case 4 is already used in 2535 - the 0th bit position is used to >define an unspecified new format for the NXT bitmap. A 1 there is a >declared silly state (the opposite value of the 0's for the NXT and >SIG silly states). Perhaps we should also specify some standard >melt down for the time being. Perhaps not the same - but we should >make sure that implementers don't vary in undesirable ways. > >PS - thanks to the bunch of folks that have replied to me privately >on this. But, please, let's keep the discussion on namedroppers - >my finger hurt from replying to so many contributors...;) > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-703-227-9854 >ARIN Research Engineer > >Note to pilots: a three-point landing SHOULD NOT include a wing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. -- 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 May 21 15:24:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04771 for ; Wed, 21 May 2003 15:24:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IZ4l-0008Dy-00 for namedroppers-data@psg.com; Wed, 21 May 2003 19:16:35 +0000 Received: from [64.19.188.18] (helo=db1.contentcatcher.com) by psg.com with esmtp (Exim 3.36 #1) id 19IZ4F-0008Ca-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 19:16:03 +0000 Received: from CC1 ([192.168.200.2]) by db1.contentcatcher.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 15:12:28 -0400 x-sender: owner-ietf-announce@ietf.org x-receiver: spamtrap@spam.clearnetwork.com Received: from pf1.contentcatcher.com ([192.168.100.2]) by CC1 with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 15:16:21 -0400 Received: by pf1.contentcatcher.com (Postfix, from userid 502) id 054189F617; Wed, 21 May 2003 15:02:12 -0400 (EDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by pf1.contentcatcher.com (Postfix) with ESMTP id 039919F616; Wed, 21 May 2003 15:01:44 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19IYio-0003Ze-JP for ietf-announce-list@asgard.ietf.org; Wed, 21 May 2003 14:53:54 -0400 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by asgard.ietf.org with esmtp (Exim 4.14) id 19IYgV-0003Ub-5k for all-ietf@asgard.ietf.org; Wed, 21 May 2003 14:51:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01424; Wed, 21 May 2003 14:51:26 -0400 (EDT) Message-Id: <200305211851.OAA01424@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Reply-To: Internet-Drafts@ietf.org Date: Wed, 21 May 2003 14:51:26 -0400 X-VIRUS-FOUND: NO X-GHOST-SENDER: owner-ietf-announce@ietf.org X-GHOST-RECEIVER: braja@tellium.com X-OriginalArrivalTime: 21 May 2003 19:16:21.0609 (UTC) FILETIME=[76A99D90:01C31FCD] x-contentCatcher: ContentCatcher build 0407021738 Cc: namedroppers@ops.ietf.org To: braja@tellium.com From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-20.txt [owner-ietf-announce@ietf.org in Pass-Through List] ['from' in Pass-Through List] X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --NextPart Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-20.txt Pages : 21 Date : 2003-5-21 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name Service (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-20.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-mdns-20.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-mdns-20.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" This is a multi-part message in MIME format. --OtherAccess Content-Type: Message/External-body;access-type="mail-server";server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-21144430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-20.txt --OtherAccess Content-Type: Message/External-body;name="draft-ietf-dnsext-mdns-20.txt";site="ftp.ietf.org";access-type="anon-ftp";directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-21144430.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 May 21 15:36:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05573 for ; Wed, 21 May 2003 15:36:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IZEf-000AUa-00 for namedroppers-data@psg.com; Wed, 21 May 2003 19:26:49 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by psg.com with esmtp (Exim 3.36 #1) id 19IZE9-000AHF-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 19:26:17 +0000 Received: from cisco.com (stealth-10-34-245-242.cisco.com [10.34.245.242]) by sj-core-2.cisco.com (8.12.9/8.12.6) with SMTP id h4LJPeee012422; Wed, 21 May 2003 12:25:41 -0700 (PDT) Date: Wed, 21 May 2003 12:25:33 -0700 Subject: Re: I-D ACTION:draft-ietf-dnsext-mdns-20.txt [owner-ietf-announce@ietf.org in Pass-Through List] ['from' in Pass-Through List] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: braja@tellium.com, namedroppers@ops.ietf.org To: Internet-Drafts@ietf.org From: Richard Johnson In-Reply-To: <200305211851.OAA01424@ietf.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-28.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The URL included in this message doesn't seem to work. /raj On Wednesday, May 21, 2003, at 11:51 AM, Internet-Drafts@ietf.org wrote: > > Title : Linklocal Multicast Name Resolution (LLMNR) > Author(s) : L. Esibov, B. Aboba, D. Thaler > Filename : draft-ietf-dnsext-mdns-20.txt > Pages : 21 > Date : 2003-5-21 > > Today, with the rise of home networking, there are an increasing number > of ad-hoc networks operating without a Domain Name Service (DNS) > server. > In order to allow name resolution in such environments, Link-Local > Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all > current and future DNS formats, types and classes, while operating on a > separate port from DNS, and with a distinct resolver cache. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-20.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > 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-mdns-20.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-mdns-20.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. > Content-Type: text/plain > Content-ID: <2003-5-21144430.I-D@ietf.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 May 21 16:10:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07088 for ; Wed, 21 May 2003 16:10:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IZn3-000HeX-00 for namedroppers-data@psg.com; Wed, 21 May 2003 20:02:21 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19IZmY-000HcX-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 20:01:50 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 436B05A4; Wed, 21 May 2003 16:01:45 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id CFF60487 for ; Wed, 21 May 2003 16:01:44 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 267573; Wed, 21 May 2003 16:00:39 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Wed, 21 May 2003 16:01:54 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: an example of why flag bits are bad things Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.2 required=5.0 tests=BAYES_01,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-08.txt This is a draft that is defining an URI based on dns. For example: dns:www.example.org?class=IN;type=A as the encoding for QNAME, QCLASS, and QTYPE. This scheme won't be able to convey DS-ok or DNSSEC-ok, and perhaps that's not desired, as it wouldn't be up to the application to care (or will it want to know if DNSSEC was 'done'?). This is an example of an extension that is made possible if we stick to the basic principles of DNS. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. -- 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 May 21 16:23:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07714 for ; Wed, 21 May 2003 16:23:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IZzU-000Kec-00 for namedroppers-data@psg.com; Wed, 21 May 2003 20:15:12 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19IZyy-000Kbp-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 20:14:41 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19IZyx-000KqY-GP for namedroppers@ops.ietf.org; Wed, 21 May 2003 13:14:39 -0700 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 21 May 2003 15:28:03 -0400 (Eastern Daylight Time) From: Natalia Syracuse To: Richard Johnson cc: Internet-Drafts@ietf.org, braja@tellium.com, namedroppers@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-dnsext-mdns-20.txt [owner-ietf-announce@ietf.org in Pass-Through List] ['from' in Pass-Through List] X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It will be around 4pm Natalia Syracuse On Wed, 21 May 2003, Richard Johnson wrote: > The URL included in this message doesn't seem to work. > > /raj > > On Wednesday, May 21, 2003, at 11:51 AM, Internet-Drafts@ietf.org > wrote: > > > > > Title : Linklocal Multicast Name Resolution (LLMNR) > > Author(s) : L. Esibov, B. Aboba, D. Thaler > > Filename : draft-ietf-dnsext-mdns-20.txt > > Pages : 21 > > Date : 2003-5-21 > > > > Today, with the rise of home networking, there are an increasing number > > of ad-hoc networks operating without a Domain Name Service (DNS) > > server. > > In order to allow name resolution in such environments, Link-Local > > Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all > > current and future DNS formats, types and classes, while operating on a > > separate port from DNS, and with a distinct resolver cache. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-20.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the > > message. > > > > 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-mdns-20.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-mdns-20.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. > > Content-Type: text/plain > > Content-ID: <2003-5-21144430.I-D@ietf.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 May 21 18:44:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12252 for ; Wed, 21 May 2003 18:44:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ic7b-00017R-00 for namedroppers-data@psg.com; Wed, 21 May 2003 22:31:43 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19Ic7X-000166-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 22:31:40 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4LMUtab097534; Thu, 22 May 2003 08:30:55 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4LMUsLZ002094; Thu, 22 May 2003 08:30:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305212230.h4LMUsLZ002094@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: an example of why flag bits are bad things In-reply-to: Your message of "Wed, 21 May 2003 16:01:54 -0400." Date: Thu, 22 May 2003 08:30:54 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-08.txt > > This is a draft that is defining an URI based on dns. For example: > > dns:www.example.org?class=IN;type=A > > as the encoding for QNAME, QCLASS, and QTYPE. > > This scheme won't be able to convey DS-ok or DNSSEC-ok, and perhaps > that's not desired, as it wouldn't be up to the application to care > (or will it want to know if DNSSEC was 'done'?). This was written well after EDNS was put onto standards track. Failure to allow for flags is a error in this draft not in DNS. > This is an example of an extension that is made possible if we stick > to the basic principles of DNS. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Your office is *not* a reality-based sit-com TV show. > > -- > 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: -- Mark Andrews, Internet Software Consortium 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 May 21 19:06:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12609 for ; Wed, 21 May 2003 19:06:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IcY8-0008hw-00 for namedroppers-data@psg.com; Wed, 21 May 2003 22:59:08 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19IcXd-0008Rx-00 for namedroppers@ops.ietf.org; Wed, 21 May 2003 22:58:37 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h4LMwY53026349; Wed, 21 May 2003 15:58:34 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 May 2003 15:58:34 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Mark.Andrews@isc.org'" , Edward Lewis Cc: namedroppers@ops.ietf.org Subject: RE: an example of why flag bits are bad things Date: Wed, 21 May 2003 15:58:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-08.txt > > > > This is a draft that is defining an URI based on dns. For example: > > > > dns:www.example.org?class=IN;type=A > > > > as the encoding for QNAME, QCLASS, and QTYPE. > > > > This scheme won't be able to convey DS-ok or DNSSEC-ok, and perhaps > > that's not desired, as it wouldn't be up to the application to care > > (or will it want to know if DNSSEC was 'done'?). Why not define the appropriate flags? And why not use the HTTP query syntax rather than defining a new separator? dns:www.example.org?class=IN&type=A&DNSSEC=1 Although I am not sure this is necessary to encode in the URL, you don't encode content-type into a URL request, it is a logical link. The DNSSEC issue would be a logical property of the client making the request not the link. Phill -- 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 May 22 07:30:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09128 for ; Thu, 22 May 2003 07:30:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Io2F-0009R9-00 for namedroppers-data@psg.com; Thu, 22 May 2003 11:14:59 +0000 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 19Io1j-0009Gc-00 for namedroppers@ops.ietf.org; Thu, 22 May 2003 11:14:27 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4MBEF4Z011646; Thu, 22 May 2003 04:14:16 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4MBEEL12856; Thu, 22 May 2003 13:14:14 +0200 (MEST) Date: Thu, 22 May 2003 13:13:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc1886bis - need updated implementation report To: Mohsen Souissi Cc: Erik Nordmark , namedroppers@ops.ietf.org, Vladimir Ksinant In-Reply-To: "Your message with ID" <20030521195833.F2927@kerkenna.nic.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > http://w6.afnic.fr/RFC1886/testRFC1886.html (dual-stack) I see the report is a bunch of web pages - perhaps all under the http://w6.afnic.fr/RFC1886 directory. Would it be possible to construct a self-contained report (a single page?) that can be handed to the secretariat for archiving? Or should I try to get them to archive everything under http://w6.afnic.fr/RFC1886? > The new I-D version will be published soon. Thanks. Erik -- 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 May 22 07:57:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09935 for ; Thu, 22 May 2003 07:57:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IoTx-000I4M-00 for namedroppers-data@psg.com; Thu, 22 May 2003 11:43:37 +0000 Received: from maya40.nic.fr ([192.134.4.151]) by psg.com with esmtp (Exim 3.36 #1) id 19IoTS-000Hn1-00 for namedroppers@ops.ietf.org; Thu, 22 May 2003 11:43:06 +0000 Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h4MBh4Nl895109; Thu, 22 May 2003 13:43:04 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h4MBh2e32147; Thu, 22 May 2003 13:43:02 +0200 Date: Thu, 22 May 2003 13:43:02 +0200 From: Mohsen Souissi To: Erik Nordmark Cc: Mohsen Souissi , namedroppers@ops.ietf.org, Vladimir Ksinant Subject: Re: rfc1886bis - need updated implementation report Message-ID: <20030522134302.H2927@kerkenna.nic.fr> References: <20030521195833.F2927@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Erik.Nordmark@sun.com on Thu, May 22, 2003 at 01:13:30PM +0200 X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 22 May, Erik Nordmark wrote: | > http://w6.afnic.fr/RFC1886/testRFC1886.html (dual-stack) | | I see the report is a bunch of web pages - perhaps all under the | http://w6.afnic.fr/RFC1886 directory. | | Would it be possible to construct a self-contained report (a single page?) | that can be handed to the secretariat for archiving? Or should I try to | get them to archive everything under http://w6.afnic.fr/RFC1886? ==> I think that the easiest way would to archive the whole directory http://w6.afnic.fr/RFC1886 which has been dedicated to the interop html pages and to the sub-directories containing interop results for the different configurations tested. I think it would be quite heavy to construct a single page report. Should there be any problem with this method, we remain. Mohsen. -- 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 May 22 08:34:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11278 for ; Thu, 22 May 2003 08:34:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ip9M-0004NS-00 for namedroppers-data@psg.com; Thu, 22 May 2003 12:26:24 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19Ip8q-00046m-00 for namedroppers@ops.ietf.org; Thu, 22 May 2003 12:25:53 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id D0DF5314; Thu, 22 May 2003 08:25:47 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 73D666A for ; Thu, 22 May 2003 08:25:47 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 268465 for namedroppers@ops.ietf.org; Thu, 22 May 2003 08:24:37 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 22 May 2003 08:25:42 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: RE: an example of why flag bits are bad things Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Regarding: >> > http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-08.txt At 15:58 -0700 5/21/03, Hallam-Baker, Phillip wrote: >Why not define the appropriate flags? And why not use the HTTP >query syntax rather than defining a new separator? > >dns:www.example.org?class=IN&type=A&DNSSEC=1 At 8:30 +1000 5/22/03, Mark.Andrews@isc.org wrote: > This was written well after EDNS was put onto standards > track. Failure to allow for flags is a error in this draft > not in DNS. On the one hand, yes, Simon's draft can be extended to cover these 'omissions.' But consider that: 1) The additions 'ruin' the sweet simplicity of the idea 2) Future flags will mean as yet unknown additions Moral 1 is that the DNS, being at the center of the universe, has to remain as bland as possible to be stable. The more functionality, the more negotiated options you throw in, the more you have to diddle with lines of code and version interactions. As tempting as one more feature is, beware the call of the Sirens. Moral 2 is that we must think of what will happen to future engineering of the DNS. Hacking on something to solve today's problem might endanger a greater feature down the road. Often times we are so concerned about interoperability with elements that exist today we fail to consider interoperability with the future. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. -- 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 May 22 12:20:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19874 for ; Thu, 22 May 2003 12:20:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Isel-0006kC-00 for namedroppers-data@psg.com; Thu, 22 May 2003 16:11:03 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19Isej-0006k0-00 for namedroppers@ops.ietf.org; Thu, 22 May 2003 16:11:01 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 19Isei-0007VF-Rc for namedroppers@ops.ietf.org; Thu, 22 May 2003 09:11:00 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 22 May 2003 09:11:00 -0700 To: namedroppers Subject: opt-in document Message-Id: X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,OPT_IN version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit even though opt-in did not gain consensus in the wg, it would be good to have a permanent document record. the iesg discussed this recently in the context of a transport area document, and the idea is something like the following: o publish opt-in as an informational rfc for the historical record o with a clear warning on the front of it that this is recording a protocol that did NOT gain ietf consensus, it documents an idea that was considered and not adopted o the ADs do have expressed concerns to the chairs about when it gets published; after DS+2535bis would be best. this doesn't prevent folk from finishing the document now and it can queue (in the wg or at the AD) on hold until DS+2535bis finishes. randy and olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 22 13:27:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21994 for ; Thu, 22 May 2003 13:27:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ItaV-000A4h-00 for namedroppers-data@psg.com; Thu, 22 May 2003 17:10:43 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19Ita0-000A2w-00 for namedroppers@ops.ietf.org; Thu, 22 May 2003 17:10:12 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFA00J3GT1UA0@eListX.com> for namedroppers@ops.ietf.org; Thu, 22 May 2003 13:10:43 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h4MH8o27037797 for ; Thu, 22 May 2003 13:08:51 -0400 (EDT envelope-from ogud@ogud.com) Date: Thu, 22 May 2003 13:09:50 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DS document done ? X-Sender: post@localhost To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030522130207.016016a0@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,RCVD_IN_RFCI version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DS passed a working group last call few months ago, since then there have been some changes to the document inspired by implementation and experimental use. I (as author) think the document is complete with one possible exception that relates to the SEK/KSK flag, if that flag is a protocol flag then DS needs updating. Please send in any nits/corrections/changes ASAP so the chair's can ask the AD to advance the document. If there are no comments by Friday May 30'th I will ask the chairs to inform AD that the document is done. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 22 18:33:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03008 for ; Thu, 22 May 2003 18:33:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IyMp-0001JF-00 for namedroppers-data@psg.com; Thu, 22 May 2003 22:16:55 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19IyM0-0001Gd-00 for namedroppers@ops.ietf.org; Thu, 22 May 2003 22:16:04 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4MMFSab099193; Fri, 23 May 2003 08:15:28 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4MMFSe6001637; Fri, 23 May 2003 08:15:28 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305222215.h4MMFSe6001637@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: an example of why flag bits are bad things In-reply-to: Your message of "Thu, 22 May 2003 08:25:42 -0400." Date: Fri, 23 May 2003 08:15:28 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Regarding: > >> > http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-08.txt > > At 15:58 -0700 5/21/03, Hallam-Baker, Phillip wrote: > >Why not define the appropriate flags? And why not use the HTTP > >query syntax rather than defining a new separator? > > > >dns:www.example.org?class=IN&type=A&DNSSEC=1 > > At 8:30 +1000 5/22/03, Mark.Andrews@isc.org wrote: > > This was written well after EDNS was put onto standards > > track. Failure to allow for flags is a error in this draft > > not in DNS. > > On the one hand, yes, Simon's draft can be extended to cover these > 'omissions.' But consider that: > > 1) The additions 'ruin' the sweet simplicity of the idea > 2) Future flags will mean as yet unknown additions Future types will mean as yet unknown additions or are you going to treat all future types as unknown? Developments happen. You design the protocol to allow for them. > Moral 1 is that the DNS, being at the center of the universe, has to > remain as bland as possible to be stable. The more functionality, > the more negotiated options you throw in, the more you have to diddle > with lines of code and version interactions. As tempting as one more > feature is, beware the call of the Sirens. > Moral 2 is that we must think of what will happen to future > engineering of the DNS. Hacking on something to solve today's > problem might endanger a greater feature down the road. Often times > we are so concerned about interoperability with elements that exist > today we fail to consider interoperability with the future. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Your office is *not* a reality-based sit-com TV show. > > -- > 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: -- Mark Andrews, Internet Software Consortium 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 Fri May 23 08:39:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03636 for ; Fri, 23 May 2003 08:39:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19JBcH-000C8n-00 for namedroppers-data@psg.com; Fri, 23 May 2003 12:25:45 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19JBcA-000C28-00 for namedroppers@ops.ietf.org; Fri, 23 May 2003 12:25:38 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 920456A9; Fri, 23 May 2003 08:25:08 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 2E43A6A2; Fri, 23 May 2003 08:25:08 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 290827; Fri, 23 May 2003 08:23:55 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200305222215.h4MMFSe6001637@drugs.dv.isc.org> References: <200305222215.h4MMFSe6001637@drugs.dv.isc.org> Date: Fri, 23 May 2003 08:21:49 -0400 To: Mark.Andrews@isc.org From: Edward Lewis Subject: Re: an example of why flag bits are bad things Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:15 +1000 5/23/03, Mark.Andrews@isc.org wrote: > Future types will mean as yet unknown additions or are you > going to treat all future types as unknown? We already know the format of the name of the future types - a number. We don't always know the format of the flags. E.g., was EDNS0 forseeable from RFC 1035? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. -- 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 May 23 18:42:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29166 for ; Fri, 23 May 2003 18:42:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19JL31-000JAZ-00 for namedroppers-data@psg.com; Fri, 23 May 2003 22:29:59 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19JL2z-000J9Y-00 for namedroppers@ops.ietf.org; Fri, 23 May 2003 22:29:57 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4NMTLl3004299; Sat, 24 May 2003 08:29:21 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4NMTL42000803; Sat, 24 May 2003 08:29:21 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305232229.h4NMTL42000803@drugs.dv.isc.org> To: Edward Lewis Cc: Mark_Andrews@isc.org, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: an example of why flag bits are bad things In-reply-to: Your message of "Fri, 23 May 2003 08:21:49 -0400." Date: Sat, 24 May 2003 08:29:21 +1000 X-Spam-Status: No, hits=-8.5 required=5.0 tests=BAYES_20,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 8:15 +1000 5/23/03, Mark.Andrews@isc.org wrote: > > Future types will mean as yet unknown additions or are you > > going to treat all future types as unknown? > > We already know the format of the name of the future types - a > number. We don't always know the format of the flags. E.g., was > EDNS0 forseeable from RFC 1035? Ed what are you smoking? You really expect humans to remember numbers instead of mnenonics. They don't do that today with dig or nslookup. What makes you think they will with any new types. Or are you seeing this as purely for machine consumption. If so we may as well just encode the dns messages directly and be done with it. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Your office is *not* a reality-based sit-com TV show. > > -- > 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: -- Mark Andrews, Internet Software Consortium 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 Fri May 23 18:55:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29434 for ; Fri, 23 May 2003 18:55:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19JLH7-000LNT-00 for namedroppers-data@psg.com; Fri, 23 May 2003 22:44:33 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19JLH3-000LNG-00 for namedroppers@ops.ietf.org; Fri, 23 May 2003 22:44:29 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 9851B58B; Fri, 23 May 2003 18:44:22 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 36F2E583; Fri, 23 May 2003 18:44:22 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 291727; Fri, 23 May 2003 18:43:07 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200305232229.h4NMTL42000803@drugs.dv.isc.org> References: <200305232229.h4NMTL42000803@drugs.dv.isc.org> Date: Fri, 23 May 2003 18:44:14 -0400 To: Mark.Andrews@isc.org From: Edward Lewis Subject: Re: an example of why flag bits are bad things Cc: Edward Lewis , Mark_Andrews@isc.org, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:29 +1000 5/24/03, Mark.Andrews@isc.org wrote: > Ed what are you smoking? Hey - the last RIPE meeting *wasn't* in Amsterdam. > Or are you seeing this as purely for machine consumption. If > so we may as well just encode the dns messages directly and > be done with it. Yeah...but the point is that by sticking to just a few query parameters (The Q's), it's easier to extend. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. -- 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 May 25 04:12:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26192 for ; Sun, 25 May 2003 04:12:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19JqK9-000EY0-00 for namedroppers-data@psg.com; Sun, 25 May 2003 07:53:45 +0000 Received: from [2001:6b0:7::26] (helo=bardisk.pilsnet.sunet.se) by psg.com with esmtp (Exim 3.36 #1) id 19JqK6-000EXg-00 for namedroppers@ops.ietf.org; Sun, 25 May 2003 07:53:42 +0000 Received: from bardisk.pilsnet.sunet.se (localhost [IPv6:::1]) by bardisk.pilsnet.sunet.se (8.12.8/8.12.8) with ESMTP id h4P7rHVf008558; Sun, 25 May 2003 09:53:17 +0200 (CEST) (envelope-from mansaxel@bardisk.pilsnet.sunet.se) Received: (from mansaxel@localhost) by bardisk.pilsnet.sunet.se (8.12.8/8.12.3/Submit) id h4P7rCpc008553; Sun, 25 May 2003 09:53:12 +0200 (CEST) Date: Sun, 25 May 2003 09:53:06 +0200 From: Mans Nilsson To: Bob Halley Cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response. Message-ID: <20030525075306.GD32787@sunet.se> References: <002001c31eec$f6c88f40$b9370681@barnacle> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hoZxPH4CaxYzWscb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-synced-from: Pilsnet X-Spam-Status: No, hits=-37.8 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --hoZxPH4CaxYzWscb Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for= neg. response. Date: Tue, May 20, 2003 at 02:33:56PM -0700 Quoting Bob Hal= ley (Bob.Halley@nominum.com): > I support keeping the current language. >=20 > Given that we have EDNS0, I don't expect that cases where a SIG(NXT) > causes truncation will be that common. If we don't think that the > switch to TCP is going to happen frequently, I don't think we need to > worry about it. >=20 > More importantly, separating SIGs from what they sign is something to > avoid. Whenever you separate a SIG, you run into the possibility that > the SIG you subsequently fetch will be for another version of the > data. When the SIG doesn't verify, the validator must not treat that > as a failure of validation, but instead must refetch both data and its > SIG and try again. I agree.=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE TONY RANDALL! Is YOUR life a PATIO of FUN?? --hoZxPH4CaxYzWscb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+0HZi02/pMZDM1cURApRpAJ94mJslw0oEaQRHbz/5ldboYLwYoQCcDIbg fl2xV1Jvs0nTq5g4dRqsNDo= =V40B -----END PGP SIGNATURE----- --hoZxPH4CaxYzWscb-- -- 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 May 27 07:55:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09259 for ; Tue, 27 May 2003 07:55:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KcsW-000Mjw-00 for namedroppers-data@psg.com; Tue, 27 May 2003 11:44:28 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19KcsU-000Mjj-00 for namedroppers@ops.ietf.org; Tue, 27 May 2003 11:44:26 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h4RBhsbd014537 for ; Tue, 27 May 2003 07:43:54 -0400 (EDT) Message-ID: <007401c32445$41fb56c0$b9370681@barnacle> From: "Scott Rose" To: Subject: Summary: DNSSECbis Q-9 - SIG(NXT) in the authority section Date: Tue, 27 May 2003 07:43:56 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The agreement seems to be in favor of leaving the text as is: NXT and SIG(NXT) combos should not be broken up in the authority section. If the size limit is exceeded, the TC bit MUST be set and the response MUST be considered truncated. Unless there is a strident voice in favor of continuing the debate, I think we can consider these two notes in the -01 draft of the protocol document to be closed. Scott -- 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 May 27 10:23:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13944 for ; Tue, 27 May 2003 10:23:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KfGM-0006L7-00 for namedroppers-data@psg.com; Tue, 27 May 2003 14:17:14 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19KfGH-0006K8-00 for namedroppers@ops.ietf.org; Tue, 27 May 2003 14:17:09 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 1D49941D; Tue, 27 May 2003 10:16:58 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 60926420 for ; Tue, 27 May 2003 10:16:57 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 300086; Tue, 27 May 2003 10:15:25 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Tue, 27 May 2003 10:17:03 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Q-10: Reaction to "Silly" NXT's Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_20,OPT_IN,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I was told that I could label this question Q-10...;) Any comments on this proposal? (It's been posted a few times.) Sooner or later this will be cast into MUST/SHOULD language and submitted to the dnssec-editors, based on feedback. ------------------------ This proposal is intended to fit into the appropriate DNSSEC document as part of the definition of the NXT record. The motivation for this proposal is buried in the opt-in discussion, but the proposal is not centered around the promotion or dismissal of the opt-in proposal. The philosophical underpinning of this proposal is based on the observation that the NXT RR, which needs the SIG RR to have any meaning, could claim that it itself and or the accompanying SIG RR (set) does not exist. This would qualify as a "silly state." Furthermore, there is a sound reason to define the reaction to the resolver or verifier to the possibility of such a "silly state" and this proposal chooses one. (Silly = saying that I don't exist, or that the one who is needed to vouch for my existence doesn't exist.) This proposal is informal, it is not cast into RFC 2119 language to reinforce the need for discussion on this. First rule. (Speaker-side) A compliant signing application will always set the values of the NXT and SIG positions of the NXT RR type code bit map to 1. This silly state is not to be seen in normal protocol operations. (Nor are any others, but that's not my concern right now.) Second rule. (Listener-side) When a verifier sees 1's in BOTH the NXT and SIG positions, processing of the NXT follows the stated rules as we have already documented them. When a verifier sees a 0 in EITHER the NXT OR the SIG positions, the verifier will take corrective action. This proposal recommends the following action be specified as a MUST: the verifier will first validate the NXT according to local policy, with the intent that the presence of the DS RR at the parent points eventually to a zone key that verifies the SIG (NXT). Once the NXT is proven valid, the verifier then treats the remainder of the query as if the DS RR did not exist - essentially treating the query as traversing through or being answered from an unsigned zone. Into the Future. If the type codes for NXT and SIG are changed, the rules for the bits move with the type codes. I.e., if, say, an NXTbis RR is used to prove non-existence, then the NXTbis position has this special meaning AND NOT the NXT position. I.e., we are only protecting against silly states, not creating flags in the NXT bit map. Discussion. There are four options I have considered for a reaction to a silly state NXT. One is to "fall back" to unsecured DNS, which is what I have chosen to propose. The rationale is that this permits enhancements to happen, if they prove to be beneficial. I did not pick this because it resembles opt-in, as some have noted. Although it resembles opt-in, it is not opt-in as that has more rules and considerations to follow. I.e., this proposal does not cover the rules of generating silly state NXT's - they are forbidden in the First Rule. The other three options are: 2) (1 is the above) Instruct the verifier to ignore the bit positions NXT and SIG. This is viable, two less bit tests, but obviates any chance of making use of these bits as a means to experiment. 3) Instruct the resolver to treat the silly state as a resource record format error. This kind of response will cut off the network anyone trying to experiment. 4) Not issue any statement on the silly state reaction. Because of the First Rule, there really isn't an immediate interoperability rule, but by allowing implementers to not respond in a harmonious way, interoperability into the future is endangered. Aside. Case 4 is already used in 2535 - the 0th bit position is used to define an unspecified new format for the NXT bitmap. A 1 there is a declared silly state (the opposite value of the 0's for the NXT and SIG silly states). Perhaps we should also specify some standard melt down for the time being. Perhaps not the same - but we should make sure that implementers don't vary in undesirable ways. PS - thanks to the bunch of folks that have replied to me privately on this. But, please, let's keep the discussion on namedroppers - my finger hurt from replying to so many contributors...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show. -- 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 May 27 13:14:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20128 for ; Tue, 27 May 2003 13:14:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Khqs-000Poj-00 for namedroppers-data@psg.com; Tue, 27 May 2003 17:03:06 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19Khqq-000PoR-00 for namedroppers@ops.ietf.org; Tue, 27 May 2003 17:03:04 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6EA2713948; Tue, 27 May 2003 17:02:51 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Q-10: Reaction to "Silly" NXT's In-Reply-To: Message from Edward Lewis of "Tue, 27 May 2003 10:17:03 -0400." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 27 May 2003 17:02:51 +0000 Message-Id: <20030527170251.6EA2713948@sa.vix.com> X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I was told that I could label this question Q-10...;) > > Any comments on this proposal? (It's been posted a few times.) Sooner or > later this will be cast into MUST/SHOULD language and submitted to the > dnssec-editors, based on feedback. i think it is a good proposal and should be added. -- 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 May 27 15:16:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26557 for ; Tue, 27 May 2003 15:16:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KjlX-000Buj-00 for namedroppers-data@psg.com; Tue, 27 May 2003 19:05:43 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19Kjl3-000BtP-00 for namedroppers@ops.ietf.org; Tue, 27 May 2003 19:05:13 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h4RJ4hbd007873 for ; Tue, 27 May 2003 15:04:43 -0400 (EDT) Message-ID: <002b01c32482$d58ea670$b9370681@barnacle> From: "Scott Rose" To: References: Subject: Re: Reaction to "Silly" NXT's Date: Tue, 27 May 2003 15:04:44 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with adding the proposal to the discussion as well. As for the casting into rfc2119 language, I would suggest keeping it more liberal if the idea is to not restrict experimentation. More "SHOULD"s than "MUST"s on the first rule. If the idea is to prevent incorrect zone information, they keep it strict. Scott ----- Original Message ----- From: "Edward Lewis" Subject: Q-10: Reaction to "Silly" NXT's > I was told that I could label this question Q-10...;) > > Any comments on this proposal? (It's been posted a few times.) > Sooner or later this will be cast into MUST/SHOULD language and > submitted to the dnssec-editors, based on feedback. > > ------------------------ -- 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 May 28 07:54:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26100 for ; Wed, 28 May 2003 07:54:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KzM3-000CrY-00 for namedroppers-data@psg.com; Wed, 28 May 2003 11:44:27 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19KzM0-000CrG-00 for namedroppers@ops.ietf.org; Wed, 28 May 2003 11:44:24 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25332; Wed, 28 May 2003 07:44:23 -0400 (EDT) Message-Id: <200305281144.HAA25332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-rfc1886bis-03.txt Date: Wed, 28 May 2003 07:44:22 -0400 X-Spam-Status: No, hits=1.5 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Extensions to support IP version 6 Author(s) : S. Thomson, C. Huitema et al. Filename : draft-ietf-dnsext-rfc1886bis-03.txt Pages : 7 Date : 2003-5-27 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This Document combines RFC1886 and changes to RFC 1886 made by RFC 3152, obsoleting both. Changes mainly consist in replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc1886bis-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-rfc1886bis-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: <2003-5-27145019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-rfc1886bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-rfc1886bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-27145019.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 May 28 07:58:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26157 for ; Wed, 28 May 2003 07:58:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KzM7-000Crn-00 for namedroppers-data@psg.com; Wed, 28 May 2003 11:44:31 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19KzM5-000Cra-00 for namedroppers@ops.ietf.org; Wed, 28 May 2003 11:44:29 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25348; Wed, 28 May 2003 07:44:27 -0400 (EDT) Message-Id: <200305281144.HAA25348@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-2535typecode-change-01.txt Date: Wed, 28 May 2003 07:44:27 -0400 X-Spam-Status: No, hits=1.5 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : Legacy Resolver Compatibility for Delegation Signer Author(s) : S. Weiler Filename : draft-ietf-dnsext-dnssec-2535typecode-change-01.txt Pages : 5 Date : 2003-5-27 As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document proposes that these interactions be avoided by changing the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-dnssec-2535typecode-change-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-27145030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-2535typecode-change-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-27145030.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 May 28 08:26:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27663 for ; Wed, 28 May 2003 08:26:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kzsl-000Jjk-00 for namedroppers-data@psg.com; Wed, 28 May 2003 12:18:15 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19Kzsj-000JjW-00 for namedroppers@ops.ietf.org; Wed, 28 May 2003 12:18:13 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h4SCI1bd021539 for ; Wed, 28 May 2003 08:18:01 -0400 (EDT) Message-ID: <001101c32513$2f96e390$b9370681@barnacle> From: "Scott Rose" To: Subject: DNSSECbis question list - not official Date: Wed, 28 May 2003 08:18:02 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I got a request for the questions that were posted/discussed on namedroppers. Here they are, with the perceived consensus. There are some holes (Q7 may exist, but I don't remember it and couldn't find it). If I have any missing parts (and missing resolutions) let me know. As I have them: Q1 - resolved Q2 - Should we move DSA to "optional" and have RSA/SHA1 be the only mandatory to implement algorithm? *Consensus? * Q3 - Can we drop the requirement to add the KEY/SIG(KEY) to the additional section of a response? *Consensus seems to be in favor of dropping requirement* Q4 - mistake in numbering, there is no Q4 Q5 - Should algorithm code 252 (now "Indirect") remain, or move it to "Reserved"? *Consensus? Could not find any resolution in archives * Q6 - Started as "Should sec-aware resolvers cache known "BAD" data"? but now encompasses how servers/resolvers should interpret the CD bit in the DNS header. * No formal consensus reached yet, discussion died out * Q7 - ?? possibly another mistake. Q8 - Should the apex allow zone KEY RRs only? *Consensus seems to be no restrictions at all on KEY RR placement in a zone * Q9 - Dropping the SIG(NXT) from the NXT RRs included in the Auth. section on wildcard and negative replies *Consensus seems to be no allowing of NXT/SIG(NXT) breakup in authority section. Truncate response * Scott -- 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 May 28 14:41:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15477 for ; Wed, 28 May 2003 14:41:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L5cp-0000FN-00 for namedroppers-data@psg.com; Wed, 28 May 2003 18:26:11 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19L5ck-0000F1-00 for namedroppers@ops.ietf.org; Wed, 28 May 2003 18:26:07 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h4SIPvbd021647 for ; Wed, 28 May 2003 14:25:57 -0400 (EDT) Message-ID: <000d01c32546$95c54de0$b9370681@barnacle> From: "Scott Rose" To: Subject: DNSSECbis Q-11: KEY RRs at delegation points Date: Wed, 28 May 2003 14:25:58 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This was a sidebar topic in Q-8: non-zone KEY RRs at the apex. Q: Should KEY RRs (any) be allowed at delegation points? Discussion: There isn't a formal rule already in the documents prior to the DNSSECbis re-write. The KEY@parent idea stated that the delegating zone key would appear at a delegating parent in order to set up the chain of authentication. Now with the DS RR, the zone KEY remains in the delegated child zone. In the latest version of the protocol draft (-01), this is further restricted by saying that KEY RRs MUST NOT appear at delegation points. The topic is whether this restriction is necessary. If the KEY RR is to be considered glue RRs like the other RRs at the delegation point, then it is not signed, and cannot be validated when received with the delegation. Unless it is to be considered authoritative for the delegating zone, like the DS RR. However, there is no harm to the protocol by allowing it, is there? Scott -- 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 May 28 15:15:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18644 for ; Wed, 28 May 2003 15:15:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L6E2-0003cE-00 for namedroppers-data@psg.com; Wed, 28 May 2003 19:04:38 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19L6E0-0003c1-00 for namedroppers@ops.ietf.org; Wed, 28 May 2003 19:04:36 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 76608452; Wed, 28 May 2003 15:04:34 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 02A242E6; Wed, 28 May 2003 15:04:34 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 332077; Wed, 28 May 2003 15:02:56 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <000d01c32546$95c54de0$b9370681@barnacle> References: <000d01c32546$95c54de0$b9370681@barnacle> Date: Wed, 28 May 2003 15:04:41 -0400 To: "Scott Rose" From: Edward Lewis Subject: Re: DNSSECbis Q-11: KEY RRs at delegation points Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:25 -0400 5/28/03, Scott Rose wrote: >However, there is no harm to the protocol by allowing it, is there? The problem is that it is a return to the bad old days of data replication. We survive the NS RR dilemma via the rules of credibility in RFC 2181 (which sorely needs to be promoted to PS soon) and the fact that this replication is so well ingrained in DNS that resolvers all know about it and deal with it. There's no good that can come out of unsigned KEY RR's as any validator worth its salt will need the SIG RR's to make user of them. That means you might encourage QTYPE=SIG, which is a real bear, as you will get back all SIG's for the apex (SOA, KEY, NXT, NS, etc.) if you bother to ask. I'd say that there are two harms - replicated data and larger responses - if you do this. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- 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 May 28 17:31:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25177 for ; Wed, 28 May 2003 17:31:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L8Dp-000HZU-00 for namedroppers-data@psg.com; Wed, 28 May 2003 21:12:33 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19L8Dk-000HZB-00 for namedroppers@ops.ietf.org; Wed, 28 May 2003 21:12:28 +0000 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h4SLCPjp015209; Wed, 28 May 2003 17:12:25 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h4SLCO3T005821; Wed, 28 May 2003 17:12:24 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h4SLCNU8028718; Wed, 28 May 2003 17:12:23 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id RAA11619; Wed, 28 May 2003 17:12:23 -0400 (EDT) To: Edward Lewis Cc: "Scott Rose" , From: Derek Atkins Subject: Another Proposal (was Re: DNSSECbis Q-11: KEY RRs at delegation points) References: <000d01c32546$95c54de0$b9370681@barnacle> Date: 28 May 2003 17:12:23 -0400 In-Reply-To: Message-ID: Lines: 79 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-33.2 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Well, then, perhaps we should think of another way to doing it? We're already proposing to change all the DNSSec RR Types. Sam's draft makes credible arguments why we need to make the change, create a real "flag day" for DNSSec. Accepting his proposal turns back the clock, so to speak, on any existing deployment of DNSSec software, as everything out there is going to be unaware of the new (revved) RR Types. So, if we're going to initiate a real flag day with new RR Types for all of DNSSec, why not take it one step further and fix this problem for good: introduce a SIG Bit? For those who haven't heard of this proposal, in short you reserve one bit in the RR Type to signify "this is a signature". For example, the RR Type for an A record (0x0001) would produce a SIG(A) by setting the 'sig' bit in the RR Type (e.g. 0x7001). In other words, each existing RR Type would imply an individual SIG RR Type for signatures over that original data. The benefits of the SIG Bit are obvious. Using the Sig Bit you can specifically query for the Signature of any individual RR Type. E.g., you can specifically query for SIG(A) vs. SIG(KEY). It also alleviates the problem at the Apex, because you can individually query for the signatures on any RRType you wish. Moreover, this should reduce the complexity of resolvers, caches, and authoritative servers, and should also improve the chances of reasonable responses. Even better, the sig bit is less prone to errors in intermediaries and would probably work through legacy, non-dnssec-aware devices (provided they support "unknown rr types"). The drawback of the Sig Bit is that it reduces by half the available RRs from 64k to 32k. Considering the number of RRs in use and current growth rate, I don't think we should be in any fear of running out anytime this century. IMHO, the benefits of reduced complexity, reduced response size, and the ability to query for individual signatures far outweigh the costs of deployment delay and rr-type namespace reduction. If we proceed with the sig bit proposal, this would be the time to do it, coincident with the rr-type changes. I would even volunteer to author the draft if the working group considers it a worthwhile proposal. -derek Edward Lewis writes: > At 14:25 -0400 5/28/03, Scott Rose wrote: > >However, there is no harm to the protocol by allowing it, is there? > > The problem is that it is a return to the bad old days of data > replication. We survive the NS RR dilemma via the rules of > credibility in RFC 2181 (which sorely needs to be promoted to PS soon) > and the fact that this replication is so well ingrained in DNS that > resolvers all know about it and deal with it. > > There's no good that can come out of unsigned KEY RR's as any > validator worth its salt will need the SIG RR's to make user of > them. That means you might encourage QTYPE=SIG, which is a real bear, > as you will get back all SIG's for the apex (SOA, KEY, NXT, NS, etc.) > if you bother to ask. > > I'd say that there are two harms - replicated data and larger > responses - if you do this. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Digital cameras are to film cameras as Etch-A-Sketches are to canvases. > > -- > 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: -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed May 28 18:06:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26383 for ; Wed, 28 May 2003 18:06:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L8r6-000Mjs-00 for namedroppers-data@psg.com; Wed, 28 May 2003 21:53:08 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19L8r3-000MjO-00 for namedroppers@ops.ietf.org; Wed, 28 May 2003 21:53:05 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 71023383; Wed, 28 May 2003 17:53:02 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 03CF8370; Wed, 28 May 2003 17:53:02 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 332453; Wed, 28 May 2003 17:51:23 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <000d01c32546$95c54de0$b9370681@barnacle> Date: Wed, 28 May 2003 17:53:06 -0400 To: Derek Atkins From: Edward Lewis Subject: Re: Another Proposal Cc: Edward Lewis , "Scott Rose" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:12 -0400 5/28/03, Derek Atkins wrote: >For those who haven't heard of this proposal, in short you reserve one >bit in the RR Type to signify "this is a signature". For example, the Does anyone have a copy of Ohta's proposal, as referenced in a message on the dns-security mailing list on Wed, 14 Dec 1994 from Jim Galvin? Rumor has it that Ohta proposed a similar idea, but I can't find any documentation of his proposal, only quotes like "The problem is that you, Jim, can't understand." (Citing a message sent on Wed, 24 May 95 22:00:48 JST). ...Some things just don't change... One reason the sig bit is a problem now is that it mucks up the NXT - requires an extended format to be used. I can say that in theory a sig-bit approach has a certain appeal, it falls in line with my recent railing against option bits and for leaving "signalling" to be done in the Q-"trinity." But on the other hand, the proposal is nearly a decade late now and I for one am tiring of the topic. Others have even better, further-ranging, ideas based on a similar construct. I don't want to steal the thunder of the folks who have thought up "slabs." That has appeal too, but, we're a bit too far down the road to go back. ...Perhaps if in '94, more DNS folks had a say in what went on in DNSSEC and there was less concern about the underlying crypto...hindsight is hindsight. PS - I encourage folks to peruse the old dns-security mailing list archive, if just for entertainment purposes. It's somewhat interesting to look back with 5-9 years hindsight and see where and when we went wrong - and right. But that's true in all endeavors, lest you be doomed to make the same mistake again. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- 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 May 28 18:26:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27983 for ; Wed, 28 May 2003 18:26:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L9Es-000Q03-00 for namedroppers-data@psg.com; Wed, 28 May 2003 22:17:42 +0000 Received: from h87.s239.netsol.com ([216.168.239.87] helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 19L9Ep-000Pzo-00 for namedroppers@ops.ietf.org; Wed, 28 May 2003 22:17:39 +0000 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id 2E8E39BE22; Wed, 28 May 2003 18:17:39 -0400 (EDT) Date: Wed, 28 May 2003 18:17:39 -0400 From: Matt Larson To: Derek Atkins Cc: Edward Lewis , Scott Rose , namedroppers@ops.ietf.org Subject: Re: Another Proposal (was Re: DNSSECbis Q-11: KEY RRs at delegation points) Message-ID: <20030528221739.GH3467@chinook.rgy.netsol.com> References: <000d01c32546$95c54de0$b9370681@barnacle> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="O98KdSgI27dgYlM5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --O98KdSgI27dgYlM5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, 28 May 2003, Derek Atkins wrote: > So, if we're going to initiate a real flag day with new RR > Types for all of DNSSec, why not take it one step further and fix this > problem for good: introduce a SIG Bit? No, stop, please stop. We must resist the temptation to tinker with anything but the type codes (and, I now reluctantly agree, the mnemonics). It's a slippery slope otherwise. Matt --O98KdSgI27dgYlM5 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIN3QYJKoZIhvcNAQcCoIINzjCCDcoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C4kwggQXMIIDgKADAgECAhACGIAs1dV22NMR6M6LcgSYMA0GCSqGSIb3DQEBBAUAMIGsMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQTAeFw0wMjEwMDEwMDAwMDBaFw0wMzEwMDEyMzU5NTlaMGoxETAPBgNVBAoTCFZF UklTSUdOMRAwDgYDVQQLEwdWQS1FQVNUMRMwEQYDVQQDEwpSZWNpcGllbnRzMS4wLAYDVQQD EyVtbGFyc29uIChMYXJzb24gTWF0dCwgVmVyaVNpZ24sIEluYy4pMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDG/1mDXVeAMTYN4xT2IOziJMBbu/VNzWrwxrjbJA1g0O5olw1zjviB Mc0Qnbm9+VIRUGioJVlU/o29f+1q++Xzg/pvLs8UQ2cWQLCZtqXSgmfKLklXo9/6plyOeAFm u6GwlrwegWKqBNu1n5iVqqFJt2BMJEdb8qnPNqNW9++NPwIDAQABo4IBeTCCAXUwCQYDVR0T BAIwADBZBgNVHR8EUjBQME6gTKBKhkhodHRwOi8vb25zaXRlY3JsLnZlcmlzaWduLmNvbS9W ZXJpU2lnbkluY0V4Y2hhbmdlRW1wbG95ZWVzL0xhdGVzdENSTC5jcmwwCwYDVR0PBAQDAgWg MB8GA1UdEQQYMBaBFG1sYXJzb25AdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4GC2CG SAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMg aW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgB hvhCAQEEBAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEB BAUAA4GBABcu8CE27c/0oFHCPx/gp2PXB0gOeKTEzSendEOXqOGvlu1PsrC5H08KAnpCwc0K ib198JPPdX0Pac2EGpN9D7y3TBDlkIzsCklCVQ0VrBbgAFJNjpHYoSSE0+RVGQ8oKjT7PrIB Fqy5QBZ0E0CUjwPZB4qxvi5+tx7wSnWJMum+MIIDpjCCAw+gAwIBAgIQdY2CixcCBqp6zaea vSOwKDANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJbmMuIC0gRm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsw HhcNOTkwMjI1MDAwMDAwWhcNMDkwMjI0MjM1OTU5WjCBrTEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBp cyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3Ig KGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENsYXNzIDIgUGVyc29ubmVsIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCnBGwPonK3SgYu+NcpLDSdgrxIkUrHrPnp/LlZeLFVwFNY sc9vFjvBSdXL9G7M4czLtccuToiqNOm20Ft8PhVXNOEYvP/d9a9nWSAK5T3qiIpA0pqJEymp ttXbp37h5zckk/2UdE165DJtTOhcFpev3ZLZZooUZuTqWgOoPV/7CwIDAQABo4GwMIGtMBEG CWCGSAGG+EIBAQQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQEAwIBBjBEBgNVHSAE PTA7MDkGC2CGSAGG+EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNh Mi1nMi5jcmwwDQYJKoZIhvcNAQEFBQADgYEAUl62ldtvfKZ+BfZUhTvZGopFWV98wmXu+UDe VG7HkBKAJDxAo2PshR/1HhuJyj2O40su35wb7o7nVLlWk/7b0cRE+MucQJ2SrMXOBPERRuyI vJjIjCF9N5zMa700pZOMvZw5HeqnnBrN9UdtLHMTY2ohLlp9h328TL7yxwPCjLYwggPAMIID KaADAgECAhBKyAADY2HUFQMW8YY2m7fNMA0GCSqGSIb3DQEBBQUAMIGtMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UE CxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0Ew HhcNOTkwMjI1MDAwMDAwWhcNMDkwMjIzMjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBp cyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3Ig KGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1VrCDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk4 7ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO13+l9TiEhYdX8O1TJpAmcuyL5orpw YU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wgjf5/AgMBAAGjgd8wgdwwKQYD VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4MBEGCWCGSAGG+EIBAQQE AwIBBjAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjBEBgNVHSAEPTA7MDkGC2CGSAGG +EUBBxcCMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC52ZXJpc2lnbi5jb20vVlNDbGFzczJJbnQuY3Js MA0GCSqGSIb3DQEBBQUAA4GBADYY/TNg1hfTBLXYVF9SGuWSCCj0okDaw1uMGoaX766iFf5s xM4vyAHKM77yeVgzl5eSRXBaTigd3ffBiE4bh1cCPZMl2X5OcjWJSRezuXcvbQ75pIglwc52 c2VpBZN35/2Tlhg4TVhsep3o0pvo0NuJ/UnCdQQDl6XUloHYI0HwMYICHDCCAhgCAQEwgcEw gawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBAhACGIAs1dV22NMR6M6LcgSYMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwNTI4MjIxNzM5WjAjBgkqhkiG 9w0BCQQxFgQUjOtCOhPtMAOd/0LurnzT/jf05QIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYBaxD6WM251GEpLNZByP63Hls3+r22zqWEDTP3UjoLo F1HWv2jBkCCsl/WD4fwxcMfU6+G3xrevjViqF7AIDCsgA148FriivaC9JTz1AXfx6L9N/rPd VmZLDIrryeP96Bj/z+VYAYoxI3jbO1Km7kpOnhmbTaffpeIOW1+viMqEjQ== --O98KdSgI27dgYlM5-- -- 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 May 29 01:41:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07948 for ; Thu, 29 May 2003 01:41:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LFyW-0007p4-00 for namedroppers-data@psg.com; Thu, 29 May 2003 05:29:16 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19LFyU-0007nS-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 05:29:14 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E091A1396A for ; Thu, 29 May 2003 05:28:58 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-11: KEY RRs at delegation points In-Reply-To: Message from "Scott Rose" of "Wed, 28 May 2003 14:25:58 -0400." <000d01c32546$95c54de0$b9370681@barnacle> X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 29 May 2003 05:28:58 +0000 Message-Id: <20030529052858.E091A1396A@sa.vix.com> X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This was a sidebar topic in Q-8: non-zone KEY RRs at the apex. > > Q: Should KEY RRs (any) be allowed at delegation points? no. > Discussion: > There isn't a formal rule already in the documents prior to the DNSSECbis > re-write. The KEY@parent idea stated that the delegating zone key would > appear at a delegating parent in order to set up the chain of > authentication. > > Now with the DS RR, the zone KEY remains in the delegated child zone. In > the latest version of the protocol draft (-01), this is further restricted > by saying that KEY RRs MUST NOT appear at delegation points. The topic is > whether this restriction is necessary. > > If the KEY RR is to be considered glue RRs like the other RRs at the > delegation point, then it is not signed, and cannot be validated when > received with the delegation. Unless it is to be considered authoritative > for the delegating zone, like the DS RR. > > However, there is no harm to the protocol by allowing it, is there? yes. in addition to ed lewis's fine comments, the rule (made implicitly in 1034 and explicitly in 2181) is that everything at or below a delegation point is authoritative only in the child. this means NS and A RRs held in a parent zone that are at (NS) or at or below (A) the delegation point, are just hints. if the parent is queried for them, the result should be a delegation to the child. therefore anything present in the parent zone which is at or below a delegation point is only to be used for delegation responses. since a KEY RR is not used in delegation responses in a the DS world we are moving to, it should be an error to specify one at or below a delegation point in a parent zone. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 29 01:52:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08083 for ; Thu, 29 May 2003 01:52:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LGDF-0009FD-00 for namedroppers-data@psg.com; Thu, 29 May 2003 05:44:29 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19LGDD-0009DE-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 05:44:27 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0618E1396C; Thu, 29 May 2003 05:44:09 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Derek Atkins Cc: Edward Lewis , "Scott Rose" , namedroppers@ops.ietf.org Subject: Re: Another Proposal (was Re: DNSSECbis Q-11: KEY RRs at delegation points) In-Reply-To: Message from Derek Atkins of "28 May 2003 17:12:23 -0400." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 29 May 2003 05:44:08 +0000 Message-Id: <20030529054409.0618E1396C@sa.vix.com> X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Well, then, perhaps we should think of another way to doing it? well, no. we've pretty much blown any hope of significant deployment of dnssec in 2003. rearchitecture along the lines that you propose would certainly make it cleaner, but would also remove any hope that some of us may (secretly?) harbor for significant dnssec deployment in 2004. if i believed otherwise, then i'd publish the ednssec spec, which is even more radical than the "SIG bit" you and ohta and olafur have all independently proposed over the years, but which demotes all dnssec data to the status of "out of band metadata" and explifies the hop by hop issues. but since i do not believe otherwise, and i do not wish see ednssec lead inevitably toward an XSL replacement for DNS, i'm going to simply recommend that we not change dnssec in any nonessential way. the SIG bit isn't "essential" it's merely "better". -- 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 May 29 02:51:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20789 for ; Thu, 29 May 2003 02:51:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LH7Y-000EGs-00 for namedroppers-data@psg.com; Thu, 29 May 2003 06:42:40 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19LH7W-000EGY-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 06:42:38 +0000 Received: by sentry.rv.nailabs.com; id CAA15170; Thu, 29 May 2003 02:43:55 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma015157; Thu, 29 May 03 02:43:06 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6/8.11.6) with ESMTP id h4T6fjX14137; Thu, 29 May 2003 02:41:45 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Thu, 29 May 2003 02:41:45 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Derek Atkins cc: Subject: Re: Another Proposal (was Re: DNSSECbis Q-11: KEY RRs at delegation points) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_PINE, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 28 May 2003, Derek Atkins wrote: > ... why not take it one step further and fix this > problem for good: introduce a SIG Bit? See my 20 March message with subject "A Plea for Restraint". As Ed points out, the implications of a(n) (RR)SIG bit are non-trivial. For more complications, note that RFC 2929 allocates 65280-65534 (0xFF00-0xFFFE) for private use. It would be unseemly to revoke that allocation, potentially breaking applications that (ever how novel it may be) actually follow the spec's guidance re: what numbers to use. -- 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 Thu May 29 04:27:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22792 for ; Thu, 29 May 2003 04:27:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LIdJ-000Oqj-00 for namedroppers-data@psg.com; Thu, 29 May 2003 08:19:33 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 19LIdH-000OqW-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 08:19:31 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E4BE892; Thu, 29 May 2003 17:19:29 +0900 (JST) To: mcr@sandelman.ottawa.on.ca Cc: namedroppers@ops.ietf.org Subject: draft-ietf-ipseckey-rr-02.txt X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Thu, 29 May 2003 17:19:29 +0900 Message-Id: <20030529081929.E4BE892@coconut.itojun.org> X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_01,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk not sure if it is for ipsec wg, or dnsext wg... the meaning of "gateway" field is not clear enough. i can guess that it is IPsec gateway for IPsec tunnelling, but 2nd example "An example of a node, 192.0.2.38 that has published its key only." (gateway field being ".") confuses me. what does it mean? what kind of value should i put into "gateway" field if i want to ask people to do transport mode IPsec? maybe, draft-ietf-ipseckey-rr-02.txt should refer some other document like draft-richardson-ipsec-opportunistic-11.txt for its actual usage/meaning? itojun -- 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 May 29 07:29:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27214 for ; Thu, 29 May 2003 07:29:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LLRH-000Mff-00 for namedroppers-data@psg.com; Thu, 29 May 2003 11:19:19 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19LLRC-000Mdm-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 11:19:14 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26709; Thu, 29 May 2003 07:19:13 -0400 (EDT) Message-Id: <200305291119.HAA26709@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-07.txt Date: Thu, 29 May 2003 07:19:12 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) 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 : KEY RR Secure Entry Point (SEP) Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-07.txt Pages : 10 Date : 2003-5-28 With the DS resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-keyrr-key-signing-flag-07.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-keyrr-key-signing-flag-07.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: <2003-5-29072553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29072553.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 Thu May 29 11:39:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07685 for ; Thu, 29 May 2003 11:39:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LPEl-0008G4-00 for namedroppers-data@psg.com; Thu, 29 May 2003 15:22:39 +0000 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 19LPEh-0008Fd-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 15:22:36 +0000 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h4TFMMB4026813 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 29 May 2003 17:22:22 +0200 To: "Scott Rose" , Paul Vixie Cc: Subject: Re: DNSSECbis Q-11: KEY RRs at delegation points References: <000d01c32546$95c54de0$b9370681@barnacle> From: Simon Josefsson X-Payment: hashcash 1.2 0:030529:scottr@nist.gov:f36dd4c4dc9caff8 X-Hashcash: 0:030529:scottr@nist.gov:f36dd4c4dc9caff8 X-Payment: hashcash 1.2 0:030529:paul@vix.com:18d92b6a3ccc293c X-Hashcash: 0:030529:paul@vix.com:18d92b6a3ccc293c X-Payment: hashcash 1.2 0:030529:namedroppers@ops.ietf.org:bb20559a13c5b839 X-Hashcash: 0:030529:namedroppers@ops.ietf.org:bb20559a13c5b839 Date: Thu, 29 May 2003 17:22:21 +0200 In-Reply-To: <000d01c32546$95c54de0$b9370681@barnacle> (Scott Rose's message of "Wed, 28 May 2003 14:25:58 -0400") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" writes: > This was a sidebar topic in Q-8: non-zone KEY RRs at the apex. > > Q: Should KEY RRs (any) be allowed at delegation points? Yes. Otherwise, future DNS extensions are excluded from placing KEY RR's at delegation points. I.e., if DNSSECbis says KEY RRs MUST NOT be present at delegation points, prudent resolvers will reject them (or worse) if they are encountered, which could be harmful in the future. However, it is fine to say explicitly that DNSSECbis does not attach any semantics to KEY RRs at delegation points, and that the RFC 2535 usage for KEY RRs at delegation points is deprecated in favor of DS. Paul Vixie writes: >> However, there is no harm to the protocol by allowing it, is there? > > yes. in addition to ed lewis's fine comments, the rule (made implicitly > in 1034 and explicitly in 2181) is that everything at or below a > delegation point is authoritative only in the child. this means NS and > A RRs held in a parent zone that are at (NS) or at or below (A) the > delegation point, are just hints. if the parent is queried for them, > the result should be a delegation to the child. Right. 1034 and 2181 also does not say that only NS and A RRs are glue records. It may be useful to make KEY RRs glue records in the future, similar to how AAAA became useful as glue records. "Glue" above includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub- zones (NS records), address records that accompany those NS records (A, AAAA, etc), and any other stray data that might appear. > therefore anything present in the parent zone which is at or below a > delegation point is only to be used for delegation responses. Exactly. It does not make sense for DNSSECbis to disallow KEY RRs at delegation points, if someone wants to use them as glue. DNSSECbis should be silent on what constitutes glue records, just like 1034 and 2181 are. > since a KEY RR is not used in delegation responses in a the DS world we > are moving to, it should be an error to specify one at or below a > delegation point in a parent zone. DNSSECbis allows the KEY RR to be used for (as of yet undefined) DNS operations, some of those DNS operations may find it useful to use KEY RRs as glue records. I could not understand what harm allowing KEY RRs at delegation points would have, although your answer was supposedly intended as backing that point. Would you mind explaining the exact harm? E.g., complexity, efficiency, round-trips, or packet size. I claim the harm of disallowing them is that future (non-DNSSEC) DNS extensions are excluded from using KEY RRs as glue records. -- 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 May 29 13:05:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10252 for ; Thu, 29 May 2003 13:05:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LQa9-000CnD-00 for namedroppers-data@psg.com; Thu, 29 May 2003 16:48:49 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19LQa6-000Cn1-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 16:48:46 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 629A236B; Thu, 29 May 2003 12:48:43 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id DC82933F; Thu, 29 May 2003 12:48:42 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 333875; Thu, 29 May 2003 12:47:00 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <000d01c32546$95c54de0$b9370681@barnacle> Date: Thu, 29 May 2003 12:48:38 -0400 To: Simon Josefsson From: Edward Lewis Subject: Re: DNSSECbis Q-11: KEY RRs at delegation points Cc: "Scott Rose" , Paul Vixie , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:22 +0200 5/29/03, Simon Josefsson wrote: >Right. 1034 and 2181 also does not say that only NS and A RRs are >glue records. It may be useful to make KEY RRs glue records in the >future, similar to how AAAA became useful as glue records. 4.2.1 of RFC 1034: # To fix this problem, a zone contains "glue" RRs which are not # part of the authoritative data, and are address RRs for the servers. # These RRs are only necessary if the name server's name is "below" the # cut, and are only used as part of a referral response. Glue records are just the address records, not the NS RR's, (apparently) required to reach "down" below the zone cut. >It does not make sense for DNSSECbis to disallow KEY RRs at >delegation points, if someone wants to use them as glue. DNSSECbis >should be silent on what constitutes glue records, just like 1034 and >2181 are. If you allow KEY RR's to appear at delegation points (that is, in the parent zone of the delegation), you are introducing a new case - non-address glue records. This would include changes to AXFR. >I could not understand what harm allowing KEY RRs at delegation points >would have, although your answer was supposedly intended as backing >that point. Would you mind explaining the exact harm? E.g., >complexity, efficiency, round-trips, or packet size. I claim the harm >of disallowing them is that future (non-DNSSEC) DNS extensions are >excluded from using KEY RRs as glue records. The harm is that in allowing this to happen you are introducing something with is precedent setting. When this is done, you will then have to go through and stamp out all the "corner cases" that pop up as a result. This is an architectural danger - making a significant change like this. The harm in the operational sense is that you are now accommodating replicated data - besides having to make sure the DS RR set is correct, you want to make sure the KEY RR set is in sync - just like you have to with address glue. Another harm is that when the KEY records appear, the parent will feel obliged to return them, enlarging the response. Is this a savings? Well, no, because in a referral, the resolver will then be contacting the authoritative source anyway and will see the KEY RR set again because the authoritative source has no way of know whether or not the querier has the KEY RR set from the parent. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- 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 May 29 14:08:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12334 for ; Thu, 29 May 2003 14:08:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LRgp-000HQb-00 for namedroppers-data@psg.com; Thu, 29 May 2003 17:59:47 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 3.36 #1) id 19LRgh-000HQM-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 17:59:39 +0000 Received: from guava.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by gusto.araneus.fi (8.12.9/8.12.9) with ESMTP id h4THxKh1005171; Thu, 29 May 2003 10:59:20 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.9/8.11.6) with ESMTP id h4THxMBK006495; Thu, 29 May 2003 10:59:22 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h4THxKit006492; Thu, 29 May 2003 10:59:20 -0700 (PDT) Date: Thu, 29 May 2003 10:59:20 -0700 (PDT) Message-Id: <200305291759.h4THxKit006492@guava.araneus.fi> To: Edward Lewis Cc: Simon Josefsson , "Scott Rose" , Paul Vixie , Subject: Re: DNSSECbis Q-11: KEY RRs at delegation points In-Reply-To: References: <000d01c32546$95c54de0$b9370681@barnacle> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-36.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > >It does not make sense for DNSSECbis to disallow KEY RRs at > >delegation points, if someone wants to use them as glue. DNSSECbis > >should be silent on what constitutes glue records, just like 1034 and > >2181 are. > > If you allow KEY RR's to appear at delegation points (that is, in the > parent zone of the delegation), you are introducing a new case - > non-address glue records. Au contraire. By explicitly disallowing KEY records, you are introducing a new case, because no other record type is currently explicitly disallowed at delegation points in parent zones. Putting a KEY, LOC, RP, PTR, or any other random record type in the parent zone at a delegation point is nonsensical, and the record will effectively be ignored by the parent server when it formulates responses to queries. This does not mean creating such records should be forbidden - forbidding them serves no purpose, and if you require servers to enforce the prohibition on such records, it complicates the server for no actual benefit. It also makes it harder to create future extensions, as Simon noted. > This would include changes to AXFR. The existing AXFR specification says absolutely nothing about the treatment of KEY RRs at delegation points. My interpretation is that they are transfered just like any other record type at any other name of the parent zone, though as I'm sure you know, my interpretation of AXFR (embodied in draft-ietf-dnsext-axfr-clarify-05.txt) is subject to debate. Also note that RFC2136 section 7.18 already implies that zone transfers can include arbitrary data at and below a delegation point: 7.18. Previously existing names which are occluded by a new zone cut are still considered part of the parent zone, for the purposes of zone transfers, even though queries for such names will be referred to the new subzone's servers. If a zone cut is removed, all parent zone names that were occluded by it will again become visible to queries. (This is a clarification of [RFC1034].) > The harm is that in allowing this to happen you are introducing > something with is precedent setting. When this is done, you will > then have to go through and stamp out all the "corner cases" that pop > up as a result. This is an architectural danger - making a > significant change like this. If there are such corner cases, they already exist as a result of people being able to create e.g. LOC records at delegation points. > The harm in the operational sense is that you are now accommodating > replicated data - besides having to make sure the DS RR set is > correct, you want to make sure the KEY RR set is in sync - just like > you have to with address glue. Perhaps if you actually create a KEY record in the parent it should be kept in sync with the child. Or perhaps not. It doesn't really matter, because no one is suggesting that KEY records should actually be created - they serve no purpose in the DNSSEC protocol. The question is whether there is any point in *forbidding* them. What operational harm is being caused by the fact that someone can now put a LOC record in the parent zone and perhaps fail to keep it in sync with one in the child? Absolutely none, because no one actually does that, and even if they did, it would be effectively ignored. There is no need for KEY to be treated differently. > Another harm is that when the KEY records appear, the parent will > feel obliged to return them, enlarging the response. Why should it feel obligated to return them? Servers don't return any other records just because they happen to exist at the delegation point, and I don't see any special provisions for KEYs in the drafts. Perhaps it would be helpful to re-cast Q-11 in the form "Should KEY records at delegation points in parent zones be treated any different from other random (non-NS, non-DS) record types?", and settle the general question of what to do with random stuff at delegation points outside the context of DNSSEC. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 29 14:27:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13218 for ; Thu, 29 May 2003 14:27:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LS2I-000IvP-00 for namedroppers-data@psg.com; Thu, 29 May 2003 18:21:58 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19LS2E-000Iv3-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 18:21:55 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 6853863D; Thu, 29 May 2003 14:21:53 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id F3B53627; Thu, 29 May 2003 14:21:52 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 334098; Thu, 29 May 2003 14:20:10 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200305291759.h4THxKit006492@guava.araneus.fi> References: <000d01c32546$95c54de0$b9370681@barnacle> <200305291759.h4THxKit006492@guava.araneus.fi> Date: Thu, 29 May 2003 14:19:19 -0400 To: gson@nominum.com (Andreas Gustafsson) From: Edward Lewis Subject: Re: DNSSECbis Q-11: KEY RRs at delegation points Cc: Edward Lewis , Simon Josefsson , "Scott Rose" , Paul Vixie , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:59 -0700 5/29/03, Andreas Gustafsson wrote: >Perhaps it would be helpful to re-cast Q-11 in the form "Should KEY >records at delegation points in parent zones be treated any different >from other random (non-NS, non-DS) record types?", and settle the >general question of what to do with random stuff at delegation points >outside the context of DNSSEC. Yeah. I was under the impression that one implementation, BIND, refused to load out of zone glue - hence I interpret more tightly the words in 1034 - the ones I quoted - as saying only address glue is acceptable. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- 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 May 29 15:28:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16418 for ; Thu, 29 May 2003 15:28:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LStr-000Mtl-00 for namedroppers-data@psg.com; Thu, 29 May 2003 19:17:19 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19LStp-000MtV-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 19:17:17 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19LSto-000HFX-Qt for namedroppers@ops.ietf.org; Thu, 29 May 2003 12:17:16 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 29 May 2003 12:17:16 -0700 To: namedroppers Subject: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt Message-Id: X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit this initiates a two week wg last call on draft-ietf-dnsext-dnssec-2535typecode-change-01.txt and, should it be info or ps? i suspect the latter as it modifies a ps document, but i could be wrong. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu May 29 15:43:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16916 for ; Thu, 29 May 2003 15:43:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LTAb-000ON4-00 for namedroppers-data@psg.com; Thu, 29 May 2003 19:34:37 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19LTAZ-000OMm-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 19:34:35 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id D596433C; Thu, 29 May 2003 15:34:34 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 84463325; Thu, 29 May 2003 15:34:34 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 334291; Thu, 29 May 2003 15:32:51 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 29 May 2003 15:34:31 -0400 To: Randy Bush From: Edward Lewis Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:17 -0700 5/29/03, Randy Bush wrote: >this initiates a two week wg last call on > > draft-ietf-dnsext-dnssec-2535typecode-change-01.txt > >and, should it be info or ps? i suspect the latter as it modifies >a ps document, but i could be wrong. It should definitely be standards track (or die trying). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- 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 May 29 18:51:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25694 for ; Thu, 29 May 2003 18:51:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LW1v-000Faz-00 for namedroppers-data@psg.com; Thu, 29 May 2003 22:37:51 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19LW1t-000FW6-00 for namedroppers@ops.ietf.org; Thu, 29 May 2003 22:37:49 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4TMapl3018022; Fri, 30 May 2003 08:36:51 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4TMak7T011602; Fri, 30 May 2003 08:36:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305292236.h4TMak7T011602@drugs.dv.isc.org> To: Edward Lewis Cc: gson@nominum.com (Andreas Gustafsson), Simon Josefsson , "Scott Rose" , Paul Vixie , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSSECbis Q-11: KEY RRs at delegation points In-reply-to: Your message of "Thu, 29 May 2003 14:19:19 -0400." Date: Fri, 30 May 2003 08:36:46 +1000 X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 10:59 -0700 5/29/03, Andreas Gustafsson wrote: > >Perhaps it would be helpful to re-cast Q-11 in the form "Should KEY > >records at delegation points in parent zones be treated any different > >from other random (non-NS, non-DS) record types?", and settle the > >general question of what to do with random stuff at delegation points > >outside the context of DNSSEC. > > Yeah. > > I was under the impression that one implementation, BIND, refused to > load out of zone glue - hence I interpret more tightly the words in > 1034 - the ones I quoted - as saying only address glue is acceptable. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Digital cameras are to film cameras as Etch-A-Sketches are to canvases. > > -- > 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: Out of zone glue is a record with a ownername that is not below the name of the zone. BIND 8 will reject non-glue below the zone as it has no way to store it. BIND 9 will accept non-glue below the zone. BIND 9 masters will reject out of zone glue. BIND 9 slaves will accept (but not return) out of zone glue (next release). -- Mark Andrews, Internet Software Consortium 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 Fri May 30 02:15:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20556 for ; Fri, 30 May 2003 02:15:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Lczn-000Jew-00 for namedroppers-data@psg.com; Fri, 30 May 2003 06:04:07 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19Lczl-000JdZ-00 for namedroppers@ops.ietf.org; Fri, 30 May 2003 06:04:05 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4U63Xl3018421 for ; Fri, 30 May 2003 16:03:33 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h4U63V7T013557 for ; Fri, 30 May 2003 16:03:33 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200305300603.h4U63V7T013557@drugs.dv.isc.org> Cc: namedroppers From: Mark.Andrews@isc.org Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt In-reply-to: Your message of "Thu, 29 May 2003 12:17:16 MST." Date: Fri, 30 May 2003 16:03:31 +1000 X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > this initiates a two week wg last call on > > draft-ietf-dnsext-dnssec-2535typecode-change-01.txt This looks fine to me and should be adopted as a PS. -- Mark Andrews, Internet Software Consortium 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 Fri May 30 08:13:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01982 for ; Fri, 30 May 2003 08:13:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LiYd-0008DJ-00 for namedroppers-data@psg.com; Fri, 30 May 2003 12:00:27 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19LiYa-0008Cv-00 for namedroppers@ops.ietf.org; Fri, 30 May 2003 12:00:24 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h4UC04bd008742 for ; Fri, 30 May 2003 08:00:04 -0400 (EDT) Message-ID: <009001c326a3$0201e830$b9370681@barnacle> From: "Scott Rose" To: "namedroppers" References: Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt Date: Fri, 30 May 2003 08:00:05 -0400 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have no (further) comments on the draft. I think it should be progressed as a PS doc, since it does change the spec (arbeit minor). Scott ----- Original Message ----- From: "Randy Bush" To: "namedroppers" Sent: Thursday, May 29, 2003 3:17 PM Subject: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt > this initiates a two week wg last call on > > draft-ietf-dnsext-dnssec-2535typecode-change-01.txt > > and, should it be info or ps? i suspect the latter as it modifies > a ps document, but i could be wrong. > > randy > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > 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 May 30 11:55:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14145 for ; Fri, 30 May 2003 11:55:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Llzm-0008Tm-00 for namedroppers-data@psg.com; Fri, 30 May 2003 15:40:42 +0000 Received: from oban.ihren.org ([192.71.80.248] helo=oban.autonomica.net) by psg.com with esmtp (Exim 3.36 #1) id 19Llzj-0008TM-00 for namedroppers@ops.ietf.org; Fri, 30 May 2003 15:40:39 +0000 Received: by oban.autonomica.net (Postfix, from userid 501) id 542D71BC011; Fri, 30 May 2003 17:40:25 +0200 (CEST) To: namedroppers Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt References: From: Johan Ihren Date: Fri, 30 May 2003 17:40:24 +0200 In-Reply-To: (Randy Bush's message of "Thu, 29 May 2003 12:17:16 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-37.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy Bush writes: > this initiates a two week wg last call on > > draft-ietf-dnsext-dnssec-2535typecode-change-01.txt > > and, should it be info or ps? i suspect the latter as it modifies > a ps document, but i could be wrong. This is important to be done with ASAP. The document is fine and should be PS, not info. Johan -- 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 May 30 12:42:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14147 for ; Fri, 30 May 2003 11:55:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LlzY-0008Se-00 for namedroppers-data@psg.com; Fri, 30 May 2003 15:40:28 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19LlzW-0008S6-00 for namedroppers@ops.ietf.org; Fri, 30 May 2003 15:40:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 326C21396A; Fri, 30 May 2003 15:40:13 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: "Scott Rose" Cc: "namedroppers" Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt In-Reply-To: Message from "Scott Rose" of "Fri, 30 May 2003 08:00:05 -0400." <009001c326a3$0201e830$b9370681@barnacle> X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 30 May 2003 15:40:13 +0000 Message-Id: <20030530154013.326C21396A@sa.vix.com> X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I have no (further) comments on the draft. I think it should be progressed > as a PS doc, since it does change the spec (arbeit minor). > > Scott i am hoping that it will be rolled into the DNSSECbis docs and not become the first post-revolution change. imagine how nice it would be if, for one shining instant, a single unified document series described the whole of dnssec. re: > ----- Original Message ----- > From: "Randy Bush" > To: "namedroppers" > Sent: Thursday, May 29, 2003 3:17 PM > Subject: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt > > > > this initiates a two week wg last call on > > > > draft-ietf-dnsext-dnssec-2535typecode-change-01.txt > > > > and, should it be info or ps? i suspect the latter as it modifies > > a ps document, but i could be wrong. > > > > randy > > > > > > -- > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > 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: -- 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 May 31 23:19:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17673 for ; Sat, 31 May 2003 23:19:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MJ4m-000F1g-00 for namedroppers-data@psg.com; Sun, 01 Jun 2003 03:00:04 +0000 Received: from randy by psg.com with local (Exim 3.36 #1) id 19MJ4j-000F18-00 for namedroppers@ops.ietf.org; Sun, 01 Jun 2003 03:00:01 +0000 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Sun, 01 Jun 2003 03:00:01 +0000 X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. posts are only accepted from subscribers. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have your alternate address added to the list of addresses from which submissions are automatically accepted. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. 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. -- 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: