From owner-namedroppers@ops.ietf.org Tue Apr 1 00:36: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 AAA13969 for ; Tue, 1 Apr 2003 00:35:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190E9w-00006H-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 21:18:08 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190E9t-000063-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 21:18:05 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3150lC30273 for ; Mon, 31 Mar 2003 21:00:47 -0800 Date: Mon, 31 Mar 2003 21:00:47 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 28 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would propose to accept the change proposed in Issue 28. Any objections? Issue 28: Addressing Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: January 17, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: 2.5 Rationale/Explanation of issue: Change: "For IPv4 link-scope addressing, section 2.4 of "Dynamic Configuration of IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to source address selection, TTL settings, and acceptable source/destination address combinations. IPv6 is described in [RFC2460]; IPv6 link-scope addressing is described in [RFC2373]. LLMNR queries and responses obey the rules laid out in these documents. " To: "The source address of LLMNR queries and responses MUST be "on link". The destination address of an LLMNR query MUST be a link-scope multicast address or an "on link" unicast address; the destination address of an LLMNR response MUST be an "on link" unicast address. For IPv4, an "on link" address is defined as an address whose prefix belongs to a subnet on the local link; for IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or an address whose prefix belongs to a subnet on the local link. LLMNR senders or responders receiving LLMNR packets from a source address that is not "on link" SHOULD silently discard them. " -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 1 00:38: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 AAA14012 for ; Tue, 1 Apr 2003 00:38:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190EMI-0001K7-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 21:30:54 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190EMB-0001Jh-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 21:30:47 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h315DTl30870 for ; Mon, 31 Mar 2003 21:13:29 -0800 Date: Mon, 31 Mar 2003 21:13:29 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 29: Valid Responses 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would like to propose that the change proposed in LLMNR Issue 29 be accepted. Any objections? Issue 29: Valid Responses Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: January 17, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: 3 Rationale/Explanation of issue: Insert the following text in Section 3: "RRs returned in LLMNR responses MUST only include values that are valid on the local interface, such as IPv4 or IPv6 addresses valid on the local link or domain names defended using the mechanism described in Section 4. In particular: [4] If a link-scope IPv6 address is returned in a AAAA RR, that address MUST be valid on the local link over which LLMNR is used. [5] If an IPv4 address is returned, it must be reachable through the link over which LLMNR is used. [6] If a domain name is returned (for example in a CNAME, MX or SRV RR), the name MUST be valid on the local interface." -- to unsubscribe send a message to namedroppers-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 Apr 1 00:58: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 AAA14240 for ; Tue, 1 Apr 2003 00:58:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190EfO-0003JS-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 21:50:38 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190EfJ-0003J5-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 21:50:34 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h315XFH31998 for ; Mon, 31 Mar 2003 21:33:15 -0800 Date: Mon, 31 Mar 2003 21:33:15 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 21: PTR queries 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Given the discussion at IETF 56 and the currently proposed resolutions to Issue 28 and 29, I would like to propose that sending of LLMNR queries for PTR RRs that represent "off link" addresses should be discouraged. The proposed resolution is given below. Comments? Issue 21: PTR queries Submitter: Markku Savela Submitter email address: msa@burp.tkv.asdf.org Date first submitted: November 4, 2002 Reference: <200211041445.QAA12218@burp.tkv.asdf.org> Document: LLMNR-12 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I assume that if you end up doing a address (fe80::1) to name query for IPv6, you end up sending a query to IPv6 multicast address generated from the hash of "1.0.0. ... 0.0.8.e.f.ip6.int" and because the hash is taken from the first label, this will be MD5 from "1"? (basically only 16 different hashes are possible). IPv4 side you have for example "1.2.254.169.in-addr.arpa". Am I right assuming the "resolvers" on nodes have to deal also with these for link local name resolution? [BA] Yes, it is expected that senders will send PTR queries, and that receivers will respond to them. However, it probably doesn't make sense to send a PTR query for an address that isn't on the local link. Here's the proposed resolution: Add the following text to Section 3: "[3] A sender SHOULD only send LLMNR queries for PTR RRs that are known to be "on link" as defined in Section 2.5." [Erik Guttman and Erik Nordmark]: The problem is that in practice a host may not know the prefixes in use on a particular link. So this restriction can't work in practice. [Comment from Mark T. Hollinger ]: I think we are being too hasty to throw out this restriction. As I metioned in my recent Namedroppers post, supporting your original proposal for issue #3, I would like the fallback to LLMNR not to occur at all for apparantly non-local prefixes. If there is a prefix on your link that you don't know about via your routing table, then I don't think LLMNR needs to handle inverse queries for that zone. The target user for LLMNR probably won't have multiple unadvertised global prefixes in the first place. Anybody sophisticated enough to set that up will already have the address of a DNS server configured. Also, if you don't know about the other guy's prefix, he may not know about yours either, in which case he'll get your multicast request but try to send a unicast response via the router, which may decrement the TTL when forwarding it back onto the same link. I'm not sure LLMNR will work in this case (due to the TTL 255 check), but even if it works, I think a configuration where hosts have to communicate (even only initially) via a router is out-of-scope for LLMNR. Let traditional DNS handle that case; we don't need LLMNR there. [BA] Back of the envelope calculations seem to indicate to me that bogus PTR queries can be a significant problem in some cases. Measurements show that a significant fraction of DNS queries are not answered, and this is particularly true with PTR queries. So we can have a substantial amount of bogus LLMNR PTR query traffic. I am particularly worried about wireless networks with lots of people like at IETF 56. 5 queries a second from 3000 people would end up eating up a significant fraction of the total bandwidth of an 802.11 network, particularly if there are lots of folks who have to step down to lower rates (1,2,5 Mbps). So there is some reason for concern. In the discussion at IETF 56, there was concern that it might not be possible for a host to know all the networks it was connected to. The question then arises as to whether it is ok not to send a PTR query for addresses on networks the host doesn't know about. It was pointed out that if the host doesn't have a route for that address, then it will route the packet to the gateway, which might not have a route for it either. In view of the proposed resolution to Issue 28 and 29, it would appear that it makes little sense to send queries for PTR RRs that aren't "on link". -- to unsubscribe send a message to namedroppers-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 Apr 1 01:48: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 BAA14957 for ; Tue, 1 Apr 2003 01:48:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190FSt-0007Vc-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 22:41:47 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190FSS-0007Uw-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 22:41:20 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h316O2A02357 for ; Mon, 31 Mar 2003 22:24:02 -0800 Date: Mon, 31 Mar 2003 22:24:02 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 27: Editorial NITs 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would like to propose that the change described below be accepted. Any objections? Issue 27: Editorial Nits Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: January 17, 2003 Reference: Document: LLMNR-13 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: Throughout the document, replace "LINKLOCAL" with "link-scope multicast". -- to unsubscribe send a message to namedroppers-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 Apr 1 01:48: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 BAA14979 for ; Tue, 1 Apr 2003 01:48:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190FUA-0007Z1-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 22:43:06 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190FU4-0007Yo-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 22:43:00 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h316Pg402430 for ; Mon, 31 Mar 2003 22:25:42 -0800 Date: Mon, 31 Mar 2003 22:25:42 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 30: Why is Dynamic Update Needed? 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 30: Why is Dynamic Update needed? Submitter: Erik Guttman Submitter email address: erik.guttman@sun.com Date first submitted: March 24, 2003 Reference: Document: LLMNR-14 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: Maybe I'm missing something, but I do not understand why a host with UNIQUE RRs needs to test for uniqueness by sending a Dynamic Update request for the RR with a prerequisite of NXRRSET. Why would it not be sufficient to send a query for the RR? Within the draft, a host that has a UNIQUE RR and receives a Dynamic Update request will respond with the YXRRSET error, because the RR does exist. The draft does not state how the host should respond if the RR is not UNIQUE. Doesn't it also send a YXRRSET error? If so, then the sender receives no information about whether the host thinks that the RR is really UNIQUE or not. Given this, it seems to me that the same result could be accomplished more simply by sending a query for the RR. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 1 02:39: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 CAA27872 for ; Tue, 1 Apr 2003 02:39:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190GGi-0009Hm-00 for namedroppers-data@psg.com; Mon, 31 Mar 2003 23:33:16 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 190GGf-0009Ha-00 for namedroppers@ops.ietf.org; Mon, 31 Mar 2003 23:33:13 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h317WuER002106; Tue, 1 Apr 2003 09:32:56 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) id h317Wu9T002105; Tue, 1 Apr 2003 09:32:56 +0200 Date: Tue, 1 Apr 2003 09:32:56 +0200 From: Miek Gieben To: Edward Lewis Cc: namedroppers Subject: Re: secure entry point Message-ID: <20030401073256.GA2029@atoom.net> Mail-Followup-To: Edward Lewis , namedroppers References: <20030331133521.GA3042@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 01 Apr, @00:16, Edward wrote in "Re: secure entry point ..."] > That's how I defined it in the 1998 secure resolver, using a file > called "/etc/sresolv.conf" as a replacement for /etc/resolv.conf. > It worked well. same here, in my little perl implementation I used resolvsec.conf, and I also stored the IP numbers there. I really think that for a resolver a SEP should be defined as: a key + ip address(es). grtz Miek -- :wq! -- to unsubscribe send a message to namedroppers-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 Apr 1 04:48: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 EAA02447 for ; Tue, 1 Apr 2003 04:48:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190IEA-000Dj6-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 01:38:46 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 190IE5-000Dit-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 01:38:41 -0800 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 0CCDE528D; Tue, 1 Apr 2003 11:38:39 +0200 (MEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id C477E1D9B; Tue, 1 Apr 2003 11:38:38 +0200 (MEST) Date: Tue, 1 Apr 2003 11:38:39 +0200 (CEST) From: Jakob Schlyter To: Miek Gieben Cc: Edward Lewis , namedroppers Subject: Re: secure entry point In-Reply-To: <20030401073256.GA2029@atoom.net> Message-ID: References: <20030331133521.GA3042@atoom.net> <20030401073256.GA2029@atoom.net> 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Apr 2003, Miek Gieben wrote: > same here, in my little perl implementation I used resolvsec.conf, > and I also stored the IP numbers there. I really think that for a > resolver a SEP should be defined as: a key + ip address(es). if a zone is moved from one name server to another, why should you need to update your resolver configuration file? the only ip address based entry point we really need have in the dns is the root. 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 Tue Apr 1 04:56: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 EAA02531 for ; Tue, 1 Apr 2003 04:56:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190IN4-000E2z-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 01:47:58 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 190IN1-000E2n-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 01:47:55 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h319lXER011682; Tue, 1 Apr 2003 11:47:33 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) id h319lXRj011681; Tue, 1 Apr 2003 11:47:33 +0200 Date: Tue, 1 Apr 2003 11:47:33 +0200 From: Miek Gieben To: Jakob Schlyter Cc: Edward Lewis , namedroppers Subject: Re: secure entry point Message-ID: <20030401094733.GA11594@atoom.net> Mail-Followup-To: Jakob Schlyter , Edward Lewis , namedroppers References: <20030331133521.GA3042@atoom.net> <20030401073256.GA2029@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 01 Apr, @11:38, Jakob wrote in "Re: secure entry point ..."] > On Tue, 1 Apr 2003, Miek Gieben wrote: > > > same here, in my little perl implementation I used resolvsec.conf, > > and I also stored the IP numbers there. I really think that for a > > resolver a SEP should be defined as: a key + ip address(es). > > if a zone is moved from one name server to another, why should you need to > update your resolver configuration file? how do you securely get the ip address for a secure entry point? There is no secured delegation that you can check. > the only ip address based entry point we really need have in the dns is > the root. if the root is secured it is simple, but even then the definition of a secure entry point is: key + root ip adresses grtz Miek -- :wq! -- to unsubscribe send a message to namedroppers-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 Apr 1 04:58: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 EAA02575 for ; Tue, 1 Apr 2003 04:58:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190ITK-000EK2-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 01:54:26 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 190ITH-000EJg-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 01:54:24 -0800 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 2793F528D; Tue, 1 Apr 2003 11:54:23 +0200 (MEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id C68B31D9B; Tue, 1 Apr 2003 11:54:22 +0200 (MEST) Date: Tue, 1 Apr 2003 11:54:23 +0200 (CEST) From: Jakob Schlyter To: Miek Gieben Cc: Edward Lewis , namedroppers Subject: Re: secure entry point In-Reply-To: <20030401094733.GA11594@atoom.net> Message-ID: References: <20030331133521.GA3042@atoom.net> <20030401073256.GA2029@atoom.net> <20030401094733.GA11594@atoom.net> 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Apr 2003, Miek Gieben wrote: > how do you securely get the ip address for a secure entry point? There is no > secured delegation that you can check. you don't. since you have the key you know that the zone is secure, but you do not know where to find it. you could make it a stub zone in your caching nameserver, but that is separate issue. > if the root is secured it is simple, but even then the definition of a secure > entry point is: key + root ip adresses how to find the root is separate from securing it. 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 Tue Apr 1 05:20: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 FAA02994 for ; Tue, 1 Apr 2003 05:20:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190IiV-000Exo-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 02:10:07 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 190IiK-000Ewe-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 02:09:56 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h31A9jER012143; Tue, 1 Apr 2003 12:09:45 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) id h31A9jtH012142; Tue, 1 Apr 2003 12:09:45 +0200 Date: Tue, 1 Apr 2003 12:09:45 +0200 From: Miek Gieben To: Jakob Schlyter Cc: Edward Lewis , namedroppers Subject: Re: secure entry point Message-ID: <20030401100944.GA11835@atoom.net> Mail-Followup-To: Jakob Schlyter , Edward Lewis , namedroppers References: <20030331133521.GA3042@atoom.net> <20030401073256.GA2029@atoom.net> <20030401094733.GA11594@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 01 Apr, @11:54, Jakob wrote in "Re: secure entry point ..."] > On Tue, 1 Apr 2003, Miek Gieben wrote: > > > how do you securely get the ip address for a secure entry point? There is no > > secured delegation that you can check. > > you don't. since you have the key you know that the zone is secure, but > you do not know where to find it. but I do think this is an issue. Not knowing where to find the zone is fatal, even if you do have to key and know the zone should be secured. Spoof the nameserver ip, and the resolver gets bad data, there is no way the resolver can guard against such an attack. And if you change nameservers you will probably also change the key, so the resolver already has to update something. With little extra work the ip number can also be updated. (This is a bold statement, but nameserver changes without changing the key will be rare, I think) grtz Miek -- to unsubscribe send a message to namedroppers-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 Apr 1 05:23: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 FAA03089 for ; Tue, 1 Apr 2003 05:23:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190InA-000FAU-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 02:14:56 -0800 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 190In7-000FAA-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 02:14:53 -0800 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 7B15B528B; Tue, 1 Apr 2003 12:14:52 +0200 (MEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id 11A401D9B; Tue, 1 Apr 2003 12:14:52 +0200 (MEST) Date: Tue, 1 Apr 2003 12:14:52 +0200 (CEST) From: Jakob Schlyter To: Miek Gieben Cc: Edward Lewis , namedroppers Subject: Re: secure entry point In-Reply-To: <20030401100944.GA11835@atoom.net> Message-ID: References: <20030331133521.GA3042@atoom.net> <20030401073256.GA2029@atoom.net> <20030401094733.GA11594@atoom.net> <20030401100944.GA11835@atoom.net> 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 1 Apr 2003, Miek Gieben wrote: > Spoof the nameserver ip, and the resolver gets bad data, there is no > way the resolver can guard against such an attack. the resolver can always detect if it had received bad data. > And if you change nameservers you will probably also change the key, so > the resolver already has to update something. why would you ever change the key if you change nameserver? distributing the signed zone and signing it is very different. 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 Tue Apr 1 05:29: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 FAA03232 for ; Tue, 1 Apr 2003 05:29:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190IvV-000FaM-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 02:23:33 -0800 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 190IvS-000FaA-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 02:23:30 -0800 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) with ESMTP id h31ANDER018702; Tue, 1 Apr 2003 12:23:13 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-5) id h31ANDt2018701; Tue, 1 Apr 2003 12:23:13 +0200 Date: Tue, 1 Apr 2003 12:23:13 +0200 From: Miek Gieben To: Jakob Schlyter Cc: Edward Lewis , namedroppers Subject: Re: secure entry point Message-ID: <20030401102313.GA13787@atoom.net> Mail-Followup-To: Jakob Schlyter , Edward Lewis , namedroppers References: <20030331133521.GA3042@atoom.net> <20030401073256.GA2029@atoom.net> <20030401094733.GA11594@atoom.net> <20030401100944.GA11835@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-26.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 01 Apr, @12:14, Jakob wrote in "Re: secure entry point ..."] > On Tue, 1 Apr 2003, Miek Gieben wrote: > > > Spoof the nameserver ip, and the resolver gets bad data, there is no > > way the resolver can guard against such an attack. > > the resolver can always detect if it had received bad data. yes.. so if I spoof the secure entry IP for .nl, the whole of .nl is bad > > And if you change nameservers you will probably also change the key, so > > the resolver already has to update something. > > why would you ever change the key if you change nameserver? distributing > the signed zone and signing it is very different. I'm in the process of writing down how DNS operations will look like when DNSSEC is deployed. Maybe we should take this up on the cafax list. grtz Miek -- to unsubscribe send a message to namedroppers-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 Apr 1 06:10:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03890 for ; Tue, 1 Apr 2003 06:10:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190JUs-000H8a-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 03:00:06 -0800 Received: from randy by psg.com with local (Exim 3.36 #1) id 190JUn-000H7t-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 03:00:01 -0800 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Tue, 01 Apr 2003 03:00:01 -0800 X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-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: From owner-namedroppers@ops.ietf.org Tue Apr 1 06:43: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 GAA04486 for ; Tue, 1 Apr 2003 06:43:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190K1K-000InM-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 03:33:38 -0800 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 190K1H-000In7-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 03:33:36 -0800 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h31BULRp005518; Tue, 1 Apr 2003 13:30:21 +0200 Date: Tue, 1 Apr 2003 13:30:20 +0200 From: "Olaf M. Kolkman" To: Miek Gieben Cc: Jakob Schlyter , Edward Lewis , namedroppers Subject: Re: secure entry point Message-Id: <20030401133020.0cfc1d29.olaf@ripe.net> In-Reply-To: <20030401102313.GA13787@atoom.net> References: <20030331133521.GA3042@atoom.net> <20030401073256.GA2029@atoom.net> <20030401094733.GA11594@atoom.net> <20030401100944.GA11835@atoom.net> <20030401102313.GA13787@atoom.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > yes.. so if I spoof the secure entry IP for .nl, the whole of .nl is bad Yes.. Bad luck I'd say. DNSSEC does not provide for a way to check the delegation. If a delegation points you to the wrong server your lost; that is to be seen as a DOS attack. If you want to be 'resistant' to drop of connectivity to the root than have your recursive servers be slave of your local domains. That can be done independend of your "trusted-keys". DNSSEC does not give a bit about where data came from. Let's not add that dependency in the resolv.conf you (provide buckshots to shoot ones foot off :-) ) --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-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 Apr 1 09:17: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 JAA12552 for ; Tue, 1 Apr 2003 09:17:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190MS2-0002Sh-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 06:09:22 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 190MRp-0002Ru-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 06:09:09 -0800 Received: from [192.149.252.108] ([192.136.136.39]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA16069; Tue, 1 Apr 2003 09:08:59 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <20030401073256.GA2029@atoom.net> References: <20030331133521.GA3042@atoom.net> <20030401073256.GA2029@atoom.net> Date: Tue, 1 Apr 2003 08:53:31 -0500 To: Miek Gieben From: Edward Lewis Subject: Re: secure entry point Cc: Edward Lewis , namedroppers 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I would recommend this in a resolver implementation, but defining this as part of the protocol would take too much debate time. At 9:32 +0200 4/1/03, Miek Gieben wrote: >[On 01 Apr, @00:16, Edward wrote in "Re: secure entry point ..."] >> That's how I defined it in the 1998 secure resolver, using a file >> called "/etc/sresolv.conf" as a replacement for /etc/resolv.conf. >> It worked well. > >same here, in my little perl implementation I used resolvsec.conf, >and I also stored the IP numbers there. I really think that for a >resolver a SEP should be defined as: a key + ip address(es). > >grtz Miek > >-- >:wq! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 1 09:20: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 JAA12717 for ; Tue, 1 Apr 2003 09:20:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190MRs-0002SJ-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 06:09:12 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 190MRp-0002Rt-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 06:09:09 -0800 Received: from [192.149.252.108] ([192.136.136.39]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA16073; Tue, 1 Apr 2003 09:09:01 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: References: <20030331133521.GA3042@atoom.net> <20030401073256.GA2029@atoom.net> Date: Tue, 1 Apr 2003 09:07:28 -0500 To: Jakob Schlyter From: Edward Lewis Subject: Re: secure entry point Cc: Miek Gieben , Edward Lewis , 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:38 +0200 4/1/03, Jakob Schlyter wrote: >if a zone is moved from one name server to another, why should you need to >update your resolver configuration file? Because I'm paranoid. There's a sliding scale from brittle to resilient. Given any system, with it's place on the brittle-to-resilient scale, once you add security to it, it slides towards brittle (because you've restricting it from entering some states). The big challenge in adding security to a resilient system is to maintain as much resiliency as possible. This points to not fixing the IP numbers of the authoritative servers in the secure resolver configuration. However, securing a brittle system is easier than securing a resilient system. The more restricted the set of states a system can enter, the easier it is to prevent it from entering an insecure one. Entering the IP numbers does make the resolver more brittle, but that's under my (the resolver operator) control. Essentially, I've moved the resiliency up into wetware - someone has to configure again when a change is made. Retaining resiliency by requiring more manual intervention is something only the paranoid should do, that's why I like the idea, but wouldn't push for documenting this as standard behavior. >the only ip address based entry point we really need have in the dns is >the root. Not exactly true - LLMNR and disconnected networks come to mind. (One of my scenarios was a ship a sea.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 1 09:37:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14224 for ; Tue, 1 Apr 2003 09:37:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190Mi3-0003aB-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 06:25:55 -0800 Received: from zydeco.netbusters.com ([66.92.86.178]) by psg.com with esmtp (Exim 3.36 #1) id 190Mhz-0003Zl-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 06:25:51 -0800 Received: by zydeco.netbusters.com (Postfix, from userid 513) id E3068B63B0; Tue, 1 Apr 2003 14:25:50 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id DFED27EC1B; Tue, 1 Apr 2003 09:25:50 -0500 (EST) Date: Tue, 1 Apr 2003 09:25:50 -0500 (EST) From: Donald Eastlake 3rd X-X-Sender: dee3@zydeco.netbusters.com To: namedroppers@ops.ietf.org Cc: Donald.Eastlake@motorola.com Subject: Re: draft-ietf-dnsext-insensitive-02.txt In-Reply-To: <200303210016.h2L0GTLU000825@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Andreas, Thanks for the comments. See responses below: On Thu, 20 Mar 2003, Andreas Gustafsson wrote: > Date: Thu, 20 Mar 2003 16:16:29 -0800 (PST) > From: Andreas Gustafsson > Subject: draft-ietf-dnsext-insensitive-02.txt > > A couple of issues with draft-ietf-dnsext-insensitive-02: > > First of all, the draft seems much longer than it needs to be. Keep > in mind that the draft arose from the following request from Erik > Nordmark: > > [...] it would be quite helpful to point out that the DNS servers notion > of "case" is limited to octets that are in the ASCII range. > Otherwise folks will continue to discuss what case sensitive means > for octet values >128. > > That could be said in a single sentence. The text on classes and > extended label types in sections 3.1-3.2 are useful additional > clarifications, but there is no real need for an extended treatment > that at best repeats what is already said in STD 13 and at worst > conflicts with it, or for historical notes on the development of > movable type. My goal in the draft is to be excruciating clear. If you assume clueful readers, nothing is needed in addition to STD 13. This draft tries to fill in some background and explain relevant points as precisely and clearly as possible, even at the expense of some redundancy, and not assuming the reader can make any but the most simple deductions from general principles. I'll see if I can tighten up the wording a little bit. > 2.1 Escaping Unusual DNS Label Octets > > The purpose of section 2.1 is unclear. Is it merely defining the > notation used for domain names in the remainder of the draft (if so, > why not simply refer to RFC1035 section 5?), or is it intended as a > clarification or update to RFC1035 section 5? > > Originally, DNS input came from an ASCII Master File as defined in > [STD 13]. DNS Dynamic update has been added as a source of DNS data > [RFC 2136, 3007]. When a node in the DNS name tree is created by such > input, no case conversion is done and the case of ASCII labels is > preserved if they are for nodes being created. However, no change is > made in the name label on nodes that already exist in the DNS data > being augmented or updated. > [...] > The same considerations apply when inputting multiple data records > with owner names differing only in case. From the example above, if > an "A" record is stored under owner name "xyz.BAR.example" and then a > second "A" record under "XYZ.BAR.example", the second will be stored > at the node with the first (lower case initial label) name. > > I have a problem with this text. It seems to imply that > implementations must not, and do not, update the character case of > existing labels in the database when they receive new data having a > different character case (e.g., in a dynamic update), but such > updating is not forbidden by STD 13. One could even argue that > updating the case would be desirable since the most recently added > data are more likely to reflect the administrator's current > preferences regarding character case than the oldest data. I would > like the draft to be changed to say that the final node may have the > character case of either the initial name or the new name, assuming > this text needs to be there at all. OK, that's a good point and I will change the draft there. > Another issue that needs to cleared up is whether the text in RFC1035 > section 2.3.3 saying > > In general, this preserves the case of the first label of a domain > name, but forces standardization of interior node labels. > > should be interpreted as saying that the character case of interior > node labels MAY be standardized by the server or that it MUST be > standardized. The draft seems to be assuming a MUST, but I would > strongly suggest an interpretation of MAY. Making it a MUST would > severely limit the options of implementers without offering any > benefit in return. For example, it would outlaw implementations that > store a separate copy of the complete owner name with each RRset. Hummm, it is my impression that all implementations thus far have standardized but I believe you are correct in saying this is not required by the standard. I'll change that also. Thanks, Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.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 Apr 1 16:13: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 QAA15353 for ; Tue, 1 Apr 2003 16:13:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190Spg-000EHI-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 12:58:12 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 190Spd-000EH5-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 12:58:09 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13674; Tue, 1 Apr 2003 12:58:07 -0800 (PST) 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 h31Kw2S16512; Tue, 1 Apr 2003 22:58:04 +0200 (MEST) Date: Tue, 1 Apr 2003 22:57:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Proposed Resolution of LLMNR Issue 28 To: Bernard Aboba 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=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > To: > > "The source address of LLMNR queries and responses MUST be "on link". The > destination address of an LLMNR query MUST be a link-scope multicast > address or an "on link" unicast address; the destination address > of an LLMNR response MUST be an "on link" unicast address. > For IPv4, an "on link" address is defined as an address whose prefix > belongs to a subnet on the local link; for IPv6 [RFC2460] > an "on link" address is either a link-local address, defined in > [RFC2373], or an address whose prefix > belongs to a subnet on the local link. LLMNR senders or responders > receiving LLMNR packets from a source address that is not "on link" > SHOULD silently discard them. " [With interested participant hat on] The above is an improvement over the old text but doesn't cover the case when the responder can't tell whether an address is on link. Is that a separate issues that is being resolved separately? 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 Apr 1 16:15:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15402 for ; Tue, 1 Apr 2003 16:15:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190SwM-000Fcm-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 13:05:06 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 190SwF-000Fbe-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 13:05:00 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h31L654l002920; Wed, 2 Apr 2003 00:06:05 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h31L64AK002919; Wed, 2 Apr 2003 00:06:04 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Proposed Resolution to LLMNR Issue 21: PTR queries 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: <1049231163.2300.122.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2003 00:06:04 +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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On Tue, 2003-04-01 at 08:33, Bernard Aboba wrote: > Given the discussion at IETF 56 and the currently proposed resolutions to > Issue 28 and 29, I would like to propose that sending of LLMNR queries for > PTR RRs that represent "off link" addresses should be discouraged. The > proposed resolution is given below. Comments? I have no objection to "should be discouraged". However, it should be realized that on many operating systems this restriction may be very difficult to implement in practise. Offhand I can't think of an easy way for an application to check whether a particular address is "on link". MikaL -- > Issue 21: PTR queries > Submitter: Markku Savela > Submitter email address: msa@burp.tkv.asdf.org > Date first submitted: November 4, 2002 > Reference: <200211041445.QAA12218@burp.tkv.asdf.org> > Document: LLMNR-12 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > I assume that if you end up doing a address (fe80::1) to name query > for IPv6, you end up sending a query to IPv6 multicast address > generated from the hash of > > "1.0.0. ... 0.0.8.e.f.ip6.int" > > and because the hash is taken from the first label, this will be MD5 > from "1"? (basically only 16 different hashes are possible). > > IPv4 side you have for example "1.2.254.169.in-addr.arpa". > > Am I right assuming the "resolvers" on nodes have to deal also with > these for link local name resolution? > > [BA] Yes, it is expected that senders will send PTR > queries, and that receivers will respond to them. > However, it probably doesn't make sense to send a > PTR query for an address that isn't on the local > link. Here's the proposed resolution: > > Add the following text to Section 3: > > "[3] A sender SHOULD only send LLMNR queries for PTR RRs that > are known to be "on link" as defined in Section 2.5." > > [Erik Guttman and Erik Nordmark]: > > The problem is that in practice a host may not know the > prefixes in use on a particular link. So this restriction > can't work in practice. > > [Comment from Mark T. Hollinger ]: > > I think we are being too hasty to throw out this restriction. As I > metioned in my recent Namedroppers post, supporting your original proposal > for issue #3, I would like the fallback to LLMNR not to occur at all for > apparantly non-local prefixes. > > If there is a prefix on your link that you don't know about via your > routing table, then I don't think LLMNR needs to handle inverse queries > for that zone. The target user for LLMNR probably won't have multiple > unadvertised global prefixes in the first place. Anybody sophisticated > enough to set that up will already have the address of a DNS server > configured. > > Also, if you don't know about the other guy's prefix, he may not know > about yours either, in which case he'll get your multicast request but try > to send a unicast response via the router, which may decrement the TTL > when forwarding it back onto the same link. I'm not sure LLMNR will work > in this case (due to the TTL 255 check), but even if it works, I think a > configuration where hosts have to communicate (even only initially) via a > router is out-of-scope for LLMNR. Let traditional DNS handle that case; we > don't need LLMNR there. > > [BA] > Back of the envelope calculations seem to indicate to me that > bogus PTR queries can be a significant problem in some cases. Measurements > show that a significant fraction of DNS queries are not answered, and this > is particularly true with PTR queries. So we can have a substantial amount > of bogus LLMNR PTR query traffic. I am particularly worried about wireless > networks with lots of people like at IETF 56. 5 queries a second from > 3000 people would end up eating up a significant fraction of the total > bandwidth of an 802.11 network, particularly if there are lots of folks > who have to step down to lower rates (1,2,5 Mbps). So there is some reason > for concern. > > In the discussion at IETF 56, there was concern that it might not be > possible for a host to know all the networks it was connected to. The > question then arises as to whether it is ok not to send a PTR query for > addresses on networks the host doesn't know about. It was pointed out that > if the host doesn't have a route for that address, then it will route the > packet to the gateway, which might not have a route for it either. > > In view of the proposed resolution to Issue 28 and 29, it would > appear that it makes little sense to send queries for PTR RRs > that aren't "on link". > > > > -- > to 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 Tue Apr 1 18:05: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 SAA19715 for ; Tue, 1 Apr 2003 18:05:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190Uj4-0006TX-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 14:59:30 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 190Uj1-0006TF-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 14:59:27 -0800 Received: from [192.149.252.108] ([192.136.136.119]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA14660; Tue, 1 Apr 2003 17:59:25 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <200302140000.h1E001d6021308@drugs.dv.isc.org> References: <200302140000.h1E001d6021308@drugs.dv.isc.org> Date: Tue, 1 Apr 2003 17:55:37 -0500 To: Mark.Andrews@isc.org From: Edward Lewis Subject: Re: DNSSEC Opt-In Q: unsigned delegations with opt-in NXTs? Cc: David Blacka , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-31.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_SHORT_SPARSE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:00 +1100 2/14/03, Mark.Andrews@isc.org wrote: >> There was a pretty important clarification that came up during the >> last workshop that I forgot to put in my list of TODOs for the Opt-In >> draft, and it leads to a question for the working group. >> >> Q: Should an Opt-In tagged NXT record be able to have the same name as >> an unsigned delegation? > > Yes. Nothing in optin should preclude a standard insecure > delegation. > me too. >> * This may complicate implementations and analysis, although I think >> that this is unlikely. Let's burn that bridge when we get to it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 1 18:05: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 SAA19835 for ; Tue, 1 Apr 2003 18:05:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190UjF-0006aM-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 14:59:41 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 190UjA-0006Ww-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 14:59:36 -0800 Received: from [192.149.252.108] ([192.136.136.119]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA14663; Tue, 1 Apr 2003 17:59:25 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <20030331100546.GB30673@atoom.net> References: <20030331111954.01add0a0.olaf@ripe.net> <20030331100546.GB30673@atoom.net> Date: Tue, 1 Apr 2003 17:58:58 -0500 To: Miek Gieben From: Edward Lewis Subject: Re: DNSSEC protocol doc question: pre-conf keys. Cc: "Olaf M. Kolkman" , 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:05 +0200 3/31/03, Miek Gieben wrote: >In section 5 it says: > > An initial KEY RR can be used to authenticate a zone's apex KEY > RRset. To authenticate an apex KEY RRset using an initial key, the > resolver MUST: > > 1. Verify that the initial KEY RR appears in the apex KEY RRset, and > verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7) > set to one. > This seems to contradict RFC 3090, section 2.2. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 1 19:47: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 TAA23436 for ; Tue, 1 Apr 2003 19:47:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190WKY-000IXP-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 16:42:18 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190WKW-000IXD-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 16:42:16 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h320Opt30064; Tue, 1 Apr 2003 16:24:51 -0800 Date: Tue, 1 Apr 2003 16:24:51 -0800 (PST) From: Bernard Aboba To: Mika Liljeberg cc: namedroppers@ops.ietf.org Subject: Re: Proposed Resolution to LLMNR Issue 21: PTR queries In-Reply-To: <1049231163.2300.122.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-17.7 required=5.0 tests=BAYES_10,IN_REP_TO,OPT_HEADER,QUOTED_EMAIL_TEXT, USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I have no objection to "should be discouraged". However, it should be > realized that on many operating systems this restriction may be very > difficult to implement in practise. Offhand I can't think of an easy way > for an application to check whether a particular address is "on link". In practice, I think an on-link address is one which corresponds to link-scope address or an address corresponding to a prefix in the routing table mapped to an interface. -- to unsubscribe send a message to namedroppers-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 Apr 1 19:51: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 TAA23565 for ; Tue, 1 Apr 2003 19:51:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190WOA-000Isj-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 16:46:02 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190WO4-000IqQ-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 16:45:56 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h320RCv30160; Tue, 1 Apr 2003 16:27:12 -0800 Date: Tue, 1 Apr 2003 16:27:12 -0800 (PST) From: Bernard Aboba To: Erik Nordmark cc: namedroppers@ops.ietf.org Subject: Re: Proposed Resolution of LLMNR Issue 28 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [With interested participant hat on] > > The above is an improvement over the old text but doesn't cover the case when > the responder can't tell whether an address is on link. > Is that a separate issues that is being resolved separately? There are several related issues: 28, 29 and 21 that use the term "on-link". See the LLMNR issues list for all the proposed text and discussion: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html As noted in one of the comments on Issue 21: If you don't know about the other guy's prefix, he may not know about yours either, in which case he'll get your multicast request but try to send a unicast response via the router, which may decrement the TTL when forwarding it back onto the same link. I'm not sure LLMNR will work in this case (due to the TTL 255 check), but even if it works, I think a configuration where hosts have to communicate (even only initially) via a router is out-of-scope for LLMNR. Let traditional DNS handle that case; we don't need LLMNR there. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 2 00:05: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 AAA28935 for ; Wed, 2 Apr 2003 00:05:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190aGJ-000IpS-00 for namedroppers-data@psg.com; Tue, 01 Apr 2003 20:54:11 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 190aGD-000IpD-00 for namedroppers@ops.ietf.org; Tue, 01 Apr 2003 20:54:06 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h324tE4l005529; Wed, 2 Apr 2003 07:55:14 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h324tDmm005528; Wed, 2 Apr 2003 07:55:13 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Proposed Resolution to LLMNR Issue 21: PTR queries 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: <1049259311.2304.126.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Apr 2003 07:55:12 +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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-04-02 at 03:24, Bernard Aboba wrote: > > I have no objection to "should be discouraged". However, it should be > > realized that on many operating systems this restriction may be very > > difficult to implement in practise. Offhand I can't think of an easy way > > for an application to check whether a particular address is "on link". > > In practice, I think an on-link address is one which corresponds to > link-scope address or an address corresponding to a prefix in the routing > table mapped to an interface. My point is that the latter case is hard for an application to check, unless the kernel provides a syscall for it. Or is LLMNR supposed to read the routing information from the kernel and replicate the next hop selection code in user space? 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 Wed Apr 2 06:39: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 GAA04496 for ; Wed, 2 Apr 2003 06:39:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190gJe-000HsQ-00 for namedroppers-data@psg.com; Wed, 02 Apr 2003 03:22:02 -0800 Received: from [2001:6e0:206:1:250:daff:fe3d:1d6] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 3.36 #1) id 190gJb-000HsD-00 for namedroppers@ops.ietf.org; Wed, 02 Apr 2003 03:22:00 -0800 Received: from open.nlnetlabs.nl (localhost [IPv6:::1]) by open.nlnetlabs.nl (8.12.6p2/8.12.6) with ESMTP id h32BLv1c003801; Wed, 2 Apr 2003 13:21:58 +0200 (CEST) (envelope-from miekg@open.nlnetlabs.nl) Received: (from miekg@localhost) by open.nlnetlabs.nl (8.12.6p2/8.12.6/Submit) id h32BLqiV003800; Wed, 2 Apr 2003 13:21:52 +0200 (CEST) Date: Wed, 2 Apr 2003 13:21:51 +0200 From: Miek Gieben To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC protocol doc question: pre-conf keys. Message-ID: <20030402112151.GA3774@NLnetLabs.nl> Mail-Followup-To: Paul Vixie , namedroppers@ops.ietf.org References: <005a01c2f786$cd4625c0$b9370681@barnacle> <20030331143834.1DEED379E40@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030331143834.1DEED379E40@as.vix.com> User-Agent: Mutt/Linux X-Home: www.miek.nl X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 31 Mar, 2003, Paul Vixie wrote in "Re: DNSSEC protocol doc question: p ..."] > > I could see where a zone would want to have the secure entry point offline. > > The root zone could publish the key somewhere else, to reduce response > > sizes, for example. Otherwise, it seems a bit self-defeating. > > agreed. > > > Is there a reason for stating that a zone MUST have its secure entry point > > key in the served zone? > > not in my view. this appears to be an overspecification. so If we allow the change from MUST to SHOULD in section 2.1: ...A signed zone MUST have at least one zonekey... to ...A signed zone SHOULD have at least one zonekey... Then we allowing keyless zones? That is zones with out any zone KEY material in it, only signatures. If so, section 5. Authenticating DNS Responses, must also be changed. The first step "Verify that the initial KEY RR appears in the apex KEY RRset" is nonsense. (maybe other sections must also be changed) grtz Miek -- to unsubscribe send a message to namedroppers-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 Apr 3 00:35:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25200 for ; Thu, 3 Apr 2003 00:35:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190xBZ-000K3w-00 for namedroppers-data@psg.com; Wed, 02 Apr 2003 21:22:49 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190xBV-000K3j-00 for namedroppers@ops.ietf.org; Wed, 02 Apr 2003 21:22:46 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3355Dj27928; Wed, 2 Apr 2003 21:05:14 -0800 Date: Wed, 2 Apr 2003 21:05:13 -0800 (PST) From: Bernard Aboba To: Mika Liljeberg cc: namedroppers@ops.ietf.org Subject: Re: Proposed Resolution to LLMNR Issue 21: PTR queries In-Reply-To: <1049259311.2304.126.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > My point is that the latter case is hard for an application to check, > unless the kernel provides a syscall for it. Or is LLMNR supposed to > read the routing information from the kernel and replicate the next hop > selection code in user space? > > MikaL In practice, I don't think this needs to be required; the issue is about the networks directly reachable from interfaces receiving or sending queries, not about replicating next hop selection code. Perhaps looking at some examples may help make sense of this. Let us assume that Myhost is attached to two networks, A and B, and that it is talking to host [1] on net A and host [2] on net B. net B ---------- ---------- net A | | | | [2] [myhost] [1] Host [1] sends an LLMNR A/AAAA RR query for "myhost". Should myhost respond with A/AAAA RRs for addresses on net B? This would be bad if host [1] only has a LL address, since it would not be able to reach net B. So I think it makes sense for myhost to only respond with addresses on the interface from which the query came. So far so good. However, the question is "what if myhost does the wrong thing?" This is harder because host [1] may not have network B in its routing table. It therefore will not know how to reach network B. Since the point of LLMNR is to allow link-local name resolution, if host [1] doesn't know how to reach net B on the local link then RRs containing that address are not useful. Perhaps the right thing to do here is to say that "addresses that are reachable on the local link are preferred" by host [1]. That way, if myhost only returned an address on network B, host [1] can try to connect to that, possibly without success. But since there is no choice, what harm can it do? Another question is what happens if myhost attempts to connect to host [1], using a source address on net B. In this case host [1] may attempt to send a PTR RR query using LLMNR, for the address on net B. In this case, myhost might respond to the query with the name myhost which is valid on the interface. No harm is done. However, one might argue that host [1] should not send such a query, and that if received, myhost should not respond to it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 3 02:29: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 CAA08968 for ; Thu, 3 Apr 2003 02:29:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190yxy-000Hrj-00 for namedroppers-data@psg.com; Wed, 02 Apr 2003 23:16:54 -0800 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 190yxt-000Hpr-00 for namedroppers@ops.ietf.org; Wed, 02 Apr 2003 23:16:49 -0800 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h337He4l011258; Thu, 3 Apr 2003 10:17:40 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h337Hckb011257; Thu, 3 Apr 2003 10:17:38 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Proposed Resolution to LLMNR Issue 21: PTR queries From: Mika Liljeberg To: Bernard Aboba Cc: namedroppers@ops.ietf.org, mika.liljeberg@nokia.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1049354257.8307.70.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2003 10:17:38 +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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, On Thu, 2003-04-03 at 08:05, Bernard Aboba wrote: > > My point is that the latter case is hard for an application to check, > > unless the kernel provides a syscall for it. Or is LLMNR supposed to > > read the routing information from the kernel and replicate the next hop > > selection code in user space? > > > > MikaL > > In practice, I don't think this needs to be required; the issue is about > the networks directly reachable from interfaces receiving or sending > queries, not about replicating next hop selection code. It's true that the route search is constrained to a single interface but this does not essentially simplify the next hop selection algorithm. A full route search is still required to do on-link determination (unless you make some severe assumptions about the kind of routes that can lead to a specific physical interface). > Perhaps looking at some examples may help make sense of this. Ok. I think your example addresses a different case from the one discussed in issue 21 (PTR queries), but let's look at the example first. > Let us > assume that Myhost is attached to two networks, A and B, and that it is > talking to host [1] on net A and host [2] on net B. > > net B ---------- ---------- net A > | | | | > [2] [myhost] [1] > > Host [1] sends an LLMNR A/AAAA RR query for "myhost". Should myhost > respond with A/AAAA RRs for addresses on net B? This would be bad > if host [1] only has a LL address, since it would not be able to > reach net B. So I think it makes sense for myhost to only respond > with addresses on the interface from which the query came. Right. Issue 29 clarifies this. I agree with the proposed resolution. > So far so good. However, the question is "what if myhost does the wrong > thing?" I don't think the multihomed and broken [myhost] is a very common case but otherwise I agree with what you say: > This is harder because host [1] may not have network B in its > routing table. It therefore will not know how to reach network B. Since > the point of LLMNR is to allow link-local name resolution, if host [1] > doesn't know how to reach net B on the local link then RRs containing that > address are not useful. Agreed. To weed out the unusable address, the LLMNR resolver on [1] should somehow check whether there is a route to it. On many operating systems you can do this by attempting to connect a UDP socket to the destination address. If there is no route, the connect() syscall will fail. Note that having a route to a destination is not the same thing as knowing that the destination is on-link. > Perhaps the right thing to do here is to say that "addresses that are > reachable on the local link are preferred" by host [1]. The LLMNR resolver doesn't *know* which addresses are on-link, so it can't prefer them. > That way, if > myhost only returned an address on network B, host [1] can try to connect > to that, possibly without success. But since there is no choice, what harm > can it do? By host [1] do you mean the LLMNR responder of host [1] or the applicaiton running on host [1]? The LLMNR resolver can, on many operating systems, check the existence of a route (e.g. by doing a UDP connect() to the address). However, what it *cannot* do (as far as I can see), is check whether the destination address is on-link. In IPv6 the DNS resolver is already required to prefer reachable addresses as part of default address selection [RFC3484]. > Another question is what happens if myhost attempts to connect to host > [1], using a source address on net B. The only way this can happen is if a) [myhost] is badly broken, or b) [myhost] uses the Weak ES model [RFC1122] and the addresses in question are not link-locals. [zeroconf] forbids Weak ES model for link-locals. > In this case host [1] may attempt to > send a PTR RR query using LLMNR, for the address on net B. In this case, > myhost might respond to the query with the name myhost which is valid > on the interface. No harm is done. However, one might argue that > host [1] should not send such a query, and that if received, > myhost should not respond to it. The more realistic example, the one which I thought was being dicussed in the context of issue 21, is the following: Internet ---------- ---------- net A | | | | [2] [router] [1] Host [2] is not in the global DNS. It connects to host [1], which tries to make a PTR query to DNS with the address of [2]. [1] receives no response from DNS (whatever the reason) and falls back on LLMNR. LLMNR naturally fails as well. As you say, no harm is done, but it would nice to skip the unnecessary LLMNR query. I agree with the intent. I just don't see a good way to actually implement it. 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 Apr 3 02:46: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 CAA09422 for ; Thu, 3 Apr 2003 02:46:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190zKd-000N3L-00 for namedroppers-data@psg.com; Wed, 02 Apr 2003 23:40:19 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190zKY-000N37-00 for namedroppers@ops.ietf.org; Wed, 02 Apr 2003 23:40:14 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h337Mgw02991; Wed, 2 Apr 2003 23:22:42 -0800 Date: Wed, 2 Apr 2003 23:22:42 -0800 (PST) From: Bernard Aboba To: Mika Liljeberg cc: namedroppers@ops.ietf.org, Subject: Re: Proposed Resolution to LLMNR Issue 21: PTR queries In-Reply-To: <1049354257.8307.70.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Note that having a route to a destination is not the same thing as > knowing that the destination is on-link. > > > Perhaps the right thing to do here is to say that "addresses that are > > reachable on the local link are preferred" by host [1]. > > The LLMNR resolver doesn't *know* which addresses are on-link, so it > can't prefer them. Can it prefer responses that correspond to addresses it has routes for? > By host [1] do you mean the LLMNR responder of host [1] or the > application running on host [1]? I mean the LLMNR responder. > The LLMNR resolver can, on many operating systems, check the existence > of a route (e.g. by doing a UDP connect() to the address). However, what > it *cannot* do (as far as I can see), is check whether the destination > address is on-link. I think this may be good enough. If a response doesn't have a corresponding route then it can be ignored. > In IPv6 the DNS resolver is already required to prefer reachable > addresses as part of default address selection [RFC3484]. That seems like a reasonable guideline to adopt here, too. > The more realistic example, the one which I thought was being dicussed > in the context of issue 21, is the following: > > Internet ---------- ---------- net A > | | | | > [2] [router] [1] > > Host [2] is not in the global DNS. It connects to host [1], which tries > to make a PTR query to DNS with the address of [2]. [1] receives no > response from DNS (whatever the reason) and falls back on LLMNR. LLMNR > naturally fails as well. > > As you say, no harm is done, but it would nice to skip the unnecessary > LLMNR query. I agree with the intent. I just don't see a good way to > actually implement it. Yes. By your logic host [1] will have a route to [2] and so will send the LLMNR query, even though it cannot succeed. My concern is that this will happen very frequently and will needlessly consume bandwidth; on a wireless network like IETF's this could have a significant (negative) effect. Perhaps the right thing is not to allow PTR RR queries in LLMNR at all? Couldn't ICMP node information queries be a more appropriate substitute? -- to unsubscribe send a message to namedroppers-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 Apr 3 03:18: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 DAA09894 for ; Thu, 3 Apr 2003 03:18:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 190zZa-0000mA-00 for namedroppers-data@psg.com; Wed, 02 Apr 2003 23:55:46 -0800 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 190zZX-0000lv-00 for namedroppers@ops.ietf.org; Wed, 02 Apr 2003 23:55:43 -0800 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h337cDl03853 for ; Wed, 2 Apr 2003 23:38:14 -0800 Date: Wed, 2 Apr 2003 23:38:13 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Revision to resolution of Issue 28 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Based on Mika's comments, I'd like to propose a revision of the resolution to Issue 28, as described below: Issue 28: Addressing Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: January 17, 2003 Reference: Document: LLMNR-13 Comment type: T Priority: S Section: 2.5 Rationale/Explanation of issue: Change: "For IPv4 link-scope addressing, section 2.4 of "Dynamic Configuration of IPv4 Link-Local Addresses" [IPV4Link] lays out the rules with respect to source address selection, TTL settings, and acceptable source/destination address combinations. IPv6 is described in [RFC2460]; IPv6 link-scope addressing is described in [RFC2373]. LLMNR queries and responses obey the rules laid out in these documents. " To: "The source address of LLMNR queries and responses MUST be "on link". The destination address of an LLMNR query MUST be a link-scope multicast address or an "on link" unicast address; the destination address of an LLMNR response MUST be an "on link" unicast address. For IPv4, an "on link" address is defined as a link-local address or an address whose prefix belongs to a subnet on the local link; for IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or an address whose prefix belongs to a subnet on the local link. A sender SHOULD prefer RRs including reachable addresses where RRs involving both reachable and unreachable addresses are returned in response to a query." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 3 09:43: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 JAA21613 for ; Thu, 3 Apr 2003 09:43:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1915hM-000BDq-00 for namedroppers-data@psg.com; Thu, 03 Apr 2003 06:28:12 -0800 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 1915hJ-000BAE-00 for namedroppers@ops.ietf.org; Thu, 03 Apr 2003 06:28:09 -0800 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.12) id 1915hH-0005et-00 for namedroppers@ops.ietf.org; Thu, 03 Apr 2003 06:28:07 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Proposed Resolution to LLMNR Issue 21: PTR queries Thread-Index: AcL5tEmFcpIEg3y8R3CtvgvJHNKEQgAARnhg Subject: RE: Proposed Resolution to LLMNR Issue 21: PTR queries Date: Thu, 3 Apr 2003 11:58:17 +0300 From: To: , Cc: X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_01,NO_REAL_NAME,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-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 JAA21613 [ 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, > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Note that having a route to a destination is not the same thing as > > knowing that the destination is on-link. > > > > > Perhaps the right thing to do here is to say that > "addresses that are > > > reachable on the local link are preferred" by host [1]. > > > > The LLMNR resolver doesn't *know* which addresses are on-link, so it > > can't prefer them. > > Can it prefer responses that correspond to addresses it has > routes for? Yes, that would be my proposal. > > By host [1] do you mean the LLMNR responder of host [1] or the > > application running on host [1]? > > I mean the LLMNR responder. > > > The LLMNR resolver can, on many operating systems, check > the existence > > of a route (e.g. by doing a UDP connect() to the address). > However, what > > it *cannot* do (as far as I can see), is check whether the > destination > > address is on-link. > > I think this may be good enough. If a response doesn't have a > corresponding route then it can be ignored. Agreed. > > In IPv6 the DNS resolver is already required to prefer reachable > > addresses as part of default address selection [RFC3484]. > > That seems like a reasonable guideline to adopt here, too. > > > The more realistic example, the one which I thought was > being dicussed > > in the context of issue 21, is the following: > > > > Internet ---------- ---------- net A > > | | | | > > [2] [router] [1] > > > > Host [2] is not in the global DNS. It connects to host [1], > which tries > > to make a PTR query to DNS with the address of [2]. [1] receives no > > response from DNS (whatever the reason) and falls back on > LLMNR. LLMNR > > naturally fails as well. > > > > As you say, no harm is done, but it would nice to skip the > unnecessary > > LLMNR query. I agree with the intent. I just don't see a good way to > > actually implement it. > > Yes. By your logic host [1] will have a route to [2] and so > will send the > LLMNR query, even though it cannot succeed. My concern is > that this will > happen very frequently and will needlessly consume bandwidth; on a > wireless network like IETF's this could have a significant (negative) > effect. Well, in general one should be able to rely on one's local recursive DNS server to return an error when it times out on a query. Especially in IETF meetings. :) > Perhaps the right thing is not to allow PTR RR queries in > LLMNR at all? Unfortunately this would break a number of applications that do reverse queries. I'd rather err on the side that doesn't break applications even if there is a small performance impact: if in doubt, do the PTR query. I.e., the LLMNR resolver should do the query if the host has a route for the address in question. > Couldn't ICMP node information queries be a more appropriate > substitute? Err, I'm not exactly sure how node information queries relate to LLMNR. As far as I'm concerned, it is a completely separate name/address resolution protocol which may or may not be used by IPv6 nodes in the future. I don't think it's wise to create a dependency between the LLMNR specification and node information queries. (And it won't solve the issue of PTR queries for IPv4 addresses). 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 Apr 3 10:02: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 KAA22353 for ; Thu, 3 Apr 2003 10:02:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19167C-000HqL-00 for namedroppers-data@psg.com; Thu, 03 Apr 2003 06:54:54 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 191679-000Hq8-00 for namedroppers@ops.ietf.org; Thu, 03 Apr 2003 06:54:51 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21870; Thu, 3 Apr 2003 09:52:20 -0500 (EST) Message-Id: <200304031452.JAA21870@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: Handling of Unknown DNS Resource Record Types to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 03 Apr 2003 09:52:20 -0500 X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_01,TO_MALFORMED version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions Working Group to consider Handling of Unknown DNS Resource Record Types as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-4-16. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-05.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 Apr 3 11:43: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 LAA28903 for ; Thu, 3 Apr 2003 11:43:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1917Yx-0009cY-00 for namedroppers-data@psg.com; Thu, 03 Apr 2003 08:27:39 -0800 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 1917Yu-0009cJ-00 for namedroppers@ops.ietf.org; Thu, 03 Apr 2003 08:27:36 -0800 Received: from [192.149.252.108] ([192.136.136.117]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA29940; Thu, 3 Apr 2003 11:27:35 -0500 (EST) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: Date: Thu, 3 Apr 2003 11:27:32 -0500 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Jakob's bug 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There has been a debate on whether the bug that Jakob Schlyter identified some months ago is a problem with the code base he was testing or if the problem is rooted in the specifications. The bug is that referrals from test servers using the DS RR code (only some testing snapshot releases) confuses some recent versions of BIND software (BIND 9.1, 9.2.) Now, no one uses DS RR code in production, so this isn't an immediate problem and the bug isn't a threat to current stability of the production DNS, but the bug is an obstacle to rolling out the DS RR version of DNSSEC. The problem associated with the bug is that when being referred down the tree from a zone signed by DNSSEC to a zone that is not signed, the referral is required to prove the non-existence of the DS RR at the cut point. The BIND code bases referenced above see the NXT stating that there is no DS RR and assumes that the referral is a negative answer for the delegated name. On the surface that sounds like a code bug, but in researching the specifications, it was thought that the combination of a negative answer (the DS RR) and a referral (the NS RR's) hadn't been described before. I.e., an under specification existed. I was just reading RFC 2308 (NCACHE) and looked at section 6, "Negative answers from the cache." (Note to my boss: I needed to look at this for the lameness requirements. Honest! ;)) In this section: "As with all answers coming from the cache, negative answers SHOULD have an implicit referral built into the answer." This points to a specification-based problem. In RFC 2308, cache-sourced negative answers are supposed to look like a referral. In the DS RR proposal, a referral will appear as a negative answer in some instances. Perhaps one adjustment needed to the DS RR proposal is to acknowledge what a referral from a signed zone to an unsigned zone looks like when it comes from a third-party cache. Whether or not this issue is specification based is a dependency of the proposal to change the type codes and mnemonics for the DNSSEC types that exist in RFC 2535 (KEY, NXT, and SIG). If the problem is truly based in the specifications and we determine that the specifications are insufficient in detail, then it's best to wipe the table clean of the old code paths. That's why this matters. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer I've had it with world domination. The maintenance fees are too high. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 4 06:51: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 GAA16496 for ; Fri, 4 Apr 2003 06:51:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191PVG-000AYY-00 for namedroppers-data@psg.com; Fri, 04 Apr 2003 03:37:02 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 191PVD-000AYL-00 for namedroppers@ops.ietf.org; Fri, 04 Apr 2003 03:36:59 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14638; Fri, 4 Apr 2003 06:34:27 -0500 (EST) Message-Id: <200304041134.GAA14638@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-15.txt Date: Fri, 04 Apr 2003 06:34:27 -0500 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-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-15.txt Pages : 20 Date : 2003-4-3 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a 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-15.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-15.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-15.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-4064933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-4064933.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 Apr 4 20:38: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 UAA15882 for ; Fri, 4 Apr 2003 20:38:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191cRe-00044P-00 for namedroppers-data@psg.com; Fri, 04 Apr 2003 17:26:10 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 191cRb-000449-00 for namedroppers@ops.ietf.org; Fri, 04 Apr 2003 17:26:07 -0800 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h351Q3Aj006228; Fri, 4 Apr 2003 17:26:04 -0800 (PST) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 17:26:03 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Steven M. Bellovin'" , Rob Austein Cc: namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Fri, 4 Apr 2003 17:25:55 -0800 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk When you have a protocol that has gone undeployed for ten years it is probably time to stop thinking about long term optimizations and start thinking about steps that can be taken to minimize the cost of deployment and maximize the buy in from the operators concerned. If DNSSEC does not have an answer for deployment in .COM it will never be deployed in the form defined by the IETF, it is as simple as that. Phill > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Thursday, March 27, 2003 1:52 PM > To: Rob Austein > Cc: namedroppers@ops.ietf.org > Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN > > > In message <20030327095743.2E17918DF@thrintun.hactrn.net>, > Rob Austein writes: > >I oppose opt-in, but would be willing to stand aside if the > WG were to > >approach consensus in favor of opt-in, because I strongly agree that > >we need to make a decision and put this behind us. > > > >I've posted enough on this subject in the past that the reasons why I > >oppose opt-in should be clear by this point (for an example, see my > >message to this list on 4 February 2003). The summary > version is that > >opt-in trades some near-term pain (cost) for operators of large > >servers against some ongoing pain (cost and complexity) for > developers > >and resolver operators, and while I have some sympathy for the large > >server operators, I don't think that this is a good tradeoff for the > >Internet as a whole. -- to unsubscribe send a message to namedroppers-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 Apr 4 22:29: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 WAA17279 for ; Fri, 4 Apr 2003 22:29:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191eIh-000HOE-00 for namedroppers-data@psg.com; Fri, 04 Apr 2003 19:25:03 -0800 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 191eId-000HNa-00 for namedroppers@ops.ietf.org; Fri, 04 Apr 2003 19:25:00 -0800 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HCU00CNKPJE5U@eListX.com> for namedroppers@ops.ietf.org; Fri, 04 Apr 2003 22:26:04 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h353O5j4061297; Fri, 04 Apr 2003 22:24:06 -0500 (EST envelope-from ogud@ogud.com) Date: Fri, 04 Apr 2003 16:57:56 -0500 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSSEC protocol doc question: pre-conf keys. In-reply-to: <20030402112151.GA3774@NLnetLabs.nl> X-Sender: post@localhost To: Miek Gieben , Paul Vixie Cc: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030404165227.023a2970@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <20030331143834.1DEED379E40@as.vix.com> <005a01c2f786$cd4625c0$b9370681@barnacle> <20030331143834.1DEED379E40@as.vix.com> X-Spam-Status: No, hits=-31.0 required=5.0 tests=BAYES_01,DATE_IN_PAST_03_06,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 06:21 2003-04-02, Miek Gieben wrote: >[On 31 Mar, 2003, Paul Vixie wrote in "Re: DNSSEC protocol doc question: p >..."] > > > I could see where a zone would want to have the secure entry point > offline. > > > The root zone could publish the key somewhere else, to reduce response > > > sizes, for example. Otherwise, it seems a bit self-defeating. > > > > agreed. > > > > > Is there a reason for stating that a zone MUST have its secure entry > point > > > key in the served zone? > > > > not in my view. this appears to be an overspecification. > >so If we allow the change from MUST to SHOULD in section 2.1: > ...A signed zone MUST have at least one zonekey... >to > ...A signed zone SHOULD have at least one zonekey... > >Then we allowing keyless zones? That is zones with out any zone KEY material >in it, only signatures. > >If so, section 5. Authenticating DNS Responses, must also be changed. >The first step "Verify that the initial KEY RR appears in the apex KEY >RRset" is nonsense. (maybe other sections must also be changed) IMHO I think the MUST is the right way to go. If the zone signing key is not available the zone can only be verified by resolvers that have that key configured. This will not scale outside a small test environment. 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 Sat Apr 5 09:27: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 JAA06747 for ; Sat, 5 Apr 2003 09:27:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191oJp-0008BF-00 for namedroppers-data@psg.com; Sat, 05 Apr 2003 06:06:53 -0800 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 191oJm-0008B3-00 for namedroppers@ops.ietf.org; Sat, 05 Apr 2003 06:06:51 -0800 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h35E53Aj005907; Sat, 5 Apr 2003 06:05:03 -0800 (PST) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Apr 2003 06:05:03 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Edward Lewis'" , namedroppers@ops.ietf.org Subject: RE: opt-in and consensus Date: Sat, 5 Apr 2003 06:05:03 -0800 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The opt-in issue has to some extent polarized the working group into > folks that are "for" opt-in and folks that are "against" opt-in. I don't see evidence for that assertion, quite the reverse. The clear majority of posts were in favor of opt-in. There were only two posts I saw outright opposed and three that said they did not think opt-in was a good idea but would stand aside to let us get on to the real problems of deployment. One comment agreed with someone else without expressing a pro/anti view. I don't think that anyone expects there to be unanimous approval here, although I will not be surprised if some try to insist on that as the criteria. There once was a principle at the IETF about complexity, complexity is often impossible to eliminate from a protocol but you can choose where you put it. The original concept of 'end-to-end' was that you avoided concentrations of complexity and processing in favor of decentralization. I find it interesting that we now have the reverse of that argument, somehow Moore's law will provide and we can make do with a bad design that creates a concentration of processing costs at a few nodes rather than risk a minor variation in end-point processing. Somewhere out there there is a world of eight billion people. Someday all those people are going to be using the Internet. It is unlikely that protocols whose design depends on salvation by Moore's law will survive to that day. 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 Sat Apr 5 10:37: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 KAA09244 for ; Sat, 5 Apr 2003 10:37:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191pcz-000H5c-00 for namedroppers-data@psg.com; Sat, 05 Apr 2003 07:30:45 -0800 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 191pcv-000H58-00 for namedroppers@ops.ietf.org; Sat, 05 Apr 2003 07:30:42 -0800 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h35FOiO8037412; Sat, 5 Apr 2003 10:24:44 -0500 (EST) Message-Id: <200304051524.h35FOiO8037412@nic-naa.net> To: "Hallam-Baker, Phillip" cc: "'Edward Lewis'" , namedroppers@ops.ietf.org, brunner@nic-naa.net Subject: Re: opt-in and consensus In-Reply-To: Your message of "Sat, 05 Apr 2003 06:05:03 PST." Date: Sat, 05 Apr 2003 10:24:44 -0500 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-8.6 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ("against" opt-in) ++ of course, another form of expression is that i think there is some possible mechanisms that arise from policies that incorporate "informed prior consent" into the requirements statement, which are not available if "ipc" is not a requirement. this may come as a surprise to phill, though not to ed. the provreg wg and the iesg, in my own personal view, are divided by this very question, and a non-trivial potential motivation for both camps there is the rasion d'etre for this irtf tf -- spam (via whois:43 server data mining). can the properties of data collectors be usefully characterized? there exists at least one such attempt. can the provisioning of end-point identifiers and other information which tends to identify individuals, as well as other categories for which some policies exist, be mediated by mechanisms which evaluate grammers which characterize data collection practices? there exists several implementations for at lesat one such grammer. can collector evaluation mechanisms mitigate any part of this tf's problem space? this is unknown. it is worth keeping in mind that mechanisms which rely upon recipient or relay properties, e.g., "consent", "content", "dnsbl", ... do not exhaust the mechanism-space. i mentioned that another approach exists, but that it seems to me to be inaccessible to the ietf, and not from ipr reasons. \begin{note-to-chair-hat-on} it might be useful to split this shouting match into working groups. the din is attrocious, the posturing rediculous, and the disincentive to work tremendous. \end{note-to-chair-hat-on} cheers, eric -- to unsubscribe send a message to namedroppers-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 Apr 5 14:27: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 OAA12211 for ; Sat, 5 Apr 2003 14:27:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191t7L-000KQk-00 for namedroppers-data@psg.com; Sat, 05 Apr 2003 11:14:19 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 191t7F-000KIS-00 for namedroppers@ops.ietf.org; Sat, 05 Apr 2003 11:14:13 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 86BDB18EC for ; Sat, 5 Apr 2003 14:13:40 -0500 (EST) Date: Sat, 05 Apr 2003 14:13:40 -0500 From: Rob Austein To: namedroppers@ops.ietf.org Subject: LLMNR Issue 3 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: <20030405191340.86BDB18EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01,USER_AGENT version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Please forgive me if I'm confused on the LLMNR issue resolution protocol, I didn't see an obvious thread on which to follow up on the proposed resolution to issue #3. I have some reservations about the solution proposed for LLMNR issue #3, and while I won't stand in the way, I thought I should explain my reservations, since I think they expose a split between two fundamentally different usage models. The scenario we discussed at the IETF 56 DNSEXT meeting (two laptops on an ad hoc network, each laptop knows its own FQDN) is the result of how I think about naming machines. My laptop's name is the same no matter where my laptop goes, and to me the whole FQDN is the laptop's name, not just the leftmost label, because the FQDN is unambiguous. Because of this, the proposed resolution to issue #3 seems bizzare to me: here I have a machine that has a perfectly good unambiguous name, but the protocol won't let me use it, and instead forces me to cons up a potentially ambiguous name. I realize that there are operating systems and networks that operate on the model that only the leftmost label is the host's business, and everything else is imposed by the local environment, but I don't operate that way (and yes, my laptop's DHCP client is configured to override most of the DNS-related information that might come from the local environment). So it seems to me that this proposed resolution is somewhat biased in favor of a particular model for ad-hoc networks at the expense of other (perhaps better) models, and increases the likelyhood of name colisions by forcing users who can supply unambiguous names to use potentially ambiguous names instead. -- to unsubscribe send a message to namedroppers-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 Apr 5 16:02: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 QAA14620 for ; Sat, 5 Apr 2003 16:02:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191ued-000945-00 for namedroppers-data@psg.com; Sat, 05 Apr 2003 12:52:47 -0800 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 191ue7-00092y-00 for namedroppers@ops.ietf.org; Sat, 05 Apr 2003 12:52:15 -0800 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 1A3B31B222F; Sat, 5 Apr 2003 13:57:22 -0600 (CST) Date: Sat, 5 Apr 2003 14:52:14 -0600 Subject: Re: LLMNR Issue 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Rob Austein From: Ted Lemon In-Reply-To: <20030405191340.86BDB18EC@thrintun.hactrn.net> Message-Id: <7ABCA64A-67A8-11D7-89A6-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-15.3 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The scenario we discussed at the IETF 56 DNSEXT meeting (two laptops > on an ad hoc network, each laptop knows its own FQDN) is the result of > how I think about naming machines. My laptop's name is the same no > matter where my laptop goes, and to me the whole FQDN is the laptop's > name, not just the leftmost label, because the FQDN is unambiguous. > Because of this, the proposed resolution to issue #3 seems bizzare to > me: here I have a machine that has a perfectly good unambiguous name, > but the protocol won't let me use it, and instead forces me to cons up > a potentially ambiguous name. You're right. It is bizarre. It's there for a good reason, which is that Joe Average doesn't think his laptop is called "joeaverage.myispsdomain.com". He thinks it's called "joeaverage". So if you want Joe Average to be able to exchange data with Jane Average (assuming that Jane Average also doesn't think of her laptop as having an FQDN) when they meet in a coffee shop to talk about their homework, and Joe and Jane average do not use the same ISP, the only name that either one of them has a chance of coming up with is "joeaverage" or "janeaverage." I think this falls apart if you think about it a bit, though - chances are that Joe and Jane don't even think of their computers as "joeaverage" and "janeaverage" - they think of them as "my computer". So the only chance Joe and Jane really have of exchanging data is if they see a menu with a name that looks right, like "Joe's Computer". They're just not going to be able to come up with a name for each other's computer otherwise. So you might as well use an fqdn. This brings us to the next problem, which is that neither Joe nor Jane are likely to have a reasonable basis for assigning an FQDN to their computer right now. For a computer to have an FQDN, it has to have a name registered in the DNS. Any other definition of "having an FQDN" is meaningless (correct me if I am wrong). Neither Joe nor Jane have any idea that their computers ought to have FQDNs, and neither Joe nor Jane would have any idea how to get their computers' name registered in the DNS even if they realized that it would be useful to do so. So for Joe and Jane, it's necessary that LLMNR allow their computers to have names without requiring them to go through the process of registering FQDNs for their computers. This gets even more complicated because Joe and Jane's laptops, being portable, may very well switch FQDNs as they move from site to site. It's quite likely that both laptops do DHCP from time to time, either when they're connecting at home or at work. It's also likely that their respective DHCP servers sometimes assign FQDNs to their laptops, unbeknownst to them. It is extremely unlikely that Joe or Jane will be aware of this, and so if their laptops use those names--and only those names--in LLMNR, Joe and Jane won't be able to identify their laptops. So I would say that it's fine for your computer to claim it's sra-vroom.hactrn.net using LLMNR, as long as Joe and Jane's computers, which haven't been explicitly configured with FQDNs, but may have been dynamically configured with FQDNs, don't do so. And if we have to pick one or the other behavior as the default, the behavior should favor Joe and Jane, because unlike you, they are not prepared to defend themselves from misconfiguration. I should point out that neither Joe nor Jane need be dunces in this scenario - they just aren't networking geeks, and don't want to be forced to be. Also, I am making no assertions about whether or not Joe and Jane are a couple; this scenario works with all configurations of Joe and Jane, and also with Joe and Dave, and with Jane and Rebecca, and so on. :') -- to unsubscribe send a message to namedroppers-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 Apr 5 16:14: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 QAA14787 for ; Sat, 5 Apr 2003 16:14:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 191utb-000Br2-00 for namedroppers-data@psg.com; Sat, 05 Apr 2003 13:08:15 -0800 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 191utX-000Bpw-00 for namedroppers@ops.ietf.org; Sat, 05 Apr 2003 13:08:12 -0800 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 57EB518EC for ; Sat, 5 Apr 2003 16:07:34 -0500 (EST) Date: Sat, 05 Apr 2003 16:07:34 -0500 From: Rob Austein To: namedroppers Subject: Re: secure entry point In-Reply-To: <20030331142044.GC3689@atoom.net> References: <20030331133521.GA3042@atoom.net> <20030331142044.GC3689@atoom.net> 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: <20030405210734.57EB518EC@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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After reviewing the whole thread, I think the following is the key issue: At Mon, 31 Mar 2003 16:20:44 +0200, Miek Gieben wrote: > > [On 31 Mar, @15:51, Donald wrote in "Re: secure entry point ..."] > > If you trust a public key to sign DNS data and can verify the signature > > over that data, it doesn't make any difference where you got the data > > from. There is no reason to worry about the IP address of the > > nameserver. > > But this opens up a huge dos attack (this has nothing to do with "dnssec does > help against doc attacks"). You will only have to spoof the IP address of a > secure entry point and you're done. The resolver will notice that the signatures > do not match and will declare the thing BAD. > > This can easily be prevented by also configuring secure entry point ip adresses. > (you already have to configure the secure entry point keys anyway, so this adds > little more work) Either I'm missing something, or this DOS attack is present in any case, because nogoodniks can intercept your queries and send you spoofed responses using the real name server's IP address. DNSSEC can't prevent this. All DNSSEC can do is give you somewhat better criteria by which to determine whether something bad has happened. -- to unsubscribe send a message to namedroppers-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 Apr 6 08:59: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 IAA26962 for ; Sun, 6 Apr 2003 08:59:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1929Y7-0000S0-00 for namedroppers-data@psg.com; Sun, 06 Apr 2003 12:47:03 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 1929Xl-0000Kl-00 for namedroppers@ops.ietf.org; Sun, 06 Apr 2003 05:46:41 -0700 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h36CkcTm008197 for ; Sun, 6 Apr 2003 05:46:38 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Apr 2003 05:46:38 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: SPAM harvesting: RE: opt-in and consensus Date: Sun, 6 Apr 2003 05:46:37 -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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > this may come as a surprise to phill, though not to ed. the > provreg wg and > the iesg, in my own personal view, are divided by this very > question, and > a non-trivial potential motivation for both camps there is > the rasion d'etre > for this irtf tf -- spam (via whois:43 server data mining). It will probably come as a surprise to most to find that WHOIS turns out to not be a major target of address harvesting attacks. At lest in empirical studies rather than anecdotes. The FTC did research in this area. 100% of the emails used in chat rooms, 85% used on mailing lists, usenet or the Web were harvested, none of the addresses in whois were harvested. http://www.ftc.gov/bcp/conline/edcams/spam/pubs/harvestchart.pdf I know, I did not expect that result either. Of course an effective way to solve the problem would be to look at the specific purposes for which whois email listing was required (domain reg challenges, etc) and to require that the registrars or the registry run a forwarding mail server that only forwardsw mail authenticated as being sent for that purpose. 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 Sun Apr 6 10: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 KAA29017 for ; Sun, 6 Apr 2003 10:15:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192Aqz-000CHf-00 for namedroppers-data@psg.com; Sun, 06 Apr 2003 14:10:37 +0000 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 192AqV-000CH8-00 for namedroppers@ops.ietf.org; Sun, 06 Apr 2003 07:10:07 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h36E5EO8041127; Sun, 6 Apr 2003 10:05:14 -0400 (EDT) Message-Id: <200304061405.h36E5EO8041127@nic-naa.net> To: "Hallam-Baker, Phillip" cc: namedroppers@ops.ietf.org, brunner@nic-naa.net Subject: Re: SPAM harvesting: RE: opt-in and consensus In-Reply-To: Your message of "Sun, 06 Apr 2003 05:46:37 PDT." Date: Sun, 06 Apr 2003 10:05:14 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-7.8 required=5.0 tests=BAYES_10,IN_REP_TO,OPT_IN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk the result (spam arising from whois:43 mining non-dominant, from http:80, from smtp:25, from irc:6667 mining, dominant), is ... er ... not registry provisioning protocol- and/or ICANN-deck-chair-migration-centric. having worked for an ad network line-of-business (engage, 2000) on the issues of pii acquisition, policies and mechanisms relevant to same, the FTC result cited is consistent with my understanding of the problem. jumping to niche-specific cure (not a discussion of phill's pre-coffee, mine at least, purpose-specific, authenticated-relay, authenticated-envelope fix) is not an exhaustive examination of whether it is useful to the problem at hand for collector evaluation mechanisms to augment existing mechanisms. eric -- to unsubscribe send a message to namedroppers-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 Apr 6 11:46: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 LAA00253 for ; Sun, 6 Apr 2003 11:46:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192CHb-000P0U-00 for namedroppers-data@psg.com; Sun, 06 Apr 2003 15:42:11 +0000 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 192CHE-000Oyp-00; Sun, 06 Apr 2003 08:41:48 -0700 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h36FatO8041434; Sun, 6 Apr 2003 11:36:55 -0400 (EDT) Message-Id: <200304061536.h36FatO8041434@nic-naa.net> To: randy@psg.com cc: namedroppers@ops.ietf.org, brunner@nic-naa.net Subject: off-topic, my confusion Date: Sun, 06 Apr 2003 11:36:55 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i just realized that the opt-* traffic on the asrg list, in which there are numerous posts by a contributor employed by verisign, and the opt-* traffic on this list (namedroppers), in which there are also numerous posts by the same contributor, confused me. my notes of yesterday and today are off-topic. appologies all, and especially to randy, as our disagreement over mechanism, and perhaps policy, in another context, is implicit in the note i wrote (to asrg in my mind), and is a no-op in this wg. eric -- to unsubscribe send a message to namedroppers-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 Apr 6 12:23: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 MAA00788 for ; Sun, 6 Apr 2003 12:23:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192Cqv-0004JU-00 for namedroppers-data@psg.com; Sun, 06 Apr 2003 16:18:41 +0000 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 192CqZ-0004JD-00 for namedroppers@ops.ietf.org; Sun, 06 Apr 2003 09:18:19 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h36GIBY25258; Sun, 6 Apr 2003 09:18:11 -0700 (PDT) From: Bill Manning Message-Id: <200304061618.h36GIBY25258@boreas.isi.edu> Subject: Re: LLMNR Issue 3 In-Reply-To: <7ABCA64A-67A8-11D7-89A6-00039367340A@nominum.com> from Ted Lemon at "Apr 5, 3 02:52:14 pm" To: mellon@nominum.com (Ted Lemon) Date: Sun, 6 Apr 2003 09:18:11 -0700 (PDT) Cc: namedroppers@ops.ietf.org, sra+namedroppers@hactrn.net X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,IN_REP_TO,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % > The scenario we discussed at the IETF 56 DNSEXT meeting (two laptops % > on an ad hoc network, each laptop knows its own FQDN) is the result of % > how I think about naming machines. My laptop's name is the same no % > matter where my laptop goes, and to me the whole FQDN is the laptop's % > name, not just the leftmost label, because the FQDN is unambiguous. % > Because of this, the proposed resolution to issue #3 seems bizzare to % > me: here I have a machine that has a perfectly good unambiguous name, % > but the protocol won't let me use it, and instead forces me to cons up % > a potentially ambiguous name. amen. thats why the TBDS project chose to key off the FQDN for its version of mDNS. % "joeaverage" and "janeaverage" - they think of them as "my computer". % So the only chance Joe and Jane really have of exchanging data is if % they see a menu with a name that looks right, like "Joe's Computer". % They're just not going to be able to come up with a name for each % other's computer otherwise. So you might as well use an fqdn. yup. % % This brings us to the next problem, which is that neither Joe nor Jane % are likely to have a reasonable basis for assigning an FQDN to their % computer right now. For a computer to have an FQDN, it has to have a % name registered in the DNS. Any other definition of "having an FQDN" % is meaningless (correct me if I am wrong). Neither Joe nor Jane have % any idea that their computers ought to have FQDNs, and neither Joe nor % Jane would have any idea how to get their computers' name registered in % the DNS even if they realized that it would be useful to do so. So % for Joe and Jane, it's necessary that LLMNR allow their computers to % have names without requiring them to go through the process of % registering FQDNs for their computers. % % This gets even more complicated because Joe and Jane's laptops, being % portable, may very well switch FQDNs as they move from site to site. % It's quite likely that both laptops do DHCP from time to time, either % when they're connecting at home or at work. It's also likely that % their respective DHCP servers sometimes assign FQDNs to their laptops, % unbeknownst to them. It is extremely unlikely that Joe or Jane will % be aware of this, and so if their laptops use those names--and only % those names--in LLMNR, Joe and Jane won't be able to identify their % laptops. perhaps. but there is the disticntion of where your computer is vs who named it. Joe and Jane likely have Internet access. They buy that access from someone. perhaps joe@aol.com and jane@bbss.net it would seem to not bee too much of a reach to presume that bbss and aol will tag the connecting machines of their customerss with a name - perhaps joe-pc.aol.com and jane-pda.bbss.net and assign credentials to them.... volia, FQDNs. Now when joe and jane meet at the StarBucks in Memphis, they get new IP addresses but their FQDNs stay the same as their creds... case closed. % % So I would say that it's fine for your computer to claim it's % sra-vroom.hactrn.net using LLMNR, as long as Joe and Jane's computers, % which haven't been explicitly configured with FQDNs, but may have been % dynamically configured with FQDNs, don't do so. And if we have to % pick one or the other behavior as the default, the behavior should % favor Joe and Jane, because unlike you, they are not prepared to defend % themselves from misconfiguration. % % I should point out that neither Joe nor Jane need be dunces in this % scenario - they just aren't networking geeks, and don't want to be % forced to be. Also, I am making no assertions about whether or not % Joe and Jane are a couple; this scenario works with all configurations % of Joe and Jane, and also with Joe and Dave, and with Jane and Rebecca, % and so on. :') % % % -- % to unsubscribe send a message to namedroppers-request@ops.ietf.org with % the word 'unsubscribe' in a single line as the message text body. % archive: % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-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 Apr 6 13:51: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 NAA01685 for ; Sun, 6 Apr 2003 13:51:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192E9h-000GgR-00 for namedroppers-data@psg.com; Sun, 06 Apr 2003 17:42:09 +0000 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 192E9B-000GWW-00 for namedroppers@ops.ietf.org; Sun, 06 Apr 2003 10:41:37 -0700 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id D12511B222F; Sun, 6 Apr 2003 11:46:32 -0500 (CDT) Date: Sun, 6 Apr 2003 12:41:34 -0500 Subject: Re: LLMNR Issue 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: namedroppers@ops.ietf.org To: Bill Manning From: Ted Lemon In-Reply-To: <200304061618.h36GIBY25258@boreas.isi.edu> Message-Id: <024C0CEA-6857-11D7-89A6-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > perhaps. but there is the disticntion of where your computer is > vs who named it. Joe and Jane likely have Internet access. > They buy that access from someone. perhaps joe@aol.com > and jane@bbss.net it would seem to not bee too much of a reach to > presume that bbss and aol will tag the connecting machines of their > customerss with a name - perhaps joe-pc.aol.com and jane-pda.bbss.net > and assign credentials to them.... volia, FQDNs. Um, Joe and Jane don't know from FQDNs. And they may use their laptops in more places than just home and Starbucks. So it's entirely possible that their laptops have more than one FQDN that could be thought of as "the laptop's FQDN." And then they will see inconsistent behavior when they visit Starbucks. Sometimes joe-pc.aol.com will be Joe's laptop's FQDN, and sometimes it'll be joe-pc.megacorp-example.com. Joe and Jane aren't going to be able to predict that. Joe and Jane will learn about FQDNs only when it's to their advantage to do so. I'm not saying that can't happen. But right now it's not particularly to their advantage, so chances are they don't know about them. Joe and Jane think of FQDNs as things that start with www, smtp or pop, that only servers have. I'm all in favor of changing this - in fact, I'm working to change it - but I don't think that the design of a protocol should be predicated on the success of my efforts. -- to unsubscribe send a message to namedroppers-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 Apr 6 13:53: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 NAA01752 for ; Sun, 6 Apr 2003 13:53:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192EDz-000HGR-00 for namedroppers-data@psg.com; Sun, 06 Apr 2003 17:46:35 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 192ED7-000HBQ-00 for namedroppers@ops.ietf.org; Sun, 06 Apr 2003 10:45:41 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 2FAD8379F98 for ; Sun, 6 Apr 2003 17:45:28 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 3 In-Reply-To: Message from Bill Manning of "Sun, 06 Apr 2003 09:18:11 MST." <200304061618.h36GIBY25258@boreas.isi.edu> X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Sun, 06 Apr 2003 17:45:28 +0000 Message-Id: <20030406174528.2FAD8379F98@as.vix.com> X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i've just got to beg to differ. if joe and jane meet in a coffee shop and, via some combination of an apple-style "chooser" and bluetooth or 802.11 or irda or null-ether cable see each other at all, then it's probably adequate for them to see rfc1918 ipv4 addresses or link-local ipv6 addresses (or both). names are a nicety but one which the palm-beamers seem to do perfectly well without, most of the time (since most palm owners don't ever name their pda's.) the more interesting question is: what if it's 802.11 and a large network, such as an internet cafe. in that case, one would immediately say that ip addresses weren't useful since there would be so many of them. (when there's only one, it's safe most of the time to assume you know who it is; when there's a lot more than one, you just don't know who's who.) but if we take this one step further, unqualified names don't help. on a large network like an 802.11 internet cafe, there's going to be more than one jane and probably more than one joe. the cases where the connectivity is limited to small numbers of other-ends are such that ip addresses (or names like "other end of null-ether cable") are good enough. the cases where the connectivity is not so limited are such that only fully qualified and "universal" names are good enough. and in either case, higher level security like certificates ought to be used, since neither ip addresses nor universal fully qualified domain names are appropriate for either authentication or authorization. -- to unsubscribe send a message to namedroppers-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 Apr 7 08:49: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 IAA18707 for ; Mon, 7 Apr 2003 08:49:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192Vut-000I1S-00 for namedroppers-data@psg.com; Mon, 07 Apr 2003 12:40:03 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 192Vum-000Hzt-00 for namedroppers@ops.ietf.org; Mon, 07 Apr 2003 05:39:57 -0700 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h37CM4U17105 for ; Mon, 7 Apr 2003 05:22:04 -0700 Date: Mon, 7 Apr 2003 05:22:04 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposal for LLMNR Issue 31: Miscellaneous NITs 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk My recommendation is that the changes proposed below be accepted. Any objections? Issue 31: Miscellaneous NITs Submitter: Randy Presuhn Submitter email address: randy_presuhn@mindspring.com Date first submitted: April 4, 2003 Reference: Document: LLMNR-15 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: A few minor editorial things jumped out at me when I looked at - In some places "." at the end of a sentence is followed by a single space. In others, there are two spaces. It should be two spaces consistently. - On page 11 in section 4, the second and third bullets go past column 72. - sections 7 and 8 don't consistently follow the format used in draft-rfc-editor-rfc2223bis-04.txt, especially regarding the order of initials and names in author lists. - There is a superfluous '"' at the end of the copyright statement near the end of the document. - DNS isn't expanded on first use. (I wouldn't have noticed, had the RFC editor not made us expand "SNMP" and "MIB" on first use in some recent RFCs. :-) - DHCPv4 and DHCPv6 should be expanded on first use. - Page 3: "adhoc" -> "ad hoc" - Page 4: "possible reevaluate" -> "possible to reevaluate" - Page 4: "in particular is" -> "in particular, is" - Page 4: "Requirements" isn't quite the right title for section 1.1 I'd merge it into the end of section 1.2. - In general, there are a lot of DNS-isms (RR, RDATA, RCODE, TC, AAAA, A, etc.) It might be helpful to point to the appropriate document for these in some kind of catch-all entry in 1.2, rather than trying to address each one individually on first use. - Section 2.1: "Type" -> "type" - Section 2.1: "exist (that" -> "exist. (That" and "section)." -> "section.)" - Section 3.2.1, last paragraph: is "recommended" supposed to be "RECOMMENDED"? - Section 4, first paragraph: "would, ordinarily." -> "would." - Section 4, second paragraph: is the mix of "MAY" and "may" intended? - Section 4.1: "wish" -> "need" (less anthropomorphic) - Section 5: "peer to peer" -> "peer-to-peer" - If the "TBD" items are to be filled in the RFC editor, it might be a good idea to flag them as such, in addition to what's already there in section 6. (On section 6, is the intent that the TCP and UDP port numbers must be the same? The current text *could* be read that way.) 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 Mon Apr 7 09:42: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 JAA19540 for ; Mon, 7 Apr 2003 09:42:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192Wk3-000LS9-00 for namedroppers-data@psg.com; Mon, 07 Apr 2003 13:32:55 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 192Wjx-000LRx-00 for namedroppers@ops.ietf.org; Mon, 07 Apr 2003 06:32:50 -0700 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h37DEtv19966 for ; Mon, 7 Apr 2003 06:14:56 -0700 Date: Mon, 7 Apr 2003 06:14:55 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 21: PTR queries 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The proposed resolution of LLMNR Issue 21 (text of the issue and discussion summary below) is to add the following text to Section 3: "[4] A sender SHOULD only send LLMNR queries for PTR RRs that represent addresses reachable through the link over which LLMNR is used." Any objections? Bernard ----------------------------------------------------------------- Issue 21: PTR queries Submitter: Markku Savela Submitter email address: msa@burp.tkv.asdf.org Date first submitted: November 4, 2002 Reference: <200211041445.QAA12218@burp.tkv.asdf.org> Document: LLMNR-12 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: I assume that if you end up doing a address (fe80::1) to name query for IPv6, you end up sending a query to IPv6 multicast address generated from the hash of "1.0.0. ... 0.0.8.e.f.ip6.int" and because the hash is taken from the first label, this will be MD5 from "1"? (basically only 16 different hashes are possible). IPv4 side you have for example "1.2.254.169.in-addr.arpa". Am I right assuming the "resolvers" on nodes have to deal also with these for link local name resolution? [BA] Yes, it is expected that senders will send PTR queries, and that receivers will respond to them. However, it probably doesn't make sense to send a PTR query for an address that isn't on the local link. Here's the proposed resolution: Add the following text to Section 3: "[4] A sender SHOULD only send LLMNR queries for PTR RRs that represent addresses known to be "on link" as defined in Section 2.5." [Erik Guttman and Erik Nordmark]: The problem is that in practice a host may not know the prefixes in use on a particular link. So this restriction can't work in practice. [Comment from Mark T. Hollinger ]: I think we are being too hasty to throw out this restriction. As I metioned in my recent Namedroppers post, supporting your original proposal for issue #3, I would like the fallback to LLMNR not to occur at all for apparently non-local prefixes. If there is a prefix on your link that you don't know about via your routing table, then I don't think LLMNR needs to handle inverse queries for that zone. The target user for LLMNR probably won't have multiple unadvertised global prefixes in the first place. Anybody sophisticated enough to set that up will already have the address of a DNS server configured. Also, if you don't know about the other guy's prefix, he may not know about yours either, in which case he'll get your multicast request but try to send a unicast response via the router, which may decrement the TTL when forwarding it back onto the same link. I'm not sure LLMNR will work in this case (due to the TTL 255 check), but even if it works, I think a configuration where hosts have to communicate (even only initially) via a router is out-of-scope for LLMNR. Let traditional DNS handle that case; we don't need LLMNR there. [BA] Back of the envelope calculations seem to indicate to me that bogus PTR queries can be a significant problem in some cases. Measurements show that a significant fraction of DNS queries are not answered, and this is particularly true with PTR queries. So we can have a substantial amount of bogus LLMNR PTR query traffic. I am particularly worried about wireless networks with lots of people like at IETF 56. 5 queries a second from 3000 people would end up eating up a significant fraction of the total bandwidth of an 802.11 network, particularly if there are lots of folks who have to step down to lower rates (1,2,5 Mbps). So there is some reason for concern. In the discussion at IETF 56, there was concern that it might not be possible for a host to know all the networks it was connected to. The question then arises as to whether it is ok not to send a PTR query for addresses on networks the host doesn't know about. It was pointed out that if the host doesn't have a route for that address, then it will route the packet to the gateway, which might not have a route for it either. In view of the proposed resolution to Issue 28 and 29, it would appear that it makes little sense to send queries for PTR RRs that aren't "on link". Comment from Mika Liljeberg : It's true that the route search is constrained to a single interface but this does not essentially simplify the next hop selection algorithm. A full route search is still required to do on-link determination (unless you make some severe assumptions about the kind of routes that can lead to a specific physical interface). > Perhaps looking at some examples may help make sense of this. Ok. I think your example addresses a different case from the one discussed in issue 21 (PTR queries), but let's look at the example first. > Let us > assume that Myhost is attached to two networks, A and B, and that it is > talking to host [1] on net A and host [2] on net B. > > net B ---------- ---------- net A > | | | | > [2] [myhost] [1] > > Host [1] sends an LLMNR A/AAAA RR query for "myhost". Should myhost > respond with A/AAAA RRs for addresses on net B? This would be bad > if host [1] only has a LL address, since it would not be able to > reach net B. So I think it makes sense for myhost to only respond > with addresses on the interface from which the query came. Right. Issue 29 clarifies this. I agree with the proposed resolution. > So far so good. However, the question is "what if myhost does the wrong > thing?" I don't think the multihomed and broken [myhost] is a very common case but otherwise I agree with what you say: > This is harder because host [1] may not have network B in its > routing table. It therefore will not know how to reach network B. Since > the point of LLMNR is to allow link-local name resolution, if host [1] > doesn't know how to reach net B on the local link then RRs containing that > address are not useful. Agreed. To weed out the unusable address, the LLMNR resolver on [1] should somehow check whether there is a route to it. On many operating systems you can do this by attempting to connect a UDP socket to the destination address. If there is no route, the connect() syscall will fail. Note that having a route to a destination is not the same thing as knowing that the destination is on-link. > Perhaps the right thing to do here is to say that "addresses that are > reachable on the local link are preferred" by host [1]. The LLMNR resolver doesn't *know* which addresses are on-link, so it can't prefer them. > That way, if > myhost only returned an address on network B, host [1] can try to connect > to that, possibly without success. But since there is no choice, what harm > can it do? By host [1] do you mean the LLMNR responder of host [1] or the applicaiton running on host [1]? The LLMNR resolver can, on many operating systems, check the existence of a route (e.g. by doing a UDP connect() to the address). However, what it *cannot* do (as far as I can see), is check whether the destination address is on-link. In IPv6 the DNS resolver is already required to prefer reachable addresses as part of default address selection [RFC3484]. > Another question is what happens if myhost attempts to connect to host > [1], using a source address on net B. The only way this can happen is if a) [myhost] is badly broken, or b) [myhost] uses the Weak ES model [RFC1122] and the addresses in question are not link-locals. [zeroconf] forbids Weak ES model for link-locals. > In this case host [1] may attempt to > send a PTR RR query using LLMNR, for the address on net B. In this case, > myhost might respond to the query with the name myhost which is valid > on the interface. No harm is done. However, one might argue that > host [1] should not send such a query, and that if received, > myhost should not respond to it. The more realistic example, the one which I thought was being dicussed in the context of issue 21, is the following: Internet ---------- ---------- net A | | | | [2] [router] [1] Host [2] is not in the global DNS. It connects to host [1], which tries to make a PTR query to DNS with the address of [2]. [1] receives no response from DNS (whatever the reason) and falls back on LLMNR. LLMNR naturally fails as well. As you say, no harm is done, but it would nice to skip the unnecessary LLMNR query. I agree with the intent. I just don't see a good way to actually implement it. MikaL [BA] How about this? Add the following text to Section 3: "[4] A sender SHOULD only send LLMNR queries for PTR RRs that represent addresses reachable through the link over which LLMNR is used." -- to unsubscribe send a message to namedroppers-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 Apr 7 12:21: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 MAA25512 for ; Mon, 7 Apr 2003 12:21:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192Z72-0006y0-00 for namedroppers-data@psg.com; Mon, 07 Apr 2003 16:04:48 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 192Z70-0006xh-00 for namedroppers@ops.ietf.org; Mon, 07 Apr 2003 09:04:46 -0700 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h37Fkok28520 for ; Mon, 7 Apr 2003 08:46:50 -0700 Date: Mon, 7 Apr 2003 08:46:50 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Conference call 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk We will be having a conference call on Wednesday April 16, 2003 at 8 AM PST in order to go over potential resolutions to open LLMNR issues: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html If you'd like to attend the call, let me know. -- to unsubscribe send a message to namedroppers-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 Apr 7 16:05: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 QAA04595 for ; Mon, 7 Apr 2003 16:05:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192chV-0005Aa-00 for namedroppers-data@psg.com; Mon, 07 Apr 2003 19:54:41 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 192chQ-0005A7-00 for namedroppers@ops.ietf.org; Mon, 07 Apr 2003 12:54:36 -0700 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h37Jts4l013784; Mon, 7 Apr 2003 22:55:55 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h37JtrVx013783; Mon, 7 Apr 2003 22:55:53 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR Issue 30: Why is Dynamic Update Needed? 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: <1049745352.5158.76.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2003 22:55:53 +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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I tend to agree with Erik. Using dynamic update seems like an unnecessary complication when a simple query would do just as well. MikaL On Tue, 2003-04-01 at 09:25, Bernard Aboba wrote: > Issue 30: Why is Dynamic Update needed? > Submitter: Erik Guttman > Submitter email address: erik.guttman@sun.com > Date first submitted: March 24, 2003 > Reference: > Document: LLMNR-14 > Comment type: T > Priority: S > Section: 4 > Rationale/Explanation of issue: > > Maybe I'm missing something, but I do not understand why a host > with UNIQUE RRs needs to test for uniqueness by sending a > Dynamic Update request for the RR with a prerequisite of NXRRSET. > Why would it not be sufficient to send a query for the RR? > > Within the draft, a host that has a UNIQUE RR and > receives a Dynamic Update request will respond with the > YXRRSET error, because the RR does exist. The draft does > not state how the host should respond if the RR is not > UNIQUE. Doesn't it also send a YXRRSET error? If so, then > the sender receives no information about whether the > host thinks that the RR is really UNIQUE or not. > > Given this, it seems to me that the same result could be > accomplished more simply by sending a query for the RR. > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-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 Apr 7 21:34:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13449 for ; Mon, 7 Apr 2003 21:34:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192hcW-000Bsp-00 for namedroppers-data@psg.com; Tue, 08 Apr 2003 01:09:52 +0000 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 192hcT-000BsZ-00 for namedroppers@ops.ietf.org; Mon, 07 Apr 2003 18:09:49 -0700 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Mon, 7 Apr 2003 18:09:48 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 Apr 2003 18:09:48 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3789.0); Mon, 7 Apr 2003 18:09:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 7 Apr 2003 18:09:47 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Mon, 7 Apr 2003 18:09:21 -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 3 Date: Mon, 7 Apr 2003 18:09:29 -0700 Message-ID: Thread-Topic: LLMNR Issue 3 Thread-Index: AcL8Zw9pMKLYKFY6RH21YlSF5PKlagBAs+8g From: "Christian Huitema" To: X-OriginalArrivalTime: 08 Apr 2003 01:09:21.0136 (UTC) FILETIME=[7C77F700:01C2FD6B] X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-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 VAA13449 We have a tension between two requirements: 1) Enable rob.example.net to discover randy.other-example.org on the same link; 2) Avoid making it too easy for a hacker to spoof "www.something-important.com" by convincing the host to send an LLMNR query and then feeding the right answer. The last-last draft (16) proposes the following: [1] If a DNS query does not receive a response, prior to falling back to LLMNR, the query SHOULD be retransmitted at least once. [2] A sender SHOULD send LLMNR queries only for names that are either unqualified or exist within the default domain. [3] A responder with both link-local and routable addresses MUST respond to LLMNR queries for A/AAAA RRs only with routable address(es). This encourages use of routable address(es) for establishment of new connections. [4] A sender SHOULD only send LLMNR queries for PTR RRs that represent addresses reachable through the link over which LLMNR is used. Recommendation [2] will effectively prevent the rob/randy scenario. The root of the issue is that there is not necessarily a "default domain" for a given link -- e.g. a corporate laptop visiting a home network keeps its corporate name. The recommendation [2] is thus difficult to implement. -- 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 Mon Apr 7 22:21: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 WAA14430 for ; Mon, 7 Apr 2003 22:21:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192iWz-000JRz-00 for namedroppers-data@psg.com; Tue, 08 Apr 2003 02:08:13 +0000 Received: from dhcp-47.wl.nominum.com ([81.200.65.47] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 192iWv-000JQz-00 for namedroppers@ops.ietf.org; Mon, 07 Apr 2003 19:08:10 -0700 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 h38261ta016984; Mon, 7 Apr 2003 19:06:01 -0700 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h3825tQb016981; Mon, 7 Apr 2003 19:05:55 -0700 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Mon, 7 Apr 2003 19:05:54 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: "Hallam-Baker, Phillip" cc: "'Steven M. Bellovin'" , Rob Austein , "" Subject: RE: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-39.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 4 Apr 2003, Hallam-Baker, Phillip wrote: > When you have a protocol that has gone undeployed for ten years > it is probably time to stop thinking about long term optimizations > and start thinking about steps that can be taken to minimize > the cost of deployment and maximize the buy in from the > operators concerned. A large part of the reason the protocol has gone undeployed for 10 years is the complexity. Opt-in won't make the protocol simpler. > If DNSSEC does not have an answer for deployment in .COM it > will never be deployed in the form defined by the IETF, it > is as simple as that. Bullying the working group is not the right solution to this, or any, problem. If Verisign is incapable of serving a signed .COM, perhaps they should consider transferring ownership to someone who is. No one else thinks it's impossible. 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 Apr 7 23:36: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 XAA15608 for ; Mon, 7 Apr 2003 23:36:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192jj8-0003lj-00 for namedroppers-data@psg.com; Tue, 08 Apr 2003 03:24:50 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe10:67ab] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 192jj6-0003lT-00 for namedroppers@ops.ietf.org; Mon, 07 Apr 2003 20:24:48 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 69F96379EF5 for ; Tue, 8 Apr 2003 03:24:35 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message from Brian Wellington of "Mon, 07 Apr 2003 19:05:54 MST." X-Mailer: MH-E 7.2; nmh 1.0.4; GNU Emacs 21.2.1 Date: Tue, 08 Apr 2003 03:24:35 +0000 Message-Id: <20030408032435.69F96379EF5@as.vix.com> X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,OPT_IN_CAPS,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > A large part of the reason the protocol has gone undeployed for 10 years > is the complexity. Opt-in won't make the protocol simpler. let's consider the way that complexity has lengthened the timeline. mostly it's because of the lengthy debate which accompanied complex proposals. > Bullying the working group is not the right solution to this, or any, > problem. yea, verily. however: > If Verisign is incapable of serving a signed .COM, perhaps they should > consider transferring ownership to someone who is. No one else thinks > it's impossible. verisign hasn't said it was impossible, either. they say it's expensive, because of the infrastructure that dnssec functionality would lay on top of. they also say it's too expensive in the absence of any accompanying new short term revenue to be worth deploying on speculation or using cross-subsidy. however, that debate is pointless. verisign as a zone publisher is allowed to make decisions concerning their zone. that's "autonomy". anyone who thinks they can get leverage on verisign to make them sign COM without opt-in, or failing that, to get it moved to a different publisher, is not being realistic. therefore whatever verisign's reasons are do not matter, and the practical point is that they've said they won't sign COM without either opt-in or a larger market, and that larger market may never appear without support for dnssec for COM subdomains. unless you think they are bluffing, or you think dnssec has some measurable difference in quality or purity with and without opt-in (hint: ~zero = ~zero), then the debate, such as it was, is over, just plain and simply over, and we ought to get on with 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 Tue Apr 8 03:35: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 DAA01464 for ; Tue, 8 Apr 2003 03:35:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192nVQ-000LNy-00 for namedroppers-data@psg.com; Tue, 08 Apr 2003 07:26:56 +0000 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 192nVO-000LNj-00 for namedroppers@ops.ietf.org; Tue, 08 Apr 2003 00:26:54 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA11790; Tue, 8 Apr 2003 01:26:52 -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 h387QpS24302; Tue, 8 Apr 2003 09:26:51 +0200 (MEST) Date: Tue, 8 Apr 2003 09:26:43 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: LLMNR Issue 3 To: Christian Huitema 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=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > We have a tension between two requirements: > > 1) Enable rob.example.net to discover randy.other-example.org on the > same link; > > 2) Avoid making it too easy for a hacker to spoof > "www.something-important.com" by convincing the host to send an LLMNR > query and then feeding the right answer. This tension is caused by the desire to have the same API do DNS and LLMNR lookups with some form of automatic fallback. What you propose might be the best compromise in that case. But there is an option to allow an explicit user interface knob to say "always use LLMNR, always use DNS, first DNS than LLMNR" and have different rules in the 3 cases. In the first case, when the user has explicitly told the system to use LLMNR for everything, then LLMNR should be able to lookup any names I think. 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 Apr 8 09:56: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 JAA10197 for ; Tue, 8 Apr 2003 09:56:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192tL3-000DuQ-00 for namedroppers-data@psg.com; Tue, 08 Apr 2003 13:40:37 +0000 Received: from sentry.gw.tislabs.com ([192.94.214.100]) by psg.com with esmtp (Exim 3.36 #1) id 192tKu-000Du8-00 for namedroppers@ops.ietf.org; Tue, 08 Apr 2003 06:40:28 -0700 Received: by sentry.gw.tislabs.com; id JAA07202; Tue, 8 Apr 2003 09:41:27 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma007191; Tue, 8 Apr 03 09:40:44 -0400 Received: from localhost (weiler@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h38Ddhp01193 for ; Tue, 8 Apr 2003 09:39:43 -0400 (EDT) Date: Tue, 8 Apr 2003 09:39:43 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Subject: WG Action: IPSEC KEYing information resource record (fwd) 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Just before the San Francisco meeting, the IPSECKEY WG was chartered to specify an RR for opportunistic IPSEC. Current discussion is about bits on the wire, and participation from DNSEXT participants would be most welcome. There's only draft, so the reading list is short. :) http://www.ietf.org/html.charters/ipseckey-charter.html http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-00.txt http://www.sandelman.ca/lists/html/ipseckey/ ---------- Forwarded message ---------- Date: Wed, 26 Feb 2003 13:48:10 -0500 From: The IESG To: IETF-Announce: ; Subject: WG Action: IPSEC KEYing information resource record A new working group has been formed in the Security Area of the IETF. For additional information, contact the Area Directors or the Working Group Chairs. IPSEC KEYing information resource record (ipseckey) ----------------------------------------------------- Current Status: Active Working Group Chair(s): Sam Weiler Rob Austein Security Area Director(s): Jeffrey Schiller Steven Bellovin Security Area Advisor: Steven Bellovin Mailing Lists: General Discussion:ipseckey@sandelman.ca To Subscribe: ipseckey-request@sandelman.ca Archive: http://www.sandelman.ca/lists/html/ipseckey/ Description of Working Group: This effort has the goal of designing a IPSEC-specific resource record for the domain name system (DNS) to replace the functionality of the IPSEC sub-type of the KEY resource record. The original DNSSEC specification explicitly specified flags on the KEY resource records for use by IPSEC. Experience has shown that this has operational problems. The DNSEXT working group is restricting the use of the KEY record to DNS uses only. Thus, IPSEC keying via DNS needs a new resource record. The scope of work is to identify what information is needed in an IPSEC-specific keying resource record, and to design such a record in co-operation with the dnsext working group. The contents of the resource record are not limited to only the information that is in the DNS KEY record but may also contain other useful IPSEC information, such as that which is required for Opportunistic Encryption. Other possible uses are out of scope for this working group, since any reuse will require a careful analysis of the trust model and possible security interactions with IPsec. It is anticipated that such analysis will be documented in some future standards-track RFCs. The WG will define the semantics of the record only in terms of how the data in the record can be used for initializing an IPSEC session. Questions of when it is appropriate to do so are regarded as policy issues that are out of scope for this WG. This effort is specific to providing IPSEC information in DNS. All other distribution channels are out of scope. Goals and Milestones: MAR 03 Solicit various proposals on what information is needed in IPSEC specific KEYing record APR 03 Publish first Internet-Draft of consensus DNS Resource Record MAY 03 Complete WG Last Call on consensus DNS RR proposal document and pass document to IESG for consideration as a Proposed Standard -- to unsubscribe send a message to namedroppers-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 Apr 8 10:32: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 KAA14175 for ; Tue, 8 Apr 2003 10:32:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 192tvC-000GTP-00 for namedroppers-data@psg.com; Tue, 08 Apr 2003 14:17:58 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 192tv8-000GT2-00 for namedroppers@ops.ietf.org; Tue, 08 Apr 2003 07:17:54 -0700 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h38EHpTm027866 for ; Tue, 8 Apr 2003 07:17:51 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Apr 2003 07:17:51 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: RE: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Tue, 8 Apr 2003 07:17:51 -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,OPT_IN_CAPS,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > A large part of the reason the protocol has gone undeployed > for 10 years > is the complexity. Opt-in won't make the protocol simpler. I think the principal reason is actually lack of a killer application retrofitting security is hard because the marginal advantage is very low if only a small fraction of the deployed base is secure. The same problem faces IPSEC, although it has managed to find a niche that provides a bootstrap for deployment. I don't think that this group has worked out how to find such a niche for DNSSEC. If there is one it is likely to be SPAM. > > If DNSSEC does not have an answer for deployment in .COM it > > will never be deployed in the form defined by the IETF, it > > is as simple as that. > > Bullying the working group is not the right solution to this, or any, > problem. Hmm, from my point of view the objective of some in the group has been to bully VeriSign. In particular comments made on more than one occasion at IETF meetings were 'we don't care about .COM', 'if DNSSEC breaks large zones, that is a good thing, they should not exist' etc. All I have ever done is to lay out the brutal facts. The Internet is a very large deployed infrastructure and it is going to take a lot more than a draft becomming an RFC to allow success. There is absolutely no point in the group comming up with a protocol that is undeployable. Even with OPT-IN the group cannot be successful without the active support of the major platform vendors. FreeSwan does not meet that description, sorry. Instead of evangelising the merits of DNSSEC to key players such as Microsoft, it appears that many in the group would rather DNSSEC was UNIX only. I am sorry, but application of a cluebat has ALWAYS been a part of the IETF lexicon. The leverage that some in the group thought and still thinks exists does not. You cannot bully a large infrastructure provider into doing things your way, particularly with a process as closed and crooked as this one has been. If the IETF is going to discuss DNS protocols in a closed directorate without any representation from the largest DNS infrastructure company then there is no value in this forum any more and it is time to choose a new one. You can call 'take my ball and go home' bullying, but really the only reason it looks that way is the relative strength of the bargaining positions. Nobody interprets the flat earther view to be bullying because they have no leverage and hence there is no threat. It should not have been necessary for that type of threat to be made simply to get the benefit of due process in this group, but it was. Perhaps if Randy had not started the relationship by telling me that he was predjudiced against my employer things might have turned out differently, but I doubt it. You can argue that maybe I could have approached the issue somewhat differently and there might have been less resistance, the presentation argument is always used when the case is lost. I don't think that any other approach would have had any better effect. We tried nice and we got nothing but insults and the DNS directorate discursion. I could sit back and just let the group be railroaded into publishing drafts that are undeployable, if my objective was to kill DNSSEC that is exactly what I would have done, I would have let the group go to RFC then said we will wait for support from 50% of the O/S platforms by market share before deployment. The whole issue would be dead and burried by now, along with DNSSEC, and over time DNS itself. > If Verisign is incapable of serving a signed .COM, perhaps > they should > consider transferring ownership to someone who is. No one > else thinks > it's impossible. Hey, Brian, we are independent contributors, remember? The application of that rule seems curious to me. It seems to me that the true intention is to preserve the privileges of seniority and allow the academics to denegrate the younger engineers who are mostly employed in corporate research labs when they feel like it as 'following company orders' while preventing the corporate researchers from pointing out that in the real world some folk have more influence than they do. As for signing .COM being impossible, nobody ever said that, I did say it was grossly uneconomic and that the incremental cost of deployment was unacceptable for an experimental protocol that may never be used on a wide scale. This group is not the only forum that gets to make comment on the quality of the group's work. If that quality is not acceptable the specs produced will not be deployed. 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 Tue Apr 8 20:21: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 UAA09357 for ; Tue, 8 Apr 2003 20:21:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19338w-000PRw-00 for namedroppers-data@psg.com; Wed, 09 Apr 2003 00:08:46 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19338t-000PRk-00 for namedroppers@ops.ietf.org; Tue, 08 Apr 2003 17:08:43 -0700 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h38Noge03035 for ; Tue, 8 Apr 2003 16:50:43 -0700 Date: Tue, 8 Apr 2003 16:50:42 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 3: LLMNR Usage 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [BA] How about this? In section 3, change: "[2] A sender SHOULD send LLMNR queries only for names that are either unqualified or exist within the default domain." To: "[2] Where a DNS server is configured, by default a sender SHOULD send LLMNR queries only for names that are either unqualified or exist within the default domain. Where no DNS server is configured, an LLMNR query MAY be sent for any name." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 8 23:28: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 XAA13793 for ; Tue, 8 Apr 2003 23:28:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193647-000FiZ-00 for namedroppers-data@psg.com; Wed, 09 Apr 2003 03:15:59 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 193644-000FgM-00 for namedroppers@ops.ietf.org; Tue, 08 Apr 2003 20:15:57 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E0F0A18ED for ; Tue, 8 Apr 2003 23:15:21 -0400 (EDT) Date: Tue, 08 Apr 2003 23:15:21 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Proposed Resolution of LLMNR Issue 3: LLMNR Usage In-Reply-To: References: 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: <20030409031521.E0F0A18ED@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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 8 Apr 2003 16:50:42 -0700 (PDT), Bernard Aboba wrote: > > [BA] How about this? In section 3, change: > > "[2] A sender SHOULD send LLMNR queries only for names that are > either unqualified or exist within the default domain." > > To: > > "[2] Where a DNS server is configured, by default a sender > SHOULD send LLMNR queries only for names that are either > unqualified or exist within the default domain. Where no > DNS server is configured, an LLMNR query MAY be sent for > any name." Other than the fact that I have no idea what "Where a DNS server is configured" means for a laptop that usually runs an iterative resolver, this seems ok :). -- to unsubscribe send a message to namedroppers-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 Apr 9 14:26: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 OAA08635 for ; Wed, 9 Apr 2003 14:25:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193K1z-0001NT-00 for namedroppers-data@psg.com; Wed, 09 Apr 2003 18:10:43 +0000 Received: from mail-out2.apple.com ([17.254.0.51]) by psg.com with esmtp (Exim 3.36 #1) id 193K1t-0001NF-00 for namedroppers@ops.ietf.org; Wed, 09 Apr 2003 11:10:37 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h39IAbQd018264 for ; Wed, 9 Apr 2003 11:10:37 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 9 Apr 2003 11:10:25 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h39IAYvu024865 for ; Wed, 9 Apr 2003 11:10:34 -0700 (PDT) Date: Wed, 9 Apr 2003 11:10:39 -0700 Subject: Re: LLMNR Issue 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <91A3C102-6AB6-11D7-8382-000A959D832C@apple.com> X-Mailer: Apple Mail (2.551) 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Apr 8, 2003, at 00:26 US/Pacific, Erik Nordmark wrote: >> We have a tension between two requirements: >> >> 1) Enable rob.example.net to discover randy.other-example.org on the >> same link; >> >> 2) Avoid making it too easy for a hacker to spoof >> "www.something-important.com" by convincing the host to send an LLMNR >> query and then feeding the right answer. > > This tension is caused by the desire to have the same API do DNS and > LLMNR > lookups with some form of automatic fallback. > What you propose might be the best compromise in that case. > > But there is an option to allow an explicit user interface knob > to say "always use LLMNR, always use DNS, first DNS than LLMNR" > and have different rules in the 3 cases. > In the first case, when the user has explicitly told the system to use > LLMNR > for everything, then LLMNR should be able to lookup any names I think. A knob is often a bad thing. It's an acknowledgment that there is no good solution so the user should research the options and come to their own conclusion about what will work best. I would not want to always use LLMNR first or even simultaneously with DNS. I don't want to make it easier for someone to spoof my mail server, or the AIM server, or any of the other number of services that are totally insecure that I make use of on a daily basis. The solution to this problem lies in LLMNR issue 22 (Bring back "local.arpa"). That issue has been rejected. Unless that issue is going to be reopened, it seems the obvious answer is that DNS should be used before LLMNR to avoid the security problems. This makes LLMNR useful only in the case where a device does not have a configured DNS server or for names that do not exist in the DNS namespace. This is a pity since multi-homed devices are so common these days. This severely (perhaps fatally) limits the usefulness of LLMNR. This limitation and the question of what name to use will likely limit LLMNR to hobbyists and experts. Since LLMNR issue 22 has been rejected, read no further. The problem you're trying to address is the reason that Apple is using a special domain to denote names that should always be resolved using a specific non DNS method. Dynamic DNS update is nice, but few people use it. This usually means that a laptop can have many names throughout the period of a day. When I'm at work, my laptop is graejo5.apple.com.. When I'm at home, my laptop is adsl-64-171-18-123.dsl.sntc01.pacbell.net.. If I had dynamic DNS setup, I could potentially have something like joshs-tibook.graessley.com. always point to whatever IP address is currently assigned to my laptop. I don't have that setup and neither does the average person. If I meet someone else at an airport or at someone's house where I'm assigned a NAT address, I would like an easy way to connect to their machine by name. In both of these cases, I have a configured DNS server. I have no idea what name the other machine has. If my friend has dynamic DNS enabled, he might have a useful name that could be up to date. If we're both behind the same NAT, we should have no trouble communicating, but my friend should not use the NAT address when updating the DNS record for their name. Yes, NAT is evil, but we can't just bury our heads in the sand and ignore the problem. By carving off a domain such as "local.arpa." and making LLMNR the authority of that domain, you solve two problems. You can make it very clear when LLMNR should be used (LLMNR issue 3), if the fully qualified name ends in "local.arpa.", use LLMNR. You also give people a domain they can use a name in. Not everyone owns a domain they can assign names from. Most ISPs certainly don't assign your computer a name, they assign a name to the IP address that you are assigned. Your IP address often changes, so that name often changes. The use of the "local.arpa." domain also solves some serious multihoming problems. With multihoming, there is a possibility that one interface will be attached to a configured network and one interface will be attached to an ad-hoc network. In such a scenario, the device connected to both networks will be unable to use LLMNR to resolve names on the ad-hoc network. The queries would be sent to DNS first. By specifying a domain such as local.arpa. to indicate queries should be sent using LLMNR, we can handle the multi-homed case. The multi-homed devices sends queries ending in local.arpa. to LLMNR and all other queries to DNS. We don't have the potential security problem of sending queries for www.ietf.org to LLMNR but we get the benefit of being able to resolve, using LLMNR, the names of the devices on the ad-hoc network. -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 Wed Apr 9 16:17: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 QAA12736 for ; Wed, 9 Apr 2003 16:17:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193Lrw-000BY7-00 for namedroppers-data@psg.com; Wed, 09 Apr 2003 20:08:28 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 193Lrq-000BX1-00 for namedroppers@ops.ietf.org; Wed, 09 Apr 2003 13:08:22 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 440EC18E6 for ; Wed, 9 Apr 2003 16:07:50 -0400 (EDT) Date: Wed, 09 Apr 2003 16:07:50 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? References: <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> 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: <20030409200750.440EC18E6@thrintun.hactrn.net> X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSSECbis Q-07: Should the DNSSECbis documents discuss use of preconfigured trusted DSs in addition to to preconfigured trusted KEYs? Discussion: As currently written, the DNSSECbis documents (specifically, -protocol) only talk about how to establish a chain of trust starting with preconfigured trusted keys. At least one member of the dnssec-editors team believes that this is just an oversight, since section 2.4.1 of -delegation-signer-13 specifically mentions the possibility of using DS RRs as a means of listing trusted keys in configuration files. Message from the DNSOP WG mailing list attached below for context. Miek has kindly volunteered to work with the editors on wording. --[[message/rfc822] Date: Tue, 08 Apr 2003 21:55:56 -0400 From: Rob Austein To: dnsop@cafax.se Subject: Re: preconfigured keys or ds's References: <20030331132915.GA2912@atoom.net> MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030409015556.6CF3B18ED@thrintun.hactrn.net> At Mon, 31 Mar 2003 15:29:15 +0200, Miek Gieben wrote: > > I would like to see the following documented, but I don't know for sure > if it is a dnssec or dnsop issue: > > The preconfigured keys for resolvers are large and are hard to compare > and read (by humans). DS records on the other hand are much smaller > and easier to handle. I think it would be better to preconfigure > DS records in stead of zone keys for resolvers. This is also how > my perl resolver works. This sounds like a reasonable implementation choice. > Where to put this? In the dnssec drafts or in a seperate dnsop BCP? The current DNSSECbis drafts don't talk about using trusted DS RRs as a starting point, only trusted KEYs. Given the last paragraph of section 2.4.1 of draft-ietf-dnsext-delegation-signer-13.txt, this looks like an oversight (probably mine, since I was probably the last person to work on the relevant text in the DNSSECbis drafts). So the DNSSECbis spec needs fixing, and I don't expect anybody to argue against the fix, but for process reasons it'd be best to post an explanation to namedroppers first, so I'll do that. Because of the above, at least part of this is a DNSEXT issue. -- to unsubscribe send a message to namedroppers-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 Apr 9 17:03: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 RAA14571 for ; Wed, 9 Apr 2003 17:03:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193MdB-000GAs-00 for namedroppers-data@psg.com; Wed, 09 Apr 2003 20:57:17 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 193Md5-000GAe-00 for namedroppers@ops.ietf.org; Wed, 09 Apr 2003 13:57:11 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h39KuWhb004205; Wed, 9 Apr 2003 16:57:06 -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 h39KqpV1004985; Wed, 9 Apr 2003 16:52:51 -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 h39KqoU8018427; Wed, 9 Apr 2003 16:52:51 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id QAA20208; Wed, 9 Apr 2003 16:52:50 -0400 (EDT) To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? References: <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> From: Derek Atkins Date: 09 Apr 2003 16:52:50 -0400 In-Reply-To: <20030409200750.440EC18E6@thrintun.hactrn.net> Message-ID: Lines: 91 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.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Effectively what you are saying is that you want to store a hash of the trusted key rather than the key itself. I'm not sure what I think about this. On the face of it, it should work just fine. However you're now trusting the hash algorithm to root your key. -derek Rob Austein writes: > DNSSECbis Q-07: > > Should the DNSSECbis documents discuss use of preconfigured trusted > DSs in addition to to preconfigured trusted KEYs? > > Discussion: > > As currently written, the DNSSECbis documents (specifically, > -protocol) only talk about how to establish a chain of trust > starting with preconfigured trusted keys. At least one member of > the dnssec-editors team believes that this is just an oversight, > since section 2.4.1 of -delegation-signer-13 specifically mentions > the possibility of using DS RRs as a means of listing trusted keys > in configuration files. > > Message from the DNSOP WG mailing list attached below for context. > > Miek has kindly volunteered to work with the editors on wording. > > > --[[message/rfc822] > Date: Tue, 08 Apr 2003 21:55:56 -0400 > From: Rob Austein > To: dnsop@cafax.se > Subject: Re: preconfigured keys or ds's > References: <20030331132915.GA2912@atoom.net> > MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") > Content-Type: text/plain; charset=US-ASCII > Message-Id: <20030409015556.6CF3B18ED@thrintun.hactrn.net> > > At Mon, 31 Mar 2003 15:29:15 +0200, Miek Gieben wrote: > > > > I would like to see the following documented, but I don't know for sure > > if it is a dnssec or dnsop issue: > > > > The preconfigured keys for resolvers are large and are hard to compare > > and read (by humans). DS records on the other hand are much smaller > > and easier to handle. I think it would be better to preconfigure > > DS records in stead of zone keys for resolvers. This is also how > > my perl resolver works. > > > > This sounds like a reasonable implementation choice. > > > > > Where to put this? In the dnssec drafts or in a seperate dnsop BCP? > > > > The current DNSSECbis drafts don't talk about using trusted DS RRs > as a starting point, only trusted KEYs. Given the last paragraph of > section 2.4.1 of draft-ietf-dnsext-delegation-signer-13.txt, this > looks like an oversight (probably mine, since I was probably the > last person to work on the relevant text in the DNSSECbis drafts). > > So the DNSSECbis spec needs fixing, and I don't expect anybody to > argue against the fix, but for process reasons it'd be best to post > an explanation to namedroppers first, so I'll do that. > > > > > > Because of the above, at least part of this is a DNSEXT issue. > > > > -- > to 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, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Apr 9 17:20: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 RAA15287 for ; Wed, 9 Apr 2003 17:20:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193Mtu-000HuP-00 for namedroppers-data@psg.com; Wed, 09 Apr 2003 21:14:34 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 193Mtr-000Hra-00 for namedroppers@ops.ietf.org; Wed, 09 Apr 2003 14:14:32 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D50A518EC for ; Wed, 9 Apr 2003 17:13:59 -0400 (EDT) Date: Wed, 09 Apr 2003 17:13:59 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? In-Reply-To: References: <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> 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: <20030409211359.D50A518EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 09 Apr 2003 16:52:50 -0400, Derek Atkins wrote: > > Effectively what you are saying is that you want to store > a hash of the trusted key rather than the key itself. > I'm not sure what I think about this. Allow implementors the option of storing the hash instead of the key, yes. Implementors who prefer to store the key could still do so. > On the face of it, it should work just fine. However > you're now trusting the hash algorithm to root your > key. Yep. We trust the same hash algorithm when following delegations, so I doubt there's a serious threat here, but that's the issue. -- to unsubscribe send a message to namedroppers-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 Apr 10 00:12: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 AAA25516 for ; Thu, 10 Apr 2003 00:12:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193TDO-000BoQ-00 for namedroppers-data@psg.com; Thu, 10 Apr 2003 03:59:06 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 193TDL-000BoA-00 for namedroppers@ops.ietf.org; Wed, 09 Apr 2003 20:59:03 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3A3x179014272; Wed, 9 Apr 2003 23:59:01 -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 h3A3x0iq004344; Wed, 9 Apr 2003 23:59:01 -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 h3A3x0U8029795; Wed, 9 Apr 2003 23:59:00 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id XAA20972; Wed, 9 Apr 2003 23:59:00 -0400 (EDT) To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? References: <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030409211359.D50A518EC@thrintun.hactrn.net> From: Derek Atkins Date: 09 Apr 2003 23:59:00 -0400 In-Reply-To: <20030409211359.D50A518EC@thrintun.hactrn.net> Message-ID: Lines: 29 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=-37.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: > At 09 Apr 2003 16:52:50 -0400, Derek Atkins wrote: > > > > Effectively what you are saying is that you want to store > > a hash of the trusted key rather than the key itself. > > I'm not sure what I think about this. > > Allow implementors the option of storing the hash instead of the key, > yes. Implementors who prefer to store the key could still do so. Sorry, of course it provides the option... > > On the face of it, it should work just fine. However > > you're now trusting the hash algorithm to root your > > key. > > Yep. We trust the same hash algorithm when following delegations, so > I doubt there's a serious threat here, but that's the issue. I think that so long as users have the option then there is no problem. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-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 Apr 10 04:54: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 EAA12366 for ; Thu, 10 Apr 2003 04:54:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193XZb-000FRb-00 for namedroppers-data@psg.com; Thu, 10 Apr 2003 08:38:19 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 193XZX-000FRN-00 for namedroppers@ops.ietf.org; Thu, 10 Apr 2003 01:38:15 -0700 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h3A8cCtF023872; Thu, 10 Apr 2003 10:38:12 +0200 Date: Thu, 10 Apr 2003 10:38:12 +0200 From: "Olaf M. Kolkman" To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Message-Id: <20030410103812.53189a5f.olaf@ripe.net> In-Reply-To: <20030409200750.440EC18E6@thrintun.hactrn.net> References: <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > DNSSECbis Q-07: > > Should the DNSSECbis documents discuss use of preconfigured trusted > DSs in addition to to preconfigured trusted KEYs? > The idea has operational elegance. I also think that because of DS having hash versioning and you rely on SHA1 hashes in algorithms 3 and 5 today there are no apparent crypto/security risks (But hey I'm no cryptoguru). What I do not like is that you loose the ability to verify directly against the configured key and thus leave the KSK out of the apex keyset. This is relevant in the context of Ihrens treshold validation and root signing draft. ----------------------- I am a little confused if having a keyset without the KSK is actually allowed by the current specs (also see the thread starting with: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00752.html ) In section 2 (signing) of the protocol doc there is a SHOULD: "For each private key used to create SIG RRs, there SHOULD be a corresponding KEY RR stored at the zone apex" In section 5 it says: "An initial KEY RR can be used to authenticate a zone's apex KEY RRset. To authenticate an apex KEY RRset using an initial key, the resolver MUST: 1. Verify that the initial KEY RR appears in the apex KEY RRset, and verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7) set to one. 2. Verify that there is some SIG RR which covers the apex KEY RRset, and that the combination of the SIG RR and the initial KEY RR authenticates the KEY RRset. The process for using a SIG RR to authenticate an RRset is described in Section 5.2. " The SHOULD in section 2 and the MUST in section 5 are IMHO inconsistent. There was some debate in the previous thread on how to solve this inconsistency. I've read sections 2.1 and 2.2 of RFC3090 and those do not seem to exclude the use of a key that is not published in the zone itself. In other words I am still confused, which is if it comes to specs a bad sign. Maybe the specs should be clarified to specifically allow or disallow proof against the pre-configured key directly. I would choose for allowing direct verification of signatures with pre-configured keys. (Hey Brian or Mark, what does the current BIND9 code do?) --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-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 Apr 10 05:47: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 FAA13585 for ; Thu, 10 Apr 2003 05:47:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193YQv-000J0D-00 for namedroppers-data@psg.com; Thu, 10 Apr 2003 09:33:25 +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 193YQs-000J00-00 for namedroppers@ops.ietf.org; Thu, 10 Apr 2003 02:33:22 -0700 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) with ESMTP id h3A9XBt2010765; Thu, 10 Apr 2003 11:33:11 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) id h3A9XBH2010764; Thu, 10 Apr 2003 11:33:11 +0200 Date: Thu, 10 Apr 2003 11:33:11 +0200 From: Miek Gieben To: "Olaf M. Kolkman" Cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Message-ID: <20030410093311.GC10167@atoom.net> Mail-Followup-To: "Olaf M. Kolkman" , Rob Austein , namedroppers@ops.ietf.org References: <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030410103812.53189a5f.olaf@ripe.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 10 Apr, @10:38, Olaf wrote in "Re: DNSSECbis Q-07: Discuss pr ..."] > > > DNSSECbis Q-07: > > > > Should the DNSSECbis documents discuss use of preconfigured trusted > > DSs in addition to to preconfigured trusted KEYs? > > > > The idea has operational elegance. I also think that because of DS > having hash versioning and you rely on SHA1 hashes in algorithms 3 and > 5 today there are no apparent crypto/security risks (But hey I'm no > cryptoguru). crypto risks aside, I think it is a good to be able to manually check that your preconfigured ds's are the right ones. > What I do not like is that you loose the ability to verify directly > against the configured key and thus leave the KSK out of the apex > keyset. This is relevant in the context of Ihrens treshold validation > and root signing draft. This should IMO be a MUST. A secure zone MUST have a key in the apex and a resolver MUST check that. grtz Miek -- to unsubscribe send a message to namedroppers-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 Apr 10 11:37: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 LAA24193 for ; Thu, 10 Apr 2003 11:37:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193dtT-0000j7-00 for namedroppers-data@psg.com; Thu, 10 Apr 2003 15:23:15 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 193dtP-0000iv-00 for namedroppers@ops.ietf.org; Thu, 10 Apr 2003 08:23:11 -0700 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HD40023YW2NX1@eListX.com> for namedroppers@ops.ietf.org; Thu, 10 Apr 2003 11:23:11 -0400 (EDT) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h3AFLVSI085076; Thu, 10 Apr 2003 11:21:32 -0400 (EDT envelope-from ogud@ogud.com) Date: Thu, 10 Apr 2003 11:20:56 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? In-reply-to: <20030410093311.GC10167@atoom.net> X-Sender: post@localhost To: Miek Gieben , "Olaf M. Kolkman" Cc: Rob Austein , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030410110749.01713ff8@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> X-Spam-Status: No, hits=-31.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 05:33 2003-04-10, Miek Gieben wrote: > > What I do not like is that you loose the ability to verify directly > > against the configured key and thus leave the KSK out of the apex > > keyset. This is relevant in the context of Ihrens treshold validation > > and root signing draft. > >This should IMO be a MUST. A secure zone MUST have a key in the apex and a >resolver MUST check that. I agree with this, operationally life will be much simpler if the KSK is in the key set. From the resolver perspective it can detect many different error conditions and give more intelligent error messages. (example if you have one KEY configured and that key rolls over, the resolver can now say: "configured KEY for '.' missing, all other KSK keys signatures verify".) The master server can use the presence of the KSK as loading precondition and reject incorrectly configured zones. As someone who has configured many trusted-keys even the best tools do not protect you against corrupting large KEY records. DS hash as trusted entry handle is much simpler for humans to manipulate and check. I think of it as feature that only few KSK can be in the root KEY set. The dissemination of the trusted DS records for the root is where a large group of keys can be used, as well as certificates. Inclusion and update of the trusted root DS set is outside the protocol, IMHO. 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 Apr 10 14:14: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 OAA29095 for ; Thu, 10 Apr 2003 14:14:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193gJY-000KKY-00 for namedroppers-data@psg.com; Thu, 10 Apr 2003 17:58:20 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 193gJV-000KKK-00 for namedroppers@ops.ietf.org; Thu, 10 Apr 2003 10:58:18 -0700 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3AHe8811411 for ; Thu, 10 Apr 2003 10:40:08 -0700 Date: Thu, 10 Apr 2003 10:40:08 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Joshua Graessley writes: "I would not want to always use LLMNR first or even simultaneously with DNS. I don't want to make it easier for someone to spoof my mail server, or the AIM server, or any of the other number of services that are totally insecure that I make use of on a daily basis." This is certainly a concern. While both unicast and multicast name resolution is vulnerable to spoofing without DNS security, the thinking is that LLMNR is even easier because you don't even have to write any software to do it, just misconfigure your machine. Also, DNS security seems difficult to deploy with protocols such as LLMNR. So the argument is that even though both usages are vulnerable today, LLMNR is likely to remain vulnerable, no matter how DNS security were to advance. "The solution to this problem lies in LLMNR issue 22 (Bring back "local.arpa")." I guess I'm missing how "local.arpa" addresses the spoofing issue. Is this because instead of spoofing ietf.org, the attacker now has to spoof ietf.org.local.arpa? Or is the "security" provided by this due to only using linklocal name resolution to resolve unqualified names (foo.local.arpa)? In that case, why wouldn't the same scope restriction in LLMNR provide equivalent security? "You can make it very clear when LLMNR should be used (LLMNR issue 3), if the fully qualified name ends in "local.arpa.", use LLMNR." Actually, this just adds another "knob to configure" -- the search list. "You also give people a domain they can use a name in." Since this is a flat name space, that doesn't address the issue of name conflicts. There will be as many "bob.local.arpa" hosts as "bob" hosts. "When I'm at work, my laptop is graejo5.apple.com. When I'm at home, my laptop is adsl-64-171-18-123.dsl.sntc01.pacbell.net." Depends on whether your host allows DHCP to assign the name or not. If not, your laptop might remain graejo5.apple.com while a PTR RR query for your IP address might return adsl-64-171-18-123.dsl.sntc01.pacbell.net from the DNS server, and graejo5.apple.com if handled via LLMNR. In any case, I'm not sure how "local.arpa" helps this situation. Does someone at the airport connect to your machine as "graejo5.apple.com.local.arpa"? "graejo5.local.arpa"? Or some other name? "If I meet someone else at an airport or at someone's house where I'm assigned a NAT address, I would like an easy way to connect to their machine by name. In both of these cases, I have a configured DNS server. I have no idea what name the other machine has." This doesn't sound like a problem that requires a name resolution solution to me. It has been pointed out by Erik Guttman that if what is actually needed to solve this is to discover the hosts and corresponding services on the local link, as well as their attributes, which could include a "friendly name". That way you don't have to know what the name is -- which is a problem whether you're using "local.arpa" or not. "there is a possibility that one interface will be attached to a configured network and one interface will be attached to an ad-hoc network. In such a scenario, the device connected to both networks will be unable to use LLMNR to resolve names on the ad-hoc network." I don't think this is true. It might attempt to do a DNS query first, but presumably this will fail and an LLMNR query will go out, potentially on both interfaces. -- to unsubscribe send a message to namedroppers-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 Apr 10 16:25: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 QAA05552 for ; Thu, 10 Apr 2003 16:25:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193iNR-000CHG-00 for namedroppers-data@psg.com; Thu, 10 Apr 2003 20:10:29 +0000 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #1) id 193iNN-000CGs-00 for namedroppers@ops.ietf.org; Thu, 10 Apr 2003 13:10:25 -0700 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 h3AKAN3h002942 for ; Thu, 10 Apr 2003 13:10:23 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 10 Apr 2003 13:10:13 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h3AKAMVX025796 for ; Thu, 10 Apr 2003 13:10:23 -0700 (PDT) Date: Thu, 10 Apr 2003 13:10:27 -0700 Subject: Re: LLMNR Issue 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: namedroppers@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <78AA0C3D-6B90-11D7-954C-000A959D832C@apple.com> X-Mailer: Apple Mail (2.551) 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, Apr 10, 2003, at 10:40 US/Pacific, Bernard Aboba wrote: > I guess I'm missing how "local.arpa" addresses the spoofing issue. Is > this > because instead of spoofing ietf.org, the attacker now has to spoof > ietf.org.local.arpa? Or is the "security" provided by this due to only > using linklocal name resolution to resolve unqualified names > (foo.local.arpa)? In that case, why wouldn't the same scope restriction > in LLMNR provide equivalent security? Unless I'm mistaken, domains in the search list are appended to unqualified names only if an attempt to resolve the unqualified name fails. A resolver attempting to resolve "ietf.org" would try to resolve "ietf.org." first. Since "ietf.org." doesn't end in "local.arpa." LLMNR would not be used if there is a DNS server configured. Even if someone were respoding to "ietf.org.local.arpa." using LLMNR, it is unlikely they would receive any queries for that name. > "You can make it very clear when LLMNR should be used (LLMNR issue 3), > if the fully qualified name ends in "local.arpa.", use LLMNR." > > Actually, this just adds another "knob to configure" -- the search > list. It is an optional knob. The default behavior could work well enough that you don't have to add local.arpa to the search list unless you really wanted to. You could resolve LLMNR names by appending local.arpa yourself. You can resolve any name without editing or even having a search list. Search lists are just a convenience for people who type a lot of names in a few domains often. > "You also give people a domain they can use a name in." > > Since this is a flat name space, that doesn't address the issue of name > conflicts. There will be as many "bob.local.arpa" hosts as "bob" hosts. Detecting and handling conflicts is not an impossible task. Creating an appropriate user experience to properly handle and notify someone of a conflict can be tricky. > "When I'm at work, my laptop is graejo5.apple.com. > When I'm at home, my laptop is > adsl-64-171-18-123.dsl.sntc01.pacbell.net." > > Depends on whether your host allows DHCP to assign the name or not. If > not, your laptop might remain graejo5.apple.com while a PTR RR query > for > your IP address might return adsl-64-171-18-123.dsl.sntc01.pacbell.net > from the DNS server, and graejo5.apple.com if handled via LLMNR. > > In any case, I'm not sure how "local.arpa" helps this situation. Does > someone at the airport connect to your machine as > "graejo5.apple.com.local.arpa"? "graejo5.local.arpa"? Or some other > name? I don't own the domain apple.com. I can't just pick any name in that domain. That domain is handled by an administrator at Apple. I don't own the dsl.sntc01.pacbell.net domain either. Come to think of it, I don't really own any domain. What name should I pick? How do I go about picking one? How do I make sure that it won't conflict with a name somewhere in the DNS namespace? If the name does exist in the DNS namespace, someone with access to a DNS server may be unable to use LLMNR to find me. If there is a specific domain for LLMNR names, the domain can be used to specify that the name should be resolved using LLMNR. People who don't have authority over any domain will still have a way to use LLMNR. Names in that domain will have certain properties. They won't be globally unique, they will be unique only on the local link. This would give me the freedom to pick any LLMNR name. The protocol can detect a conflict and notify me, at which time I can pick a new unique name or maybe my LLMNR responder could automatically generate a unique name. > "If I meet someone else at an airport or at someone's house where I'm > assigned a NAT address, I would like an easy way to connect to their > machine by name. In both of these cases, I have a configured DNS > server. I have no idea what name the other machine has." > > This doesn't sound like a problem that requires a name resolution > solution > to me. It has been pointed out by Erik Guttman that if what is actually > needed to solve this is to discover the hosts and corresponding > services > on the local link, as well as their attributes, which could include a > "friendly name". That way you don't have to know what the name is -- > which > is a problem whether you're using "local.arpa" or not. Service discovery is ideal but there are many tools that exist today that could make use of LLMNR. For example, my ssh client doesn't know about any service discovery mechanisms. The ability to use a name instead of addresses with an ssh client is very desirable. The same is true of a web browser. Few web browsers support any service discovery mechanisms. The ability to use a name instead of an address when typing in a URL for my buddies machine is very useful. Such a name would continue to work even if the network topology changes, as long as my buddy and I are still on the same local network and our names don't conflict with other names on that network. -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 Fri Apr 11 08:04: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 IAA08813 for ; Fri, 11 Apr 2003 08:04:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193wyO-0005Nh-00 for namedroppers-data@psg.com; Fri, 11 Apr 2003 11:45:36 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 193wyL-0005NN-00 for namedroppers@ops.ietf.org; Fri, 11 Apr 2003 04:45:33 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07352; Fri, 11 Apr 2003 07:42:56 -0400 (EDT) Message-Id: <200304111142.HAA07352@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-16.txt Date: Fri, 11 Apr 2003 07:42:56 -0400 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-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-16.txt Pages : 20 Date : 2003-4-10 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-16.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-16.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-16.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-10155806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-10155806.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 Apr 11 10:57: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 KAA16363 for ; Fri, 11 Apr 2003 10:57:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 193znB-000I3q-00 for namedroppers-data@psg.com; Fri, 11 Apr 2003 14:46:13 +0000 Received: from ops.arin.net ([192.149.252.141]) by psg.com with esmtp (Exim 3.36 #1) id 193zn5-000I18-00 for namedroppers@ops.ietf.org; Fri, 11 Apr 2003 07:46:07 -0700 Received: from [192.149.252.108] ([192.136.136.88]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA22018 for ; Fri, 11 Apr 2003 10:46:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@ops Message-Id: In-Reply-To: <5.1.1.6.2.20030410110749.01713ff8@localhost> References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> Date: Fri, 11 Apr 2003 10:43:38 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Content-Type: text/plain; charset="iso-8859-1" ; 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-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 KAA16363 Is preconfigured really a word? Don't we just mean configured? At sometime, some date, someone wrote: >> > What I do not like is that you loose the ability to verify directly >> > against the configured key and thus leave the KSK out of the apex >> > keyset. This is relevant in the context of Ihrens treshold validation >> > and root signing draft. In the interest of interoperability, is it important whether the resolver has configured either the key or the hash of the key, or even a certificate containing the key? It makes no difference to the on-the-wire DNS protocol. The documents SHOULD NOT dictate the way in which the chain is anchored, just note that there MUST be a way to anchor chains. At 11:20 -0400 4/10/03, Ólafur Guðmundsson wrote: > >I agree with this, operationally life will be much simpler if the KSK >is in the key set. Yeah, but we must allow Randy to continue to say "I invite my competitors to operate this way." I don't understand the need to over specify, why dictate one way of operating when there is no real need to do so? All that we need to do is ensure that there's interoperability and a stable network. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as rare as a fire at a sushi bar... -- to unsubscribe send a message to namedroppers-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 Apr 11 11:56:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18178 for ; Fri, 11 Apr 2003 11:56:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1940kf-000Md1-00 for namedroppers-data@psg.com; Fri, 11 Apr 2003 15:47:41 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 1940kX-000McA-00 for namedroppers@ops.ietf.org; Fri, 11 Apr 2003 08:47:34 -0700 Received: from lapdancer (gorilla.antd.nist.gov [129.6.55.20]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h3BFkxbd011666 for ; Fri, 11 Apr 2003 11:46:59 -0400 (EDT) Message-ID: <002001c3003a$c3226420$14370681@lapdancer> From: "Scott Rose" To: References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Date: Fri, 11 Apr 2003 10:58:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I second the "let's not overspecify". We might pass a point were we give more people ammo to shoot themselves than security risks. Not everyone will want to have both a zone key and a KSK. Those that will have both might not want to put their KSK in the apex. Scott ----- Original Message ----- From: "Edward Lewis" To: Sent: Friday, April 11, 2003 10:43 AM Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? > > > Is preconfigured really a word? Don't we just mean configured? > > At sometime, some date, someone wrote: > >> > What I do not like is that you loose the ability to verify directly > >> > against the configured key and thus leave the KSK out of the apex > >> > keyset. This is relevant in the context of Ihrens treshold validation > >> > and root signing draft. > > In the interest of interoperability, is it important whether the > resolver has configured either the key or the hash of the key, or > even a certificate containing the key? It makes no difference to the > on-the-wire DNS protocol. > > The documents SHOULD NOT dictate the way in which the chain is > anchored, just note that there MUST be a way to anchor chains. > > At 11:20 -0400 4/10/03, Ólafur Guðmundsson wrote: > > > >I agree with this, operationally life will be much simpler if the KSK > >is in the key set. > > Yeah, but we must allow Randy to continue to say "I invite my > competitors to operate this way." I don't understand the need to > over specify, why dictate one way of operating when there is no real > need to do so? All that we need to do is ensure that there's > interoperability and a stable network. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > ...as rare as a fire at a sushi bar... > > -- > to 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 Apr 12 08:59: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 IAA26587 for ; Sat, 12 Apr 2003 08:59:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194KP7-000JAB-00 for namedroppers-data@psg.com; Sat, 12 Apr 2003 12:46:45 +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 194KP0-000J9z-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 05:46:38 -0700 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.12) id 194KOz-000CPm-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 05:46:37 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: From: "Mohammad Awad" To: namedroppers@ops.ietf.org Subject: TXT records, are they alive? Date: Sat, 12 Apr 2003 08:08:50 +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=BAYES_01,FROM_ENDS_IN_NUMS,SEMIFORGED_HOTMAIL_RCVD version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-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. ] Hi all, I'm doing some research that I'll get it dependant on the TXT record in RFC1464 of 1993. I've noticed that there was no further drafts, RFCs, nor comments about that RR. So: 1- Is the TXT record still considered a standard and is it really implemented in nowadays server? 2- if yes, do the servers really respond to queries that necessitate searching inside the RDATA cell of that TXT records? Thank you all Moh Awad _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- to unsubscribe send a message to namedroppers-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 Apr 12 10:48: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 KAA29164 for ; Sat, 12 Apr 2003 10:48:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194MBh-000OUw-00 for namedroppers-data@psg.com; Sat, 12 Apr 2003 14:41:01 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 194MBZ-000OUi-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 07:40:53 -0700 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 h3CEepfc016982; Sat, 12 Apr 2003 10:40:51 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3CEeo26026860; Sat, 12 Apr 2003 10:40:51 -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 h3CEeoFJ022967; Sat, 12 Apr 2003 10:40:50 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id KAA27524; Sat, 12 Apr 2003 10:40:50 -0400 (EDT) To: "Mohammad Awad" Cc: namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: TXT records, are they alive? References: Date: 12 Apr 2003 10:40:50 -0400 In-Reply-To: Message-ID: Lines: 34 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_01,EMAIL_ATTRIBUTION,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Mohammad Awad" writes: > Hi all, > I'm doing some research that I'll get it dependant on the TXT record > in RFC1464 of 1993. I've noticed that there was no further drafts, > RFCs, nor comments about that RR. Why should there be? It works fine, and no problems have been found requiring an update to the draft. > So: > 1- Is the TXT record still considered a standard and is it really > implemented in nowadays server? Uh, most definitely. As far as I can tell just about every DNS Server and resolver around nowadays supports TXT records. Hesiod wouldn't work without it. > 2- if yes, do the servers really respond to queries that necessitate > searching inside the RDATA cell of that TXT records? No -- at least not that I've seen. The servers only look at the name, not the rdata, when looking up a response. This is as it should be in general. > Thank you all > Moh Awad -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 Sat Apr 12 10:51: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 KAA29186 for ; Sat, 12 Apr 2003 10:51:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194MBZ-000OUj-00 for namedroppers-data@psg.com; Sat, 12 Apr 2003 14:40:53 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 194MBR-000OUV-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 07:40:46 -0700 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 h3CEeefc016949; Sat, 12 Apr 2003 10:40:40 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3CEed26026857; Sat, 12 Apr 2003 10:40:39 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3CEedFJ022964; Sat, 12 Apr 2003 10:40:39 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h3CEebut026088; Sat, 12 Apr 2003 10:40:37 -0400 Subject: Re: TXT records, are they alive? From: Greg Hudson To: Mohammad Awad Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1050158436.30908.38.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 12 Apr 2003 10:40:37 -0400 X-Spam-Status: No, hits=-36.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_XIMIAN,X_NJABL_OPEN_PROXY autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-04-12 at 02:08, Mohammad Awad wrote: > 1- Is the TXT record still considered a standard and is it really > implemented in nowadays server? Yup. They've worked fine in BIND for a while. (On the server side, there's been some issue about how much control a zone file has over the boundaries between the text labels. I don't know the status of that.) > 2- if yes, do the servers really respond to queries that necessitate > searching inside the RDATA cell of that TXT records? I'm not quite sure what you're asking here. At MIT, we use them for Hesiod records, which isn't necessarily the cleanest use of the DNS, but it works well. Dig for something like ghudson.passwd.ns.athena.mit.edu txt for an example. -- to unsubscribe send a message to namedroppers-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 Apr 12 12:20: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 MAA00073 for ; Sat, 12 Apr 2003 12:20:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194NeD-0003In-00 for namedroppers-data@psg.com; Sat, 12 Apr 2003 16:14:33 +0000 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 194Ndy-0003Gb-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 09:14:19 -0700 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/pk+ro20010720) with ESMTP id h3CGEHQ01675; Sat, 12 Apr 2003 18:14:17 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.6+Sun/8.9.1) with SMTP id h3CGEGb10453; Sat, 12 Apr 2003 18:14:17 +0200 (MEST) Message-Id: <200304121614.h3CGEGb10453@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: "Mohammad Awad" Cc: namedroppers@ops.ietf.org Subject: Re: TXT records, are they alive? In-reply-to: Your message of "Sat, 12 Apr 2003 08:08:50 +0200." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Sat, 12 Apr 2003 18:14:16 +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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm doing some research that I'll get it dependant on the TXT record in > RFC1464 of 1993. I've noticed that there was no further drafts, RFCs, nor > comments about that RR. The TXT RR was not introduced by RFC 1464. It's only the idea of internal structure (tag/value) that was promoted by this document. > 1- Is the TXT record still considered a standard and is it really > implemented in nowadays server? Since the TXT RR was part of the initial DNS RFCs it's part of the DNS standard. RFC 1464 however has "Experimental" status. You can find out the difference in BCP 9/RFC2026. Not only do servers implement the TXT RRs, but also resolvers support it. TXT RRs are not really in widespread use today unless for locally focused purposes (e.g. hesiod). Within "DE", a TLD with > 6 million names and more than 4.5 million zones, there are roughly 150000 TXT RRs and only some in the low hundreds use the RFC 1464 notation, mostly to ``advertise'' ethernet addresses. Some others are used to support the RP RR defined in RFC 1183. > 2- if yes, do the servers really respond to queries that necessitate > searching inside the RDATA cell of that TXT records? RFC 1464 did not suggest specific server behaviour. Instead, the resolver or some function between application and resolver would have to extract the information based on the selected attribute. There's no other way because there is currently no query type or opcode which could take into account partially available RDATA (i.e. return all A RRs for foo.example.com with '10' in the first octet or return all TXT RRs for bar.example.com with 'location=' at the beginning of RDATA. And while it's theoretically possible to define such an opcode, it would be in conflict with both RFC 2181, which mandates that RRSets always be dealt with as a complete set and DNSSEC, which can only sign complete RRSets. -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 Apr 12 13:51: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 NAA01339 for ; Sat, 12 Apr 2003 13:51:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194Oy4-00084f-00 for namedroppers-data@psg.com; Sat, 12 Apr 2003 17:39:08 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 194Oy2-00084P-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 10:39:06 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DA12F18ED for ; Sat, 12 Apr 2003 13:38:33 -0400 (EDT) Date: Sat, 12 Apr 2003 13:38:33 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: TXT records, are they alive? In-Reply-To: <1050158436.30908.38.camel@error-messages.mit.edu> References: <1050158436.30908.38.camel@error-messages.mit.edu> 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: <20030412173833.DA12F18ED@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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12 Apr 2003 10:40:37 -0400, Greg Hudson wrote: > > On Sat, 2003-04-12 at 02:08, Mohammad Awad wrote: > > 1- Is the TXT record still considered a standard and is it really > > implemented in nowadays server? > > Yup. They've worked fine in BIND for a while. (On the server side, > there's been some issue about how much control a zone file has over the > boundaries between the text labels. I don't know the status of that.) The original BIND 4.x implementation of TXT RRs treated the entire RDATA as one big string. If memory serves, this was fixed circa 1996. -- to unsubscribe send a message to namedroppers-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 Apr 12 14:27: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 OAA01650 for ; Sat, 12 Apr 2003 14:27:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194PgE-000As7-00 for namedroppers-data@psg.com; Sat, 12 Apr 2003 18:24:46 +0000 Received: from [2001:4f8:3:bb:2e0:81ff:fe23:a062] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 194PgC-000Ari-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 11:24:44 -0700 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9E0BE13953 for ; Sat, 12 Apr 2003 18:24:31 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: TXT records, are they alive? In-Reply-To: Message from Rob Austein of "Sat, 12 Apr 2003 13:38:33 -0400." <20030412173833.DA12F18ED@thrintun.hactrn.net> X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 12 Apr 2003 18:24:31 +0000 Message-Id: <20030412182431.9E0BE13953@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.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Yup. They've worked fine in BIND for a while. (On the server side, > > there's been some issue about how much control a zone file has over the > > boundaries between the text labels. I don't know the status of that.) > > The original BIND 4.x implementation of TXT RRs treated the entire > RDATA as one big string. If memory serves, this was fixed circa 1996. yes. both when parsing zone files and when handling it in cache, bind4 before 4.9.3b17 failed to deal with the inner segmentation of txt rdata's. this meant an incompatibility when it was fixed, since FOO IN TXT abc def used to create rdlen 8 rdata \07 a b c \020 d e f and now it creates rdlen 8 rdata \03 a b c \03 d e f to get the prior behaviour, quotes are needed (per the standard), i.e., FOO IN TXT "abc def" -- to unsubscribe send a message to namedroppers-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 Apr 12 15:26: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 PAA03488 for ; Sat, 12 Apr 2003 15:26:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194QTp-000EJ7-00 for namedroppers-data@psg.com; Sat, 12 Apr 2003 19:16:01 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 194QTm-000EIn-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 12:15:58 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id PAA22395 for ; Sat, 12 Apr 2003 15:10:17 -0400 Date: Sat, 12 Apr 2003 15:10:28 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: namedroppers@ops.ietf.org Subject: Re: TXT records, are they alive? In-Reply-To: <20030412173833.DA12F18ED@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-29.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Supposedly this is a protocol list, not a bind list. The standards are not defined by bind behavior. TXT records certainly are current standard, and should be implemented in a standards-compliant server. I note that AFS, DCE, CODA, and other applications use TXT records. --Dean On Sat, 12 Apr 2003, Rob Austein wrote: > At 12 Apr 2003 10:40:37 -0400, Greg Hudson wrote: > > > > On Sat, 2003-04-12 at 02:08, Mohammad Awad wrote: > > > 1- Is the TXT record still considered a standard and is it really > > > implemented in nowadays server? > > > > Yup. They've worked fine in BIND for a while. (On the server side, > > there's been some issue about how much control a zone file has over the > > boundaries between the text labels. I don't know the status of that.) > > The original BIND 4.x implementation of TXT RRs treated the entire > RDATA as one big string. If memory serves, this was fixed circa 1996. -- to unsubscribe send a message to namedroppers-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 Apr 12 15:54: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 PAA03905 for ; Sat, 12 Apr 2003 15:54:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194Qzn-000GYX-00 for namedroppers-data@psg.com; Sat, 12 Apr 2003 19:49:03 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 194Qzl-000GYH-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 12:49:01 -0700 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 h3CJmbVA001524; Sat, 12 Apr 2003 15:48:37 -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 h3CJmZdR007731; Sat, 12 Apr 2003 15:48:37 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3CJmXU8011007; Sat, 12 Apr 2003 15:48:34 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h3CJmXme023344; Sat, 12 Apr 2003 15:48:33 -0400 Subject: Re: TXT records, are they alive? From: Greg Hudson To: Dean Anderson Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1050176912.30908.51.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 12 Apr 2003 15:48:33 -0400 X-Spam-Status: No, hits=-36.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_XIMIAN,X_NJABL_OPEN_PROXY autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-04-12 at 15:10, Dean Anderson wrote: > Supposedly this is a protocol list, not a bind list. The standards are > not defined by bind behavior. Of course not, but it's information relevant to the question at hand. (In particular, it's useful to know that TXT records passing through an old BIND cache may have their boundaries rewritten; depending on the number of such caches out there, that might be an obstacle to using RFC 1464 on a wide scale.) > TXT records certainly are current standard, and should be implemented in a > standards-compliant server. I note that AFS, DCE, CODA, and other > applications use TXT records. This statement doesn't agree with my understanding, although it's tough to prove a negative. AFS uses AFSDB records, and does not make any use of TXT records that I can determine. Coda does not appear to use either AFSDB or TXT from a search of the current source code. I don't know about DCE, but I imagine it would use the DCE registry for anything you might consider using TXT records for. -- to unsubscribe send a message to namedroppers-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 Apr 12 17:58: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 RAA05486 for ; Sat, 12 Apr 2003 17:58:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 194Soz-000OyO-00 for namedroppers-data@psg.com; Sat, 12 Apr 2003 21:46:01 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 194Sox-000OyB-00 for namedroppers@ops.ietf.org; Sat, 12 Apr 2003 14:45:59 -0700 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id RAA17403; Sat, 12 Apr 2003 17:41:03 -0400 Date: Sat, 12 Apr 2003 17:41:13 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Greg Hudson cc: namedroppers@ops.ietf.org Subject: Re: TXT records, are they alive? In-Reply-To: <1050176912.30908.51.camel@error-messages.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 12 Apr 2003, Greg Hudson wrote: > On Sat, 2003-04-12 at 15:10, Dean Anderson wrote: > > Supposedly this is a protocol list, not a bind list. The standards are > > not defined by bind behavior. > > Of course not, but it's information relevant to the question at hand. > (In particular, it's useful to know that TXT records passing through an > old BIND cache may have their boundaries rewritten; depending on the > number of such caches out there, that might be an obstacle to using RFC > 1464 on a wide scale.) Sounds like an operational problem to me. Since these old versions of bind have pretty severe security problems, it seems unlikely that there are enough around to be concerned about. > > TXT records certainly are current standard, and should be implemented in a > > standards-compliant server. I note that AFS, DCE, CODA, and other > > applications use TXT records. > > This statement doesn't agree with my understanding, although it's tough > to prove a negative. AFS uses AFSDB records, and does not make any use > of TXT records that I can determine. Coda does not appear to use either > AFSDB or TXT from a search of the current source code. I don't know > about DCE, but I imagine it would use the DCE registry for anything you > might consider using TXT records for. I think OpenAFS has some differences to transarc AFS. Now that you mention it, TXT was deprecated after the AFSDB record type was approved. Most of my afs administration was in the old days. I don't have the transarc source online anymore, due to disk failure on the old ri.osf.org cell. DCE uses a TXT record to locate other cells. It doesn't have anything similar to the old CellServDB file. The registry is used by the cell itself to find RPC endpoints. I have old sets of DCE and AFS manuals in the office. I'll be happy to fax you a copy of the relevant pages on monday, if you want. --Dean -- to unsubscribe send a message to namedroppers-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 Apr 14 15:50: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 PAA19821 for ; Mon, 14 Apr 2003 15:50:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1959gG-000BCn-00 for namedroppers-data@psg.com; Mon, 14 Apr 2003 19:31:52 +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 1959fu-000BAq-00 for namedroppers@ops.ietf.org; Mon, 14 Apr 2003 19:31:30 +0000 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id E073710FD34; Mon, 14 Apr 2003 15:31:29 -0400 (EDT) Date: Mon, 14 Apr 2003 15:31:29 -0400 From: Matt Larson To: namedroppers@ops.ietf.org Subject: Last call results? Message-ID: <20030414193129.GS7491@chinook.rgy.netsol.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="jZ6LB7VX2Q2qroxd" Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-10.9 required=5.0 tests=BAYES_10,OPT_IN,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 --jZ6LB7VX2Q2qroxd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Could the co-chairs please make a statement regarding the last calls that ended on 31 March? ----- Forwarded message from Randy Bush ----- =46rom: Randy Bush Subject: extend last calls in process To: namedroppers Date: Thu, 20 Mar 2003 08:34:18 -0800 three wg last calls were announced on 2003.03.12 opt-in threats ksk flag some folk are uncomfortable that this iesg week is in the middle of the last call period. so let's extend these three last calls one week to end on 2003.03.31. 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: ----- End forwarded message ----- -- Matt Larson VeriSign Global Registry Services --jZ6LB7VX2Q2qroxd 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwNDE0MTkzMTI5WjAjBgkqhkiG 9w0BCQQxFgQUhpBZmEn6lFvwemZUsigKQn4RvNMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYAbCsZV7c2y0wMqw9VdZfYERAgDyUHsGogg7JGxP9cw AdVg08RMDyf/d4LkAtAW348M79RgJYu5qWOKFOqYiEbs45F+NNYnyZM4ETiUNRzqoHiBTgRn a35oIa6Qerj5TXjnwOrnPTr/iK5JBn3cNkK/fov9121PiofgQy+Z0taPeQ== --jZ6LB7VX2Q2qroxd-- -- to unsubscribe send a message to namedroppers-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 Apr 14 16:01: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 QAA20081 for ; Mon, 14 Apr 2003 16:01:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195A1s-000CXO-00 for namedroppers-data@psg.com; Mon, 14 Apr 2003 19:54:12 +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 195A1U-000CUY-00 for namedroppers@ops.ietf.org; Mon, 14 Apr 2003 19:53:48 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) with ESMTP id h3EJrUKA013716; Mon, 14 Apr 2003 21:53:30 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) id h3EJrTCX013713; Mon, 14 Apr 2003 21:53:29 +0200 Date: Mon, 14 Apr 2003 21:53:29 +0200 From: Miek Gieben To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Message-ID: <20030414195329.GB13422@atoom.net> Mail-Followup-To: Edward Lewis , namedroppers@ops.ietf.org References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,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 [On 11 Apr, @16:43, Edward wrote in "Re: DNSSECbis Q-07: Discuss pr ..."] > > > Is preconfigured really a word? Don't we just mean configured? > > At sometime, some date, someone wrote: > >> > What I do not like is that you loose the ability to verify directly > >> > against the configured key and thus leave the KSK out of the apex > >> > keyset. This is relevant in the context of Ihrens treshold validation > >> > and root signing draft. > > In the interest of interoperability, is it important whether the > resolver has configured either the key or the hash of the key, or > even a certificate containing the key? It makes no difference to the > on-the-wire DNS protocol. > > The documents SHOULD NOT dictate the way in which the chain is > anchored, just note that there MUST be a way to anchor chains. yes, but this was/is somewhat related to the issue of having a key in the zone. We agreed(?) that a zone MUST have a key in it to be considered secure. If you say DS records can be used as a starting point you must also say something about the use of a KSK in the zone. If there is no KSK there the DS record can not be compared with it and your stuck. If one only says there MUST be way to anchor chains, you leave this in the open. I don't feel this is a overspecification, grtz Miek -- to unsubscribe send a message to namedroppers-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 Apr 14 16:36: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 QAA20923 for ; Mon, 14 Apr 2003 16:36:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195Acr-000Ewx-00 for namedroppers-data@psg.com; Mon, 14 Apr 2003 20:32:25 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 195AcV-000EwH-00 for namedroppers@ops.ietf.org; Mon, 14 Apr 2003 20:32:03 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 856243D8; Mon, 14 Apr 2003 16:32:00 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 005C73CD; Mon, 14 Apr 2003 16:32:00 -0400 (EDT) Received: from [192.136.136.41] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 184852; Mon, 14 Apr 2003 16:22:31 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <20030414195329.GB13422@atoom.net> References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> Date: Mon, 14 Apr 2003 16:32:05 -0400 To: Miek Gieben From: Edward Lewis Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? 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 21:53 +0200 4/14/03, Miek Gieben wrote: >[On 11 Apr, @16:43, Edward wrote in "Re: DNSSECbis Q-07: Discuss pr ..."] >> >> The documents SHOULD NOT dictate the way in which the chain is >> anchored, just note that there MUST be a way to anchor chains. > >yes, but this was/is somewhat related to the issue of having a key in >the zone. We agreed(?) that a zone MUST have a key in it to be considered >secure. Somewhat, but not quite, and I don't think this is related in this case. ;) What data structure is used to hold the material a resolver considers absolutely trustworthy is what's at stake here. I don't see the reason to specify the form of the data structure (i.e./e.g., key, hash, or certificate). Of course, what is in the resolver's cache of absolutely trustworthy material has to relate to what is published in a zone - the KSK and/or ZSK. But that's how you build the chain - what kinds of links are allowed and how the links are joined. The data structure in the resolver is just the anchoring of the chain. It only says how the first link in the chain is learned and accepted as "verifiably trustworthy" to the resolver. >If you say DS records can be used as a starting point you must also say >something about the use of a KSK in the zone. If there is no KSK there the DS >record can not be compared with it and your stuck. Note that above I referred to key, hash, or certificate. These three could be configured in the resolver using syntax equivalent to KEY, DS, or CERT RR's. The three could also use other forms too, to the resolver it is not important as the configuration of the resolver is not subject to a protocol transfer. (It's an "implementation detail.") >If one only says there MUST be way to anchor chains, you leave this in the >open. I don't feel this is a overspecification, Yeah - -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 15 04:30: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 EAA18989 for ; Tue, 15 Apr 2003 04:30:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195LeS-000OIC-00 for namedroppers-data@psg.com; Tue, 15 Apr 2003 08:18:48 +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 195Le5-000OHo-00 for namedroppers@ops.ietf.org; Tue, 15 Apr 2003 08:18:26 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) with ESMTP id h3F8I6CR031936; Tue, 15 Apr 2003 10:18:07 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) id h3F8I6tu031935; Tue, 15 Apr 2003 10:18:06 +0200 Date: Tue, 15 Apr 2003 10:18:06 +0200 From: Miek Gieben To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Message-ID: <20030415081806.GA31527@atoom.net> Mail-Followup-To: Edward Lewis , namedroppers@ops.ietf.org References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,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 [On 14 Apr, @22:32, Edward wrote in "Re: DNSSECbis Q-07: Discuss pr ..."] > > Note that above I referred to key, hash, or certificate. These three > could be configured in the resolver using syntax equivalent to KEY, > DS, or CERT RR's. The three could also use other forms too, to the > resolver it is not important as the configuration of the resolver is > not subject to a protocol transfer. (It's an "implementation > detail.") ok, I can live with that. But what would you then like to see in the DNSSEC Protocol Modifications draft, for instance section 5 starts like this: 5. Authenticating DNS Responses In order to use DNSSEC RRs for authentication, a security-aware resolver requires preconfigured knowledge of at least one authenticated KEY RR. I mean it is already in there... grtz Miek -- to unsubscribe send a message to namedroppers-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 Apr 15 10:23: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 KAA29252 for ; Tue, 15 Apr 2003 10:23:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195R9u-000BiI-00 for namedroppers-data@psg.com; Tue, 15 Apr 2003 14:11:38 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 195R9X-000Bhp-00 for namedroppers@ops.ietf.org; Tue, 15 Apr 2003 14:11:15 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 1265F350; Tue, 15 Apr 2003 10:11:15 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 829B1345; Tue, 15 Apr 2003 10:11:14 -0400 (EDT) Received: from [192.136.136.103] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 185510; Tue, 15 Apr 2003 10:01:43 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <20030415081806.GA31527@atoom.net> References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> <20030415081806.GA31527@atoom.net> Date: Tue, 15 Apr 2003 10:11:07 -0400 To: Miek Gieben From: Edward Lewis Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? 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 10:18 +0200 4/15/03, Miek Gieben wrote: >5. Authenticating DNS Responses > > In order to use DNSSEC RRs for authentication, a security-aware > resolver requires preconfigured knowledge of at least one > authenticated KEY RR. > >I mean it is already in there... The spirit is right, but I two issues with this. One issue is from a wording point of view. The other is from a specification (requirements) point of view. If I were to write the above, I would say: For a security-aware resolver to be able to authenticate and verify the integrity of the data received through the use of the DNSSEC RR's, the resolver needs to have configured information from which to anchor the chain of trust. I assume that "chain of trust" (or similar phrase) is defined elsewhere. The reason I dropped the KEY RR is that it is possible that a resolver would be able to use the configured data to verify a SIG RR without consulting any KEY RR(s). E.g., a CERT RR might be in the resolver's configuration data - which might identify the subject public key as the key also known as the "signer" and "footprint" in the SIG RR fields. As far as a requirement: A security aware resolver MUST be capable of configuring security information that will enable the anchoring of a chain of trust. An implementation SHOULD NOT place any limits on the number of security anchors other than that necessitated by resource (e.g., memory) limitations. An implementation MAY restrict the security anchors to one form, e.g., DS RR's, or MAY accept non-DNS data structures, e.g., pkcs #? X.509 certificates. (The examples I've chosen are quite arbitrary. I mean not to slight those who favor KEY RR or OpenPGP or whatever.) As a document editor, I would include both passages - prose to explain and requirements to specify. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 15 11:59: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 LAA02395 for ; Tue, 15 Apr 2003 11:59:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195SjI-000EhI-00 for namedroppers-data@psg.com; Tue, 15 Apr 2003 15:52:16 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 195SiV-000EgF-00 for namedroppers@ops.ietf.org; Tue, 15 Apr 2003 15:51:28 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3FFpAft029430; Tue, 15 Apr 2003 11:51:10 -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 h3FFp7IS025495; Tue, 15 Apr 2003 11:51:07 -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 h3FFp7U8004039; Tue, 15 Apr 2003 11:51:07 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id LAA05537; Tue, 15 Apr 2003 11:51:06 -0400 (EDT) To: Edward Lewis Cc: Miek Gieben , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> Date: 15 Apr 2003 11:51:06 -0400 In-Reply-To: Message-ID: Lines: 37 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.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,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: > What data structure is used to hold the material a resolver considers > absolutely trustworthy is what's at stake here. I don't see the > reason to specify the form of the data structure (i.e./e.g., key, > hash, or certificate). Actually, I do. Zone A running servers from vendor A create the zone information and want to supply an out-of-band method to their known clients to authenticate their zone (such as a PGP-signed data object). Clients of Zone A are running resolvers from vendors A, B, C, and D and all need to be able to plug in the PGP-signed object (after the PGP signature has been verified and removed) into their resolver's "secure entry point database". We need a standard way to doing this in order to solve this particular scenario (and frankly I think this is going to be the common usage scenario). > Note that above I referred to key, hash, or certificate. These three > could be configured in the resolver using syntax equivalent to KEY, > DS, or CERT RR's. The three could also use other forms too, to the > resolver it is not important as the configuration of the resolver is > not subject to a protocol transfer. (It's an "implementation detail.") I think I just explained why it is more than just an implementation detail. Certainly how it is stored _in core_ is an implementation detail, but how it is configured externally needs to have an equivalent on-the-wire format in order for the zone operators to send the key material to the clients in a common format. -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 Tue Apr 15 13:13: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 NAA04430 for ; Tue, 15 Apr 2003 13:13:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195TsM-000HUZ-00 for namedroppers-data@psg.com; Tue, 15 Apr 2003 17:05:42 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 195Trx-000HTa-00 for namedroppers@ops.ietf.org; Tue, 15 Apr 2003 17:05:17 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id AA50C32F; Tue, 15 Apr 2003 13:05:16 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 1C42030D; Tue, 15 Apr 2003 13:05:16 -0400 (EDT) Received: from [192.136.136.103] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 185713; Tue, 15 Apr 2003 12:55:44 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> Date: Tue, 15 Apr 2003 13:05:25 -0400 To: Derek Atkins From: Edward Lewis Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Cc: Edward Lewis , Miek Gieben , namedroppers@ops.ietf.org 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 11:51 -0400 4/15/03, Derek Atkins wrote: >information and want to supply an out-of-band method to their known "Out-of-band to DNS." - right? DNSEXT is extensions to DNS, right? >and all need to be able to plug in the PGP-signed object (after the >PGP signature has been verified and removed) into their resolver's >"secure entry point database". This sounds like a security data management protocol. >We need a standard way to doing this in order to solve this particular >scenario (and frankly I think this is going to be the common usage >scenario). I strongly disagree - especially if "we" is the DNSEXT WG. Certainly a resolver could support PGP-objects in some standard (whatever that means) specified way and also support X.509 certificates according to some other standard specified way. DNSSEC shouldn't restrict this choice by defining one of the other. I grok that you want to have an easy way to manage security parameters cross-platform. But "the" mechanism to do this is best solved in a constituency that is more interested in security operations. (Cue the arguments behind IPSECKEY.) DNS folks need not reinvent this - I'm sure other protocol WGs have studied this. What about defining a new DNS security MIB and using SNMPv4? (That's one approach.) >I think I just explained why it is more than just an implementation >detail. Certainly how it is stored _in core_ is an implementation >detail, but how it is configured externally needs to have an >equivalent on-the-wire format in order for the zone operators to send >the key material to the clients in a common format. To me as a DNS protocol weenie, how you type in the security data is just an implementation detail. E.g., I don't care a wit about whether your name server uses ASCII zone files and loads them into memory, pre-calculates all possible answers based on authoritative data, or even uses a mySQL back end - it matters not to the wire protocol. The DNS specifications need to be fair and unbiased, no leaning towards any one way to do something - and there are many ways we could go about configuring security meta-data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 15 14:12: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 OAA05849 for ; Tue, 15 Apr 2003 14:12:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195UnN-000JvK-00 for namedroppers-data@psg.com; Tue, 15 Apr 2003 18:04:37 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 195Umj-000Jst-00 for namedroppers@ops.ietf.org; Tue, 15 Apr 2003 18:03:57 +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 h3FI3g3o011408; Tue, 15 Apr 2003 14:03:42 -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 h3FI3YkP014632; Tue, 15 Apr 2003 14:03:39 -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 h3FI0GFJ021606; Tue, 15 Apr 2003 14:00:17 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id OAA05764; Tue, 15 Apr 2003 14:00:16 -0400 (EDT) To: Edward Lewis Cc: Miek Gieben , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> Date: 15 Apr 2003 14:00:16 -0400 In-Reply-To: Message-ID: Lines: 81 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.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,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 Ed, I think you misunderstood what I was saying... Edward Lewis writes: > This sounds like a security data management protocol. And as such DNSEXT cannot ignore it. You cannot just toss it over the fence -- this is exactly why each and every RFC is required to have a Security Considerations section -- everyone needs to think about security. > >We need a standard way to doing this in order to solve this particular > >scenario (and frankly I think this is going to be the common usage > >scenario). > > I strongly disagree - especially if "we" is the DNSEXT WG. > > Certainly a resolver could support PGP-objects in some standard > (whatever that means) specified way and also support X.509 > certificates according to some other standard specified way. DNSSEC > shouldn't restrict this choice by defining one of the other. You clearly misunderstood what I meant, and nowhere did I state OR imply that DNS software needs to implement PGP objects. I uses PGP as an example, and I'm sorry if that confused you. Just to make sure it's absolutely clear, let me enumerate a bunch of ways this could be done (and note to the pedantic that this list is NOT exhaustive): HTTPS GET PGP protected file S/MIME protected file CD-ROM you get from your local IT Admin Barcode printed in the NYT SNMP MIB (just to use your example) Yes, you are absolutely correct that we cannot, indeed MUST NOT, mandate any particular _method_ of transmission of data. However, that does NOT imply that we should not standardize on the message being transmitted and protected through all these methods. To repeat myself, I'm specifically talking about the data format, not the transmission and/or protection method. In short: we need a way so to create a secure-entry-point data object that can be read by any implementation. This data object can be protected by PGP, S/MIME, or Telepathy for all I care... But I want a data object that can be read by all resolvers (just like we have a zone-file format that can be read by all servers). > >I think I just explained why it is more than just an implementation > >detail. Certainly how it is stored _in core_ is an implementation > >detail, but how it is configured externally needs to have an > >equivalent on-the-wire format in order for the zone operators to send > >the key material to the clients in a common format. > > To me as a DNS protocol weenie, how you type in the security data is > just an implementation detail. E.g., I don't care a wit about whether > your name server uses ASCII zone files and loads them into memory, > pre-calculates all possible answers based on authoritative data, or > even uses a mySQL back end - it matters not to the wire protocol. The > DNS specifications need to be fair and unbiased, no leaning towards > any one way to do something - and there are many ways we could go > about configuring security meta-data. Then explain why the DNS Protocol Specification talks about zone file formats for each of the DNS Resource Records. We already standardize a file format for zones. Why be hypocritical and claim that defining zone-file formats is reasonable but defining the file format for secure entry points is not reasonable? Note that, to make it clear, all I'm saying is that we should standardize the secure entry point data; I am _NOT_ suggesting that we standardize the METHOD of transmission or protecting said data. I think that is completely within the purview of DNSEXT, just as it it within our purview to define the zone file format. -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 Tue Apr 15 14:52: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 OAA07074 for ; Tue, 15 Apr 2003 14:52:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195VQW-000M7v-00 for namedroppers-data@psg.com; Tue, 15 Apr 2003 18:45:04 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 195VQ8-000M6K-00 for namedroppers@ops.ietf.org; Tue, 15 Apr 2003 18:44:40 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 847713B2; Tue, 15 Apr 2003 14:44:39 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id CF0CC334; Tue, 15 Apr 2003 14:44:37 -0400 (EDT) Received: from [192.136.136.103] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 185848; Tue, 15 Apr 2003 14:35:06 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> Date: Tue, 15 Apr 2003 14:44:45 -0400 To: Derek Atkins From: Edward Lewis Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Cc: Edward Lewis , Miek Gieben , 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 14:00 -0400 4/15/03, Derek Atkins wrote: >And as such DNSEXT cannot ignore it. You cannot just toss it over the >fence -- this is exactly why each and every RFC is required to have a >Security Considerations section -- everyone needs to think about >security. Ignore it, no. But the DNS specification ought not to overstep its bounds. If we were to try to bloat the feature set in the DNSSEC protocol this way, we will incur more delay in trying to get the documents back to Proposed Standard - if we do the job right. (As in research and discuss these points and then see how these points impact all the previously agreed-to points already in the document.) Note that TSIG and SIG(0) aren't in the DNSSEC documents either. They are part of the problem, but are not integral to DNSSEC. How the anchors are implemented shouldn't be either. DNSSEC just assumes that resolvers have anchors (hence the MUST in my previous message). >Yes, you are absolutely correct that we cannot, indeed MUST NOT, >mandate any particular _method_ of transmission of data. However, >that does NOT imply that we should not standardize on the message >being transmitted and protected through all these methods. You have me at a loss here. Completely. Are you saying that we shouldn't agree on whether we use TCP or UDP so long as we use X.509? (All examples are arbitrary.) >Telepathy for all I care... But I want a data object that can be read >by all resolvers (just like we have a zone-file format that can be >read by all servers). It would be nice if all the world worked one way. But there's a cost to achieving it. The reason I don't want to tie down one method now is that I am not aware of a solution that is the best now and will be the best in two years. If you insist on trying to find that solution, I for one will not participate in the debate - because that would be all that I would be doing, not gaining hands on experience, refining what I think is the situation to solve for. Can "all" name servers read the BIND file format? I didn't think it was required. >a file format for zones. Why be hypocritical and claim that defining >zone-file formats is reasonable but defining the file format for >secure entry points is not reasonable? The hypocrisy here is not mine. I have frequently balked at textual definitions being part of the standard. (Ask the chairs.) On the other hand, it is good to have textual conventions for the sake of documentation (and that's all). A name server implementation would not be discounted by me if it did not conform to the text representations. >Note that, to make it clear, all I'm saying is that we should >standardize the secure entry point data; I am _NOT_ suggesting that we >standardize the METHOD of transmission or protecting said data. I >think that is completely within the purview of DNSEXT, just as it it >within our purview to define the zone file format. Well, as you can see, I don't support defining textual conventions for DNS, so I don't agree with this last portion of your message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 15 15:16: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 PAA08564 for ; Tue, 15 Apr 2003 15:16:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195Vk7-000NJq-00 for namedroppers-data@psg.com; Tue, 15 Apr 2003 19:05:19 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 195Vjk-000NGG-00 for namedroppers@ops.ietf.org; Tue, 15 Apr 2003 19:04:56 +0000 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3FJ4g0n012527; Tue, 15 Apr 2003 15:04:42 -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 h3FJ4fiv003657; Tue, 15 Apr 2003 15:04:41 -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 h3FJ4cU8010758; Tue, 15 Apr 2003 15:04:41 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id PAA05868; Tue, 15 Apr 2003 15:04:38 -0400 (EDT) To: Edward Lewis Cc: Miek Gieben , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> Date: 15 Apr 2003 15:04:38 -0400 In-Reply-To: Message-ID: Lines: 53 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.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,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: > >Yes, you are absolutely correct that we cannot, indeed MUST NOT, > >mandate any particular _method_ of transmission of data. However, > >that does NOT imply that we should not standardize on the message > >being transmitted and protected through all these methods. > > You have me at a loss here. Completely. Are you saying that we > shouldn't agree on whether we use TCP or UDP so long as we use X.509? > (All examples are arbitrary.) Sort of. I'm saying that "we don't need to agree on whether we use TCP, UDP, HTTPS, PGP-over-email, or unencrypted/unsigned CDRoms, so long as we agree that we should use the KEY or DS format records for the secure entry point." We don't need to agree on how the SEP data gets to the resolver. We don't need to agree on how the SEP data is authenticated by the end user (or the resolver). However, we should agree on what the SEP data should be that is fed to the resolver. Note that I see no reason to actually use X.509 certs (or PGP Certs, or indeed ANY certificate) for the SEP data. The nice thing about pre-configured SEPs is that you don't need to verify them too -- they are trusted. This means can use raw keys just as easily as you can use self-signed certificates. Using anything but a self-signed certificate is just silly, because it implies that you _don't_ have the entry point -- because you need the certificate signer to verify the certificate.... Personally, I recommend we standardize on "KEY", and "DS" (and maybe CERT) record formats for the SEP data. Just like many resolvers use a root.hints file which contain a set of NS and A records; we can create an SEP.hints file which contain a set of KEY, DS, and maybe CERT records (although I'm not sure how the CERT record would/could be used). Then we could just use the standard master-file format and be done with it. Note that I don't say how the resolver gets this hint file, how how it is verified. I'm just talking about the contents. > Can "all" name servers read the BIND file format? I didn't think it > was required. RFC 1035 is unclear -- it's before the use of MUST/SHOULD/MAY -- but my interpretation is that they MUST understand the master file format but they may choose not to use it. I haven't followed up with the updated RFCs to see if that's made more clear. -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 Tue Apr 15 15:41: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 PAA09336 for ; Tue, 15 Apr 2003 15:41:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195W8p-000OVx-00 for namedroppers-data@psg.com; Tue, 15 Apr 2003 19:30:51 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 195W8S-000OVK-00 for namedroppers@ops.ietf.org; Tue, 15 Apr 2003 19:30:29 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 5AC583BA; Tue, 15 Apr 2003 15:30:28 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id C56303A4; Tue, 15 Apr 2003 15:30:27 -0400 (EDT) Received: from [192.136.136.103] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 185940; Tue, 15 Apr 2003 15:20:55 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta (Unverified) Message-Id: In-Reply-To: References: <20030410103812.53189a5f.olaf@ripe.net> <20030331132915.GA2912@atoom.net> <20030409015556.6CF3B18ED@thrintun.hactrn.net> <20030409030333.E8E6518ED@thrintun.hactrn.net> <20030409200750.440EC18E6@thrintun.hactrn.net> <20030410103812.53189a5f.olaf@ripe.net> <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> Date: Tue, 15 Apr 2003 15:30:37 -0400 To: Derek Atkins From: Edward Lewis Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Cc: Edward Lewis , Miek Gieben , namedroppers@ops.ietf.org 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 15:04 -0400 4/15/03, Derek Atkins wrote: >Sort of. I'm saying that "we don't need to agree on whether we use >TCP, UDP, HTTPS, PGP-over-email, or unencrypted/unsigned CDRoms, so >long as we agree that we should use the KEY or DS format records for >the secure entry point." We don't need to agree on how the SEP data >gets to the resolver. What do you mean by SEP data? What do you mean "gets to" the resolver? My assumption is that DNSSEC is about making the world safe for the resolver. It needs security anchor data to do this - that's a requirement. How the anchor data gets there and in what form is out of scope for the DNSSEC document. I think that trying to specify the how a resolver's configuration is done is on par with that of a name server - we don't specify the "named.conf" file. >Personally, I recommend we standardize on "KEY", and "DS" (and maybe >CERT) record formats for the SEP data. Just like many resolvers use a Would an resolver implementation choosing to use X.509 certificates be non-interoperable with the implementation you build to your suggestion? >used). Then we could just use the standard master-file format and be >done with it. Have you read Johan Ihren's drafts? Do you mean to say that the DNSOP WG gets to have no say in the matter? You seem to want to restrict operational choices by over-specifying the underlying protocol. >RFC 1035 is unclear -- it's before the use of MUST/SHOULD/MAY -- but >my interpretation is that they MUST understand the master file format >but they may choose not to use it. I haven't followed up with the >updated RFCs to see if that's made more clear. What do you mean by "understand?" (Upon what section of 1035 do you base your interpretation?) BIND parses it's master file format and stores data accordingly. Why would I implement (such) a parser if my server never read text files? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 15 23:21: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 XAA21206 for ; Tue, 15 Apr 2003 23:21:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195dDH-000ICU-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 03:03:55 +0000 Received: from motgate5.mot.com ([144.189.100.105]) by psg.com with esmtp (Exim 3.36 #1) id 195dCv-000IBw-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 03:03:33 +0000 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h3G33UWc020840; Tue, 15 Apr 2003 20:03:30 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id UAA07398; Tue, 15 Apr 2003 20:03:28 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h3G33PVI016602; Wed, 16 Apr 2003 13:03:25 +1000 (EST) Message-ID: <3E9CC7FD.8010701@motorola.com> Date: Wed, 16 Apr 2003 13:03:25 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: namedroppers@ops.ietf.org Subject: Re: Proposed resolution of Issue 6: IPv6 Multicast Groups References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,REFERENCES,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 Bernard Aboba wrote: > [BA] I would like to propose that Mika's suggestion > be accepted: > > A single well-known multicast group for IPv6 queries other than A/AAAA. > I would prefer a single well known multicast address for the all types of IPv6 queries. Is there any reason why we shouldn't do this? Whilst using the solicited name link local addresses for queries is cute, it doesn't seem a particularly useful optimisation particularly if we're only doing it for *some* queries. I don't see it outweighing the increased code complexity and hence the increased potential for bugs. - aidan -- to unsubscribe send a message to namedroppers-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 Apr 15 23:57: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 XAA21733 for ; Tue, 15 Apr 2003 23:57:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195dlC-000KKG-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 03:38:58 +0000 Received: from motgate.mot.com ([129.188.136.100]) by psg.com with esmtp (Exim 3.36 #1) id 195dkr-000KJo-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 03:38:37 +0000 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h3G3cYca025379; Tue, 15 Apr 2003 20:38:34 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id UAA14267; Tue, 15 Apr 2003 20:38:02 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h3G3cVVI018291; Wed, 16 Apr 2003 13:38:31 +1000 (EST) Message-ID: <3E9CD036.3020507@motorola.com> Date: Wed, 16 Apr 2003 13:38:30 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: namedroppers Subject: Re: Revision to resolution of Issue 28 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,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 Bernard Aboba wrote: > Change: ... > To: > > "The source address of LLMNR queries and responses MUST be "on link". The > destination address of an LLMNR query MUST be a link-scope multicast > address or an "on link" unicast address; the destination address > of an LLMNR response MUST be an "on link" unicast address. > For IPv4, an "on link" address is defined as a link-local address or > an address whose prefix belongs > to a subnet on the local link; for IPv6 [RFC2460] > an "on link" address is either a link-local address, defined in > [RFC2373], or an address whose prefix > belongs to a subnet on the local link. A sender SHOULD prefer > RRs including reachable addresses where RRs involving > both reachable and unreachable addresses are returned in > response to a query." > Why does the proposed text start talking about "reachable" and "unreachable" rather than "on link"? Perhaps: A sender SHOULD prefer RRs including "on link" addresses where RRs involving both "on link" and "off link" addresses are returned in response to a query. - aidan -- to unsubscribe send a message to namedroppers-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 Apr 16 00:18: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 AAA22222 for ; Wed, 16 Apr 2003 00:18:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195eDW-000M91-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 04:08:14 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 195eDA-000M3H-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 04:07:52 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3G3nAr24074; Tue, 15 Apr 2003 20:49:10 -0700 Date: Tue, 15 Apr 2003 20:49:09 -0700 (PDT) From: Bernard Aboba To: Aidan Williams cc: namedroppers Subject: Re: Revision to resolution of Issue 28 In-Reply-To: <3E9CD036.3020507@motorola.com> 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,IN_REP_TO,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 > Why does the proposed text start talking about "reachable" > and "unreachable" rather than "on link"? See the discussion under Issue 28 on the LLMNR issues list: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The question is whether it is possible to know that a prefix is "on link". With IPv6 this seems possible, but it is not clear for IPv4. -- to unsubscribe send a message to namedroppers-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 Apr 16 00:54: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 AAA22766 for ; Wed, 16 Apr 2003 00:54:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195eqC-000Ol4-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 04:48:12 +0000 Received: from motgate4.mot.com ([144.189.100.102]) by psg.com with esmtp (Exim 3.36 #1) id 195epg-000Ojy-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 04:47:40 +0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h3G4lc0c025615; Tue, 15 Apr 2003 21:47:38 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h3G4lYXL014306; Tue, 15 Apr 2003 23:47:35 -0500 Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h3G4lXVI021905; Wed, 16 Apr 2003 14:47:33 +1000 (EST) Message-ID: <3E9CE065.8040208@motorola.com> Date: Wed, 16 Apr 2003 14:47:33 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba CC: namedroppers Subject: Re: Revision to resolution of Issue 28 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,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 Bernard Aboba wrote: >>Why does the proposed text start talking about "reachable" >>and "unreachable" rather than "on link"? > > See the discussion under Issue 28 on the LLMNR issues list: > http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > > The question is whether it is possible to know that a prefix is "on link". > With IPv6 this seems possible, but it is not clear for IPv4. > I think I found what you are referring to under Issue 21: PTR Queries Issue 21 winds up recommending: "[4] A sender SHOULD only send LLMNR queries for PTR RRs that represent addresses reachable through the link over which LLMNR is used." "Reachable" in the proposed resolution for 28 seems different in that it doesn't include the "through the link over which LLMNR is used" part.. but I think that is what is desired. How about: "A sender SHOULD prefer RRs including addresses known to be [directly] reachable through the link over which LLMNR is used." - aidan -- to unsubscribe send a message to namedroppers-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 Apr 16 02:16: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 CAA06088 for ; Wed, 16 Apr 2003 02:16:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195g6q-00049X-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 06:09:28 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 195g6Q-00043M-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 06:09:02 +0000 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h3G6AL4l000416; Wed, 16 Apr 2003 09:10:21 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h3G6AJ3k000415; Wed, 16 Apr 2003 09:10:19 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Revision to resolution of Issue 28 From: Mika Liljeberg To: Aidan Williams Cc: Bernard Aboba , namedroppers In-Reply-To: <3E9CE065.8040208@motorola.com> References: <3E9CE065.8040208@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1050473418.22245.1044.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Apr 2003 09:10:19 +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 Aidan, The change was made because there is no easy way for an application (= LLMNR resolver) to check whether a particular address is on-link. Not on any operating system I know, anyway. There's no difference between IPv4 and IPv6 in this respect. [On-link determination would become trivial, by the way, if we only allowed LLMNR to only advertise link-local addresses]. MikaL On Wed, 2003-04-16 at 07:47, Aidan Williams wrote: > Bernard Aboba wrote: > >>Why does the proposed text start talking about "reachable" > >>and "unreachable" rather than "on link"? > > > > See the discussion under Issue 28 on the LLMNR issues list: > > http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > > > > The question is whether it is possible to know that a prefix is "on link". > > With IPv6 this seems possible, but it is not clear for IPv4. > > > > I think I found what you are referring to under > Issue 21: PTR Queries > > Issue 21 winds up recommending: > > "[4] A sender SHOULD only send LLMNR queries for PTR RRs > that represent addresses reachable through the link > over which LLMNR is used." > > "Reachable" in the proposed resolution for 28 seems different > in that it doesn't include the "through the link over which > LLMNR is used" part.. but I think that is what is desired. > > How about: > > "A sender SHOULD prefer RRs including addresses known to > be [directly] reachable through the link over which LLMNR > is used." > > - aidan > > > -- > to 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 Wed Apr 16 08: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 IAA26405 for ; Wed, 16 Apr 2003 08:01:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195lUf-000GUv-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 11:54:25 +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 195lUJ-000GTT-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 11:54:03 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) with ESMTP id h3GBratk004136; Wed, 16 Apr 2003 13:53:36 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) id h3GBrV1E004133; Wed, 16 Apr 2003 13:53:31 +0200 Date: Wed, 16 Apr 2003 13:53:30 +0200 From: Miek Gieben To: Edward Lewis Cc: Derek Atkins , namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Message-ID: <20030416115330.GC3851@atoom.net> Mail-Followup-To: Edward Lewis , Derek Atkins , namedroppers@ops.ietf.org References: <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,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 [On 15 Apr, @21:30, Edward wrote in "Re: DNSSECbis Q-07: Discuss pr ..."] > At 15:04 -0400 4/15/03, Derek Atkins wrote: > >Sort of. I'm saying that "we don't need to agree on whether we use > >TCP, UDP, HTTPS, PGP-over-email, or unencrypted/unsigned CDRoms, so > >long as we agree that we should use the KEY or DS format records for > >the secure entry point." We don't need to agree on how the SEP data > >gets to the resolver. > > What do you mean by SEP data? What do you mean "gets to" the resolver? > > My assumption is that DNSSEC is about making the world safe for the > resolver. It needs security anchor data to do this - that's a > requirement. How the anchor data gets there and in what form is out > of scope for the DNSSEC document. it should at least not be specified in the dnssec-protocol draft. But I can not stop myself from thinking that stuff like this should be written down (somewhere)... grtz Miek -- to unsubscribe send a message to namedroppers-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 Apr 16 08:51: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 IAA26406 for ; Wed, 16 Apr 2003 08:01:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195lSD-000GRO-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 11:51:53 +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 195lRr-000GQi-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 11:51:31 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 195lRr-000P3u-AH for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 04:51:31 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Revision to resolution of Issue 28 Thread-Index: AcMD4aJnR/dOKtoySnauIACy4Ymz6wAFGTlQ Subject: RE: Revision to resolution of Issue 28 Date: Wed, 16 Apr 2003 12:16:53 +0300 From: To: Cc: , X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_01,NO_REAL_NAME,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 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 IAA26406 [ 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. ] Hi Aidan, [Mailing from work now] > Mika Liljeberg wrote: > > The change was made because there is no easy way for an > application (= > > LLMNR resolver) to check whether a particular address is > on-link. Not on > > any operating system I know, anyway. There's no difference > between IPv4 > > and IPv6 in this respect. > > > > Yes, I gathered that from reading the stuff on the issues web page > and the mailing list. I didn't really buy the check the routing > table thing.. Why? > The proposed solution seems like a bit of a fudge, (as in it doesn't > address the fundamental issue of not being able to tell what is > on-link) but because it is only a "preference" it probably won't > hurt that much. Yes, it could be clearer. But a clear requirement won't help if there is no clear way to implement it. It just means that different implementations will get it wrong in different ways. It occurs to me that it would be a whole lot simpler to do the PTR queries using unicast. The LLMNR resolver could use a TTL=1 when sending the query. This way it would either get an immediate no-route response from the local TCPIP stack, a direct response from the holder of the address, or an ICMP time exceeded reply from the default router. Either way, the resolver wouldn't have to do any checking on the address. This approach has several benefits: 1) Immediate error response if there is no route for the address 2) Error response from default router if the address is off-link 3) LLMNR resolver does not need to do any checking on the address 4) Unicast is easier on the network Note that conflict resolution for addresses is taken care by DAD, so using unicast for PTR shouldn't make any difference there. Another assumption is that the PTR query is already vulnerable to spoofing on the local link, so, as long as we use TTL=1 for the query there should be no perceivable additional risk. > > [On-link determination would become trivial, by the way, if we only > > allowed LLMNR to only advertise link-local addresses]. > > True.. but it appears people want to use it for more than that, > at least in the IPv6 case. Yes, IPv4 keeps muddying the water. LL's are always available with IPv6, so there should be no reason to advertise anything else. 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 Wed Apr 16 09:33: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 JAA00708 for ; Wed, 16 Apr 2003 09:33:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195myT-000LL2-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 13:29:17 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 195mxx-000LGJ-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 13:28:45 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 7E0C33A4; Wed, 16 Apr 2003 09:28:44 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id AC8EB342; Wed, 16 Apr 2003 09:28:43 -0400 (EDT) Received: from [192.136.136.97] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 186752; Wed, 16 Apr 2003 09:19:09 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <20030416115330.GC3851@atoom.net> References: <5.1.1.6.2.20030410110749.01713ff8@localhost> <20030414195329.GB13422@atoom.net> <20030416115330.GC3851@atoom.net> Date: Wed, 16 Apr 2003 09:28:33 -0400 To: Miek Gieben From: Edward Lewis Subject: Re: DNSSECbis Q-07: Discuss preconfigured trusted DSs in addition to preconfigured trusted KEYs? Cc: Edward Lewis , Derek Atkins , namedroppers@ops.ietf.org 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:53 +0200 4/16/03, Miek Gieben wrote: >it should at least not be specified in the dnssec-protocol draft. But I >can not stop myself from thinking that stuff like this should be written >down (somewhere)... Right. Finding the "someplace else" is hard - DNS has already struck out once with a MIB definition. I'm not against the effort. Based on past history, my prediction is that such an effort faces many challenges before accomplishing anything. My first advice to anyone trying such an effort - research the previous efforts and see where they stumbled. ("Past is prologue"-- unknown to me.) This, of course, has no bearing on any individual implementor's desire to experiment on their own. Running code is always welcome. Sometimes just being first means you get to set the table, it could mean that you're the one who gets shot in the back. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 16 12:38: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 MAA07939 for ; Wed, 16 Apr 2003 12:38:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195ppa-0003Qv-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 16:32:18 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 195ppD-0003PG-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 16:31:55 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3GGDCQ00864 for ; Wed, 16 Apr 2003 09:13:13 -0700 Date: Wed, 16 Apr 2003 09:13:12 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 30: Why is Dynamic Update Needed? 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 LLMNR Issues List is available at: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html During the LLMNR Issue Conference call of 4/16/03, the only advantage that could be ascribed to Dynamic Update was that responses to a dynamic update request might be more likely to fit within a single UDP packet than responses to an LLMNR query. This reason was felt to be insufficient for the added complexity and potential interoperability problems resulting from use of dynamic update. Even where the response to an LLMNR query is larger than can fit in a UDP packet (so that the TC bit is set), it is not clear that the LLMNR sender needs to make an additional request, since the essential information (that a conflict exists) is already known. On the hand, there are numerous potential interoperability issues that could result from use of Dynamic Update. So the downside outweighs any potential benefit. As a result, it is proposed that use of Dynamic Update be eliminated. The proposed resolution is to change the text of Section 4 to the following: "4. Conflict resolution The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers receive the query and respond with valid answers. When this occurs, the responses MAY first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would. There are some scenarios when multiple responders MAY respond to the same query. There are other scenarios when only one responder MAY respond to a query. Resource records for which the latter queries are submitted are referred as UNIQUE throughout this document. The uniqueness of a resource record depends on a nature of the name in the query and type of the query. For example it is expected that: - multiple hosts may respond to a query for an SRV type record - multiple hosts may respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster) - only a single host may respond to a query for an A or AAAA type record for a hostname. Every responder that responds to a LLMNR query and/or dynamic update request AND includes a UNIQUE record in the response: 1. MUST verify that there is no other host within the scope of the LLMNR query propagation that can return a resource record for the same name, type and class. 2. MUST NOT include a UNIQUE resource record in the response without having verified its uniqueness. 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, the host MUST verify resource record uniqueness on that interface. To accomplish this, the host MUST send an LLMNR query for each UNIQUE resource record. By default, a host SHOULD be configured to behave as though all RRs are UNIQUE. Uniqueness verification is carried out when the host: - starts up or - is configured to respond to the LLMNR queries on an interface or - is configured to respond to the LLMNR queries using additional UNIQUE resource records. When a host that owns a UNIQUE record receives an LLMNR query for that record, the host MUST respond. After the client receives a response, it MUST check whether the response arrived on another interface. If this is the case, then the client can use the UNIQUE resource record in response to LLMNR queries. If not, then it MUST NOT use the UNIQUE resource record in response to LLMNR queries. Note that this 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 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 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 unsubscribe send a message to namedroppers-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 Apr 16 12:51: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 MAA08175 for ; Wed, 16 Apr 2003 12:51:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195q4I-00040T-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 16:47:30 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 195q3v-0003yt-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 16:47:07 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3GGSO701714 for ; Wed, 16 Apr 2003 09:28:25 -0700 Date: Wed, 16 Apr 2003 09:28:24 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 6: IPv6 Multicast Groups 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 During the LLMNR Issue Conference call of 4/16/03, it was noted that use of multiple multicast groups requires that the name be canonicalized prior to computing the hash to determine what multicast group is to be used. In the past, canonicalization has been the source of issues, so requiring that it be done correctly is likely to result in interoperability problems. Also, each responder will need to listen both on the "node information" IPv6 multicast addresses used for A/AAAA queries as well as on the single multicast address used for other queries. This means that a sender could send to the single multicast address that all responders must listen on, and it would work. Therefore, implementers looking to simplify their senders will choose only send to a single multicast group anyway. Given that multiple multicast groups results in interoperability and is likely to be bypassed by implementers, the recommended resolution is to use a single multicast group with IPv6 as well as IPv4. In Section 1, Change: "LLMNR queries are sent to and received on port TBD using a link-scope multicast address as specified in "Administratively Scoped IP Multicast" [RFC2365] for IPv4. The LLMNR link-scope multicast address to be used for IPv4 is 224.0.0.251. For IPv6, the "solicited name" link-scope multicast addresses are used for A/AAAA queries, and a separate link- scope multicast address TBD for all other queries. Link-scope multicast addresses are used to prevent propagation of LLMNR traffic across routers, potentially flooding the network; for details, see Section 2.4. In circumstances described in Section 2.3, LLMNR queries can also be sent to a unicast address." To: "LLMNR queries are sent to and received on port TBD using a link-scope multicast address as specified in "Administratively Scoped IP Multicast" [RFC2365] for IPv4. The LLMNR link-scope multicast address to be used for IPv4 is 224.0.0.251. For IPv6, the LLMNR link-scope multicast address is TBD. Link-scope multicast addresses are used to prevent propagation of LLMNR traffic across routers, potentially flooding the network; for details, see Section 2.4. In circumstances described in Section 2.3, LLMNR queries can also be sent to a unicast address." Change Section 2.4 from: "The IPv4 link-scope multicast address a given responder listens to, and to which a sender sends all queries, is 224.0.0.251. The IPv6 link- scope multicast address a given responder listens to, and to which a sender sends A/AAAA queries, is formed as follows: The name of the resource record in question is expressed in its canonical form (see [RFC2535], section 8.1), which is uncompressed with all alphabetic characters in lower case. The first label of the FQDN in the query is then hashed using the MD5 algorithm, described in [RFC1321]. The first 32 bits of the resultant 128-bit hash is then appended to the prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name multicast address". (Note: this procedure is intended to be the same as that specified in section 3 of "IPv6 Node Information Queries" [NodeInfo]). A responder that listens for queries for multiple names with different first labels will necessarily listen to multiple of these solicited name multicast addresses. " To: "The IPv4 link-scope multicast address a given responder listens to, and to which a sender sends all queries, is 224.0.0.251. The IPv6 link- scope multicast address a given responder listens to, and to which a sender sends all queries, is TBD." Section 6 from: "This specification does not create any new name spaces for IANA administration. LLMNR requires allocation of a port TBD for both TCP and UDP. Assignment of the same port for both transports is requested. LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251) that has been previously allocated to LLMNR by IANA. It also requires allocation of a link scope multicast IPv6 address, for use with queries of types other than A/AAAA." To: "This specification does not create any new name spaces for IANA administration. LLMNR requires allocation of a port TBD for both TCP and UDP. Assignment of the same port for both transports is requested. LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251) that has been previously allocated to LLMNR by IANA. It also requires allocation of a link-scope multicast IPv6 address." -- to unsubscribe send a message to namedroppers-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 Apr 16 13: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 NAA08630 for ; Wed, 16 Apr 2003 13:11:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195qLR-0004iX-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 17:05:13 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 195qL4-0004gp-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 17:04:50 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3GGk7E02785 for ; Wed, 16 Apr 2003 09:46:07 -0700 Date: Wed, 16 Apr 2003 09:46:07 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Minutes of the 4/16/03 LLMNR Conference Call 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 During the 4/16/03 conference call, discussion focused on Issues 6, 21 and 30. On Issue 6 (IPv6 Multicast Groups) it was decided to go with a single IPv6 multicast group. It was noted that with multiple multicast groups, it was necessary to correctly canonicalize names prior to computing the hash or the wrong group would be chosen to send the query. This was thought likely to cause interoperability problems. In addition it was pointed out that since the proposal was to have only a single IPv6 multicast group for all non-A/AAAA queries, that responder would have to listen on this group. That meant that senders looking to simplify their implementations could send all queries to that group. As a result, in practice most traffic might go to a single group anyway. As a result, it was resolved to change the text to use only a single IPv6 multicast group. On Issue 21, it was argued that the text in Section 3 should be changed from: "[4] A sender SHOULD only send LLMNR queries for PTR RRs that represent addresses reachable through the link over which LLMNR is used." To: "[4] A sender SHOULD only send LLMNR queries for PTR RRs that represent addresses reachable on the link over which LLMNR is used." Since this appears to reflect the original discussion on the issues, it was recommended that this proposed change be made. On Issue 30 (Why is Dynamic Update Needed?), it was decided to replace the use of dynamic update with use of a regular LLMNR query. The major advantage of dynamic update was thought to be that responses to dynamic update requests would be more likely to fit within a single UDP packet, while responses to an LLMNR query might have the TC bit set. This was not thought to be a sufficient advantage to be worth the extra complexity and potential interoperability issues resulting from dynamic update. Also, there was concern that implementations of dynamic update might attempt to do inappropriate things, such as to use TSIG security or attempt to update hosts on which conflicts were detected. The proposed text changes to carry out these proposed resolutions are available on the LLMNR issues web site at: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 16 13:18: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 NAA08832 for ; Wed, 16 Apr 2003 13:18:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195qSK-00050X-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 17:12:20 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 195qRy-0004z2-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 17:11:58 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3GGrGj03158 for ; Wed, 16 Apr 2003 09:53:16 -0700 Date: Wed, 16 Apr 2003 09:53:16 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: New LLMNR "strawman" -17 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 I've put together a strawman LLMNR-17 draft, based on the proposed resolutions from today's LLMNR conference call. It can be found at: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-17.txt Please look at it closely and send comments to the list. Assuming that the proposed resolutions meet with approval, and no other issues arise, this may be the version of the draft brought to DNSEXT WG last call. -- to unsubscribe send a message to namedroppers-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 Apr 16 13:44: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 NAA09462 for ; Wed, 16 Apr 2003 13:44:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195qrW-0006BM-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 17:38:22 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 195qrA-0006AS-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 17:38:00 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3GHJHv04657 for ; Wed, 16 Apr 2003 10:19:18 -0700 Date: Wed, 16 Apr 2003 10:19:17 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 33: PTR via Unicast 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 Issue 33: PTR via Unicast Submitter: Mika Liljeberg Submitter email address: mika.liljeberg@welho.com Date first submitted: April 17, 2003 Reference: Document: LLMNR-16 Comment type: T Priority: S Section: 3 Rationale/Explanation of issue: It occurs to me that it would be a whole lot simpler to do PTR queries using unicast. The LLMNR resolver could use a TTL=1 when sending the query. This way it would either get an immediate no-route response from the local TCPIP stack, a direct response from the holder of the address, or an ICMP time exceeded reply from the default router. Either way, the resolver wouldn't have to do any checking on the address. This approach has several benefits: 1) Immediate error response if there is no route for the address 2) Error response from default router if the address is off-link 3) LLMNR resolver does not need to do any checking on the address 4) Unicast is easier on the network Note that conflict resolution for addresses is taken care by DAD, so using unicast for PTR shouldn't make any difference there. Another assumption is that the PTR query is already vulnerable to spoofing on the local link, so, as long as we use TTL=1 for the query there should be no perceivable additional risk. -- to unsubscribe send a message to namedroppers-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 Apr 16 14:00: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 OAA10084 for ; Wed, 16 Apr 2003 14:00:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195r9m-0006wz-00 for namedroppers-data@psg.com; Wed, 16 Apr 2003 17:57:14 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 195r9Q-0006vX-00 for namedroppers@ops.ietf.org; Wed, 16 Apr 2003 17:56:52 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3GHc9D05659 for ; Wed, 16 Apr 2003 10:38:09 -0700 Date: Wed, 16 Apr 2003 10:38:09 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 3 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 On Thu, 10 April 2003, Joshua Graessley said: "Unless I'm mistaken, domains in the search list are appended to unqualified names only if an attempt to resolve the unqualified name fails. A resolver attempting to resolve "ietf.org" would try to resolve "ietf.org." first. Since "ietf.org." doesn't end in "local.arpa." LLMNR would not be used if there is a DNS server configured. Even if someone were respoding to "ietf.org.local.arpa." using LLMNR, it is unlikely they would receive any queries for that name." The problem is that in practice attempts to resolve names fail a significant portion of the time, even when the DNS server is up and the RR exists. So once the attempt to resolve "ietf.org" fails, an attempt will be made to resolve "ietf.org.local.arpa". [The searchlist] "is an optional knob. The default behavior could work well enough that you don't have to add local.arpa to the search list unless you really wanted to. You could resolve LLMNR names by appending local.arpa yourself. You can resolve any name without editing or even having a search list. Search lists are just a convenience for people who type a lot of names in a few domains often." Unless "local.arpa" were in the searchlist, if conventional DNS were to fail, as it does in practice, then it would not be possible to resolve a non "local.arpa" FQDN on the local link. So either the searchlist entry is present and things "just work" or it is not present and they break. In any case, the same behavior is exhibited depending on whether LLMNR is used as a fallback name resolution mechanism or not. "If the name does exist in the DNS namespace, someone with access to a DNS server may be unable to use LLMNR to find me. If there is a specific domain for LLMNR names, the domain can be used to specify that the name should be resolved using LLMNR. People who don't have authority over any domain will still have a way to use LLMNR. Names in that domain will have certain properties. They won't be globally unique, they will be unique only on the local link. This would give me the freedom to pick any LLMNR name. The protocol can detect a conflict and notify me, at which time I can pick a new unique name or maybe my LLMNR responder could automatically generate a unique name." Wouldn't use of unqualified names with fallback provide the same benefit? "Bob" isn't registered in the DNS, so a host can choose that name, and it can be resolved via LLMNR. I'm not sure why the name has to be uniquely tied to a particular name resolution mechanism. -- to unsubscribe send a message to namedroppers-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 Apr 16 20:46: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 UAA22660 for ; Wed, 16 Apr 2003 20:46:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 195xLj-0002bZ-00 for namedroppers-data@psg.com; Thu, 17 Apr 2003 00:33:59 +0000 Received: from motgate3.mot.com ([144.189.100.103]) by psg.com with esmtp (Exim 3.36 #1) id 195xKa-0002Un-00 for namedroppers@ops.ietf.org; Thu, 17 Apr 2003 00:32:48 +0000 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h3H0Wi2x021399; Wed, 16 Apr 2003 17:32:45 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA28232; Wed, 16 Apr 2003 17:32:42 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h3H0WcVI016834; Thu, 17 Apr 2003 10:32:39 +1000 (EST) Message-ID: <3E9DF626.2020607@motorola.com> Date: Thu, 17 Apr 2003 10:32:38 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mika.Liljeberg@nokia.com CC: mika.liljeberg@welho.com, namedroppers@ops.ietf.org Subject: Re: Revision to resolution of Issue 28 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,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 Mika.Liljeberg@nokia.com wrote: >>Yes, I gathered that from reading the stuff on the issues web page >>and the mailing list. I didn't really buy the check the routing >>table thing.. > > Why? Mainly because the suggested approach of using a UDP connect as a test will succeed when there is a default route, or a route of more than one hop. Perhaps we really mean that we should prefer addresses we can ARP/ND directly for. "Reachable" (or unreachable) in RFC3484 is deliberately vague, and explicitly says that determining unreachability is implementation dependent. >>The proposed solution seems like a bit of a fudge, (as in it doesn't >>address the fundamental issue of not being able to tell what is >>on-link) but because it is only a "preference" it probably won't >>hurt that much. > > Yes, it could be clearer. But a clear requirement won't help if > there is no clear way to implement it. I understand that the resolver doesn't have a guaranteed way of discovering whether a particular address is directly reachable on the link.. My concern was more about the proposed text for Issue 28. The -17 text doesn't define "reachable" anywhere, but it does define "on link". Right at the point where it seems like it is going to use the "on link" definition for something, it starts talking about "reachable". The text used elsewhere ("must be reachable through the link over which LLMNR is used") seems self-contained enough to me -- hence the suggestion I made. "Prefer addresses that can be directly ARPed/NDed for" would work for me too. > It just means that > different implementations will get it wrong in different ways. Quite.. ;-) > It occurs to me that it would be a whole lot simpler to do the PTR > queries using unicast. The LLMNR resolver could use a TTL=1 when > sending the query. This way it would either get an immediate > no-route response from the local TCPIP stack, a direct response from > the holder of the address, or an ICMP time exceeded reply from the > default router. Either way, the resolver wouldn't have to do any > checking on the address. This approach has several benefits: > > 1) Immediate error response if there is no route for the address > 2) Error response from default router if the address is off-link > 3) LLMNR resolver does not need to do any checking on the address > 4) Unicast is easier on the network > I think that is a good idea. This is what the Node Information Query reverse lookup does. When asked to reverse lookup a multicast address what then? Offhand I can't think of a good reason not to just multicast the PTR query to the address you are looking up. - aidan -- to unsubscribe send a message to namedroppers-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 Apr 17 08:53: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 IAA19607 for ; Thu, 17 Apr 2003 08:53:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1968i8-000L2y-00 for namedroppers-data@psg.com; Thu, 17 Apr 2003 12:41:52 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 1968hW-000Kzv-00 for namedroppers@ops.ietf.org; Thu, 17 Apr 2003 12:41:14 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h3HCfDSs001344 for ; Thu, 17 Apr 2003 14:41:13 +0200 Date: Thu, 17 Apr 2003 14:41:13 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: DNSSEC protocol: attempting to retrieve SIGs Message-Id: <20030417144113.48df6726.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 dnssec protocol draft. A somewhat detailed nit. Section 4, page 21 first but last paragraph: a security aware resolver MUST attempt to retrieve missing DS, KEY, or SIG RRs. Seems to be inconsistent with section 3 that says that: SIG RRs which can be used to authenticate the data MUST be included. (more detailed in the subsections) Based on the "MUST" in section 3 I would say if the SIG is not included in a response packet (while it is being expected) a implementation can just drop it and concern it bad. Section 4 could read: a security aware resolver MUST attempt to retrieve missing DS and KEYs, (drop the SIGs from that). On the other hand it could be that one of the set of authoritative servers does not properly do the dnssec processing (is buggy or not DNSSEC aware). In that case such server should be marked as lame and the query (not for the SIG but the original query, I'd say) should be done against another server. If that is the expected behavior I think some explanatory text is needed. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-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 Apr 17 09:44: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 JAA20870 for ; Thu, 17 Apr 2003 09:44:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1969cY-000Nwf-00 for namedroppers-data@psg.com; Thu, 17 Apr 2003 13:40:10 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 1969cC-000NvB-00 for namedroppers@ops.ietf.org; Thu, 17 Apr 2003 13:39:48 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id E4FB23AF; Thu, 17 Apr 2003 09:39:44 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 74AC4388; Thu, 17 Apr 2003 09:39:44 -0400 (EDT) Received: from [192.136.136.64] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 188019; Thu, 17 Apr 2003 09:30:06 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <20030417144113.48df6726.olaf@ripe.net> References: <20030417144113.48df6726.olaf@ripe.net> Date: Thu, 17 Apr 2003 09:39:36 -0400 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: DNSSEC protocol: attempting to retrieve SIGs 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 The reason for the differences is that there are non-security aware protocol elements out there. In the old days we had hoped to be able to retrieve DNSSEC data through older DNS implementations (e.g., caching servers performing proxy DNS service on statefull firewalls). Perhaps this is quixotic, as we eventually ran into trouble trying to implement responses to queries for QTYPE=SIG, and we've seen even uglier interactions (with legacy code bases) when looking at the "grandparent problem" during discussions of the DS RR. But a stab at backwards compatibility is the reason for the two requirements. At 14:41 +0200 4/17/03, Olaf M. Kolkman wrote: >Section 4, page 21 first but last paragraph: > > a security aware resolver MUST attempt to retrieve missing DS, KEY, > or SIG RRs. I.e., be liberal in what you receive. >Seems to be inconsistent with section 3 that says that: > > SIG RRs which can be used to authenticate the data MUST be included. > (more detailed in the subsections) I.e., be conservative in what you send. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 17 13:39: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 NAA29763 for ; Thu, 17 Apr 2003 13:38:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196DGA-0009tB-00 for namedroppers-data@psg.com; Thu, 17 Apr 2003 17:33:18 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 196DEg-0009of-00 for namedroppers@ops.ietf.org; Thu, 17 Apr 2003 17:31:47 +0000 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-2) with ESMTP id h3HHXF7o014219; Thu, 17 Apr 2003 20:33:15 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-2) id h3HHXEn0014218; Thu, 17 Apr 2003 20:33:14 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Revision to resolution of Issue 28 From: Mika Liljeberg To: Aidan Williams Cc: Mika.Liljeberg@nokia.com, namedroppers@ops.ietf.org In-Reply-To: <3E9DF626.2020607@motorola.com> References: <3E9DF626.2020607@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1050600793.2891.111.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Apr 2003 20:33:13 +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 Thu, 2003-04-17 at 03:32, Aidan Williams wrote: > Mika.Liljeberg@nokia.com wrote: > >>Yes, I gathered that from reading the stuff on the issues web page > >>and the mailing list. I didn't really buy the check the routing > >>table thing.. > > > > Why? > > Mainly because the suggested approach of using a UDP connect as a test > will succeed when there is a default route, or a route of more than > one hop. Perhaps we really mean that we should prefer addresses we > can ARP/ND directly for. Well, I gave the UDP connect as an example of what an application could try in order to satisfy the requirement. To force the stack to do ARP/ND the application would actually have to send a packet (which I think is unfeasible in practise). > I understand that the resolver doesn't have a guaranteed way of > discovering whether a particular address is directly reachable on the > link.. My concern was more about the proposed text for Issue 28. > > The -17 text doesn't define "reachable" anywhere, but it does define > "on link". Right at the point where it seems like it is going to use > the "on link" definition for something, it starts talking about > "reachable". Hmm. I don't see any problem with the text, because the "on-link" definition is used for constrain the source and destination addresses used by LLMN. Which RRs to prefer is a separate issue and the text on that is correct (and consistent with RFC3484), I think. Maybe we just need a definition for "reachable"? > The text used elsewhere ("must be reachable through the link over > which LLMNR is used") seems self-contained enough to me -- hence the > suggestion I made. "Prefer addresses that can be directly ARPed/NDed > for" would work for me too. Does that mean you require the resolver to ARP/ND every address to find out whether it can be done, before returning the address to the application? I should hope not. 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 Apr 17 13:39: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 NAA29778 for ; Thu, 17 Apr 2003 13:39:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196DCR-0009ee-00 for namedroppers-data@psg.com; Thu, 17 Apr 2003 17:29:27 +0000 Received: from mail-out1.apple.com ([17.254.0.52]) by psg.com with esmtp (Exim 3.36 #1) id 196DC4-0009dh-00 for namedroppers@ops.ietf.org; Thu, 17 Apr 2003 17:29:04 +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 h3HHT43h009118 for ; Thu, 17 Apr 2003 10:29:04 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 17 Apr 2003 10:28:54 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h3HHT2VX020773; Thu, 17 Apr 2003 10:29:03 -0700 (PDT) Date: Thu, 17 Apr 2003 10:29:03 -0700 Subject: Re: LLMNR Issue 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: namedroppers@ops.ietf.org To: Bernard Aboba From: Joshua Graessley In-Reply-To: Message-Id: <15366F1E-70FA-11D7-A65B-000A959D832C@apple.com> Content-Transfer-Encoding: 7bit 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, Apr 16, 2003, at 10:38 US/Pacific, Bernard Aboba wrote: > On Thu, 10 April 2003, Joshua Graessley said: > > "Unless I'm mistaken, domains in the search list are appended to > unqualified names only if an attempt to resolve the unqualified name > fails. A resolver attempting to resolve "ietf.org" would try to resolve > "ietf.org." first. Since "ietf.org." doesn't end in "local.arpa." LLMNR > would not be used if there is a DNS server configured. Even if someone > were respoding to "ietf.org.local.arpa." using LLMNR, it is unlikely > they would receive any queries for that name." > > The problem is that in practice attempts to resolve names fail > a significant portion of the time, even when the DNS server is up > and the RR exists. So once the attempt to resolve "ietf.org" fails, > an attempt will be made to resolve "ietf.org.local.arpa". I think we've gone in a circle. One of the problems with LLMNR is that it is unclear when LLMNR should be used to resolve a name. Should DNS or LLMNR come first? We don't want to make it really easy to spoof ietf.org, so must only use LLMNR when either there is no DNS server or the query fails. I believe we can make this work better by having a domain for which LLMNR is authoritative. Any queries in this domain a resolved using LLMNR only. You point out that if someone adds that domain to their search list, then a query for ietf.org.local.arpa. will occur of the query for ietf.org. fails. Is this any different from the case where the query for ietf.org fails in DNS and we fall back to using LLMNR? > Unless "local.arpa" were in the searchlist, if conventional > DNS were to fail, as it does in practice, then it would not be > possible to resolve a non "local.arpa" FQDN on the local link. So > either > the searchlist entry is present and things "just work" or it is not > present and they break. In any case, the same behavior is exhibited > depending on whether LLMNR is used as a fallback name resolution > mechanism > or not. I would not expect a FQDN to work if DNS was flaky. In the example we've been using, I would never expect that if my DNS server is not working, I could use LLMNR to get the address of ietf.org. It is unlikely I will ever be on the same local link as any of the IETF servers. > "If the name does exist in the DNS > namespace, someone with access to a DNS server may be unable to use > LLMNR to find me. If there is a specific domain for LLMNR names, the > domain can be used to specify that the name should be resolved using > LLMNR. People who don't have authority over any domain will still have > a way to use LLMNR. Names in that domain will have certain properties. > They won't be globally unique, they will be unique only on the local > link. This would give me the freedom to pick any LLMNR name. The > protocol can detect a conflict and notify me, at which time I can pick > a new unique name or maybe my LLMNR responder could automatically > generate a unique name." > > Wouldn't use of unqualified names with fallback provide the same > benefit? > "Bob" isn't registered in the DNS, so a host can choose that name, and > it can be resolved via LLMNR. I'm not sure why the name has to > be uniquely tied to a particular name resolution mechanism. tv is. I can't give my television the name tv? Based on the implementations I've seen, most resolvers would try a query for bob. Bob would be sent off to the DNS code. The DNS code would append domains in the search list if bob failed to resolve. Before bob would ever be tried with LLMNR, DNS would be used for bob and bob followed by all of the names in the search domains list. If the resolver libraries were changed, there would still be problems. If someone knew that I commonly use a server named zaphod.apple.com, but I was lazy and typed zaphod, relying on the search domains to do the right thing, they could easily spoof zaphod. If the use of LLMNR is triggered by the domain, the search list can actually be used to specify an order in which LLMNR is used for unqualified names. By default, the LLMNR domain shouldn't be in the list so LLMNR would not be used unless someone typed a name ending in the LLMNR domain. -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 Apr 17 13:54: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 NAA00247 for ; Thu, 17 Apr 2003 13:54:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196DW0-000AYO-00 for namedroppers-data@psg.com; Thu, 17 Apr 2003 17:49:40 +0000 Received: from dhcp-86.wl.nominum.com ([81.200.65.86] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 196DVe-000AXR-00 for namedroppers@ops.ietf.org; Thu, 17 Apr 2003 17:49:18 +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 h3HHkDta022956; Thu, 17 Apr 2003 10:46:13 -0700 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h3HHkCVY022953; Thu, 17 Apr 2003 10:46:12 -0700 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Thu, 17 Apr 2003 10:46:11 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: Edward Lewis cc: "Olaf M. Kolkman" , "" Subject: Re: DNSSEC protocol: attempting to retrieve SIGs In-Reply-To: Message-ID: References: <20030417144113.48df6726.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-39.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,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 Thu, 17 Apr 2003, Edward Lewis wrote: > The reason for the differences is that there are non-security aware > protocol elements out there. In the old days we had hoped to be able > to retrieve DNSSEC data through older DNS implementations (e.g., > caching servers performing proxy DNS service on statefull firewalls). The old days are long gone. > Perhaps this is quixotic, as we eventually ran into trouble trying to > implement responses to queries for QTYPE=SIG, and we've seen even > uglier interactions (with legacy code bases) when looking at the > "grandparent problem" during discussions of the DS RR. > > But a stab at backwards compatibility is the reason for the two requirements. It won't work at all. One reason that it won't work is that any intermediary server that would need to be explicitly queried for SIG wouldn't have set the DO bit in the first place, and thus wouldn't have received the SIGs in its response. Supporting backwards compatibility is a good idea, but not when it won't work. Especially not when it requires servers to add code just to handle cases that won't work. 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 Thu Apr 17 13:57:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00365 for ; Thu, 17 Apr 2003 13:57:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196DR3-000AKc-00 for namedroppers-data@psg.com; Thu, 17 Apr 2003 17:44:33 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 196DQP-000AJh-00 for namedroppers@ops.ietf.org; Thu, 17 Apr 2003 17:43:53 +0000 Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-2) with ESMTP id h3HHjM7o014252; Thu, 17 Apr 2003 20:45:22 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-2) id h3HHjLao014251; Thu, 17 Apr 2003 20:45:21 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: LLMNR Issue 33 [Was: Re: Revision to resolution of Issue 28] From: Mika Liljeberg To: Aidan Williams Cc: Mika.Liljeberg@nokia.com, namedroppers@ops.ietf.org In-Reply-To: <3E9DF626.2020607@motorola.com> References: <3E9DF626.2020607@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1050601520.2893.125.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Apr 2003 20:45:21 +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 Thu, 2003-04-17 at 03:32, Aidan Williams wrote: > > It occurs to me that it would be a whole lot simpler to do the PTR > > queries using unicast. The LLMNR resolver could use a TTL=1 when > > sending the query. This way it would either get an immediate > > no-route response from the local TCPIP stack, a direct response from > > the holder of the address, or an ICMP time exceeded reply from the > > default router. Either way, the resolver wouldn't have to do any > > checking on the address. This approach has several benefits: > > > > 1) Immediate error response if there is no route for the address > > 2) Error response from default router if the address is off-link > > 3) LLMNR resolver does not need to do any checking on the address > > 4) Unicast is easier on the network > > > > I think that is a good idea. This is what the Node Information Query > reverse lookup does. > > When asked to reverse lookup a multicast address what then? Offhand I > can't think of a good reason not to just multicast the PTR query to > the address you are looking up. I think we have to be careful here. Even though setting TTL=1 would limit the propagation, I wouldn't want to send a PTR query to the subnet broadcast address. The first question is, is it useful to support PTR queries for multicast and broadcast addresses at all? If yes, we have to define the behaviour both ways. Does a responder also include its subscribed multicast addresses to A and AAAA responses? Multicast addresses would also have to be treated as non-UNIQUE RRs to avoid problems with conflict resolution. I would say just return an error to PTR queries for multicast/broadcast addresses. 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 Apr 17 14:02: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 OAA00523 for ; Thu, 17 Apr 2003 14:02:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196Da0-000Al6-00 for namedroppers-data@psg.com; Thu, 17 Apr 2003 17:53:48 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 196DZe-000Ajm-00 for namedroppers@ops.ietf.org; Thu, 17 Apr 2003 17:53:26 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 2958F432; Thu, 17 Apr 2003 13:53:26 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id BB33841F; Thu, 17 Apr 2003 13:53:25 -0400 (EDT) Received: from [192.136.136.64] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 188868; Thu, 17 Apr 2003 13:43:47 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: References: <20030417144113.48df6726.olaf@ripe.net> Date: Thu, 17 Apr 2003 13:53:18 -0400 To: Brian Wellington From: Edward Lewis Subject: Re: DNSSEC protocol: attempting to retrieve SIGs Cc: Edward Lewis , "Olaf M. Kolkman" , "" 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:46 -0700 4/17/03, Brian Wellington wrote: >The old days are long gone. True - but that's why the text was there. Perhaps changes can be made, but it's good to know the history first. >Supporting backwards compatibility is a good idea, but not when it won't >work. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 18 07:37: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 HAA10001 for ; Fri, 18 Apr 2003 07:37:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 196Tst-00061k-00 for namedroppers-data@psg.com; Fri, 18 Apr 2003 11:18:23 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 196TsX-0005zD-00 for namedroppers@ops.ietf.org; Fri, 18 Apr 2003 11:18:02 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08349; Fri, 18 Apr 2003 07:15:19 -0400 (EDT) Message-Id: <200304181115.HAA08349@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-17.txt Date: Fri, 18 Apr 2003 07:15:19 -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 : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-17.txt Pages : 20 Date : 2003-4-17 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-17.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-17.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-17.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-17132102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-17132102.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 Sun Apr 20 17:32: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 RAA16012 for ; Sun, 20 Apr 2003 17:32:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197MEQ-0007Hw-00 for namedroppers-data@psg.com; Sun, 20 Apr 2003 21:20:14 +0000 Received: from gw.enyo.de ([212.9.189.178] helo=mail.enyo.de) by psg.com with esmtp (Exim 3.36 #1) id 197ME4-0007GH-00 for namedroppers@ops.ietf.org; Sun, 20 Apr 2003 21:19:52 +0000 Received: from [212.9.189.171] (helo=deneb.enyo.de) by mail.enyo.de with esmtp (Exim 3.34 #2) id 197MDs-0006I1-00; Sun, 20 Apr 2003 23:19:40 +0200 Received: from fw by deneb.enyo.de with local (Exim 3.34 #4) id 197MDs-0005zV-00; Sun, 20 Apr 2003 23:19:40 +0200 To: Peter Koch Cc: "Mohammad Awad" , namedroppers@ops.ietf.org Subject: Re: TXT records, are they alive? From: Florian Weimer Date: Sun, 20 Apr 2003 23:19:40 +0200 In-Reply-To: <200304121614.h3CGEGb10453@grimsvotn.TechFak.Uni-Bielefeld.DE> (Peter Koch's message of "Sat, 12 Apr 2003 18:14:16 +0200") Message-ID: <87fzoc989f.fsf@deneb.enyo.de> User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.2 (gnu/linux) References: <200304121614.h3CGEGb10453@grimsvotn.TechFak.Uni-Bielefeld.DE> 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 Peter Koch writes: > Not only do servers implement the TXT RRs, but also resolvers > support it. However, as far as I can tell, stub resolvers lack convenient interfaces for extracting TXT RRs. This might explain why a lot of DNS applications use A RRs to encode things which actually aren't IP addresses. 8-/ -- to unsubscribe send a message to namedroppers-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 Apr 20 19: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 TAA18646 for ; Sun, 20 Apr 2003 19:03:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197Nnc-000IBa-00 for namedroppers-data@psg.com; Sun, 20 Apr 2003 23:00:40 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 197NnF-000I3o-00 for namedroppers@ops.ietf.org; Sun, 20 Apr 2003 23:00:17 +0000 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3KN0EsY027832; Sun, 20 Apr 2003 19:00:14 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3KN0CXx002709; Sun, 20 Apr 2003 19:00:13 -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 h3KN0BFJ022487; Sun, 20 Apr 2003 19:00:12 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id TAA19512; Sun, 20 Apr 2003 19:00:11 -0400 (EDT) To: Florian Weimer Cc: Peter Koch , "Mohammad Awad" , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: TXT records, are they alive? References: <200304121614.h3CGEGb10453@grimsvotn.TechFak.Uni-Bielefeld.DE> <87fzoc989f.fsf@deneb.enyo.de> Date: 20 Apr 2003 19:00:10 -0400 In-Reply-To: <87fzoc989f.fsf@deneb.enyo.de> Message-ID: Lines: 18 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.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,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 Florian Weimer writes: > However, as far as I can tell, stub resolvers lack convenient > interfaces for extracting TXT RRs. This might explain why a lot of > DNS applications use A RRs to encode things which actually aren't IP > addresses. 8-/ What applications do something like this? An A record is extremely limited in what it can hold (namely, a 4 octet address). So, I'd be interested in hearing about "DNS applications" that hold something else or somehow use A records differently. -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 Sun Apr 20 22:41: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 WAA21590 for ; Sun, 20 Apr 2003 22:41:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197RAW-000H9G-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 02:36:32 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 197RAA-000H7K-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 02:36:10 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h3L2Zwdf019066; Sun, 20 Apr 2003 19:35:58 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 20 Apr 2003 19:36:01 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Derek Atkins'" , Florian Weimer Cc: Peter Koch , Mohammad Awad , namedroppers@ops.ietf.org Subject: RE: TXT records, are they alive? Date: Sun, 20 Apr 2003 19:36:00 -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 Some of the spam blacklists use A records to encode their opinion of the domain in question. > -----Original Message----- > From: Derek Atkins [mailto:derek@ihtfp.com] > Sent: Sunday, April 20, 2003 7:00 PM > To: Florian Weimer > Cc: Peter Koch; Mohammad Awad; namedroppers@ops.ietf.org > Subject: Re: TXT records, are they alive? > > > Florian Weimer writes: > > > However, as far as I can tell, stub resolvers lack convenient > > interfaces for extracting TXT RRs. This might explain why a lot of > > DNS applications use A RRs to encode things which actually aren't IP > > addresses. 8-/ > > What applications do something like this? An A record is extremely > limited in what it can hold (namely, a 4 octet address). So, I'd be > interested in hearing about "DNS applications" that hold something > else or somehow use A records differently. > > -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: > -- to unsubscribe send a message to namedroppers-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 Apr 20 22:41: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 WAA21605 for ; Sun, 20 Apr 2003 22:41:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197R5l-000Gbs-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 02:31:37 +0000 Received: from walrus.ne.client2.attbi.com ([24.60.130.129] helo=walrus.jabberwocky.com) by psg.com with esmtp (Exim 3.36 #1) id 197R4F-000G4z-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 02:30:03 +0000 Received: from claude.jabberwocky.com (bgp423281bgs.union01.nj.comcast.net [68.36.187.43]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h3L2U3408189; Sun, 20 Apr 2003 22:30:03 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h3L2TZv05706; Sun, 20 Apr 2003 22:29:35 -0400 Date: Sun, 20 Apr 2003 22:29:05 -0400 From: David Shaw To: Derek Atkins Cc: Florian Weimer , Peter Koch , Mohammad Awad , namedroppers@ops.ietf.org Subject: Re: TXT records, are they alive? Message-ID: <20030421022905.GF1276@jabberwocky.com> Mail-Followup-To: Derek Atkins , Florian Weimer , Peter Koch , Mohammad Awad , namedroppers@ops.ietf.org References: <200304121614.h3CGEGb10453@grimsvotn.TechFak.Uni-Bielefeld.DE> <87fzoc989f.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (78% of Full) User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-43.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Apr 20, 2003 at 07:00:10PM -0400, Derek Atkins wrote: > Florian Weimer writes: > > > However, as far as I can tell, stub resolvers lack convenient > > interfaces for extracting TXT RRs. This might explain why a lot of > > DNS applications use A RRs to encode things which actually aren't IP > > addresses. 8-/ > > What applications do something like this? An A record is extremely > limited in what it can hold (namely, a 4 octet address). So, I'd be > interested in hearing about "DNS applications" that hold something > else or somehow use A records differently. The various DNS-based email blacklist systems come to mind. They use different "addresses" in the loopback net (127.0.0.1, 127.0.0.2, etc) to indicate different reasons to block a given SMTP connection. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2rc2 (GNU/Linux) Comment: http://www.jabberwocky.com/david/keys.asc iD8DBQE+o1Ky4mZch0nhy8kRAlSgAKDYH4C7Z/R+/xyP1c4KwIxlXgPmEwCg10qu 99SMYyuvqnDaBvICxtDWk7g= =uQMz -----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 Sun Apr 20 23:18: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 XAA22207 for ; Sun, 20 Apr 2003 23:18:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197RmU-000MjO-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 03:15:46 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 197Rm8-000Miq-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 03:15:24 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3L3FKR4027307; Sun, 20 Apr 2003 23:15:21 -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 h3L3FJfP029912; Sun, 20 Apr 2003 23:15:19 -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 h3L3FIFJ025622; Sun, 20 Apr 2003 23:15:18 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id XAA19919; Sun, 20 Apr 2003 23:15:18 -0400 (EDT) To: "Hallam-Baker, Phillip" Cc: Florian Weimer , Peter Koch , Mohammad Awad , namedroppers@ops.ietf.org From: "'Derek Atkins'" Subject: Re: TXT records, are they alive? References: Date: 20 Apr 2003 23:15:17 -0400 In-Reply-To: Message-ID: Lines: 52 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.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,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 Sure, but it's still just returning a IP Address.. Nothing says that that IP Address has to be real or routable or accurate.. It's still limited to 4 bytes. But I conceed that people are actually using it from things other than hostname looking to contact that host. -derek "Hallam-Baker, Phillip" writes: > Some of the spam blacklists use A records to encode their opinion of the > domain in question. > > > -----Original Message----- > > From: Derek Atkins [mailto:derek@ihtfp.com] > > Sent: Sunday, April 20, 2003 7:00 PM > > To: Florian Weimer > > Cc: Peter Koch; Mohammad Awad; namedroppers@ops.ietf.org > > Subject: Re: TXT records, are they alive? > > > > > > Florian Weimer writes: > > > > > However, as far as I can tell, stub resolvers lack convenient > > > interfaces for extracting TXT RRs. This might explain why a lot of > > > DNS applications use A RRs to encode things which actually aren't IP > > > addresses. 8-/ > > > > What applications do something like this? An A record is extremely > > limited in what it can hold (namely, a 4 octet address). So, I'd be > > interested in hearing about "DNS applications" that hold something > > else or somehow use A records differently. > > > > -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: > > -- 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 Apr 21 10:04: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 KAA16148 for ; Mon, 21 Apr 2003 10:04:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197bbQ-000Kpb-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 13:45:00 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 197bb3-000Kk2-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 13:44:37 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id C1D313EC; Mon, 21 Apr 2003 09:44:34 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3B28B2AE for ; Mon, 21 Apr 2003 09:44:34 -0400 (EDT) Received: from [192.136.136.46] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 192239; Mon, 21 Apr 2003 09:34:42 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: References: Date: Mon, 21 Apr 2003 09:44:32 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: concerned - RE: TXT records, are they alive? Cc: 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 This (below) concerns me at some level. Without pontificating on the morality of this at all, I'm worried that this happens. Why do the application writers of this software opt to use an existing RR in a manner not intended? Why are they unwilling to define a new RR? Has the IETF made it too hard for engineers to do the right thing? Do the application writes feel disenfranchised? Why are they not coming to and actively participating in the WG process? How has the IETF failed in this way? Has the IETF failed in educating developers, presumably newer developers, in good engineering practices? The IETF once prided itself on not educating folks, to discourage 'tourists,' maybe the IETF has succeeded in building a large body of work that may go misunderstood by the next generation of engineers because of this? I'm not disappointed that developers do whatever they can to seek out the path of least resistance towards meeting a goal. I'm disappointed that the IETF hasn't carved a path - making it least resistance - that meets high-quality engineering practice. Back to DNS - Why I am concerned in this case - although the IETF does not enforce protocol use, I hope not to have to maintain backwards compatibility with wayward extensions and operations. At 19:36 -0700 4/20/03, Hallam-Baker, Phillip wrote: >Some of the spam blacklists use A records to encode their opinion of the >domain in question. > >> -----Original Message----- >> From: Derek Atkins [mailto:derek@ihtfp.com] >> Sent: Sunday, April 20, 2003 7:00 PM >> To: Florian Weimer >> Cc: Peter Koch; Mohammad Awad; namedroppers@ops.ietf.org >> Subject: Re: TXT records, are they alive? >> >> What applications do something like this? An A record is extremely >> limited in what it can hold (namely, a 4 octet address). So, I'd be >> interested in hearing about "DNS applications" that hold something >> else or somehow use A records differently. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 21 11:33: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 LAA19896 for ; Mon, 21 Apr 2003 11:33:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197dBD-0001Ld-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 15:26:03 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 197dAh-0001Ko-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 15:25:31 +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 h3LFPKla027291; Mon, 21 Apr 2003 11:25:20 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3LFPJWo028184; Mon, 21 Apr 2003 11:25:20 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3LFPIFJ003576; Mon, 21 Apr 2003 11:25:19 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h3LFPH8d008036; Mon, 21 Apr 2003 11:25:17 -0400 Subject: Re: concerned - RE: TXT records, are they alive? From: Greg Hudson To: Edward Lewis Cc: namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1050938714.1552.80.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 21 Apr 2003 11:25:17 -0400 X-Spam-Status: No, hits=-36.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_XIMIAN,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 Content-Transfer-Encoding: 7bit On Mon, 2003-04-21 at 09:44, Edward Lewis wrote: > Why do the application writers of this software opt to use an > existing RR in a manner not intended? Why are they unwilling to > define a new RR? A new RR type wouldn't be supported by the majority of deployed primary DNS servers for years. (djbdns allows you to input RRs of new types by giving the binary representation of the RR, but even that's not terribly friendly.) Even leaving aside operational issues associated with caches and secondary servers which don't do the right thing with new RR types, using a new RR type for your application would be a high barrier to entry. And they don't use a more generic RR type, like TXT or UNSPEC, because you'd have to parse a DNS packet to do so, which is a lot harder than calling gethostbyname() and comparing to a few IP addresses. > I'm not disappointed that developers do whatever they can to seek out > the path of least resistance towards meeting a goal. I'm > disappointed that the IETF hasn't carved a path - making it least > resistance - that meets high-quality engineering practice. What are we going to do, reconcieve DNS as a text protocol and add something akin to XML namespace support? I guess there's been periodic talk of a "next-generation DNS," but it would be one hell of a transition. -- to unsubscribe send a message to namedroppers-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 Apr 21 11:43: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 LAA20158 for ; Mon, 21 Apr 2003 11:42:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197dNT-0002LX-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 15:38:43 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 197dN7-0002Hk-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 15:38:21 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 364C6313; Mon, 21 Apr 2003 11:38:21 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 95E34356; Mon, 21 Apr 2003 11:38:20 -0400 (EDT) Received: from [192.136.136.46] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 192348; Mon, 21 Apr 2003 11:28:28 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <1050938714.1552.80.camel@error-messages.mit.edu> References: <1050938714.1552.80.camel@error-messages.mit.edu> Date: Mon, 21 Apr 2003 11:38:22 -0400 To: Greg Hudson From: Edward Lewis Subject: Re: concerned - RE: TXT records, are they alive? Cc: Edward Lewis , namedroppers@ops.ietf.org 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 11:25 -0400 4/21/03, Greg Hudson wrote: >A new RR type wouldn't be supported by the majority of deployed primary >DNS servers for years. (djbdns allows you to input RRs of new types by Is that because of the IETF bureaucracy or stubbornness of the code writers? >giving the binary representation of the RR, but even that's not terribly >friendly.) Even leaving aside operational issues associated with caches >and secondary servers which don't do the right thing with new RR types, >using a new RR type for your application would be a high barrier to >entry. True, if we had "unknown type code" support in the older code. >And they don't use a more generic RR type, like TXT or UNSPEC, because >you'd have to parse a DNS packet to do so, which is a lot harder than >calling gethostbyname() and comparing to a few IP addresses. Interesting - the API's surrounding DNS are lagging even more than the protocol and the server implementations. >What are we going to do, reconcieve DNS as a text protocol and add >something akin to XML namespace support? I guess there's been periodic >talk of a "next-generation DNS," but it would be one hell of a >transition. I was thinking more of the process. The process of following good engineering practices (including research, open discussion, documentation, testing, among others) shouldn't become so onerous that cutting corners on this is attractive. I wasn't thinking that we beef up DNS to do more, just to make sure those relying on DNS know what DNS is really about - and to make sure the DNS protocol designers know of the changing requirements imposed by the changing environment. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing." -- to unsubscribe send a message to namedroppers-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 Apr 21 11:45: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 LAA20233 for ; Mon, 21 Apr 2003 11:45:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197dQk-0002S9-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 15:42:06 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 197dQO-0002QY-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 15:41:44 +0000 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3LFfTlw006104; Mon, 21 Apr 2003 11:41:29 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3LFfTWo029326; Mon, 21 Apr 2003 11:41:29 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h3LFfSFJ003924; Mon, 21 Apr 2003 11:41:28 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h3LFfR0n008153; Mon, 21 Apr 2003 11:41:27 -0400 Subject: Re: concerned - RE: TXT records, are they alive? From: Greg Hudson To: Edward Lewis Cc: namedroppers@ops.ietf.org In-Reply-To: References: <1050938714.1552.80.camel@error-messages.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1050939686.1552.84.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 21 Apr 2003 11:41:27 -0400 X-Spam-Status: No, hits=-36.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_XIMIAN,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 Content-Transfer-Encoding: 7bit On Mon, 2003-04-21 at 11:38, Edward Lewis wrote: > At 11:25 -0400 4/21/03, Greg Hudson wrote: > >A new RR type wouldn't be supported by the majority of deployed primary > >DNS servers for years. (djbdns allows you to input RRs of new types by > > Is that because of the IETF bureaucracy or stubbornness of the code writers? Even if the IETF were a rubber stamp and the code writers were infinitely fast, people don't upgrade their server software very often. So you'd put new adopters of your application in the position of asking their DNS administrators to take a software upgrade and add records of a type they don't understand. -- to unsubscribe send a message to namedroppers-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 Apr 21 12:23: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 MAA21494 for ; Mon, 21 Apr 2003 12:23:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197e2A-0005Gq-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 16:20:46 +0000 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 197e1n-0005GR-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 16:20:23 +0000 Received: (qmail 6026 invoked by uid 1016); 21 Apr 2003 16:20:52 -0000 Date: 21 Apr 2003 16:20:52 -0000 Message-ID: <20030421162052.6025.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: concerned - RE: TXT records, are they alive? References: <1050938714.1552.80.camel@error-messages.mit.edu> 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 Greg Hudson writes: > leaving aside operational issues associated with caches > and secondary servers which don't do the right thing with new RR types You're talking about most versions of BIND deployed on the Internet. The bug wasn't fixed until 9.1. See http://cr.yp.to/djbdns/newtypes.html. > And they don't use a more generic RR type, like TXT or UNSPEC, because > you'd have to parse a DNS packet to do so, which is a lot harder than > calling gethostbyname() and comparing to a few IP addresses. Actually, the RBLs provided TXT records from the beginning (although the big ones that use BIND have dropped the TXT records to avoid some BIND performance problems), and most of the initial client implementations used those records. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 21 13:29: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 NAA23271 for ; Mon, 21 Apr 2003 13:29:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197f1N-0009tj-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 17:24:01 +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 197f0t-0009sI-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 17:23:31 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 73F7113967 for ; Mon, 21 Apr 2003 17:23:18 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: concerned - RE: TXT records, are they alive? In-Reply-To: Message from Edward Lewis of "Mon, 21 Apr 2003 09:44:32 -0400." X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 21 Apr 2003 17:23:18 +0000 Message-Id: <20030421172318.73F7113967@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 > Why do the application writers of this software opt to use an existing RR > in a manner not intended? Why are they unwilling to define a new RR? the biggest single reason is that bind was broken for many years in its handling of unknown resource record types. on the one hand we couldn't transfer or cache them if we didn't know their interior structure, and on another hand we compressed the interior structure in variance with the dictates of rfc1035. this pretty much made new rr types impossible to roll out, and although several did make it through, it took a decade for them to be widely usable. now that bind isn't broken in this way, and now that there are other widely deployed implementations (both open source and not), it's reasonable to consider putting more rrtypes into the field. however, institutional memory means we have some cultural inertia to overcome before this can happen. -------- another reason, which you aluded to, is that the ietf makes new rrtypes hard. again this is cultural -- our work is done in an environment where any single loudmouth bozo can so polarize the debate on any given issue that there will be no clear consensus. since ietf is open to all comers, there's apparently no fix for this other than to wait for people to move on to some other area. (this isn't iesg's fault, they'll approve anything that's technically reasonable and has WG consensus... and remember that our area director found some embarrassing glitches in the last thing he was asked to approve, and it became clear that not very many of us had actually read the thing that we claimed to have come to consensus on.) -- to unsubscribe send a message to namedroppers-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 Apr 21 13: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 NAA23643 for ; Mon, 21 Apr 2003 13:39:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197fCP-000Apf-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 17:35:25 +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 197fC2-000AkC-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 17:35:02 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B8C2B13967 for ; Mon, 21 Apr 2003 17:34:49 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: concerned - RE: TXT records, are they alive? In-Reply-To: Message from Greg Hudson of "21 Apr 2003 11:41:27 -0400." <1050939686.1552.84.camel@error-messages.mit.edu> X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 21 Apr 2003 17:34:49 +0000 Message-Id: <20030421173449.B8C2B13967@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 > Even if the IETF were a rubber stamp and the code writers were > infinitely fast, people don't upgrade their server software very often. upgrades of that kind for this reason are no longer nec'y. the need was due to errors in old versions of bind, which are no longer the majority and need not be coddled. current bind8 and bind9, and as far as i know current djbdns and mswin, are all capable of both caching and transferring rrtypes which were unknown at the time of the software's release, and all of them avoid compressing any rdata which was did not exist before rfc2181 (even though by law, this should apply to all rdatas after rfc1035.) > So you'd put new adopters of your application in the position of asking > their DNS administrators to take a software upgrade and add records of a > type they don't understand. not any more. and for bind's part in having made it once so, i apologize. -- to unsubscribe send a message to namedroppers-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 Apr 21 19:58: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 TAA09011 for ; Mon, 21 Apr 2003 19:58:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197l0o-000D3p-00 for namedroppers-data@psg.com; Mon, 21 Apr 2003 23:47:50 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 197l0T-000D3F-00 for namedroppers@ops.ietf.org; Mon, 21 Apr 2003 23:47:29 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h3LNid44015199; Mon, 21 Apr 2003 16:44:39 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Apr 2003 16:47:26 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Paul Vixie'" , namedroppers@ops.ietf.org Subject: RE: concerned - RE: TXT records, are they alive? Date: Mon, 21 Apr 2003 16:47:18 -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=-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 problem with TXT record is simply a result of an age old problem, how to support experimental deployment in a way that can transition to a permanent solution? Look at the number of X-Headers end up in use that should be commonly agreed standards. It is the same issue. The IETF has been burned both ways. In the past it would hand out numbers, they would get used and then there would be a need to fix something, only the existing deployment would be a fait acompli. The opposite problem is when the OID never gets assigned because someone is playing games fillibustering for three or four years so the draft never gets to RFC, the code points are never assigned. I don't think there is an ideal answer to the problem. At the moment the IETF is operating in fear of the unknown mode, its proceedures simply take too long for any viable product plan to depend on them. I have been waiting several years now for the OID for logotypes in certs to be assigned. TXT records do have deployment advantages, they also have major limitations, you cannot query for particular types of TXT record. They are perfectly adequate for proof of concept however. 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 Tue Apr 22 05:39: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 FAA01279 for ; Tue, 22 Apr 2003 05:39:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197u6W-000AN5-00 for namedroppers-data@psg.com; Tue, 22 Apr 2003 09:30:20 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 197u5W-000AKU-00 for namedroppers@ops.ietf.org; Tue, 22 Apr 2003 09:29:18 +0000 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h3M9TGSt014243 for ; Tue, 22 Apr 2003 11:29:16 +0200 Date: Tue, 22 Apr 2003 11:29:16 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: Re: concerned - RE: TXT records, are they alive? In-Reply-To: <20030421162052.6025.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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 21 Apr 2003, D. J. Bernstein wrote: > Greg Hudson writes: > > And they don't use a more generic RR type, like TXT or UNSPEC, because > > you'd have to parse a DNS packet to do so, which is a lot harder than > > calling gethostbyname() and comparing to a few IP addresses. > > Actually, the RBLs provided TXT records from the beginning (although the > big ones that use BIND have dropped the TXT records to avoid some BIND > performance problems), and most of the initial client implementations > used those records. Its worth noting that these RBL-client implementations merely checked for the existence of a record at the appropriate spot, and if it was a TXT record, quoted said TXT record in the rejection message. They didn't actually parse the TXT record that I'm aware of. This is more ontopic for spamtools or spam-L though, not namedroppers. --==-- Bruce. -- to unsubscribe send a message to namedroppers-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 Apr 22 11:17: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 LAA13406 for ; Tue, 22 Apr 2003 11:17:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197zNf-00057o-00 for namedroppers-data@psg.com; Tue, 22 Apr 2003 15:08:23 +0000 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #1) id 197zNJ-00057N-00 for namedroppers@ops.ietf.org; Tue, 22 Apr 2003 15:08:01 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id h3MF7veU029427 for ; Tue, 22 Apr 2003 11:07:57 -0400 (EDT) Received: from unknown(53.231.71.237) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAzoaqE5; Tue, 22 Apr 03 11:07:57 -0400 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003042211075703394 for ; Tue, 22 Apr 2003 11:07:57 -0400 Received: from wokcdts1.is.chrysler.com (extra.daimlerchrysler.com.names.do.not.resolve.sanely.on.the.inside.is.chrysler.com [53.230.102.56]) by shmrspr2-hme0.shdc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h3MF7vAm015339 for ; Tue, 22 Apr 2003 11:07:57 -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 h3MF7Ae9004532 for ; Tue, 22 Apr 2003 11:07:10 -0400 (EDT) Message-ID: <3EA55A9D.4EB8342C@daimlerchrysler.com> Date: Tue, 22 Apr 2003 11:07:10 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: concerned - RE: TXT records, are they alive? References: <1050938714.1552.80.camel@error-messages.mit.edu> 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 Greg Hudson wrote: > On Mon, 2003-04-21 at 09:44, Edward Lewis wrote: > > Why do the application writers of this software opt to use an > > existing RR in a manner not intended? Why are they unwilling to > > define a new RR? > > A new RR type wouldn't be supported by the majority of deployed primary > DNS servers for years. (djbdns allows you to input RRs of new types by > giving the binary representation of the RR, but even that's not terribly > friendly.) Even leaving aside operational issues associated with caches > and secondary servers which don't do the right thing with new RR types, > using a new RR type for your application would be a high barrier to > entry. > > And they don't use a more generic RR type, like TXT or UNSPEC, because > you'd have to parse a DNS packet to do so, which is a lot harder than > calling gethostbyname() and comparing to a few IP addresses. > > > I'm not disappointed that developers do whatever they can to seek out > > the path of least resistance towards meeting a goal. I'm > > disappointed that the IETF hasn't carved a path - making it least > > resistance - that meets high-quality engineering practice. > > What are we going to do, reconcieve DNS as a text protocol and add > something akin to XML namespace support? I guess there's been periodic > talk of a "next-generation DNS," but it would be one hell of a > transition. No, I don't think DNS needs to be completely reconceived as an XMLish text-based protocol, however, it *is* too difficult to introduce new RR types, and we should do something about it, IMO. Perhaps an XMLish protocol extension should be a fallback. E.g. if a resolver doesn't understand a particular RR type that it receives, it could make a special meta-query to the source of those RR's for the schema of the RR type, so that it knows how to store and forward the RR type properly. The extra resources consumed by these metaqueries would give operators an incentive to upgrade their software to versions that understand the new RR type(s) natively. -Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 22 11:46: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 LAA14242 for ; Tue, 22 Apr 2003 11:46:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 197zp0-0007Dy-00 for namedroppers-data@psg.com; Tue, 22 Apr 2003 15:36:38 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 197zoe-0007DE-00 for namedroppers@ops.ietf.org; Tue, 22 Apr 2003 15:36:16 +0000 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h3MFa2dH004813; Tue, 22 Apr 2003 11:36:11 -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 h3MFQJNP018766; Tue, 22 Apr 2003 11:26:19 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h3MFQHU8023996; Tue, 22 Apr 2003 11:26:17 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id h3MFQFIR019421; Tue, 22 Apr 2003 11:26:15 -0400 Subject: Re: concerned - RE: TXT records, are they alive? From: Greg Hudson To: Kevin Darcy Cc: namedroppers@ops.ietf.org In-Reply-To: <3EA55A9D.4EB8342C@daimlerchrysler.com> References: <1050938714.1552.80.camel@error-messages.mit.edu> <3EA55A9D.4EB8342C@daimlerchrysler.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1051025173.1552.95.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 22 Apr 2003 11:26:15 -0400 X-Spam-Status: No, hits=-36.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN,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 Content-Transfer-Encoding: 7bit On Tue, 2003-04-22 at 11:07, Kevin Darcy wrote: > No, I don't think DNS needs to be completely reconceived as an XMLish > text-based protocol, however, it *is* too difficult to introduce new > RR types, and we should do something about it, IMO. Perhaps an XMLish > protocol extension should be a fallback. E.g. if a resolver doesn't > understand a particular RR type that it receives, it could make a special > meta-query to the source of those RR's for the schema of the RR type, so > that it knows how to store and forward the RR type properly. The extra > resources consumed by these metaqueries would give operators an incentive > to upgrade their software to versions that understand the new RR > type(s) natively. This sounds easy enough to do within DNS, thus taking advantage of DNS caching. 35.rrtype.arpa RRTYPE "NAPTR" "22sssd" The trick, of course, is designing a schema language rich enough to describe the most complicated of existing records (probably SIG and KEY) as well as the most complicated of future records we hope to support. And an API which can take advantage of the schemas--easier in some programming languages than others. Well, it's an idea. I don't plan to take it any farther than that. -- to unsubscribe send a message to namedroppers-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 Apr 22 12:21: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 MAA15186 for ; Tue, 22 Apr 2003 12:21:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1980QH-000ALl-00 for namedroppers-data@psg.com; Tue, 22 Apr 2003 16:15:09 +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 1980Pu-000AFu-00 for namedroppers@ops.ietf.org; Tue, 22 Apr 2003 16:14:46 +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 h3MGEdh1026158; Tue, 22 Apr 2003 09:14:39 -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 h3MGEdBK003463; Tue, 22 Apr 2003 09:14:39 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h3MGEcRt003460; Tue, 22 Apr 2003 09:14:38 -0700 (PDT) Date: Tue, 22 Apr 2003 09:14:38 -0700 (PDT) Message-Id: <200304221614.h3MGEcRt003460@guava.araneus.fi> To: namedroppers@ops.ietf.org Subject: Re: concerned - RE: TXT records, are they alive? In-Reply-To: <3EA55A9D.4EB8342C@daimlerchrysler.com> References: <1050938714.1552.80.camel@error-messages.mit.edu> <3EA55A9D.4EB8342C@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: > No, I don't think DNS needs to be completely reconceived as an XMLish > text-based protocol, however, it *is* too difficult to introduce new > RR types, and we should do something about it, IMO. Perhaps an XMLish > protocol extension should be a fallback. E.g. if a resolver doesn't > understand a particular RR type that it receives, it could make a special > meta-query to the source of those RR's for the schema of the RR type, so > that it knows how to store and forward the RR type properly. You don't actually need a schema just to store and forward RRs of a new or unknown type; they can be handled as opaque data as described in draft-ietf-dnsext-unknown-rrs-05.txt. A standardized and published schema could be useful as a way of enabling human-readable entry and display of such RRs, but we should not make the operation of the core DNS protocol depend on it. -- 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 Apr 22 12:57:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16190 for ; Tue, 22 Apr 2003 12:57:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198108-000DQk-00 for namedroppers-data@psg.com; Tue, 22 Apr 2003 16:52:12 +0000 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #1) id 1980zl-000DO0-00 for namedroppers@ops.ietf.org; Tue, 22 Apr 2003 16:51:50 +0000 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.12.8/8.9.0) id h3MGn9pm023295 for ; Tue, 22 Apr 2003 12:49:09 -0400 (EDT) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAjNaWFT; Tue, 22 Apr 03 12:49:09 -0400 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 58) with SMTP id M2003042212513119593 for ; Tue, 22 Apr 2003 12:51:31 -0400 Received: from wokcdts1.is.chrysler.com (extra.daimlerchrysler.com.names.do.not.resolve.sanely.on.the.inside.is.chrysler.com [53.230.102.56]) by shmrspr2-hme0.shdc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h3MGpWAm014183 for ; Tue, 22 Apr 2003 12:51:32 -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 h3MGoie9005235 for ; Tue, 22 Apr 2003 12:50:44 -0400 (EDT) Message-ID: <3EA572E4.40105B56@daimlerchrysler.com> Date: Tue, 22 Apr 2003 12:50:44 -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: concerned - RE: TXT records, are they alive? References: <1050938714.1552.80.camel@error-messages.mit.edu> <3EA55A9D.4EB8342C@daimlerchrysler.com> <200304221614.h3MGEcRt003460@guava.araneus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit Andreas Gustafsson wrote: > Kevin Darcy writes: > > No, I don't think DNS needs to be completely reconceived as an XMLish > > text-based protocol, however, it *is* too difficult to introduce new > > RR types, and we should do something about it, IMO. Perhaps an XMLish > > protocol extension should be a fallback. E.g. if a resolver doesn't > > understand a particular RR type that it receives, it could make a special > > meta-query to the source of those RR's for the schema of the RR type, so > > that it knows how to store and forward the RR type properly. > > You don't actually need a schema just to store and forward RRs of a > new or unknown type; they can be handled as opaque data as described > in draft-ietf-dnsext-unknown-rrs-05.txt. A standardized and published > schema could be useful as a way of enabling human-readable entry and > display of such RRs, but we should not make the operation of the core > DNS protocol depend on it. Right, but treating unknown RRs opaquely has serious limitations, as you've noted in your draft. You don't know if the RR type causes Additional Section processing. You don't know how to do duplicate elimination properly (maybe one of the subfields of the RDATA is a name which should be compared case-insensitively, or maybe not). You don't know whether there are names in the RDATA which are forbidden to point to aliases. You don't know whether the RR type is a "singleton" or not. When treating the RRsets as opaque data, you must make very conservative assumptions, which might impair your ability to serve your RR-type-knowledgeable clients to the fullest extent that they may expect. A schema-based extension would at least provide a middle ground between full knowledge of the RR type (contingent on software upgrade), and the lowest-common-denominator "opaque data" solution you outline in your draft. I wouldn't make the "core DNS protocol" dependent on any such extension, however. If the resolver can't get the schema for a particular unknown RR type, the next fallback after that would be to treat it as opaque data. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 23 15:00: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 PAA00829 for ; Wed, 23 Apr 2003 15:00:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198PHI-000DWy-00 for namedroppers-data@psg.com; Wed, 23 Apr 2003 18:47:32 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 198PHC-000DW9-00 for namedroppers@ops.ietf.org; Wed, 23 Apr 2003 18:47:26 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3NIS5R03665 for ; Wed, 23 Apr 2003 11:28:05 -0700 Date: Wed, 23 Apr 2003 11:28:05 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 36: Consolidation of addressing information 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 Issue 36: Consolidation of addressing information Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 22, 2003 Reference: Document: LLMNR-17 Comment type: E Priority: 2 Section: 1, 2.4 Rationale/Explanation of issue: It is best to put information on link-scope addressing in a single place. In Section 1, change: "LLMNR queries are sent to and received on port TBD using a link-scope multicast address as specified in "Administratively Scoped IP Multicast" [RFC2365] for IPv4. The LLMNR link-scope multicast address to be used for IPv4 is 224.0.0.251. For IPv6, the LLMNR link-scope multicast address is TBD. Link-scope multicast addresses are used to prevent propagation of LLMNR traffic across routers, potentially flooding the network; for details, see Section 2.4. In circumstances described in Section 2.3, LLMNR queries can also be sent to a unicast address." To: "LLMNR queries are sent to and received on port TBD. Link-scope multicast addresses are used to prevent propagation of LLMNR traffic across routers, potentially flooding the network; for details, see Section 2.4. In circumstances described in Section 2.3, LLMNR queries can also be sent to a unicast address." In Section 2.4, change: "The IPv4 link-scope multicast address a given responder listens to, and to which a sender sends all queries, is 224.0.0.251. The IPv6 link- scope multicast address a given responder listens to, and to which a sender sends all queries, is TBD." To: "IPv4 administratively scoped multicast usage is specified in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope multicast address a given responder listens to, and to which a sender sends queries, is 224.0.0.251. The IPv6 link-scope multicast address a given responder listens to, and to which a sender sends all queries, is TBD." -- to unsubscribe send a message to namedroppers-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 Apr 23 15:00: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 PAA00853 for ; Wed, 23 Apr 2003 15:00:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198PAi-000Cu5-00 for namedroppers-data@psg.com; Wed, 23 Apr 2003 18:40:44 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 198PAd-000CsW-00 for namedroppers@ops.ietf.org; Wed, 23 Apr 2003 18:40:39 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3NILIY03300 for ; Wed, 23 Apr 2003 11:21:19 -0700 Date: Wed, 23 Apr 2003 11:21:18 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Minutes of the Wednesday, April 23 LLMNR conference call 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 Minutes of the Wednesday, April 23 LLMNR conference call Attendees: Bernard Aboba, Olafur G., Christian Huitema The focus of today's LLMNR conference call was Issue 33, sending of LLMNR PTR queries via unicast. In general, the feelings about the proposed change were positive, since this simplifies the protocol. However, some concerns were raised. It was noted that using TCP for unicast queries would make it harder to spoof unicast LLMNR queries and responses to those queries. Also setting TTL=1 on unicast queries and responses to those queries would help ensure that they travel only over the local link. To address those concerns, two new issues were opened up. Issue 34 deals with use of TCP for unicast queries, and Issue 35 deals with setting TTL=1. Proposed resolutions to Issues 33, 34 and 35 will be posted to the DNSEXT WG mailing list for discussion. Assuming that the response is positive, then the changes can be made. Since the proposed resolution to Issue 33 depends on resolutions for Issues 34 and 35, until Issues 34 and 35 are positively resolved, then Issue 33 cannot be accepted. With the addition of unicast PTR queries, the similarities of LLMNR to the ICMPv6 node information query become even greater. This is an issue that needs to be taken up by the IESG. However, it was noted that LLMNR can be implemented in user mode whereas the ICMPv6 information query needs to be implemented in kernel mode. Also, use of TCP for unicast query makes LLMNR less vulnerable to spoofing, which has been brought up as an issue with the ICMPv6 node information query. The LLMNR issues list is available at: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 23 15:00: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 PAA00871 for ; Wed, 23 Apr 2003 15:00:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198PGK-000DR4-00 for namedroppers-data@psg.com; Wed, 23 Apr 2003 18:46:32 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 198PGD-000DQk-00 for namedroppers@ops.ietf.org; Wed, 23 Apr 2003 18:46:26 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3NIR5P03615 for ; Wed, 23 Apr 2003 11:27:05 -0700 Date: Wed, 23 Apr 2003 11:27:04 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 35: IP TTL 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 Issue 35: IP TTL Submitter: Christian Huitema Submitter email address: huitema@microsoft.com Date first submitted: April 22, 2003 Reference: Document: LLMNR-17 Comment type: T Priority: S Section: 2, 2.5 Rationale/Explanation of issue: The current document is not explicit about use of TTL/Hop Limit in all circumstances. Assuming that unicast queries and responses to those queries are sent only over TCP with TTL=1, and that multicast queries are also sent with TTL=1 so as to avoid possible propagation beyond the local link, the only issue left is the TTL setting for responses to multicast queries. In Section 2, change: "[3] Upon the reception of the response, the sender verifies that the packet originated on-link (see Section 2.5 for details). If these conditions are met, then the sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response." To: "[3] Upon the reception of the response, the sender performs the checks described in Section 2.5. If these conditions are met, then the sender uses and caches the returned response. If not, then the sender ignores the response and continues waiting for the response." In Section 2.5, change: "The source address of LLMNR queries and responses MUST be "on link". The destination address of an LLMNR query MUST be a link-scope multicast address or an "on link" unicast address; the destination address of an LLMNR response MUST be an "on link" unicast address. For IPv4, an "on link" address is defined as a link-local address or an address whose prefix belongs to a subnet on the local link; for IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or an address whose prefix belongs to a subnet on the local link. A sender SHOULD prefer RRs including reachable addresses where RRs involving both reachable and unreachable addresses are returned in response to a query. In composing an LLMNR response, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the LLMNR response to 255. The sender MUST verify that the Hop Limit field in IPv6 header and TTL field in IPv4 header of each response to the LLMNR query is set to 255. If it is not, then sender MUST ignore the response. Since routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a neighbor. Implementation note: In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket options are used to set the TTL of outgoing unicast and multicast packets. The IP_RECVTTL socket option is available on some platforms to retrieve the IPv4 TTL of received packets with recvmsg(). [RFC2292] specifies similar options for setting and retrieving the IPv6 Hop Limit." To: "The source address of LLMNR queries and responses MUST be "on link". The destination address of an LLMNR query MUST be a link-scope multicast address or an "on link" unicast address; the destination address of an LLMNR response MUST be an "on link" unicast address. On receiving an LLMNR query, the responder MUST check whether it was sent to the LLMNR multicast address; if it was sent to another multicast address, then the query MUST be silently discarded. For IPv4, an "on link" address is defined as a link-local address or an address whose prefix belongs to a subnet on the local link; for IPv6 [RFC2460] an "on link" address is either a link-local address, defined in [RFC2373], or an address whose prefix belongs to a subnet on the local link. A sender SHOULD prefer RRs including reachable addresses where RRs involving both reachable and unreachable addresses are returned in response to a query. 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. In composing a multicast LLMNR query, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to 1. Even though LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Therefore setting the IPv6 Hop Limit or IPv4 TTL field to one provides an additional precaution against leakage of LLMNR traffic. In composing a response to a multicast 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. This is done so as to prevent the use of LLMNR for denial of service attacks across the Internet. Implementation note: In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket options are used to set the TTL of outgoing unicast and multicast packets. The IP_RECVTTL socket option is available on some platforms to retrieve the IPv4 TTL of received packets with recvmsg(). [RFC2292] specifies similar options for setting and retrieving the IPv6 Hop Limit." -- to unsubscribe send a message to namedroppers-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 Apr 23 15:02: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 PAA00919 for ; Wed, 23 Apr 2003 15:02:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198PCR-000D7U-00 for namedroppers-data@psg.com; Wed, 23 Apr 2003 18:42:31 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 198PCP-000D7I-00 for namedroppers@ops.ietf.org; Wed, 23 Apr 2003 18:42:29 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3NIN8C03405 for ; Wed, 23 Apr 2003 11:23:08 -0700 Date: Wed, 23 Apr 2003 11:23:08 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 33: PTR via Unicast 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 Issue 33 is given below. The proposed resolution is as follows: In Section 3, change: "[4] A sender SHOULD only send LLMNR queries for PTR RRs that represent addresses reachable on the link over which LLMNR is used." To: "[4] A sender SHOULD send LLMNR queries for PTR RRs via unicast over TCP, as specified in Section 2.3." Note: Acceptance of the proposed resolution to Issue 33 is dependent on acceptance of the proposed resolution to Issue 34 (to follow). --------------------------------------------------------------------- Issue 33: PTR via Unicast Submitter: Mika Liljeberg Submitter email address: mika.liljeberg@welho.com Date first submitted: April 17, 2003 Reference: Document: LLMNR-16 Comment type: T Priority: S Section: 3 Rationale/Explanation of issue: It occurs to me that it would be a whole lot simpler to do PTR queries using unicast. The LLMNR resolver could use a TTL=1 when sending the query. This way it would either get an immediate no-route response from the local TCPIP stack, a direct response from the holder of the address, or an ICMP time exceeded reply from the default router. Either way, the resolver wouldn't have to do any checking on the address. This approach has several benefits: 1) Immediate error response if there is no route for the address 2) Error response from default router if the address is off-link 3) LLMNR resolver does not need to do any checking on the address 4) Unicast is easier on the network Note that conflict resolution for addresses is taken care by DAD, so using unicast for PTR shouldn't make any difference there. Another assumption is that the PTR query is already vulnerable to spoofing on the local link, so, as long as we use TTL=1 for the query there should be no perceivable additional risk. -- to unsubscribe send a message to namedroppers-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 Apr 23 15:54: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 PAA00828 for ; Wed, 23 Apr 2003 15:00:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198PF2-000DNN-00 for namedroppers-data@psg.com; Wed, 23 Apr 2003 18:45:12 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 198PEf-000DKK-00 for namedroppers@ops.ietf.org; Wed, 23 Apr 2003 18:44:49 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3NIPSY03533 for ; Wed, 23 Apr 2003 11:25:28 -0700 Date: Wed, 23 Apr 2003 11:25:28 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 34: Unicast over TCP only 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 Issue 34: Unicast over TCP only Submitter: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 22, 2003 Reference: Document: LLMNR-17 Comment type: T Priority: S Section: 2.3, 2.6 Rationale/Explanation of issue: Doing unicast queries only over TCP will make LLMNR more resilient against spoofing. In Section 2.3, change: "A sender MUST NOT send a unicast LLMNR query except when: a. A sender repeats a query after it received a response to the previous LLMNR query with the TC bit set, 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. 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 or using EDNS0 with larger window 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 it." To: "Unicast LLMNR queries MUST be sent using TCP and TTL=1. Responses to unicast LLMNR queries also MUST be sent using TCP (using the same connection as the query) and TTL=1. If the response to a unicast LLMNR query is not sent using TCP, the query sender MUST silently discard the response. Unicast queries sent using UDP also MUST be silently discarded by the responder. Unicast queries SHOULD be sent when: a. A sender repeats a query after it received a response to the previous LLMNR multicast query with the TC bit set, 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. 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." In section 2.6, change: "In order to avoid synchronization, LLMNR queries and responses are delayed by a time uniformly distributed between 0 and 200 ms. If the LLMNR query is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a query in order to assure themselves that the query has been received by a host capable of responding to the query. Since a sender cannot know beforehand whether it will receive no response, one response, or more than one response to a query, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the query answered after the first response is received. LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described in [RFC2988], with a minimum timeout value of 300 ms. Retransmission SHOULD NOT be attempted more than 3 times." To: "In order to avoid synchronization, LLMNR queries and responses are delayed by a time uniformly distributed between 0 and 200 ms. If a multicast LLMNR query is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of a multicast query in order to assure themselves that the multicast query has been received by a host capable of responding to the query. Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one response to a multicast query, 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. LLMNR implementations SHOULD dynamically estimate the timeout value for multicast queries (LLMNR_TIMEOUT) on a per-interface basis, using the algorithms described in [RFC2988], with a minimum timeout value of 300 ms. Retransmission of multicast queries SHOULD NOT be attempted more than 3 times. Since unicast LLMNR queries must be sent using TCP, for these queries, retransmission behavior 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 Wed Apr 23 22:14: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 WAA18574 for ; Wed, 23 Apr 2003 22:14:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198W8R-000CAS-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 02:06:51 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 198W8O-000C9Q-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 02:06:48 +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 <0HDT00K2VSJNW8@eListX.com> for namedroppers@ops.ietf.org; Wed, 23 Apr 2003 22:06:59 -0400 (EDT) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h3O23SSI036320 for ; Wed, 23 Apr 2003 22:03:29 -0400 (EDT envelope-from ogud@ogud.com) Date: Wed, 23 Apr 2003 22:06:39 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Q-03: inclusion of KEY records in additional records section In-reply-to: <20030325122251.12ee18ff.Juergen@ripe.net> X-Sender: post@localhost To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030423144112.020542f8@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <200303241121.37529.davidb@verisignlabs.com> <200303192345.05600.davidb@verisignlabs.com> <5.1.1.6.2.20030324094803.023640f8@localhost> <200303241121.37529.davidb@verisignlabs.com> X-Spam-Status: No, hits=-15.1 required=5.0 tests=BAYES_01,IN_REP_TO,RCVD_IN_RFCI,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 After reading all the postings on this it is not clear to me what the working group wants. As far as I can tell there are 3 options have been put forward, to replace the RFC2535 rules (that do not make sense anymore). It is not clear if anyone of the proposals has a significantly more following than the other two. Listed below in order of frequency of inclusion of KEY RRset in additional section: 1. Always include covering KEY 2. Include covering KEY on referral only 3. Never Please express preference on which rule to pick, and why. If rule 1 or 2 is selected we need to set rules about inclusion order. Current RFC2535 rules say address glue has higher priority than KEY, this is a good rule. The open issue is do we need to specify in what order multiple KEY RRsets are included? Example: QNAME: com. QTYPE: NS Answer section: NS set signed by com. Additional section: glue addresses signed by gtld-servers.net. Should inability to include one or both of the KEY RRsets cause the TC bit to be set ? (RFC2535 said no) 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 Wed Apr 23 22:31: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 WAA19080 for ; Wed, 23 Apr 2003 22:31:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198WRM-000Ctw-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 02:26:24 +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 198WRJ-000Cte-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 02:26:21 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1043C7F; Thu, 24 Apr 2003 11:26:20 +0900 (JST) To: Bernard Aboba Cc: namedroppers@ops.ietf.org In-reply-to: aboba's message of Wed, 23 Apr 2003 11:21:18 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 Wednesday, April 23 LLMNR conference call From: itojun@iijlab.net Date: Thu, 24 Apr 2003 11:26:19 +0900 Message-Id: <20030424022620.1043C7F@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 >With the addition of unicast PTR queries, the >similarities of LLMNR to the ICMPv6 node information query >become even greater. This is an issue that needs to >be taken up by the IESG. However, it was noted that >LLMNR can be implemented in user mode whereas the >ICMPv6 information query needs to be implemented in >kernel mode. Also, use of TCP for unicast query >makes LLMNR less vulnerable to spoofing, which has >been brought up as an issue with the ICMPv6 node >information query. assuming that the OS kernel implements the current IPv6 raw socket standard, it is possible to implement ICMPv6 node information query client/server in the userland. 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 Wed Apr 23 22:34: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 WAA19154 for ; Wed, 23 Apr 2003 22:34:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198WTF-000D0y-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 02:28:21 +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 198WTD-000D0j-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 02:28:19 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 124E092; Thu, 24 Apr 2003 11:28:18 +0900 (JST) To: Bernard Aboba Cc: namedroppers@ops.ietf.org In-reply-to: aboba's message of Wed, 23 Apr 2003 11:23:08 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: Proposed Resolution to LLMNR Issue 33: PTR via Unicast From: itojun@iijlab.net Date: Thu, 24 Apr 2003 11:28:18 +0900 Message-Id: <20030424022818.124E092@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 >Issue 33 is given below. The proposed resolution is as follows: > >In Section 3, change: > >"[4] A sender SHOULD only send LLMNR queries for PTR RRs >that represent addresses reachable on the link >over which LLMNR is used." > >To: > >"[4] A sender SHOULD send LLMNR queries for PTR RRs >via unicast over TCP, as specified in Section 2.3." >Note: Acceptance of the proposed resolution to Issue 33 is dependent on >acceptance of the proposed resolution to Issue 34 (to follow). i don't think it necesary to require TCP here. 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 Apr 24 01:48: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 BAA24053 for ; Thu, 24 Apr 2003 01:48:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198ZXb-000NEQ-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 05:45:03 +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 198ZWu-000N9b-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 05:44:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 786111394B for ; Thu, 24 Apr 2003 05:44:07 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= of "Wed, 23 Apr 2003 22:06:39 -0400." <5.1.1.6.2.20030423144112.020542f8@localhost> X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 24 Apr 2003 05:44:07 +0000 Message-Id: <20030424054407.786111394B@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 > Listed below in order of frequency of inclusion of KEY RRset > in additional section: > 1. Always include covering KEY > 2. Include covering KEY on referral only > 3. Never > Please express preference on which rule to pick, and why. #3. the time the KEY is needed is the first time a validator sees a SIG with that keyname. there is no way for a server to know when that's occuring. including it every time the SIG is exposed (as in #1 above) would waste resources. including it only in the case of a referral (#2 above) misses the target since the next key the validator will need is in the child zone and won't be the one you're including. > Should inability to include one or both of the KEY RRsets cause the > TC bit to be set ? (RFC2535 said no) no. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 24 03: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 DAA07512 for ; Thu, 24 Apr 2003 03:58:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198bUs-00065F-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 07:50:22 +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 198bUp-00064W-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 07:50:20 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.6) with ESMTP id h3O7oFBd006005; Thu, 24 Apr 2003 09:50:15 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h3O7oFN3006004; Thu, 24 Apr 2003 09:50:15 +0200 (CEST) Message-Id: <200304240750.h3O7oFN3006004@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 24 Apr 2003 09:50:14 +0200 In-Reply-To: "=?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?='s message as of Apr 24, 4:20" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section 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 [Quoting =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=, on Apr 24, 4:20, in "Re: Q-03: inclusion ..."] > Additional section: glue addresses signed by gtld-servers.net. Glue was never to be signed, or has this been changed recently? -- 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 Thu Apr 24 04:35: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 EAA08223 for ; Thu, 24 Apr 2003 04:35:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198c8c-0009No-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 08:31:26 +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 198c8Z-0009Nc-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 08:31:24 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.6) with ESMTP id h3O8VLBd006182; Thu, 24 Apr 2003 10:31:21 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h3O8VLDe006181; Thu, 24 Apr 2003 10:31:21 +0200 (CEST) Message-Id: <200304240831.h3O8VLDe006181@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 24 Apr 2003 10:31:21 +0200 In-Reply-To: "Paul Vixie's message as of Apr 24, 7:53" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section X-Spam-Status: No, hits=-12.4 required=5.0 tests=BAYES_01,IN_REP_TO,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 [Quoting Paul Vixie, on Apr 24, 7:53, in "Re: Q-03: inclusion ..."] > #3. the time the KEY is needed is the first time a validator sees a SIG > with that keyname. there is no way for a server to know when that's > occuring. .. I'm getting very confused now... The whole point of authenticated denial of existance plus verifyable unsecurity, and thus why we need NXTs (see Note-1)) was, IMHO, exactly to make sure that the resolver (see Note-2) "knows" when a SIG must be present. Note-1: And why some want OptIn to get rid of those NXT's where possible again. Note-2: I see that Paul writes "validator" and "server" above, I'm not sure which validator/server that is supposed to be, I guess a server acting as secure aware caching forwarder? Background: In designing the resolver software, we constantly run against this problem. In short, we are still debating which way to go: 1. Should the resolver go down the tree, determining the security status, and validating the chain of trust on the way. 2. Should the (stub-)resolver go right for the answer at the nearest caching forwarder, then ask for a SIG and then chase the chain of trust up the tree for validation? 3. Should we forget dealing with validation in the stubresolver and trust secure aware caching forwarders? Ad 1. This means "a full service resolver", capable of following delegations. This is a much more complicated beast than the current stubresolvers we all use. If we go this way, some implementations may choose to go right to the auth. servers instead of using a caching forwarder. And this, in turn, may present a high load on the DNS system. Advantage of this scheme is that we don't need secure aware caching forwarders. Ad 2. Extending a stubresolver to do this is easy. However, it means that if no SIG is found, the resolver is in the dark whether the RR is verifyably unsecure or spoofed. Thus we need to go top-down after all to check for possible verifyable unsecurity? Ad 3. For this we need first to trust the secure aware caching forwarder and second to have some secure communication with it. TSIG works, but will not scale, I have not seen other implementations yet. We think 1. is the most feasible way, and that leads to the wish to get KEYs in the additional section when going into a delegation. -- 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 Thu Apr 24 05:06: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 FAA08945 for ; Thu, 24 Apr 2003 05:06:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198ce1-000CCz-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 09:03:53 +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 198cdx-000CCC-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 09:03:49 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.6) with ESMTP id h3O93kBd006338; Thu, 24 Apr 2003 11:03:46 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h3O93kAT006337; Thu, 24 Apr 2003 11:03:46 +0200 (CEST) Message-Id: <200304240903.h3O93kAT006337@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 24 Apr 2003 11:03:46 +0200 In-Reply-To: "=?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?='s message as of Apr 24, 4:20" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section 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 [Quoting =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=, on Apr 24, 4:20, in "Re: Q-03: inclusion ..."] > Listed below in order of frequency of inclusion of KEY RRset > in additional section: > 1. Always include covering KEY > 2. Include covering KEY on referral only > 3. Never > Please express preference on which rule to pick, and why. It should be 3: IMHO, one needs the KEY before we get anything else from a child to determine the security status. Then we go ask for specific RRs, and we don't need the KEY in the additional section as we have it already. Said differently: -- suppose we want: A host.dom.top. suppose we have: KEY from root preconfigured -- we ask "A host.dom.top." at a rootserver we get NS-glue plus DS+SIG for top from rootserver we check DS+SIG with KEY from root -- we ask KEY RRset for top from top-server we check the KEY RRset with the DS now we know that top is secured, that the delegation is valid, and we have the KEY. -- we ask "A host.dom.top." at a top-server we get NS-glue plus DS+SIG for dom.top. from top-server we check DS+SIG with KEY from top. -- we ask KEY RRset for dom.top from dom.top server we check the KEY RRset with the DS now we know that dom.top-server is secured, that the delegation is valid, and we have the KEY. -- we ask "A host.dom.top." at a dom.top server we get A host.dom.top + SIG we check the sig with the dom.top KEY Thus: the moment we need the KEY we must ask for it anyway, it is never useful as additional info with other queries as we should have the KEY (== the security status) already by then. > If rule 1 or 2 is selected we need to set rules about inclusion order. not applicable, as 3 was selected. > Should inability to include one or both of the KEY RRsets cause the > TC bit to be set ? (RFC2535 said no) No. -- 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 Thu Apr 24 05:12: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 FAA09108 for ; Thu, 24 Apr 2003 05:12:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198cjw-000ClM-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 09:10:00 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 198cjt-000Cl6-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 09:09:57 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h3O99uSs018723; Thu, 24 Apr 2003 11:09:56 +0200 Date: Thu, 24 Apr 2003 11:09:56 +0200 From: "Olaf M. Kolkman" To: ted@NLnetLabs.nl (Ted Lindgreen) Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section Message-Id: <20030424110956.7617b290.olaf@ripe.net> In-Reply-To: <200304240831.h3O8VLDe006181@open.nlnetlabs.nl> References: <200304240831.h3O8VLDe006181@open.nlnetlabs.nl> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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, 24 Apr 2003 10:31:21 +0200 ted@NLnetLabs.nl (Ted Lindgreen) wrote: > [Quoting Paul Vixie, on Apr 24, 7:53, in "Re: Q-03: inclusion ..."] > > > #3. the time the KEY is needed is the first time a validator sees a SIG > > with that keyname. there is no way for a server to know when that's > > occuring. .. > > I'm getting very confused now... > > The whole point of authenticated denial of existance plus verifyable > unsecurity, and thus why we need NXTs (see Note-1)) was, IMHO, > exactly to make sure that the resolver (see Note-2) "knows" when a > SIG must be present. > The way I read this: An security aware server will not know if a validator (a client that verifies the DNS data) already has a KEY in its cache. Only if the validators cache sees a SIG made with a given key for the _first_ time it will need to go and fetch that key. In other words once you verified one piece of zone data you have cached the key-set to verify all the other pieces of zone data. The question if the client (the validator in this case) needs to validate the SIG i.e. if the validator is looking at data that is in secure or insecure namespace (from the validators perspective) is irrelevant to the inclussion of the KEY in the additional section at the server side. Based on it's idea about the security status of a zone a validator will know that it will have to get the key and verify the data. > Ad 1. This means "a full service resolver", capable of following > delegations. This is a much more complicated beast than > the current stubresolvers we all use. If we go this way, > some implementations may choose to go right to the auth. > servers instead of using a caching forwarder. And this, > in turn, may present a high load on the DNS system. > Advantage of this scheme is that we don't need secure > aware caching forwarders. (...) > We think 1. is the most feasible way, and that leads to the > wish to get KEYs in the additional section when going into > a delegation. This is also the method that Juergen Pfleger (our student intern who looked at the algorithm for a secure caching resolver) followed, we think that is the most feasible way to. The crux is that you will get a delegation with a DS RR (or the NXT RR proving the DS non-existence) that is signed with the zone-signin key from the parent. At the first delegation from parent to child you have to do an extra query but once you had one delegation from the parent you will have a fair change that key still lives in your cache. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-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 Apr 24 05:48: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 FAA09707 for ; Thu, 24 Apr 2003 05:48:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198dJE-000GCv-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 09:46:28 +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 198dJA-000GCZ-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 09:46:24 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.6) with ESMTP id h3O9kMBd006688; Thu, 24 Apr 2003 11:46:22 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h3O9kLXd006687; Thu, 24 Apr 2003 11:46:21 +0200 (CEST) Message-Id: <200304240946.h3O9kLXd006687@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Thu, 24 Apr 2003 11:46:21 +0200 In-Reply-To: ""Olaf M. Kolkman"'s message as of Apr 24, 11:09" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Olaf M. Kolkman" , ted@NLnetLabs.nl (Ted Lindgreen) Subject: Re: Q-03: inclusion of KEY records in additional records section Cc: Paul Vixie , namedroppers@ops.ietf.org 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 [Quoting "Olaf M. Kolkman", on Apr 24, 11:09, in "Re: Q-03: inclusion ..."] > On Thu, 24 Apr 2003 10:31:21 +0200 > ted@NLnetLabs.nl (Ted Lindgreen) wrote: > > > [Quoting Paul Vixie, on Apr 24, 7:53, in "Re: Q-03: inclusion ..."] > > > > > #3. the time the KEY is needed is the first time a validator sees a SIG > > > with that keyname. there is no way for a server to know when that's > > > occuring. .. > > > > I'm getting very confused now... > > > > The whole point of authenticated denial of existance plus verifyable > > unsecurity, and thus why we need NXTs (see Note-1)) was, IMHO, > > exactly to make sure that the resolver (see Note-2) "knows" when a > > SIG must be present. > > > > > The way I read this: > > An security aware server will not know if a validator (a client that > verifies the DNS data) already has a KEY in its cache. Only if the > validators cache sees a SIG made with a given key for the _first_ time > it will need to go and fetch that key. OK, yes, I misinterpreted Pauls sentence, I'm sorry. But for the end result it does not matter: Paul, you and me, we all agree that the KEY should not be included in the additional section, because the validator very likely already has it cached. -- 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 Thu Apr 24 10:02: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 KAA16576 for ; Thu, 24 Apr 2003 10:02:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198h8k-000HYg-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 13:51:54 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 198h8i-000HYU-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 13:51:53 +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 <0HDU0049QP6TG3@eListX.com> for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 09:52:05 -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 h3ODmQQZ038272; Thu, 24 Apr 2003 09:48:29 -0400 (EDT envelope-from ogud@ogud.com) Date: Thu, 24 Apr 2003 09:51:40 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Q-03: inclusion of KEY records in additional records section In-reply-to: <200304240750.h3O7oFN3006004@open.nlnetlabs.nl> X-Sender: post@localhost To: ted@NLnetLabs.nl (Ted Lindgreen), namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030424094752.02055928@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <"Ólafur Guðmundsson's message as of Apr 24, 4:20"@eListX.com> X-Spam-Status: No, hits=-31.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,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 At 03:50 2003-04-24, Ted Lindgreen wrote: >[Quoting =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=, on Apr >24, 4:20, in "Re: Q-03: inclusion ..."] > > > Additional section: glue addresses signed by gtld-servers.net. > >Glue was never to be signed, or has this been changed recently? > >-- ted In this case the server is authoritative for .com and gtld-servers.net., so in this case the use of the word "glue" is wrong, but I'm not sure what the right term is ? 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 Apr 24 10:24: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 KAA18165 for ; Thu, 24 Apr 2003 10:24:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198hXL-000KjC-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 14:17:19 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 198hXI-000Kiw-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 14:17:16 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 92ACD45C; Thu, 24 Apr 2003 10:17:13 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 0175A458; Thu, 24 Apr 2003 10:17:13 -0400 (EDT) Received: from [192.136.136.24] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 196214; Thu, 24 Apr 2003 10:07:10 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <5.1.1.6.2.20030423144112.020542f8@localhost> References: <200303241121.37529.davidb@verisignlabs.com> <200303192345.05600.davidb@verisignlabs.com> <5.1.1.6.2.20030324094803.023640f8@localhost> <200303241121.37529.davidb@verisignlabs.com> <5.1.1.6.2.20030423144112.020542f8@localhost> Date: Thu, 24 Apr 2003 10:17:15 -0400 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= From: Edward Lewis Subject: Re: Q-03: inclusion of KEY records in additional records section Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA18165 At 22:06 -0400 4/23/03, Ólafur Guðmundsson wrote: > 3. Never There are two reasons not to include the KEY RR. 1) We should return to the basic premise of the DNS protocol - given a query for the Q-trinity (QNAME, QCLASS, QTYPE) you should get back a specific response for that. Whenever we are throwing in more than that, we engender "special processing" which is a disease in the DNS protocol. Because of this, let the verifier decide if it needs to ask the resolver to get the KEY set. This moves the smarts outward to the edge of the network. Don't make the server make the determination - let the server get dumber. This is an architectural reason. 2) Including the KEY RR in every message requires the message be expanded by that many bytes. Worse yet, if the KEY RR's failure to fit causes a TC bit and TCP retry, we also see more packets and latency (round trips). A side issue of larger and more data transfer is the impact on ill-adjusted intrusion detection systems, etc., that overreact (seen it). Since it is not clear that the KEY RR is needed in each answer, operationally, this is a poor choice. However, if we observe a lot of queries for the KEY RR, it might be an overall savings to just throw them in there. --- Architecturally, it's a bad idea to include the KEY RR set. Operationally, there's a slim chance it would be a helpful optimization. Based on this, I would urge that for now we say "never" (or almost never) and look to see if there are excessive KEY RR lookups that result from this choice. If so, then we consider recommending that KEY RR's are added. I would require resolvers to work with or without the KEY RR in the answer, so they won't need to be updated if the time comes. (The verifier should drive what's needed, if the set is not in cache, it should ask for the KEY RR set over the net.) I would specify that serves are either "RECOMMENDED NOT TO" or "SHOULD NOT" include the KEY RR's. I would avoid a "MUST NOT" here as the inclusion of the KEY RR (set) is not likely to cause damage to the protocol or the network. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer A compiler-directive person living in an HTML-tagged world. -- to unsubscribe send a message to namedroppers-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 Apr 24 11:35: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 LAA20202 for ; Thu, 24 Apr 2003 11:35:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198iem-0004BE-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 15:29:04 +0000 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 198iek-0004B0-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 15:29:02 +0000 Received: from pinion.admin.cto.netsol.com (scooter.bo.verisignlabs.com [::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Thu, 24 Apr 2003 10:51:07 -0400 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section Date: Thu, 24 Apr 2003 11:27:52 -0400 User-Agent: KMail/1.5 References: <20030424054407.786111394B@sa.vix.com> In-Reply-To: <20030424054407.786111394B@sa.vix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304241127.52088.davidb@verisignlabs.com> X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,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 Content-Transfer-Encoding: 7bit On Thursday 24 April 2003 01:44 am, Paul Vixie wrote: > > Listed below in order of frequency of inclusion of KEY RRset > > in additional section: > > 1. Always include covering KEY > > 2. Include covering KEY on referral only > > 3. Never > > Please express preference on which rule to pick, and why. > > #3. the time the KEY is needed is the first time a validator sees a SIG > with that keyname. there is no way for a server to know when that's > occuring. including it every time the SIG is exposed (as in #1 above) > would waste resources. including it only in the case of a referral (#2 > above) misses the target since the next key the validator will need is > in the child zone and won't be the one you're including. Would choosing option #1 waste resources that are important? I can see how it will make response sizes larger, but so what? Bandwidth gets cheaper over time, and DNS is already a near insignificant portion of overall IP traffic. What other resources does this waste? Choosing #3 forces more round trips. Network latency has a fixed upper limit. Of course, more round trips does not ncessarily mean more latency on the query as a whole, as clients can do parallel queries. I'm just trying to make sure that we are optimizing the right thing here. > > Should inability to include one or both of the KEY RRsets cause the > > TC bit to be set ? (RFC2535 said no) > > no. If this remains true, then option #1 would effectively be an unenforceable recommendation. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 24 12:09:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21703 for ; Thu, 24 Apr 2003 12:09:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198jEi-0008xY-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 16:06:12 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 198jEe-0008xE-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 16:06:09 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 6BD55302; Thu, 24 Apr 2003 12:06:08 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 94C9A26B; Thu, 24 Apr 2003 12:06:07 -0400 (EDT) Received: from [192.136.136.24] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 196374; Thu, 24 Apr 2003 11:56:05 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <200304241127.52088.davidb@verisignlabs.com> References: <20030424054407.786111394B@sa.vix.com> <200304241127.52088.davidb@verisignlabs.com> Date: Thu, 24 Apr 2003 12:06:08 -0400 To: David Blacka From: Edward Lewis Subject: Re: Q-03: inclusion of KEY records in additional records section Cc: namedroppers@ops.ietf.org 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 11:27 -0400 4/24/03, David Blacka wrote: >Would choosing option #1 waste resources that are important? I can see how >it will make response sizes larger, but so what? Bandwidth gets cheaper >over time, and DNS is already a near insignificant portion of overall IP >traffic. What other resources does this waste? > >Choosing #3 forces more round trips. Network latency has a fixed upper >limit. Of course, more round trips does not ncessarily mean more latency >on the query as a whole, as clients can do parallel queries. I effectively disagreed with this - with the rationale that if we start out with the smaller answers we could 1) determine that they were sufficent or 2) observer that we need to do option 1. If we start out with the larger answers, we might 1) not realize that smaller would be better or 2) not realize we made the right choice. I also think that switching from #3 to #1 isn't that hard to deploy. This all assumes that we have no sufficiently large test bed in which to try and measure the options. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer A compiler-directive person living in an HTML-tagged world. -- to unsubscribe send a message to namedroppers-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 Apr 24 12:50: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 MAA23212 for ; Thu, 24 Apr 2003 12:50:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198jqw-000EnF-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 16:45:42 +0000 Received: from mail-out2.apple.com ([17.254.0.51]) by psg.com with esmtp (Exim 3.36 #1) id 198jqu-000En3-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 16:45:40 +0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h3OGjdQd026621 for ; Thu, 24 Apr 2003 09:45:39 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 24 Apr 2003 09:45:28 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h3OGjdVX025139 for ; Thu, 24 Apr 2003 09:45:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v568.1) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2DA94EC1-7674-11D7-A77D-000A959D832C@apple.com> Content-Transfer-Encoding: 7bit From: Joshua Graessley Subject: Re: LLMNR Issue 34: Unicast over TCP only Date: Thu, 24 Apr 2003 09:45:38 -0700 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.568.1) X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,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 If unicast TCP queries with a TTL of 1 are used, it seems quite likely that PTR queries using LLMNR that could have succeeded will fail in cases where more than one ip subnet is present on the local link. If my machine does not have a routing entry, it will send the packet to the router, which will presumably decrement the TTL and put the packet back on the same link. Since the TTL is set to 1 my packet would be dropped. If I sent the same query using multicast, the device on the same link would have a chance to respond. This TTL=1 setting may get us in a bind of a response to an LLMNR query sets the TC bit and the source address of the response is on a different subnet. I also think that for queries in certain domains, LLMNR should always be used. It makes sense to use LLMNR for queries with names ending in "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa.". I oppose issue 33, 34 and 35. -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 Apr 24 12:52: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 MAA23259 for ; Thu, 24 Apr 2003 12:52:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198jsn-000F5P-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 16:47:37 +0000 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 198jsi-000F56-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 16:47:32 +0000 Received: from pinion.admin.cto.netsol.com (scooter.bo.verisignlabs.com [::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Thu, 24 Apr 2003 12:09:36 -0400 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section Date: Thu, 24 Apr 2003 12:46:20 -0400 User-Agent: KMail/1.5 References: <20030424054407.786111394B@sa.vix.com> <200304241127.52088.davidb@verisignlabs.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200304241246.20838.davidb@verisignlabs.com> 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 Content-Transfer-Encoding: 7bit On Thursday 24 April 2003 12:06 pm, Edward Lewis wrote: > At 11:27 -0400 4/24/03, David Blacka wrote: > >Would choosing option #1 waste resources that are important? I can see how > >it will make response sizes larger, but so what? Bandwidth gets cheaper > >over time, and DNS is already a near insignificant portion of overall IP > >traffic. What other resources does this waste? > > > >Choosing #3 forces more round trips. Network latency has a fixed upper > >limit. Of course, more round trips does not ncessarily mean more latency > >on the query as a whole, as clients can do parallel queries. > > I effectively disagreed with this - with the rationale that if we > start out with the smaller answers we could 1) determine that they > were sufficent or 2) observer that we need to do option 1. If we > start out with the larger answers, we might 1) not realize that > smaller would be better or 2) not realize we made the right choice. Ok, I think I get it. You are saying that we don't know which approach is more efficient and we should be recommending a path that will make it apparent which approach is better. > I also think that switching from #3 to #1 isn't that hard to deploy. I agree, as long as the specification makes it clear the KEY rrsets MAY be included in the additional section of a response and that caches should accept, use and cache these RRsets. If we go so far as to remove all additional processing considerations for KEY, then I think it would be difficult to switch. Or maybe just useless to switch. So, Ed, what I think you are driving toward is allowing servers to include KEY rrsets in the additional section (either all the time or just some of the time) but recommending that they do not. Or am I going to far? I like this, but I think it makes figuring out how to write an efficient client sort of harder. Does the client, when querying a known or suspected secure zone for which it does not have a keyset issue a parallel query or not? If we choose option #1 then maybe clients don't have to implement parallel queries? -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 24 12:57: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 MAA23376 for ; Thu, 24 Apr 2003 12:57:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198jxj-000Fou-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 16:52:43 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 198jxg-000Fog-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 16:52:40 +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 h3OGsLRH022186; Thu, 24 Apr 2003 19:54:22 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h3OGsHgT022185; Thu, 24 Apr 2003 19:54:17 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Proposed Resolution to LLMNR Issue 33: PTR via Unicast From: Mika Liljeberg To: itojun@iijlab.net Cc: Bernard Aboba , namedroppers@ops.ietf.org In-Reply-To: <20030424022818.124E092@coconut.itojun.org> References: <20030424022818.124E092@coconut.itojun.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1051203256.14360.7.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 24 Apr 2003 19:54:17 +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 Thu, 2003-04-24 at 05:28, itojun@iijlab.net wrote: > >"[4] A sender SHOULD send LLMNR queries for PTR RRs > >via unicast over TCP, as specified in Section 2.3." > >Note: Acceptance of the proposed resolution to Issue 33 is dependent on > >acceptance of the proposed resolution to Issue 34 (to follow). > > i don't think it necesary to require TCP here. I agree. Connection hijacking on the local link is easy, so using TCP doesn't provide any additional protection. Besides, certain restricted devices equipped with a minimal protocol stack might only support UDP. 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 Apr 24 13:39: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 NAA24835 for ; Thu, 24 Apr 2003 13:39:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198kYu-000LPM-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 17:31:08 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 198kYr-000LPA-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 17:31:05 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A7407417; Thu, 24 Apr 2003 13:31:04 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 143C8416; Thu, 24 Apr 2003 13:31:04 -0400 (EDT) Received: from [192.136.136.24] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 196467; Thu, 24 Apr 2003 13:21:01 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <200304241246.20838.davidb@verisignlabs.com> References: <20030424054407.786111394B@sa.vix.com> <200304241127.52088.davidb@verisignlabs.com> <200304241246.20838.davidb@verisignlabs.com> Date: Thu, 24 Apr 2003 13:31:06 -0400 To: David Blacka From: Edward Lewis Subject: Re: Q-03: inclusion of KEY records in additional records section Cc: namedroppers@ops.ietf.org 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:46 -0400 4/24/03, David Blacka wrote: >Ok, I think I get it. You are saying that we don't know which approach is >more efficient and we should be recommending a path that will make it >apparent which approach is better. That is one of my arguments. Thinking about it, I would have placed the architectural one and the IDS going ape ones first, but what you said above is the most important concern. It might be that #1 is better than #3, but I can't see it and sort of feel that if we choose #3 now, the answer will be clear. >... as long as the specification makes it clear the KEY rrsets MAY be >included in the additional section of a response and that caches should >accept, use and cache these RRsets. If we go so far as to remove all >additional processing considerations for KEY, then I think it would be >difficult to switch. Or maybe just useless to switch. That's a vital point. I am assuming that clients are agile (liberal in what they deal with while the servers are conservative in the range of answers they give). >So, Ed, what I think you are driving toward is allowing servers to include >KEY rrsets in the additional section (either all the time or just some of >the time) but recommending that they do not. Or am I going to far? That's the right level. I can't see banning the practice, but I'd like to discourage it if only to provide a 'control group' for the experiment (to see if #1 or #3 is the right approach). >I like this, but I think it makes figuring out how to write an efficient >client sort of harder. Does the client, when querying a known or >suspected secure zone for which it does not have a keyset issue a parallel >query or not? If we choose option #1 then maybe clients don't have to >implement parallel queries? My assumption, rightly or wrongly, is that this isn't a problem. Keep in mind that I'm one step up from a tourist when it comes to writing resolvers, the last one I did was 6 years ago and was just dig with a verifier. I.e., I didn't dabble in parallelism in anyway and didn't try to optimize performance. I do have a faint recollection of being shown, by another implementer, that a deadlock was possible if parallel queries went awry. It would be good to get an opinion from someone who's given more recent thought to the implications of this on the resolver (as in - has cut code). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer A compiler-directive person living in an HTML-tagged world. -- to unsubscribe send a message to namedroppers-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 Apr 24 14:30: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 OAA26172 for ; Thu, 24 Apr 2003 14:30:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198lPs-0003Ri-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 18:25:52 +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 198lPq-0003RH-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 18:25:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E6FD81398E for ; Thu, 24 Apr 2003 18:25:36 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= of "Thu, 24 Apr 2003 09:51:40 -0400." <5.1.1.6.2.20030424094752.02055928@localhost> X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 24 Apr 2003 18:25:36 +0000 Message-Id: <20030424182536.E6FD81398E@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 > > > Additional section: glue addresses signed by gtld-servers.net. > > > >Glue was never to be signed, or has this been changed recently? > > In this case the server is authoritative for .com and gtld-servers.net., > so in this case the use of the word "glue" is wrong, but I'm not sure > what the right term is ? it's still glue. the protocol doesn't permit a client to impute authority of additional data based on name-similarity to data in other sections which is claimed as 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 Thu Apr 24 14:42: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 OAA26950 for ; Thu, 24 Apr 2003 14:42:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198lcF-0005Ty-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 18:38:39 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 198lcA-0005LX-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 18:38:34 +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 h3OIe4RH022581; Thu, 24 Apr 2003 21:40:04 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h3OIe2bp022564; Thu, 24 Apr 2003 21:40:02 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR Issue 34: Unicast over TCP only From: Mika Liljeberg To: Joshua Graessley Cc: namedroppers@ops.ietf.org In-Reply-To: <2DA94EC1-7674-11D7-A77D-000A959D832C@apple.com> References: <2DA94EC1-7674-11D7-A77D-000A959D832C@apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1051209601.14360.19.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 24 Apr 2003 21:40:01 +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 Josh, On Thu, 2003-04-24 at 19:45, Joshua Graessley wrote: > If unicast TCP queries with a TTL of 1 are used, it seems quite likely > that PTR queries using LLMNR that could have succeeded will fail in > cases where more than one ip subnet is present on the local link. If my > machine does not have a routing entry, it will send the packet to the > router, which will presumably decrement the TTL and put the packet back > on the same link. Since the TTL is set to 1 my packet would be dropped. > If I sent the same query using multicast, the device on the same link > would have a chance to respond. This seems a bit far fetched. Do you have a real world example in mind? Note that if we want to support something like this, we really have no choice but try all PTR queries with LLMNR, since there is no way to tell which destination addresses the default router might bounce back to the local link. > This TTL=1 setting may get us in a bind of a response to an LLMNR query > sets the TC bit and the source address of the response is on a > different subnet. > > I also think that for queries in certain domains, LLMNR should always > be used. It makes sense to use LLMNR for queries with names ending in > "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa.". I think I agree, although I would reverse this and say that it does not make sense to send these PTR queries to a DNS server, so that phase may be skipped. 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 Apr 24 15:52: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 PAA00466 for ; Thu, 24 Apr 2003 15:52:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198mbz-0005yV-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 19:42:27 +0000 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 198mbS-0005xO-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 19:41:55 +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 h3OJfrm16843 for ; Thu, 24 Apr 2003 21:41:53 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h3OJfq025211 for ; Thu, 24 Apr 2003 21:41:52 +0200 (MEST) Message-Id: <200304241941.h3OJfq025211@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section In-reply-to: Your message of "Thu, 24 Apr 2003 18:25:36 -0000." <20030424182536.E6FD81398E@sa.vix.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Thu, 24 Apr 2003 21:41:52 +0200 From: Peter Koch X-Spam-Status: No, hits=-27.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,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 Paul Vixie wrote: > > In this case the server is authoritative for .com and gtld-servers.net., > > so in this case the use of the word "glue" is wrong, but I'm not sure > > what the right term is ? > > it's still glue. the protocol doesn't permit a client to impute authority it's not. "glue" is a term for data origin, i.e. there's a difference between additional data and "glue". The client can't tell that difference. > of additional data based on name-similarity to data in other sections which > is claimed as authoritative. Well, the client may not, but why shouldn't the server feed the additional section with authoritative data - if it's signed? -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 Thu Apr 24 16:35: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 QAA02237 for ; Thu, 24 Apr 2003 16:35:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198nJn-000DPh-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 20:27: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 198nJl-000DPF-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 20:27:41 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3DF3313984 for ; Thu, 24 Apr 2003 20:27:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section In-Reply-To: Message from Peter Koch of "Thu, 24 Apr 2003 21:41:52 +0200." <200304241941.h3OJfq025211@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.2+cvs; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 24 Apr 2003 20:27:28 +0000 Message-Id: <20030424202728.3DF3313984@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 > > > In this case the server is authoritative for .com and > > > gtld-servers.net., so in this case the use of the word "glue" is > > > wrong, but I'm not sure what the right term is ? > > > > it's still glue. the protocol doesn't permit a client to impute > > authority ... > > it's not. "glue" is a term for data origin, i.e. there's a difference > between additional data and "glue". The client can't tell that > difference. correct, it may or may not be glue, depending on how deep the owner names are. and because the client can't tell the difference, it has to be presumed "glue" or at least NOT presumed to be "authoritative". > > ... of additional data based on name-similarity to data in other > > sections which is claimed as authoritative. > > Well, the client may not, but why shouldn't the server feed the > additional section with authoritative data - if it's signed? i don't know what the dnssec docset currently says about that, but it sounds like a good idea (or a good interpretation if the docset is ambiguous on the issue.) this gets back to the TC question, though. if the sig/key for "authoritative additional data" is available and it will fit then i see no problem in adding it. if it's available but it won't fit, though, then it ought not be added, and TC ought not be set. so, it's additional-additional-data, or meta-additional-data. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 24 20:04: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 UAA10655 for ; Thu, 24 Apr 2003 20:04:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198qbI-000OSD-00 for namedroppers-data@psg.com; Thu, 24 Apr 2003 23:58:00 +0000 Received: from mail-out2.apple.com ([17.254.0.51]) by psg.com with esmtp (Exim 3.36 #1) id 198qbD-000OR3-00 for namedroppers@ops.ietf.org; Thu, 24 Apr 2003 23:57:55 +0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h3ONvsQd001203 for ; Thu, 24 Apr 2003 16:57:54 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 24 Apr 2003 16:57:41 -0700 Received: from graessley.com (graejo5.apple.com [17.202.43.251]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id h3ONTKVc020876; Thu, 24 Apr 2003 16:57:51 -0700 (PDT) In-Reply-To: <1051209601.14360.19.camel@devil> References: <2DA94EC1-7674-11D7-A77D-000A959D832C@apple.com> <1051209601.14360.19.camel@devil> Mime-Version: 1.0 (Apple Message framework v568.1) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8E7C9B75-76B0-11D7-834A-000A959D832C@apple.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Joshua Graessley Subject: Re: LLMNR Issue 34: Unicast over TCP only Date: Thu, 24 Apr 2003 16:57:50 -0700 To: Mika Liljeberg X-Mailer: Apple Mail (2.568.1) 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 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 Thursday, April 24, 2003, at 11:40, Mika Liljeberg wrote: > Josh, > > On Thu, 2003-04-24 at 19:45, Joshua Graessley wrote: >> If unicast TCP queries with a TTL of 1 are used, it seems quite likely >> that PTR queries using LLMNR that could have succeeded will fail in >> cases where more than one ip subnet is present on the local link. If >> my >> machine does not have a routing entry, it will send the packet to the >> router, which will presumably decrement the TTL and put the packet >> back >> on the same link. Since the TTL is set to 1 my packet would be >> dropped. >> If I sent the same query using multicast, the device on the same link >> would have a chance to respond. > > This seems a bit far fetched. Do you have a real world example in mind? > > Note that if we want to support something like this, we really have no > choice but try all PTR queries with LLMNR, since there is no way to > tell > which destination addresses the default router might bounce back to the > local link. At home, I have a network with a NAT and a few global IP addresses. Both subnets are on the same network. I would like to be able to use LLMNR to resolve the names of devices with global addresses from devices that have NAT addresses. There are a lot of problems with this setup and some tweaks to routing tables would make the TTL 1 rule work. My concern is that if the two devices can get information using multicast queries, but then fail if the TC bit is set because of the TTL requirement, it might be a little difficult to understand what's going on. Then again, resolving a name to a private address won't do much good without the proper routing configuration on the local machines. So no, I can't think of a real world example. -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 Apr 24 21:48: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 VAA12712 for ; Thu, 24 Apr 2003 21:48:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198sBQ-00027l-00 for namedroppers-data@psg.com; Fri, 25 Apr 2003 01:39:24 +0000 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #1) id 198sBO-00027Z-00 for namedroppers@ops.ietf.org; Fri, 25 Apr 2003 01:39:22 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 24 Apr 2003 18:39:21 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 24 Apr 2003 18:39:20 -0700 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Apr 2003 18:39:20 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Apr 2003 18:39:20 -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(5.0.2195.5600); Thu, 24 Apr 2003 18:39:18 -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); Thu, 24 Apr 2003 18:39:17 -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: Proposed Resolution to LLMNR Issue 33: PTR via Unicast Date: Thu, 24 Apr 2003 18:39:17 -0700 Message-ID: Thread-Topic: Proposed Resolution to LLMNR Issue 33: PTR via Unicast Thread-Index: AcMKhs8eISt8YjGmQl2gAwPRyREk9AAQmsEw From: "Christian Huitema" To: "Mika Liljeberg" , Cc: "Bernard Aboba" , X-OriginalArrivalTime: 25 Apr 2003 01:39:17.0604 (UTC) FILETIME=[7C44FA40:01C30ACB] X-Spam-Status: No, hits=-9.2 required=5.0 tests=BAYES_01,OPT_IN,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 VAA12712 > > >"[4] A sender SHOULD send LLMNR queries for PTR RRs > > >via unicast over TCP, as specified in Section 2.3." > > >Note: Acceptance of the proposed resolution to Issue 33 is dependent on > > >acceptance of the proposed resolution to Issue 34 (to follow). > > > > i don't think it necesary to require TCP here. > > I agree. Connection hijacking on the local link is easy, so using TCP > doesn't provide any additional protection. Besides, certain restricted > devices equipped with a minimal protocol stack might only support UDP. The goal is not to protect from connection hijacking on the local link. Indeed, an attacker on a local link can use ARP poisoning, and all bets are pretty much off. The goal is to prevent off link attacks, and also DOS amplification attacks. First, off-link attacks. Off link attacks to a link-local multicast destination are very hard. Off link attack to a TCP destination are also very hard: if the SYN-ACK is sent with TTL 1, the attacker has to successfully guess the TCP sequence number, and that is not easy. Off link attack to an UDP unicast port with a spoofed IP source address are on the contrary much easier. Sure, you get some protection via TTL checks, but TTL checks can be bypassed with various tunneling technologies, not to mention faulty routers. (The recent slammer worm propagated through an off link attack to a UDP listener.) Second, DoS amplification. The attack is to send a short UDP request to an intermediary, using a spoofed source address, and to have the intermediary respond to that target address with a long packet. This achieves two interesting goals: hiding the actual source of the attack, and amplifying the attack. This can be trivially mounted with a UDP PTR request. Clearly, using TCP for direct queries has some cost. However, these costs will mostly appear when a service insists on resolving PTR records, which is clearly an "opt-in" function. And the cost does not appear un-surmountable... -- 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 Apr 24 22:12: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 WAA13311 for ; Thu, 24 Apr 2003 22:12:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198saj-00036Z-00 for namedroppers-data@psg.com; Fri, 25 Apr 2003 02:05: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 198sah-00036M-00 for namedroppers@ops.ietf.org; Fri, 25 Apr 2003 02:05:32 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C7B341A; Fri, 25 Apr 2003 11:05:29 +0900 (JST) To: "Christian Huitema" Cc: "Mika Liljeberg" , "Bernard Aboba" , namedroppers@ops.ietf.org In-reply-to: huitema's message of Thu, 24 Apr 2003 18:39:17 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: Proposed Resolution to LLMNR Issue 33: PTR via Unicast From: itojun@iijlab.net Date: Fri, 25 Apr 2003 11:05:29 +0900 Message-Id: <20030425020529.C7B341A@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 >The goal is to prevent off link attacks, and also DOS amplification >attacks. (snip) >Second, DoS amplification. The attack is to send a short UDP request to >an intermediary, using a spoofed source address, and to have the >intermediary respond to that target address with a long packet. This >achieves two interesting goals: hiding the actual source of the attack, >and amplifying the attack. This can be trivially mounted with a UDP PTR >request. when i hear the word "DoS amplification", i assume that there are more than N packet produced in response to N malicious packets. is it common to call the above scenario (N larger packet generated by N malicious packet) "amplification"? i don't think so. 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 Apr 24 23:35: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 XAA14196 for ; Thu, 24 Apr 2003 23:35:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198tvm-0006cK-00 for namedroppers-data@psg.com; Fri, 25 Apr 2003 03:31:22 +0000 Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 198tvj-0006c4-00 for namedroppers@ops.ietf.org; Fri, 25 Apr 2003 03:31:19 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3P3Bit15779; Thu, 24 Apr 2003 20:11:44 -0700 Date: Thu, 24 Apr 2003 20:11:44 -0700 (PDT) From: Bernard Aboba To: Christian Huitema cc: Mika Liljeberg , itojun@iijlab.net, namedroppers@ops.ietf.org Subject: RE: Proposed Resolution to LLMNR Issue 33: PTR via Unicast In-Reply-To: Message-ID: References: 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 > I agree. Connection hijacking on the local link is easy, so using TCP > doesn't provide any additional protection. Besides, certain restricted > devices equipped with a minimal protocol stack might only support UDP. -17 essentially requires that either TCP or EDNS0 be implemented anyway, so as to be to handle extended replies. The issue is whether *both* mechanisms are required, or only one. -- to unsubscribe send a message to namedroppers-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 Apr 25 01:49: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 BAA16471 for ; Fri, 25 Apr 2003 01:49:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 198w1W-000ESO-00 for namedroppers-data@psg.com; Fri, 25 Apr 2003 05:45:26 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 198w1T-000ESC-00 for namedroppers@ops.ietf.org; Fri, 25 Apr 2003 05:45:24 +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 h3P5lBRH025540; Fri, 25 Apr 2003 08:47:11 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h3P5l8qe025539; Fri, 25 Apr 2003 08:47:08 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: Proposed Resolution to LLMNR Issue 33: PTR via Unicast From: Mika Liljeberg To: Christian Huitema Cc: itojun@iijlab.net, Bernard Aboba , namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1051249627.23516.21.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 25 Apr 2003 08:47:08 +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-04-25 at 04:39, Christian Huitema wrote: > First, off-link attacks. Off link attacks to a link-local multicast > destination are very hard. Off link attack to a TCP destination are also > very hard: if the SYN-ACK is sent with TTL 1, the attacker has to > successfully guess the TCP sequence number, and that is not easy. Off > link attack to an UDP unicast port with a spoofed IP source address are > on the contrary much easier. Even with UDP there is still the timing problem, which makes off-link attacks very hard. However, I conceed they are possible. > Sure, you get some protection via TTL > checks, but TTL checks can be bypassed with various tunneling > technologies, not to mention faulty routers. (The recent slammer worm > propagated through an off link attack to a UDP listener.) If you get access to the link, whether physically or via a tunnel or a misconfigured router, all bets are off anyway. Suppose we just require that the responder must always send the responses to the link-local multicast address and that the resolver must not accept unicast responses? That should take care of any off-link LLMNR cache poisoning attacks using a spoofed source address. > Second, DoS amplification. The attack is to send a short UDP request to > an intermediary, using a spoofed source address, and to have the > intermediary respond to that target address with a long packet. This > achieves two interesting goals: hiding the actual source of the attack, > and amplifying the attack. This can be trivially mounted with a UDP PTR > request. As Itojun pointed out, one-for-one isn't really amplification. A TCP server would send multiple SYN-ACKs for one SYN before giving up (although with exponential backoff). Also, the scope of the DoS attack is limited to other nodes on the same link, since responses would have TTL=1. It doesn't look like a massive DDoS is in the cards. 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 Fri Apr 25 14:24: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 OAA18065 for ; Fri, 25 Apr 2003 14:24:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1997fh-000BS5-00 for namedroppers-data@psg.com; Fri, 25 Apr 2003 18:11:41 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 1997fb-000BOe-00 for namedroppers@ops.ietf.org; Fri, 25 Apr 2003 18:11:35 +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 h3PIBFbd028732 for ; Fri, 25 Apr 2003 14:11:15 -0400 (EDT) Message-ID: <001b01c30b55$a48a0420$14370681@lapdancer> From: "Scott Rose" To: References: <20030424202728.3DF3313984@sa.vix.com> Subject: Re: Q-03: inclusion of KEY records in additional records section Date: Fri, 25 Apr 2003 14:08: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 5.50.4920.2300 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_10,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 Should this be option 4? 4. "Add KEY/SIG if and only if it can fit without causing truncation" Or words to that effect. But when exactly: Referrals, or any authoritative response? And should it even matter? Scott ----- Original Message ----- From: "Paul Vixie" > > > > ... of additional data based on name-similarity to data in other > > > sections which is claimed as authoritative. > > > > Well, the client may not, but why shouldn't the server feed the > > additional section with authoritative data - if it's signed? > > i don't know what the dnssec docset currently says about that, but > it sounds like a good idea (or a good interpretation if the docset > is ambiguous on the issue.) > > this gets back to the TC question, though. if the sig/key for > "authoritative additional data" is available and it will fit then > i see no problem in adding it. if it's available but it won't > fit, though, then it ought not be added, and TC ought not be set. > so, it's additional-additional-data, or meta-additional-data. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > 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 Apr 25 14:55: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 OAA19006 for ; Fri, 25 Apr 2003 14:55:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1998Db-000GF9-00 for namedroppers-data@psg.com; Fri, 25 Apr 2003 18:46:43 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 1998DX-000GEq-00 for namedroppers@ops.ietf.org; Fri, 25 Apr 2003 18:46:39 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 45A033FF; Fri, 25 Apr 2003 14:46:39 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id D67443D7; Fri, 25 Apr 2003 14:46:38 -0400 (EDT) Received: from [192.136.136.76] ([192.136.136.76] verified) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 198103; Fri, 25 Apr 2003 14:36:32 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <001b01c30b55$a48a0420$14370681@lapdancer> References: <20030424202728.3DF3313984@sa.vix.com> <001b01c30b55$a48a0420$14370681@lapdancer> Date: Fri, 25 Apr 2003 14:46:35 -0400 To: "Scott Rose" From: Edward Lewis Subject: Re: Q-03: inclusion of KEY records in additional records section 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 14:08 -0400 4/25/03, Scott Rose wrote: >Should this be option 4? >4. "Add KEY/SIG if and only if it can fit without causing truncation" Or >words to that effect. > >But when exactly: Referrals, or any authoritative response? And should it >even matter? I'd say no - don't encourage the extra data until it is demonstrated that there is a need for it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer A compiler-directive person living in an HTML-tagged world. -- to unsubscribe send a message to namedroppers-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 Apr 26 08:12: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 IAA19142 for ; Sat, 26 Apr 2003 08:12:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 199OGp-000L6c-00 for namedroppers-data@psg.com; Sat, 26 Apr 2003 11:55:07 +0000 Received: from [3ffe:b80:2:a90::2] (helo=devil.pp.htv.fi) by psg.com with esmtp (Exim 3.36 #1) id 199OGl-000L55-00 for namedroppers@ops.ietf.org; Sat, 26 Apr 2003 11:55:04 +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 h3QBulRH031432; Sat, 26 Apr 2003 14:56:48 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h3QBuhQk031431; Sat, 26 Apr 2003 14:56:43 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: LLMNR Issues 33,34,35 threat analysis and proposal [RE: Proposed Resolution to LLMNR Issue 33: PTR via Unicast] From: Mika Liljeberg To: Bernard Aboba Cc: Christian Huitema , itojun@iijlab.net, namedroppers@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1051358202.23505.304.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 26 Apr 2003 14:56:43 +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 Hi all, On Fri, 2003-04-25 at 06:11, Bernard Aboba wrote: > -17 essentially requires that either TCP or EDNS0 be implemented anyway, > so as to be to handle extended replies. The issue is whether *both* > mechanisms are required, or only one. The requirement in the draft is MAY and I think that is the correct thing to say. There are implementations that only support address queries and for those implementatons it is quite acceptable to only support UDP, since they will practically never encounter responses that don't fit into a UDP response packet. I share the concern about the security issues so I did a little threat analysis to make sense of the problem. The analysis is appended below, in case anyone is interested. It's probably far from complete but feel free to expand on it (I hope you can make sense of the notation). The upshot of the analysis, however, is that using TCP for unicast would indeed address some problems. However, as I would not like to mandate TCP for PTR queries, I propose an alternative solution. The critical thing is that a sender can easily verify that a particular response is not spoofed by an off-link sender. If we have a simple way to do that, we can use link-local addressing and TTL to make sure we don't leak anything off-link. So, I propose the following simple rules for ALL queries: 1. Concatenate a random cookie to the canonical name. The cookie should be changed for every new query (but not retransmission). The sender must verify that the cookie is correctly echoed by the responder or discard the response (this is already done as part of normal response processing). Naturally, the responder must to disregard the cookie element while looking up the name database. 2. Send all queries and responses with TTL=1 to prevent leakage. 3. Don't amplify: respond to unicast queries with unicast responses. Note that we could use the above rules only for unicast and the current TTL=255 checks with multicast, but the proposed rules would work equally well for both unicast and multicast queries. The "when to use unicast" rules are fine as proposed in resolution 34. What do you think, did I overlook something? MikaL Threats and alternative solutions to each threat ================================================ THREAT A: sender should not accept any responses from off-link. Alternative solutions: [1] check that the destination address of the response is link-local (multicast) [2] check that TTL=255 in response packets [8] use TCP unicast, send queries with TTL=1 to avoid asking off-link [9] concatenate a random cookie to the canonical name, send queries with TTL=1, verify cookie on receipt THREAT B: A responder should not leak information to off-link attackers. Alternative solutions: [3] check that the destination address of the query packet is link-local (multicast) [4] check that TTL=255 in query packets [5] send responses with TTL=1 [6] send responses to link-local (multicast) address THREAT C: Both sender and responder should guard against reflection/amplification attacks. Solution: [7] don't amplify: don't respond to a single packet with many packets and don't respond to a unicast with multicast Threat coverage analysis ======================== Link-local multicast query A: 1,2 (alternative with 5),!8,9 B: 3,4,5 (alternative with 2),6 C: 7 Outcome: All three threats countered, alternative solutions UDP unicast query with TTL=1 A: !1 (conflicts with 7),!2 (conflicts with 5),!8,9 B: !3,!4,5,!6 (conflicts with 7) C: 7 => respond with unicast Outcome: All three threats countered, solution=9,5,7 TCP unicast query with TTL=1 A: 1,!2 (conflicts with 5),8,9 B: !3,!4,5,!6 C: 7 Outcome: All three threats countered, solution=8,5,7 or 9,5,7 NOTE: solution=9,5,7 works for all of the 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 Sat Apr 26 23:16: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 XAA05717 for ; Sat, 26 Apr 2003 23:16:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 199cQ4-000JH9-00 for namedroppers-data@psg.com; Sun, 27 Apr 2003 03:01:36 +0000 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 199cPy-000JGe-00 for namedroppers@ops.ietf.org; Sun, 27 Apr 2003 03:01:31 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3PKB1C03879 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 25 Apr 2003 16:11:02 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h3PKAx64011118 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 25 Apr 2003 16:11:00 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h3PKAwZl011115 for ; Fri, 25 Apr 2003 16:10:58 -0400 Message-Id: <200304252010.h3PKAwZl011115@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: Q-03: inclusion of KEY records in additional records section In-reply-to: Your message of "Fri, 25 Apr 2003 14:08:15 EDT." <001b01c30b55$a48a0420$14370681@lapdancer> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 25 Apr 2003 16:10:57 -0400 From: Michael Richardson X-Spam-Status: No, hits=-14.7 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE 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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott Rose writes: Scott> Should this be option 4? Scott> 4. "Add KEY/SIG if and only if it can fit without causing Scott> truncation" Or words to that effect. This just seems to sensible to me! I couldn't understand the origin of this whole conversation, except that Ed wanted #1 for a period so that we could understand the impact. And, btw, if the request is TCP *already*, then add it. I.e. TCP doesn't have a limit. The thing that I want, as an application writer, is an audit trail. That means that I want to receive the following back when I do a DNS request (oops, I have RFC2535 in brain, and no useful DS records to pull down, but, you get the idea), if I have, for instance pre-configured the trust for the in-addr.arpa. key. This is, however, a *local* issue. ("lwres" in bind9-speak) The application needs this for auditing. But, more to the point, the application needs to also get back data when there is a signature *FAILURE* that explains the failure. This will require innovations in the local format. marajade-[~] mcr 1101 %dig -x 192.139.46.38 txt ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.3.0s20021115 <<>> -x 192.139.46.38 txt ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35628 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6 ;; QUESTION SECTION: ;38.46.139.192.in-addr.arpa. IN TXT ;; ANSWER SECTION: 38.46.139.192.in-addr.arpa. 7200 IN TXT "X-IPsec-Server(10)=192.139.46.38 AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZTh48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh149ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRR" "RCMWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3fejrfi1H" ;; AUTHORITY SECTION: ... ;; ADDITIONAL SECTION: 38.46.139.192.in-addr.arpa. 7200 IN SIG TXT 1 6 7200 20030511005658 20030411005658 28815 46.139.192.in-addr.arpa. DVbqbMbp+Cddqcy+bsNsX6s3CCNpDKqJ4xf5EfMdsoX5b1yLKFwdsrFm hNVAyglQEh2IDmvBfYpTDfbMkGEJUM0/sqmLi2E20mMMUAM3xq7XNNZm AXy1Y5jBSiWGou7q 46.139.192.in-addr.arpa. 7200 IN SIG DNSKEY 1 6 7200 20030511005658 20030411005658 1234 139.192.in-addr.arpa. DVbqblahblahblah 46.139.192.in-addr.arpa. 7200 IN DNSKEY 28815 4 1 AQOrwhatever 139.192.in-addr.arpa. 7200 IN SIG DNSKEY 1 6 7200 20030511005658 20030411005658 4523 192.in-addr.arpa. DVbqmoreblahblahblah 139.192.in-addr.arpa. 7200 IN DNSKEY 1234 4 1 AQOrwhatever 192.in-addr.arpa. 7200 IN SIG DNSKEY 1 6 7200 20030511005658 20030411005658 4523 in-addr.arpa. DVbqmoreblahblahblah 192.in-addr.arpa. 7200 IN DNSKEY 4523 4 1 AQOrwhatever 192.in-addr.arpa. 7200 IN SIG DNSKEY 1 6 7200 20030511005658 20030411005658 7789 in-addr.arpa. DVbqmoreblahblahblah in-addr.arpa. 7200 IN DNSKEY 7789 4 1 AQOrwhatever ; the following key was axiomatic in-addr.arpa. 7200 IN SIG DNSKEY 1 6 7200 20030511005658 20030411005658 7789 in-addr.arpa. DVbqmoreblahblahblah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPqmWS4qHRg3pndX9AQFnRgQAvpg3sfYAhSnXN0yt76KxUTiFBX/oUCil ZWLG1C6seM7KLyaLiHxsZRlaLcMllK4FXp9Kl9fZtkFlJzMfsZjyA+zdWzb3g8ur aMZ2Be64tAcxq5+0MXjl1GEH/VBrNg8jNzDbQ4rITlt7lXvoZpRfIXRLri72Vpn6 TQD8NQfsX/U= =AaF+ -----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 Sat Apr 26 23:23: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 XAA05816 for ; Sat, 26 Apr 2003 23:23:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 199cY4-000Jnh-00 for namedroppers-data@psg.com; Sun, 27 Apr 2003 03:09:52 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 199cXy-000JnS-00 for namedroppers@ops.ietf.org; Sun, 27 Apr 2003 03:09:46 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h3R36r44025892 for ; Sat, 26 Apr 2003 20:06:53 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sat, 26 Apr 2003 20:09:43 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "Larson, Matt" , namedroppers@ops.ietf.org Subject: RE: Last call results? Date: Sat, 26 Apr 2003 20:09:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0006_01C30C48.EBC43970"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-8.6 required=5.0 tests=BAYES_01,MISSING_OUTLOOK_NAME,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 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C30C48.EBC43970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Could the co-chairs please make a statement regarding the last calls that ended on 31 March? Phill > -----Original Message----- > From: Matt Larson [mailto:mlarson@verisign.com] > Sent: Monday, April 14, 2003 3:31 PM > To: namedroppers@ops.ietf.org > Subject: Last call results? > > > Could the co-chairs please make a statement regarding the last calls > that ended on 31 March? > > > ----- Forwarded message from Randy Bush ----- > > From: Randy Bush > Subject: extend last calls in process > To: namedroppers > Date: Thu, 20 Mar 2003 08:34:18 -0800 > > three wg last calls were announced on 2003.03.12 > > opt-in > > threats ksk flag some folk are uncomfortable that this iesg week is in the middle of the last call period. so let's extend these three last calls one week to end on 2003.03.31. 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: ----- End forwarded message ----- -- Matt Larson VeriSign Global Registry Services ------=_NextPart_000_0006_01C30C48.EBC43970 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILizCCA6Yw ggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJpbWFy eSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJpU2ln biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BV c2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWty IChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHPbxY7 wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+4ec3 JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhCAQEE BAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQt MCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3DQEB BQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9juNL Lt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wazfVH bSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTANBgkq hkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENsYXNz IDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYD VQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1kS3Z OO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6cGFP hkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1UdEQQi MCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYwDwYD VR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAroCmG J2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUFAAOB gQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVwWk4o Hd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb6NDb if1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICED71tdHM9i4jiA298PD00EgwDQYJKoZIhvcN AQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVt cGxveWVlIENBMB4XDTAzMDMwNjAwMDAwMFoXDTA0MDMwNTIzNTk1OVowbTERMA8GA1UEChMIVkVS SVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFrZXIg KEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBALnb2fFyN844Cl9FoNaBDI8P+O4JliUWbYoS/H5ebiL9BiGWuVAXoo1TAaB/SHU6 Sw12kMz9z7gL+HW09pG9kofKMikS3baa49tG5t/Ap7wOnVNmLgelD5d/JuYi3d5J94N9qh2krJqP auD5FjEbnTQ/Op2NHQzivxnE+g0cdDLJAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1UdHwRS MFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhjaGFu Z2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJha2Vy QHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWdu LCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCi33oiw4urer1XI46PtYSjUD2W43Q+Ez8T9XJo Ewtc3mfUOuEw/PAH7VU3pLjUm6QfGe6W3xRzedAhAWzG1mWKK5vAq4Nnu8tpIV14PdxeXfKWM1Z0 Jw/1MHijGcoqLU9i3a1HYz/pF2A7/mibKe8Le+nJXV5q+XSAaL7K1ZcV3zGCAvgwggL0AgEBMIHB MIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3ll ZSBDQQIQPvW10cz2LiOIDb3w8PTQSDAJBgUrDgMCGgUAoIIBjDAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MjcwMzA5NDJaMCMGCSqGSIb3DQEJBDEWBBSsYBis LUs471rV1sWNCzPkzW89czBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB0gYJKwYB BAGCNxAEMYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xh c3MgMiBFbXBsb3llZSBDQQIQPvW10cz2LiOIDb3w8PTQSDANBgkqhkiG9w0BAQEFAASBgBmT2tCF 7azQkH2PSq8ibec7l5ih1yaF03wOaOkxAeZMoNWxnJD/UE+dgeEhylDiBj73RuXdC205GMjSnUwa u1L6dakhMBOq6NIXES3wXbYDewlpzIN+UZMfD3uF9HOMd657NoayfMfX1NXkJpZP0cTLIzo/M8Kk VmxNlpVxWRyBAAAAAAAA ------=_NextPart_000_0006_01C30C48.EBC43970-- -- to unsubscribe send a message to namedroppers-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 Apr 27 01:12: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 BAA06951 for ; Sun, 27 Apr 2003 01:12:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 199eGU-0000Mf-00 for namedroppers-data@psg.com; Sun, 27 Apr 2003 04:59:50 +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 199eGN-0000Hs-00 for namedroppers@ops.ietf.org; Sun, 27 Apr 2003 04:59:43 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 199eGL-000BLN-Fz; Sat, 26 Apr 2003 21:59:41 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 26 Apr 2003 21:59:40 -0700 To: "Hallam-Baker, Phillip" Cc: "Larson, Matt" , namedroppers@ops.ietf.org Subject: RE: Last call results? References: Message-Id: 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 > Could the co-chairs please make a statement regarding the last > calls that ended on 31 March? statement: we're working on it randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Apr 27 10:39: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 KAA26274 for ; Sun, 27 Apr 2003 10:39:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 199mzH-0003HQ-00 for namedroppers-data@psg.com; Sun, 27 Apr 2003 14:18:39 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 199mzE-0003F9-00 for namedroppers@ops.ietf.org; Sun, 27 Apr 2003 14:18:36 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h3REIVqJ000549 for ; Sun, 27 Apr 2003 07:18:31 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Apr 2003 07:18:35 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Sun, 27 Apr 2003 07:18:34 -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=-4.0 required=5.0 tests=BAYES_10,OPT_IN,OPT_IN_CAPS 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 Summary In favor 12 Abstain 7 Opposed 2 I have counted as abstain all the folk who said they did not think OptIn a good idea but would let it go through for the sake of consensus. These were 6 people all told. The other abstention being someone who did not actually appear to have made a concrete statement. Folk may want to check I recorded their statement correctly. Unfortunately I could not find a web archive that would let me link the statements to the actual posts. Unsurprisingly support for OptIn comes from the large registries and Paul Vixie. Nobody appears to have changed their mind during the discussion. There is definitely consensus on the proposition that it is high time the debate closed so we can get on with the next bit. In Favor -------- Paul Vixie as an individual, i support this. Roy Arends I support opt-in. Matt Larson I support Opt-In. Mark Kosters I support Opt-In. Olaf Kolkman Although I would advise against its use in all other cases but the huge zones out there, I do support the draft. Ted Lemon I support opt-in. We've been playing around with DNSSEC for a long time, and we will still be playing with it (or have abandoned it) ten years from now if we don't adopt opt-in. Phillip Hallam-Baker In favor Scott Rose I support the draft with the last round of comments. Daniel Massey support for the draft with the last round of comments. David Blaka I support Opt-In. Joerg Bauer I also prefer OPT-IN. Frederico Neves We strongly support OPT-IN. Today as the "standard" is we can't deploy DNSSEC without OPT-IN. 'Abstain with comments??' ------------------------- David Conrad Sigh. I've said I don't care what decision is made as long as a decision is made Sam Weiler I still oppose opt-in, but for the moment I'm willing to step aside and let it advance. Rob Austin: I oppose opt-in, but would be willing to stand aside if the WG were to approach consensus in favor of opt-in Steve Bellovin Agrees with Rob 'on both points' ted (NLnet Labs) This [Rob's text] is exactly also my position. Miek Gieben I totally agree with this. That is: I oppose opt-in, but ... Brian Wellington - I am unable to find a clear statement of support or opposition. Opposed ------- Ted Hardie I oppose OPT-IN going forward as a proposed standard. tale@nominum.com I'm unprepared to just "move on" at this point, particularly as I too am one of the people opposed to OPT-IN (on grounds that have all been presented by others here). -- to unsubscribe send a message to namedroppers-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 Apr 27 17:34: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 RAA02470 for ; Sun, 27 Apr 2003 17:34:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 199tdZ-000LAT-00 for namedroppers-data@psg.com; Sun, 27 Apr 2003 21:24:41 +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 199tdX-000LA7-00 for namedroppers@ops.ietf.org; Sun, 27 Apr 2003 21:24:39 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.14) id 199tdV-000Cac-Rs for namedroppers@ops.ietf.org; Sun, 27 Apr 2003 14:24:37 -0700 Message-id: <00d101c3092b$13c95070$b7cbdba8@daniel7209> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_E2AJtbLhAJLstM4Mk7ncOw)" Date: Wed, 23 Apr 2003 08:58:31 +0900 From: Soohong Daniel Park Subject: IPv6 Extensions for DNS Plug and Play To: dnsop@cafax.se, namedroppers@ops.ietf.org Cc: "'Syam Madanapalli'" , "'Soohong Daniel Park'" X-Spam-Status: No, hits=-5.0 required=5.0 tests=BAYES_01,HTML_40_50,HTML_FONT_COLOR_BLUE, HTML_FONT_FACE_BAD,HTML_FONT_FACE_ODD 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. --Boundary_(ID_E2AJtbLhAJLstM4Mk7ncOw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi folks This initial draft was spoke in 56 IETF meeting. After then this draft is revised and added many section. Look into it and let me know your comments. --------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Extensions for DNS Plug and Play Author(s) : S. Park, S. Madanapalli Filename : draft-park-ipv6-extensions-dns-pnp-00.txt Pages : 30 Date : 2003-4-21 This document proposes automatic configuration of domain name (FQDN) for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as a part of IPv6 plug and play feature. 6DNAC allows the automatic registration of domain name and corresponding IPv6 Addresses with the DNS server. In order to provide 6DNAC function, Neighbor Discovery Protocol [2461] will be used. Moreover, 6DNAC does not require any changes to the existing DNS system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-ipv6-extensions-dns-pnp-0 0.txt Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics Tel:+82-31-200-4508 Fax:+82-31-200-3147 mailto:soohong.park@samsung.com --Boundary_(ID_E2AJtbLhAJLstM4Mk7ncOw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT IPv6 Extensions for DNS Plug and Play

Hi folks

This initial draft was spoke in 56 IETF meeting.
After then this draft is revised and added many section.
Look into it and let me know your comments.

---------------------------
A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : IPv6 Extensions for DNS Plug and Play
        Author(s)       : S. Park, S. Madanapalli
        Filename        : draft-park-ipv6-extensions-dns-pnp-00.txt
        Pages           : 30
        Date            : 2003-4-21
       
This document proposes automatic configuration of domain name (FQDN) for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as a part of IPv6 plug and play feature. 6DNAC allows the automatic registration of domain name and corresponding IPv6 Addresses with the DNS server. In order to provide 6DNAC function, Neighbor Discovery Protocol [2461] will be used. Moreover, 6DNAC does not require any changes to the existing DNS system.

A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-ipv6-extensions-dns-pnp-00.txt







Daniel (Soohong Daniel Park)
Mobile Platform Lab,SAMSUNG Electronics
Tel:+82-31-200-4508 Fax:+82-31-200-3147
mailto:soohong.park@samsung.com

--Boundary_(ID_E2AJtbLhAJLstM4Mk7ncOw)-- -- to unsubscribe send a message to namedroppers-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 Apr 28 04:38: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 EAA24248 for ; Mon, 28 Apr 2003 04:38:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19A40v-000D8O-00 for namedroppers-data@psg.com; Mon, 28 Apr 2003 08:29:29 +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 19A40q-000D86-00 for namedroppers@ops.ietf.org; Mon, 28 Apr 2003 08:29:27 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.6) with ESMTP id h3S8TJBd097691; Mon, 28 Apr 2003 10:29:19 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h3S8TJak097690; Mon, 28 Apr 2003 10:29:19 +0200 (CEST) Message-Id: <200304280829.h3S8TJak097690@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Mon, 28 Apr 2003 10:29:19 +0200 In-Reply-To: ""Hallam-Baker, Phillip"'s message as of Apr 27, 16:44" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN X-Spam-Status: No, hits=-11.8 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN_CAPS,QUOTED_EMAIL_TEXT, UPPERCASE_25_50 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 Apr 27, 16:44, in "Summary: DNSEXT WGLC ..."] > Folk may want to check I recorded their statement correctly. ... Please count my position as "I oppose OPT-IN". -- ted (NLnet Labs) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 28 13:46: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 NAA08273 for ; Mon, 28 Apr 2003 13:46:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ACXz-0004tt-00 for namedroppers-data@psg.com; Mon, 28 Apr 2003 17:36:11 +0000 Received: from cpe-24-221-172-100.ca.sprintbbd.net ([24.221.172.100] helo=spratly.wl.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 19ACXw-0004tg-00 for namedroppers@ops.ietf.org; Mon, 28 Apr 2003 17:36:09 +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 h3SHZKe9032178; Mon, 28 Apr 2003 10:35:20 -0700 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h3SHZHRT032175; Mon, 28 Apr 2003 10:35:19 -0700 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Mon, 28 Apr 2003 10:35:17 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: "Hallam-Baker, Phillip" cc: namedroppers@ops.ietf.org Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-37.0 required=5.0 tests=BAYES_10,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 Sun, 27 Apr 2003, Hallam-Baker, Phillip wrote: > 'Abstain with comments??' > ------------------------- > > ... > > Brian Wellington > - I am unable to find a clear statement of support or opposition. You don't think: Furthermore, the main argument for opt-in has historically been that full DNSSEC would require too many resources. Since this argument was originally used, probably 2 years ago, every conceivable resource has become both cheaper and faster, and the size of excessively large zones has more or less stayed the same. This means that even if it had been a good argument in the past, it's days are over. is a clear enough argument for opposition? Just like last time you posted an "unbiased" summary, it's wrong. I urge the working group chairs to either completely ignore this or come up with a truly unbiased list and compare it. 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 Apr 28 14:05: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 OAA08823 for ; Mon, 28 Apr 2003 14:05:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ACum-0006Ff-00 for namedroppers-data@psg.com; Mon, 28 Apr 2003 17:59:44 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19ACuk-0006FQ-00 for namedroppers@ops.ietf.org; Mon, 28 Apr 2003 17:59:42 +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 h3SHxGbd025681 for ; Mon, 28 Apr 2003 13:59:16 -0400 (EDT) Message-ID: <000701c30daf$77c171b0$14370681@lapdancer> From: "Scott Rose" To: Subject: DNSSECbis Q-8: Non-zone KEY RR at the apex. Date: Mon, 28 Apr 2003 13:56:17 -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=-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 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 Mon Apr 28 14:29: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 OAA09526 for ; Mon, 28 Apr 2003 14:29:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ADJj-000827-00 for namedroppers-data@psg.com; Mon, 28 Apr 2003 18:25:31 +0000 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 19ADJg-00081n-00 for namedroppers@ops.ietf.org; Mon, 28 Apr 2003 18:25:28 +0000 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h3SIFfZj081168; Mon, 28 Apr 2003 14:15:41 -0400 (EDT) Message-Id: <200304281815.h3SIFfZj081168@nic-naa.net> To: namedroppers@ops.ietf.org cc: brunner@nic-naa.net Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Mon, 28 Apr 2003 14:15:41 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_01,OPT_IN,OPT_IN_CAPS 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 opposed to opt-in (yes, dnsext context). Eric -- to unsubscribe send a message to namedroppers-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 Apr 28 15:36: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 PAA12423 for ; Mon, 28 Apr 2003 15:36:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AEM5-000Cq3-00 for namedroppers-data@psg.com; Mon, 28 Apr 2003 19:32:01 +0000 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 19AEM2-000Cph-00 for namedroppers@ops.ietf.org; Mon, 28 Apr 2003 19:31:58 +0000 Received: (qmail 90200 invoked by uid 1016); 28 Apr 2003 19:32:23 -0000 Date: 28 Apr 2003 19:32:23 -0000 Message-ID: <20030428193223.90199.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_01,OPT_IN,OPT_IN_CAPS,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 I oppose opt-in for an additional reason: it tends to hide security problems. Without opt-in, there's a clear difference between the current .com security disaster (all records from .com can be forged) and the desired situation (no records from .com can be forged). With opt-in, the .com people will start proudly advertising ``DNSSEC support'' (exactly as the BIND implementors have been doing for years) when they still aren't protecting all their incoming and outgoing data. This seems to be the basic reason that they support opt-in---they want to claim security without doing the necessary work. ---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 Mon Apr 28 16:59: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 QAA14395 for ; Mon, 28 Apr 2003 16:59:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AFcD-000LLx-00 for namedroppers-data@psg.com; Mon, 28 Apr 2003 20:52:45 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19AFc2-000LGJ-00 for namedroppers@ops.ietf.org; Mon, 28 Apr 2003 20:52:34 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 178BA48A; Mon, 28 Apr 2003 16:52:31 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id AED463DA; Mon, 28 Apr 2003 16:52:30 -0400 (EDT) Received: from [127.0.0.1] (HELO [66.44.68.85]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 210095; Mon, 28 Apr 2003 16:42:12 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200304252010.h3PKAwZl011115@marajade.sandelman.ottawa.on.ca> References: <200304252010.h3PKAwZl011115@marajade.sandelman.ottawa.on.ca> Date: Mon, 28 Apr 2003 16:22:13 -0400 To: Michael Richardson From: Edward Lewis Subject: Re: Q-03: inclusion of KEY records in additional records section Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-30.6 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,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:10 -0400 4/25/03, Michael Richardson wrote: > I couldn't understand the origin of this whole conversation, except that >Ed wanted #1 for a period so that we could understand the impact. Naw, I was fer #3, DavidB was for #1. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer A compiler-directive person living in an HTML-tagged world. -- to unsubscribe send a message to namedroppers-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 Apr 28 17:00: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 RAA14449 for ; Mon, 28 Apr 2003 17:00:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AFc4-000LGZ-00 for namedroppers-data@psg.com; Mon, 28 Apr 2003 20:52:36 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19AFc2-000LGI-00 for namedroppers@ops.ietf.org; Mon, 28 Apr 2003 20:52:34 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id B28AF4A1; Mon, 28 Apr 2003 16:52:33 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 42B9848D; Mon, 28 Apr 2003 16:52:33 -0400 (EDT) Received: from [127.0.0.1] (HELO [66.44.68.85]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 210096; Mon, 28 Apr 2003 16:42:15 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 28 Apr 2003 16:44:46 -0400 To: "Hallam-Baker, Phillip" From: Edward Lewis Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-27.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN_CAPS, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,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 7:18 -0700 4/27/03, Hallam-Baker, Phillip wrote: >Summary > In favor 12 > Abstain 7 > Opposed 2 I've said quite a bit on the topic, yet you don't list which side you think I am on. Don't I get a vote too? Sorry folks, I usually can refrain from snideness like this, but I'm beyond my limit of patience. PS - Finally, hi-bandwidth is allegedly (newly) available in my "hi-tech" county. The cable technician came today, with a service window of 1000-1400, promptly at 1500 with a tech who had just been hired to do this. As he left, there's an "outage" so the installation couldn't be tested. If the real Internet is this badly run, why are we trying to hard to over engineer the protocols? (I'm still using 48K modem service.) I can't wait for IPv6 service. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer A compiler-directive person living in an HTML-tagged world. -- to unsubscribe send a message to namedroppers-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 Apr 29 03:42: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 DAA09369 for ; Tue, 29 Apr 2003 03:42:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19APWU-000HKU-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 07:27:30 +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 19APWR-000HKI-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 07:27:27 +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 h3T7RLjL019485 for ; Tue, 29 Apr 2003 09:27:22 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) with ESMTP id h3T7RLjG019482 for ; Tue, 29 Apr 2003 09:27:21 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Tue, 29 Apr 2003 09:27:21 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: <20030428193223.90199.qmail@cr.yp.to> Message-ID: References: <20030428193223.90199.qmail@cr.yp.to> 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, 28 Apr 2003, D. J. Bernstein wrote: > I oppose opt-in for an additional reason: it tends to hide security > problems. > > Without opt-in, there's a clear difference between the current .com > security disaster (all records from .com can be forged) and the desired > situation (no records from .com can be forged). All records under and including root can be forged anytime, anywhere. It's error detection at the client side we're talking about. All authoritative records are signed, with or without opt-in, and can be verified to be valid or not. Opt-in removes redundant crypto. C'est ca. > With opt-in, the .com people will start proudly advertising ``DNSSEC > support'' (exactly as the BIND implementors have been doing for years) Finally, about time, you should too ! > when they still aren't protecting all their incoming and outgoing data. Who says they have to ? They need to do (at least) two things: 1) sign authoritative RRsets. 2) send them at request of the client. badabing. > This seems to be the basic reason that they support opt-in---they want > to claim security without doing the necessary work. They want to claim security without doing the unnecessary work. 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 Tue Apr 29 08:58: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 IAA15359 for ; Tue, 29 Apr 2003 08:58:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AUXZ-000Lsj-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 12:48:57 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19AUXU-000LsX-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 12:48:52 +0000 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h3TCmiqJ025334; Tue, 29 Apr 2003 05:48:44 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 05:48:49 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Edward Lewis'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Tue, 29 Apr 2003 05:48:47 -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=-15.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,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 18 -0700 4/27/03, Hallam-Baker, Phillip wrote: > >Summary > > In favor 12 > > Abstain 7 > > Opposed 2 > > I've said quite a bit on the topic, yet you don't list which side you > think I am on. Don't I get a vote too? I could not find a definitive statement from you during the last call. And in any case it does not appear that you get a vote at all in this group unless you vote the way Randy approves of. > Sorry folks, I usually can refrain from snideness like this, but I'm > beyond my limit of patience. So am I. This is now the FOURTH last call of this Florida style decision procedure. -- to unsubscribe send a message to namedroppers-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 Apr 29 08: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 IAA15376 for ; Tue, 29 Apr 2003 08:58:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AUby-000MDH-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 12:53:30 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19AUbv-000MD2-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 12:53:28 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h3TCrMqJ025852; Tue, 29 Apr 2003 05:53:22 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 05:53:27 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Brian Wellington'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Tue, 29 Apr 2003 05:53:25 -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 No, the call for votes was very clear, make a clear statement of support or opposition. You made statements on the subject but I was not going to interpret your statements for you. > -----Original Message----- > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > Sent: Monday, April 28, 2003 1:35 PM > To: Hallam-Baker, Phillip > Cc: namedroppers@ops.ietf.org > Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN > > > On Sun, 27 Apr 2003, Hallam-Baker, Phillip wrote: > > > 'Abstain with comments??' > > ------------------------- > > > > ... > > > > Brian Wellington > > - I am unable to find a clear statement of support or > opposition. > > You don't think: > > Furthermore, the main argument for opt-in has historically > been that full > DNSSEC would require too many resources. Since this argument was > originally used, probably 2 years ago, every conceivable resource has > become both cheaper and faster, and the size of excessively > large zones > has more or less stayed the same. This means that even if it > had been a > good argument in the past, it's days are over. > > is a clear enough argument for opposition? Just like last > time you posted > an "unbiased" summary, it's wrong. > > I urge the working group chairs to either completely ignore > this or come > up with a truly unbiased list and compare it. > > 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 Tue Apr 29 09: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 JAA15459 for ; Tue, 29 Apr 2003 09:01:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AUaE-000MBH-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 12:51:42 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19AUaC-000MB5-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 12:51:40 +0000 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h3TCpYqJ025648; Tue, 29 Apr 2003 05:51:34 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 05:51:39 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'D. J. Bernstein'" , namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Tue, 29 Apr 2003 05:51:38 -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.2 required=5.0 tests=BAYES_10,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 > Without opt-in, there's a clear difference between the current .com > security disaster (all records from .com can be forged) and > the desired > situation (no records from .com can be forged). As has been stated during the discussion on the OPTIN proposal the security considerations of an unsecured delegation and a secured delegation to an unsecured zone are exactly the same except in one regard - an unsecure delegation is subject to a record insertion attack, a risk that is not relevant to the .com zone. > With opt-in, the .com people will start proudly advertising ``DNSSEC > support'' (exactly as the BIND implementors have been doing for years) > when they still aren't protecting all their incoming and > outgoing data. > This seems to be the basic reason that they support opt-in---they want > to claim security without doing the necessary work. No, without doing unecessary work. -- to unsubscribe send a message to namedroppers-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 Apr 29 09:07: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 JAA15592 for ; Tue, 29 Apr 2003 09:07:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AUm8-000NLX-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 13:04:00 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19AUm5-000NLG-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 13:03:57 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h3TD3eqJ026877; Tue, 29 Apr 2003 06:03:40 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 06:03:44 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'ted@NLnetLabs.nl'" , "Hallam-Baker, Phillip" , namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Tue, 29 Apr 2003 06:03:43 -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.2 required=5.0 tests=BAYES_01,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 Your actual statement was in response to Rob who stated he did not think Opt-in was a good idea but would not object for the sake of consensus. This is exactly also my position. I strongly feel that the problems that OptIn may or may not solve or impose are dwarfed by the problems we still have to face to get DNSSEC widely deployed. Most of the work sofar has been done from the viewpoint of the DNS-administrator, we still have to do a lot of work to make DNSSEC understood, working, and useful for the user. I do not believe that I misrepresented your statement during the last call period. Given the procedural manipulations and abuses by one of the chairs I think folk will understand why this has to be played strictly by the originally stated rules at this point. The last call was the FOURTH, each time the last call failed to go the way Randy wanted a new last call was staged. > -----Original Message----- > From: ted@NLnetLabs.nl [mailto:ted@NLnetLabs.nl] > Sent: Monday, April 28, 2003 4:29 AM > To: Hallam-Baker, Phillip; namedroppers@ops.ietf.org > Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN > > > [Quoting "Hallam-Baker, Phillip", on Apr 27, 16:44, in > "Summary: DNSEXT WGLC ..."] > > > Folk may want to check I recorded their statement correctly. ... > > Please count my position as "I oppose OPT-IN". > > -- ted (NLnet Labs) > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > 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 Tue Apr 29 09: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 JAA17630 for ; Tue, 29 Apr 2003 09:39:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AVCK-0001Fp-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 13:31:04 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19AVCG-0001FU-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 13:31:00 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id EB4B34B9; Tue, 29 Apr 2003 09:30:57 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 90A64449 for ; Tue, 29 Apr 2003 09:30:57 -0400 (EDT) Received: from [192.136.136.100] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 210922 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 09:20:37 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: References: Date: Tue, 29 Apr 2003 09:30:52 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,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 5:48 -0700 4/29/03, Hallam-Baker, Phillip wrote: >I could not find a definitive statement from you during the >last call. Thank you. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer A compiler-directive person living in an HTML-tagged world. -- to unsubscribe send a message to namedroppers-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 Apr 29 10:29: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 KAA23720 for ; Tue, 29 Apr 2003 10:29:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AVwX-0007v4-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 14:18:49 +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 19AVwS-0007uX-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 14:18:46 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.6) with ESMTP id h3TEIbBd027296 for ; Tue, 29 Apr 2003 16:18:37 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h3TEIao2027293 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 16:18:36 +0200 (CEST) Message-Id: <200304291418.h3TEIao2027293@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Tue, 29 Apr 2003 16:18:36 +0200 In-Reply-To: ""Hallam-Baker, Phillip"'s message as of Apr 29, 15:03" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_01,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 [Quoting "Hallam-Baker, Phillip", on Apr 29, 15:03, in "RE: Summary: DNSEXT ..."] > Your actual statement was in response to Rob who stated he did not > think Opt-in was a good idea but would not object for the sake of > consensus. Sorry, but according to my e-mail archive it appears that Rob had written something different: [Quoting Rob Austein, on Mar 27, 11:14, in "Re: DNSEXT WGLC: To ..."] > I oppose opt-in, but would be willing to stand aside if the WG were to > approach consensus in favor of opt-in, because I strongly agree that > we need to make a decision and put this behind us. I interpreted Rob's words as that he would be willing to stand aside if the WG were to approach consensus in favor of opt-in. And that was also my position. However, giving the fact that the WG is NOT approaching consensus about opt-in, makes the "but would ..." part of the sentence no longer relevant. So _my_ position was, is and remains: I oppose opt-in > I do not believe that I misrepresented your statement during the last > call period. I believe you did, anyway, this is now straightend out. > Given the procedural manipulations and abuses by one of the chairs I > think folk will understand why this has to be played strictly by the > originally stated rules at this point. And please don't do this. I, and everybody I've spoken with during the years that I have been involved with the IETF, have high respect for the chairs and I have never seen manipulations or abuses by them. On the contrary, I think they do a terrific job. The fact that not everybody applauds the OptIn idea is not because of the chairs, it's because of the OptIn idea. -- 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 Tue Apr 29 12:20: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 MAA29684 for ; Tue, 29 Apr 2003 12:20:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AXgj-000NrR-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 16:10:37 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 19AXgf-000NrE-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 16:10:33 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h3TG7d44022419; Tue, 29 Apr 2003 09:07:39 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 09:10:31 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'ted@NLnetLabs.nl'" , namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Tue, 29 Apr 2003 09:10:29 -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.2 required=5.0 tests=BAYES_01,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 > And please don't do this. I, and everybody I've spoken with during > the years that I have been involved with the IETF, I have no respect for Randy and he told me during the very first meeting I attended, before I had ever said a word beyond my name and company, that he had no respect for me. Several people have represented to me that I am the one creating this issue. That is simply untrue and unsupported by the facts. On the contrary you will find that in the past 36 months I have been a signficiant if not principal contributor to the core specifications of Web Services Security. I have brokered many of the agreements between the fiercest rivals in the space. I suggest that the opponents of OPTIN consider their actions and ask whether my statements that I may not accept the decision of the group might have been based on their own statements such as 'I don't believe deployment in .com is important'. If a WG decides not to address my needs I am under no duty, moral or otherwise to accept the decision of that group. If telling you that gives offense then take it. If it really is true that this working group cannot work with me then that speaks more for this group than it does for me. I have two choices here, appeal or simply deploy a DNS Security solution without IETF sanction. I do not believe that the sanction of this group counts for very much in the cryptography world, and it is that world my world, which will decide whether to sanction deployment of any DNS Security solution or not. This group has repeatedly told me not to make statements of this type that they feel are threatening. Well, sorry if it bursts your bubble if I tell you that in the world of commercial deployment of cryptographic protocols you will find that I am the only major voice with standing that is supporting DNSSEC at all. Name one other front line champion from the commercial cryptography world who is going to persuade Microsoft or any other major vendor to deploy DNSSEC. IF DNSSEC is not deployed in end points the end to end argument collapses and you are better off with link security which will be easier to deploy. This process has been a farce from beginning to end. The only reason that I am willing to make an appeal is that I believe that the actions of this group do not reflect those of the IETF in general. Randy has deliberately constructed this procedure to give himself the maximum opportunities to obtain the result he has wanted from the outset. My purpose in summarising the votes was not to address the consensus issue, it was to force the chairs to announce their decision so the process can move on to the next stage. I am not prepared to play another round of procedural games in this forum. The issue of consensus is not the principal issue that the appeal is based on. The principal issues are technical merit and due process. Frankly the consensus of this group on the issue of facilitating deployment by the largest operator of DNS services does not appear to me to be a useful question to ask. 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 Tue Apr 29 12:22: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 MAA29708 for ; Tue, 29 Apr 2003 12:22:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AXhS-000Nus-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 16:11:22 +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 19AXhO-000NuQ-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 16:11:18 +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 h3TGAie9031531; Tue, 29 Apr 2003 09:10:44 -0700 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h3TGAheJ031528; Tue, 29 Apr 2003 09:10:43 -0700 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Tue, 29 Apr 2003 09:10:43 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: "Hallam-Baker, Phillip" cc: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: References: 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 Tue, 29 Apr 2003, Hallam-Baker, Phillip wrote: > No, the call for votes was very clear, make a clear statement of > support or opposition. You made statements on the subject but > I was not going to interpret your statements for you. Fine. For anyone else who didn't get it, I oppose opt-in. 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 Tue Apr 29 12: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 MAA00232 for ; Tue, 29 Apr 2003 12:36:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AXt1-000039-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 16:23:19 +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 19AXsy-00002u-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 16:23:17 +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 h3TGMge9031541; Tue, 29 Apr 2003 09:22:42 -0700 Received: from localhost (bwelling@localhost) by spratly.wl.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h3TGMgVE031538; Tue, 29 Apr 2003 09:22:42 -0700 X-Authentication-Warning: spratly.wl.nominum.com: bwelling owned process doing -bs Date: Tue, 29 Apr 2003 09:22:42 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.wl.nominum.com To: "Hallam-Baker, Phillip" cc: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-39.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,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 Tue, 29 Apr 2003, Hallam-Baker, Phillip wrote: > The last call was the FOURTH, each time the last call failed to go > the way Randy wanted a new last call was staged. Rather than making unfounded accusations, maybe you should consider the fact that during the first 3 calls, as well as this one, there was nothing resembling working group consensus in either direction. 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 Tue Apr 29 13:11: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 NAA02001 for ; Tue, 29 Apr 2003 13:11:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AYVS-0006YN-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 17:03:02 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19AYVP-0006Y8-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 17:02:59 +0000 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h3TH2rqJ021277; Tue, 29 Apr 2003 10:02:53 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 10:02:58 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Brian Wellington'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Tue, 29 Apr 2003 10:02: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=-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 Actually there was consensus recognized on the technical issues in the previous last call. The last call before that had no comments, but those in favor were under the impression that the last call was a last chance for those opposed to say so or forever hold their peace. I would certainly have posted if not for the request of opt-in opponents to avoid striring up more argument in the group, to simply let the matter pass quietly. My trust was abused on that occasion, never again. There was also consensus at the first last call. Otherwise it would not have been necessary to make the unanounced referral to the DNS Directorate which held the process up for 6 months but never reported to the group. The procedures that this group has acted under are simply not defensible. Fortunately the decision is no longer in the hands of this group or Randy. Further argument here is futile, but that won't stop it of course. Phill > -----Original Message----- > From: Brian Wellington [mailto:Brian.Wellington@nominum.com] > Sent: Tuesday, April 29, 2003 12:23 PM > To: Hallam-Baker, Phillip > Cc: namedroppers@ops.ietf.org > Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN > > > On Tue, 29 Apr 2003, Hallam-Baker, Phillip wrote: > > > The last call was the FOURTH, each time the last call failed to go > > the way Randy wanted a new last call was staged. > > Rather than making unfounded accusations, maybe you should > consider the > fact that during the first 3 calls, as well as this one, > there was nothing > resembling working group consensus in either direction. > > 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: > -- to unsubscribe send a message to namedroppers-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 Apr 29 13:19: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 NAA02309 for ; Tue, 29 Apr 2003 13:19:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AYfw-0008CN-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 17:13:52 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19AYfb-0008Br-00; Tue, 29 Apr 2003 17:13:34 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19AYfT-0004zW-DI; Tue, 29 Apr 2003 10:13:23 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Apr 2003 10:13:22 -0700 To: "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN References: Message-Id: X-Spam-Status: No, hits=-12.5 required=5.0 tests=BAYES_01,OPT_IN_CAPS,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 call for votes was very clear there was never a call for votes. no surprise, this is the ietf. there was a call for people to state their expert opinions. thanks to those who have done so. 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 Tue Apr 29 13:29: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 NAA02675 for ; Tue, 29 Apr 2003 13:29:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AYr0-000AVV-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 17:25:18 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 19AYqw-000ATq-00; Tue, 29 Apr 2003 17:25:14 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h3THMM44006296; Tue, 29 Apr 2003 10:22:22 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 10:25:14 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Tue, 29 Apr 2003 10:25:11 -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.2 required=5.0 tests=BAYES_01,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 I was responding to the following question: "I've said quite a bit on the topic, yet you don't list which side you think I am on. Don't I get a vote too?" And yes I too pointed out that, no Edward does not get a 'vote'. When Bush is involved you have to wait for the decision of the Supreme Court. Phill > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Tuesday, April 29, 2003 1:13 PM > To: Hallam-Baker, Phillip > Cc: namedroppers@ops.ietf.org > Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN > > > > the call for votes was very clear > > there was never a call for votes. no surprise, this is the ietf. > > there was a call for people to state their expert opinions. thanks > to those who have done so. > > 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 Tue Apr 29 15: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 PAA07415 for ; Tue, 29 Apr 2003 15:19:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AaLF-0000fg-00 for namedroppers-data@psg.com; Tue, 29 Apr 2003 19:00:37 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19AaLA-0000fH-00 for namedroppers@ops.ietf.org; Tue, 29 Apr 2003 19:00:32 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.9/) with ESMTP id h3TJ0RqJ019951 for ; Tue, 29 Apr 2003 12:00:27 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 12:00:31 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'namedroppers@ops.ietf.org'" Subject: Appeal against decision of DNSEXT working group chairs to prevent progess of OPT-IN Date: Tue, 29 Apr 2003 12:00:25 -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=-1.1 required=5.0 tests=BAYES_20,OPT_HEADER,OPT_IN,OPT_IN_CAPS 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. I have counted the statements on the last call issue, only 2 are opposed outright, while 12 are in favor. 6 state that they are opposed to or do not like the proposal but are willing to allow it to progress for the sake of consensus. 1 party failled to make a clear statement on the issue during the Last Call period but subsequently stated that his statement should be counted as opposition. The grounds for the appeal are as follows 1: Technical necessity. Deployment of DNSSEC is not practical in the large zones without modification to address the shortcommings of the original specification. The original specification is now ten years old and has failed to achieve any meaningful degree of deployment. It is clear that it will not achieve meaningful deployment without the active support of the operators of the large zones. 2: Procedural abuse. The chairs have failled to recognise the clear consensus of the group. They have made repeated requests for last calls in a transparent attempt to arrive at the answer they favor. New procedures have been invented to prevent progress of the specification. 3: Failure to observe open process The decision process applied in the case of DNS-SEC OPT-IN does not meet criteria that any independent party or court of law could consider to be open. This appeal is made by Phillip Hallam-Baker acting in his individual capacity and not on behalf of VeriSign or any other party. In point of fact i have deliberately not forwarded this to anyone else in VeriSign for comment, in particular to avoid placing Mark and Leslie in an awkward position. The right to seek redress in other forums is expressly reserved. 1) Technical Necessity: The DNSSEC specification is now ten years old. Despite repeated warnings of the severe consequences of a compromise of the DNS system to the fabric of the Internet the IETF has failled to deploy any system to mitigate or control these risks. Revision of the DNSSEC specifications in the DNSEXT working group has revealled numerous shortcommings in the specifications, most of which have been accepted as requiring changes, whether major or minor in order to achieve a deployable specification. The one exception to this willingness to accept change has been the issue of the cost of generating NXT records in the large zones. As matters stand the deployment of DNSSEC is unduly burdensome to operators of the large zones as it will cause an immediate six fold increase in the volume of data in the zones. This fact is not in dispute, only the significance of the fact and whether the operators of the large zones should simply be required to accept this cost is in dispute. The OPT-IN proposal is a simple piece of engineering that eliminates most of the excess costs of operating DNSSEC in a large zone where takeup of DNSSEC is negligible. The working group has completed a last call on the technical merits of OPT-IN and it has been determined that the specification is sound technically. This issue is not in dispute. The issue of the burdensome costs of deployment and the technical merits not being in dispute, what then can be in dispute? The issue the Working Group chairs have chosen to accept as an issue that should block progress of OPT IN is the question of whether the specification should be modified to meet the needs of operators of large zones, and by implication the needs of their ultimate customers, the owners of domain names. 1A) In an Engineering Decision, Commercial Logic MUST suport Technology Various stratagems have been applied to prevent the admissibility of the commercial logic that no operator of a large zone is going to commit millions to the deployment of a specification if the vast majority of those costs could be eliminated through a simple modification of the protocol. This argument is further reinforced by the fact that DNSSEC has not been deployed for over a decade. It is very likely that DNSSEC will never be deployed on an appreciable scale whether or not OPTIN is accepted. The responsibility for this fact rests in large part on the chairs of the working group who have allowed to pass the best chance for deployment of DNSSEC, the transistion of the .COM and .NET zones to the ATLAS infrastructure. As was repeatedly made clear to all concerned deployment of DNSSEC could proceed as a part of the ATLAS rollout provided that the specification was agreed in time. Deployment of DNSSEC must now be justified in very different and much harder to achieve terms. Yet another factor making commercial deployment of DNSSEC on any terms difficult is the manifest lack of a necessary Internet application that cannot be deployed without DNSSEC and the lack of buy-in from the major platform vendors. When I tell people that I am working on DNSSEC I am most often asked if that had not died a decade ago, then they ask if I am still writing code for PDP-11 or if I am ready to make the leap to VAX? Given these obstacles to deployment it is clear that the accusations of OPTIN opponents that the proposal is some sort of plot to kill DNSSEC is clearly false. DNSSEC is to all intents and purposes dead. OPTIN and the related improvements are an attempt to re-animate the corpse. There is still a chance that DNSSEC can be deployed, in particular the prevelance of SPAM demonstrates a clear need for a mechanism for advertising security policy so that an email recipient can verify the sender address to see if the purported sender does in fact authorize the mode of delivery. If secure the DNS is one candidate for that advertisement mechanism. Another initiative the author has been involved in has been the promotion of XKMS and DNS linked PKI as a means of superceeding the failed concept of deploying and X.500 directory at Internet scale. 1B) Chance of Divergent Deployments In essence the Working Group has told the large registrars that their concerns are of no importance. This is a dangerous situation since divergence in the DNS specifications can only be avoided if the large registrars continue to support a group that has stated that it does not intend to support them. Already there are proposals to deploy OPTIN, either on the basis of an Experimental RFC or on the basis of no RFC at all. While some of the consequences of this divergence could be mitigated it is surely better to prevent it taking place. Asking the parties that are being told that their issues do not count not to make unpleasant threats is not going to prevent a divergence. All that strategy would achieve is to ensure that when the inevitable occured it would come as a complete surprise. 2) Procedural Abuse The present last call is actually the fourth that the group has been presented with. At no time has the group rejected OPT-IN or have the discussions in last call been interpretable as anything other than a narrow consensus in favor of OPT-IN with the large domain registries and Paul Vixie of BIND being in favor and others against. Instead of forwarding the draft to the IESG a series of stratagems has been employed to prevent any decision that would be appealable on the technical merits. A pattern that continues to this day. The first Last Call terminated with no decision from the chairs until a later report stated that the matter had been referred to the DNS Directorate (see below) The second Last Call terminated with no comments raised in opposition. A chair then stated that the standard on this occasion had been choosen as a requirement for positive affirmation, and not as had been the custom of that working group until that date of no opposing comments. The lack of statements of support was in large part the result of a request that had been made by OPTIN opponents to OPTIN proponents to avoid re-raising what had become a divisive and contentious issue. The third Last Call was confined to the technical issues of opt in. These were to be discussed before the valoidity of the requirements on which the proposal is based. Once again the consensus of the working group was in favor of opt-in. The fourth Last Call result has not been announced and it is likely will never be announced. The clear consensus, nay unanimity! amongst those parties that operate the class of infrastructure whose needs OPT-IN is meant to serve is in favor of OPTIN. One of the chairs has suggested though that such opinions have to be given weight in accordance with the 'expertise' he accords to the individuals concerned. If commercial interest is not going to play a part in the operation of the IETF then what grounds can there be for 'expertise'. How dare the claim be made that an academic whose experience of DNS operations is limited to reading theory and compiling BIND gainsay the expertise of those who keep the Internet running on a daily basis? The opponents of OPTIN have frequently pointed to the IETF policy that we are all individual contributors and do not speak for our employers, thus conveniently depriving those of us with responsibilities to our customers, the ultimate users of the Internet the authority to speak in that role. They have not however shrunk from using the fact of our employment against us. Almost every statement I have made on the subject of OPTIN has been attacked on the grounds of pecuniary interest. OPTIN opponents have also attempted to silence my dissent by complaining to my employer. Finally it has been asserted that this issue has become a an issue of personalities rather than technical merit. I absolutely concur and in this regard report that Randy Bush informed me of this fact in the first DNSEXT meeting I attended, befire I had in fact made any contribution to the group directly and I am sure before Randy could have any personal knowledge of either me or my work. Rather than allow me to give my name and company directly he choose to deliberately and audibly hiss in order to intimidate me. I am not the type of person to be intimidated so easily, but yes the action and Randy's subsequent refusal to appologise has of course coloured all the deallings between myself and the group. I conclude from such actions that Randy Bush has from the start intended to make the DNSEXT group a hostile environment for participation by people such as myself. In this respect I believe that Randy Bush has willfully broken the core values of the IETF, namely inclusiveness in persuit of his own personal agenda. 3) Failure to observe open process At one point OPT-IN was refered to the 'DNS Directorate'. This being a closed body that does not minute its deliberations, this referal however allegedly proper in terms of IETF process cannot be considered to be an open process. The referal to the DNS Directorate was not notified to the WG in advance, the first notice that was given was a statement that the Doirectorate had decided against OPT-IN. The Directorate then composted the OPT-IN document for a further six months until the WG finaly restarted work of its own accord. I can find absolutely no record of a report to the WG of the Directorate input. I requested the right to participate in the discussions of the directorate as someone very familiar with security issues and in particular the workings of OPT-IN and was refused. That left Steve Bellovin and Derek Atkins as the only members of the Directorate who were first and foremost cryptographic security experts. Indeed so opaque are the workings of the Directorate that even its members do not know whether they are members or not. Derek Atkins reports that he only discovered he was no longer on the directorate through a third party. In conclusion, it is clear that the DNSEXT working Group has done all that it can on this subject. It is now time for the IESG to consider the issue on the technical merits. If OPTIN is not to proceed they must state whether they believe that DNSSEC deployment will ever be feasible and if so which parties they believe are going to support deployment. 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 Wed Apr 30 02:52: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 CAA23658 for ; Wed, 30 Apr 2003 02:52:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AlK2-000FaF-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 06:44:06 +0000 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 19AlJW-000FUf-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 06:43:34 +0000 Received: (qmail 64586 invoked by uid 1016); 30 Apr 2003 06:44:03 -0000 Date: 30 Apr 2003 06:44:03 -0000 Message-ID: <20030430064403.64584.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-27.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,OPT_IN,OPT_IN_CAPS, 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 Hallam-Baker, Phillip writes: > the security considerations of an unsecured delegation and a secured > delegation to an unsecured zone are exactly the same The same argument cuts both ways. To fix the existing security disaster, we have to secure all the zones _and_ we have to secure the delegations. If the .com people were prepared for this, they wouldn't need opt-in. Opt-in allows the .com people to claim full DNSSEC support when the reality is that they can't handle a DNSSEC universe. It takes a failed security system and tries to pretend that it's a working system. ---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 Wed Apr 30 08:50: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 IAA00556 for ; Wed, 30 Apr 2003 08:50:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AquS-000GMA-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 12:42:04 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 19AquP-000GLx-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 12:42:01 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h3UCd71F026499 for ; Wed, 30 Apr 2003 05:39:07 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Apr 2003 05:42:00 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Wed, 30 Apr 2003 05:41:49 -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 Dan, 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. All anyone is talking about is adding crypto to the DNS, that is not by any step of the imagination eliminating all risks, regardless of whether you deploy with or without OPTIN. Security is risk control, not risk elimination. Systems that attempt to eliminate all risks, even those not relevant to a particular deployment tend not to be deployed. We have had ten years of non-deployment here. Do you really want to wait another ten? Without OPTIN DNSSEC becomes even more expensive to deploy than PKIX. That is quite some feat. Phill > -----Original Message----- > From: D. J. Bernstein [mailto:djb@cr.yp.to] > Sent: Wednesday, April 30, 2003 2:44 AM > To: namedroppers@ops.ietf.org > Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN > > > Hallam-Baker, Phillip writes: > > the security considerations of an unsecured delegation and a secured > > delegation to an unsecured zone are exactly the same > > The same argument cuts both ways. To fix the existing > security disaster, > we have to secure all the zones _and_ we have to secure the > delegations. > If the .com people were prepared for this, they wouldn't need opt-in. > > Opt-in allows the .com people to claim full DNSSEC support when the > reality is that they can't handle a DNSSEC universe. It takes a failed > security system and tries to pretend that it's a working system. > > ---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: > -- to unsubscribe send a message to namedroppers-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 Apr 30 10:22: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 KAA05789 for ; Wed, 30 Apr 2003 10:22:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AsNq-000PS5-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 14:16:30 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19AsNX-000PRN-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 14:16:11 +0000 Received: by sentry.rv.nailabs.com; id KAA16908; Wed, 30 Apr 2003 10:17:19 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma016901; Wed, 30 Apr 03 10:16:26 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6/8.11.6) with ESMTP id h3UEFHA09355 for ; Wed, 30 Apr 2003 10:15:17 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Wed, 30 Apr 2003 10:15:17 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-27.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, 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 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: From owner-namedroppers@ops.ietf.org Wed Apr 30 11:00: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 LAA07938 for ; Wed, 30 Apr 2003 11:00:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19At10-0001Th-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 14:56:58 +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 19At0w-0001TA-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 14:56:54 +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 h3UEumbV006349 for ; Wed, 30 Apr 2003 16:56:48 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) with ESMTP id h3UEulTB006346 for ; Wed, 30 Apr 2003 16:56:47 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 30 Apr 2003 16:56:47 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-39.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,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 Wed, 30 Apr 2003, Sam Weiler wrote: > There's also the deletion ("spoof a zone out of existence") attack. Sam, when you use Opt-In, the domain that is 'skipped' using NXT is not secured. Its part of the definition, similarly: an unlocked door can be opened. Don't blame the lock. Blame the policy for the door. Protection against your deletion ("spoof a zone out of existence") attack: sign the delegated zone. A secured delegation to an unsecured zone is as practical as an unsecured delegation. 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 Wed Apr 30 11:24: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 LAA08574 for ; Wed, 30 Apr 2003 11:24:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AtNK-0002T2-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 15:20:02 +0000 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 19AtNG-0002SG-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 15:19:58 +0000 Received: from isi.edu (wireless221.east.isi.edu [65.123.202.221]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3UFJf111920; Wed, 30 Apr 2003 08:19:41 -0700 (PDT) Date: Wed, 30 Apr 2003 11:19:40 -0400 Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Daniel Massey , To: Sam Weiler From: Daniel Massey In-Reply-To: Message-Id: <29FE364A-7B1F-11D7-9174-000393C783A2@isi.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, 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, April 30, 2003, at 10:15 AM, Sam Weiler wrote: > 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. > This has always seemed like nothing more than smoke and mirrors to me. If I want to delete a zone without opt-in, I will send the valid NXT RR proving that the zone is not signed and I will make up any NS records of my choosing. As Roy points out, security has ended at this point so all bets are off. I don't see how the signed NXT RR has bought you anything here. If I want to delete a zone with opt-in, I will send the valid NXT RR proving the range containing that zone is not signed (and will optionally make up any NS records of my choosing or just say no zone). I think you start to point out the tip of the iceberg: if I can convince some IDS to do a look of work trying to check unsecure zones that can (by definition) never be authenticated, then I believe I will have lots of fun making your IDS do a variety of bad things. Good luck to your IDS design :) Dan > 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 Wed Apr 30 13:55: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 NAA14766 for ; Wed, 30 Apr 2003 13:55:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Avfm-000AHF-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 17:47:14 +0000 Received: from stoneport.math.uic.edu ([131.193.178.160]) by psg.com with smtp (Exim 3.36 #1) id 19Avfi-000AGt-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 17:47:10 +0000 Received: (qmail 60311 invoked by uid 1016); 30 Apr 2003 17:47:40 -0000 Date: 30 Apr 2003 17:47:40 -0000 Message-ID: <20030430174740.60310.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-28.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,OPT_IN_CAPS,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 Hallam-Baker, Phillip writes: > All anyone is talking about is adding crypto to the DNS Security is not some optional feature that we want a few people to ``opt in'' to. We need a security system that works for _all_ DNS records. Evidently the .com people don't think they can sign all their records. That's a serious problem. It has to be fixed. Opt-in doesn't fix it. > What value do you claim there is to securing the delegation without > any security on the delegated zone? Communication from the zone server is often secured by mechanisms other than DNSSEC. But this is a side issue. I'm talking about a different situation, the situation we're aiming for: namely, having _all_ zones signed. The .com people can't handle this. Opt-in doesn't help the .com people handle it. Opt-in tends to hide the fact that they can't handle it. ---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 Wed Apr 30 14:33: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 OAA16356 for ; Wed, 30 Apr 2003 14:33:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AwGI-000CU7-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 18:24:58 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19AwGE-000CTv-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 18:24:54 +0000 Received: by sentry.rv.nailabs.com; id OAA22748; Wed, 30 Apr 2003 14:26:01 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma022737; Wed, 30 Apr 03 14:25:49 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6/8.11.6) with ESMTP id h3UIOeG15374; Wed, 30 Apr 2003 14:24:40 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Wed, 30 Apr 2003 14:24:40 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Roy Arends cc: Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, 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 Wed, 30 Apr 2003, Roy Arends wrote: > > Protection against your deletion ("spoof a zone out of existence") attack: > sign the delegated zone. > > A secured delegation to an unsecured zone is as practical as an unsecured > delegation. Roy, As Dan so ably points out, signing a child zone won't protect it from someone corrupting the NS glue, whether or not there's a DS in the parent. But adding the NXT to the parent, with or without a DS, signals the existence of the delegation. A client seeing an NXT at least knows that the delegation exists. It may not know how to find it, for inability to get the glue or because it was fed bad glue, but it knows that it's there. That's a different and more informative failure mode, and there may be ways of recovering from it. In an opt-in zone (in an unsecure span), you're telling the client to fallback to the current state of the world: there's no reason to believe that there's anything in the span. Without opt-in, you know something should be there, and you can try to recover (not that we know how, yet). And whether or not the child is signed makes no difference. Yes, this would be much more interesting if the parent signed the glue. Too bad we're not redoing delegations at this point in the process. Yesterday, you wrote: > All authoritative records are signed, with or without opt-in, and > can be verified to be valid or not. Correct, but misleading. The parent is authoritative for the existence of a delegation, and the existence is proved with an NXT and SIG(NXT). So while the parent isn't authoritative for the NSset, it is making an authoritative statement by the inclusion of a NXT. Without opt-in, it makes an authoritative statement by the omission of a NXT ("there's nothing to see here, move along"). With opt-in, omission of the NXT is ambiguous. -- 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 Wed Apr 30 14:53: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 OAA17916 for ; Wed, 30 Apr 2003 14:53:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AwdA-000EFv-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 18:48:36 +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 19Awd6-000EFd-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 18:48:32 +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 h3UImRbV011433; Wed, 30 Apr 2003 20:48:27 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.6/Debian-7) with ESMTP id h3UImQKc011430; Wed, 30 Apr 2003 20:48:26 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Wed, 30 Apr 2003 20:48:26 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Sam Weiler cc: namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN In-Reply-To: Message-ID: References: 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 Wed, 30 Apr 2003, Sam Weiler wrote: > On Wed, 30 Apr 2003, Roy Arends wrote: > > > > Protection against your deletion ("spoof a zone out of existence") attack: > > sign the delegated zone. > > > > A secured delegation to an unsecured zone is as practical as an unsecured > > delegation. > > Roy, > > As Dan so ably points out, signing a child zone won't protect it from > someone corrupting the NS glue, whether or not there's a DS in the > parent. But adding the NXT to the parent, with or without a DS, > signals the existence of the delegation. Sign the delegated zone implies the parent signs the delegation, i.e. add the DS/NXT/SIG set. I didn't want to spell it out, I thought it was obvious. > A client seeing an NXT at least knows that the delegation exists. It > may not know how to find it, for inability to get the glue or because it > was fed bad glue, but it knows that it's there. That's a different and > more informative failure mode, and there may be ways of recovering from > it. > > In an opt-in zone (in an unsecure span), you're telling the client to > fallback to the current state of the world: there's no reason to > believe that there's anything in the span. Sure, plain ol'dns. > Without opt-in, you know something should be there, and you can try to > recover (not that we know how, yet). No, there is no recover. DNSSEC is simply error detection, not error correction. You can detect an error merely by validating a sig. No sig, no validation. If a certain branch does not want to be secured, why bother do this in some intersection. Either you sign the whole intersection (delegation at parent (NXT/DS/SIG) AND the delegated zone) or you sign neither, any other combination is not secure. > And whether or not the child is signed makes no difference. > > Yes, this would be much more interesting if the parent signed the > glue. Too bad we're not redoing delegations at this point in the > process. > > Yesterday, you wrote: > > All authoritative records are signed, with or without opt-in, and > > can be verified to be valid or not. > > Correct, but misleading. The parent is authoritative for the > existence of a delegation, and the existence is proved with an NXT and > SIG(NXT). I said "authoritative records" not "authoritative responses". There is nothing misleading about that. > So while the parent isn't authoritative for the NSset, it is making an > authoritative statement by the inclusion of a NXT. An Opt-In NXT record is interpreted as: "authoritative that there are no signed delegations" It is all in the eye of the resolver, if it queries for some endpoint, it does not matter which entity states the authoritative 'unsigned'. Not existant is then similar as to not signed to a secure resolver. > Without opt-in, it makes an authoritative statement by the omission of a > NXT ("there's nothing to see here, move along"). With opt-in, omission > of the NXT is ambiguous. Whatever, If I want security, an open door has at much value as a non existant door. 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 Wed Apr 30 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 PAA19428 for ; Wed, 30 Apr 2003 15:04:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AwnC-000EvS-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 18:58:58 +0000 Received: from mail-out2.apple.com ([17.254.0.51]) by psg.com with esmtp (Exim 3.36 #1) id 19Awmp-000Eum-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 18:58:35 +0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h3UIwZQd001786 for ; Wed, 30 Apr 2003 11:58:35 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 30 Apr 2003 11:58:22 -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 h3UIwXIa028143 for ; Wed, 30 Apr 2003 11:58:33 -0700 (PDT) Message-Id: <200304301858.h3UIwXIa028143@scv3.apple.com> Subject: RFC 2181: What is the maximum length of a domain name? Date: Wed, 30 Apr 2003 11:58:34 -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=-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 It is well-known that the maximum length of a domain name is 255 octets. It sounds simple, but what is included in that count? * Is it the conventional API representation of the name, with text and separator dots? Is the final trailing dot included? * Or is it the on-the-wire representation of the name, with length bytes and data bytes? Is the final null root label included? To illustrate, is the length of "apple.com" considered to be 9, 10 or 11? (A) Text representation, as commonly written with no trailing dot: "apple.com" Length = 9 (B) Text representation, with trailing dot: "apple.com." Length = 10 (C) On-the-wire representation, excluding terminator: ----------------------------------------------- | 0x05 | a | p | p | l | e | 0x03 | c | o | m | ----------------------------------------------- Length = 10 (D) On-the-wire representation, as it actually appears in a packet, including final null root label: ------------------------------------------------------ | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 | ------------------------------------------------------ Length = 11 RFC 1034 seems relatively clear: >To simplify implementations, the total number of octets that represent a >domain name (i.e., the sum of all label octets and label lengths) is >limited to 255. While this certainly could be more specific, with a little thought it seems clear that the LEN("apple.com")=11 interpretation is the correct one: 1. The RFC 1034 text above says that *all* label octets and label lengths are included in the count. The final 0x00 is the label length byte for the zero-length root label at the end, so it is included in the count. 2. The RFC 1034 text above says "the total number of octets that represent a domain name". The final 0x00 is an essential part of how you represent a domain name in a packet -- if you try to omit it, then it won't work. Therefore it is included in the count. If the intent of RFC 1034 were really to say, "The total number of octets that represent a domain name, not counting the final zero," then I think it would have said that explicitly. I don't think it is reasonable to assume, "Not counting the final zero," unless the text actually says that. So far, so good. The text could have been clearer, but I think we have discerned the correct meaning. Unfortunately, RFC 2181 "Clarifications to the DNS Specification" contradicts this: > A full domain > name is limited to 255 octets (including the separators). The zero > length full name is defined as representing the root of the DNS tree, > and is typically written and displayed as ".". What is "The zero length full name"? The shortest possible name is just one byte long: a single zero byte. That's one byte, not zero bytes. You can't put a zero-byte name into a DNS packet. RFC 1034 is talking about the on-the-wire representation, with length bytes and data bytes. RFC 2181 is talking about the conventional API representation of the name, with text and separator dots. RFC 2181 also describes the root name, ".", as the "zero length full name", implying that the final dot in any name is not counted. This would appear to support the LEN("apple.com")=9 interpretation. There's a discrepancy of *two* between RFC 1034 and RFC 2181. My current code uses the RFC 1034 interpretation (the total number of octets that it takes to represent a domain name in a packet, including all label length octets, all label data octets, and the label length octet for the terminating root label, so that LEN("apple.com")=11). Having given this some thought, I believe this is the correct interpretation of RFC 1034, but I'm willing to listen to arguments. 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 Wed Apr 30 15:24: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 PAA21291 for ; Wed, 30 Apr 2003 15:24:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ax6g-000GEd-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 19:19:06 +0000 Received: from momotombo.techfak.uni-bielefeld.de ([129.70.136.107]) by psg.com with esmtp (Exim 3.36 #1) id 19Ax6T-000GDc-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 19:18:53 +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 h3UJIpm12004; Wed, 30 Apr 2003 21:18:51 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h3UJIoQ14406; Wed, 30 Apr 2003 21:18:51 +0200 (MEST) Message-Id: <200304301918.h3UJIoQ14406@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: Stuart Cheshire Cc: namedroppers@ops.ietf.org Subject: Re: RFC 2181: What is the maximum length of a domain name? In-reply-to: Your message of "Wed, 30 Apr 2003 11:58:34 PDT." <200304301858.h3UIwXIa028143@scv3.apple.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Wed, 30 Apr 2003 21:18:50 +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 > * Is it the conventional API representation of the name, with text and > separator dots? Is the final trailing dot included? neither - nor. It's the wire format length which is restricted to 255 octets. That's 253 octets with conventional ASCII representation. The "final trailing dot" is not included, because it's not part of the name, except for the root. > * Or is it the on-the-wire representation of the name, with length bytes > and data bytes? Is the final null root label included? Yes and yes. That's 255 octets in wire format and 253 in conventional (i.e. no \-style escapes) ASCII representation. In text format n labels have n-1 intermediate dots (the "final trailing dot" is not included, because it's not part of the name), while you need n length octets plus one for the terminating NUL octet in wire format. That's n - 1 vs. n + 1. For the ease of the calculation I've assumed that the name consists of "printable" characters only. > (C) On-the-wire representation, excluding terminator: > ----------------------------------------------- > | 0x05 | a | p | p | l | e | 0x03 | c | o | m | > ----------------------------------------------- > Length = 10 Where would it occur in this form? > Unfortunately, RFC 2181 "Clarifications to the DNS Specification" > contradicts this: > > > A full domain > > name is limited to 255 octets (including the separators). The zero > > length full name is defined as representing the root of the DNS tree, > > and is typically written and displayed as ".". > > What is "The zero length full name"? The shortest possible name is just > one byte long: a single zero byte. That's one byte, not zero bytes. You > can't put a zero-byte name into a DNS packet. Unfortunately the use of "separators" suggests that the sentence addresses a textual representation, for which a maximum length of 255 is wrong. > Comments? I remember an old posting by Paul or Mark comparing the different encoding levels (compressed/uncompressed wire format, text format, expanded text). Maybe an Informational document on this would help. Fun will increase with IDN. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 30 16:51: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 QAA23725 for ; Wed, 30 Apr 2003 16:51:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AySY-000MFN-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 20:45:46 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19AyRv-000MCw-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 20:45:07 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h3UKj04q023753; Wed, 30 Apr 2003 13:45:00 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Apr 2003 13:45:05 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'D. J. Bernstein'" , namedroppers@ops.ietf.org Subject: RE: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Date: Wed, 30 Apr 2003 13:45:04 -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.2 required=5.0 tests=BAYES_01,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 > Hallam-Baker, Phillip writes: > > All anyone is talking about is adding crypto to the DNS > > Security is not some optional feature that we want a few > people to ``opt > in'' to. We need a security system that works for _all_ DNS records. Tough, there is no way of securing www.xyz.com unless xyz.com chooses to deploy DNSSEC in the zone. So your argument does cut both ways. > Evidently the .com people don't think they can sign all their records. > That's a serious problem. It has to be fixed. Opt-in doesn't fix it. > > > What value do you claim there is to securing the delegation without > > any security on the delegated zone? > > Communication from the zone server is often secured by > mechanisms other > than DNSSEC. But this is a side issue. no it isn't it is absolutely the central issue. Trying to pretend that securing dotCOM is relevant if the subdomains are insecure is precisely the bogus security you are arguing against. > I'm talking about a different situation, the situation we're > aiming for: > namely, having _all_ zones signed. The .com people can't handle this. > Opt-in doesn't help the .com people handle it. Opt-in tends > to hide the > fact that they can't handle it. If you want dotcom signed then best provide a spec that meets the criteria of the operator. If you want to propose an alternative that meets those criteria then do so. 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 Wed Apr 30 17:01: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 RAA24161 for ; Wed, 30 Apr 2003 17:01:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19AydT-000N8r-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 20:57:03 +0000 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 19AydQ-000N8O-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 20:57:00 +0000 Received: from isi.edu (scout-3.cnds.jhu.edu [128.220.221.223]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3UKuk116176; Wed, 30 Apr 2003 13:56:46 -0700 (PDT) Date: Wed, 30 Apr 2003 16:56:45 -0400 Subject: Re: Summary: DNSEXT WGLC: To OPT-IN or not to OPT_IN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Daniel Massey , Roy Arends , To: Sam Weiler From: Daniel Massey In-Reply-To: Message-Id: <40F76948-7B4E-11D7-9174-000393C783A2@isi.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-27.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, 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, April 30, 2003, at 02:24 PM, Sam Weiler wrote: > On Wed, 30 Apr 2003, Roy Arends wrote: >> >> Protection against your deletion ("spoof a zone out of existence") >> attack: >> sign the delegated zone. >> >> A secured delegation to an unsecured zone is as practical as an >> unsecured >> delegation. > > Roy, > > As Dan so ably points out, signing a child zone won't protect it from > someone corrupting the NS glue, whether or not there's a DS in the > parent. But adding the NXT to the parent, with or without a DS, > signals the existence of the delegation. A client seeing an NXT at > least knows that the delegation exists. It may not know how to find > it, for inability to get the glue or because it was fed bad glue, but > it knows that it's there. in other words, you know that the parent thinks a delegation exists and have a proof there is now way you can every be sure you have reached a real server for that delegation. so what? > That's a different and more informative > failure mode, and there may be ways of recovering from it. > such as?? perhaps I'm not understanding your claim, but it reads to me as there may be some yet to be thought of way to use DNSSEC to help recover from errors reaching unsigned zones and we should not deploy opt-in because it may interfere with this yet to be thought protection for unsigned zones. I view DNS security adding value to signed zones. if you want to avoid various problems, sign the zone. using DNSSEC to try and recover from problems with unsigned zones is dangerous at best in my view. a system that adds value to unsigned zones is a different problem from DNSSEC and I have not seen any justification or even promising approaches that applying to DNSSEC to unsigned zones would be helpful. I would also say that trying to use the DNSSEC RRs to infer things about unsigned zones is something we should recommend strongly against (isn't one justification for changing the type codes based on the use of an NXT RR that can not be authenticated?) Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 30 17:30: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 RAA24863 for ; Wed, 30 Apr 2003 17:30:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Az2g-000PTg-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 21:23:06 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19Az2d-000PTR-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 21:23:03 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id D0D5F3B8; Wed, 30 Apr 2003 17:23:02 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3FA31362; Wed, 30 Apr 2003 17:23:02 -0400 (EDT) Received: from [192.136.136.50] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b4) with ESMTP id 220249; Wed, 30 Apr 2003 17:12:37 -0400 Mime-Version: 1.0 X-Sender: edlewis@mta Message-Id: In-Reply-To: <200304301918.h3UJIoQ14406@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200304301918.h3UJIoQ14406@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 30 Apr 2003 17:22:01 -0400 To: Peter Koch From: Edward Lewis Subject: Re: RFC 2181: What is the maximum length of a domain name? Cc: Stuart Cheshire , 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 On the wire, the name is 1 to 255 octets, with the smallest being '0x00' in the first byte. As far as printed ("conventional"), if you discount the escaped characters, you will have up to 254. I disagree with Peter about the trailing dot - that is included in a formal name. An API ought to allow for it because in some instances (e.g. DHCP options) it is allowed to include both partially-qualified and fully-qualified domain names. If you allow for escaped characters, then you will multiple 254 by 4 and then subtract the minimum number of labels needed to fill up 255 octects worth of name. (A label can be only 64 octets long - including the length byte.) So - len label len label len label len label len 1 63 1 63 1 63 1 61 1 (individ counts) 1 64 65 128 129 192 193 254 255 (cumulative to reach 255) --- ----- --- ----- --- ----- --- ----- --- value 63 ??? 63 ??? 63 ??? 61 ??? 0 It looks to me 4*(63+63+63+61)+5 = 1005 octets for the characters is possible (neglecting local encoding and the C-style terminating '\0'). On or before 21:18 +0200 4/30/03, someone wrote: >> Unfortunately, RFC 2181 "Clarifications to the DNS Specification" >> contradicts this: >> >> > A full domain >> > name is limited to 255 octets (including the separators). The zero >> > length full name is defined as representing the root of the DNS tree, >> > and is typically written and displayed as ".". >> >> What is "The zero length full name"? The shortest possible name is just >> one byte long: a single zero byte. That's one byte, not zero bytes. You >> can't put a zero-byte name into a DNS packet. Something to clean up when we shoot 2181 into Draft Standard. >I remember an old posting by Paul or Mark comparing the different encoding >levels (compressed/uncompressed wire format, text format, expanded text). >Maybe an Informational document on this would help. Fun will >increase with IDN. This is part of why I bristle at defining a standard "presentation" format. On the wire, 255 is 255 - no matter how you cook it up. Compression of messages doesn't change the syntactic representation, just how the transport is carried out. Once you go start worrying about the presentation (presented) format you get into a rat's nest. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 Wed Apr 30 19:16: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 TAA29263 for ; Wed, 30 Apr 2003 19:16:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B0fr-0009Pb-00 for namedroppers-data@psg.com; Wed, 30 Apr 2003 23:07:39 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19B0fo-0009Of-00 for namedroppers@ops.ietf.org; Wed, 30 Apr 2003 23:07: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 h3UN6xab057999; Thu, 1 May 2003 09:06:59 +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 h3UN701G001836; Thu, 1 May 2003 09:07:00 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200304302307.h3UN701G001836@drugs.dv.isc.org> To: Stuart Cheshire Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: RFC 2181: What is the maximum length of a domain name? In-reply-to: Your message of "Wed, 30 Apr 2003 11:58:34 MST." <200304301858.h3UIwXIa028143@scv3.apple.com> Date: Thu, 01 May 2003 09:07:00 +1000 X-Spam-Status: No, hits=-8.0 required=5.0 tests=BAYES_10,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 255 refers to the uncompressed wire representation. All other maximums are derived from that. e.g. space required to hold a ascii encoded arbitary domain name with final period null terminated. 4*250 (label characters) + 4 (periods) + 1 (null) Hostnames also have a maximum length of 255. There are some hostnames that you cannot encode in the DNS as they are too long to fit the wire representation. Hostnames do not have a trailing dot. The maximum length hostname that can be stored in the DNS is 253 (250 label characters and 3 period) characters. -- 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 Apr 30 23:02: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 XAA03864 for ; Wed, 30 Apr 2003 23:02:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19B4Im-000MpN-00 for namedroppers-data@psg.com; Thu, 01 May 2003 03:00:04 +0000 Received: from randy by psg.com with local (Exim 3.36 #1) id 19B4Ij-000Moe-00 for namedroppers@ops.ietf.org; Thu, 01 May 2003 03:00:01 +0000 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Thu, 01 May 2003 03:00:01 +0000 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 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: