From owner-namedroppers@ops.ietf.org Mon Sep 1 01:37: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 BAA20818 for ; Mon, 1 Sep 2003 01:37:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19thG9-000Lff-DQ for namedroppers-data@psg.com; Mon, 01 Sep 2003 05:29:49 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19thFV-000Lcb-7j for namedroppers@ops.ietf.org; Mon, 01 Sep 2003 05:29:09 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h814vca12702 for ; Sun, 31 Aug 2003 21:57:40 -0700 Date: Sun, 31 Aug 2003 21:57:38 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf Kolkman wrote: "Going back to our proposal, you are providing us 2 lists. We now have 1 item and we would like to make sure: - Is this 1 item the complete list of issues previously discussed and that need to be reviewed? - Is the list of 'new items' an empty list? We proposed the process so that the working group can make an informed decision, based on the amount of things that need to be revisited, if we need to go back and re-argue the issue. No hidden surprises further down the road ;-) ? --Olaf Kolkman DNSEXT Co-Chair Just off the top of my head, it would appear to me that the following additional interoperability issues also exist: a. LLMNR responders are not authoritative for names within the ".local" domain. Won't this create problems in responding to queries by Rendezvous senders? Does the reverse problem also exist? (will Rendezvous responders respond to queries for domains outside of .local?) b. Multicasting. LLMNR sends unicast responses as well as queries. There was mention in Issue 44 that the unicasting of queries created an interoperability problem. What about the unicasting of responses? c. Lack of support for DNS-SD. LLMNR senders and responders typically won't support DNS-SD. This implies that they won't respond to TXT RR queries with appropriately formatted responses. Won't this cause problems as well? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 1 09:18: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 JAA05738 for ; Mon, 1 Sep 2003 09:18:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19toL1-000LeC-Mf for namedroppers-data@psg.com; Mon, 01 Sep 2003 13:03:19 +0000 Received: from [3ffe:805::230:48ff:fe22:6a53] (helo=karoshi.com) by psg.com with esmtp (Exim 4.22) id 19toKQ-000LZO-T5 for namedroppers@ops.ietf.org; Mon, 01 Sep 2003 13:02:43 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h81D2Vr03176; Mon, 1 Sep 2003 06:02:31 -0700 From: bmanning@karoshi.com Message-Id: <200309011302.h81D2Vr03176@karoshi.com> Subject: adopt wildcard clarify To: edlewis@arin.net (Edward Lewis) Date: Mon, 1 Sep 2003 06:02:31 -0700 (PDT) Cc: olaf@ripe.net (Olaf M. Kolkman), edlewis@arin.net (Edward Lewis), namedroppers@ops.ietf.org In-Reply-To: from "Edward Lewis" at Aug 28, 2003 10:05:50 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit actually, i like the idea of wildcard clarify (see below) and appreciate Ed's patience in getting this work this far. I would hope that the WG participants would get behind this work and get it advanced... otherwise I may be forced to insist that the following be supported (basically, all that is not expressly permitted is forbidden) Now... spot the errors. A prize may be awarded. To Wit: $TTL 16 . IN SOA ns.example.com. i.am.well. ( 22 1800 900 604800 999999 ) ns foo ns bar ; ; Auth delegation list ; COM ns pig. ns dog. ; arpa ns iab. ns iesg. ; ; everything not otherwise delegated.... ; * ns bill. ns kato. ; and then this zone: $TTL 16 * IN SOA ns.example.com. i.am.lame. ( 23 1800 900 604800 999999 ) ns lumpy. ns gravy. ; ; authoritative answer for non-existance * AAAA ::1 txt " not in my DNS thank you! " ; ; eof So you see, we really need wildcard clarify. :) --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 1 16:20: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 QAA12757 for ; Mon, 1 Sep 2003 16:20:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tv1f-0005Zr-BI for namedroppers-data@psg.com; Mon, 01 Sep 2003 20:11:47 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19tv06-0005Ql-SU for namedroppers@ops.ietf.org; Mon, 01 Sep 2003 20:10:10 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h81K8u7J014199 for ; Mon, 1 Sep 2003 16:08:56 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcEAAw_a4SB; Mon, 1 Sep 03 16:08:56 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h81FLq4l000108; Mon, 1 Sep 2003 11:21:52 -0400 (EDT) Date: Mon, 1 Sep 2003 11:21:52 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: Mike StJohns cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <6.0.0.14.2.20030819132716.036ab008@localhost> Message-ID: References: <20030818122248.429096f6.olaf@ripe.net> <6.0.0.14.2.20030819132716.036ab008@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.0 required=5.0 tests=DATE_IN_PAST_03_06,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm writing a wrap-up summary, but here is a reply to Mike's comments: I've been working with the premise that "signing a zone must not make your zone disappear". This same constraint that drove the DS lameness and grandparent problem fixes as well as the type code roll. If signing a zone would make it less visibile, there's too much disincentive to deploy DNSSEC. On Tue, 19 Aug 2003, Mike StJohns wrote: > The resolver either understands or doesn't understand an algorithm > If it understands it, it either trusts it or rejects it. (rejects it > because its considered broken for ex) If it trusts it, it will > follow a chain signed by it, otherwise it won't. > the resolver may also impose certain minimums on things like key > length to determine trust/reject? A client may certainly do this, but only if it would also reject unsigned zones. For example, you might say "I'll only accept DNS data signed by 1024+ bit RSA/SHA-1 keys". Dandy. Then a zone choosing to sign only with DSA is no less visible to that client than if it were unsigned. The danger comes when signing with 512 bit RSA/SHA-1 leaves you inivisible where you weren't before. We should prohibit clients from doing that, to keep from providing disincentives to signing. By the same token, if a client thinks an algorithm is broken, it may ignore it -- if it would normally pass through unsigned data, it should still pass through data signed only by the broken algorithm. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 1 16:20: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 QAA12772 for ; Mon, 1 Sep 2003 16:20:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tv0a-0005TF-Ei for namedroppers-data@psg.com; Mon, 01 Sep 2003 20:10:40 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19tv03-0005QH-Rj for namedroppers@ops.ietf.org; Mon, 01 Sep 2003 20:10:07 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h81K8rIb014184 for ; Mon, 1 Sep 2003 16:08:53 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAs_a4SB; Mon, 1 Sep 03 16:08:51 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h81G6PLl002388; Mon, 1 Sep 2003 12:06:25 -0400 (EDT) Date: Mon, 1 Sep 2003 12:06:25 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <5.1.1.6.2.20030814233139.0169ef58@localhost> Message-ID: References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_30,DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It sounds like Olafur and I have different views of the current state of the world. It sounds like Olafur thinks clients should already be enforcing the tighter rules that I'm asking for, or something similar: > IFF some RRset is only signed with type 42 then any validator that > does not understand/use that type, will drop this RRset as bad, this > is the publishers choice. As I said in response to MSJ, this violates the premise that "signing a zone must not make your zone less visible". But if this is the current state of the world, then my scheme is really a no-op. It just clarifies client behavior and tells zone owners how to avoid being knocked off the net. To clarify, my logic went as: 1) Signing (or adding a new algorithm) must do no harm -- adding RRSIGs should not cause a zone to be less visible than before. 2) In the current world (according to the current specs), it's OK to sign some RRsets with one algorithm, and some with another. 3) A client that comes across an RRset with an RRSIG of only a non-understood type must treat the data as unsigned in order to reconcile #1 and #2. 4) #3 allows a degradation attack, which is bad. And I proposed that we change #2 to deal with this -- specifically that we say it's not okay to, as Ed puts it, "'turn off' security 'per algorithm' in a zone". With that in place, clients can then impose a stricter set of checks, and the degradation attack goes away. From the sound of Olafur's and Miek's messages, they don't believe one of #1 or #2, and I'm not sure which. Either way, I'm pretty committed to #1. If #2 isn't true, then my scheme is a merely a clarification. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 1 16:20: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 QAA12790 for ; Mon, 1 Sep 2003 16:20:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tv16-0005Vq-AL for namedroppers-data@psg.com; Mon, 01 Sep 2003 20:11:12 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19tv04-0005Qb-UK for namedroppers@ops.ietf.org; Mon, 01 Sep 2003 20:10:09 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h81K8sVW014188 for ; Mon, 1 Sep 2003 16:08:54 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcCAAu_a4SB; Mon, 1 Sep 03 16:08:53 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h81FRhHX000312; Mon, 1 Sep 2003 11:27:43 -0400 (EDT) Date: Mon, 1 Sep 2003 11:27:43 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <20030818122248.429096f6.olaf@ripe.net> Message-ID: References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <6.0.0.14.2.20030815121652.035be698@localhost> <20030817020128.GA20956@atoom.net> <20030818122248.429096f6.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20,DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The problem as I read it from Mike's and Ed's message, is that one > wants to turn the use of specific algorithms within a zone on or of, > without imposing requirements on the algorithm used by the parent (and > having the parent impose algorithms on the child). ... > The scheme below does not require the algorithms of the parent and > child to match. Besides one can use the keys without the SEP bit to > turn specific algorithms on or off; making the it decidable which > algorithms to expect. My scheme doesn't require that they match either. A parent could have a DS of type 42 (for the child) signed only by a type 5 (it's own algorithm choice). That's fine and dandy. Olaf's scheme looks similar to mine, but it allows algorithms to be removed in the DNSKEYset at the cost of assigning protocol semantics to the SEP bit. I think it's sufficient to allow algorithms to be removed at the DSset (they can be added there or in the DNSKEYset). If we're worried about a malicious parent imposing algorithms, then we might as well worry about it imposing it's own choice of DS, and not telling the child what the corresponding DNSKEY is. So, again, I think the scheme I proposed is sufficient. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 12:55: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 MAA14232 for ; Tue, 2 Sep 2003 12:55:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uE7D-0001eu-Kt for namedroppers-data@psg.com; Tue, 02 Sep 2003 16:34:47 +0000 Received: from [193.0.8.2] (helo=server.ripemtg.ripe.net) by psg.com with esmtp (Exim 4.22) id 19uE6W-0001ZM-Fq for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 16:34:04 +0000 Received: from mint.tislabs.com (mint.tislabs.com [193.0.9.154] (may be forged)) by server.ripemtg.ripe.net (8.12.9/8.12.6) with ESMTP id h82ELnxA027854; Tue, 2 Sep 2003 16:21:50 +0200 Date: Tue, 2 Sep 2003 10:21:51 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@localhost.localdomain To: bmanning@karoshi.com cc: Mike StJohns , Subject: Re: DNSSECbis Q-2: degradation attack Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=QUOTED_EMAIL_TEXT,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Resending this, since tislabs.com seems to have trouble sending mail to namedroppers. Sorry for the duplicate, if any.] > > > the resolver may also impose certain minimums on things like key > > > length to determine trust/reject? > > > > A client may certainly do this, but only if it would also reject > > unsigned zones. For example, you might say "I'll only accept DNS data > > signed by 1024+ bit RSA/SHA-1 keys". Dandy. Then a zone choosing to > > sign only with DSA is no less visible to that client than if it were > > unsigned. The danger comes when signing with 512 bit RSA/SHA-1 leaves > > you inivisible where you weren't before. We should prohibit clients > > from doing that, to keep from providing disincentives to signing. > > say what? just how are you going to enforce this prohibition? > are you proposing that a client may not create a local policy > that states "if its not signed, it doesn't exist"? What part of "'I'll only accept DNS data signed by 1024+ bit RSA/SHA-1 keys'. Dandy." didn't you understand? Sure, a client may create that policy. The policy I want to prohibit is: "I won't accept any signed DNS data; I'll take unsigned data only; if you sign your zone, you lose." This, and its variants, violate the safety property, and just like the (unintended?) policy of treating all NXTs as NXDOMAINS, they leave us with an undeployable DNSSEC. How do I plan to "enforce" it? By publicly humiliating client authors who do something different, much as we like to publicly humiliate clients that don't do negative caching. We can't keep clients from shooting DNSSEC in the foot, but we can keep from writing a spec that gives them a hunting license. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 13:29:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18712 for ; Tue, 2 Sep 2003 13:29:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uEsB-0004Lh-4W for namedroppers-data@psg.com; Tue, 02 Sep 2003 17:23:19 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19uEDR-0002Fr-8O for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 16:41:15 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h82CgNsg000688 for ; Tue, 2 Sep 2003 08:42:23 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAS6aWpb; Tue, 2 Sep 03 08:42:12 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h82C7ESp006061; Tue, 2 Sep 2003 08:07:14 -0400 (EDT) Date: Tue, 2 Sep 2003 08:07:14 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: bmanning@karoshi.com cc: Mike StJohns , namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <200309020856.h828ulv10620@karoshi.com> Message-ID: References: <200309020856.h828ulv10620@karoshi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > the resolver may also impose certain minimums on things like key > > > length to determine trust/reject? > > > > A client may certainly do this, but only if it would also reject > > unsigned zones. For example, you might say "I'll only accept DNS data > > signed by 1024+ bit RSA/SHA-1 keys". Dandy. Then a zone choosing to > > sign only with DSA is no less visible to that client than if it were > > unsigned. The danger comes when signing with 512 bit RSA/SHA-1 leaves > > you inivisible where you weren't before. We should prohibit clients > > from doing that, to keep from providing disincentives to signing. > > say what? just how are you going to enforce this prohibition? > are you proposing that a client may not create a local policy > that states "if its not signed, it doesn't exist"? What part of "'I'll only accept DNS data signed by 1024+ bit RSA/SHA-1 keys'. Dandy." didn't you understand? Sure, a client may create that policy. The policy I want to prohibit is: "I won't accept any signed DNS data; I'll take unsigned data only; if you sign your zone, you lose." This, and its variants, violate the safety property, and just like the (unintended?) policy of treating all NXTs as NXDOMAINS, they leave us with an undeployable DNSSEC. How do I plan to "enforce" it? By publicly humiliating client authors who do something different, much as we like to publicly humiliate clients that don't do negative caching. We can't keep clients from shooting DNSSEC in the foot, but we can keep from writing a spec that gives them a hunting license. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 14:08: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 OAA22424 for ; Tue, 2 Sep 2003 14:08:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uFRo-0005pn-Ca for namedroppers-data@psg.com; Tue, 02 Sep 2003 18:00:08 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.22) id 19uFRF-0005lg-M2 for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 17:59:33 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h82HxE7C002074; Tue, 2 Sep 2003 19:59:15 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) id h82HxCYg002072; Tue, 2 Sep 2003 19:59:12 +0200 Date: Tue, 2 Sep 2003 19:59:12 +0200 From: Miek Gieben To: Sam Weiler Cc: =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-ID: <20030902175911.GB1887@atoom.net> Mail-Followup-To: Sam Weiler , =?iso-8859-1?Q?=D3lafur_Gu=F0mundsson?= , namedroppers@ops.ietf.org References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@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-new X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 01 Sep, @18:06, Sam wrote in "Re: DNSSECbis Q-2: degradation ..."] > >From the sound of Olafur's and Miek's messages, they don't believe one > of #1 or #2, and I'm not sure which. Either way, I'm pretty committed > to #1. If #2 isn't true, then my scheme is a merely a clarification. i'm re-reading the entire thread to make sure I understand it. And now I do :) (have to think about the solution though). But you make one assumption: resolvers will check the zone's status before validating anything. I have yet to see such resolvers.... Those resolvers just check sigs if they get them. Just spoofing sigs (with whatever algorithm) is just as bad. (I'm not saying I like this method of resolving, i'm just saying that there already are resolvers working like this. However a bad sig is an indication that something is the matter) 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 Sep 2 14:12: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 OAA22630 for ; Tue, 2 Sep 2003 14:12:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uFWu-0006Il-8Q for namedroppers-data@psg.com; Tue, 02 Sep 2003 18:05:24 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.22) id 19uFTj-00061f-Ua for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 18:02:08 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.12.8p1/8.12.8) with ESMTP id h827oTwP034631 for ; Tue, 2 Sep 2003 09:50:29 +0200 (CEST) (envelope-from ted@open.nlnetlabs.nl) Received: (from ted@localhost) by open.nlnetlabs.nl (8.12.8p1/8.12.8/Submit) id h827oSrr034630 for namedroppers@ops.ietf.org; Tue, 2 Sep 2003 09:50:28 +0200 (CEST) (envelope-from ted) Message-Id: <200309020750.h827oSrr034630@open.nlnetlabs.nl> From: ted@NLnetLabs.nl (Ted Lindgreen) Date: Tue, 2 Sep 2003 09:50:28 +0200 In-Reply-To: ""Olaf M. Kolkman"'s message as of Aug 28, 16:55" X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: namedroppers@ops.ietf.org Subject: Re: half time report on wcard X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting "Olaf M. Kolkman", on Aug 28, 16:55, in "Re: half time report ..."] > I would like to repeat the call to provide motivated support or > opposition to the document or, if there is critique, provide motivation > and alternative text. > > -- Olaf Kolkman > DNSEXT Co-Chair. To be able to implement DNSSEC in NSD, we really need a clear and unambiguous definition of wildcards. draft-ietf-dnsext-wcard-clarify-01.txt is providing this and we would very much like to see it progressed quickly on the standards track. -- Ted Lindgreen (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 Tue Sep 2 14:16: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 OAA22940 for ; Tue, 2 Sep 2003 14:16:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uFbk-0006s8-Fg for namedroppers-data@psg.com; Tue, 02 Sep 2003 18:10:24 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.22) id 19uFWK-0006ES-5d for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 18:04:48 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h828ulv10620; Tue, 2 Sep 2003 01:56:47 -0700 From: bmanning@karoshi.com Message-Id: <200309020856.h828ulv10620@karoshi.com> Subject: Re: DNSSECbis Q-2: degradation attack To: weiler@tislabs.com (Sam Weiler) Date: Tue, 2 Sep 2003 01:56:47 -0700 (PDT) Cc: Mike.StJohns@nominum.com (Mike StJohns), namedroppers@ops.ietf.org In-Reply-To: from "Sam Weiler" at Sep 01, 2003 11:21:52 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > the resolver may also impose certain minimums on things like key > > length to determine trust/reject? > > A client may certainly do this, but only if it would also reject > unsigned zones. For example, you might say "I'll only accept DNS data > signed by 1024+ bit RSA/SHA-1 keys". Dandy. Then a zone choosing to > sign only with DSA is no less visible to that client than if it were > unsigned. The danger comes when signing with 512 bit RSA/SHA-1 leaves > you inivisible where you weren't before. We should prohibit clients > from doing that, to keep from providing disincentives to signing. say what? just how are you going to enforce this prohibition? are you proposing that a client may not create a local policy that states "if its not signed, it doesn't exist"? > -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 14:16:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22968 for ; Tue, 2 Sep 2003 14:16:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uFbF-0006mp-1J for namedroppers-data@psg.com; Tue, 02 Sep 2003 18:09:53 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.22) id 19uFWJ-0006ES-KG for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 18:04:47 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h82EMtZ13185; Tue, 2 Sep 2003 07:22:55 -0700 From: bmanning@karoshi.com Message-Id: <200309021422.h82EMtZ13185@karoshi.com> Subject: Re: DNSSECbis Q-2: degradation attack To: weiler@tislabs.com (Sam Weiler) Date: Tue, 2 Sep 2003 07:22:55 -0700 (PDT) Cc: bmanning@karoshi.com, Mike.StJohns@nominum.com (Mike StJohns), namedroppers@ops.ietf.org In-Reply-To: from "Sam Weiler" at Sep 02, 2003 08:07:14 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.6 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > unsigned zones. For example, you might say "I'll only accept DNS data > > > signed by 1024+ bit RSA/SHA-1 keys". Dandy. Then a zone choosing to > > > sign only with DSA is no less visible to that client than if it were > > > unsigned. The danger comes when signing with 512 bit RSA/SHA-1 leaves > > > you inivisible where you weren't before. We should prohibit clients > > > from doing that, to keep from providing disincentives to signing. > > > > say what? just how are you going to enforce this prohibition? > > are you proposing that a client may not create a local policy > > that states "if its not signed, it doesn't exist"? > > What part of "'I'll only accept DNS data signed by 1024+ bit RSA/SHA-1 > keys'. Dandy." didn't you understand? you are not being consistant here. your statement above indicates the clients are expected to have a local policy, and then you make the claim, on behalf of the server operators that "We should prohibit clients..." You can't have your cake and eat it too. > Sure, a client may create that policy. The policy I want to prohibit > is: "I won't accept any signed DNS data; I'll take unsigned data only; > if you sign your zone, you lose." This, and its variants, violate the > safety property, and just like the (unintended?) policy of treating > all NXTs as NXDOMAINS, they leave us with an undeployable DNSSEC. We either get to let client set policy or not. Scoping the policies that are "allowed" is presumptious for zone admins, -if- it is expected to be a client activity. > How do I plan to "enforce" it? By publicly humiliating client authors > who do something different, much as we like to publicly humiliate > clients that don't do negative caching. We can't keep clients from > shooting DNSSEC in the foot, but we can keep from writing a spec that > gives them a hunting license. If you want a fixed policy, then don't let the clients set one. They just eat what the servers say. Thats the only enforcement tool you get. If you open up policy for clients to set, then your only choice is to tell them the outcome of certain choices, some of which will hurt them. > -- Sam > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 14:20: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 OAA23389 for ; Tue, 2 Sep 2003 14:20:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uFh3-0007TG-RF for namedroppers-data@psg.com; Tue, 02 Sep 2003 18:15:53 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 19uFd2-0006zt-1u for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 18:11:44 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h82HTfLR015678 for ; Tue, 2 Sep 2003 13:29:41 -0400 (EDT) Message-ID: <00a201c37177$cb751240$b9370681@barnacle> From: "Scott Rose" To: References: Subject: Re: DNSSECbis Q-2: degradation attack Date: Tue, 2 Sep 2003 13:29:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-0.4 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Samuel Weiler" > > > > > the resolver may also impose certain minimums on things like key > > > > length to determine trust/reject? > > > > > > A client may certainly do this, but only if it would also reject > > > unsigned zones. For example, you might say "I'll only accept DNS data > > > signed by 1024+ bit RSA/SHA-1 keys". Dandy. Then a zone choosing to > > > sign only with DSA is no less visible to that client than if it were > > > unsigned. The danger comes when signing with 512 bit RSA/SHA-1 leaves > > > you inivisible where you weren't before. We should prohibit clients > > > from doing that, to keep from providing disincentives to signing. > > > > say what? just how are you going to enforce this prohibition? > > are you proposing that a client may not create a local policy > > that states "if its not signed, it doesn't exist"? > > What part of "'I'll only accept DNS data signed by 1024+ bit RSA/SHA-1 > keys'. Dandy." didn't you understand? > > Sure, a client may create that policy. The policy I want to prohibit > is: "I won't accept any signed DNS data; I'll take unsigned data only; > if you sign your zone, you lose." This, and its variants, violate the > safety property, and just like the (unintended?) policy of treating > all NXTs as NXDOMAINS, they leave us with an undeployable DNSSEC. > I don't think anyone can enforce client policy. If a client refuses signed answers (which is odd behavior, since the unsigned answer is the same minus a few RRs), it is the client's perogative. The server still is available to everyone. Pretty soon, the client will realize they are segregating themselves from the rest of the net. I don't think we can prohibit an overly strict policy either way (unsigned only, or signed with a 4096 bit key only), but those that do so will have to accept that the rest of the net might not have such strict standards. I feel the issue of unverifiable data (unknown algorithm, lost key, etc.) might need different considerations than known bad data (explicitly failed to verify) with regards to caches. Scott > How do I plan to "enforce" it? By publicly humiliating client authors > who do something different, much as we like to publicly humiliate > clients that don't do negative caching. We can't keep clients from > shooting DNSSEC in the foot, but we can keep from writing a spec that > gives them a hunting license. > > -- 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 Tue Sep 2 14:21: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 OAA23579 for ; Tue, 2 Sep 2003 14:21:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uFj7-0007i0-QJ for namedroppers-data@psg.com; Tue, 02 Sep 2003 18:18:01 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.22) id 19uFWK-0006ES-FL for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 18:04:48 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h8292SU10673; Tue, 2 Sep 2003 02:02:28 -0700 From: bmanning@karoshi.com Message-Id: <200309020902.h8292SU10673@karoshi.com> Subject: Re: DNSSECbis Q-2: degradation attack To: weiler@tislabs.com (Sam Weiler) Date: Tue, 2 Sep 2003 02:02:28 -0700 (PDT) Cc: ogud@ogud.com (=?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=), namedroppers@ops.ietf.org In-Reply-To: from "Sam Weiler" at Sep 01, 2003 12:06:25 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.5 required=5.0 tests=BAYES_30,DATE_IN_PAST_06_12,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1) Signing (or adding a new algorithm) must do no harm -- adding > RRSIGs should not cause a zone to be less visible than before. you, as zone owner, have one choice, to sign or not. you can't infer client behaviour when they are presented with this choice. You may recommend specific actions as desirable for a particular outcome, but thats about as far as you can go. > 2) In the current world (according to the current specs), it's OK to > sign some RRsets with one algorithm, and some with another. yes. > 3) A client that comes across an RRset with an RRSIG of only a > non-understood type must treat the data as unsigned in order to > reconcile #1 and #2. if and only if thats the local resolver policy. you have at least one unstated presumption here. > 4) #3 allows a degradation attack, which is bad. sort of. > >From the sound of Olafur's and Miek's messages, they don't believe one > of #1 or #2, and I'm not sure which. Either way, I'm pretty committed > to #1. If #2 isn't true, then my scheme is a merely a clarification. #1 is not enforceable. > > -- 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 Tue Sep 2 14:49: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 OAA25887 for ; Tue, 2 Sep 2003 14:49:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uG8E-000Apx-1D for namedroppers-data@psg.com; Tue, 02 Sep 2003 18:43:58 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.22) id 19uG71-000AhZ-3Q for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 18:42:43 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h82Ige7b017124; Tue, 2 Sep 2003 11:42:40 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn1-461.cisco.com [10.82.225.205]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACA26226; Tue, 2 Sep 2003 14:42:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20030902061001.05dc81e8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 02 Sep 2003 06:25:49 -0400 To: Michael Richardson From: John Schnizlein Subject: Re: LLMNR interoperability with Rendezvous? Cc: namedroppers@ops.ietf.org In-Reply-To: <8814.1062346886@marajade.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_20,DATE_IN_PAST_06_12,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:21 PM 8/31/2003, Michael Richardson wrote: >>>>>> "Ted" == Ted Lemon writes: > >> If I'm not mistaken, the BGP protocol originally used TTL=1, but > >> now recommends using TTL=255 and checking that way instead. > > Ted> Hm. I was one of the people who thought that TTL=255 wasn't such a > Ted> great idea, all other things being equal. However, nobody ever > Ted> presented any strong reason why we should use one over the other - > Ted> it was always a matter of preferences and fine distinctions. > > TTL=1 depends upon the routers dropping at exactly the right time. > TTL=255 is locally checkable, but requires that link-local multicast works. > > Both depend upon the router doing something correctly. This interpretation depends on what you mean by "correct". The correct behavior of a router getting a packet with TTL=1 has been clear for a long time. The new proposal to use TTL as a flag to be checked by (end-system) hosts is a radical change to the concept of this field, which was defined for the health of the Internet. Changes to fundamentals of the Internet layer should not be made without significant and broad examination of their potential implications. The existence of an implementation is not a substitute for this analysis. The use of TTL as a flag in multicast is also not a substitute. This entire episode, including the reversal of the rough consensus favoring TTL=1 for link-local traffic in the ZeroConf WG, brings to mind the freshman engineering example in which a column is removed from a room for aesthetic reasons, rendering the entire building weak. Please do not mess with the foundation without compelling reasons! John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 14:54: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 OAA26610 for ; Tue, 2 Sep 2003 14:54:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uGDv-000Ba3-V8 for namedroppers-data@psg.com; Tue, 02 Sep 2003 18:49:51 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 19uGCz-000BU9-Iw for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 18:48:53 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h82BMILR016846 for ; Tue, 2 Sep 2003 07:22:18 -0400 (EDT) Message-ID: <00ef01c37144$7a5ebdd0$b9370681@barnacle> From: "Scott Rose" To: Subject: Fw: DNSSECbis Q-16 suggested text CORRECTION Date: Tue, 2 Sep 2003 07:22:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The last sentence should read: "However, if the DO bit is not set, the name server side MUST strip all DNSSEC related RRsets from the final response." Sorry Scott ----- Original Message ----- From: "Scott Rose" To: Sent: Tuesday, September 02, 2003 7:20 AM Subject: DNSSECbis Q-16 suggested text > Looking back at the suggested text, I realize I agreed with Andreas but > misinterpreted the text based on previous discussions. > > The DO and CD bit should not be able to override each other, as they have > different meanings to the resolver. Suggested text for the last paragraph > of section 4.1: > > "The name server side of a security-aware recursive name server MUST > pass the sense of the CD bit to the resolver side along with the rest > of an initiating query, so that the resolver side will know whether > whether or not it is required to verify the response data it returns > to the name server side. The name server side is not required to pass > the sense of the DO bit to the resolver side depending on local policy. > However, if the DO bit is set, the name server side MUST strip all DNSSEC > related RRsets from the final response." > > > > Comments welcome. > > Scott > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 14:56: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 OAA26772 for ; Tue, 2 Sep 2003 14:56:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uGF2-000Bga-BB for namedroppers-data@psg.com; Tue, 02 Sep 2003 18:51:00 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 19uGCv-000BU9-Kt for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 18:48:49 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h82BKULR016333 for ; Tue, 2 Sep 2003 07:20:33 -0400 (EDT) Message-ID: <00dd01c37144$3b410ea0$b9370681@barnacle> From: "Scott Rose" To: Subject: DNSSECbis Q-16 suggested text Date: Tue, 2 Sep 2003 07:20:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=1.0 required=5.0 tests=DATE_IN_PAST_06_12,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Looking back at the suggested text, I realize I agreed with Andreas but misinterpreted the text based on previous discussions. The DO and CD bit should not be able to override each other, as they have different meanings to the resolver. Suggested text for the last paragraph of section 4.1: "The name server side of a security-aware recursive name server MUST pass the sense of the CD bit to the resolver side along with the rest of an initiating query, so that the resolver side will know whether whether or not it is required to verify the response data it returns to the name server side. The name server side is not required to pass the sense of the DO bit to the resolver side depending on local policy. However, if the DO bit is set, the name server side MUST strip all DNSSEC related RRsets from the final response." Comments welcome. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 15:05: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 PAA27717 for ; Tue, 2 Sep 2003 15:05:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uGNo-000CWB-Ne for namedroppers-data@psg.com; Tue, 02 Sep 2003 19:00:04 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 19uGJM-000C7v-Np for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 18:55:28 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h82ItQLR003206 for ; Tue, 2 Sep 2003 14:55:26 -0400 (EDT) Message-ID: <032901c37183$c6652e00$b9370681@barnacle> From: "Scott Rose" To: Subject: DNSSECbis Q16: newly suggested text Date: Tue, 2 Sep 2003 14:55:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit **note - this post ran into some trouble with the mail server tues morning. sorry if this is a repeat. Looking back at the suggested text, I realize I agreed with Andreas but misinterpreted the text based on previous discussions. The DO and CD bit should not be able to override each other, as they have different meanings to the resolver. Suggested text for the last paragraph of section 4.1: "The name server side of a security-aware recursive name server MUST pass the sense of the CD bit to the resolver side along with the rest of an initiating query, so that the resolver side will know whether whether or not it is required to verify the response data it returns to the name server side. The name server side is not required to pass the sense of the DO bit to the resolver side depending on local policy. However, if the DO bit is not set, the name server side MUST strip all DNSSEC related RRsets from the final response." Comments welcome. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 15:37: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 PAA00595 for ; Tue, 2 Sep 2003 15:37:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uGr5-000Fgc-J2 for namedroppers-data@psg.com; Tue, 02 Sep 2003 19:30:20 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.22) id 19uGqY-000FcB-ON for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 19:29:46 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 806575684B; Tue, 2 Sep 2003 12:29:42 -0700 (PDT) Message-Id: <6.0.0.20.2.20030902140309.035bac98@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Date: Tue, 02 Sep 2003 15:29:41 -0400 To: Samuel Weiler , bmanning@karoshi.com From: Mike StJohns Subject: Re: DNSSECbis Q-2: degradation attack Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_524426044==_" X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_524426044==_ Content-Type: text/plain; charset="us-ascii"; format=flowed OK - Its possible we're all on different pages. I've attached a PDF of a visio diagram which describes my understanding of what the output response should be for a query. Brief explanation of the diagram terms: If you ask a secure question you should get a secure response unless the zone is not secured. Known Secure: In certain circumstances, a query should return a secure response, and the resolver can reason from information it has to come to that conclusion. Basically if there's a known trust anchor and the path information says the leaf answer should be secure an insecure answer should be considered bogus. Valid direct chain means both that the origin of the signature chain is configured as trusted, and all the information up to but not including the leaf data SIG (of RRSIG) verifies. Known Anchor - one of the reasons for not having a valid chain is that you don't recognize the anchor as trusted. If you don't recognize the anchor, the DNSSEC info should be considered extraneous. If you do recognize the anchor, then if the chain is invalid, the information should be considered bogus. Verifies?: Means "does the final signature on the leaf information verify?" Secure and Normal Response are self explanatory. Bogus means that you were expecting a secure result and the information returned was unable to be validated using the information you had. So putting this all together. a) If a signature chain depends on an algorithm that the resolver doesn't implement, then the chain information is considered extraneous and the insecure data can be returned. (This is the expansion of the "if I don't implement DNSSEC, then the DNSSEC info is extraneous" principle.) b) If a signature chain contains multiple algorithms, all implemented by the resolver, then if at each node, there is at least one valid signature and at least one valid DS-KEY link exists at each delegation point, and the final signature on the leaf data is valid, then the chain is valid. c) If, at any given node in the chain, considering only the algorithms the resolver knows, none of the signatures verify, then the data should be considered bogus. Resolver policy gets to specify how the application treats data based on whether it thinks the responses are secure, insecure or bogus. So continuing along that path: In this document should go: "A resolver MUST implement support for both RSA and DSA. This requirement ensures the ability to transition to a secondary algorithm in the event of the primary algorithm becomes cryptographically tractable in the future (i.e. "broken"). For the foreseeable future, it is anticipated that RSA will be used as the primary algorithm for signing data in the DNS. Any tools written to sign DNS data MUST default to RSA as the signature mechanism, but MUST also implement support for DSA signatures. Those tools MAY implement support for other defined algorithms, but MUST default to not using those algorithms unless explicitly requested by the operator." In a document on DNSSEC operational policy (a BCP) should contain: "RSA MUST be used by all zone owners as the primary signature algorithm for DNSSEC zone signing. Zone owners MAY also sign their zones with DSA. The root zone, when signed, shall contain a complete set of both RSA and DSA signature records." Sorry for the long winded description with diagrams... it was the only way I could actually get it straight in my mind. At 10:21 9/2/2003, Samuel Weiler wrote: >[Resending this, since tislabs.com seems to have trouble sending mail to >namedroppers. Sorry for the duplicate, if any.] > > > > > the resolver may also impose certain minimums on things like key > > > > length to determine trust/reject? > > > > > > A client may certainly do this, but only if it would also reject > > > unsigned zones. For example, you might say "I'll only accept DNS data > > > signed by 1024+ bit RSA/SHA-1 keys". Dandy. Then a zone choosing to > > > sign only with DSA is no less visible to that client than if it were > > > unsigned. The danger comes when signing with 512 bit RSA/SHA-1 leaves > > > you inivisible where you weren't before. We should prohibit clients > > > from doing that, to keep from providing disincentives to signing. > > > > say what? just how are you going to enforce this prohibition? > > are you proposing that a client may not create a local policy > > that states "if its not signed, it doesn't exist"? > >What part of "'I'll only accept DNS data signed by 1024+ bit RSA/SHA-1 >keys'. Dandy." didn't you understand? > >Sure, a client may create that policy. The policy I want to prohibit >is: "I won't accept any signed DNS data; I'll take unsigned data only; >if you sign your zone, you lose." This, and its variants, violate the >safety property, and just like the (unintended?) policy of treating >all NXTs as NXDOMAINS, they leave us with an undeployable DNSSEC. > >How do I plan to "enforce" it? By publicly humiliating client authors >who do something different, much as we like to publicly humiliate >clients that don't do negative caching. We can't keep clients from >shooting DNSSEC in the foot, but we can keep from writing a spec that >gives them a hunting license. > >-- 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: --=====================_524426044==_ Content-Type: application/pdf; name="Visio-secure-flow-dnssec.pdf" Content-Disposition: attachment; filename="Visio-secure-flow-dnssec.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjYgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDggDS9IIFsgNjkz IDE3OCBdIA0vTCAyNzc5MiANL0UgMjYwMjkgDS9OIDEgDS9UIDI3NTU1IA0+PiANZW5kb2JqDSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTYgMTMgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDYwNCAwMDAwMCBuDQowMDAw MDAwODcxIDAwMDAwIG4NCjAwMDAwMDEwMjIgMDAwMDAgbg0KMDAwMDAwMTE1NiAwMDAwMCBuDQow MDAwMDAxMzYzIDAwMDAwIG4NCjAwMDAwMDE3OTcgMDAwMDAgbg0KMDAwMDAwMTgzNiAwMDAwMCBu DQowMDAwMDAzNzMwIDAwMDAwIG4NCjAwMDAwMjMyNDQgMDAwMDAgbg0KMDAwMDAyNTkyMSAwMDAw MCBuDQowMDAwMDAwNjkzIDAwMDAwIG4NCjAwMDAwMDA4NTEgMDAwMDAgbg0KdHJhaWxlcg08PA0v U2l6ZSAxOQ0vSW5mbyA0IDAgUiANL1Jvb3QgNyAwIFIgDS9QcmV2IDI3NTQ2IA0vSURbPDYzNjk4 MmE4NWRmNDQyNGJjMjI0NjQ3ODc3YTVlYjE3PjwyYTFmZjRjM2I0ZjZiNWRjNTZlNzhkNWVmYjgx MGI3ZT5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgDTcgMCBvYmoNPDwgDS9UeXBlIC9DYXRh bG9nIA0vUGFnZXMgMyAwIFIgDS9NZXRhZGF0YSA1IDAgUiANL1BhZ2VMYWJlbHMgMiAwIFIgDT4+ IA1lbmRvYmoNMTcgMCBvYmoNPDwgL1MgMzYgL0wgNzkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xl bmd0aCAxOCAwIFIgPj4gDXN0cmVhbQ0KSIliYGDgZmBg2soABEkaDNgAB5QWAGJOKGZgUGfgZ3jA WMPqILGBgfH8M84uPwY/sAQjA0PKXSDNBMQeAAEGABpgCIgNZW5kc3RyZWFtDWVuZG9iag0xOCAw IG9iag02OCANZW5kb2JqDTggMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDMgMCBSIA0v UmVzb3VyY2VzIDkgMCBSIA0vQ29udGVudHMgMTMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag05IDAg b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAxMSAwIFIgPj4g DS9FeHRHU3RhdGUgPDwgL0dTMSAxNiAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMTIgMCBS ID4+IA0+PiANZW5kb2JqDTEwIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2Nl bnQgOTA1IA0vQ2FwSGVpZ2h0IDcxOCANL0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDMyIA0vRm9udEJC b3ggWyAtNjY1IC0zMjUgMjAyOCAxMDA2IF0gDS9Gb250TmFtZSAvQU1DUExMK0FyaWFsIA0vSXRh bGljQW5nbGUgMCANL1N0ZW1WIDAgDS9Gb250RmlsZTIgMTQgMCBSIA0+PiANZW5kb2JqDTExIDAg b2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0v TGFzdENoYXIgMTIxIA0vV2lkdGhzIFsgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiANMCA2NjcgNjY3IDcyMiA3MjIgMCAw IDAgMCAwIDAgNjY3IDAgODMzIDcyMiAwIDY2NyA3NzggNzIyIDY2NyA2MTEgDTAgNjY3IDAgMCA2 NjcgMCAwIDAgMCAwIDAgMCA1NTYgMCA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMCANNTAw IDIyMiA4MzMgNTU2IDU1NiA1NTYgMCAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiAwIDUwMCBdIA0v RW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9BTUNQTEwrQXJpYWwgDS9Gb250 RGVzY3JpcHRvciAxMCAwIFIgDT4+IA1lbmRvYmoNMTIgMCBvYmoNWyANL0lDQ0Jhc2VkIDE1IDAg UiANXQ1lbmRvYmoNMTMgMCBvYmoNPDwgL0xlbmd0aCAxODE5IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCkiJ3FdNb+M2EL3rV/AoFTBDDimKOi262aLAFg3a2ihQLPZgaJXdbOW4sJMu +u875JCUKCuO0eYUGLA9GH694cy8x6vro2HdkUn/OXb3xdWPa8k+HwvT8lqzGn+sZQ2wFVqHvrgt rtyU6zUTXAidfa+vbwrJ3uNCX5nkwL4xKdjP7MNHwT6h447FRWUdFqU118XbTXG12QDO3NwWDW8t E/jxf6zkrcGBNQfLNrtCeJc7qdtUarbpipX/yzbfig/lz9s/e7buu8dDpbgp++rj5n0heW1NzVZ4 KqHY5h3NBTdX0LRfH/tDtdJclv/4GT9sijEmdGyjpTv2rpCi9raxzh4KiY7RPyS/1GRn04fi9rsX XvDo4pdHrQXnMlqfRM3HShsH/UO57quVBK7L7tGBtyXGoOVtiBoONaaFWdhETXN/64/74W+Kmi3f pKhlZ98VGhQXZjzsujhNHHcuDcAlDqu58bNyiMGrLJdmNP1gH9DxrqRtuQb0WbctggONACQ3IX1P QiVbwTVupVquFkIlfIaVN/tq89Xjy+4i3V3dGK7MGXxStBwwkZuGK5jMowJzd4xQIfqH2fgZyLbh Bq8X0TmMNW/seYytdT4j1BziWAflH/0xQpwlvq7xDBOs2mpnpzwN/pSnWgmys+mTxH+pBZ9MfF23 Lib/I/Fb3eh54rc+Tpj3f+3vj/2bk2jJts7QgZIZOjBNdvzoj+jy+XTlL7zkQsRAusRfipgH7QNW /nS//3bvAGNolLJqFhqox7DWXJVdhdVQPlaA34f+zWlHjfVNHW9KL9FD9ZVzRH5wrTSnutVLV+1O 1xGGhnr8u321wgZSspv9YefuW5fbgVHnx06y1Pm1xu6F8cMf6mbWTmxsRCG+ZNeCoq/bqUWx74po G+0KPc5shE/YsC5ZXdqXbNxHuVYXB1OI4kLQZttEmw4RJtL5cjSdS7DXDXAh3bVqkDoW0z3li6Z8 +eWw7/rjkd1Uq4ZDidkj8Oew2w5BVChxUglSJlGROkVoFNrkzBFs7Tr8OebQxjOBbiwxR5oXQ2c8 cwT/MBvv20jeJhIpp7awDozqlpIj/SZ/8NaoqEb6pcEzZgJ3EqM4yoaRe2v7BC/haKfudI3qDk6b TwMz7s3oYee5PofxBPdi8o3g5j0xeCO46eC5tsD9NeGrL9MWGpy20DVe+eXaIujjkR5RodgLtIVu fSIs0Cppi+AfZuNnIIljVW0zila2zig6+BNFKySeCUUnd+L8l1pwoaRxJWGZMmKRwZRMTwQIRPD7 drirXEl/Yu/oz6HvHkJRQ413u8T8VNTXX7Z39/l9BbYdobm4XnBfyokVWAoJ3VfwD7Pxi1pQQ+Nz 8lItqKWdp+QzWlCBvyfAzunBqtr3FLCGDq1aNfEPya8g2Nl8D+Kll1zIDYVvBMUAq7mx7on4H/UN kL75/p6UAuqb8kvlKcGZhwqVyMkTKGU8gM1SONpGMMBGi61SGZ/sQb0Fq0M1p1xfTF6dpoW/tGIX A5N2iIFyCXMuEd3KmFiAcfaJeHIBtXcE/zAbP++OeA2YpEjaKJ0vaP4SCxZTVmHzby/pjrm2TVoY mvY8fwIqBHdoK4g/0zwg/gQsHQeS/MNs/JzfkDlduWGhoXMst6cpDrSvN2Ec2OcLbl4T0GjX3VKO P4kSx7ntMJpIY7tI+Wle9CN3yYlJw2cgFfYjcGNrf5XPg1SIDtxm5uQqp9Cyck5CJh0xChtUaEqf FUREZ8o4ch0FUdKsQQCRf5iNn2HVwlegC5e0l3C6ll53AdaahktIPW1lvThtAnoJdjSxxysPgszQ QYgPgkEv2y52Fyl8eoZpUviKDWsGqws7BnMoGieVg0W0GlYhI+5AFm3up9Chpsf3b4dXhWeBO1CY 4wAUX/P35fRRualWjgAkb8t+S+/LB7Y9snXfPZJ56E/flWFvIfLYkT0Gj+wQoSbEJFhSZfFrsG+M 8WugmcQvWDF+wQzxCxYFKawSjLhFMGl/mkQny2BMc+KVAVtIDpRd2JYb7BRL2QGjYFw/bA8PuWAc w0O2wa3PUlgQgKYxRGFxnrHU8YJgDP5hNn5R4KcuHNZKnB/Cnrpy9EfRlU2fCPyXWnBJ4GOLXmYX 1PL94e72rjJYaP1xlGDZI2I803OCKAQuCaITLBToJIDy8YvKXCF/wkUsSsrccelSSp1K8yyO6axS XoZRyhxj6qoBY/APs/GLGAHEhUqBMAIOaU/0+OKzA3B3PDigjrdeD9V6YqOQMZRdZCfVIzMr9Pho G+Mv0Ux1YFy3CaQR900qEaNioinberJQtOI2yaZD0MRwvgyN75ivG+BCNYPQTjktlfOon5BYD9VK e1b1fPp2//nxOHthjS0HOwS+5J4VydIiIQcNvCtyWEP0Rkk8HTx/6mjLIenjC546uuXSPAm5gVwy /jsAuKkBYgplbmRzdHJlYW0NZW5kb2JqDTE0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMTk0MjMgL0xlbmd0aDEgMzQ5MzYgPj4gDXN0cmVhbQ0KSIlcVAl4VNUV/s+9782E bAQMZAHhTR6JkkUgFAmQhkAyAQuBLKATCpIhCUmQkAmbCYZNTEKHReSDVCIiCEiQii800EChRUVr C1mKVsFaNrGAn4G034dYkXk9MyCFvvO9984599yz/PfcAwIQhBWQyJqcOyhxlstRAdR1sXZSQZnT 1bPzsTVATV+AthYsXqjVu04v5rUvAcvg2a7islNVeQ2ANZDlecVzq2Z3LAi9DiSkAmlJJUXOwtag 69uA1SzjyRJW9Czr8TYHrGZ5QEnZwsq/vLmA14K2A6Hb55YXOGl8WwjgqmR5V5mz0tXtMm3mfDrY XpvnLCta0tFvDFB7huXvXeULFnLe/NS2eNdd84tcOZ4T14Ao9ulvqkcQwW+kugcRSgzCAfMKv1e9 f0+pedW77v2Lb3h3y70XaMQ7VIp38Ee8T128610cRjM+RhjSsRXV2IQ6WDCNNb9CDpPK+k0UYTZj EHZwPjvQyrbPYBmOoDeFm9ewHDXyE95Vw0hHYQyyUI51NNFchOk4r6zCcEzEPLhohekw15sbzV3Y jcPyY/MOAhCJAqZW87p6xvwSCbxjM7bgPG3sdhCpHGUFW76O+WiQMxQyi80fOAMbnuccFGSilY6L OPZehCsUTtUyjb3sNA3zBFv1xQyUoAFHaBiNEzZ1uplptqI3x6hkr1twAIeYWnAMX1Cg2mXuMrsQ gXg8xfU0o42OS8+dlZ7RjJjKKA3ECF4pxx/wJ3SQTu+JcjVQTVRT1SXmpwjFEEzlbPfwzn/SLbGM abn8SMkwxyKYcXnFizY+xEWKpEE0mZ4WA0W52Cbnw48jDmEqRCnj/Sp7P0dxdEgEina5U9mn3LY8 6rlgBvOJxOA1vI73KIgr1WgBvUif0VciTcwUr4lLcpOyVzltdXLVz6IM67APt6gnJVE2/ZJKqJrq 6BXaQq3UQVfFGDFFPCduyBJZIY8pY5lylQXKKrVWXWO56nF4Tnj+6rllJpq1yOZ+WMnZb8Y2ruww 2nGW6TwukUoBFMykkY2m0gtMy2gdvUmNtJeaOUoHXaJr9G+6SbcFmCyij7CJKCZdzBfPi01iq2hn 6hDfiv/IMBkl4+QwmSzzZDlnVSc3MB2UF5VIpV0xGedEtV59Q21U96nvq12WQOuLfvA79ePOO7F3 znngWe2p9xzwNJsX0YvPMJJR6I9kzt7JNIfPu5477l18QoGMXSTFUgpNZGRm0hyqoEpG8iVqoN2+ 3PfTUUbpc7rBOQeJvr6cnxDDxFgxmelZUSQqxAaxUTSLz8QP0ioDZHfZS8bKcXKGLJILZZWsl4Y8 Jf8hL8nv5I9MpuKv9FeilBglThmnzFQWKduUK8oVdbp6Uv3a4m8ps9RaWiz/sj5pTbFmWbOtM6wv Ww9ZP/XL5+78AAfxOzzw0AW5UtrlQawXQ5UI0SbauJ9nolBmCu5U0UirxVJqFgPUSssoMYomoUuJ Yaw/Em+I78QomUkTKBdzxJC73iyhCk8rJCsfoFM5yrW1sedKSyAtEzcsgThAECM45odysBInT+IL eZ6syg78XfGnMOoUe2QWd8ExJUV1wCa3Yr+soKU4KOw8nW77reU+nkRv81yYQon0vTQhxSTuouHy K6zCc+IMOvker8avqVApxnoMpWpcwVt8Kwaq8yyxll70Z1GquMUj1Ayh7OXqRtAAkmooXqIZssFy Q5zFIrQr/jgnf8PZt4v9MlPpUnOohG/AUtSiwlyJKtWhnKZiSHoa0coFnm7VMlGx8X85T5XpPNMO 8e0+wnNgjMxkTTh3zkTui6k8IRqYXuU5oXAHlfIdf4anWBuaLVNEC4rVYOKpAygnPTmYZr6FLWYx 5pkbkcDzoM6sZo+N+Bovo5FqPC/AhX58c87RRDVDtKsZZoJwi7MiV9Q/fL6MdjSF4xum/chAivp7 uJXPkYvR5lrzb9zdj/OE3YJZ+AUuc5XXOcJ4eRxDPZNEk5khXVzveWSbe8z+5I8Scy4m4yh2W1U4 rXGpaVOnjEkdnfLz5FEjRyQNH/azoYlDBg96IiE+Lnbg44/FRA/Qo2xa/36P9u0TGREe1rtX6CM9 e4R0Dw4KDPDv5me1qIoUhHi7npGvGTH5hhKjjx+f4JV1JyucDyjyDY1VGQ/bGFq+z0x72DKVLWf/ n2XqXcvU+5YUoiUjOSFes+ua0Zquay00LdvB/Lp0PU8zOn18po/f4OODmLfZeINmDy9J1wzK1+xG xuIStz0/nd01Bfin6WlF/gnxaPIPYDaAOSNMdzVRWAr5GBFmH9kk4BfESRmRerrdiNDTvRkYMtru LDSysh329D42W15CvEFpBfosA/pYo3uczwRpvjCGJc2w+sJopd5qsEZrij/uXtsSgln5cYGFeqFz usOQzjxvjB5xHDfdCFtyOfx/Ijvvmeaoe3C1j3Tbw0s1r+h212nG9mzHg6s27zcvj33wXhGdke/O 4NBrGcQJuRpHEzV5DoNqOKTmrcRb1d36inS7V5M/RzO66WP1EvecfD6aSLeBnCrbgcjI1MPmBUTa NfcUh24zRvfR85zpfZtC4c6p+m1Eqhbx8EpCfFNIj7vANgV3v8cEBj3IFN1f83E+cy83Iec+suTN SH+KG8LQCjTOxKFzTUneT1ES3AVJbMZPHvEuo5BPpNTolpbvDhnp1Xv3G2p0iK65b4I7QO/89mGN 857GEh1yE17W2yf3W43Xf+KNuDgjNtbbItY0PlPOMcUnD0uIX9widN0VovGP4UMWY+vMGzmI4bfZ vAe8piUVs1gwVmQ77soa/st91QdHVV3x89677+2CUALpUiGDJAQUhEAgw1cKZSEQgQgakk02Ky3h oxaJVCrV0g7KMuEjLEnHWmEiIE1SKGlChw3GmjC2BmY0xY4wdRpsK/3wIzPVdFp10BlB8vo79923 bB6Modr+08z+8rvn3K9zzz333PvWpJ2k4JSJZXG9nGs63JpAiGuibk2ie3kmIrmV+CkbiPtvT/yG pAxPXbQ+N64N/4zqbzr1BUWZBYWRcPqiWLnybUFxH8mpn5WoU6V4al7YSNNVSU8zZC2CcmWiMQvh QXExDj9LBvW6Np8fUSk1Wnp+PKV8sfO/bGBGxk12arPf516SrnVTZsZzJ/aVv9pH7mPeoJgBg3EN FhRHYrGBfeoQas6ESxQh4qk4nJGeF6cQTuY4/NrsjlmMsrR4EC7L4waIP0elxD4N01S5DH8cnVmT 8pHoYrH8zPT8WHlsdZsdXZOZnpIZa9fP6GdimxaVu4HTZp/amxbPry6Dr9ZruTgUOi1oydSqCluC WlVRJNyOj4f0quLwSV3T88oXlLWMRV24PZ0oKLU6a1nJQjoLVKBhkSd1v2yf1o4vh6isFVIh5bVt Gkmd39VptLZNd3Qprk6HTji6oNTxH+eYvOJwcvTII1mWxVcZvpy+1ruc8lLo8onenJRcGaNJf+Z4 S6n4naEQ11+nb4jNFACW+EbR98wSCmu7KaI30VaGMYqC4jg9jLZNkOeDT3FftA8BfwXmACXASKVb BqwGilhG23buizE28TiSN1PEP5oeMkvsq5hvv9lJ9wOHUW4Qb1OjNZs2Qj6Cfi8KopncBn32W01U C/0h1K+F7jA4DLke5ZXol63KA3w1+FYDAxb0EzDOXrXeO4zTNENstt/EWsow5lJgF+a4F5wPFKBN KngBsFvrpCqt025APZgqMf9u1gMLFS/GODtRPw/9xkKuRHkk7LDAQ4AMYLx+nGbrX6YXwFOw/lJn 3UAnrec1J9YE+5VN18OxsSAZmPNXQKY+2+4GD0iyzYtKD5YYORQFVwBpQKH+Km0Ud5MGfz1tdpPB 8BOxn/4CzBXraDlkDXYWma10gGVgmcRm+6o4RHXGJZqFuh9Y+7GOdfA3Xr76xzRF/wdlWeNoG+Jr IcbfDhzGmH+X8bCOijH/ZHCO6JYxtAuoxlz/cv3EvoG8Hfu6AnN96ucYbqIi4C7sSxR4kO3B/FPY 57zvWknvbLR9B21WMqD/igTWzjHJfbg/xhqn4rDhGlMD2tTAr38DCyDANriQcaaAupcxzgjAAkYB k4FuoAGoAHKB54HxmJswryHjFTHDsSnjA7FhdsKHsE3GrLOGw3I/nTNTr8bieTKs41ShkMFj8nnh mIUtLe7YfKY4ZlyW8V3Bca99wOvkmEowzp7oobvYBnkGEVsu87mDzXwe9ushqgIfQBxXcsyyfS6z XzjWpE9wJhTPSVprtjwjYIMoU8V6pcuuLxK8no5gzHJrDXJKHS0W38Xb+0e0RrxPC40JNNnMhg7r Qdu43kMr/HiXYy/vgfy0h2sZvi5tg9mBdTbDn130DHz6HdGljxFdmmk22++apJ01m/XHZfk69kLr cOqYGcl1/6n+80C/YDYjZzbb75ldto31PMlnwtejZQPpLkN/EogCd/onarX+Cq3NF6IUi+gS8JAI Uq4ZpJmiA/sTQJ7HWYA+ZL5JLxo1tEd02X/UohTVu2iXL0Cr8f00hOfSL1Alg8cHb0qKoz4x540l l9149TLnfBVTo8EWzt85hXcUPgY+Qhz9VHPmmMn5Wd4PyNHALide7cuJ+DxLR8F73fj0xGmFJz4H eePSy/JuQX53zyns2OOun/Mj5zjOkZznOM+47b2c1D+mNyGOOQ+/ShF1rscoLIWNb6mzjzyM/S61 bSvfPma12o3GMLvRmobyHwDTPoZ1b0ncqWG7V92nE9y71NHTLe49aubQRpXPjsh88yE9Je/REmnf AOsEbTOvYN+RA6W9deoMwp+wu0KUw+cHqBrrGGHsxnmEHljJPpF7QXQr3wt8Jxr74Ge+i2qo0ngD 7wXum0ND5X0xj0ph+1mpw53KzDqzlBqsHpomQsi1HbSO94rXwfbw3vsfocH+APJEF00VP0ebAA1E uzrpgyAdk3HBfSvw+oEvfGvJh5hdjjY8Xr3sE6Rhyh9HpC9kf7xFOL7YFxjTCtAK+Z7ooZ+YISrF Gar3RaneCuHMBagRYxxFvxDbgn4j5X29j+7D+apCbqpCziEZ/xH7itGM9WxBXgeMKHzUTLeaUfiw Qq59oXBy7G4+P0YT3c4xYu1DHub3xD6KiYm0yKqgGuhqTORJzLsXuh04v9k4u3vQf7TK24S590DP fefxW4bfCHxefEFKtaLyHUDSBn6nYH7jXao3llIV4ni+fx/8sJOycF9oiL3bgKkOpPy4QrUDqUtx WMswUugxqc+h1/Qm4xbELd+h7WI7PSBKaJoxlUaIoZQlfoez+gkdNIbQKvEKHRRtVM2ySKXxBl7p Rivelqw/T/eyXn8Nci1FxBz0r6Jvi1W02WhB7P2eBor7sdfoZ/4QcTIW/T/EuAra2xQxSnC2dqH8 iX2c28k5Wu1ShlhMWbJfEqStLjw26wXw21LsKezlch97YWvCTtfGG9gn18njoh+3EQdpDpF9ERjn cG+hXkPNQJ3+J8ozltH3tUYkmEOUr3UDhxR+QYsltwCFuOOna1uByWI6PQ9sR3kS+NfACUfG2206 vQHsxNinwc/ydwFDX0AzmKE7DNQCv3XrksFz3UifDDON+srPUZShXbKvMrzt4ecZmG+GmAt/AojF JxjWNor4HsX+3QH9bRjTI2OeaeI52tCfPf1BO0/Z0ocOgslrdPcDPPwmcDGJ05nV3fCF7Ps8wP5u A74u/ftPCqgY+pJ2gcaAS8AlxiO0hQE5C3KZ60/tEmKN0Ug/lvrE/jl6xArhHTfXq/fK3n3tT9af paPJcOMgEQ9P0g6GmIf2gFf2n6UdDOsl1L10vSyO9YMI3WkckDaRjDGPbN2DOxPQx8LWkbJPNSMh n8dZBrit7D+Yahjy7AJ6Kz3ASNRPR/4Gkvw6g/2KOWW9uz/uvnj3B/YFxTkggrviHGWDi8DzXU7E t8oXfWK+0In3hMy5pNvT5tqZuHY2zvNdc+Mx/5+As/MK0Am8/L+ei7MM54gUzhMX8Q6Zh3dkF94n 91El0VXkkk+nAD9DHioGvw4dbu/eCcBglIdC9y3wM0RXPkL5Yei7HNi6SKM69a4cAd0vVV+/Gq/I 6X/lN0SXEVGXTzj9rzQBG1D+AHgM5T+DT4Nr0f499NsBPuPUX10F+VHgBcg9kB8Ewig/AQ6AJwGp wDD038/g98h136H/db7x98fNMt4sa2HnaPAp8FbvN8RNs7uf/bD3W8Pd//7YVN8S17PjB3wzvYV3 Xzz52+ezvnFcxn72JkOE/s149cc2cd3x9945thOS+OyGJCSO7xwnZmBKggkxSdz4HOyFYtEECNTO QhICUSGggeRApKmjh1akIlqCWokOJi0MbdW0quLioMxJkJIpGxtpGdXK6ER/0S5/rJOyFISgaDDv 884ODI1Ju/Pn+/m+7/dz77179+75Xeoh9pS5fB/N97J8/6zvHzOsf7/p+1i0S0jBAqM/2Xz/yvfO fP8K/hn4NWOW3p+t6Fc379dwmyVYLhSReSAFCESCrQJagC5gEBgCjMSSiewHXgEmgW/0jCIUJd5c rSRBx3Ua6dvn1Ys70sWO7Xpx5MVYmjduSnPo+bSsPi1bVZMOr2xK89IVabZVelXOOXneqWChUEg+ BBg5AEvZb4mFUiKRs8JiogFMMGYiimAbqXB7hyYFA6ECEyjZRaTUlEATeVZvMIel2DyxYa79g82l M2xuJN/qHQpuYF+R88AkILCvcH7JvsQf+02sGSJsABgCJoGrwDxgZDdxfoHzc/Y5sbDPSBUQALqA IWASmAdM7DNYkX3KVyDdcj8AMPYprMg+wW19AmvBNpSyG+wGuvZRwlfnHdMdT1XGkSozTlFpxrEV epPsT4n7y6Qk++uI7JHOBqvZNaIBDI1dQ+XXiAy0At3AAcAI7zq860QFTgJnAQ3A5w2sCMhsBvgA uE6qAQVoBczswwSaSbKrCXeTFCxkf2S/J0UY1CvsDzp/wC7p/D77nc6XwQ7wDLuUcEgkuAh5gmtE sAiuQj6L/WakwialglY2ieGRYKuAANACdAGDgJFNsvLELsmGSibIDBZXiSXI1zq/Q86ZidInKe51 mGMyN+765+DBDMlDbqa4T51GkRv3iTfhceN+9XV43Lh/cAQeN+59h+Bx497VB48bd3sXPG7cLW3w YJLsp7+uWCr5WvZSOWhhAxilAYzSAEZpgBjYAD/JfQPv208Sy5djxM4onmXLJXWcqhepupmq56ja S9XDVD1CVT9VO6nqoaqdqg6qKlSdoGsxFCpVLjxRrFOKqTpD1feoGqeqm6qVVK2gqkx9SpI5E8+v 1ims00iQv1fg5xq9FvTRiRF1Ylo78dpPwl4FUnpJgUguT4uXODiXjywPpMsr6737g+vZNC6cxmOY Jl8ABjygaUyjaVQyjQossAGgC5gC5oEUYIS6HB0f1K0FtgoIAF3AK8A8YNS7Mw8wsj/TxfN6x6oy nW7hJTaNsxynkzmVMtEuesT1wqCdWhy0xZFyMB8pxEcBsVnN1iTNG72X9+29PJIdzGYn2CApw4M4 meHBxP0yKUl/nHBPSMHF9G3iMGDW0TrippXgtdhf8vIaYjdzriF29i7Ym7Bvw2WWhHuFNE7z+VWj 0n37rPS1Pcng/s0+IX0sJw00If0ZkXdHpWv2Y9LlqqQZkYvuJAWNy7p0zL5Wem9Glx5B4kxCOsxp VPqhvVnaa9cTvelEZxwlxSJtdrdL61FfyN4jKXHUOSoF7J2SP61aw68ZlarRBU/aXY7OLrPrjboc eoVbfUm6W1lhOmWKmlpMtSavaYXJaZJMZaZSU4HZZhbN+eZcc47ZbDaaDWZmJuaCZOqm4sE2mBQY RU78Tw9fOrovMm5h9HWNmhnZQLRnhAiLbGmiEW1qJ4n0yNrdLa4kzdnUrmW5mqhmi5BIW5O21hNJ mlKbNZ8noplavxcdpvREDFGNvZakpC2apCkeOlqq2dZFxwil1qNvlHL+ztE3YjFSXHgoUBywNVrr vht6iunOWM/jo/gJv0w7FdkS1X5VFtO83EmVxSLaW1vkjugYvU2/CYfG6C1OseiY0EhvhzfzuNAY isUiSbpN1xGZ3oIOM+aWrjM7iMx1RDY70rozaV0lroeughN02dmkUtdVZmfrOgPluuF4RTg0XFGh a4pkEtc18SL5PzUzldBUVuqaQpXM6JqZQpVrtEZdYrdD4rDrElpC7LrETkt0ybbHkqqM5NgjyTG9 JYE+1tjTmrybC5q8m9B4/t+jt8njoSMNsZ0d4V5XuNsV7gW6teOHdhdrao8sD++M8YSsCe7unp27 Oe/o1WKu3pC20xWShxs6npLu4OkGV2iYdITbosMdSm8o0aA0hF07QrGR5tYa3xNtHXvUVk3rUypr 5ZXV8LaafU9J+3i6mbfl4235eFvNSrPeFtHneGt02EyaYus60jzCFuVgvnaXOmNNheKBRn3yNjiL D5eOG/iX6SJPTMt1NWl5AE89G3w2yFN4p3gqH2FLJlV8uMFZOk5/mUmJCFtdTcTTfzB+kBSH94TS vzgOhPoP8gFPW0/8fx3IhTVlRyjeT0hEW74logU2tUeHTSZEu/ktafULsUWLwsnUVDq4EsF6HhSE R0Ie8/NYdnZG+N/P/2CG1/G3QGUTI1Rx0H4SjwmaI9LGsBS0teNeO9qj49gu8b+HeAw3GKceGl+o Q+82SfuE3+8C+g9mvMw49Gc4fRUuiS8Mx6ODjxJfp7BeZeHEn4uJNF1gdNZoSrLTyjMkyzArkByT YZaSJWZj1iwTLrJVJJuepitJsUe863/of0G849/40E8C8MUHMKuqnVantRIGqyJ5IAtTD5Qs8k8i G6bQFmknxJCb9RE2QOXkVaXq9ZLjpezlkpdLWU9Jbynbm7sjn7XntuWz2vxQPitdYjYZiLjUaiV5 ywqogyTZecXlLHf6pRzJX14u+51OB+l0fD+ns6ivQuyUrdTa53qxnfdt+5x4d+7OnOgX5/ziQxKA vesPzNnqqmatRXWrqul2HGT7dupeU+Or9TWyNTVuV7nRtLS2drXXsLjAaMpnJmHN6sX0L9RRuKpi Yu3PB+JniseW3Hv/Y0rafxStLWHJK3RPha1vY32D5xc99XuGTp4uvHLj7+90n+t/YUP3vn+9feUK YamHGN1Y1jjGNp++NErzLSLbypKp2xcyzrcX8vKM3LmjxHJzjVuzc7nN0m2VWC2+ZN6d3S2+JpwU L2ddMv6b8mqPjeK4wzszO7uzz9tdn893Z995z4cf2BD8wrBgxCokpkBJkQUGk1xCi0LSpml5pLRp RTF5YCmhKhTV5REh+kjiFNHgYBxjqOpQS1SiEfQFQW0T1AINUS9xg0Uoxuf+Zs8OqP2j7dk7+83s 3uzO7/v9vvlu0Bq2NEbbURteZj2uHbGu69eN66Yi6qIhmkRTFSqKumEySZZ1wEzSZSAYHuOHdB2v EFxZD8MlTAgfK+RjxBX1MHxLSVLKkhKR+vF6XxGYfs3HCOMBpME+o/mO7gqPyqR1mXhWfE8kO0Uk wl7qa8v0Qfk9nezUkc77Vkg+K+OtcoeM5d2h8xeAjJHMhhgc8B/NWtl4zMpmhej85nh2/uWAnmwn vaemZos11HlPNDgj2/E82/M6raEhc2iok+bPwNqSIxpUWhIqrVcMESYPjA8LwvjN2fBpRxs3ZPKZ nUYNKE1SpCBFKiolmeCG3+BVfz40tv+HF9E/9raUlTTQgVst6GTuPrwadR3/+nde5NnfBbl5DZiy wRJVo4LjggicLNQ0aYUotqTb0uvSm5TnFOmL8a/R9com7Vn6rCZVRhQSraxORhKKUuAkq6unThVK EkmIW2kyaQssWiHpFhAt9Y9f9RtCIUCOYUAr8chLjM8uBVxLYZ4H0vLyCr2Ef0NX+X06z4tCfpce n5ZIusgFWXD5deD0Ri+fMAD8XgC3egOS80DiYNhX+bxCpmbuQ7wu8gHKBKXLO0uzIxNykA2KmB9Q JFAzzd4M2wMikJOvF5iiwU7VRyK8OHhr4jRK1c9qaoLSqUhDxdfnywhwF67oPrNp3WPPf3dlx1s7 crvRvG2zFy9peeZA7o/oyYcrFqyes/z7O3KH6UD78UcffqWh8mTHYz1r6kirHVm3dNFXp44elPXZ T7S0Pl3HrdS68b/RzaAZCeF3x9biLyUw6h9/v5fHBNb3vv8IR65Qb6wV1gtPJTqE5xI7hX30EHnZ OE56jdPGOeFy4nrCNp2EnUiQaqnKri5xSxcabeGVhW2xx+kTiW85Lzr7yF5zX0k3+gnutv9gFghh IW6FrbgIlfnuG1UePHPQn17lWSEBicUFSZ0UJ0XFqggtFipchFC8tKjCZYjp/G1YLLkWog3iWJNZ moVAQzsC8c3Oz+bFBxjIbICA1qCNqEgS02VTIHDOFFCeIrmC6xAuDDuRhvomsffUvNwvr2RzF/a/ jhac+hOaNvcXDad2v/bXh568uv3Hf8G47qPRt9BXfnsFrei5dGb6we/9KPfRrhO5ay+c5Gp7ALRn NWR0CGJ3xZ/hlqIFLJ+dtpUMCQxeWUGlPk8eJUgqReUZpUSDkSD1AkmKlyas/zn1PplMvZuTqZf8 99SbwJk7KVdXu+Bpv4kUy+C0KXhtUYpF41EsaSrUgUqkwkg4UhAhUjEpSiHHhCbKSlIootop2A0h ntXw2YYyPEOLIkURpzCMIT/LU/VN+QSthKw8gP55aPW325/a9MA3d739fK4Hebterrt/6Q++/MDh 3K/pQGHis1/InR16NZd77fP1h5vq7r/2ytVPqpOwalAG2gpx1FDOT5KyWR5T5lSqM6UmdaG6kmwn F4i8Wb1ILsKL8qAF4auiO8QX6E/FDxhVRTRTPC9ihf94UJxUI3F5A4l1VPccPnoU+mziLPJzIjgP HnUifPxdf14MnllePo8psdg8SZIVVWEqJaLoUjVMKfSYK0ug7JKqChSLCMsa/FxRCdZgH+7Hc/xQ LUUH6RE6SC9RkS5mfEyrlZELSn1EJrDlb/d1zf1/9eXjSZL1ud1c6idIzo5lNmRB8PkG3NzM/UFz Mz9AWrjYm1zsKai9CEBmVjNrBmmPgrQXg7Rz5X1ndnuPhBcsDzrDR3Wbx2vYLwIgWabdyCzTalQ4 Ui3DapywRO1BbU26LN9WyiBu02KeyI+yYo9CLPsiACOexMOqOR4rC3uiH/Z4mI+VAyz07vJI7Xxi tGFjpkbgm0uD3WCjFIJ/2e46hd9B8the/My4MHZjmA6MTcUXxn52ew+++kEO7K2wRxCkEGSNhS/3 4PxS2PgNX+MhZKZhB9v/h70cwHt96FdxpDv8Mg3pRBEQZopmCkzBqiZxTjSL86BB+Pv4XZoFBFzt nWDr5iRbt/NszYA3fztohPnzBwetc+cGbZDympp8jITifHz9UtkNdqGgJUErBi0NWsY5TnOEA20j Emcem3e8ihq08qSVYbzySzmqoEh3VacxFDRUJwIyNYExhFW+cD5bAIJJTuA2wYFYtfmGEDxIkCZ1 JJhWQHwtIzMgwyCbIJfyi8ncYXzCFxf7WwUcYmFczMTN+nb9VxBKfZG+KESmiuXGNHMVeVDcbHzD 7DSYhinzjCbzc3gJuU/22VLjXlPdg/eSLrmLdZNXZcnBIdOspRhqDDPdMGopA8j01lAr8sEcMaao mmYYpmlxntY4HQ52BnC3YKC6N6jL+lGdr+qK6vr6Vg1pA7BIE2lwBfeDpVJCUGyh9Ray+nHbmy5d Qzsoof24+6g9tz1aEwPnNJJpjoJgBq4JcPzTzuUMeCgIg3XXXxycFS+vzi2BlYJTXa1wxzL9XNDH RyEHz4MtPR84piVHdLhWFdScMX6zx1T5aPADxRj/fV/KM6elPKMf4CzPrJ8VwGPTYXT6RJG0g+eC ykCZ9naQXhQpapqFUnbaRmlk70FT0IO1kdhM9AiiJ3Jtr+dW0YHRj3d9Ztl+cvtWi3hmdKZ4aZQL zkugr6VQKQra0uNofKdVCwobWVSPgDvle3yKIwam1ZUZiBwDa06YImKsyEwkriRBAf09yH/K01Xj BUDzlQQbkh8P0jnjasjVlmlrtPVah0Y1prhI4A8z4GH/RffyVSuIE67jP/c4lRM2ucfVZGr4LgeW l3e4lwpSFkwt4q5WDBialDcyfulNUDXmQiMEEsY3NOCgl/ktHix/sK/FY359HtZ7MmgaNyV9MYD1 echH0wH0tbQnm2E4Cnh/pK8AYCIPEwALObzZ86nIobtKByhsQKBwwN1LpwkeOH07B4RtE7cCWR2j HROOQvwX49UaG8V1hefemTue2ZnZl/cx+/B617s7+8LYxsZm7ShMU+zWgMENNWDsLVTExLwxDhGG 0BIlYEx5lTRESSERoq1CKArFASwnPwiiDTRJI6WhhDS0KuLZ1hFNXCRSvO65s7uAVFXt2nPvmbl3 Z2fO4zvfNwaRUhiVOa5P6LItd+AZ1hmODmuHg5PkAFQL41Ypw2AEuyYYHFaw5nFkVPdRtwneoBfB v1dV/iepyPtdzvv9P2mt52Fukee1PZkcswXcy7NZSjAogzXoQQDIFQ6FbGDfZwY4sbdlxd72L7Ln s9vQxndezcysej47QIbN9q6TK9/Ojo39kkU7ftj5nFOhXpg/vot8QT5hnEwcdesvLtRe07BHrXNi yc+VcmGf31HqCPNJUu5OaQ3kEXe9NpPMdDdrGdIWnq+tJhvZDWQHu4O8yLzC/ow5wl5gLriuMdfc 11Svn6SYJGkgXIbsVfdpFzQu6kpqNa601qw2+xtLG8MztLnCfFubc4F/Qcnc0nnBeWVLyRLncm2j tsu/S/uj+rnmkVTkhEo97kuDqz7Rp/jSnOpQk6SecJh1xdmiuKa6CMODQvISTE8YEgkELCwWIoEi 0asVqzQSxUZ7UgzjptH5wbht4DYYowYsU0OP0qgUT8feYHJzEidDGlSapNJ9kgHikidR4MM5Qpy5 0zJ6X3WMTDVoMSgNUBsA6oyt2nreej6T58nMWoovPWujLuDGMf4hrkxJHlyttdVg4MyMzcpUT6rT Ytw/+9emXz1w6NfvZd958xhqPP8+ajqyauz66yuP9N368aXsFeT7vLuzo+tAJtWf3thxGnV+dgk9 Mfxu9uefncj+eWdFZj9KH0emF7IXs7A5+7tYgwdifhAwCgQL5H0ZuqeH7JIZ2Wv9C0qXCCtLQQgY nc8Yi4wxAsVquEyhnqKGXDCkgmEfGr8yaPfWwHx7sCxWY6PnJbEaa3625GdY/3SwRMutw35rfqbr ejMYUfN0//TgHKnTv9K/Vlxv7rNsMW2zvKQctgxZbppvWKzQrYM2i8Nms9gssmj34ZDXZeLtNqsi E1UUXW6vJ+CmUOihQXO7mVCZUcMq5IFZCGjm/TxNAUO/FsqTp2y2zJCxvCFdM8HImsjmCBspU//f uub/K56GKZ2cVeCTUNgtFFCNOvdcValwoA0vX98pWAO5CrmDIJH6zRNTBHglLfnUwx8KchnKC02C bklbrPU2ez2FPdRjdDwzoKfXk7YBvtrhMOv+tBXIobWsFI77gEn73CSXy+ngi0BnuIvD7EQMEBI2 4ITiSTh0EG8/+8GG3/6+Jd42c3z0TNuqeeWhGX9BB7fsm/XSoWwlGZ59rm//H0qikVnrsj2o6vkd U6SisXVsdV3ft7q3UsXbOX6D+xso3krs1GOL2cVcL/sUx0Vjk9m0/5tsc9HMksbSaZGm2By2vaiz ZF58oNgchr5nMMFIwYgWDK1gxApG2AhFbnPOiBYMrWDA5jt6E7XiihbBETYWrbXUhKdFGysWBOeG 26IrpGXKcvMSR5faJ21QNlg2WddFeqNb2e3SgLLdstO6JfJcdK+yz7LPGcgzzfKQZvdpXlFLII1h El47N6lKY7qguJTyPt+AD/uiLqU8EIuiKHERCiwGsySBcjEQcLEUKUZSgBEZOPJTBlEaWDGS+/Pp 5dGIWZFICFSuTyjiORbzKBopg2s8CfjKvTpNu93Qe0ZcTDmiGW+wBCsKola0CK1BexCPhtAxvbic /iT9aXji6aLGJFBiaPyvb5nNuC1BH02h30t4J8E7Ic1O6QddsheS3E5z2WJU+XdpLXiqFncYCZ1p uUphzwooeMdAw1EDAkesY5nUVTqM0jeCNLZRugAmEAIm0/MgiwELi+sCuHpSXtdGYpo2uaa2thqy EhASkJB3Otwuzm0kKcVLrfOUsvDcptVvzGntbMiu+M7SJ3/w5U8O3d1Khi1HDx87mJ6CLs3fvGHr vw68l/3qZXTRumrnvMd6pzU+GXZ/P1V3qGv1u08s/eBZ8492Pdsxu7p6ebzhxNPrPup96hbN1Erg A8OAikXMgK4QHACHM+B3wolDuHcwyCFuCKFTfBDhChaxYJ9ABjRQUicZ8CDkseHLgrS8UgCJewVQ yOYEAL2jcPLlB+0+8wi4E9jV1cx1Cga5dl9VGbKFJoecIRsuzpZw27M+ohw9+vVX9GlFwPAmeFoT ejSnyHQ7QYxgsBUTQ0SBIEwqLn9ovfyhrboa7jcVglBV6dMjFQQlmTgbNVXIlfIieUAYEPfIp+Xb shSUW2XMYUnAuSw/JSIZRA7ccupU2tDS8G2TKAYF4hAEwsDrY+LAmIjwU7eCJlANXQLqwgLNRSme bhXQZmGPAOcI6QrW4+mFGO3Gr2GM6RVbkLQSXAlKYQ85TW4TAmph26C06PWcWui5CplCD9UKGQYg 6fWMqFMfoZoAAJFqAphQThE4gPUfZyygwP5xXLQjOoFogpY/xfhQcRCHbbWGOGDGT09pb6eICnw/ 0x5C1TmuX43wN8bOfYw2TSwtK0c7fjN2Bhjjxc1r1q/nEl83UZ/zeZ/LaNlJQaxnuQZxaPzGoN1d A698QzeDwXlgYOkg0k6nhujSp3oDGFwcBrvGJYSkqcLMdaNuvlv6E88RjmV5oUjkeZFnRZMMmSQG TZLDZJJ4lhdZCl4uepUNYgTuRrws8QiSE0lD2KOLJpPIYoi6eQiruiiLj+umzSaQpeiErkiSHGTY x2fj3YbTT+giQoyj0Mt0yUhYOZ+kV/Jpi9WTivlMiAYidSfH+kczUNS56TrNTdBqo4ZqRfZ0/8RU SoBYEBoTw+o3nz3bb4VhxjE3uN0Pbn9LkEWZGx4fBY0wioygUCxARg8TRehRAhwcsP5feWh7ar+P ESHbgwDZcMPY+39HodbGx76H/FfGTuGVbEu26ZlnevegN+8Njr1AGe308Zucn3uUiTN1uFyfICpi 0qN4kwklmUwrtc46X32yOZlRMsllytLkosrtytbEK66feg8rzjglBrSNx2hNG/zhF5434ic9b8fP ej6Kf+y8HBemuVCAYqaNFrTdboC6Ae2TKYdoo1apu1RNTUjWpLn0hGbu2xPmCu2pJcLS1NNyv3xe vqvc/TfVVR8UxXnG99292+U+9utub/fuWFgO7jjwriLcoeCcssaARhRR/EiMV4+oUbFRjqrFJFaM 9asxqZMZO2lMC1brGPMBicQodSqtjn907GCmmpkarc4UWpMWdTqWtkSk7/MeRDrA7XvcO/fuPr/n 9/FE5GlxAVmkkmBcKwso3lXFm4vpYr1EqBJ+IrQLo4K1XegU7guM4ASABBBrwEyAgz2SxC4VnCAj AiuK+FXQGe0sfeqM97Ci6xwFm/xEbqrD9jKdcRQ3So0US0AOBYIg72Pm+o/MdBm0AO74fT9+eLJ4 SKqAFzdB2fCKHBQc17HgWfp5UwibVKFUmFc4pbCz0FoJGRFcA5vuF2fIorSSDKS5BfEplb2VdEcl qtTg3mbBN2ohb35J8ALbx9IGW8XSrEACGWlF1kuSmBNuhiXjEiuQVCbB4WxpxZMZKY0tJ4KHU+jT 5OB4wsITa2RgAKyoP1I1ONIvQ64a25/OGG4lMVtoQeJDaXyh0iGwGGJA08hPeTwMFsSFZ9LEkVSP R1G1gkKG5QQ8eKnYt/AmJrHmXFPn+Tnfn1u+8cY6FKvev3N7Tpd309UD+0/VSzYt/7yuvXBp88qy lzas/2Vhzu6lNe/vqdtVpwi8Pxiyb/rOjOfS3vTrtWbjvMmtD77ZM6MC3SrSpaIFJXNTzy+c8QOs O/Wjd5lB3NF+tGJM6+PCThGJDmRS9VQzxVAWl+7gvLrFgQQPlwXl50gpOSeUkpOglBypwR+uXc54 9KVkGfyBJcyxOZGhz3bP1hrcDVrKndKO0EeYd/jj0nG/M4v32ZvoDUyTdauzmW/jTzg/tZ2xf+p0 qs69zr/QjJC/Stws7hQZEeEmNLdPoeCmUvi2DlEd1B3qAbYqUXRQT+5Rx7ceFLJIB+dn4+cLOiIG 1iWETQHQRiZ0CJoLaCM/bEPP6J5gH4cMroqjOQE2cXbYxBECcqXZ8UtjXoohzrRHsqW2oaCWKD4C xR9seRgZbCHPjttBriyRkv34lyQSbAXPIQ3Qp+S4C+LHt+kDQGYSH+fc/+jG43+3fHXgw5tGp2/n iv2njv+o6U20R/usD+Ug+weI3tV5NHvj9y7+8YvfvQYqVIMxu429QqZy0FLzuJ228CE+zj/NW8uV cn05vcS+WGnQ19FrrGttq5WU3mtcs1533/INuAeU+9rffQM5d4xRQzWMiD+hJvy1/mbjkMFNpoP8 ZHU6Xc7X0tV8jfKMvty+jF/HD7B/U4fRQ0FCHkZwSCKVjWstU3YPpr83hqiQLIYk6aqMJNmUU3Kb bDFM6AnDhC6RXSAIMpE1oKHMQgfJXvIZjjN4K664LEDF8ft7RARkSIVPATryFlfwAtfH3eZGOQtA tJBjuFzScoTJXG6mFQlsRLg4ok+cLzdeP2EySqYXDI48CYfJdEIC1+kHzBLwJ1eSDINtAzt3OlAO bMV0zQAmx2RE0IK5JZ9lKtZe2nl9a9O13amflpweyftg67ZfnXyl9ejeXxz85lg7Yn68aBYtDNfQ riu//+3lG1cuAWa12DlyMc88GLMGUzMo3YNdN2lN2pY61jIbrZttax1ZHtBJ8th4YS6GVY4Or2HX n6zDypDfUuqa7ivVZ7kW+Gfpi1wrfYv1RtdL/ka9lW31DNFDXolSkchrWr2aUptVRtXFQ1KHREuS JVu3c1QPfQo6log0ifUS1F3C7DjsxuzRTB7rMgmWPGABR/PgEFBSHvbbwpPiXTzi/QZ+dzpUGIer OQuE2ECGGpOCnBmcFB9HKm8CUjpBKkMwnWCkErwwUtMmIhVZMNJfJ+EkP0TS/ALI/TjvR/oJuZKJ kXSCBEaACyWJyKJ0yzjFJCpWRskKF1ABLxQoJDLLfLcneu/cV4/vI+XmdSSgR3ftn+xZfXDkBr3I WbHswKvvoWXasW5kIAY5UdHjPz/+r5TX2bMeHd47e/0JrCJuDGEbnjQ1xJu5ig2JvhLfFJ/pa/Yd cb7Lv8dn+fkivsvX67P4oB5FfiOek8UzTlG3Iw8dUdwWhqXs7QpSRt2mRQtZKIZ+C0G+7z1dWhGH qxnRjfghCvlMoInP5DFNxuJUEYlS+UAcKjoWqDBxSKJSoJ5UxsXJ4q/d4Kd4MfwZMepjXt951EMF qCFkp8ZT1zgNSP7CMwFOwYPJTPgawXSolHFtZ283FUlmbRybhT1UsrmyKZkVs1EERSbt2oUimCct MbmgPFYenwZjFZY1UDVPzFMgf9Le7vbv3jZ/ZXZF2eKn+/qYdw6mN8Zrlrt+bq9JvXDw0YuYEU89 XsR8jRmRS01Cm82Uw2FVoo6QMt9RrbC2HF9O1FGoRAsqHVOVeY4aZRn3rGO9Y9j+L48wuSAanlkw Mzw/fCjaEeWmBqYWV0VrHDWB6uIlgSXFG7jVgdXFqWhb9Eb4buBewf2wrKms5yz9cXeR7uaIk0h5 eCQDH2mjeqmreCw7S+8wy6y6Ltqr83WnXfXEQjF7yOu9qiFJM7WU1qZZorjk9NIokTWNyJr2raxp RNY0lXyG0cjIGuxi4X1G1vDikTkPml7bIqIQlW8EL4h94m1xVLQYYpW4EBsdYYzoB2zFfPg2UYdv Eom2iUTbRF8kuiUA8hapmyBvD7Gg/b/CjfQP4WlvsB/40w/XBJlMsClpGk4cJGKEMWvojM5p5TFZ ITHFPUHsXux0lM3esmO/V0Dbur58sOnzN86/fGLtlx2/+fpnJ3a8evLDl1tPPutfFCpbs2Ja1+so cetthA6+3fao6T99re8zkz7vvXDl4uWLMOHsoyjmLnYtBTWeo1Tc+B48zUCwJQEsZClnqpke3kL+ NV3zxbUs2SkrDJ48Rd3KKQ67M2QzY1PjozbUa0Mq8RjVBBhsReRVAQhsED1lKJyNRE+bH/bZyEQC hbQpAIkNDMYB59rsQBf4/AzU1lanAhe1+NR4l/pApZvVDrVLHVUtKq2ECF9NCd/DA/w8VB7unDuU BajWPTb2DJsaYSk5msqCoynLGEOHTZUwkya0pOFwqs4zp34sXIyhhvNlAkLnw8hEnqYjMKVin8I2 BXMRYafAClxIYJ3ZiM/CvKQwMSO7KExqFIlhxwLnUj1ygUxgZD3yvu4f9m77qLZ768b6NxLWnpF/ vpU8/u7IKvrovlca3twx8mvMyf/RXa2xUVxXeO7MncedmV3Pvsder732PuxkCTXY4Nhx4y2BmEIw SUgQhl1CkUmLwZXNO6WkJIGYNhV1aRFp1RZILGiTH7GNhQClqlVBqvBQ3ObRNhUv4dBE1JGlIpcE bPfcs7uwkNaPuWfGM9c75zvfd76zC4CCP4HrU4VzyeVsJn+DhaybHWC9bJBdZKNMFVgp62Db2f7s pUtskumlDDyWSkUJ5sznYZqVFaorakwW6H56gPbSQXqJKoN0lIoCDdMhOKMwkN3AvNHbeaOYN6rz /0pR2WhO2SCYwH5EOYl0nkParN2bvXWQPS5jjSPYIvgvL/l1nQnPjGqfBFnZNTAwQK+9995NH43f /JjXJbyzdAPe2RC/lQwqGQ+hLFaWMqnA8W95TJGYyT+lwkcX/vH0XMBygcRHOos/+LS0WRfdSthT VqMdmxw94q6ogbtGB2B1y3ihDC8kd8AVhVKZKrWsicox5QF9ib5Z2qh/LF1R1EMKiShxNabVKQ+y RsdCRwttUZaoLWwbfU7+BXtH+Qv9SBlWPlP/o3yh+dy6LksSFRVFZUyDE6ZpMVXxqqoiURqTda8s 6zoAQzUC6ZcVVYPKFHR6jBQkmUxxzizX+FlZGF0wDkNqUTc0eiMmiDFCoDE1CguhQgCG5DSscQs7 kYWVjogJbqx0tM0CWnCh0HRcLmt6Nk+puDAtAO81Ai1+LJEG2cLStuAbYGtwBeq65KkJus06Caud cEKgWlqD1iDhsU/BGcUxn5FStkMSme1w1UDNd7YAzo+kliR1NiVUx7RQqAEAu9AfqoPlg/4wLn1l dfgRWsDhgc8TEgl44rigTA72l9UBiIP9fr5c6LfqlMyCZyYufUbm4UQL0Iw/mHSfp0Tz+uG/eb0N eICnxvpt/vC/+oKZ20m6JTMHQtSJvCTVhESICpVI3vhsoo384cLEwR/IJ269TXonNo23iqXfm1jG 6/IlONQiF68clZGIMrcLtQ/W4FozI7NWTcus5TFckzGQ1QK5VN4vX5TpQjiMylKp3CFvlydlCqql i1JGyPhOKGg+6OD7BTII45SYr2o37qhaKE/VMlhnfIeWNR0ZakIwiY1OuM1RoZnezVFO0kQiQ1Ps Rusyl3lmXhqQT3z5aLZXKHHwBhHyp+OCA2jGt9eOZQNg0N+SCwxHTYwO02F2OfBJWP5QHguLAS0c YXYwzCQpUlKs+HjrVIkSKSq09KEY6Y4diImxQKDIGet2ERfFycTGqYR3DQMnEy9/SRdndIC/qEvE +cTE+UThAu7iep+bUrJunaSTph3rDpIgbhe8vV0Qt4Pzz5Muvl0Qu0EQB8wg5xI2oaDJN4bzW7hx kO/nF8TqSIwMCYTPumKpwPknIf9CX+GfiZj4s53mVs4LXk96seVkoHBmKBmNHSNbjpQ15fuHrHiC 87byrozkNaH0ePOcVbOvdsKUCyYRJBZJDHTlQptrSKbXE/eariBxO3y5hpS16ICvbyYOU/yQaUvo F/Mb1MHph9o27St9/vRv3jgSST3c8fOBJa2PvVBP43ubn1m55MRbR8crxF+vfaZ+b8/4PrF/y5bH f/nT8b/nvMVVqBc/2Zb0yJLiEX9rHbOuSP/0jEpjHoVyyW2AgnnOIq9aQ/Yle9KmYc3r9Prd4C2I 4nfoDqfpjNroJ2z0Fga6CgNdhXHbVRhIAqMc7+AZRldhoKuA8y8ygBroKgzuOlAODTQuBoEfo9nm pCviDsMetcUO+4Ddaw/a1JbEap8fuTk24HJlmPe/jYV+j7Fw5RkLmmXiYNJ9r1FpDlhj6c47mAIL r6PZuOsqfI2AGnO/0Thyx234FRfTNV3VJcWKuxRnkBTo7izI97/AbSWUEKLMfUfgLoi7Xtt4fsXB xy194P41c9cfpvF9b83pWDB92/h68eXvtn9jz9nxt2HAEmZPfkorAEWHUEjWHPXZ/E08wEQkWQGn 5HoeFeIf3KpeaDYpc7XFSov2bWW1ptVY9e56/wx7jjXfPd8/x07JKfaklXan/U/a7XI7a7Xa3e3+ Vnsz8TFFdiyTnpKf0peZa6VV8ip9rakHiqnqAsnwRoPo8YNYBip38+jxVRsnWCt7dXQAR1keoGfg AccBA2ygHARPNFZTpRJBtdSwKqnTLoJG8OvfLInUVEHsjAqmk493bqSzifgWI75OxDfDWtQfwY8I J2FLLgeiMK2oppaLa/oOclZnIj2WTudhCRNA4whILcxrnbxtsUXyIrZSXsko7038Fo9VC6AJPjT/ Qr75n93zw1P/IP6t1165ODFyvL/r5f4jO7v6RQ+p2L1p4vL4uWsvkhLiOHvm7J9PnTkNH6hrYjUt AwTdQglZmdxtWg9YX7fmW7Qx3BsWS8P3mZHQdN/00KxQR7g7rNUH6oPzAvOCLdoyMxVIBdu0NeZq qz2wJjgYft973j5f9H7JsHe45FJ4MuyP0ISV8M2g9dajdJ611PrEuBaasAyXU/IXF3OV9xc7DcFZ GB3SiaUn9RX6dp2GEcIwwgm+7WrS4EDqdvb8y5yh+xyxRGfHIdR5rUV4svUNxFMtVrtjgjAILogc IL1klNBS0kgWEonwPodqTFCNCaoxwQohJt+ScDJz7PBWHACIyTcGiQRcSWFpU61NEs3WPUJsjV8f vjPOpTsBRYCR85HTUUjzxil0enKi6vd5RT64VbikPPS6eur3fGfXUNvGi1uX/mSq69CmLW8e3rC+ b2K1/PsfPfHEjydffX3i5iuP1Y/flHrOnTzz4ZnTf+VauhOo+A5g6BLeTT70NQ+xKInQGvoIXUSf pRuowlwa05jD42IOQdKIgckXdFbZrRGtPOwhHrHc9f9npduu4kbSlSdpCpb8Xb0rMy4peXay2d10 8ivj0rCVvr5uGPLDswPjEXakOsF6t8u57STP1TqSznWfgMrzooIk7Xzt4dWNy5Y/PGvWQ8u9JTR+ sHNu/eGKpsYV68Y/4FlonPxU6oMsVEmB5FZa7i2vZ/PY7Oji8lXl32e72Y7oIc+bU/4oOVigyA5U zZ/yUUAOik+LojWd6HZKS7GUnjJSZsrRprWxNr3NaDPbHAPxgYqCini0InrfzOhSvcVojbdWbohs iG6P/kz/lbmnct+UvVU9+u/M1yt6Ko/ET8X9lTnPU54LIrkgmgsqM3NI9h4eRHJBNBeEwMEm3SV1 S7WKmKnTonDcR42poaL/kl3tsVEcZ3xmbl8zt3v7uMvd7Z0f68fZx61jE/uMcQP1IhJBQsHiUcrL LWobEAnhlapAA42RUEyiPJrmjxC1FWkqlRBFBYMNhpQWqWnUtLKwKkITJBRLRSlCcRVFlEql4H7f nO2S1t6dnZ3b2Zn9Hr/f7xthb0f1fgsav9bv8Xv9b/nH/Yu+Zvu1/nb/E1+p9V/2mX8efHMfxMXb hIJXU/i4QyPKHDoGJQV1KKOoKFPpMpVuT7hlSls3VG+tZtVV9+kKbkMWdZCD0+Xcp1ESHaxUtcZr czTX6EfJbLkdp7dhkvrZSot55acxRvwAZ/oBzvJlieKnJR+MsPUn9cYSTB2u6h4r0RKugjNKSB74 GtnBGdC5cRonlXJyqbrmUnlj+4V21tPe387aHUppI8lWlJUMuaBiZQAR7OAGsBP5uImg0Zapbsvt 2QE+ZiMfB7imncAFbVlQ2vWfTBdQ/gOI2ZDwfTuXTiX9BJwOXHYtk2SMQzvDpfeorwlQXfhQz8RO r7utoqEBHuQFgh0OiPlMhaej5vtrGtRUS5PreE7SiWn1VpAnvKjnqXo/NDUpuK1LNORJfYNlGrNE nhabudBCJU9qnWpk9BCrsUqDtU5YCg8cOEDuASjat2tnX7IrXYGa5qbmVtZZntNVgSLIMcn6qQyo gEwNq9BKU89J+7mn9+3pLLz6/uu9C+aWXlm5//w694T51JZ9j6fTbfmDv31t9Zb391/8mM6vemLX Yw/Nb8gW2h85sGzR3mJtuPjpzdkVG1Z0NVRVJ0Vjx4J9G9Yd+cY7mKeNk1+wkvo6yZCPzhIBMdjQ VObo2QXQ6fcpoaYlaIykHR7aAkgiFredelJPLa9g0kndeJg/vFHfoffrP9IVAhz9hn5Cv6CP6ZqO tIBYpVdoQXa+GELM0ivKf6qDztcrWq3C/sgy0NOmREBFv+jn2OMkS+cMbvqfcgiAfgKUmHPt5jyk augiyLsdHc4HWCCFYSGD9mvqdBs6O9wuQLIGN4WmZ07ua/O+vbXl4MFTw8PJsFjz8yPOVx97k33n BapvvfviC3deXdqSk5UkYNm40gSr954lObANhxqRBcl02cbddnipcpikjUYybdJkOg5g7oKZSEe6 kM2gcM1JVZyRejjjoQEyssBBC2QkfGdmlHBGKuEMwrtUwhlZ2mRQCVtoj8kMvZChmWU5WXmiCM59 nmM7cm/kTuQmc0rOLPAZ4uCU8ICP8XGu8Gni4DPEweXKXOCqHN8v+YJLFcyZrBOX+V8qPiG5Jv5f 7gKDoN175lWYQyZRTnESlm0xTTc0QzVA8ipmnliGmycoeEulA0DBMLeuU7qmGZzT4ULAY0LMwX6s Z9+H3/xFrxMfirvbli9/6cGhnw4tfrK38yn24zunXnxg0fKVLx9i3bevgHfARbHr4B1BbwwytnDV miijGkQYGtUEUbmhUqY2YvipbeHVUefqKIQGsh1uNX+mU6Wk3u0WiO+W282hoCkb2DBAulNwpVNX eOKjiNfUlUkRGqlweH2hTNLQwN2V6IfF1jIJoLHNWaTIm0Q36RSLySKxmq5ma401fBPdxLYYW/ge spvuZnuNPXy3GKAD7NnYc/oh43n+M3KYvyLeIW+K8+SMPig+IL8XV8iH4jPyV3Gb3BQt8DkiS9Ki SJpEl+glkeBq5KXLKoRKeVCT387he/DTCYqxyEY3CiIxFG2BY1I4oVXkKFNVMw5ua7sagm3gHA1H Q9LW0yNdmY+6hG4YBS5SnAsSYwyESYpS2IgAyWIYjFFNFzxGqNpmUrPeiKKI93PGR2h+OFL7VaZC L+IBi2h9/MafMZomcv6dvjt9uezEtT6UGqg2euYhXPZA6g6oreHA/vcGWrN4WQsCJAxBe99bXpG+ tXW0I5nOzOlKdlD6q7tbf3OtUJsNPzt7d5vSdOfg5u2rvs8OQXBAdGiEqGcgOjyluhIdZ4kHRpC1 qK5JotKm1OylIdOSFHs9imPPDczKDxeGEo78AagVe24k74Ubo8QENUQ1G6xhmRomlOlSpgjFFXjj TgOdC6wzOupcHnUuhaMYfWhgZJwpWsBkyEMGpmhJmSXYo+569yU35gbSfyOT4xIClemOi7DDa+vK TlV1M8L159GZ2sayopk8qeW576kKUbQ4jycMzyHJWEqvMvLxaqiVCnrJCBNl0ql/xXgw8VBskRbp S40l8YX2IvdRb729wntC/66x2dur/UD/nnFWO2ef9v6h3ebFuFskRas5UbSbvbbUXNLl7TaeNQ7H XjOP0rfYW/FfmsPktHYu8QflsvYxv65ct//m3dT+xaviGu7YlK0j24Rsbdl6U2GbFwlb8Yhr6EZB twsJLBgSesyiZsEambwcdSFKWRB9JVkVWDSV1ETcbRKhu0pZITa4W9197vOucIUCsYjuqDjmv6bu k7K2LbwJB9471/C/wv5w5KNUTFUBsHSVC2HETVM4rgv4vuSUSjzQLI9Em4SdCH7n6kagu54XqnpK VfUE+LlgJVKWlTCgyg2FkYLpRJ3JFMKo7imG7ZoJS27PAxw3DF3H1PFsO5EgInXLsehGa4fVb8Ws EXo0EkGvoNvFM4KJEfb1iPe6dLv7jMtcvIs7Kt2o7oDkikFyHR2mt5K3NklJ5C+92deXBV0DByZZ X/bTmcxypv7h0+lU1rmyHVh6b8J9+QJROZBw3tMTzjw8sY/nkhO1K9cMWYEZsF9PjoOmHSeJybEh MtsOPIhROnfqb+2SE+WVkHHG5NigPpvKgbqVS050LF8nR8cH9aAy6sFojRyFF50GKQjvBrQaO6nP xjeeJHPZucpKMy+fmZeR89zJ8VMiUAKCPwBs0IUb5Nsunfa6SQuckOCDyW74orXTZSJCCWpFqAYl oEg8SWYQVBpizTG65O675471KB3Hzh7pnH/6+N2hd4/N+gsAzE+uuX9k2+4c/tMo23T7Cts3/O+L gDR1d5fH/g5Ik6P/nOKhapGyY/FYlW97WlxLRp4dxCMzsKUyt/22MHc1lx3N+Q5eZAEmISF/yq6i NhLSk1XdxdRq+7iIRVZkMzsozi472Ogm99L/Yb9sYtsowjD8er0xG+/au95dBydeSmqc2KoLSf/i pljYaVoIbdKatoQaQasU0chKkNpIDUoUhKhAolUPiANqJQ6IE5x66I+iFqkSJw6cERcQKJGIKoUT PVBIzDvZTYuQ3IgL4jDf6lm/86PxzDff7jcbS9k5PWfkYn1GX2xX/EpCz9t5Z6itZtecWrJu1516 ciYyHZtJzLqzyQ9iFxOX7EvOBfdy9Av9K+t24pZ7N/qLey+2Yv3uNrxN649im6N7adXcZ75vhs32 B9P3PxDt4DliYjBNw+JzwKzQ7jpOlx11WTANBnqXHuUnTtSxbcPQI2IAeJan9Hh3PMWbV8o3TPqi 4s4rxyp62a7Yykn7jq3Y86G9N81QBvvTUdG05q1Kp9FrHDbCVaNhKAZ7XOsx6RulfD3dOcegp/NW zvJTgMmEcjll/bbYbi2+fna5I2UtrymkxKFQRL7ILNo7jOAWBnecAlwJw7lU0hjRcUZSipF0G0Zj CXpjKfT3OHIbP94s9kczxf4488ONZH8ikxSxVKiJsxCYnxhDTk6cX4riepie+BriGedd99mtpaHH E90t+upbX/9QyDxZWLi+OjmQ7Z0b3bk6/qWVz6YnzCfU/MqVc+/NTSsTf3xzdW/tKAKb/H8QOuET 1gD1M2ZWptjHMs1pPe5jnOfbfKuPuR1IdAPOx0Bbidz1SZ14SIf6aLzvfDZdBDqfAzb/CTxVBboq QPcikPveZ8sZHjc576c/BXpOAduywPYlnx2/AsVPgN23gD2cY2kaqPzkM7hbIpFIJBKJRCKRSCQS iUQikawDBSEIcxEWKtRBItjQwo9uziDb1Z3z9TPo3YYdO3f1FdEPlIIe+/D8C0MvHjg4jEOHqy8d OYqXR185XnsVr2383/+JqfiQdw8Wl2qgE2XO+CAO4RhGUcMY6jiDtzHTaLCXaB1g6wiqQesbmMCU aG0sNLsCvze3DVxM03A6GEXMEYFWqY1AR6hSYmfVVtakkA20gjh3wtdh1h8ItEp9KtAR6tmBkcHq 8HBhYKo+NtlMc+0jGOTah3kVWJqid8YwiSN4E+M4RzXGuma9/m09V9aS561ML7dwJRZ66HWoMe5F mGUuIvQRWzSVSpTWf3FasemkB/ZPd5ZpqHA3ZzQxzLeaEb4ceFW5/7N3obXtpFm6p6W1td6fL+S2 iN/5xPnN96+ujFt7NLEHws9rI/8lwACAeaa+CmVuZHN0cmVhbQ1lbmRvYmoNMTUgMCBvYmoNPDwg L04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0xlbmd0aCAyNTc1IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCkiJnJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkIARJCSNgF QUQFFEVEhKqVMtZtdEZPRZ0urmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v3d+9 953zAKAnpaq11TALAI3WoM9KjMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4HkGm9 IkzKwDDw/4kt1+kNAEAZOAcolLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jnaxAqN VoGzKWedQqMw8WmcV9cZlTgjqTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6PidL gvMCAMh01Ttc+g4blA0G06Uk1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5NpGwGY v/OcOKbaYniRg0WhwcFCfx/RO4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0AjK8E wPLmW5vL+wAw8b4dvvjOffimeSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/JgccoymbHK gJnqJq+uqjbqsVqdTK7EhD8d4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/UxN/ZdhP ND/XuLhjrwGv2AewLvIA8rcLAOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NWrZqLk2Tl YHKjvm5+z/RZAgKgAibgAStgD5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAddIEesB5s AsNgOxgDu8F+cBCMg4/BCfBHcB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflDYigSiodS oSyoACqBVJAWMkIt0AqoB+qHhqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vBvrAYjoFT 4Bx4CayCa+AmuBNeBw/Bo/A++DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV6UYGkVFk P3IMOYtcQSaRR8gLlIhyUQwVouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBFCCNICYsI KkI9oYswSNhJ+IhwhnCNME14SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF8iJFkNJJ MpKB1EXaQtpH+ox0mTRNek6mkR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVBaaT0UcYo xygXKdOUV1Q2VUCNoOZQK6jt1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gcuiddQi+i G+nr6B/Sj9O/oj9hMBhujGhGIcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElhujJjmEuZ TcxB5iHmReYjFoXlxpKwZKxW1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifnA84pzl0u wnXmSrhy7gruGPcMd5pH5Al4Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g/zr/ pYWdRYyF0mKNxX6LyxbPLG0soy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+xfmTD swm3kdt02xy0uWkL23raZtk2235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEOaocB h88c/oqZYzFYFTaEncZmHG0dkxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5tLjs dbnpSnEVu5a7bnY96/rMTeCW77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+9IQ9 gzzLPUc8L3rBXsFeaq+tXpe8Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB71ve1 X5Bfld+Y3y0RR5Qs6hAdE33n7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauCTgb9Izgk WB+8P/hBiEtISch7ITfEPHGGuFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0CwQLlgbMHd CKcIWcSOiMlILLIk8v3IySjHKFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBImWSY5HofE JcZ1x03Ec+Jz44fjv05wSlAl7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06hp2SnDKd8 k+qZqk89lganJadtTLu90HWhduF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc7OLsPdlP c2Jz+nJu5brnGnNP5jHzivJ25z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdvWjxdFFTU VXR9iWBJw5JzS62XVi39pJhZLCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUDigfKCGW/ 8l5ZRFl/2X1VhGqj6kF5VPlg+SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxtpfZ0tX11 Q/UlnZeuSzdZE1azqWZGn6LfWQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqGC42ejWsa 7zUlNP2mGW2WN59scWxpb5laFrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/In/FsU67 zuWdd1cmrtzbZdal77qxKnzV9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW/riubN1E X3DftvXE9dr11zdEbdjVz+5v6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCkAVv+mLiZ JJmQmfyaaJrVm0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4 pammGqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsday S7LCszizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796 v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXN tc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF 3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXr cOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn +3f8B/yY/Sn9uv5L/tz/bf//AgwA94Tz+wplbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqDTw8IA0v VHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIyIC9EZWZhdWx0IA0+PiAN ZW5kb2JqDTEgMCBvYmoNPDwgDS9TIC9EIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9OdW1zIFsg MCAxIDAgUiBdIA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyA4 IDAgUiBdIA0vQ291bnQgMSANPj4gDWVuZG9iag00IDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChE OjIwMDMwOTAyMTQzMDQ4LTA0JzAwJykNL01vZERhdGUgKEQ6MjAwMzA5MDIxNDMwNDgtMDQnMDAn KQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDUuMC41IFwoV2luZG93c1wpKQ0vQXV0aG9y IChNaWtlIFN0Sm9obnMpDS9DcmVhdG9yIChQU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjIpDS9UaXRs ZSAoVmlzaW8tc2VjdXJlLWZsb3ctZG5zc2VjLnZzZCkNPj4gDWVuZG9iag01IDAgb2JqDTw8IC9U eXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9MZW5ndGggMTA4NSA+PiANc3RyZWFtDQo8P3hw YWNrZXQgYmVnaW49JycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCcgYnl0ZXM9JzEwODQn Pz48cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5 bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPjxyZGY6RGVz Y3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nIHht bG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgcGRmOkNyZWF0aW9uRGF0ZT0n MjAwMy0wOS0wMlQxODozMDo0OFonIHBkZjpNb2REYXRlPScyMDAzLTA5LTAyVDE4OjMwOjQ4Wicg cGRmOlByb2R1Y2VyPSdBY3JvYmF0IERpc3RpbGxlciA1LjAuNSAoV2luZG93cyknIHBkZjpBdXRo b3I9J01pa2UgU3RKb2hucycgcGRmOkNyZWF0b3I9J1BTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMicg cGRmOlRpdGxlPSdWaXNpby1zZWN1cmUtZmxvdy1kbnNzZWMudnNkJy8+CjxyZGY6RGVzY3JpcHRp b24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhtbG5zOnhh cD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFwOkNyZWF0ZURhdGU9JzIwMDMtMDkt MDJUMTg6MzA6NDhaJyB4YXA6TW9kaWZ5RGF0ZT0nMjAwMy0wOS0wMlQxODozMDo0OFonIHhhcDpB dXRob3I9J01pa2UgU3RKb2hucycgeGFwOk1ldGFkYXRhRGF0ZT0nMjAwMy0wOS0wMlQxODozMDo0 OFonPjx4YXA6VGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5WaXNp by1zZWN1cmUtZmxvdy1kbnNzZWMudnNkPC9yZGY6bGk+PC9yZGY6QWx0PjwveGFwOlRpdGxlPjwv cmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8v cHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9l bGVtZW50cy8xLjEvJyBkYzpjcmVhdG9yPSdNaWtlIFN0Sm9obnMnIGRjOnRpdGxlPSdWaXNpby1z ZWN1cmUtZmxvdy1kbnNzZWMudnNkJy8+CjwvcmRmOlJERj48P3hwYWNrZXQgZW5kPSdyJz8+CmVu ZHN0cmVhbQ1lbmRvYmoNeHJlZg0wIDYgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAyNTk5OSAw MDAwMCBuDQowMDAwMDI2MDI5IDAwMDAwIG4NCjAwMDAwMjYwNzEgMDAwMDAgbg0KMDAwMDAyNjEz NSAwMDAwMCBuDQowMDAwMDI2Mzc4IDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgNg0vSURbPDYz Njk4MmE4NWRmNDQyNGJjMjI0NjQ3ODc3YTVlYjE3PjwyYTFmZjRjM2I0ZjZiNWRjNTZlNzhkNWVm YjgxMGI3ZT5dDT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN --=====================_524426044==_-- -- to unsubscribe send a message to namedroppers-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 Sep 2 15:57: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 PAA02676 for ; Tue, 2 Sep 2003 15:57:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uH6a-000GxH-Kp for namedroppers-data@psg.com; Tue, 02 Sep 2003 19:46:20 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.22) id 19uH5w-000GuE-OL for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 19:45:40 +0000 Received: from depa.dmes.org (user-uinj286.dialup.mindspring.com [165.121.137.6]) by toccata.fugue.com (Postfix) with ESMTP id 12EA51B2508 for ; Tue, 2 Sep 2003 14:45:31 -0500 (CDT) From: Ted Lemon To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? Date: Tue, 2 Sep 2003 15:45:41 -0400 User-Agent: KMail/1.5 References: <200308311150.02665.mellon@nominum.com> <4.3.2.7.2.20030902061001.05dc81e8@wells.cisco.com> In-Reply-To: <4.3.2.7.2.20030902061001.05dc81e8@wells.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309021545.41846.mellon@nominum.com> X-Spam-Status: No, hits=-0.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday 02 September 2003 06:25, John Schnizlein wrote: > Changes to fundamentals of the Internet layer should not be made > without significant and broad examination of their potential implications. > The existence of an implementation is not a substitute for this analysis. > The use of TTL as a flag in multicast is also not a substitute. Well, yes, John, but we *did* analyze this, at length. The only reason that anybody came up with for not doing it the way Rendezvous does it was that it isn't how we normally use the TTL. I didn't hear a single substantive objection. You are simply re-raising this point. It is a good point, but not a compelling one. For example, to date nobody has pointed out any reason why this is similar to removing a supporting beam from a large structure for aesthetic reasons. I would say, based on the discussion to date, that it is not similar. -- to unsubscribe send a message to namedroppers-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 Sep 2 16:52: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 QAA06099 for ; Tue, 2 Sep 2003 16:52:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uI0A-000LUr-By for namedroppers-data@psg.com; Tue, 02 Sep 2003 20:43:46 +0000 Received: from [141.225.37.221] (helo=thales.memphis.edu) by psg.com with smtp (Exim 4.22) id 19uHze-000LS4-K1 for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 20:43:14 +0000 Received: (qmail 952 invoked by uid 500); 2 Sep 2003 20:43:34 -0000 From: mw-list-namedroppers@csi.hu Date: Tue, 2 Sep 2003 15:43:34 -0500 To: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 Message-ID: <20030902204334.GA31955@csi.hu> References: <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> <20030828042006.26191.qmail@cr.yp.to> <20030828094003.GP910@apb.cequrux.com> <20030830055434.GA18190@csi.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-7.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Aug 30, 2003 at 10:21:20AM -0400, Edward Lewis wrote: > This discussion is crossing the line of being on-topic for wild card, > but the question raised is a reasonable one. And the discussion does > start in scope for the document, and when it strays, it strays into > an area that does need to be discussed... > > At 0:54 -0500 8/30/03, mw-list-namedroppers@csi.hu wrote: > >On Thu, Aug 28, 2003 at 11:40:03AM +0200, Alan Barrett wrote: > >> RFC 2308 appears to be silent on this issue. A reasonable > >> interpretation of RFC 1034 would certainly permit the inference that > >> NXDOMAIN also applies to subdomains. > > > >Is there a place in RFC 1034 you have in mind where the interpretation of > >name error would suggest this? > > In 4.3.2, step c. "If a match is impossible" you seek to apply wild > card synthesis. If you treat all names as existing (many with empty > sets), you will *always* get an exact match as in step a. There will > never be a time to apply step c - hence the realization that 1034 > didn't really mean to say 'everything exists' as it does. I certainly never said anything about the "always existence" of names. In fact, what I mean to emphasize is that the existence of _names_ is not be confused with the existence of nodes(=resource sets). Maybe it is easier to parse if I say this: the author of 1034 does not distinguish (well, unfortunately, mixes) the pointer (domain name) and the object (resource set or node) the pointer points to. But I think all rfc1034 really talks about is the (existence or non existence of the) resource set. Indeed, should we care about the existence of the name a.b.c separately from the resource set it points to? If the answer is that we just care about (the existence of) resource sets, then of course you do not get stuck with case a. of algorithm 4.3.2 of rfc1034. In example 1.3 of wcard-clarify, one can just simply say "_telnet._tcp.host1.example does not exist" because the resource set is empty, and the server would return NXDOMAIN. Is it important that the server, after wcard synthesis, "knows about the domain name _telnet._tcp.host1.example" ? I think the following rules do not contradict rfc1034: 1) empty resource set means domain does not exist 2) domain name not found in zonefile (even after wcard synthesis) means empty resource set (and hence, by 1), domain does not exist) The above two rules also imply that if the domain name is found in the zonefile but it points to an empty resource set, then the domain does not exist. Mate -- --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis -- to unsubscribe send a message to namedroppers-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 Sep 2 16:59: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 QAA07130 for ; Tue, 2 Sep 2003 16:59:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uIAt-000MSJ-Al for namedroppers-data@psg.com; Tue, 02 Sep 2003 20:54:51 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.22) id 19uIAN-000MOc-Lx for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 20:54:19 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6F53818C7 for ; Tue, 2 Sep 2003 16:54:05 -0400 (EDT) Date: Tue, 02 Sep 2003 16:54:05 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: LLMNR interoperability with Rendezvous? In-Reply-To: <200309021545.41846.mellon@nominum.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030902205405.6F53818C7@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The one perhaps real difference I see has to do with how many discrete entities would have to be buggy for LLMNR to leak beyond its intended scope. With TTL=255, only the LLMNR speakers would have to be buggy; with TTL=1, the intervening routers would also have to be buggy. How worriesome this is probably depends in large part on how pessimistic one is about unplanned interactions in complex systems. -- to unsubscribe send a message to namedroppers-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 Sep 2 17:26: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 RAA08806 for ; Tue, 2 Sep 2003 17:26:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uIYh-000OUE-AE for namedroppers-data@psg.com; Tue, 02 Sep 2003 21:19:27 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 19uIXY-000OO6-Vw for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 21:18:17 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h82LH1d00802 for ; Tue, 2 Sep 2003 17:17:01 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h82LIt229543 for ; Tue, 2 Sep 2003 17:19:00 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h82LGd0e005029 for ; Tue, 2 Sep 2003 17:16:40 -0400 To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-reply-to: Your message of "Tue, 02 Sep 2003 15:29:41 EDT." <6.0.0.20.2.20030902140309.035bac98@localhost> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Sep 2003 17:16:39 -0400 Message-ID: <5027.1062537399@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-6.5 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Mike, thank you for the diagram. It looks correct to me. It certainly answers the algorithm question for me. A major question is what does the resolver do with all this information? One thing I found weird about your diagram is that you have "Process Normal Response" in the middle of the diagram, while "Treat Secure" is at the bottom. It isn't obvious that the "Treat as Bogus" is also a terminal node. May I suggest that you put them all at the bottom of the diagram? Then, we are back to the problem of expressing three outcomes using only 1 bit when communicating with the application :-) I had hoped to experiment with this question via a set of OPT replies in the bind9 "lwres" interface. {Alas, I have no funding to pursue that at this time} ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1UItIqHRg3pndX9AQHzMgQAlBXea9KI4jLK6KVk8qUWcOZfI9iIOwrQ vYusjg5I1Q+DWzp1lb6eHKcdZ3vwcmMP0r1ThMXie6aiAiKfJndkiHafaWXYDWgf fkwirMGxuzleqAdEkeAcv+HXOYMfQU789QOMTdrJ3wn6j22UBAKEQS0qOF7cl7No ZGg+Fz+QO+I= =ro8g -----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 Tue Sep 2 17:37: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 RAA09642 for ; Tue, 2 Sep 2003 17:37:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uIjX-000PQo-NJ for namedroppers-data@psg.com; Tue, 02 Sep 2003 21:30:39 +0000 Received: from [204.152.186.164] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.22) id 19uIii-000PKu-9c for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 21:29:48 +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 h82LSSh1001158; Tue, 2 Sep 2003 14:28:28 -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 h82LSSRt016172; Tue, 2 Sep 2003 14:28:28 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h82LSPYJ004810; Tue, 2 Sep 2003 14:28:25 -0700 (PDT) Date: Tue, 2 Sep 2003 14:28:25 -0700 (PDT) Message-Id: <200309022128.h82LSPYJ004810@guava.araneus.fi> To: "Scott Rose" Cc: Subject: Re: Fw: DNSSECbis Q-16 suggested text CORRECTION In-Reply-To: <00ef01c37144$7a5ebdd0$b9370681@barnacle> References: <00ef01c37144$7a5ebdd0$b9370681@barnacle> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Scott Rose writes: > The last sentence should read: "However, if the DO bit is not set, the name > server side MUST strip all DNSSEC related RRsets from the final response." That is not what the DO bit does. DO=0 does not cause the server to "strip all DNSSEC related RRsets from the response" - it just causes it to not add DNSSEC related RRs authenticating the response. RFC3225 section 3 says: More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, or NXT RRs to authenticate a response as specified in [RFC2535] unless the DO bit was set on the request. Security records that match an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data for an AXFR or IXFR query, are included whether or not the DO bit was set. Therefore, to correctly reflect the semantics of DO, the last sentence would have to say something like "However, if the DO bit is not set, the name server side MUST strip any DNSSEC RRs that the resolver side may have added to authenticate the response", and perhaps even add "but MUST NOT strip any DNSSEC RRs explicitly requested". -- 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 Sep 2 17:40: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 RAA09877 for ; Tue, 2 Sep 2003 17:40:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uImr-000Pfa-26 for namedroppers-data@psg.com; Tue, 02 Sep 2003 21:34:05 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.22) id 19uIm5-000Pbr-OB for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 21:33:17 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h82LXG7C006102 for ; Tue, 2 Sep 2003 23:33:16 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) id h82LXFKS006100 for namedroppers@ops.ietf.org; Tue, 2 Sep 2003 23:33:15 +0200 Date: Tue, 2 Sep 2003 23:33:15 +0200 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-ID: <20030902213315.GB6000@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <6.0.0.20.2.20030902140309.035bac98@localhost> <5027.1062537399@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5027.1062537399@marajade.sandelman.ottawa.on.ca> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 02 Sep, @23:16, Michael wrote in "Re: DNSSECbis Q-2: degradation ..."] > Mike, thank you for the diagram. It looks correct to me. > It certainly answers the algorithm question for me. > > A major question is what does the resolver do with all this information? > > One thing I found weird about your diagram is that you have "Process Normal > Response" in the middle of the diagram, while "Treat Secure" is at the > bottom. > > It isn't obvious that the "Treat as Bogus" is also a terminal node. May > I suggest that you put them all at the bottom of the diagram? > > Then, we are back to the problem of expressing three outcomes using only > 1 bit when communicating with the application :-) is there any documentation about this API? Should I look at the lwred source code from bind9? Or are we free to invent a new API? 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 Sep 2 17:44: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 RAA10083 for ; Tue, 2 Sep 2003 17:44:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uIrP-00005g-46 for namedroppers-data@psg.com; Tue, 02 Sep 2003 21:38:47 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.22) id 19uIqk-000Q0I-Je for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 21:38:06 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 5FBB45681D; Tue, 2 Sep 2003 14:38:04 -0700 (PDT) Message-Id: <6.0.0.20.2.20030902172923.01f8b268@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta) Date: Tue, 02 Sep 2003 17:38:02 -0400 To: Michael Richardson , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <5027.1062537399@marajade.sandelman.ottawa.on.ca> References: <5027.1062537399@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:16 9/2/2003, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >Mike, thank you for the diagram. It looks correct to me. >It certainly answers the algorithm question for me. > >A major question is what does the resolver do with all this information? That's another RFC.... "An application's view of DNSSEC"...:-) Seriously though, I'd be happy just to get the resolver to the secure, bogus, insecure state and then map that answer with the question against some sort of action/policy table. E.g. someone who's trying to make an HTTPS connection may not care as much about the DNS mapping being secure if they can check the SSL certificate...but a mail forwarder may care a lot... *mumble* >One thing I found weird about your diagram is that you have "Process Normal >Response" in the middle of the diagram, while "Treat Secure" is at the >bottom. I did that to minimize crossed lines... topological sort. Among other things, I'm translating this into an ascii art diagram for inclusion into an RFC and fewer lines crossing is better. >It isn't obvious that the "Treat as Bogus" is also a terminal node. May >I suggest that you put them all at the bottom of the diagram? All of the ovals are terminals.... Rectangles are processes and Diamonds are choices. >Then, we are back to the problem of expressing three outcomes using only >1 bit when communicating with the application :-) Yup..... much of it can be handled by setting the policy at the recursive resolver to translate the three into two according to some reasonable sorting algorithm... such algorithm is left as an exercise for the reader. >I had hoped to experiment with this question via a set of OPT replies in the >bind9 "lwres" interface. {Alas, I have no funding to pursue that at this >time} Yeah...I need to look at what bind and other things do here... >] Out and about in Ottawa. hmmm... >beer. | firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >architect[ >] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device >driver[ >] panic("Just another Debian/notebook using, kernel hacking, security >guy"); [ >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.2 (GNU/Linux) >Comment: Finger me for keys - custom hacks make this fully PGP2 compat > >iQCVAwUBP1UItIqHRg3pndX9AQHzMgQAlBXea9KI4jLK6KVk8qUWcOZfI9iIOwrQ >vYusjg5I1Q+DWzp1lb6eHKcdZ3vwcmMP0r1ThMXie6aiAiKfJndkiHafaWXYDWgf >fkwirMGxuzleqAdEkeAcv+HXOYMfQU789QOMTdrJ3wn6j22UBAKEQS0qOF7cl7No >ZGg+Fz+QO+I= >=ro8g >-----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: -- to unsubscribe send a message to namedroppers-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 Sep 2 18:08: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 SAA12029 for ; Tue, 2 Sep 2003 18:08:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uJCI-0002Cg-3p for namedroppers-data@psg.com; Tue, 02 Sep 2003 22:00:22 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 19uJBl-00029x-L1 for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 21:59:49 +0000 From: Masataka Ohta Message-Id: <200309022150.GAA02446@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA02446; Wed, 3 Sep 2003 06:50:26 +0900 Subject: Re: LLMNR interoperability with Rendezvous? To: sra+namedroppers@hactrn.net (Rob Austein) Date: Wed, 3 Sep 3 6:50:25 JST Cc: namedroppers@ops.ietf.org In-Reply-To: <20030902205405.6F53818C7@thrintun.hactrn.net>; from "Rob Austein" at Sep 3, 103 6:02 am X-Mailer: ELM [version 2.3 PL11] X-Spam-Status: No, hits=-0.3 required=5.0 tests=BAYES_30,INVALID_DATE,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2, QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The one perhaps real difference I see has to do with how many discrete > entities would have to be buggy for LLMNR to leak beyond its intended > scope. With TTL=255, only the LLMNR speakers would have to be buggy; > with TTL=1, the intervening routers would also have to be buggy. > > How worriesome this is probably depends in large part on how > pessimistic one is about unplanned interactions in complex systems. A proper assumption should be that multicast does not work beyond a subnet. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 18:19: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 SAA13382 for ; Tue, 2 Sep 2003 18:19:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uJQF-0003O1-Ch for namedroppers-data@psg.com; Tue, 02 Sep 2003 22:14:47 +0000 Received: from [217.13.230.178] (helo=yxa.extundo.com) by psg.com with esmtp (Exim 4.22) id 19uJPi-0003KG-Qh for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 22:14:15 +0000 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h82MECdk011389 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Wed, 3 Sep 2003 00:14:13 +0200 To: namedroppers@ops.ietf.org Subject: Re: Comment on draft-ietf-dnsext-wcard-clarify-01.txt References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030902:namedroppers@ops.ietf.org:3968df40c8fb2982 X-Hashcash: 0:030902:namedroppers@ops.ietf.org:3968df40c8fb2982 Date: Wed, 03 Sep 2003 00:14:12 +0200 In-Reply-To: (Simon Josefsson's message of "Tue, 02 Sep 2003 21:30:22 +0200") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Repost from a private thread in order to get input from WG: ,---- | 4 Impact of a Wild Card Domain In a Query Message or in an RDATA field | ... | R4.1 A wild card domain name acting as a QNAME MUST be treated as any | other QNAME, there MUST be no special processing accorded it. `---- This appear to be over-qualified; it isn't valid in the point of view of a client. Specifically: RFC 1034 section 4.3.3 says results from wildcard queries should not be cached. Hence there actually is special processing accorded to wild card labels in a QNAME. The last note of section 2, and the entire appendix A, seems at least partially inconsistent with RFC 1034. Specifically: RFC 1034 says a wildcard RR look like *. where should not contain other * labels. So *.*.example is not a valid wild card according to RFC 1034, contrary to what the draft claims. If something needs to be clarified, how about making a clarification saying that 'MUST NOT' contain other * labels? If the draft intend to redefine RFC 1034 on what may contain, that should IMHO be made more clear, as the abstract now give the impression that the draft doesn't alter any definitions. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Sep 2 18:56: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 SAA15125 for ; Tue, 2 Sep 2003 18:56:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uK03-0006M5-RD for namedroppers-data@psg.com; Tue, 02 Sep 2003 22:51:47 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 19uK00-0006Ln-CH for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 22:51:44 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h82Mo6d01432; Tue, 2 Sep 2003 18:50:11 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h82Mpt204589; Tue, 2 Sep 2003 18:52:00 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h82MnOVq007168; Tue, 2 Sep 2003 18:49:24 -0400 To: Mike StJohns cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-reply-to: Your message of "Tue, 02 Sep 2003 17:38:02 EDT." <6.0.0.20.2.20030902172923.01f8b268@localhost> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Sep 2003 18:49:24 -0400 Message-ID: <7167.1062542964@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-6.5 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Mike" == Mike StJohns writes: Mike> At 17:16 9/2/2003, Michael Richardson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> >> >> Mike, thank you for the diagram. It looks correct to me. >> It certainly answers the algorithm question for me. >> >> A major question is what does the resolver do with all this information? Mike> That's another RFC.... "An application's view of DNSSEC"...:-) Mike> Seriously Mike> though, I'd be happy just to get the resolver to the secure, bogus, Mike> insecure state and then map that answer with the question against Not enough. We have been down this route. When it breaks, we get "SERVFAIL". There aren't very many people who can diagnose the problem, even with resolver logs. Solution? Turn off DNSSEC. For this reason alone, we have to do better than this. Mike> sorting algorithm... such algorithm is left as an exercise for the Mike> reader. I beg to differ. It might seem easy, but it isn't. It is critical that we do this right. Otherwise, DNSSEC gets turned off because we can't distinguish two of the cases. Mike> Yeah...I need to look at what bind and other things do here... Not lots yet. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1Uec4qHRg3pndX9AQEo8QQAiB7oT8iDSnyDDwGGwMPJsqiOlgdU5zHL mTmLxxXKbvfkkPeukaAlcfPCSfYjTTFg6QIX+acoqYmeK1Z/WjbTQv7svDM8aKcz YEp9Fzfi6Rmy5+trSCVvMm2D8GaNRjgjebMASNu5uo8xhzYrNHYzgSrGeZG3An0G hXctFjuop68= =ac5A -----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 Tue Sep 2 18:56: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 SAA15169 for ; Tue, 2 Sep 2003 18:56:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uJxO-00060O-I1 for namedroppers-data@psg.com; Tue, 02 Sep 2003 22:49:02 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 19uJxE-0005zS-J9 for namedroppers@ops.ietf.org; Tue, 02 Sep 2003 22:48:52 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h82MlBd01417; Tue, 2 Sep 2003 18:47:11 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h82Mmt204471; Tue, 2 Sep 2003 18:49:00 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h82Mk5W0007100; Tue, 2 Sep 2003 18:46:05 -0400 To: namedroppers@ops.ietf.org, bind9-workers@isc.org CC: miekg@atoom.net Reply-To: bind9-workers@isc.org Subject: Re: DNSSECbis Q-2: degradation attack In-reply-to: Your message of "Tue, 02 Sep 2003 23:33:15 +0200." <20030902213315.GB6000@atoom.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 02 Sep 2003 18:46:05 -0400 Message-ID: <7099.1062542765@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-6.5 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Miek" == Miek Gieben writes: Miek> [On 02 Sep, @23:16, Michael wrote in "Re: DNSSECbis Q-2: degradation ..."] >> Mike, thank you for the diagram. It looks correct to me. >> It certainly answers the algorithm question for me. >> >> A major question is what does the resolver do with all this information? >> >> One thing I found weird about your diagram is that you have "Process Normal >> Response" in the middle of the diagram, while "Treat Secure" is at the >> bottom. >> >> It isn't obvious that the "Treat as Bogus" is also a terminal node. May >> I suggest that you put them all at the bottom of the diagram? >> >> Then, we are back to the problem of expressing three outcomes using only >> 1 bit when communicating with the application :-) Miek> is there any documentation about this API? Should I look at the Miek> lwred source code from bind9? Or are we free to invent a new API? lwres is built into bind9. It is presently just DNS over 127.0.0.1:953. I would actually prefer to use Unix domain stream sockets - specifically so that I know that it is local, and so that I can get signaled when the server dies, etc. I have just finished (yet another?.. not quite) async interface to liblwres, which I'm about to post. It groks DNSSEC and follows CNAMEs, which I need. Please note reply-to. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1UdoIqHRg3pndX9AQGiRwP9HP68wAMR90hDq6yO81tcM//8LXmnUvhi tHRhVcxyDhLd6wE8Q6bWn/UZPgO4s2K0eHiLsuQJhfoGHtQaBeaOvA/aFdXqlKrk WKDDiNpN/jYI1HVjIXf5uQg+mYv5z/Ww8JyxRp6RfSNnl5LuXnZmeGep2KKcfSng 3rOGkcw88e8= =CtWw -----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 Wed Sep 3 00:10: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 AAA02155 for ; Wed, 3 Sep 2003 00:10:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uOoj-0002W3-K5 for namedroppers-data@psg.com; Wed, 03 Sep 2003 04:00:25 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19uOoC-0002Td-Tm for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 03:59:53 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h833m7Yf094891; Wed, 3 Sep 2003 13:48:09 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309030348.h833m7Yf094891@bsdi.dv.isc.org> To: bmanning@karoshi.com Cc: weiler@tislabs.com (Sam Weiler), ogud@ogud.com (=?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?=), namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSSECbis Q-2: degradation attack In-reply-to: Your message of "Tue, 02 Sep 2003 02:02:28 MST." <200309020902.h8292SU10673@karoshi.com> Date: Wed, 03 Sep 2003 13:48:07 +1000 X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > 1) Signing (or adding a new algorithm) must do no harm -- adding > > RRSIGs should not cause a zone to be less visible than before. > > you, as zone owner, have one choice, to sign or not. > you can't infer client behaviour when they are presented > with this choice. You may recommend specific actions > as desirable for a particular outcome, but thats about > as far as you can go. > > > 2) In the current world (according to the current specs), it's OK to > > sign some RRsets with one algorithm, and some with another. > > yes. > > > 3) A client that comes across an RRset with an RRSIG of only a > > non-understood type must treat the data as unsigned in order to > > reconcile #1 and #2. > > if and only if thats the local resolver policy. > you have at least one unstated presumption here. > > > 4) #3 allows a degradation attack, which is bad. > > sort of. > > > >From the sound of Olafur's and Miek's messages, they don't believe one > > of #1 or #2, and I'm not sure which. Either way, I'm pretty committed > > to #1. If #2 isn't true, then my scheme is a merely a clarification. > > #1 is not enforceable. > > > > > -- 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: If a zone is not signed with *a* manditory to implement algorithm it is a operator error (this assumes the Internet name space). It doesn't have to be signed with all manditory to implement algorithms. A parent and child can choose to use different manditory to implement algorithms. This does NOT break the chain of trust. If a answer comes in w/o a algorithm you understand then you drop the answer and wait for the real answer to arrive. You should be waiting anyway in case the first response is bogus. If a resolver has disabled a manditory to implement algorithm and that is all that is there then they can't resolve the zone. If a resolver says that some algorithm must be there and it isn't then again the zone cannot be resolved. One would assume that when one tells a resolver this that the operators have some knowledge that would lead them to believe that this is a reasonable restriction of part/all of the namespace. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 3 03:38: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 DAA11012 for ; Wed, 3 Sep 2003 03:38:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uS6u-000GwK-44 for namedroppers-data@psg.com; Wed, 03 Sep 2003 07:31:24 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19uS6c-000Gvr-2o for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 07:31:06 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 7B8154EC7B; Wed, 3 Sep 2003 09:31:05 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 0020C4E6D4; Wed, 3 Sep 2003 09:31:05 +0200 (CEST) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h837V4Wt030597; Wed, 3 Sep 2003 09:31:04 +0200 Message-Id: <200309030731.h837V4Wt030597@birch.ripe.net> To: Michael Richardson Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: Message from Michael Richardson of "Tue, 02 Sep 2003 17:16:39 EDT." <5027.1062537399@marajade.sandelman.ottawa.on.ca> Date: Wed, 03 Sep 2003 09:31:04 +0200 From: Olaf Kolkman X-RIPE-Spam-Status: N 0.005247 X-RIPE-Signature: f01d7191808e77221e5c6b9b771a1cc0 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_01,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk * Then, we are back to the problem of expressing three outcomes using only * 1 bit when communicating with the application :-) Although important this issue is out of scope for this particular thread. --Olaf DNSEXT Co-chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 3 06:51: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 GAA22888 for ; Wed, 3 Sep 2003 06:51:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uV3m-0005eO-G0 for namedroppers-data@psg.com; Wed, 03 Sep 2003 10:40:22 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19uV3G-0005bW-9Z for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 10:39:50 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h83AcY2G007888 for ; Wed, 3 Sep 2003 06:38:34 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAObayzp; Wed, 3 Sep 03 06:38:32 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h83AM2Bl009964; Wed, 3 Sep 2003 06:22:02 -0400 (EDT) Date: Wed, 3 Sep 2003 06:22:02 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: Mike StJohns cc: bmanning@karoshi.com, namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <6.0.0.20.2.20030902140309.035bac98@localhost> Message-ID: References: <6.0.0.20.2.20030902140309.035bac98@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks for the diagram. Although I'd reorder some things, it sounds like we're on the same page. > a) If a signature chain depends on an algorithm that the resolver doesn't ... > b) If a signature chain contains multiple algorithms, all implemented ... > c) If, at any given node in the chain, considering only the algo... ... > Resolver policy gets to specify how the application treats data based on > whether it thinks the responses are secure, insecure or bogus. At a first pass, I concur with the above. > In this document should go: > > "A resolver MUST implement support for both RSA and DSA. This requirement > ensures the ability to transition to a secondary algorithm in the event of > the primary algorithm becomes cryptographically tractable in the future > (i.e. "broken"). For the foreseeable future, it is anticipated that RSA > will be used as the primary algorithm for signing data in the DNS. Any > tools written to sign DNS data MUST default to RSA as the signature > mechanism, but MUST also implement support for DSA signatures. Those tools > MAY implement support for other defined algorithms, but MUST default to not > using those algorithms unless explicitly requested by the operator." > > In a document on DNSSEC operational policy (a BCP) should contain: > > "RSA MUST be used by all zone owners as the primary signature algorithm for > DNSSEC zone signing. Zone owners MAY also sign their zones with DSA. The > root zone, when signed, shall contain a complete set of both RSA and DSA > signature records." I'm not sure how this follows from the a, b, c above. Is there any need to require RSA signing? I think we can get away without it. The last line "shall contain a complete set" is the bit I think is so important, and it needs a MUST. As for exact text, what do you think of the text I proposed on August 13th? And I'm still indifferent as to whether or not we deprecate DSA. -- 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 Sep 3 09:00: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 JAA00533 for ; Wed, 3 Sep 2003 09:00:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uX7z-000GED-5F for namedroppers-data@psg.com; Wed, 03 Sep 2003 12:52:51 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 19uX7t-000GDl-7V for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 12:52:45 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h83CqaLR024023 for ; Wed, 3 Sep 2003 08:52:36 -0400 (EDT) Message-ID: <014901c3721a$41425c10$b9370681@barnacle> From: "Scott Rose" To: References: <00ef01c37144$7a5ebdd0$b9370681@barnacle> <200309022128.h82LSPYJ004810@guava.araneus.fi> Subject: Re: Fw: DNSSECbis Q-16 suggested text CORRECTION Date: Wed, 3 Sep 2003 08:52:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Agreed, the suggestion is much clearer that way. A recursive nameserver must not send any DNSSEC RRs added for authentication back to the originating client (unless explicitly queried by the client resolver). My main goal with the text I suggested was to allow a recursive, caching server the option of following its own local policy if it can mesh it with a client's specific request options. Scott ----- Original Message ----- From: "Andreas Gustafsson" To: "Scott Rose" Cc: Sent: Tuesday, September 02, 2003 5:28 PM Subject: Re: Fw: DNSSECbis Q-16 suggested text CORRECTION > Scott Rose writes: > > The last sentence should read: "However, if the DO bit is not set, the name > > server side MUST strip all DNSSEC related RRsets from the final response." > > That is not what the DO bit does. DO=0 does not cause the server to > "strip all DNSSEC related RRsets from the response" - it just causes > it to not add DNSSEC related RRs authenticating the response. RFC3225 > section 3 says: > > More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, > or NXT RRs to authenticate a response as specified in [RFC2535] > unless the DO bit was set on the request. Security records that > match an explicit SIG, KEY, NXT, or ANY query, or are part of the > zone data for an AXFR or IXFR query, are included whether or not the > DO bit was set. > > Therefore, to correctly reflect the semantics of DO, the last sentence > would have to say something like "However, if the DO bit is not set, > the name server side MUST strip any DNSSEC RRs that the resolver side > may have added to authenticate the response", and perhaps even add > "but MUST NOT strip any DNSSEC RRs explicitly requested". > -- > Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 3 09:39: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 JAA03532 for ; Wed, 3 Sep 2003 09:39:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uXki-000JNi-FG for namedroppers-data@psg.com; Wed, 03 Sep 2003 13:32:52 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 19uXjM-000JDy-6z for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 13:31:28 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 2BA8162C; Wed, 3 Sep 2003 09:31:27 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B8A27624; Wed, 3 Sep 2003 09:31:26 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 614071; Wed, 03 Sep 2003 09:28:31 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030902204334.GA31955@csi.hu> References: <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> <20030828042006.26191.qmail@cr.yp.to> <20030828094003.GP910@apb.cequrux.com> <20030830055434.GA18190@csi.hu> <20030902204334.GA31955@csi.hu> Date: Wed, 3 Sep 2003 09:31:39 -0400 To: mw-list-namedroppers@csi.hu From: Edward Lewis Subject: Re: wcard-clarify violating RFC 2119, section 6 Cc: Name Droppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:43 -0500 9/2/03, mw-list-namedroppers@csi.hu wrote: >I certainly never said anything about the "always existence" of names. >In fact, what I mean to emphasize is that the existence of _names_ is >not be confused with the existence of nodes(=resource sets). I'm going to hold back on my discussion on this because I really don't have a lot of time to allocate. But, to start, I think the problem here is that the names are the nodes, not the resource sets. The names are organized in the tree structure, not the data. Perhaps that's the start of the confusion. I.e., wild card synthesis doesn't care about QTYPE (unless it's CNAME), only about QNAME and the declared names. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 3 09:39: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 JAA03588 for ; Wed, 3 Sep 2003 09:39:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uXlr-000JRP-M3 for namedroppers-data@psg.com; Wed, 03 Sep 2003 13:34:03 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19uXjL-000JDw-E9 for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 13:31:27 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 63966425; Wed, 3 Sep 2003 09:31:26 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id DE395351; Wed, 3 Sep 2003 09:31:25 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 614070; Wed, 03 Sep 2003 09:28:30 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 3 Sep 2003 09:23:06 -0400 To: Simon Josefsson From: Edward Lewis Subject: Re: Comment on draft-ietf-dnsext-wcard-clarify-01.txt Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 0:14 +0200 9/3/03, Simon Josefsson wrote: >This appear to be over-qualified; it isn't valid in the point of view >of a client. Specifically: RFC 1034 section 4.3.3 says results from >wildcard queries should not be cached. Hence there actually is >special processing accorded to wild card labels in a QNAME. Splitting hairs, the requirement in wcard-clarify talks about the query, not the caching of the result. I can make a note that 1034 states to not cache the result, but otherwise I don't see special processing during the query process. >The last note of section 2, and the entire appendix A, seems at least >partially inconsistent with RFC 1034. Specifically: RFC 1034 says a >wildcard RR look like *. where should not >contain other * labels. So *.*.example is not a valid wild card >according to RFC 1034, contrary to what the draft claims. If >something needs to be clarified, how about making a clarification >saying that 'MUST NOT' contain other * labels? If the >draft intend to redefine RFC 1034 on what may contain, >that should IMHO be made more clear, as the abstract now give the >impression that the draft doesn't alter any definitions. There's a quite explicit contradiction here. On the one hand, 1034 bars multiple '*'-names. When doing the research behind wcard-clarify, this was missed, but we did find that they "work" on paper and even when tested in some software laying about. There are two options here, just as Simon mentions. 1) Undo what's in Appendix A to remain in line with 1034. 2) Allow "them" and alter the intro/abstract to say that definitions are changed. I may need to soften the statements that nothing is changed because we have redefined "CNAMEs at wild cards." I'll say one thing in defense of allowing multiple-*'d names. They work without a meltdown. I.e., the don't seem to cause harm. Why I favor them for this is that if we retain the restriction against them, we should specify what happens if they are seen - in configurations, in zone transfers, and in responses and queries. If we allow them, there are no special rules to specify and enforce. I'm for fewer error conditions. When the doc was individual I mentioned that nothing was changed other than existence, and any changes were in error. Being that it was then an individual submission, I didn't want to propose changes. Now that this is a WG doc, it's up to the WG and the WG can make changes. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 3 10:59: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 KAA12722 for ; Wed, 3 Sep 2003 10:59:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uYyd-0000K1-Ci for namedroppers-data@psg.com; Wed, 03 Sep 2003 14:51:19 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.22) id 19uYy5-0000Iw-6A for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 14:50:45 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h83Eog42025680 for ; Wed, 3 Sep 2003 16:50:43 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) id h83Eogc0025678 for namedroppers@ops.ietf.org; Wed, 3 Sep 2003 16:50:42 +0200 Date: Wed, 3 Sep 2003 16:50:42 +0200 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-ID: <20030903145042.GA25645@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@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-new X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 01 Sep, @18:06, Sam wrote in "Re: DNSSECbis Q-2: degradation ..."] > >From the sound of Olafur's and Miek's messages, they don't believe one > of #1 or #2, and I'm not sure which. Either way, I'm pretty committed > to #1. If #2 isn't true, then my scheme is a merely a clarification. Ok, having talked to Sam, he convinced me about this degradation attack. As I understand it, the following takes place: There are four distinct cases: 1. there is no DS at the parent. A resolver should treat the child zone as being "verifiably UNsecured". 2. there is DS and the DS points to a DNSKEY with a known algorithm. The resolver should treat the child zone is being "verifiably secured". 3. There is a valid DS at the parent, but the DS points to a DNSKEY with a unknown algorithm. So there is a DS. The zone should be verifiably unsecured not BAD. You should treat this as unsigned, not as BAD. If you treat this as BAD it is impossible to deploy new algorithms - the zone deploying the new algorithm would drop from the Net immediately. 4. There are 2 DSs at the parent, one which points to a key with an unknown alg. DNSKEY and one that points to a DNSKEY with a known alg. Then in the child zone some RRsets are signed with the known alg. and others with the unknown alg KEY. With 4. A resolver comes in, sees the RRset, get's the sig. *bam* unknown algorithm. Now what? Bad? Well actually no - it is just that the resolver doesn't know the algorithm. This should not lead to a situation were the zone drops from the Net. If that happens it is impossible to deploy new algorithms gradually on the Net. (This is the same as what happens in 3.) The only thing that would help here is if the RRsets are also signed with the other, known algorithm. And that is what Sam is saying: A zone should be signed with ALL the algorithms in the keyset. And the keyset in turn should be signed with all the algs. in the DS set. This is currently under or not specicified in the specs. If a zone is not signed this way a resolver should raise an error (and not treat the data is being BAD). regard, 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 Sep 3 11:09: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 LAA13802 for ; Wed, 3 Sep 2003 11:09:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uZCM-0001OG-Gb for namedroppers-data@psg.com; Wed, 03 Sep 2003 15:05:30 +0000 Received: from [141.225.37.221] (helo=thales.memphis.edu) by psg.com with smtp (Exim 4.22) id 19uZBq-0001K5-Ub for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 15:04:59 +0000 Received: (qmail 9226 invoked by uid 500); 3 Sep 2003 15:05:18 -0000 From: mw-list-namedroppers@csi.hu Date: Wed, 3 Sep 2003 10:05:18 -0500 To: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 Message-ID: <20030903150518.GA8460@csi.hu> References: <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> <20030828042006.26191.qmail@cr.yp.to> <20030828094003.GP910@apb.cequrux.com> <19794.1062334942@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19794.1062334942@munnari.OZ.AU> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-7.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, Aug 31, 2003 at 08:02:22PM +0700, Robert Elz wrote: > | Each node and leaf on the tree corresponds to a resource set (which > | may be empty). > | > | in section 3.1, that in fact what it says is > | > | Each node and leaf on the tree corresponds to a resource set (which > | may be empty, but then the resource sets of all subnodes must be > | empty too). > > It doesn't, and no-one claims that. > > | I believe the author specifically wants to allow names that refer to > | nothing (what else is the meaning of an empty resource set), > > Yes, exactly. > > | and once he established the concepts precisely in the beginning, > | he identifies a name with the node and then the node with the > | associated resource set. So when he later writes about nonexistent > | names he means nonexistent (empty) associated resource set. > > I'm not sure I can parse that last sentence, but I think I agree. > That is, I think you're saying, that if a name has an empty resource set > (or a non-empty one for that matter), it exists. That I believe is the > intent of the sentence from 1034 you quoted. Actually, my interpretation is the opposite: an empty resource set means the domain does not exist. This is because the resource set should determine existence/nonexistence. It does not matter whether the owner of the empty resource set is in the zonefile or not (it was QNAME). For example, wcard-clarify's section 1.3 says _tcp.host1.example exists with no data---I'd say it does not exist. Of course, it sounds silly to say the _name_ _tcp.host1.example does not exist. Names always exist, but what servers/clients (should) care about is the resource set. And if the resource set is empty, that is a name error using rfc1034's terminology. > > | So when you receive a "name error" when querying aol.org for > | ns.aol.org, it seems to be a stretch to conclude that you also have to > | give up on d.ns.aol.org. > > What I think you're missing there, is the real point. That is, if > d.ns.aol.org exists, then (obviously, as you can see it sitting there > in that name) ns.aol.org exists. Consequently, you don't get a "name > error" (rcode == 3, which we mostly call NXDOMAIN) when you query ns.aol.com > (you cannot) regardless of what RR's exist at that node (including none). > By what I said above, while _name_ ns.aol.org exists, it owns an empty resource set, and hence name error should be returned. > Even Prof Bernstein agrees that this is what RFC1034/5 say is correct. I do not see this if I read rfc1034 with the understanding that in many cases when it talks about (the existence of) a name it, in fact, talks about the resource set owned by the name. Mate --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis -- to unsubscribe send a message to namedroppers-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 Sep 3 11:30: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 LAA15683 for ; Wed, 3 Sep 2003 11:30:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uZTp-0002eV-5u for namedroppers-data@psg.com; Wed, 03 Sep 2003 15:23:33 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 19uZTf-0002e4-L3 for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 15:23:28 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h83FN4LR019417 for ; Wed, 3 Sep 2003 11:23:04 -0400 (EDT) Message-ID: <000a01c3722f$45637080$b9370681@barnacle> From: "Scott Rose" To: References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> Subject: Re: DNSSECbis Q-2: degradation attack Date: Wed, 3 Sep 2003 11:23:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think this write-up helps clear the air a bit. I agree with the threat of the degradation attack, but there are 2 (possible) task the WG and DNSSECbis editors should clarify: 1. Should the DNSSECbis drafts, or some other document, give more specifications of what a "secure, signed zone" should contain? In order for a resolver to be able to make a decision about the security status of a zone when it gets a response. 2. Is this threat severe enough to warrant specific language on a secure zone contents (with respect to RRSIGs) in the DNSSECbis spec, or have it as a recommendation, as in a BCP? 3. (larger scope) - how resolvers might want to classify responses with regards to security as well as authority. With respects to question 2, I'm starting to lean towards BCP for the text. I believe it is a threat, but not one that most administrators will have to deal with (most will only sign with 1 algo until told it has been broken). I'm ambivalent on the topic Scott ----- Original Message ----- From: "Miek Gieben" To: Sent: Wednesday, September 03, 2003 10:50 AM Subject: Re: DNSSECbis Q-2: degradation attack > [On 01 Sep, @18:06, Sam wrote in "Re: DNSSECbis Q-2: degradation ..."] > > >From the sound of Olafur's and Miek's messages, they don't believe one > > of #1 or #2, and I'm not sure which. Either way, I'm pretty committed > > to #1. If #2 isn't true, then my scheme is a merely a clarification. > > Ok, having talked to Sam, he convinced me about this degradation attack. > > As I understand it, the following takes place: > > There are four distinct cases: > > 1. there is no DS at the parent. A resolver should treat the > child zone as being "verifiably UNsecured". > > 2. there is DS and the DS points to a DNSKEY with a known algorithm. > The resolver should treat the child zone is being "verifiably secured". > > 3. There is a valid DS at the parent, but the DS points to a DNSKEY with a > unknown algorithm. So there is a DS. The zone should be verifiably unsecured > not BAD. > > You should treat this as unsigned, not as BAD. If you treat this as > BAD it is impossible to deploy new algorithms - the zone deploying > the new algorithm would drop from the Net immediately. > > 4. There are 2 DSs at the parent, one which points to a key with an > unknown alg. DNSKEY and one that points to a DNSKEY with a known alg. > Then in the child zone some RRsets are signed with the known alg. and > others with the unknown alg KEY. > > With 4. A resolver comes in, sees the RRset, get's the sig. *bam* unknown > algorithm. Now what? Bad? Well actually no - it is just that the resolver > doesn't know the algorithm. This should not lead to a situation were the zone > drops from the Net. If that happens it is impossible to deploy new algorithms > gradually on the Net. (This is the same as what happens in 3.) > > The only thing that would help here is if the RRsets are also signed with the > other, known algorithm. > > And that is what Sam is saying: > A zone should be signed with ALL the algorithms in the keyset. And the keyset in > turn should be signed with all the algs. in the DS set. This is currently under > or not specicified in the specs. If a zone is not signed this way a resolver > should raise an error (and not treat the data is being BAD). > > regard, > 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: -- to unsubscribe send a message to namedroppers-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 Sep 3 11:49: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 LAA17358 for ; Wed, 3 Sep 2003 11:49:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uZnP-0004KE-0g for namedroppers-data@psg.com; Wed, 03 Sep 2003 15:43:47 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19uZmV-0004DM-A1 for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 15:42:51 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h83FfVYf096721; Thu, 4 Sep 2003 01:41:31 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309031541.h83FfVYf096721@bsdi.dv.isc.org> To: mw-list-namedroppers@csi.hu Cc: Name Droppers From: Mark.Andrews@isc.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-reply-to: Your message of "Wed, 03 Sep 2003 10:05:18 EST." <20030903150518.GA8460@csi.hu> Date: Thu, 04 Sep 2003 01:41:31 +1000 X-Spam-Status: No, hits=-4.4 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Sun, Aug 31, 2003 at 08:02:22PM +0700, Robert Elz wrote: > > | Each node and leaf on the tree corresponds to a resource set (which > > | may be empty). > > | > > | in section 3.1, that in fact what it says is > > | > > | Each node and leaf on the tree corresponds to a resource set (which > > | may be empty, but then the resource sets of all subnodes must be > > | empty too). > > > > It doesn't, and no-one claims that. > > > > | I believe the author specifically wants to allow names that refer to > > | nothing (what else is the meaning of an empty resource set), > > > > Yes, exactly. > > > > | and once he established the concepts precisely in the beginning, > > | he identifies a name with the node and then the node with the > > | associated resource set. So when he later writes about nonexistent > > | names he means nonexistent (empty) associated resource set. > > > > I'm not sure I can parse that last sentence, but I think I agree. > > That is, I think you're saying, that if a name has an empty resource set > > (or a non-empty one for that matter), it exists. That I believe is the > > intent of the sentence from 1034 you quoted. > > Actually, my interpretation is the opposite: an empty resource set > means the domain does not exist. This is because the resource set > should determine existence/nonexistence. The DNS is a tree. The nodes of this tree can be empty but they do exist. 3.1. Name space specifications and terminology The domain name space is a tree structure. Each node and leaf on the tree corresponds to a resource set (which may be empty). The domain system makes no distinctions between the uses of the interior nodes and leaves, and this memo uses the term "node" to refer to both. > It does not matter whether the owner of the empty resource set is in > the zonefile or not (it was QNAME). For example, wcard-clarify's > section 1.3 says _tcp.host1.example exists with no data---I'd say it > does not exist. No. It exist. > Of course, it sounds silly to say the _name_ _tcp.host1.example does > not exist. Names always exist, but what servers/clients (should) care > about is the resource set. And if the resource set is empty, that is > a name error using rfc1034's terminology. No. It is not. > > | So when you receive a "name error" when querying aol.org for > > | ns.aol.org, it seems to be a stretch to conclude that you also have to > > | give up on d.ns.aol.org. > > > > What I think you're missing there, is the real point. That is, if > > d.ns.aol.org exists, then (obviously, as you can see it sitting there > > in that name) ns.aol.org exists. Consequently, you don't get a "name > > error" (rcode == 3, which we mostly call NXDOMAIN) when you query ns.aol.co > m > > (you cannot) regardless of what RR's exist at that node (including none). > > > > By what I said above, while _name_ ns.aol.org exists, it owns an empty > resource set, and hence name error should be returned. > > > Even Prof Bernstein agrees that this is what RFC1034/5 say is correct. > > I do not see this if I read rfc1034 with the understanding that in > many cases when it talks about (the existence of) a name it, in fact, > talks about the resource set owned by the name. > > Mate > --- > Mate Wierdl | Dept. of Math. Sciences | University of Memphis > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 3 14:23: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 OAA27476 for ; Wed, 3 Sep 2003 14:23:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uc68-000Ku5-Je for namedroppers-data@psg.com; Wed, 03 Sep 2003 18:11:16 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.22) id 19uc5c-000KpK-Uf for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 18:10:45 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 011EE18D2 for ; Wed, 3 Sep 2003 14:10:30 -0400 (EDT) Date: Wed, 03 Sep 2003 14:10:30 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: Fw: DNSSECbis Q-16 suggested text CORRECTION In-Reply-To: <200309022128.h82LSPYJ004810@guava.araneus.fi> References: <00ef01c37144$7a5ebdd0$b9370681@barnacle> <200309022128.h82LSPYJ004810@guava.araneus.fi> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030903181031.011EE18D2@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Tue, 2 Sep 2003 14:28:25 -0700 (PDT), Andreas Gustafsson wrote: > > Therefore, to correctly reflect the semantics of DO, the last sentence > would have to say something like "However, if the DO bit is not set, > the name server side MUST strip any DNSSEC RRs that the resolver side > may have added to authenticate the response", I have a minor issue with "that the resolver side may have added", because if one believes in the "blob caching" theory, the resolver doesn't add anything, it just spits out everything it received in response to a particular triple verbatim (other than adjusting TTLs and so forth) rather than attempting to piece together answers from individual cached RRsets. (Yes, I know that piecing answers together from individual RRsets is traditional, and indeed, all the resolver code I've ever written does it that way, but over the last year or so I've become convinced that the blob caching approach is more robust, particularly as we add more and more baroque stuff to the DNS in an attempt to add new features while maintaining backwards compatability.) But I think this is getting past the point of diminishing returns for wordsmithing at this stage, and I think we agree on the interaction between CD and DO, which was the point of this thread. > and perhaps even add "but MUST NOT strip any DNSSEC RRs explicitly > requested". Agreed. -- to unsubscribe send a message to namedroppers-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 Sep 3 14:39: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 OAA28757 for ; Wed, 3 Sep 2003 14:39:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ucQR-000Nya-Re for namedroppers-data@psg.com; Wed, 03 Sep 2003 18:32:15 +0000 Received: from [141.225.37.221] (helo=thales.memphis.edu) by psg.com with smtp (Exim 4.22) id 19ucPv-000Nua-NS for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 18:31:43 +0000 Received: (qmail 10789 invoked by uid 500); 3 Sep 2003 18:32:05 -0000 From: mw-list-namedroppers@csi.hu Date: Wed, 3 Sep 2003 13:32:05 -0500 To: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 Message-ID: <20030903183204.GB8460@csi.hu> References: <20030903150518.GA8460@csi.hu> <200309031541.h83FfVYf096721@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309031541.h83FfVYf096721@bsdi.dv.isc.org> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Sep 04, 2003 at 01:41:31AM +1000, Mark.Andrews@isc.org wrote: > > > On Sun, Aug 31, 2003 at 08:02:22PM +0700, Robert Elz wrote: > > > | Each node and leaf on the tree corresponds to a resource set (which > > > | may be empty). > > > | > > > | in section 3.1, that in fact what it says is > > > | > > > | Each node and leaf on the tree corresponds to a resource set (which > > > | may be empty, but then the resource sets of all subnodes must be > > > | empty too). > > > > > > It doesn't, and no-one claims that. > > > > > > | I believe the author specifically wants to allow names that refer to > > > | nothing (what else is the meaning of an empty resource set), > > > > > > Yes, exactly. > > > > > > | and once he established the concepts precisely in the beginning, > > > | he identifies a name with the node and then the node with the > > > | associated resource set. So when he later writes about nonexistent > > > | names he means nonexistent (empty) associated resource set. > > > > > > I'm not sure I can parse that last sentence, but I think I agree. > > > That is, I think you're saying, that if a name has an empty resource set > > > (or a non-empty one for that matter), it exists. That I believe is the > > > intent of the sentence from 1034 you quoted. > > > > Actually, my interpretation is the opposite: an empty resource set > > means the domain does not exist. This is because the resource set > > should determine existence/nonexistence. > > The DNS is a tree. The nodes of this tree can be empty but > they do exist. So, unlike Mr Lewis, you do identify the node with the resource set, and not the name. In any case, can you tell me why clients should care to distingush between 1) name is in zonefile with empty resource set 2) name is not in zonefile Except that in wcard-clarify, the desire to distinguish the two cases results in a complicated and unclear definition of existence/nonexistence. Indeed, can you tell me when a domain exists according to wcard-clarify? I see (R3.1) A domain name is defined to exist if the domain name owns data and/or has a subdomain that exists. This definition does not fit _tcp.host1.example of example 1.3 (of wcard-clarify) since the resource set is empty (so there is no data to be owned) and it does not have an existing subdomain. You would then think, _tcp.host1.example does not exist, since the denial of existence is non-existence. But in wcard-clarify there is R3.2, which says: R3.2 An authoritative server MUST treat a domain name that has neither a resource record set nor an existing subdomain as non-existent... First, I do not understand why there would be a need for a separate definition of nonexistence if the definition of existence was precise enough to cover all cases. In any case, notice that the above does not cover _tcp.host1.example of example 1.3 either, since _tcp.host1.example does have a resource record set, namely the empty set. wcard-clarify takes the position, in example 1.3, that _tcp.host1.example exists---I do not see, though, how either of the above definitions are used for this conclusion. Why cannot we just define the existence of a domain by the resource record set? A domain exists if and only if the RR set is nonempty. --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis -- to unsubscribe send a message to namedroppers-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 Sep 3 15:28: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 PAA02592 for ; Wed, 3 Sep 2003 15:28:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19udBA-0005ba-NL for namedroppers-data@psg.com; Wed, 03 Sep 2003 19:20:32 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19udAK-0005SS-Eo for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 19:19:40 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 0AD7831B; Wed, 3 Sep 2003 15:19:39 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id A0C9B2EF; Wed, 3 Sep 2003 15:19:38 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 615455; Wed, 03 Sep 2003 15:16:41 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030903183204.GB8460@csi.hu> References: <20030903150518.GA8460@csi.hu> <200309031541.h83FfVYf096721@bsdi.dv.isc.org> <20030903183204.GB8460@csi.hu> Date: Wed, 3 Sep 2003 15:19:49 -0400 To: mw-list-namedroppers@csi.hu From: Edward Lewis Subject: Re: wcard-clarify violating RFC 2119, section 6 Cc: Name Droppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:32 -0500 9/3/03, mw-list-namedroppers@csi.hu wrote: >So, unlike Mr Lewis, you do identify the node with the resource set, >and not the name. I'll leave that ("you do identify") to Mark Andrews to answer. I think that there's a need for you to study 1034 closer. It's not just my opinion that names exist or don't, and that existence of sets is a second tier issue. It's the reason that there is a 'name error' defined but no 'set error.' (Look at the RCODE values in 1035.) It's the reason synthesis is done on a name basis and not on a set basis. (Why doesn't * MX fill in the MX's for all the hosts "in" the zone?) >In any case, can you tell me why clients should >care to distingush between > >1) name is in zonefile with empty resource set >2) name is not in zonefile I've already answered this in http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01574.html, look for the word "folklore". There's no reason why a client should really care - 'no data' is 'no data.' But, well, it's a historic distinction. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 3 16:00: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 QAA04542 for ; Wed, 3 Sep 2003 16:00:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19udeL-000Arq-KZ for namedroppers-data@psg.com; Wed, 03 Sep 2003 19:50:41 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.22) id 19uddp-000Al9-Hr for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 19:50:09 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h83Jo742029603 for ; Wed, 3 Sep 2003 21:50:08 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) id h83Jo7na029601 for namedroppers@ops.ietf.org; Wed, 3 Sep 2003 21:50:07 +0200 Date: Wed, 3 Sep 2003 21:50:07 +0200 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-ID: <20030903195006.GA29560@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> <000a01c3722f$45637080$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000a01c3722f$45637080$b9370681@barnacle> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 03 Sep, @17:23, Scott wrote in "Re: DNSSECbis Q-2: degradation ..."] > I think this write-up helps clear the air a bit. I agree with the threat of > the degradation attack, but there are 2 (possible) task the WG and DNSSECbis > editors should clarify: > > 1. Should the DNSSECbis drafts, or some other document, give more > specifications of what a "secure, signed zone" should contain? In order for > a resolver to be able to make a decision about the security status of a zone > when it gets a response. > > 2. Is this threat severe enough to warrant specific language on a secure > zone contents (with respect to RRSIGs) in the DNSSECbis spec, or have it as > a recommendation, as in a BCP? > > 3. (larger scope) - how resolvers might want to classify responses with > regards to security as well as authority. > > With respects to question 2, I'm starting to lean towards BCP for the text. > I believe it is a threat, but not one that most administrators will have to > deal with (most will only sign with 1 algo until told it has been broken). well, I guess it should be specified in the DNSSECbis spec - that way resolvers can treat it as a "real" protocol error when they encountered it. The attack is real enough to warrant this. It's not about administrators, it is about being able to deploy a new algorithm when the need arises. 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 Sep 3 19:29:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16449 for ; Wed, 3 Sep 2003 19:29:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uguU-000H23-Nn for namedroppers-data@psg.com; Wed, 03 Sep 2003 23:19:34 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19ugty-000Gxy-9W for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 23:19:02 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h83NHCYf097726; Thu, 4 Sep 2003 09:17:12 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309032317.h83NHCYf097726@bsdi.dv.isc.org> To: mw-list-namedroppers@csi.hu Cc: Name Droppers From: Mark.Andrews@isc.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-reply-to: Your message of "Wed, 03 Sep 2003 13:32:05 EST." <20030903183204.GB8460@csi.hu> Date: Thu, 04 Sep 2003 09:17:12 +1000 X-Spam-Status: No, hits=-4.4 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Thu, Sep 04, 2003 at 01:41:31AM +1000, Mark.Andrews@isc.org wrote: > > > > > On Sun, Aug 31, 2003 at 08:02:22PM +0700, Robert Elz wrote: > > > > | Each node and leaf on the tree corresponds to a resource set (wh > ich > > > > | may be empty). > > > > | > > > > | in section 3.1, that in fact what it says is > > > > | > > > > | Each node and leaf on the tree corresponds to a resource set (wh > ich > > > > | may be empty, but then the resource sets of all subnodes must be > > > > | empty too). > > > > > > > > It doesn't, and no-one claims that. > > > > > > > > | I believe the author specifically wants to allow names that refer t > o > > > > | nothing (what else is the meaning of an empty resource set), > > > > > > > > Yes, exactly. > > > > > > > > | and once he established the concepts precisely in the beginning, > > > > | he identifies a name with the node and then the node with the > > > > | associated resource set. So when he later writes about nonexistent > > > > | names he means nonexistent (empty) associated resource set. > > > > > > > > I'm not sure I can parse that last sentence, but I think I agree. > > > > That is, I think you're saying, that if a name has an empty resource se > t > > > > (or a non-empty one for that matter), it exists. That I believe is th > e > > > > intent of the sentence from 1034 you quoted. > > > > > > Actually, my interpretation is the opposite: an empty resource set > > > means the domain does not exist. This is because the resource set > > > should determine existence/nonexistence. > > > > The DNS is a tree. The nodes of this tree can be empty but > > they do exist. > > So, unlike Mr Lewis, you do identify the node with the resource set, > and not the name. In any case, can you tell me why clients should > care to distingush between An empty resouce set is just a name. These only appear in the interior of a tree and never at the leaves. > 1) name is in zonefile with empty resource set > 2) name is not in zonefile > > Except that in wcard-clarify, the desire to distinguish the two cases > results in a complicated and unclear definition of > existence/nonexistence. Indeed, can you tell me when a domain exists > according to wcard-clarify? It comes back to the basic premise that the DNS is a tree. All names exist between the root of the tree and the leaves. You also want nameservers from different vendors to produce consistant results based on the same zone contents. > I see (R3.1) > > A domain name is defined to exist if the domain name owns data > and/or has a subdomain that exists. > > This definition does not fit _tcp.host1.example of example 1.3 (of > wcard-clarify) since the resource set is empty (so there is no data to > be owned) and it does not have an existing subdomain. In the example _tcp.host1.example has a subdomain that has a non-empty RRset. That non-empty RRset is _ssh._tcp.host1.example. SRV _ssh._tcp.host1.example is a subdomain of _tcp.host1.example, host1.example, example and ".". The set of all non-empty RRsets in a zone define all names the exist in a zone whether all those names have RRset at them or not. > You would then > think, _tcp.host1.example does not exist, since the denial of > existence is non-existence. > > But in wcard-clarify there is R3.2, which says: > > R3.2 An authoritative server MUST treat a domain name that has neither > a resource record set nor an existing subdomain as non-existent... > > First, I do not understand why there would be a need for a separate > definition of nonexistence if the definition of existence was precise > enough to cover all cases. In any case, notice that the above does > not cover _tcp.host1.example of example 1.3 either, since > _tcp.host1.example does have a resource record set, namely the empty > set. You fail to account for "nor an existing subdomain". It has an existing subdomain (_ssh._tcp.host1.example). > wcard-clarify takes the position, in example 1.3, that > _tcp.host1.example exists---I do not see, though, how either of the > above definitions are used for this conclusion. > > Why cannot we just define the existence of a domain by the resource > record set? > > A domain exists if and only if the RR set is nonempty. This is false. > --- > Mate Wierdl | Dept. of Math. Sciences | University of Memphis > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 3 20:33: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 UAA20710 for ; Wed, 3 Sep 2003 20:33:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uhv3-000111-TB for namedroppers-data@psg.com; Thu, 04 Sep 2003 00:24:13 +0000 Received: from [129.9.82.74] (helo=fxodpr13.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.22) id 19uhsM-0000bG-56 for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 00:21:26 +0000 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.12.8/8.9.0) id h840LNcB016539 for ; Wed, 3 Sep 2003 20:21:23 -0400 (EDT) Received: from unknown(53.231.71.24) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAIFaqtG; Wed, 3 Sep 03 20:21:23 -0400 Received: from odconpr2-hme0.oddc.chrysler.com ([127.0.0.1]) by odconpr2-hme0.oddc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003090320212216668 for ; Wed, 03 Sep 2003 20:21:22 -0400 Received: from shmrspr2-hme0.shdc.chrysler.com ([129.9.145.240]) by odconpr2-hme0.oddc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003090320212225957 for ; Wed, 03 Sep 2003 20:21:22 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by shmrspr2-hme0.shdc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h840LMWs021325 for ; Wed, 3 Sep 2003 20:21:22 -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 h840Kgp1012597 for ; Wed, 3 Sep 2003 20:20:42 -0400 (EDT) Message-ID: <3F56855A.79BF498F@daimlerchrysler.com> Date: Wed, 03 Sep 2003 20:20:42 -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: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 References: <200309032317.h83NHCYf097726@bsdi.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org wrote: > > On Thu, Sep 04, 2003 at 01:41:31AM +1000, Mark.Andrews@isc.org wrote: > > > > > > > On Sun, Aug 31, 2003 at 08:02:22PM +0700, Robert Elz wrote: > > > > > | Each node and leaf on the tree corresponds to a resource set (wh > > ich > > > > > | may be empty). > > > > > | > > > > > | in section 3.1, that in fact what it says is > > > > > | > > > > > | Each node and leaf on the tree corresponds to a resource set (wh > > ich > > > > > | may be empty, but then the resource sets of all subnodes must be > > > > > | empty too). > > > > > > > > > > It doesn't, and no-one claims that. > > > > > > > > > > | I believe the author specifically wants to allow names that refer t > > o > > > > > | nothing (what else is the meaning of an empty resource set), > > > > > > > > > > Yes, exactly. > > > > > > > > > > | and once he established the concepts precisely in the beginning, > > > > > | he identifies a name with the node and then the node with the > > > > > | associated resource set. So when he later writes about nonexistent > > > > > | names he means nonexistent (empty) associated resource set. > > > > > > > > > > I'm not sure I can parse that last sentence, but I think I agree. > > > > > That is, I think you're saying, that if a name has an empty resource se > > t > > > > > (or a non-empty one for that matter), it exists. That I believe is th > > e > > > > > intent of the sentence from 1034 you quoted. > > > > > > > > Actually, my interpretation is the opposite: an empty resource set > > > > means the domain does not exist. This is because the resource set > > > > should determine existence/nonexistence. > > > > > > The DNS is a tree. The nodes of this tree can be empty but > > > they do exist. > > > > So, unlike Mr Lewis, you do identify the node with the resource set, > > and not the name. In any case, can you tell me why clients should > > care to distingush between > > An empty resouce set is just a name. These only appear in the > interior of a tree and never at the leaves. > > > 1) name is in zonefile with empty resource set > > 2) name is not in zonefile > > > > Except that in wcard-clarify, the desire to distinguish the two cases > > results in a complicated and unclear definition of > > existence/nonexistence. Indeed, can you tell me when a domain exists > > according to wcard-clarify? > > It comes back to the basic premise that the DNS is a tree. > All names exist between the root of the tree and the leaves. Not to be contrary, but I think the more _modern_ way to view it is that a DNS name is just a concatenated sequence of labels which forms a unique index into a DNS database. From that standpoint, the distinction between "terminal" and "nonterminal" really loses its meaning and it seems rather silly and quaint for a query of an empty "nonterminal" node to return anything different than a query of an empty "terminal" node. Empty is empty. Period. Whatever negative-caching optimizations are theoretically possible as a result of the seemingly-inconsistent empty-terminal-vs-empty-nonterminal response differentiation seem to me to be underutilized and not worth the confusion and the extra code and resources required to interpret such response variations. Obviously, the hierarchical structure of the DNS database is still important from a zone-delegation/referral standpoint. But as a *database*structure*, the hierarhical paradigm has long been superceded by relational and/or contextual paradigms. Maybe it's time to let it go... - 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 Sep 3 22:18: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 WAA26431 for ; Wed, 3 Sep 2003 22:18:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ujaG-000HkV-Fv for namedroppers-data@psg.com; Thu, 04 Sep 2003 02:10:52 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19uja9-000HjM-SY for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 02:10:46 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h8429NYf098200; Thu, 4 Sep 2003 12:09:24 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309040209.h8429NYf098200@bsdi.dv.isc.org> To: Kevin Darcy Cc: Name Droppers From: Mark.Andrews@isc.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-reply-to: Your message of "Wed, 03 Sep 2003 20:20:42 -0400." <3F56855A.79BF498F@daimlerchrysler.com> Date: Thu, 04 Sep 2003 12:09:23 +1000 X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Not to be contrary, but I think the more _modern_ way to view it is that a > DNS name is just a concatenated sequence of labels which forms a unique index > into > a DNS database. From that standpoint, the distinction between "terminal" and > "nonterminal" really loses its meaning and it seems rather silly and quaint f > or a > query of an empty "nonterminal" node to return anything different than a quer > y of > an empty "terminal" node. Empty is empty. Period. Whatever negative-caching > optimizations are theoretically possible as a result of the seemingly-inconsi > stent > empty-terminal-vs-empty-nonterminal response differentiation seem to me to be > underutilized and not worth the confusion and the extra code and resources > required to interpret such response variations. > > Obviously, the hierarchical structure of the DNS database is still important > from > a zone-delegation/referral standpoint. But as a *database*structure*, the > hierarhical paradigm has long been superceded by relational and/or contextual > paradigms. Maybe it's time to let it go... Kevin this isn't about the "modern way". This is about clearing up any ambiguities in the definition. There are lots of nameservers that follow RFC 1034 and support empty nodes by returning NOERROR/NODATA. There are two nameservers that don't (one of which has been corrected) based on an interpretation of RFC 2535. > - 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: -- 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 Sep 3 23:29:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00669 for ; Wed, 3 Sep 2003 23:29:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ukfp-0002zi-Ho for namedroppers-data@psg.com; Thu, 04 Sep 2003 03:20:41 +0000 Received: from [203.146.39.147] (helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 4.22) id 19ukem-0002ng-Dx for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 03:19:37 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h843IWV20184; Thu, 4 Sep 2003 10:18:34 +0700 (ICT) From: Robert Elz To: mw-list-namedroppers@csi.hu cc: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 In-Reply-To: <20030903150518.GA8460@csi.hu> References: <20030903150518.GA8460@csi.hu> <20030827171224.70609.qmail@cr.yp.to> <20030826174447.46552.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826024218.10706.qmail@cr.yp.to> <20030826141441.GK910@apb.cequrux.com> <15467.1061972977@munnari.OZ.AU> <18758.1062006971@munnari.OZ.AU> <20030828042006.26191.qmail@cr.yp.to> <20030828094003.GP910@apb.cequrux.com> <19794.1062334942@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Sep 2003 10:18:32 +0700 Message-ID: <1919.1062645512@munnari.OZ.AU> X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 3 Sep 2003 10:05:18 -0500 From: mw-list-namedroppers@csi.hu Message-ID: <20030903150518.GA8460@csi.hu> | Of course, it sounds silly to say the _name_ _tcp.host1.example does | not exist. Names always exist, but what servers/clients (should) care | about is the resource set. Mark Andrews already replied to most of your message, but just on this point - existence of itself is meaningless, what matters is existence in a particular domain (in the generic sense, not the DNS meaning of the term). For that, in the DNS, if I control a particular zone, I get to decide what names exist in that namespace - you can't make one appear by querying it. Whether or not I then choose to associate any resources with the name or not is an entirely separate question. | And if the resource set is empty, that is | a name error using rfc1034's terminology. No, it isn't - that's just an empty answer and no error, if the name exists. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Sep 3 23:37: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 XAA01057 for ; Wed, 3 Sep 2003 23:37:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uks6-0004zn-1U for namedroppers-data@psg.com; Thu, 04 Sep 2003 03:33:22 +0000 Received: from [141.225.37.221] (helo=thales.memphis.edu) by psg.com with smtp (Exim 4.22) id 19ukr3-0004q0-Nm for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 03:32:17 +0000 Received: (qmail 15621 invoked by uid 500); 4 Sep 2003 03:32:36 -0000 From: mw-list-namedroppers@csi.hu Date: Wed, 3 Sep 2003 22:32:36 -0500 To: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 Message-ID: <20030904033236.GA14932@csi.hu> References: <20030903183204.GB8460@csi.hu> <200309032317.h83NHCYf097726@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309032317.h83NHCYf097726@bsdi.dv.isc.org> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-7.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Sep 04, 2003 at 09:17:12AM +1000, Mark.Andrews@isc.org wrote: > You fail to account for "nor an existing subdomain". It has > an existing subdomain (_ssh._tcp.host1.example). My bad. All seem consistent now (sorry for the long learning curve), except rfc1034 does not explicitly outlaw a leaf with an empty RR set. While wcard-clarify does that now explicitly in its definition of existence, it also outlaws tinydns's present behavior: $ dnsq a ns.csi.hu a.ns.csi.hu | grep nx 76 bytes, 1+0+1+0 records, response, authoritative, nxdomain -- --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis -- to unsubscribe send a message to namedroppers-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 Sep 4 00:05: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 AAA02632 for ; Thu, 4 Sep 2003 00:05:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ulIo-0009ky-7k for namedroppers-data@psg.com; Thu, 04 Sep 2003 04:00:58 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19ulIg-0009jG-5J for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 04:00:50 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h843x2Yf098584; Thu, 4 Sep 2003 13:59:02 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309040359.h843x2Yf098584@bsdi.dv.isc.org> To: mw-list-namedroppers@csi.hu Cc: Name Droppers From: Mark.Andrews@isc.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-reply-to: Your message of "Wed, 03 Sep 2003 22:32:36 EST." <20030904033236.GA14932@csi.hu> Date: Thu, 04 Sep 2003 13:59:02 +1000 X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Thu, Sep 04, 2003 at 09:17:12AM +1000, Mark.Andrews@isc.org wrote: > > You fail to account for "nor an existing subdomain". It has > > an existing subdomain (_ssh._tcp.host1.example). > > My bad. All seem consistent now (sorry for the long learning curve), > except rfc1034 does not explicitly outlaw a leaf with an empty RR set. RFC 1034 provided no way to express such a construct. It would require meta data to be transmitted. > While wcard-clarify does that now explicitly in its definition of > existence, it also outlaws tinydns's present behavior: > > $ dnsq a ns.csi.hu a.ns.csi.hu | grep nx > 76 bytes, 1+0+1+0 records, response, authoritative, nxdomain Which is one of the two nameservers that get this wrong. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 00:14: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 AAA03068 for ; Thu, 4 Sep 2003 00:14:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ulSY-000BQ6-Nc for namedroppers-data@psg.com; Thu, 04 Sep 2003 04:11:02 +0000 Received: from [203.146.39.147] (helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 4.22) id 19ulRy-000BO4-0s for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 04:10:26 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8448ZV01087; Thu, 4 Sep 2003 11:08:36 +0700 (ICT) From: Robert Elz To: Mark.Andrews@isc.org cc: mw-list-namedroppers@csi.hu, Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 In-Reply-To: <200309040359.h843x2Yf098584@bsdi.dv.isc.org> References: <200309040359.h843x2Yf098584@bsdi.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Sep 2003 11:08:35 +0700 Message-ID: <28460.1062648515@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 04 Sep 2003 13:59:02 +1000 From: Mark.Andrews@isc.org Message-ID: <200309040359.h843x2Yf098584@bsdi.dv.isc.org> | RFC 1034 provided no way to express such a construct. It would | require meta data to be transmitted. Yes, I guess the closest currently possible would be a name with just a NULL RR - which is about as useful as a name with no RR's, given that NULL has no defined uses (or syntax) that I'm aware of. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 00:32: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 AAA04275 for ; Thu, 4 Sep 2003 00:32:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ulgC-000DJp-UZ for namedroppers-data@psg.com; Thu, 04 Sep 2003 04:25:08 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 19ulfg-000DDk-On for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 04:24:36 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 617E7139BC for ; Thu, 4 Sep 2003 04:24:06 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 In-Reply-To: Message from Robert Elz of "Thu, 04 Sep 2003 11:08:35 +0700." <28460.1062648515@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 04 Sep 2003 04:24:06 +0000 Message-Id: <20030904042406.617E7139BC@sa.vix.com> X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > | RFC 1034 provided no way to express such a construct. It would > | require meta data to be transmitted. > > Yes, I guess the closest currently possible would be a name with just > a NULL RR - which is about as useful as a name with no RR's, given that > NULL has no defined uses (or syntax) that I'm aware of. if it had a NULL RR then it wouldn't be empty. -- to unsubscribe send a message to namedroppers-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 Sep 4 00:33: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 AAA04336 for ; Thu, 4 Sep 2003 00:33:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uljN-000DpA-V9 for namedroppers-data@psg.com; Thu, 04 Sep 2003 04:28:25 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19ulis-000DlF-DL for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 04:27:54 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 19ulir-000PDi-3K for namedroppers@ops.ietf.org; Wed, 03 Sep 2003 21:27:53 -0700 Message-ID: <20030904011749.39495.qmail@cr.yp.to> References: <20030903150518.GA8460@csi.hu> <200309031541.h83FfVYf096721@bsdi.dv.isc.org> <20030903183204.GB8460@csi.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Date: 4 Sep 2003 01:17:49 -0000 From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify violating RFC 2119, section 6 X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > It's the reason that there is a 'name error' defined but no 'set error.' On the contrary. Caches apply NXDOMAIN to queries for any type under the same name, while they apply NODATA only to the same type. Your ``no data is no data'' comment fails to take cache effects into account. The packet format was badly designed, so NODATA is much more difficult to detect than NXDOMAIN, but this doesn't mean that NODATA is undefined; it simply means that the definition is complicated. Go read RFC 2308, or the BIND code, or cr.yp.to/djbdns/notes.html, or the dnscache code. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 00:49: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 AAA05489 for ; Thu, 4 Sep 2003 00:49:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ulxh-000GSt-LM for namedroppers-data@psg.com; Thu, 04 Sep 2003 04:43:13 +0000 Received: from [203.146.39.147] (helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 4.22) id 19ulx7-000GLM-4C for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 04:42:37 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h844eEV06336; Thu, 4 Sep 2003 11:40:15 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 In-Reply-To: <20030904042406.617E7139BC@sa.vix.com> References: <20030904042406.617E7139BC@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Sep 2003 11:40:14 +0700 Message-ID: <25432.1062650414@munnari.OZ.AU> X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Yes, of course, which is why I said "the closest currently possible", it almost achieves the status of being an empty name, in that it has no useful data, without actually being empty. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 00:54: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 AAA05997 for ; Thu, 4 Sep 2003 00:54:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19um3G-000HUp-S5 for namedroppers-data@psg.com; Thu, 04 Sep 2003 04:48:58 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19um3D-000HU3-L7 for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 04:48:55 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h844l9Yf098793; Thu, 4 Sep 2003 14:47:09 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309040447.h844l9Yf098793@bsdi.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-reply-to: Your message of "04 Sep 2003 01:17:49 GMT." <20030904011749.39495.qmail@cr.yp.to> Date: Thu, 04 Sep 2003 14:47:09 +1000 X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Edward Lewis writes: > > It's the reason that there is a 'name error' defined but no 'set error.' > > On the contrary. Caches apply NXDOMAIN to queries for any type under the > same name, while they apply NODATA only to the same type. Your ``no data > is no data'' comment fails to take cache effects into account. > > The packet format was badly designed, so NODATA is much more difficult > to detect than NXDOMAIN, but this doesn't mean that NODATA is undefined; > it simply means that the definition is complicated. Go read RFC 2308, or > the BIND code, or cr.yp.to/djbdns/notes.html, or the dnscache code. More that there was no RCODE for NODATA than the packet format was badly designed. I keep thinking about introducing a NODATA rcode along with a client signaling that it can be understood via EDNS. > ---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: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 08: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 IAA16925 for ; Thu, 4 Sep 2003 08:34:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ut7D-000IHY-Kz for namedroppers-data@psg.com; Thu, 04 Sep 2003 12:21:31 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19ut6r-000IET-Pl for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 12:21:09 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h84CI7YR021376 for ; Thu, 4 Sep 2003 08:18:15 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUCayTP; Thu, 4 Sep 03 08:17:54 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h849rC9T015229 for ; Thu, 4 Sep 2003 05:53:12 -0400 (EDT) Date: Thu, 4 Sep 2003 05:53:12 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify scope confusion In-Reply-To: <20030826033236.60412.qmail@cr.yp.to> Message-ID: References: <20030820100735.39120ccd.olaf@ripe.net> <20030826033236.60412.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_20,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > To the extent that wcard-clarify goes beyond issues > visible on the wire, it's violating section 6 of RFC 2119. DNSSEC makes these issues visible on the wire, making these clarifications necessary. Pre-DNSSEC, a unified understanding of wildcards was vastly less important -- so long as a zone behaved consistently, it didn't matter to clients how servers interpreted wildcards they found in zone files -- the clients never saw raw wildcards. DNSSEC, with its requirement for off-line signing, forces wildcard logic into the client -- even if the client doesn't do the actual synthesis, it has to be able to check it. That forces a unified definition, at least for those zones using DNSSEC. 1034's treatment of wilcards was, obviously, inadequate. These clarifications are vital to the DNSSEC specification effort. DNSSECbis is incomplete without them. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 09:43: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 JAA22081 for ; Thu, 4 Sep 2003 09:43:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uuGl-0004v6-N9 for namedroppers-data@psg.com; Thu, 04 Sep 2003 13:35:27 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19uuG9-0004mG-91 for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 13:34:49 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 42DBE50E; Thu, 4 Sep 2003 09:34:45 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id CE51F514 for ; Thu, 4 Sep 2003 09:34:44 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 617701 for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 09:31:44 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030904011749.39495.qmail@cr.yp.to> References: <20030903150518.GA8460@csi.hu> <200309031541.h83FfVYf096721@bsdi.dv.isc.org> <20030903183204.GB8460@csi.hu> <20030904011749.39495.qmail@cr.yp.to> Date: Thu, 4 Sep 2003 09:28:25 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wcard-clarify violating RFC 2119, section 6 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 1:17 +0000 9/4/03, D. J. Bernstein wrote: >Edward Lewis writes: >> It's the reason that there is a 'name error' defined but no 'set error.' > >On the contrary. Caches apply NXDOMAIN to queries for any type under the >same name, while they apply NODATA only to the same type. Your ``no data >is no data'' comment fails to take cache effects into account. > We're talking apples and oranges here. There's no 'set error' value return code defined, that's the context of the comment, and that is traced back to the time when names were all we queried for. You're right, there are set errors, but not as a return code value. You're right that I am not talking about caches, wild cards are not synthesized there. Do you feel that there should be a return code value defined for the condition in which a name/class matches but the desired set is absent? (This is out of scope for wild card, I'm just asking.) >The packet format was badly designed, so NODATA is much more difficult >to detect than NXDOMAIN, but this doesn't mean that NODATA is undefined; >it simply means that the definition is complicated. Go read RFC 2308, or >the BIND code, or cr.yp.to/djbdns/notes.html, or the dnscache code. The packet format could have been better, but it's not that bad. DNS has managed to work for the past upteen years and has been a big part of the growth of the Internet. You're right that there's room for improvement, especially when it comes to detecting when QNAME & QCLASS matched and QTYPE didn't. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 4 10:03: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 KAA23524 for ; Thu, 4 Sep 2003 10:03:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uubi-00095U-0C for namedroppers-data@psg.com; Thu, 04 Sep 2003 13:57:06 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19uubC-0008xR-PQ for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 13:56:34 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 29215425; Thu, 4 Sep 2003 09:56:34 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id C64C43FB for ; Thu, 4 Sep 2003 09:56:33 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 617729; Thu, 04 Sep 2003 09:53:33 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 4 Sep 2003 09:56:54 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: On wild cards Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk While I appreciate discussion of existence, the difficulty of detecting when an answer indicates no data is available, what this means for DNSSEC, and the general need of the DNS protocol to be overhauled with a jackhammer and backhoe, there are a few issues outstanding that aren't getting the attention they deserve. These issues are in Simon's recent message. He caught a few things in RFC 1034, section 4.3.3. that the wild card clarification conflicts. (Most importantly, these *are* issues dealing with the synthesis and treatment of wild cards.) Please take time to review those issues and decide if the document will change 1034, or will we rescind the proposed text? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 4 14:34: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 OAA12456 for ; Thu, 4 Sep 2003 14:34:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uyfi-0000R6-Tn for namedroppers-data@psg.com; Thu, 04 Sep 2003 18:17:30 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 19uyfC-0000Mx-Q4 for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 18:16:58 +0000 Received: (qmail 2367 invoked by uid 1016); 4 Sep 2003 18:17:19 -0000 Date: 4 Sep 2003 18:17:19 -0000 Message-ID: <20030904181719.2366.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify scope confusion References: <20030820100735.39120ccd.olaf@ripe.net> <20030826033236.60412.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sam Weiler writes: > DNSSEC, with its requirement for off-line signing, forces > wildcard logic into the client I agree that the semantics of wildcards in DNSSEC are a protocol issue. If wcard-clarify said ``The purpose of this document is to specify the semantics of wildcards sent to DNSSEC clients'' and didn't swerve into other issues, I wouldn't be complaining about it. But wcard-clarify isn't limited to this. For example, it also outlaws servers that support regular expressions. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 15:32: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 PAA17749 for ; Thu, 4 Sep 2003 15:32:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19uzj8-000Bad-I4 for namedroppers-data@psg.com; Thu, 04 Sep 2003 19:25:06 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19uziU-000BTX-Rl for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 19:24:27 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 9D40A546; Thu, 4 Sep 2003 15:24:23 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 28360360; Thu, 4 Sep 2003 15:24:23 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 620170; Thu, 04 Sep 2003 15:21:21 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030904181719.2366.qmail@cr.yp.to> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826033236.60412.qmail@cr.yp.to> <20030904181719.2366.qmail@cr.yp.to> Date: Thu, 4 Sep 2003 15:24:39 -0400 To: "D. J. Bernstein" From: Edward Lewis Subject: Re: wcard-clarify scope confusion Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:17 +0000 9/4/03, D. J. Bernstein wrote: >But wcard-clarify isn't limited to this. For example, it also outlaws >servers that support regular expressions. Can you suggest new wording to prevent outlawing "that?" By "that" I mean that I've been able to find any documentation (in the WG/mail list, draft, RFC) that describes how you would synthesize an answer from a regular expression. I'm not against it, it's an intriguing idea. It's just not been defined. By specifying "here's a wcard domain name" and "you can't escape it away" the draft isn't outlawing any other form of synthesis. By defining a wcard domain name label this makes it possible to transmit the synthesis via AXFR - which you pointed out. The escape rule isn't meant to say you must have escapes, but if you do...do it this way. (How would you transmit the synthesis rules from a master to secondary server?) My motivation behind writing the document was nestled in the question of how many NXT's would have to be returned given that there was wild card synthesized answers for which to account. In doing so, the concept of the closest encloser came up (as an outcome of the existence issue and 4.3.2). I would imagine that if you had another synthesis mechanism, you still would need to decide when it will be invoked, that is, if you assume a zone would have some statically defined names augmented by the rules. So, the same question would apply - how many NXT's. I just had a thought - perhaps you are referring to the prohibition of "labels-*-this" which would match "labels-1-this" and so on. 1034, in 4.3.3 does mention that names are of the form "*.", which I think rules out mid-label wild cards. (That is also the basis od Simon's comment that double-wild cards aren't allowed per 1034.) I'd imagine regular expression synthesis would mean you could have: [A-Z][^aeiou]\.* MX mailhost [a-z][aeiou]\.* MX spamhost I can see how this would work, my questioning of providing this is that it's getting a bit heavy on functionality (in the sense that A6 was) for such a basic core service as DNS. Also, how does this fit into a zone transfer? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 4 16:04: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 QAA19359 for ; Thu, 4 Sep 2003 16:04:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v0FB-000HJl-MH for namedroppers-data@psg.com; Thu, 04 Sep 2003 19:58:13 +0000 Received: from [129.9.80.165] (helo=fxshpr08.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.22) id 19v0Cc-000Gt3-8v for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 19:55:34 +0000 Received: (from uucp@localhost) by fxshpr08.extra.daimlerchrysler.com (8.12.8/8.9.0) id h84JpTiG020941 for ; Thu, 4 Sep 2003 15:51:29 -0400 (EDT) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAUZaG5O; Thu, 4 Sep 03 15:51:29 -0400 Received: from shconpr2-hme0.shdc.chrysler.com ([127.0.0.1]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003090415553023119 for ; Thu, 04 Sep 2003 15:55:30 -0400 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by shconpr2-hme0.shdc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003090415553032296 for ; Thu, 04 Sep 2003 15:55:30 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h84JtUQu021730 for ; Thu, 4 Sep 2003 15:55:30 -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 h84Jspp1017188 for ; Thu, 4 Sep 2003 15:54:51 -0400 (EDT) Message-ID: <3F57988B.8C96E987@daimlerchrysler.com> Date: Thu, 04 Sep 2003 15:54:51 -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: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 References: <200309040209.h8429NYf098200@bsdi.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org wrote: > > Not to be contrary, but I think the more _modern_ way to view it is that a > > DNS name is just a concatenated sequence of labels which forms a unique index > > into > > a DNS database. From that standpoint, the distinction between "terminal" and > > "nonterminal" really loses its meaning and it seems rather silly and quaint f > > or a > > query of an empty "nonterminal" node to return anything different than a quer > > y of > > an empty "terminal" node. Empty is empty. Period. Whatever negative-caching > > optimizations are theoretically possible as a result of the seemingly-inconsi > > stent > > empty-terminal-vs-empty-nonterminal response differentiation seem to me to be > > underutilized and not worth the confusion and the extra code and resources > > required to interpret such response variations. > > > > Obviously, the hierarchical structure of the DNS database is still important > > from > > a zone-delegation/referral standpoint. But as a *database*structure*, the > > hierarhical paradigm has long been superceded by relational and/or contextual > > paradigms. Maybe it's time to let it go... > > Kevin this isn't about the "modern way". This is about > clearing up any ambiguities in the definition. Those are not mutually exclusive goals. If we have a more-or-less equal choice of one interpretation or another, why not go with the one future administrators are more likely to find familiar and intuitive? > There are > lots of nameservers that follow RFC 1034 and support empty > nodes by returning NOERROR/NODATA. I never questioned that. What I questioned was whether there were any/many caching resolvers that actually use the NODATA response to "prune" the namespace so as to obviate future queries for subsidiary nodes (that's what I was alluding to by the term "negative-caching optimizations") for the duration of the negative cache entry. If no-one, or very few implementations, are actually using the optimization that has been offered, and the behavior is confusing and quirky and requires more programming logic to parse, let's clarify the spec to simplify the response behavior -- i.e. empty node -> NXDOMAIN, whether it's terminal or nonterminal -- and move on. -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 Thu Sep 4 18:33: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 SAA28436 for ; Thu, 4 Sep 2003 18:33:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v2Y3-000Gjq-CP for namedroppers-data@psg.com; Thu, 04 Sep 2003 22:25:51 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 19v2XP-000Gda-Rt for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 22:25:12 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 8C071707; Thu, 4 Sep 2003 18:25:11 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id D4E43291; Thu, 4 Sep 2003 18:25:10 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 620559; Thu, 04 Sep 2003 18:22:08 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3F57988B.8C96E987@daimlerchrysler.com> References: <200309040209.h8429NYf098200@bsdi.dv.isc.org> <3F57988B.8C96E987@daimlerchrysler.com> Date: Thu, 4 Sep 2003 18:25:29 -0400 To: Kevin Darcy From: Edward Lewis Subject: Re: wcard-clarify violating RFC 2119, section 6 Cc: Name Droppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:54 -0400 9/4/03, Kevin Darcy wrote: >Those are not mutually exclusive goals. If we have a more-or-less equal >choice of one interpretation or another, why not go with the one future >administrators are more likely to find familiar and intuitive? > ... > >If no-one, or very few implementations, are actually using the optimization >that has been offered, and the behavior is confusing and quirky and requires >more programming logic to parse, let's clarify the spec to simplify the >response behavior -- i.e. empty node -> NXDOMAIN, whether it's terminal or >nonterminal -- and move on. ... While it would be insane of me to defend the current definition DNS as an epitome of excellent engineering, let's keep in mind the scope and bounds of our work as a group. After a decade of beating my head against a pile of specifications and bloodied by the points of a thousand staples while trying to hammer out a workable DNSSEC definition, it is painfully obvious (to me) that DNS has some quirks, to put it nicely. The current WG has two main points of work, DNSSEC and LLMNR. For the group to ever hope of being successful (which is, "closed") we need to make sure we restrict ourselves to those two topics. wcard-clarify is written because of work in DNSSEC, not because there's a need to fix DNS per se. As far as whether we should use the new features (DNSSEC) to right old wrongs, I can say from experience that when you extend any system in a way not in keeping with the original spirit of the system - right or wrong - the extension is bound to fail. Exhibit A - RFC 2065. Exhibit B - RFC 2535. Exhibit C - the house I almost bought in Severna Park until I noticed the incredibly straight crack in the basement floor (paralleling the old foundation). Thus its apparent to me that we need to extend DNS within the lunacy of the current DNS. I applaud the brave souls who wish to charge off and redefine a naming system, one that fixes the wrongs in DNS, fixes the wrongs in X.509 and LDAP, one that would have let DCE choose one system and not four! (4!) naming systems in its middleware offering. (~10 years ago, a product of the OSF.) While you brave souls have a lot of previous work to build upon, remember that engineers of yore were just as bright as you and they didn't get it right, so it's not likely you will either. It's not a statement about you, it's that the problem is just plain hard. (And don't forget to measure deployment time in decades.) I'm not willing to commit to replacing DNS with a workable system. (I'd like to retire some day with career closure.) I'm not willing to again inflict pain on myself trying to extend a system that needed an adjustment to make the extension work. (Like never again buying a used car that had it's frame straightened.) I am willing to wind up extending a current system and, if I need to, declare failure when I find the foundation wasn't strong enough. This is why wcard-clarify is in front of us. To make sure the foundation of DNS is right for extension. This is why I think Simon's comments are the most important - he's questioning if the clarifications are really within line of the original foundation. This is why I'd rather not get into the rat hole of what a 'name error' is in a cache - that's not part of the synthesis problem. Let's resist the temptation to widen the scope of any clarification work. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 4 19:06: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 TAA00134 for ; Thu, 4 Sep 2003 19:06:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v34j-000NHo-8k for namedroppers-data@psg.com; Thu, 04 Sep 2003 22:59:37 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.22) id 19v34D-000NDs-5v for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 22:59:05 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5A93018D8 for ; Thu, 4 Sep 2003 18:58:33 -0400 (EDT) Date: Thu, 04 Sep 2003 18:58:33 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Wildcard Clarify In-Reply-To: <20030820100735.39120ccd.olaf@ripe.net> References: <20030820100735.39120ccd.olaf@ripe.net> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030904225833.5A93018D8@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Summary: this is important work and should go forward, but there are portions of it which could benefit from further work if the authors have the time and the WG so wills it. I think that the general intent of this doc is correct, and we badly need something in this space. The discussion of existance and so forth matches my understanding of how this is supposed to work, and the concept of "closest encloser" does indeed look very useful in attempting to document how the DNSSEC NXT/NSEC stuff should work. That said, some issues: Section 6.4 needs work. It's not at all obvious what action a name server should take upon encountering a wildcard DNAME RR during the lookup process: repeated use of the phrase "DNAME is a CNAME generator" doesn't answer this question. If the real answer is that we haven't got a clue what to do here, the doc should say so, and should state what one should do until we -do- acquire a clue. Sections 6.1 and 6.2 are also a bit weird. While the discussion of synthesized zones in these sections is interesting, it strikes me as either too much or too little: it's speculating about behavior that we don't understand, but not in enough detail to help us understand said behavior very well, and it seems to confound SOA RRs with a name server's knowledge of the boundaries of the authoritative zones it has loaded. Finally, these sections don't ever come out and say what a name server which -doesn't- implement zone synthesis should do with these types; since all of section 6 is about "special processing", it'd be good to describe what the processing rules for a normal authoritative server are for each of the special types. Last, with all due respect to the authors, and with the understanding that Ed and I have long-standing friendly disagreements on many stylistic issues, I found the document unnecessarily hard to read, and suspect that a good flossing with a copy of Strunk and White would make the document text a lot clearer. -- to unsubscribe send a message to namedroppers-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 Sep 4 19:59: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 TAA03398 for ; Thu, 4 Sep 2003 19:59:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v3tm-0005o7-Aj for namedroppers-data@psg.com; Thu, 04 Sep 2003 23:52:22 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19v3tg-0005nL-99 for namedroppers@ops.ietf.org; Thu, 04 Sep 2003 23:52:16 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h84NoqYf001407; Fri, 5 Sep 2003 09:50:53 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309042350.h84NoqYf001407@bsdi.dv.isc.org> To: Kevin Darcy Cc: Name Droppers From: Mark.Andrews@isc.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-reply-to: Your message of "Thu, 04 Sep 2003 15:54:51 -0400." <3F57988B.8C96E987@daimlerchrysler.com> Date: Fri, 05 Sep 2003 09:50:52 +1000 X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org wrote: > > > > Not to be contrary, but I think the more _modern_ way to view it is that > a > > > DNS name is just a concatenated sequence of labels which forms a unique i > ndex > > > into > > > a DNS database. From that standpoint, the distinction between "terminal" > and > > > "nonterminal" really loses its meaning and it seems rather silly and quai > nt f > > > or a > > > query of an empty "nonterminal" node to return anything different than a > quer > > > y of > > > an empty "terminal" node. Empty is empty. Period. Whatever negative-cachi > ng > > > optimizations are theoretically possible as a result of the seemingly-inc > onsi > > > stent > > > empty-terminal-vs-empty-nonterminal response differentiation seem to me t > o be > > > underutilized and not worth the confusion and the extra code and resource > s > > > required to interpret such response variations. > > > > > > Obviously, the hierarchical structure of the DNS database is still import > ant > > > from > > > a zone-delegation/referral standpoint. But as a *database*structure*, the > > > hierarhical paradigm has long been superceded by relational and/or contex > tual > > > paradigms. Maybe it's time to let it go... > > > > Kevin this isn't about the "modern way". This is about > > clearing up any ambiguities in the definition. > > Those are not mutually exclusive goals. If we have a more-or-less equal choic > e of > one interpretation or another, why not go with the one future administrators > are > more likely to find familiar and intuitive? > > > There are > > lots of nameservers that follow RFC 1034 and support empty > > nodes by returning NOERROR/NODATA. > > I never questioned that. What I questioned was whether there were any/many ca > ching > resolvers that actually use the NODATA response to "prune" the namespace so a > s to > obviate future queries for subsidiary nodes (that's what I was alluding to by > the > term "negative-caching optimizations") for the duration of the negative cache > entry. You can't use NODATA to prune namespace. You can theoretically use a NODATA response to a ANY to answer queries for other types. You can theoretically use NXDOMAIN to prune namespace provided you have RFC 1034's definition of NXDOMAIN (Name Error). > If no-one, or very few implementations, are actually using the optimization t > hat > has been offered, and the behavior is confusing and quirky and requires more > programming logic to parse, let's clarify the spec to simplify the response > behavior -- i.e. empty node -> NXDOMAIN, whether it's terminal or nonterminal > -- > and move on. empty terminal nodes DO NOT EXIST. If I give you a domain name a.b.c.d.e.f.g.example then the super domains are b.c.d.e.f.g.example, c.d.e.f.g.example, d.e.f.g.example, e.f.g.example, f.g.example, g.example example and ".". It is illogical to have a "sub-domain" of something that does not exist. This is what returning NXDOMAIN for empty nodes produces. > > -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: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 21:25: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 VAA07893 for ; Thu, 4 Sep 2003 21:25:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v5DM-000J0C-SC for namedroppers-data@psg.com; Fri, 05 Sep 2003 01:16:40 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 19v5CM-000Iql-3v for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 01:15:38 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h851Drd15843; Thu, 4 Sep 2003 21:13:58 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h851FlZ05334; Thu, 4 Sep 2003 21:15:52 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h851D9Uc027390; Thu, 4 Sep 2003 21:13:12 -0400 To: Miek Gieben cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-reply-to: Your message of "Wed, 03 Sep 2003 16:50:42 +0200." <20030903145042.GA25645@atoom.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 04 Sep 2003 21:13:09 -0400 Message-ID: <27388.1062724389@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-6.5 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Miek" == Miek Gieben writes: Miek> With 4. A resolver comes in, sees the RRset, get's the sig. *bam* Miek> unknown algorithm. Now what? Bad? Well actually no - it is just Miek> that the resolver doesn't know the algorithm. This should not lead Miek> to a situation were the zone drops from the Net. If that happens it Miek> is impossible to deploy new algorithms gradually on the Net. (This Miek> is the same as what happens in 3.) This is why context is important. That's why the stub resolver and application are important here. The answer as to what to do depends upon the consumer. I.e. the application. In all cases where we would say "bad", we need to actually say something more complicated to the application. ||ugh has called this property "quality" of the answer. Since different applications have different security requirements, they need to be able to make informed choices. Sure, lots won't, and you need a default for that. But that itself, is a system-admin defined choice. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP1fjJIqHRg3pndX9AQETZwP9ErVdXF8cpMULl3+sNoN7FEXHtLZohVg/ K0BsZyCxc5z9uGOXOtSnexWH75wwvYLYAUVMKggYutY+E2eogOeYv/o1Sqdd8Byx E4zktqvbZiO15V2DM5UT5Ynll1sajdI1AoPApqarKR0u37HTcjNeHwlFcwJYPCG9 utdkLvjMTko= =eY1j -----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 Thu Sep 4 21:57: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 VAA10027 for ; Thu, 4 Sep 2003 21:57:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v5mH-000P8y-2G for namedroppers-data@psg.com; Fri, 05 Sep 2003 01:52:45 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 19v5jo-000OgZ-Pn for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 01:50:12 +0000 Received: (qmail 58601 invoked by uid 1016); 5 Sep 2003 01:50:31 -0000 Date: 5 Sep 2003 01:50:31 -0000 Message-ID: <20030905015031.58600.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify violating RFC 2119, section 6 References: <200309040209.h8429NYf098200@bsdi.dv.isc.org> <3F57988B.8C96E987@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kevin Darcy writes: > If no-one, or very few implementations, are actually using the > optimization that has been offered, and the behavior is confusing and > quirky and requires more programming logic to parse, let's clarify the > spec to simplify the response behavior -- i.e. empty node -> NXDOMAIN, > whether it's terminal or nonterminal -- and move on. There are two separate proposals here: (1) Telling caches that they can't apply NXDOMAIN to subdomains. This is important, and appears to have already been done by RFC 2308. Existing caches already comply with this rule. New caches have to comply too, because many server installations generate (and will continue to generate) NXDOMAIN for empty nonterminals. (2) Telling servers that they have to use NXDOMAIN rather than NODATA for nonempty terminals, or in any other situation where both NXDOMAIN and NODATA work. I see no interoperability excuse for this; NXDOMAIN is, from a protocol perspective, at best a minor speedup. I chose NXDOMAIN because it simplified my code, not because Vixie claimed that it was required; others might choose NODATA for the same reason. Anyway, many existing installations use NXDOMAIN, and many others use NODATA. Neither proposal is tied to the definition of wildcards in DNSSEC. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 22:06:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10636 for ; Thu, 4 Sep 2003 22:06:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v5uL-0000gB-HR for namedroppers-data@psg.com; Fri, 05 Sep 2003 02:01:05 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 19v5uF-0000ek-Sh for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 02:00:59 +0000 Received: (qmail 67731 invoked by uid 1016); 5 Sep 2003 02:01:20 -0000 Date: 5 Sep 2003 02:01:20 -0000 Message-ID: <20030905020120.67730.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify scope confusion References: <20030820100735.39120ccd.olaf@ripe.net> <20030826033236.60412.qmail@cr.yp.to> <20030904181719.2366.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > How would you transmit the synthesis rules from a master to secondary > server? The standard answer to ``How do you transfer something that AXFR doesn't understand?'' is ``We replicate data with rsync, not AXFR.'' Are you aware that many modern servers can provide different answers to different clients? (``Client differentiation'' in tinydns; ``views'' in BIND 9.) Do you realize that the client-differentiation data * can't be transferred through AXFR, * can't be updated through DNSUPD, and * can't be secured with DNSSEC? Do you conclude (1) that this variability has to be outlawed, or (2) that AXFR, DNSUPD, and DNSSEC are behind the times? > Can you suggest new wording to prevent outlawing "that?" I just did: ``The purpose of this document is to specify the semantics of wildcards sent to DNSSEC clients.'' Of course, you also have to eliminate the portions of the document that stray outside this scope. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 22:31:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12123 for ; Thu, 4 Sep 2003 22:31:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v6H4-0004P0-Fp for namedroppers-data@psg.com; Fri, 05 Sep 2003 02:24:34 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 19v6Gw-0004Ny-C5 for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 02:24:26 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h852MfYf001843; Fri, 5 Sep 2003 12:22:41 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309050222.h852MfYf001843@bsdi.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wcard-clarify violating RFC 2119, section 6 In-reply-to: Your message of "05 Sep 2003 01:50:31 GMT." <20030905015031.58600.qmail@cr.yp.to> Date: Fri, 05 Sep 2003 12:22:41 +1000 X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Kevin Darcy writes: > > If no-one, or very few implementations, are actually using the > > optimization that has been offered, and the behavior is confusing and > > quirky and requires more programming logic to parse, let's clarify the > > spec to simplify the response behavior -- i.e. empty node -> NXDOMAIN, > > whether it's terminal or nonterminal -- and move on. > > There are two separate proposals here: > > (1) Telling caches that they can't apply NXDOMAIN to subdomains. This > is important, and appears to have already been done by RFC 2308. > Existing caches already comply with this rule. New caches have to > comply too, because many server installations generate (and will > continue to generate) NXDOMAIN for empty nonterminals. > > (2) Telling servers that they have to use NXDOMAIN rather than NODATA > for nonempty terminals, or in any other situation where both > NXDOMAIN and NODATA work. I see no interoperability excuse for > this; NXDOMAIN is, from a protocol perspective, at best a minor > speedup. I chose NXDOMAIN because it simplified my code, not > because Vixie claimed that it was required; others might choose > NODATA for the same reason. Anyway, many existing installations > use NXDOMAIN, and many others use NODATA. > > Neither proposal is tied to the definition of wildcards in DNSSEC. Actually it is. You need to decide which RCODE you are going to accept. RCODE=???? Question: foo.example A Authority: example SOA ... exampe SIG(SOA) a.example NXT bar.foo.example (proves foo.example is empty and exist). a.example SIG(NXT) > ---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: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 4 22:44: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 WAA12743 for ; Thu, 4 Sep 2003 22:44:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v6UY-0006b7-Mk for namedroppers-data@psg.com; Fri, 05 Sep 2003 02:38:30 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19v6U2-0006Uf-1m for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 02:37:58 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 6C4755FE; Thu, 4 Sep 2003 22:37:57 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id E784D5CD; Thu, 4 Sep 2003 22:37:56 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 621042; Thu, 04 Sep 2003 22:34:53 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030905020120.67730.qmail@cr.yp.to> References: <20030820100735.39120ccd.olaf@ripe.net> <20030826033236.60412.qmail@cr.yp.to> <20030904181719.2366.qmail@cr.yp.to> <20030905020120.67730.qmail@cr.yp.to> Date: Thu, 4 Sep 2003 22:38:13 -0400 To: "D. J. Bernstein" From: Edward Lewis Subject: Re: wcard-clarify scope confusion Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 2:01 +0000 9/5/03, D. J. Bernstein wrote: >Edward Lewis writes: >> How would you transmit the synthesis rules from a master to secondary >> server? > >The standard answer to ``How do you transfer something that AXFR doesn't >understand?'' is ``We replicate data with rsync, not AXFR.'' Fair 'nuff. What would help interoperability though is a specification of what's sent via rsync. (What if someone uses a UltraDNS master and a PowerDNS slave?) Note that I didn't use AXFR in my question. That was on purpose - I didn't think you would transfer the rules in that format. I'm curious what you do (or plan to) use to transfer the synthesis rules. >Are you aware that many modern servers can provide different answers to ... >Do you conclude (1) that this variability has to be outlawed, or (2) >that AXFR, DNSUPD, and DNSSEC are behind the times? No problem with any of that functionality/variability. Just so long as if interoperability is desired, the protocol for that is documented. I realize you are using these as examples, but I'm trying to stick to the rules for answer synthesis. (I really don't have the time to dedicate to try and work on regular expression synthesis. So if it seems that I drop it at some point, it's not like I'm "playing" along. I feel that there's nothing wrong with pursuing it, but it's beyond my needs hence my willingness to contribute time towards it. I'm not opposed to it in principle.) As far as (2), AXFR was designed for a simpler time. DNSUPD is due for review sometime, and DNSSEC is once again being defined. Maybe they are behind the times. But still, none of them were designed for regular expression based synthesis. > >> Can you suggest new wording to prevent outlawing "that?" > >I just did: ``The purpose of this document is to specify the semantics >of wildcards sent to DNSSEC clients.'' Of course, you also have to >eliminate the portions of the document that stray outside this scope. Well, I'd remove DNSSEC from that. Do you have in mind specific portions of the document that stray beyond the scope? (I know you've complained about the quote from 1034 that reappears in the draft, but it reappears only to give the context of another change. BTW, is that perhaps the only place the document strays?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 4 22:48: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 WAA12986 for ; Thu, 4 Sep 2003 22:48:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v6am-0007dJ-Qa for namedroppers-data@psg.com; Fri, 05 Sep 2003 02:44:56 +0000 Received: from [129.9.80.165] (helo=fxshpr08.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 4.22) id 19v6a1-0007Wx-3X for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 02:44:09 +0000 Received: (from uucp@localhost) by fxshpr08.extra.daimlerchrysler.com (8.12.8/8.9.0) id h852e351023698 for ; Thu, 4 Sep 2003 22:40:03 -0400 (EDT) Received: from nodnsquery(129.9.147.104) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAA8EaisU; Thu, 4 Sep 03 22:40:03 -0400 Received: from shconpr2-hme0.shdc.chrysler.com ([127.0.0.1]) by shconpr2-hme0.shdc.chrysler.com (Mail-Gear 2.0.0 bld 66) with SMTP id M2003090422440402707 for ; Thu, 04 Sep 2003 22:44:04 -0400 Received: from odmrspr2-hme0.oddc.chrysler.com ([53.231.2.113]) by shconpr2-hme0.shdc.chrysler.com (SAVSMTP 3.1.1.32) with SMTP id M2003090422440507311 for ; Thu, 04 Sep 2003 22:44:05 -0400 Received: from wokcdts1.is.chrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by odmrspr2-hme0.oddc.chrysler.com (8.12.8/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id h852i5Qu015632 for ; Thu, 4 Sep 2003 22:44:05 -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 h852hPp1019287 for ; Thu, 4 Sep 2003 22:43:25 -0400 (EDT) Message-ID: <3F57F84D.99D7C68@daimlerchrysler.com> Date: Thu, 04 Sep 2003 22:43:25 -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: Name Droppers Subject: Re: wcard-clarify violating RFC 2119, section 6 References: <200309042350.h84NoqYf001407@bsdi.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_XM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark.Andrews@isc.org wrote: > > Mark.Andrews@isc.org wrote: > > > [Are] there any/many caching > > resolvers that actually use the NODATA response to "prune" the namespace so a > > s to > > obviate future queries for subsidiary nodes (that's what I was alluding to by > > the > > term "negative-caching optimizations") for the duration of the negative cache > > entry. > > You can't use NODATA to prune namespace. You can theoretically > use a NODATA response to a ANY to answer queries for other types. > > You can theoretically use NXDOMAIN to prune namespace provided > you have RFC 1034's definition of NXDOMAIN (Name Error). Sorry, I said that the wrong way around -- I meant NXDOMAIN-based pruning. The question still stands: do any extant implementations you know of actually use such NXDOMAIN responses to negatively cache subdomains? Does BIND? > > If no-one, or very few implementations, are actually using the optimization t > > hat > > has been offered, and the behavior is confusing and quirky and requires more > > programming logic to parse, let's clarify the spec to simplify the response > > behavior -- i.e. empty node -> NXDOMAIN, whether it's terminal or nonterminal > > -- > > and move on. > > empty terminal nodes DO NOT EXIST. > If I give you a domain name a.b.c.d.e.f.g.example then the > super domains are b.c.d.e.f.g.example, c.d.e.f.g.example, > d.e.f.g.example, e.f.g.example, f.g.example, g.example > example and ".". > It is illogical to have a "sub-domain" > of something that does not exist. This is what returning > NXDOMAIN for empty nodes produces. Well, I'll try to make this short, since as others have pointed out, this discussion is wandering somewhat astray of the I-D in question. Suffice it to say, there are only 2 reasons why a resolver would care about the tree structure of DNS: 1) in order to follow referrals to get its answer, or 2) because it might, in the context of optimizing its negative caching, be smart enough to "prune" the namespace tree if it gets a particular RCODE, so as to obviate subsequent forwarded queries for descendant nodes, for the duration of that negative cache entry. But, if we assume that the resolver has already made it to an authoritative nameserver for the zone in question (therefore reason #1 for caring about the tree structure doesn't apply) and if reason #2 doesn't apply (as far as I know, no-one has identified any resolver implementation that uses NXDOMAIN-pruning to its advantage), what is the value to the resolver of having two different possible response codes to the query of an empty node? It doesn't care about the tree structure. Having multiple possible responses for essentially the same scenario just makes response processing more convoluted and inefficient, not to mention being less intuitive to us humans. - 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 Thu Sep 4 23:17: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 XAA14660 for ; Thu, 4 Sep 2003 23:17:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v71o-000CGn-2y for namedroppers-data@psg.com; Fri, 05 Sep 2003 03:12:52 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19v712-000CBK-J2 for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 03:12:04 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 2C1D2575; Thu, 4 Sep 2003 23:12:04 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id AA94851E; Thu, 4 Sep 2003 23:12:03 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 621094; Thu, 04 Sep 2003 23:09:00 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <3F57F84D.99D7C68@daimlerchrysler.com> References: <200309042350.h84NoqYf001407@bsdi.dv.isc.org> <3F57F84D.99D7C68@daimlerchrysler.com> Date: Thu, 4 Sep 2003 23:12:22 -0400 To: Kevin Darcy From: Edward Lewis Subject: Re: wcard-clarify violating RFC 2119, section 6 Cc: Name Droppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 22:43 -0400 9/4/03, Kevin Darcy wrote: >Well, I'll try to make this short, since as others have pointed out, this >discussion is wandering somewhat astray of the I-D in question. Amen. ;) >what is the value to the resolver of having two different possible >response codes to the query of an empty node? It doesn't care about the tree >structure. Having multiple possible responses for essentially the >same scenario >just makes response processing more convoluted and inefficient, not to mention >being less intuitive to us humans. Because going through the process of fixing this is worse that what we have, that's the best excuse I can come up with. That's my story and I'm sticking to it. I agree it's inane to have multiple ways to say "no" but we have quite a long history of it. Maybe once we get to authenticated denial of existence a lot will be cleaned up, because there will be a record in the answer that says "no." When that happens, we will still have name errors and non-name errors, but at least we'll have something in the authority section. (Unless it's just telling us that there's no DS at an existing delegation.) BTW, in my day job, I'm testing for lameness. I'm getting some responses that have these settings - aa = 0, ra = 0, rcode = 0, an/ns/adcount = 0/0/0 - as nearly empty a response as I can can imagine, 1's-wise. (The query has rd=0, and the query goes to an alleged authoritative server, asking for the SOA RR.) I've been scratching my head on this and guess it's a type 3 "no data" answer from RFC 2308 - although it's lacking an aa bit. If ancount was > 0, it'd be a classic referral. If aa=1, it'd be a classic no error but no data. As it stands, it looks like a negative answer from a cache that won't do recursion for me. I suppose. I can't say it's an illegal answer from the RFCs, but it leaves me guessing as to what is wrong. DNS is puzzling...I agree...but it's "our" DNS. (As in, like that weird uncle in the family.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 5 01:14: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 BAA21485 for ; Fri, 5 Sep 2003 01:14:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v8l9-0003JO-79 for namedroppers-data@psg.com; Fri, 05 Sep 2003 05:03:47 +0000 Received: from [203.146.39.147] (helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 4.22) id 19v8kX-0003CQ-1I for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 05:03:09 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8552Ut26394; Fri, 5 Sep 2003 12:02:31 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify scope confusion In-Reply-To: <20030905020120.67730.qmail@cr.yp.to> References: <20030905020120.67730.qmail@cr.yp.to> <20030820100735.39120ccd.olaf@ripe.net> <20030826033236.60412.qmail@cr.yp.to> <20030904181719.2366.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Sep 2003 12:02:30 +0700 Message-ID: <13679.1062738150@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 5 Sep 2003 02:01:20 -0000 From: "D. J. Bernstein" Message-ID: <20030905020120.67730.qmail@cr.yp.to> | The standard answer to ``How do you transfer something that AXFR doesn't | understand?'' is ``We replicate data with rsync, not AXFR.'' But you're also on record (and I agree with this) as claimimg that the IETF should never have standardised a local implementation detail (the master file format), which in conjunction with the above, means that you no longer have interoperable servers - only servers that have the same implementation (since rsync just synchronises an array of anonymous bytes) can possibly agree on what a zone actually contains. We need either a standard format to transfer, or a standard transfer method. 1034/5 gave us both (so the standard transfer method could be used, or some other method, and the data would have the same meaning). | Are you aware that many modern servers can provide different answers to | different clients? | Do you conclude (1) that this variability has to be outlawed, Yes, it should - at least in the sense that it must be treated as a non-standard extension, and that people doing that need to be aware of the problems they are causing for themselves (including not being able to just use any random two server implementations - which is one of the more minor problems). The doc needs to define wildcards as exchanged using AXFR, which is the only currently viable method of getting data between two different server implementations that can really be expected to work (there have been two many local improvements added, and straight out implementation bugs, for master file formatted file copy via another means to remain viable). To do that, it needs to define the semantics of wildcards, so the receiving server knows exactly what should be done with them - for which their implications for dnssec seem to be one of the more important issues. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 5 01:27:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21706 for ; Fri, 5 Sep 2003 01:27:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v94y-0006MC-Ow for namedroppers-data@psg.com; Fri, 05 Sep 2003 05:24:16 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19v94c-0006Hq-Ms for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 05:23:54 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h854q2S17559; Thu, 4 Sep 2003 21:52:03 -0700 Date: Thu, 4 Sep 2003 21:52:02 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org cc: erik.guttman@sun.com Subject: LLMNR Issue 46: Retransmission Behavior Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 46: Retransmission behavior Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: >For each UNIQUE resource record in a given interface's configuration, >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. How many LLMNR queries? What interval? How long after the query (or queries) may it start issuing responses for that name? [BA] UNIQUEness verification is handled similarly to any other query, as specified in Section 2.6. What about tie-breaking in the event of simultaneous startup (e.g. when power is restored after an outage)? [BA] The draft does not specify what is done in the event of a name conflict. In general, automatic name change may be neither possible nor desirable. -- to unsubscribe send a message to namedroppers-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 Sep 5 01:28: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 BAA21733 for ; Fri, 5 Sep 2003 01:28:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v95j-0006SL-Vp for namedroppers-data@psg.com; Fri, 05 Sep 2003 05:25:03 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19v95W-0006Pz-O3 for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 05:24:50 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h854qxP17609 for ; Thu, 4 Sep 2003 21:52:59 -0700 Date: Thu, 4 Sep 2003 21:52:59 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 45: Handling of Unqualified Names Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 45: Handling of Unqualified Names Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: >Today, with the rise of home networking, there are an increasing number >of ad-hoc networks operating without a Domain Name System (DNS) server. I think this is side-stepping the real issue. The real issue is: >Today, with the rise of home networking, there are an increasing number >of home users who do not have ownership of any part of the name space >in which they can assign names. The whole section talking about "unqualified names" seems to be skirting around this issue without being willing to face it head-on and tackle it. Section 3.1 says: >3.1. Unqualified names > >The same host MAY use LLMNR queries for the resolution of unqualified >host names, and conventional DNS queries for resolution of other DNS >names. > >If a name is not qualified and does not end in a trailing dot, for the >purposes of LLMNR, the implicit search order is as follows: > >[1] Request the name with the current domain appended. >[2] Request just the name. You can't "request just the name". There is no way to represent an unqualified name ("no trailing dot") in the DNS packet format. What you mean is: >[1] Request the name with the current domain appended. >[2] Request the name with the root domain (".") appended. What this means is that if a home user calls their TV "tv", and their FM radio receiver "fm", and their CD player "cd", their computer is going to be sending queries for the TLDs "tv.", "fm." and "cd." (Tuvalu, Federal State of Micronesia, and Democratic Republic of the Congo, respectively.) This seems like it invites chaotic uncontrolled pollution of the top-level name space. [BA] I assume you are referring to DNS queries for "tv." Presumably there is no harm in allowing LLMNR queries for this. The draft allows a host to resolve queries for unqualified names only via LLMNR, so this can be avoided. Are you suggesting that this behavior be recommended? Furthermore, because there is no way to represent an unqualified name in the DNS packet format, there is also no way to represent an unqualified name on the right-hand-side of a PTR, CNAME or SRV record. This means that if you do a LLMNR query for an SRV record with an "unqualified" name, what you get back is an SRV record containing a target host name that you can't use with LLMNR because it's not an "unqualified" name. [BA] Agreed. This should be fixed. >3.1. Unqualified names > >The same host MAY use LLMNR queries for the resolution of unqualified >host names Who makes the choice offered by that "MAY"? User? OS vendor? Application writer? [BA] The LLMNR implementation. >If a name is not qualified and does not end in a trailing dot, What does that mean? Do "fully qualified" and "ends in a trailing dot" mean the same thing, or is there a difference? -- to unsubscribe send a message to namedroppers-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 Sep 5 01:30: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 BAA21780 for ; Fri, 5 Sep 2003 01:30:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v97r-0006n6-3i for namedroppers-data@psg.com; Fri, 05 Sep 2003 05:27:15 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19v97o-0006mc-Qz for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 05:27:13 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h854tLM17772; Thu, 4 Sep 2003 21:55:21 -0700 Date: Thu, 4 Sep 2003 21:55:21 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org cc: erik.guttman@eng.sun.com Subject: Proposed Resolution to Issue 46: Retransmission Behavior Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 46 is enclosed below. The proposed fix is as follows: Change Section 2.6 from: "2.6. Retransmissions In order to avoid synchronization, LLMNR queries and responses are delayed by a time uniformly distributed between 0 and 200 ms. If an LLMNR query sent over UDP is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) based on the last response received, on a per-query basis. The algorithms described in [RFC2988] (including exponential backoff) are suggested, with a minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer." To: "2.6. Retransmissions In order to avoid synchronization, LLMNR queries and responses are delayed by a time uniformly distributed between 0 and 200 ms. If an LLMNR query sent over UDP is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) based on the last response received for a query, on a per-interface basis. The algorithms described in [RFC2988] are suggested, with a minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer." ------------------------------------------------------------------------ Issue 46: Retransmission behavior Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: >For each UNIQUE resource record in a given interface's configuration, >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. How many LLMNR queries? What interval? How long after the query (or queries) may it start issuing responses for that name? [BA] UNIQUEness verification is handled similarly to any other query, as specified in Section 2.6. What about tie-breaking in the event of simultaneous startup (e.g. when power is restored after an outage)? [BA] The draft does not specify what is done in the event of a name conflict. In general, automatic name change may be neither possible nor desirable. -- to unsubscribe send a message to namedroppers-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 Sep 5 02:13:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04817 for ; Fri, 5 Sep 2003 02:13:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19v9kH-000D8P-0M for namedroppers-data@psg.com; Fri, 05 Sep 2003 06:06:57 +0000 Received: from [203.146.39.147] (helo=delta.cs.mu.OZ.AU) by psg.com with esmtp (Exim 4.22) id 19v9je-000D49-7C for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 06:06:18 +0000 Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8564et26536; Fri, 5 Sep 2003 13:04:43 +0700 (ICT) From: Robert Elz To: Bernard Aboba cc: namedroppers@ops.ietf.org, erik.guttman@eng.sun.com Subject: Re: Proposed Resolution to Issue 46: Retransmission Behavior In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Sep 2003 13:04:40 +0700 Message-ID: <14401.1062741880@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 4 Sep 2003 21:55:21 -0700 (PDT) From: Bernard Aboba Message-ID: | The text of Issue 46 is enclosed below. The proposed fix is as follows: | To: | | | "2.6. Retransmissions | | In order to avoid synchronization, LLMNR queries and responses are | delayed by a time uniformly distributed between 0 and 200 ms. I know that sentence isn't what is being proposed to be changed, but while this section is being worked on, I would suggest that it should be - not any kind of substantive change, just wording. That is, I don't think it makes any sense to have *a* time that is uniformly distributed, I don't think that makes either grammatical or mathematical sense. What I think is the intent is to have the delays selected by various queries and responses form a uniform distribution, but that's between difficult and impossible to specify or enforce. All that's needed is to require a random selection of the delay value in the 0..200 ms interval, and then we can rely upon the properties of random numbers to assume that the distribution of delays will turn out to be uniform. So In order to avoid synchronization, LLMNR queries and responses are delayed by a time randomly selected from the interval 0 to 200ms. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 5 10:15: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 KAA25503 for ; Fri, 5 Sep 2003 10:15:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19vHE8-000D1S-JN for namedroppers-data@psg.com; Fri, 05 Sep 2003 14:06:16 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 19vHE4-000D1E-QW for namedroppers@ops.ietf.org; Fri, 05 Sep 2003 14:06:12 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1F86A139CB for ; Fri, 5 Sep 2003 14:05:42 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify scope confusion In-Reply-To: Message from Edward Lewis of "Thu, 04 Sep 2003 22:38:13 -0400." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 05 Sep 2003 14:05:42 +0000 Message-Id: <20030905140542.1F86A139CB@sa.vix.com> X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >The standard answer to ``How do you transfer something that AXFR doesn't > >understand?'' is ``We replicate data with rsync, not AXFR.'' > > Fair 'nuff. no, it's really not. if something can't fit in the axfr protocol then it really is not dns data, but rather some kind of metadata outside the dns which happens to be needed to make a given implementation do the right thing. i liken this to "active directory" which likewise won't fit into axfr in some cases due to the non-dns data that their system also needs. -- to unsubscribe send a message to namedroppers-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 Sep 6 12: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 MAA23745 for ; Sat, 6 Sep 2003 12:51:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19vg33-000HSY-64 for namedroppers-data@psg.com; Sat, 06 Sep 2003 16:36:29 +0000 Received: from [17.254.0.51] (helo=mail-out2.apple.com) by psg.com with esmtp (Exim 4.22) id 19vg1p-000HLS-KM for namedroppers@ops.ietf.org; Sat, 06 Sep 2003 16:35:13 +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 h86GZBiZ003039 for ; Sat, 6 Sep 2003 09:35:11 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sat, 6 Sep 2003 09:34:45 -0700 Received: from [17.219.195.26] ([17.219.195.26]) by scv2.apple.com (8.12.9/8.12.9) with SMTP id h86GYxWI004689 for ; Sat, 6 Sep 2003 09:35:02 -0700 (PDT) Message-Id: <200309061635.h86GYxWI004689@scv2.apple.com> Subject: Re: LLMNR interoperability with Rendezvous? Date: Sat, 6 Sep 2003 09:35:09 -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=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >Going back to our proposal, you providing us 2 lists. We now have 1 item >and we like to make sure: > >- Is this 1 item the complete list of issues previously discussed and > that need to be reviewed? I am not aware of any other show-stopping incompatibility between Apple Rendezvous and LLMNR, but I do not have an implementation of LLMNR to test with. Perhaps one of the LLMNR implementers could test their code against OS X and report whether it works? One area that I think is currently weakest in LLMNR, is the issue of "unqualified names". The dilemma is that from one point of view, all DNS names are fully qualified, and from another, almost none of them are: * All names are fully qualified: When you actually try write the code, you find that all names in DNS packets are fully qualified. This is something that is not neccessarily apparent to someone whose only interaction with DNS until now has been on the user-interface side -- i.e. writing zone files for BIND, but not writing the code that puts that data in packets. Zone files can have unqualified names and often do. DNS packets cannot. * Almost all names are *not* fully qualified: On the user-interface side, almost no one puts the trailing dot at the end of names. Not in email addresses, not in URLs, not in command-line programs like telnet, ssh, ftp, etc. Even if you, as a user, are diligent and put the trailing dot, almost all "A HREF" links on web page do not, so the resolver library on your computer is constantly being bombarded with unqualified names. This leads LLMNR to the following dilemma: Under the current rules, almost *every* name entered by a user or encountered in a URL is a legitimate candidate for LLMNR resolution. The only names that are *not* candidates for LLMNR resolution are the ones *received* as replies to LLMNR queries for CNAME, PTR, SRV, etc. This seems backwards. The only thing LLMNR doesn't work with is itself! >- Is the list of 'new items' an empty list? > >We proposed the process so that the working group can make an informed >decision, based on the amount of things that need to be revisited, if >we need to go back and re-argue the issue. > >No hidden surprises further down the road ;-) ? The base idea in Apple Rendezvous and LLMNR is the same -- send DNS-format queries via multicast. Building on that base, Apple Rendezvous adds a bunch of capabilities. There is a spectrum of compatibility here, from "working" (which is what I believe we have now, aside from the TTL issue) to "working well", to "full feature parity". I am quite confident that the more ambitious features of Apple Rendezvous will be considered far too novel to be accepted by this working group. Others will fall somewhere in the middle of the spectrum. Implementing all of the optional parts is not necessary for interoperability. Using TCP as an analogy, a good example of what I'm talking about is things like slow start, fast retransmit, fast recovery, etc. A device that doesn't implement these things may not work as well as a device that does, but it still interoperates with a device that does. To be clear, I have no intention of trying to sell this WG on the idea of adopting every last one of the esoteric features of Apple Rendezvous, such as: * Efficiently handling the case where a query may elicit responses from a hundred or more different peers. * Known-answer suppression -- when a query is retransmitted, the ability to avoid the same hundred hosts answering over and over again. * Allowing multiple questions in a single packet, so that a batch of ten questions may be sent as a single packet instead of ten separate multicasts. The semantics of this at the receiver treats the query packet exactly as if it were the same as ten separate query packets each containing just a single question. * Name-space management -- informing users when two machines are trying to use the same name, and assisting the user in the process of picking a new one. * Tie-breaking when multiple machines are powered on simultaneously. * Support of sleep proxy server for power management. * The option to request responses by multicast or unicast, at the requester's discretion. Multicast responses may seem to increase the traffic load because every host sees the response as well as the query, but in fact experimental measurement shows that it does the opposite. Multicast responses allow other machines to suppress their own queries, because they know that if there is an answer to the query, they will see it, and correspondingly, if they don't see an answer to the query, that means there isn't one, because if there was, they would have seen it. If I see you do a query and I don't see any answer, then I don't need to repeat the same query myself -- there's no reason to believe that my attempt to elicit a response is any more likely to be successful than yours. So, when responses are multicast, everyone pays the cost of receiving the response, but then they save by *not* having to pay the cost of receiving all the multicast queries which are then subsequently suppressed. In summary, instead of ten multicast queries and ten unicast responses on the network, you get one multicast query and one multicast response. This is a net win. * And so on... None of this is secret. All of this (as of June) is described in In addition, all of the source code is open. Anyone can check out the source code from the Apple CVS server and see every change, every branch, every tag, every checkin comment, exactly the same as the engineers inside the company. The code is a little ahead of draft-02 right now, but we'll be updating the draft to catch up as soon as we get some time after OS X 10.3 ships. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Sep 7 18:01: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 SAA11931 for ; Sun, 7 Sep 2003 18:01:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19w7NY-0007d0-QC for namedroppers-data@psg.com; Sun, 07 Sep 2003 21:47:28 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.22) id 19w7N0-0007Zx-O7 for namedroppers@ops.ietf.org; Sun, 07 Sep 2003 21:46:54 +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 h87LkrG23129 for ; Sun, 7 Sep 2003 23:46:53 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h87Lkqm06695 for ; Sun, 7 Sep 2003 23:46:52 +0200 (MEST) Message-Id: <200309072146.h87Lkqm06695@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: On wild cards In-reply-to: Your message of "Thu, 04 Sep 2003 09:56:54 EDT." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6690.1062971210.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Sun, 07 Sep 2003 23:46:52 +0200 From: Peter Koch X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ed Lewis wrote: > These issues are in Simon's recent message. He caught a few things > in RFC 1034, section 4.3.3. that the wild card clarification > conflicts. (Most importantly, these *are* issues dealing with the > synthesis and treatment of wild cards.) Please take time to review > those issues and decide if the document will change 1034, or will we > rescind the proposed text? wildcards are counter intuitive enough and there's little use for them today anyway. I've never seen multi-wild cards in the wild (pun intended) and didn't miss them so far. Multi-wild cards are not really that general, since the name has to start with a '*' anyway (i.e. it's still not allowed to define "www.*.example.com", although a certain group of people would love this) and there's enough space for ambiguity left (for example, how is "sub.sub.sub.sub.example" matched against "*.sub.*.example"?). So, although you put really some brain cycles into appendix A I'd rather see a clarification that translates "should not" as in RFC 1034 into "MUST NOT" as of today. I do not, however, understand why a cache shouldn't remember a response to a "wildcard" (i.e. "*.") query. Probably that was meant to discourage synthesis of responses by (non-authoritative) caches. Wildcard synthesis should of course only be performed by an authoritative server. -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 Sun Sep 7 18:15: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 SAA14132 for ; Sun, 7 Sep 2003 18:15:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19w7jL-0009Tg-6T for namedroppers-data@psg.com; Sun, 07 Sep 2003 22:09:59 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.22) id 19w7i2-0009Lv-As for namedroppers@ops.ietf.org; Sun, 07 Sep 2003 22:08:38 +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 h87M8bG23939 for ; Mon, 8 Sep 2003 00:08:37 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h87M8au06781 for ; Mon, 8 Sep 2003 00:08:36 +0200 (MEST) Message-Id: <200309072208.h87M8au06781@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: DNSEXT WGLC: Wildcard Clarify In-reply-to: Your message of "Wed, 20 Aug 2003 10:07:35 +0200." <20030820100735.39120ccd.olaf@ripe.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6777.1062972515.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 08 Sep 2003 00:08:36 +0200 From: Peter Koch X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Please read the document, send in motivated statements of support, > opposition, clarifications &c. This protocol is on standards track, > if you disagree with that please speak up and motivate. I agree with the main direction of the document and support putting it onto standards track. However, the current version 01 of this draft is not ready for submission to the IESG. > Another reason this clarification is needed is to answer questions > regarding authenticated denial of existence, a service introduced in the > DNS Security Extensions [RFC 2535]. Prior to the work leading up to this > document, it had been feared that a large number of proof records (NXTs) > might be needed in each reply because of the unknown number of potential > wild card domains that were thought to be applicable. One outcome of this > fear is a now discontinued document solving a problem that is now known > not to exist. I.e., this clarification has the impact of defending against > unwarranted protocol surgery. It is not "yet another" effort to just > rewrite the early specifications for the sake of purity. Speaking of fears, I fear that the neutral reader in a year will be confused by this paragraph. Just delete it. > - Implications of a wild card domain name owning any of the following > resource record sets: DNAME [RFC 2672], CNAME, NS, and SOA s/sets/types/ in this case. In various other places this document uses the term "resource record set" or "resource set". For the sake of consistency (and brevity) that should just be "RRSet". This was defined by RFC 2181 which should be added to the normative reference list. > The following queries would be synthesized from the wild card: s/following queries/responses to the following queries/ > QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN > because _tcp.host1.example. exists (without data) > QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN > because host2.example. exists (without data) Maybe I got the "closest encloser" wrong, but why is the reason different in these two cases? > RFC1034's wording is to be clarified by adding the following paragraph: There may have bee precedents and it's clear to me what should be achieved, but since noone is going to maintain the amended version of 1034, this wording may be misleading (hey, we're *no* lawyers :-) > NS RR set. At the delegating server, the NS RR set is not authoritative, There's no "the delegating server". s/At the delegating server/In the delegating zone/; > zone." In this usage, a domain name is the root of a domain, not the entire > domain. The domain's root point is said to "exist in a zone" if the zone Now, what's a domain? I'd rather use the term apex or something similar here. > the authority, then a referral is given, possibly one indicating lameness. You mean, the referral than turns out to be lame? > Is it not a protocol error to have a NS RR owned by a wild card domian name, > complimentary to the case of a SOA RR. However, for this to work, an Now, is it an error or is it none - as inthe case of SOA? Minor nits to be sent to the author in private. -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 Mon Sep 8 10:01: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 KAA20674 for ; Mon, 8 Sep 2003 10:01:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wMQN-000NUB-9E for namedroppers-data@psg.com; Mon, 08 Sep 2003 13:51:23 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19wMPc-000NP3-25 for namedroppers@ops.ietf.org; Mon, 08 Sep 2003 13:50:36 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id D3CBA448; Mon, 8 Sep 2003 09:50:34 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 66A00423; Mon, 8 Sep 2003 09:50:34 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 629318; Mon, 08 Sep 2003 09:47:15 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200309072146.h87Lkqm06695@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200309072146.h87Lkqm06695@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 8 Sep 2003 09:40:05 -0400 To: Peter Koch From: Edward Lewis Subject: Re: On wild cards Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:46 +0200 9/7/03, Peter Koch wrote: >wildcards are counter intuitive enough and there's little use for them >today anyway. I've never seen multi-wild cards in the wild (pun intended) >and didn't miss them so far. Multi-wild cards are not really that general, >since the name has to start with a '*' anyway (i.e. it's still not allowed >to define "www.*.example.com", although a certain group of people would love >this) and there's enough space for ambiguity left (for example, how is >"sub.sub.sub.sub.example" matched against "*.sub.*.example"?). So, although >you put really some brain cycles into appendix A I'd rather see a >clarification >that translates "should not" as in RFC 1034 into "MUST NOT" as of today. No argument at all about multi-wild cards being "perverse" (to borrow the words of another person in private email), and the brain cycles would have been lost to beer anyway. But the question is - if we say "MUST/SHOULD NOT" what are the implications? Do we refuse to load a zone into the master if such a name is found? Do we drop an AXFR connection if one is found (and I do mean an "AXFR")? (Or IXFR?) What if the name is in a dynamic update? (An issue for RFC2136++.) >I do not, however, understand why a cache shouldn't remember a response >to a "wildcard" (i.e. "*.") query. Probably that was meant to >discourage synthesis of responses by (non-authoritative) caches. Wildcard >synthesis should of course only be performed by an authoritative server. I agree, how does the WG want to proceed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 8 10:01: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 KAA20690 for ; Mon, 8 Sep 2003 10:01:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wMRY-000NaQ-RE for namedroppers-data@psg.com; Mon, 08 Sep 2003 13:52:36 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 19wMPc-000NPF-SE for namedroppers@ops.ietf.org; Mon, 08 Sep 2003 13:50:36 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id D89D564F; Mon, 8 Sep 2003 09:50:35 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 2ED82632 for ; Mon, 8 Sep 2003 09:50:35 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 629319; Mon, 08 Sep 2003 09:47:15 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Mon, 8 Sep 2003 09:50:24 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: summary of wcard-clarify issues Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_20,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk As the (informal) WG last call has expired - which doesn't mean an ending to comments - here are what I see as issues: 1) A mistake in the label definition - 0b00 is the start, not 0b01 2) Simon's question about multi-wild cards being described in the draft as legal when they are SHOULD NOT in the original. (So far only Peter has chimed in.) --Do we need to state what happens when one is detected (or just legalize them)? 3) Simon's issue about whether the query has special processing because 1034 says not to cache the answer to a QNAME=*.. a) I think that's a cache issue and would document it as such. b) Peter suggests removing this prohibition and warning that no synthesis is done as a result of retrieving data from the cache. 4) Rob suggests I take Inglesh lessons (;)). Everything I learnt about righting I got from the IETF documents. Seriously, the parts of section 6 mentioned are the least mature, they were thrown in between July and the submission date. The issue there is when I will have time to do the edit. These are the hanging issues I've identified. Issues I think that are out of scope for this document: 1) The meaning of a name error in a negative response, and how a cache or stub resolver might interpret this. 2) Alternative means of synthesizing answers and transferring them between servers. 3) Any actions taken at a cache. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 8 12:06: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 MAA04753 for ; Mon, 8 Sep 2003 12:06:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wOQ7-0007oG-RF for namedroppers-data@psg.com; Mon, 08 Sep 2003 15:59:15 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.22) id 19wOQ2-0007ms-1B for namedroppers@ops.ietf.org; Mon, 08 Sep 2003 15:59:10 +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 h88FUEG06864 for ; Mon, 8 Sep 2003 17:30:14 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h88FUEY09048 for ; Mon, 8 Sep 2003 17:30:14 +0200 (MEST) Message-Id: <200309081530.h88FUEY09048@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: On wild cards In-reply-to: Your message of "Mon, 08 Sep 2003 09:40:05 EDT." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9043.1063035012.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 08 Sep 2003 17:30:14 +0200 From: Peter Koch X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ed Lewis wrote: > But the question is - if we say "MUST/SHOULD NOT" what are the > implications? Do we refuse to load a zone into the master if such a > name is found? Do we drop an AXFR connection if one is found (and I > do mean an "AXFR")? (Or IXFR?) What if the name is in a dynamic > update? (An issue for RFC2136++.) a less drastic approach than explicitly dropping RRs owned by a "multi- wildcard", would be to just not treat the inner wild card(s) "special". I.e. for "*.sub.*.example" the inner "*" would only be matched literally. Would, however, be hard to list the parents of "*.sub.*.example" because the '*' can't be escaped. -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 Mon Sep 8 12:43:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06926 for ; Mon, 8 Sep 2003 12:43:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wOzF-000ARR-UQ for namedroppers-data@psg.com; Mon, 08 Sep 2003 16:35:33 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 19wOxy-000AK8-7w for namedroppers@ops.ietf.org; Mon, 08 Sep 2003 16:34:14 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 06933139AC for ; Mon, 8 Sep 2003 16:33:44 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: On wild cards In-Reply-To: Message from Edward Lewis of "Mon, 08 Sep 2003 09:40:05 -0400." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 08 Sep 2003 16:33:43 +0000 Message-Id: <20030908163344.06933139AC@sa.vix.com> X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > But the question is - if we say "MUST/SHOULD NOT" what are the > implications? Do we refuse to load a zone into the master if such a name > is found? Do we drop an AXFR connection if one is found (and I do mean an > "AXFR")? (Or IXFR?) What if the name is in a dynamic update? (An issue > for RFC2136++.) it's not a protocol violation, it just doesn't mean anything and will never be found or used. there's no reason to reject a transfer or update under those conditions, though a recommendation that the master server produce a warning about the meaningless of the data would help us all. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Sep 8 12:47: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 MAA07188 for ; Mon, 8 Sep 2003 12:47:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19wP6D-000Aza-6b for namedroppers-data@psg.com; Mon, 08 Sep 2003 16:42:45 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19wP5h-000Axo-U0 for namedroppers@ops.ietf.org; Mon, 08 Sep 2003 16:42:14 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 1AD3D43F; Mon, 8 Sep 2003 12:42:13 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 9CF553C3; Mon, 8 Sep 2003 12:42:12 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 629855; Mon, 08 Sep 2003 12:38:52 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200309081530.h88FUEY09048@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200309081530.h88FUEY09048@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 8 Sep 2003 12:42:06 -0400 To: Peter Koch From: Edward Lewis Subject: Re: On wild cards Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:30 +0200 9/8/03, Peter Koch wrote: >a less drastic approach than explicitly dropping RRs owned by a "multi- >wildcard", would be to just not treat the inner wild card(s) "special". This adds a step to 4.3.2c - (instead of just determining that a match is impossible and then seek the wild card) you have to then also see if the wild card found has descendents. Again, I agree that these things are of no real use. But every time I've tried to defend the outlawing of behavior on the basis of it being "useless" or "senseless" or "undesirable" (as opposed to being truly harmful) I keep finding more tar pits to build fences around. (This "philosophical moment" extends beyond the wild card issue.) If we don't admit the names to the DNS because the syntax is offensive, then we are setting a precedent as no (other) names are illegal - and the added work load is in finding all the places an "illegal" name would have to be detected. If we allow these names into the service but restrict their impact, we have to modify what's in 4.3.2 and in the instructions for the readers of the message. (So long as there are legacy servers, these names might be sent.) If we accept them despite what 1034 says, then wcard-clarify is inconsistent when it says it doesn't change 1034. >I.e. for "*.sub.*.example" the inner "*" would only be matched literally. >Would, however, be hard to list the parents of "*.sub.*.example" because >the '*' can't be escaped. Well, 'sub.*.example' wouldn't need any escaping because we would be changing the semantics of the name, not the syntax. ...I guess we could look at the question in another light...is the passage in 1034 (4.3.3) sufficient when it says they should not be there? Are implementers comfortable with the lack of specificity here? Is there a reason to try and define one way of doing this, or is the drive for interoperability preceding the need to interoperate in this case? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 10 18:39: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 SAA21682 for ; Wed, 10 Sep 2003 18:39:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xDPI-000GkH-7J for namedroppers-data@psg.com; Wed, 10 Sep 2003 22:25:48 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.22) id 19xDOi-000Ghs-AP for namedroppers@ops.ietf.org; Wed, 10 Sep 2003 22:25:12 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id AB09E591; Wed, 10 Sep 2003 18:25:08 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 51BB7586 for ; Wed, 10 Sep 2003 18:25:08 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 638950 for namedroppers@ops.ietf.org; Wed, 10 Sep 2003 18:21:37 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030903145042.GA25645@atoom.net> References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> Date: Wed, 10 Sep 2003 18:25:01 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: DNSSECbis Q-2: degradation attack Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:50 +0200 9/3/03, Miek Gieben wrote: > >And that is what Sam is saying: >A zone should be signed with ALL the algorithms in the keyset. And the keyset >in turn should be signed with all the algs. in the DS set. This is currently >under or not specified in the specs. .................................. Right. And, IMHO, the "shoulds" above ought to be MUSTs in the document. >.................................... If a zone is not signed this way a >resolver should raise an error (and not treat the data is being BAD). I admire the effort, but this is impossible. A client can't determine if data is missing at the server if there's a chance the medium is stripping the data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 11 04:02: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 EAA14874 for ; Thu, 11 Sep 2003 04:02:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xMEm-000IbB-5Z for namedroppers-data@psg.com; Thu, 11 Sep 2003 07:51:32 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19xMEB-000IZP-R0 for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 07:50:55 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 40EE64E1CC; Thu, 11 Sep 2003 09:50:55 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id CD1644E082; Thu, 11 Sep 2003 09:50:54 +0200 (CEST) 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 h8B7osWt003343; Thu, 11 Sep 2003 09:50:54 +0200 Date: Thu, 11 Sep 2003 09:50:54 +0200 From: "Olaf M. Kolkman" To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-Id: <20030911095054.4332b4c2.olaf@ripe.net> In-Reply-To: References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.180033 X-RIPE-Signature: 2267ea0c21b6dc5e3191de15395129cc X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Right. And, IMHO, the "shoulds" above ought to be MUSTs in the document. > > >.................................... If a zone is not signed this way a > >resolver should raise an error (and not treat the data is being BAD). > > I admire the effort, but this is impossible. A client can't > determine if data is missing at the server if there's a chance the > medium is stripping the data. Huhhh???? But the whole point is that not having SIGs for each algorithm is an error condition; Off course you do not know what caused the error; maliciousness, signer error, config error, but there is an error. It is local policy to the resolver how to deal with that. -- Olaf PS. The chairs would like to get this issue closed, say within a week. Please speak up if you do not agree with the idea that zone data MUST be signed with all of the algorithms present in the keyset. Suggestions on the resolver behavior are still welcomed. -- to unsubscribe send a message to namedroppers-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 Sep 11 07:43: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 HAA18904 for ; Thu, 11 Sep 2003 07:43:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xPiJ-0004h6-8S for namedroppers-data@psg.com; Thu, 11 Sep 2003 11:34:15 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 19xPhm-0004eT-QZ for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 11:33:42 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h8BBXLt0029067 for ; Thu, 11 Sep 2003 07:33:21 -0400 (EDT) Message-ID: <003501c37858$8217d140$b9370681@barnacle> From: "Scott Rose" To: References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> Subject: Re: DNSSECbis Q-2: degradation attack Date: Thu, 11 Sep 2003 07:33:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just to clarify (in my own mind mostly): Strong statement about how a zone MUST be presented - i.e. with a RRSIG from every algorithm in the zone signing keyset. I guess that means protocol document statements. On the resolver end, local policy will determine if missing RRSIGs might cause the entire response to be marked BAD, or something else. It would be up to the resolver. Is that seem to mesh? I'm pretty much restating in order to keep things clear and (hopefully) resolved quickly. Scott ----- Original Message ----- From: "Edward Lewis" To: Sent: Wednesday, September 10, 2003 6:25 PM Subject: Re: DNSSECbis Q-2: degradation attack > At 16:50 +0200 9/3/03, Miek Gieben wrote: > > > >And that is what Sam is saying: > >A zone should be signed with ALL the algorithms in the keyset. And the keyset > >in turn should be signed with all the algs. in the DS set. This is currently > >under or not specified in the specs. .................................. > > Right. And, IMHO, the "shoulds" above ought to be MUSTs in the document. > > >.................................... If a zone is not signed this way a > >resolver should raise an error (and not treat the data is being BAD). > > I admire the effort, but this is impossible. A client can't > determine if data is missing at the server if there's a chance the > medium is stripping the data. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Sponge Bob Square Pants? I'm still trying to figure out the Macarena. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 11 08:26: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 IAA19795 for ; Thu, 11 Sep 2003 08:26:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xQQw-0007o1-Mn for namedroppers-data@psg.com; Thu, 11 Sep 2003 12:20:22 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.22) id 19xQQQ-0007kG-R1 for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 12:19:50 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h8BCJmSG030852 for ; Thu, 11 Sep 2003 14:19:48 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) id h8BCJmMq030850 for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 14:19:48 +0200 Date: Thu, 11 Sep 2003 14:19:48 +0200 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-ID: <20030911121948.GB30459@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> <003501c37858$8217d140$b9370681@barnacle> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003501c37858$8217d140$b9370681@barnacle> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 11 Sep, @13:33, Scott wrote in "Re: DNSSECbis Q-2: degradation ..."] > Just to clarify (in my own mind mostly): Strong statement about how a zone > MUST be presented - i.e. with a RRSIG from every algorithm in the zone > signing keyset. I guess that means protocol document statements. yes, > On the resolver end, local policy will determine if missing RRSIGs might > cause the entire response to be marked BAD, or something else. It would be > up to the resolver. yes, > Is that seem to mesh? I'm pretty much restating in order to keep things yes, > clear and (hopefully) resolved quickly. let's hope so. I'm in favor of putting (something like) the first paragraph in the protocol doc, 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 Sep 11 08:35: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 IAA20070 for ; Thu, 11 Sep 2003 08:35:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xQaJ-0008aU-MA for namedroppers-data@psg.com; Thu, 11 Sep 2003 12:30:03 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 19xQZm-0008WS-9T for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 12:29:30 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id DA38D433; Thu, 11 Sep 2003 08:29:29 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 5EED5B3; Thu, 11 Sep 2003 08:29:29 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 640662; Thu, 11 Sep 2003 08:25:55 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030911095054.4332b4c2.olaf@ripe.net> References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> <20030911095054.4332b4c2.olaf@ripe.net> Date: Thu, 11 Sep 2003 08:29:23 -0400 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: DNSSECbis Q-2: degradation attack Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:50 +0200 9/11/03, Olaf M. Kolkman wrote: >> >> Right. And, IMHO, the "shoulds" above ought to be MUSTs in the document. >> >> >.................................... If a zone is not signed this way a >> >resolver should raise an error (and not treat the data is being BAD). >> >> I admire the effort, but this is impossible. A client can't >> determine if data is missing at the server if there's a chance the >> medium is stripping the data. > > >Huhhh???? > >But the whole point is that not having SIGs for each algorithm is an >error condition; Off course you do not know what caused the error; >maliciousness, signer error, config error, but there is an error. It >is local policy to the resolver how to deal with that. Server has medium does this Client gets Case 1 (The desired case): X----------------------------------------X Y----------------------------------------Y Z----------------------------------------Z Case 2 (Server doesn't sign with all) X----------------------------------------X Y----------------------------------------Y Case 3 (Medium eats one/MIM stips one) X----------------------------------------X Y----------------------------------------Y Z--------------------\ A resolver (besides only being able to judge the set, not whether the zone is signed correctly) can't determine if the zone admin did the right job (whether the zone is signed correctly). In the context of Miek's message, it appeared be wanted the resolver to flag the zone as misconfigured - which is something a client cannot do. (In case 3, it looks like the zone is misconfigured, but it isn't the server side's fault.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 11 08:57: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 IAA20766 for ; Thu, 11 Sep 2003 08:57:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xQvz-000Abg-Ft for namedroppers-data@psg.com; Thu, 11 Sep 2003 12:52:27 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.22) id 19xQvQ-000AWZ-Lr for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 12:51:52 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) with ESMTP id h8BCplSG031757; Thu, 11 Sep 2003 14:51:47 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.9/8.12.9/Debian-5) id h8BCplJs031755; Thu, 11 Sep 2003 14:51:47 +0200 Date: Thu, 11 Sep 2003 14:51:46 +0200 From: Miek Gieben To: Edward Lewis Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack Message-ID: <20030911125146.GA31706@atoom.net> Mail-Followup-To: Edward Lewis , "Olaf M. Kolkman" , namedroppers@ops.ietf.org References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> <20030911095054.4332b4c2.olaf@ripe.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-new X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 11 Sep, @14:29, Edward wrote in "Re: DNSSECbis Q-2: degradation ..."] > Server has medium does this Client gets > > Case 1 (The desired case): > X----------------------------------------X > Y----------------------------------------Y > Z----------------------------------------Z > > Case 2 (Server doesn't sign with all) > X----------------------------------------X > Y----------------------------------------Y > > Case 3 (Medium eats one/MIM stips one) > X----------------------------------------X > Y----------------------------------------Y > Z--------------------\ > > A resolver (besides only being able to judge the set, not whether the > zone is signed correctly) can't determine if the zone admin did the > right job (whether the zone is signed correctly). In the context of > Miek's message, it appeared be wanted the resolver to flag the zone > as misconfigured - which is something a client cannot do. (In case > 3, it looks like the zone is misconfigured, but it isn't the server > side's fault.) I agree that a resolver cannot distinguish between a wrongly signed zone and a network hiccup which causes sigs to disappear. So I should have said: flag it as an error (not a misconfiguration). 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 Sep 11 09:13: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 JAA21271 for ; Thu, 11 Sep 2003 09:13:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xRDl-000CSE-Fx for namedroppers-data@psg.com; Thu, 11 Sep 2003 13:10:49 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 19xRDF-000CQF-Gb for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 13:10:17 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id DA921621; Thu, 11 Sep 2003 09:10:16 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 6A46861C; Thu, 11 Sep 2003 09:10:16 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.101]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 640762; Thu, 11 Sep 2003 09:06:42 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030911125146.GA31706@atoom.net> References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> <20030911095054.4332b4c2.olaf@ripe.net> <20030911125146.GA31706@atoom.net> Date: Thu, 11 Sep 2003 09:10:07 -0400 To: Miek Gieben From: Edward Lewis Subject: Re: DNSSECbis Q-2: degradation attack Cc: Edward Lewis , "Olaf M. Kolkman" , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:51 +0200 9/11/03, Miek Gieben wrote: >I agree that a resolver cannot distinguish between a wrongly signed zone >and a network hiccup which causes sigs to disappear. So I should have >said: flag it as an error (not a misconfiguration). Yeah - or as something "to be reported." In general Internet usage, feedback to the server via some other means isn't a consideration. But there might be private applications that would. Odds are that this isn't a problem that would go away with a retry. Parts of packets don't just "disappear" without a little help. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-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 Sep 11 09:46: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 JAA22567 for ; Thu, 11 Sep 2003 09:46:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xReU-000EV8-28 for namedroppers-data@psg.com; Thu, 11 Sep 2003 13:38:26 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19xRdy-000ESF-Jn for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 13:37:54 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h8BDaXUx012673 for ; Thu, 11 Sep 2003 09:36:33 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_MaaWy; Thu, 11 Sep 03 09:36:32 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h8BDaTav029593; Thu, 11 Sep 2003 09:36:29 -0400 (EDT) Date: Thu, 11 Sep 2003 09:36:29 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: Scott Rose cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <003501c37858$8217d140$b9370681@barnacle> Message-ID: References: <20030813101218.18d5417d.olaf@ripe.net> <20030813101218.18d5417d.olaf@ripe.net> <5.1.1.6.2.20030814233139.0169ef58@localhost> <20030903145042.GA25645@atoom.net> <003501c37858$8217d140$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.7 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.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 11 Sep 2003, Scott Rose wrote: > Just to clarify (in my own mind mostly): Strong statement about how > a zone MUST be presented - i.e. with a RRSIG from every algorithm in > the zone signing keyset. I guess that means protocol document > statements. > > On the resolver end, local policy will determine if missing RRSIGs > might cause the entire response to be marked BAD, or something else. > It would be up to the resolver. Some client rules are needed, namely that a zone MUST be treated as unsigned if only unsupported algorithms are in the DSset. I've been trying to refine the text I posted on 13 August. Here's that text, as background: > Every RRset MUST be signed by at least one DNSKEY of each > algorithm in the DSset and each additional algorithm, if any, in > the apex DNSKEYset. The apex DNSKEYset itself must be signed by > each algorithm appearing in the zone's DSset. > > And the implications for a validator: > > 1) If the only algorithms in a DSset aren't ones you understand, > you may treat the zone as unsigned (as things are now). > > 2) If there are algorithms you grok in the DSset, but the only > algorithms signing the DNSKEYset are ones you don't understand, > you should assume something bad is happening. (this is a change) > > 3) And if there are algorithms you grok in the DSset and > DNSKEYset, but the only signatures on some RRset are made with > algorithms you don't understand, you should assume something bad > is happening (this is a change). The first paragraph above (re: zone contents) is good verbatim, I think. Here's the new stuff re: resolver behavior. 1) A resolver that supports none of the algorithms in a zone's DSset MUST treat the zone as unsigned. (Implicitly, if the resolver, by policy, insists on signed data, that's fine -- a zone signed only by unwanted/unsupported algorithms is still treated the same as an unsigned zone.) 2) If a resolver supports one or more of the algorithms appearing in a zone's DSset, it SHOULD expect every RRset in the zone to be signed. The resolver SHOULD NOT treat an RRset as unsigned just because it lacks an RRSIG made by any algorithm it supports, so long as that algorithm appeared in the zone's DSset or DNSKEYset. When a supported algorithm appears in a zone's DSset but not in its apex DNSKEYset, a resolver SHOULD NOT treat the zone as unsigned. Alternative text for #2 might say: A resolver SHOULD treat the absence... as a validation failure. But that doesn't deal with the case where some signature chain did validate. If any signature chain validates, everything else (dropping algorithms that appeared in the DSset from the DNSKEYset, not getting RRSIGs of all algorithms (algorithms, not DNSKEYs)) is irrelevant. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 11 10:05: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 KAA23335 for ; Thu, 11 Sep 2003 10:05:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xRyh-000GPD-SA for namedroppers-data@psg.com; Thu, 11 Sep 2003 13:59:19 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 19xRxy-000GKt-EC for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 13:58:48 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h8BDwSt0004254; Thu, 11 Sep 2003 09:58:28 -0400 (EDT) Message-ID: <005301c3786c$c751e520$b9370681@barnacle> From: "Scott Rose" To: "Sam Weiler" Cc: References: Subject: Re: DNSSECbis Q-2: degradation attack Date: Thu, 11 Sep 2003 09:58:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Sam Weiler" *snip* > I've been trying to refine the text I posted on 13 August. Here's > that text, as background: > > > Every RRset MUST be signed by at least one DNSKEY of each > > algorithm in the DSset and each additional algorithm, if any, in > > the apex DNSKEYset. The apex DNSKEYset itself must be signed by > > each algorithm appearing in the zone's DSset. > > > > And the implications for a validator: > > > The first paragraph above (re: zone contents) is good verbatim, I > think. > I agree. If the concensus is to put this in the protocol document, I will abide. I agree about the text, and have no strong feelings about where it should be placed (spec or BCP) as long as it appears. > Here's the new stuff re: resolver behavior. > > 1) A resolver that supports none of the algorithms in a zone's > DSset MUST treat the zone as unsigned. (Implicitly, if the > resolver, by policy, insists on signed data, that's fine -- a zone > signed only by unwanted/unsupported algorithms is still treated the > same as an unsigned zone.) > > 2) If a resolver supports one or more of the algorithms appearing > in a zone's DSset, it SHOULD expect every RRset in the zone to be > signed. The resolver SHOULD NOT treat an RRset as unsigned just > because it lacks an RRSIG made by any algorithm it supports, so > long as that algorithm appeared in the zone's DSset or DNSKEYset. > > When a supported algorithm appears in a zone's DSet but not in its > apex DNSKEYset, a resolver SHOULD NOT treat the zone as unsigned. > > The first SHOULD in 2) seems out of place. I can't see how 2119 language should be used to tell a resolver what it should expect to see in a response, just how to deal with it. I believe that if the resolver cannot get a security statement from the verifier (ie cannot verify all or part of an response), it should treat the data as "unsigned" and go from there accor ding to local policy. > Alternative text for #2 might say: A resolver SHOULD treat the > absence... as a validation failure. But that doesn't deal with the > case where some signature chain did validate. If any signature > chain validates, everything else (dropping algorithms that appeared > in the DSset from the DNSKEYset, not getting RRSIGs of all > algorithms (algorithms, not DNSKEYs)) is irrelevent. > > -- to unsubscribe send a message to namedroppers-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 Sep 11 11:36: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 LAA27889 for ; Thu, 11 Sep 2003 11:36:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xTM4-000NGz-UH for namedroppers-data@psg.com; Thu, 11 Sep 2003 15:27:32 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19xTLR-000NEC-HH for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 15:26:53 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 19xTLQ-000L4I-JU for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 08:26:52 -0700 Message-Id: <200309101711.h8AHBiN29552@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3597 on Handling of Unknown DNS Resource Record (RR) Types Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Wed, 10 Sep 2003 10:11:44 -0700 X-Spam-Status: No, hits=2.9 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3597 Title: Handling of Unknown DNS Resource Record (RR) Types Author(s): A. Gustafsson Status: Standards Track Date: September 2003 Mailbox: gson@nominum.com Pages: 8 Characters: 17559 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-unknown-rrs-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3597.txt Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030910101027.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3597 --OtherAccess Content-Type: Message/External-body; name="rfc3597.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030910101027.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Sep 11 13:08: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 NAA01612 for ; Thu, 11 Sep 2003 13:08:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xUkw-0005GP-ST for namedroppers-data@psg.com; Thu, 11 Sep 2003 16:57:18 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 19xUkR-0005E9-7a for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 16:56:47 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 19xUkQ-000O4s-NN for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 09:56:46 -0700 In-Reply-To: <003501c37858$8217d140$b9370681@barnacle> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 11 Sep 2003 09:28:45 -0400 (EDT) From: Sam Weiler To: Scott Rose cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack X-Spam-Status: No, hits=-6.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-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. ] On Thu, 11 Sep 2003, Scott Rose wrote: > Just to clarify (in my own mind mostly): Strong statement about how a zone > MUST be presented - i.e. with a RRSIG from every algorithm in the zone > signing keyset. I guess that means protocol document statements. > > On the resolver end, local policy will determine if missing RRSIGs might > cause the entire response to be marked BAD, or something else. It would be > up to the resolver. Some client rules are needed, namely that a zone MUST be treated as unsigned if only unsupported algorithms are in the DSset. I've been trying to refine the text I posted on 13 August. Here's that text, as background: > Every RRset MUST be signed by at least one DNSKEY of each > algorithm in the DSset and each additional algorithm, if any, in > the apex DNSKEYset. The apex DNSKEYset itself must be signed by > each algorithm appearing in the zone's DSset. > > And the implications for a validator: > > 1) If the only algorithms in a DSset aren't ones you understand, > you may treat the zone as unsigned (as things are now). > > 2) If there are algorithms you grok in the DSset, but the only > algorithms signing the DNSKEYset are ones you don't understand, > you should assume something bad is happening. (this is a change) > > 3) And if there are algorithms you grok in the DSset and > DNSKEYset, but the only signatures on some RRset are made with > algorithms you don't understand, you should assume something bad > is happening (this is a change). The first paragraph above (re: zone contents) is good verbatim, I think. Here's the new stuff re: resolver behavior. 1) A resolver that supports none of the algorithms in a zone's DSset MUST treat the zone as unsigned. (Implicitly, if the resolver, by policy, insists on signed data, that's fine -- a zone signed only by unwanted/unsupported algorithms is still treated the same as an unsigned zone.) 2) If a resolver supports one or more of the algorithms appearing in a zone's DSset, it SHOULD expect every RRset in the zone to be signed. The resolver SHOULD NOT treat an RRset as unsigned just because it lacks an RRSIG made by any algorithm it supports, so long as that algorithm appeared in the zone's DSset or DNSKEYset. When a supported algorithm appears in a zone's DSet but not in its apex DNSKEYset, a resolver SHOULD NOT treat the zone as unsigned. Alternative text for #2 might say: A resolver SHOULD treat the absence... as a validation failure. But that doesn't deal with the case where some signature chain did validate. If any signature chain validates, everything else (dropping algorithms that appeared in the DSset from the DNSKEYset, not getting RRSIGs of all algorithms (algorithms, not DNSKEYs)) is irrelevent. -- to unsubscribe send a message to namedroppers-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 Sep 11 17:01: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 RAA13857 for ; Thu, 11 Sep 2003 17:01:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xYVR-0000Gw-RC for namedroppers-data@psg.com; Thu, 11 Sep 2003 20:57:33 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19xYVM-0000GR-9K for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 20:57:28 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8BKP0k26519 for ; Thu, 11 Sep 2003 13:25:00 -0700 Date: Thu, 11 Sep 2003 13:25:00 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 47: Miscellaneous Comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 47 is enclosed below. The proposed fixes are as follows: In Section 2.5, change: "The source address of LLMNR queries and responses MUST be "on link"." To: "A sender MUST select a source address for LLMNR queries and responses that is "on link"." In Section 2.7 change: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response." To: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 0 is recommended in highly dynamic environments (such as mobile ad-hoc networks). In more static environments, LLMNR traffic can be reduced by setting the TTL to a higher value." Change: "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 names defended using the mechanism described in Section 4. In particular:" To: "It is the responsibility of the responder to ensure that 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 names defended using the mechanism described in Section 4. In particular:" In Section 3.2, change: "Where there is no DNS server authoritative for the names of hosts on the local network" To: "Where there is no DNS server authoritative for the name of at least one of the hosts currently on the local network" Change: "linklocal name resoltion over IPv4." To: "linklocal name resolution over IPv4." In Section 4, change: "Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache." To: "Where a host is configured to issue LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache." In Section 4, change: "For each UNIQUE resource record in a given interface's configuration, 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 rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to the LLMNR queries on an interface - is configured to respond to the LLMNR queries using additional UNIQUE resource records - detects that an interface is connected and is usable (e.g. an IEEE 802 hardware link-state change indicating that a cable was attached or that an association has occurred with a wireless base station and that any required authentication has completed)" To: "For each UNIQUE resource record in a given interface's configuration, 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, as described in Section 2.6. 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 rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to the LLMNR queries on an interface enabled for transmission and reception of IP traffic - is configured to respond to the LLMNR queries using additional UNIQUE resource records" ------------------------------------------------------ Issue 47: Miscellaneous Issues Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: >Where there is >no DNS server authoritative for the names of hosts on the local network What does that mean? What is the area code for mobile phones at an IETF meeting? The statement doesn't have well-defined meaning. My laptop computer has a name, and its name is not determined by its geographic location at any given time. DNS servers are authoritative for pieces of the name space, not for physical networks. Perhaps the text should say, "Where there is no DNS server authoritative for the name of at least *one* of the hosts *currently* on the local network..." [BA] Agreed. >Where a host is configured to respond to LLMNR queries on more than one >interface, each interface should have its own independent LLMNR cache. Perhaps you mean "configured to *issue* LLMNR queries on more than one interface" [BA] Yes. >Unicast queries SHOULD be sent when: > > b. The sender queries for a [reverse mapping] PTR RR. Rendezvous has something called sleep proxy service, where a device can transfer its RRs to a sleep proxy server on the local LAN and then go into low-power sleep mode. The sleep proxy server answers queries on the device's behalf, and wakes the device with a magic packet when an A or SRV query is detected that indicates the device needs to wake up to provide some active service. Sending queries via unicast means the sleep proxy server may not get to see them, and may be unable to answer and/or wake the device. [BA] It also means that other hosts won't see these queries. On a high populated network such as the IETF's, such queries could consume a substantial percentage of all bandwidth, and so it is desirable to limit them. >The source address of LLMNR queries and responses MUST be "on link". Is this "MUST" a requirement imposed on senders, or a checking requirement imposed on receivers? [BA] On senders. There is no checking requirement on receivers, because by setting TTL=1 the possibility of DoS amplification is removed. If TTL=255 were set on unicast responses, then it would be possible for LLMNR UDP responses to leak beyond link-scope if unicast UDP queries were to be allowed. For TCP this is not an issue since TTL=1 ensures that the 3-way handshake cannot succeed if unless the endpoints are on-link. >it is possible that some routers may not properly implement >link-scope multicast This is far fetched. How many routers *DO* implement multicast forwarding, but *DON'T* understand 224.0.0/8? It's not a plausible scenario. Rendezvous has been sending to 224.0.0.251 with TTL 255 for over a year (longer if you count OS 9) and there have been no problems reported. [BA] As recently as a year ago, we have seen routers that don't properly implement link local multicast, so we disagree on this. >The responder should use a pre-configured TTL value Pre-configured by whom? [BA] By the implementation. It probably makes sense to add some text suggesting appropriate default values. > [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. This creates failures where failures were not necessary. Just put all answers in the response, and let the client use them intelligently: If the routable address works, great, otherwise, the client can try the LL to see if that works. Omitting the LL from the response does not help the client work better: it prevents the client from connecting in situations where it should be able to. (In some cases of network problems, omitting the LL addresses may prevent you from connecting to the some piece of network infrastructure to correct the misconfiguration that led to the problem in the first place.) [BA] The ZEROCONF WG has recommended this behavior to encourage use of a routable address when it is available. The routable address is likely to be more stable, and since the IPv4 LL draft will incorporate behavior to allow hosts with routable and IPv4 LL addresses to communicate, I'm not sure why this should be an issue. Since LLMNR is about linklocal name resolution, a host configured to ARP for addresses on the local link (whether they are routable or IPv4 LL) should be able to reach both types of addresses. >For example, the hostname could be chosen randomly from a large pool of >potential names Doesn't this miss the point of hostnames? The whole point of using names instead of dotted-decimal IP addresses is that names are supposed to be more memorable, and easier for humans to type. If we're going to use randomly chosen names, then we already have a mechanism for randomly choosing from a pool of potential identifiers: it's called a DHCP server. Isn't the point of LLMNR to let people pick a name for their machine that's a little more convenient and friendly than "dhcp-dynamic-191-72-231-201.ietf-53.ietf.org."? [BA] This is just cited as an example of how name conflict can be avoided. It is not being recommended necessarily -- and could be usable in situations where no human intervention is anticipated. -- to unsubscribe send a message to namedroppers-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 Sep 11 17:01: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 RAA13873 for ; Thu, 11 Sep 2003 17:01:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xYSE-000Ptg-PU for namedroppers-data@psg.com; Thu, 11 Sep 2003 20:54:14 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19xYSC-000PtL-DE for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 20:54:12 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8BKLia26354 for ; Thu, 11 Sep 2003 13:21:45 -0700 Date: Thu, 11 Sep 2003 13:21:44 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Issue 44: Reuse of Rendezvous IPv4 Multicast Address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 44: Reuse of Rendezvous IPv4 multicast address Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: This is a busy time at Apple, working towards our next OS release, but I managed to make time to read draft-ietf-dnsext-mdns-22.txt. >The IPv4 link-scope multicast address a given responder listens >to, and to which a sender sends queries, is 224.0.0.251. If your intention is to make LLMNR interoperable with Rendezvous, I fully support that, and would be willing to do the necessary work. For example, Rendezvous does not currently support TCP queries, but we would be willing to add that support, and things like it, if the WG wanted to pursue that direction. Otherwise, if the intention is not to make LLMNR interoperable with Rendezvous, then it should not use the same multicast address. Using the same multicast address, and then using a different UDP port number so as to demultiplex the traffic in the kernel, would be the height of folly. The whole point of multicast (as opposed to good old-fashioned broadcast) is that it lets the Ethernet hardware (and/or the Ethernet switch) reduce the interrupt burden on the host CPU (and/or reduce the traffic on that link). Using the UDP port number as the filtering mechanism means that you pay all the cost of delivering a packet to a host that doesn't want it, only to have the packet discarded in the kernel because no one is listening on that port. The whole point of multicast is to prevent that waste. -- to unsubscribe send a message to namedroppers-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 Sep 11 17:43: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 RAA14781 for ; Thu, 11 Sep 2003 17:43:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xZ71-0003T9-LH for namedroppers-data@psg.com; Thu, 11 Sep 2003 21:36:23 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19xZ6x-0003Sm-5l for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 21:36:19 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8BL3pV28827 for ; Thu, 11 Sep 2003 14:03:51 -0700 Date: Thu, 11 Sep 2003 14:03:51 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Revised Proposed Resolution of Issue 47: Miscellaneous Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 47 is enclosed below. The proposed fix is as follows: 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. On receiving an LLMNR query, the responder MUST check whether it was sent to a LLMNR multicast addresses defined in Section 2.4. If it was sent to another multicast address, then the query MUST be silently discarded." To: "A sender MUST select a source address for LLMNR queries that is "on link". The destination address of an LLMNR query MUST be a link-scope multicast address or an "on link" unicast address. A responder MUST select a source address for responses that is "on link". 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 a LLMNR multicast addresses defined in Section 2.4. If it was sent to another multicast address, then the query MUST be silently discarded." In Section 2.7 change: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response." To: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 0 is recommended in highly dynamic environments (such as mobile ad-hoc networks). In more static environments, LLMNR traffic can be reduced by setting the TTL to a higher value." Change: "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 names defended using the mechanism described in Section 4. In particular:" To: "It is the responsibility of the responder to ensure that 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 names defended using the mechanism described in Section 4. In particular:" In Section 3.2, change: "Where there is no DNS server authoritative for the names of hosts on the local network or the authoritative DNS server does not support dynamic client update over IPv6 or DHCPv6-based dynamic update, hosts on the home network will not be able to dynamically register or resolve the names of local IPv6 hosts." To: "Where there is no DNS server authoritative for the name of a host or the authoritative DNS server does not support dynamic client update over IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not be able to do DNS dynamic update, and other hosts will not be able to resolve its name." Change: "linklocal name resoltion over IPv4." To: "linklocal name resolution over IPv4." In Section 4, change: "Where a host is configured to respond to LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache." To: "Where a host is configured to issue LLMNR queries on more than one interface, each interface should have its own independent LLMNR cache." In Section 4, change: "For each UNIQUE resource record in a given interface's configuration, 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 rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to the LLMNR queries on an interface - is configured to respond to the LLMNR queries using additional UNIQUE resource records - detects that an interface is connected and is usable (e.g. an IEEE 802 hardware link-state change indicating that a cable was attached or that an association has occurred with a wireless base station and that any required authentication has completed)" To: "For each UNIQUE resource record in a given interface's configuration, 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, as described in Section 2.6. 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 rebooted - wakes from sleep (if the network interface was inactive during sleep) - is configured to respond to the LLMNR queries on an interface enabled for transmission and reception of IP traffic - is configured to respond to the LLMNR queries using additional UNIQUE resource records" ----------------------------------------------------------------- Issue 47: Miscellaneous Issues Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: >Where there is >no DNS server authoritative for the names of hosts on the local network What does that mean? What is the area code for mobile phones at an IETF meeting? The statement doesn't have well-defined meaning. My laptop computer has a name, and its name is not determined by its geographic location at any given time. DNS servers are authoritative for pieces of the name space, not for physical networks. Perhaps the text should say, "Where there is no DNS server authoritative for the name of at least *one* of the hosts *currently* on the local network..." [BA] Agreed. >Where a host is configured to respond to LLMNR queries on more than one >interface, each interface should have its own independent LLMNR cache. Perhaps you mean "configured to *issue* LLMNR queries on more than one interface" [BA] Yes. >Unicast queries SHOULD be sent when: > > b. The sender queries for a [reverse mapping] PTR RR. Rendezvous has something called sleep proxy service, where a device can transfer its RRs to a sleep proxy server on the local LAN and then go into low-power sleep mode. The sleep proxy server answers queries on the device's behalf, and wakes the device with a magic packet when an A or SRV query is detected that indicates the device needs to wake up to provide some active service. Sending queries via unicast means the sleep proxy server may not get to see them, and may be unable to answer and/or wake the device. [BA] It also means that other hosts won't see these queries. On a high populated network such as the IETF's, such queries could consume a substantial percentage of all bandwidth, and so it is desirable to limit them. >The source address of LLMNR queries and responses MUST be "on link". Is this "MUST" a requirement imposed on senders, or a checking requirement imposed on receivers? [BA] On senders. There is no checking requirement on receivers, because by setting TTL=1 the possibility of DoS amplification is removed. If TTL=255 were set on unicast responses, then it would be possible for LLMNR UDP responses to leak beyond link-scope if unicast UDP queries were to be allowed. For TCP this is not an issue since TTL=1 ensures that the 3-way handshake cannot succeed if unless the endpoints are on-link. >it is possible that some routers may not properly implement >link-scope multicast This is far fetched. How many routers *DO* implement multicast forwarding, but *DON'T* understand 224.0.0/8? It's not a plausible scenario. Rendezvous has been sending to 224.0.0.251 with TTL 255 for over a year (longer if you count OS 9) and there have been no problems reported. [BA] As recently as a year ago, we have seen routers that don't properly implement link local multicast, so we disagree on this. >The responder should use a pre-configured TTL value Pre-configured by whom? [BA] By the implementation. It probably makes sense to add some text suggesting appropriate default values. >[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. This creates failures where failures were not necessary. Just put all answers in the response, and let the client use them intelligently: If the routable address works, great, otherwise, the client can try the LL to see if that works. Omitting the LL from the response does not help the client work better: it prevents the client from connecting in situations where it should be able to. (In some cases of network problems, omitting the LL addresses may prevent you from connecting to the some piece of network infrastructure to correct the misconfiguration that led to the problem in the first place.) [BA] The ZEROCONF WG has recommended this behavior to encourage use of a routable address when it is available. The routable address is likely to be more stable, and since the IPv4 LL draft will incorporate behavior to allow hosts with routable and IPv4 LL addresses to communicate, I'm not sure why this should be an issue. Since LLMNR is about linklocal name resolution, a host configured to ARP for addresses on the local link (whether they are routable or IPv4 LL) should be able to reach both types of addresses. >For example, the hostname could be chosen randomly from a large pool of >potential names Doesn't this miss the point of hostnames? The whole point of using names instead of dotted-decimal IP addresses is that names are supposed to be more memorable, and easier for humans to type. If we're going to use randomly chosen names, then we already have a mechanism for randomly choosing from a pool of potential identifiers: it's called a DHCP server. Isn't the point of LLMNR to let people pick a name for their machine that's a little more convenient and friendly than "dhcp-dynamic-191-72-231-201.ietf-53.ietf.org."? [BA] This is just cited as an example of how name conflict can be avoided. It is not being recommended necessarily -- and could be usable in situations where no human intervention is anticipated. -- to unsubscribe send a message to namedroppers-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 Sep 11 17:44: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 RAA14829 for ; Thu, 11 Sep 2003 17:44:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xZ4i-0003Ga-Iv for namedroppers-data@psg.com; Thu, 11 Sep 2003 21:34:00 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19xZ4e-0003G5-T6 for namedroppers@ops.ietf.org; Thu, 11 Sep 2003 21:33:57 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8BL1TO28706 for ; Thu, 11 Sep 2003 14:01:29 -0700 Date: Thu, 11 Sep 2003 14:01:29 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Revised Proposed Resolution to LLMNR Issue 46: Retransmission Behavior Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Below find the text of Issue 46. The proposed fix is as follows: Change Section 2.6 from: "2.6. Retransmissions In order to avoid synchronization, LLMNR queries and responses are delayed by a time uniformly distributed between 0 and 200 ms. If an LLMNR query sent over UDP is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) based on the last response received for a query, on a per-interface basis. The algorithms described in [RFC2988] are suggested, with a minimum timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer." To: "2.6. Retransmissions In order to avoid synchronization, LLMNR queries and responses are delayed by a time randomly selected from the interval 0 to 200 ms. If an LLMNR query sent over UDP is not resolved within the timeout interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of the query in order to assure that it was received by a host capable of responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. Since a multicast query sender cannot know beforehand whether it will receive no response, one response, or more than one response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has been received. LLMNR implementations SHOULD dynamically estimate the timeout value (LLMNR_TIMEOUT) based on the last response received for a query, on a per-interface basis. The algorithms described in [RFC2988] are suggested (including exponential backoff). Smaller values of RTOinitial, RTOmin and RTOmax MAY be used. Recommended values are RTOinitial=1 second, RTOmin=200ms, RTOmax=20 seconds. " ------------------------------------------------------------------------- Issue 46: Retransmission behavior Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: >For each UNIQUE resource record in a given interface's configuration, >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. How many LLMNR queries? What interval? How long after the query (or queries) may it start issuing responses for that name? [BA] UNIQUEness verification is handled similarly to any other query, as specified in Section 2.6. What about tie-breaking in the event of simultaneous startup (e.g. when power is restored after an outage)? [BA] The draft does not specify what is done in the event of a name conflict. In general, automatic name change may be neither possible nor desirable. -- to unsubscribe send a message to namedroppers-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 Sep 12 00:27: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 AAA25423 for ; Fri, 12 Sep 2003 00:27:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xfJS-0005HO-8H for namedroppers-data@psg.com; Fri, 12 Sep 2003 04:13:38 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 19xfIv-0005G5-Su for namedroppers@ops.ietf.org; Fri, 12 Sep 2003 04:13:06 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8C4BZd05445 for ; Fri, 12 Sep 2003 00:11:40 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h8C4DKi22516 for ; Fri, 12 Sep 2003 00:13:47 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h8C4Af4h031814 for ; Fri, 12 Sep 2003 00:10:45 -0400 To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-reply-to: Your message of "Thu, 11 Sep 2003 09:36:29 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 12 Sep 2003 00:10:41 -0400 Message-ID: <31813.1063339841@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Status: No, hits=-8.1 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Sam" == Sam Weiler writes: Sam> Here's the new stuff re: resolver behavior. Sam> 1) A resolver that supports none of the algorithms in a zone's DSset Sam> MUST treat the zone as unsigned. (Implicitly, if the resolver, by Sam> policy, insists on signed data, that's fine -- a zone signed only by Sam> unwanted/unsupported algorithms is still treated the same as an Sam> unsigned zone.) i.e. if I can't understand the DS/DNSKEY/DNSSIG, then they don't exist for me. Sam> 2) If a resolver supports one or more of the algorithms appearing in Sam> a zone's DSset, it SHOULD expect every RRset in the zone to be Sam> signed. The resolver SHOULD NOT treat an RRset as unsigned just Sam> because it lacks an RRSIG made by any algorithm it supports, so long Sam> as that algorithm appeared in the zone's DSset or DNSKEYset. so, if the entry point is made with a algorithm I support, but the RRsets are done with another algorithm, then ??? I'm not clear I understand the text for this case. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP2FHPoqHRg3pndX9AQGoqwQArTmjSieXGKuMcBDQwqULZcExBMznVeoo RatkbBkHlEnYSAph4bpWFyN1ZtIIFbCmm33fLawjT6RF70LWfuIcvzGAuX1ehAJB wBEVvSk9E6SJFSmN9aH+kupjBjVOvP7iYNybTsfA/8fpGIyyGZqNAPdWqx+D/NDd ADBRP0woSXQ= =d4Fs -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 12 07:21: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 HAA16631 for ; Fri, 12 Sep 2003 07:21:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xlp4-00059o-U3 for namedroppers-data@psg.com; Fri, 12 Sep 2003 11:10:42 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19xlox-00059M-Fe for namedroppers@ops.ietf.org; Fri, 12 Sep 2003 11:10:35 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h8CB9DjJ001553 for ; Fri, 12 Sep 2003 07:09:13 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA6kaacd; Fri, 12 Sep 03 07:09:12 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h8CB96iG008643; Fri, 12 Sep 2003 07:09:06 -0400 (EDT) Date: Fri, 12 Sep 2003 07:09:05 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: Michael Richardson cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <31813.1063339841@marajade.sandelman.ottawa.on.ca> Message-ID: References: <31813.1063339841@marajade.sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 12 Sep 2003, Michael Richardson wrote: > i.e. if I can't understand the DS/DNSKEY/DNSSIG, then they don't > exist for me. Yup. (s/DNSSIG/RRSIG/) > so, if the entry point is made with a algorithm I support, but the RRsets > are done with another algorithm, then ??? > I'm not clear I understand the text for this case. The new rule is that if the entry point includes algorithm A, algorithm A must be used to sign the whole zone.[1] So, by these rules, the zone is not properly signed, and the resolver SHOULD treat this an a validation error.[2] With the current BIND behavior, it would give a SERVFAIL and no answer. That's not ideal, but it's the best we have today. Another way to look at the change is that we needed to find a way for the zone to tell resolvers which algorithms it's used to sign a given RRset. Rather than add a new signaling mechanism, this change assigns additional semantics to the DSset and DNSKEYset. -- Sam [1] With DSsets and DNSKEYsets, it's a little more complicated than this -- look at the text I posted yesterday morning. And, of course, you can switch DNSKEYs, so long as some DNSKEY of the algorithm is used for every RRset. [2] Like the "alternative" text from yesterday, this doesn't deal with the case of "I found another valid signature chain for this RRset". -- to unsubscribe send a message to namedroppers-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 Sep 12 07:43: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 HAA17106 for ; Fri, 12 Sep 2003 07:43:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xmHP-0007M8-Jy for namedroppers-data@psg.com; Fri, 12 Sep 2003 11:39:59 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19xmHN-0007Lq-7d for namedroppers@ops.ietf.org; Fri, 12 Sep 2003 11:39:57 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h8CBcZPw002799 for ; Fri, 12 Sep 2003 07:38:35 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKwaWDf; Fri, 12 Sep 03 07:38:34 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h8CBcUMf010354; Fri, 12 Sep 2003 07:38:32 -0400 (EDT) Date: Fri, 12 Sep 2003 07:38:30 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@filbert To: Scott Rose cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <005301c3786c$c751e520$b9370681@barnacle> Message-ID: References: <005301c3786c$c751e520$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 11 Sep 2003, Scott Rose wrote: > > 2) If a resolver supports one or more of the algorithms appearing > > in a zone's DSset, it SHOULD expect every RRset in the zone to be > > signed. The resolver SHOULD NOT treat an RRset as unsigned just > > because it lacks an RRSIG made by any algorithm it supports, so > > long as that algorithm appeared in the zone's DSset or DNSKEYset. > > The first SHOULD in 2) seems out of place. I can't see how 2119 language > should be used to tell a resolver what it should expect to see in a > response, just how to deal with it. It probably is out of place. The alternative text is probably must easier to understand. > I believe that if the resolver cannot > get a security statement from the verifier (ie cannot verify all or part of > an response), it should treat the data as "unsigned" and go from there accor > ding to local policy. Are you distinguishing between "I got a chain of trust that I should be able to verify (I support all the algorithms and have a configured root of trust), but it didn't" and "I didn't expect this zone to be signed"? This whole problem falls of from thinking that resolvers will have at least three cases, not all of which are the same: 1) The data is signed and validated. Yippee. 2) The data isn't supposed to be signed. Perhaps I lack a root of trust. Perhaps the delegation to the child (or one of its parents) lacks a DS, confirmed by a signed NSEC. Perhaps the only DS is for an algorithm I don't understand. 3) The data is supposed to be signed, but something broke. Maybe the RRSIG just didn't validate. Maybe there was a DS at the parent, but no DNSKEYset in the child. Maybe there was a DS (of a supported algorithm) at the parent, but no matching DNSKEY in the child. Maybe the RRs weren't signed with the algorithm I understand (and that appeared in the DNSKEYset). In case 2, some clients might reject all unsigned data, but I suspect most won't. In case 3, current clients give very hard failures. That probably needs to change slightly. (ie. What if the thing that broke was the trust root (my preconfigured key didn't match the one in use), and everything below it validated? I might want a softer failure mode.) But under the assumption that most clients still give answers in case 2, treating case 3 as unsigned (case 2) makes me wonder why we're doing DNSSEC at all. If we're just going to give the same answers no matter which of case 1, 2, or 3 happened, why bother? Going back to the issue at hand, if clients expect a zone to be signed with any, but not all, of the algorithms, then they don't have enough information to decide if "the RRs weren't signed with the algorithm I understand" is case 2 or case 3. And routinely treating it as case 2, which I think is necessary to satisfy the safety property, opens the door to a degradation attack. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Sep 12 07:53: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 HAA17354 for ; Fri, 12 Sep 2003 07:53:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xmQE-00085J-Lh for namedroppers-data@psg.com; Fri, 12 Sep 2003 11:49:06 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19xmPh-000842-8u for namedroppers@ops.ietf.org; Fri, 12 Sep 2003 11:48:33 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id A84744EE20; Fri, 12 Sep 2003 13:48:32 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 004324EE08 for ; Fri, 12 Sep 2003 13:48:32 +0200 (CEST) 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 h8CBmVWt019006 for ; Fri, 12 Sep 2003 13:48:31 +0200 Date: Fri, 12 Sep 2003 13:48:31 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Issue Tracker Message-Id: <20030912134831.62a26ca1.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.499984 X-RIPE-Signature: 5b26a61fb217093c49275ab9aab58854 X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Name-droppers colleagues, In order to more tightly manage the work-flow we intend to start using an issue tracker. Below is a description that will be included in the monthly subscription-reminder. We are open to suggestions for improvement. --Olaf DNSEXT Chair -------------------------------------------------------------------- - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. $Id: issue-tracker.txt,v 1.4 2003/09/12 11:47:30 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 12 09:47: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 JAA22028 for <dnsext-archive@lists.ietf.org>; Fri, 12 Sep 2003 09:47:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xoAd-000HUA-4F for namedroppers-data@psg.com; Fri, 12 Sep 2003 13:41:07 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 19xoAX-000HTk-IA for namedroppers@ops.ietf.org; Fri, 12 Sep 2003 13:41:01 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21626; Fri, 12 Sep 2003 09:40:53 -0400 (EDT) Message-Id: <200309121340.JAA21626@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-23.txt Date: Fri, 12 Sep 2003 09:40:53 -0400 X-Spam-Status: No, hits=2.9 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME, RCVD_IN_OSIRUSOFT_COM,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-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-23.txt Pages : 21 Date : 2003-9-12 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-23.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-23.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-23.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-9-12084430.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-23.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-12084430.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 12 13:10: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 NAA05251 for <dnsext-archive@lists.ietf.org>; Fri, 12 Sep 2003 13:10:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xrFe-0008m2-IG for namedroppers-data@psg.com; Fri, 12 Sep 2003 16:58:30 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.22) id 19xrF8-0008ht-Eb for namedroppers@ops.ietf.org; Fri, 12 Sep 2003 16:57:58 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h8CGtiu11722; Fri, 12 Sep 2003 09:55:44 -0700 From: bmanning@karoshi.com Message-Id: <200309121655.h8CGtiu11722@karoshi.com> Subject: Re: DNSSECbis Q-2: degradation attack To: weiler@tislabs.com (Sam Weiler) Date: Fri, 12 Sep 2003 09:55:44 -0700 (PDT) Cc: mcr@sandelman.ottawa.on.ca (Michael Richardson), namedroppers@ops.ietf.org In-Reply-To: <Pine.GSO.4.55.0309120652490.20063@filbert> from "Sam Weiler" at Sep 12, 2003 07:09:05 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > On Fri, 12 Sep 2003, Michael Richardson wrote: > > > i.e. if I can't understand the DS/DNSKEY/DNSSIG, then they don't > > exist for me. > > Yup. (s/DNSSIG/RRSIG/) again, I am a bit confused. (sam, feel free to take me in a corner and gently persuade me) w/ DNSSEC, individual rrs are bound into "atomic" rrsets. you seem to be intimating that if part of an rrset is unknown/opaque to me as a resolver, I have the obligation to split the rrset back into indvidual rrs and toss those bits I can't parse and then (possibly) reassemble the rrset with the bits I can parse? is that -really- what you are suggesting? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 12 13:31:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06050 for <dnsext-archive@lists.ietf.org>; Fri, 12 Sep 2003 13:31:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19xrhb-000BBB-0o for namedroppers-data@psg.com; Fri, 12 Sep 2003 17:27:23 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 19xrh5-000B7M-Bj for namedroppers@ops.ietf.org; Fri, 12 Sep 2003 17:26:51 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5E25113971 for <namedroppers@ops.ietf.org>; Fri, 12 Sep 2003 17:26:17 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: Message from bmanning@karoshi.com of "Fri, 12 Sep 2003 09:55:44 MST." <200309121655.h8CGtiu11722@karoshi.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 12 Sep 2003 17:26:17 +0000 Message-Id: <20030912172617.5E25113971@sa.vix.com> X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk bill wrote: > ... w/ DNSSEC, individual rrs are bound into "atomic" rrsets. ... that's not a dnssec thing, it's a basic fact of dns. the fact that the protocol doesn't express rrsets as atomic is a weakness in the design (in that it wastes space and permits erroneous carriage). rrsets cannot be validly sent, cached, or used other than in their authoritative entirety. paul -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 13 00:12: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 AAA27717 for <dnsext-archive@lists.ietf.org>; Sat, 13 Sep 2003 00:12:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19y1bq-000I0R-64 for namedroppers-data@psg.com; Sat, 13 Sep 2003 04:02:06 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 19y1bK-000HwL-VF for namedroppers@ops.ietf.org; Sat, 13 Sep 2003 04:01:35 +0000 Received: (qmail 48432 invoked by uid 1016); 13 Sep 2003 04:01:54 -0000 Date: 13 Sep 2003 04:01:53 -0000 Message-ID: <20030913040153.48392.qmail@cr.yp.to> From: "D. J. Bernstein" <djb@cr.yp.to> To: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack References: <200309121655.h8CGtiu11722@karoshi.com> <20030912172617.5E25113971@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: > rrsets cannot be validly sent, cached, or used other than in their > authoritative entirety. Last I checked, BIND truncated UDP packets before the first record that passes 512 bytes, even if that's in the middle of a record set. I simply truncate before all records. Clients shouldn't be trying to use records from a truncated packet anyway; I don't know why BIND bothers to send them. ---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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 13 01:32: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 BAA28910 for <dnsext-archive@lists.ietf.org>; Sat, 13 Sep 2003 01:32:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19y2tY-0006RZ-E5 for namedroppers-data@psg.com; Sat, 13 Sep 2003 05:24:28 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.22) id 19y2ry-0006AS-9z for namedroppers@ops.ietf.org; Sat, 13 Sep 2003 05:22:50 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id h8D5LSCI006098 for <namedroppers@ops.ietf.org>; Sat, 13 Sep 2003 01:21:28 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAN2ai6l; Sat, 13 Sep 03 01:21:27 -0400 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id h8D5LNgq010238; Sat, 13 Sep 2003 01:21:23 -0400 (EDT) Date: Sat, 13 Sep 2003 01:21:23 -0400 (EDT) From: Sam Weiler <weiler@tislabs.com> X-X-Sender: weiler@filbert To: bmanning@karoshi.com cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis Q-2: degradation attack In-Reply-To: <200309121655.h8CGtiu11722@karoshi.com> Message-ID: <Pine.GSO.4.55.0309130119540.10118@filbert> References: <200309121655.h8CGtiu11722@karoshi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... you seem to be intimating that if part of an rrset is > unknown/opaque to me as a resolver, I have the obligation to split > the rrset back into indvidual rrs and toss those bits I can't parse > and then (possibly) reassemble the rrset with the bits I can parse? > is that -really- what you are suggesting? Not at all. I don't like this existence language, but MCR made it sound so reasonable. :) <gentle persuading device activated> Instead, how about "they don't exist for me for the purposes of DNSSEC validation"? If I cache the RRset, I must cache the whole thing. Same thing for answering queries. Or perhaps: I assign no special meaning to them -- where I might have seen an unsupported RRSIG and assumed 'oh well, the record is signed but I'm lame and don't grok the algorithm; maybe I should tuck my tail between my legs, whimper a little, and give a soft failure since I'm so incapable', I instead say 'there's no RRSIG here and because there's a supported DS for the zone, I expected one, so I'll give a hard failure. Bite me.' Again, the RRset is atomic. -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 13 07:55: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 HAA16671 for <dnsext-archive@lists.ietf.org>; Sat, 13 Sep 2003 07:55:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19y8nB-000P7e-7Q for namedroppers-data@psg.com; Sat, 13 Sep 2003 11:42:17 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19y8mf-000P35-Jk for namedroppers@ops.ietf.org; Sat, 13 Sep 2003 11:41:45 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8DB99s29564 for <namedroppers@ops.ietf.org>; Sat, 13 Sep 2003 04:09:09 -0700 Date: Sat, 13 Sep 2003 04:09:08 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 44: Reuse of Rendezvous IPV4 Multicast Address Message-ID: <Pine.LNX.4.53.0309130407070.29462@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 44 is enclosed below. The proposed resolution is as follows: Change "224.0.0.251" throughout the document to TBD. --------------------------------------------------------- Issue 44: Reuse of Rendezvous IPv4 multicast address Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: This is a busy time at Apple, working towards our next OS release, but I managed to make time to read draft-ietf-dnsext-mdns-22.txt. >The IPv4 link-scope multicast address a given responder listens >to, and to which a sender sends queries, is 224.0.0.251. If your intention is to make LLMNR interoperable with Rendezvous, I fully support that, and would be willing to do the necessary work. For example, Rendezvous does not currently support TCP queries, but we would be willing to add that support, and things like it, if the WG wanted to pursue that direction. Otherwise, if the intention is not to make LLMNR interoperable with Rendezvous, then it should not use the same multicast address. Using the same multicast address, and then using a different UDP port number so as to demultiplex the traffic in the kernel, would be the height of folly. The whole point of multicast (as opposed to good old-fashioned broadcast) is that it lets the Ethernet hardware (and/or the Ethernet switch) reduce the interrupt burden on the host CPU (and/or reduce the traffic on that link). Using the UDP port number as the filtering mechanism means that you pay all the cost of delivering a packet to a host that doesn't want it, only to have the packet discarded in the kernel because no one is listening on that port. The whole point of multicast is to prevent that waste. [BA] Before we can decide on this, it's important to understand what changes would be required to achieve interoperability, and whether that interoperability would extend beyond the wire (e.g. to the content of the RRs) so that it would be meaningful -- rather than just a mechanism for Rendezvous to claim compliance with the LLMNR Proposed Standard without yielding the ability to interoperate with other LLMNR implementations in meaningful scenarios. Assuming that LLMNR and Rendezvous can't interoperate, it seems fair to request assignment of a distinct IPv4 link-scope multicast 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 13 07:55:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16687 for <dnsext-archive@lists.ietf.org>; Sat, 13 Sep 2003 07:55:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19y8pt-000Pdd-C1 for namedroppers-data@psg.com; Sat, 13 Sep 2003 11:45:05 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19y8pN-000PWd-Br for namedroppers@ops.ietf.org; Sat, 13 Sep 2003 11:44:33 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8DBBuo29685 for <namedroppers@ops.ietf.org>; Sat, 13 Sep 2003 04:11:57 -0700 Date: Sat, 13 Sep 2003 04:11:56 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: Proposed Resolution of LLMNR Issue 45: Handling of Unqualified Names Message-ID: <Pine.LNX.4.53.0309130409160.29462@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 45 is enclosed below. The proposed fix is as follows: In Section 2.1, change: "An LLMNR sender MAY send a request for any name." To: "Section 3 describes the circumstances in which LLMNR requests may be sent." In Section 3, change: "LLMNR is a peer-to-peer name resolution protocol that is not intended as a replacement for DNS. By default, LLMNR requests SHOULD be sent only when no manual or automatic DNS configuration has been performed, when DNS servers do not respond, or when they respond to a query with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. As noted in [DNSPerf], even when DNS servers are configured, a significant fraction of DNS queries do not receive a response, or result in negative responses due to missing inverse mappings or NS records that point to nonexistent or inappropriate hosts. Given this, support for LLMNR as a secondary name resolution mechanism has the potential to result in a large number of inappropriate queries without the following additional restrictions: [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] 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. [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 send LLMNR queries for PTR RRs via unicast, as specified in Section 2.3." To: "LLMNR is a peer-to-peer name resolution protocol that is not intended as a replacement for DNS. By default, LLMNR requests SHOULD be sent only when no manual or automatic DNS configuration has been performed, when DNS servers do not respond, or when they respond to a query with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. An LLMNR sender may send a request for any name. As noted in [DNSPerf], even when DNS servers are configured, a significant fraction of DNS queries do not receive a response, or result in negative responses due to missing inverse mappings or NS records that point to nonexistent or inappropriate hosts. Given this, support for LLMNR as a secondary name resolution mechanism has the potential to result in a large number of inappropriate queries without the following additional restrictions: [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 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. [3] A sender SHOULD send LLMNR queries for PTR RRs via unicast, as specified in Section 2.3." Change section 3.1, from: "The same host MAY use LLMNR queries for the resolution of unqualified host names, and conventional DNS queries for resolution of other DNS names. If a name is not qualified and does not end in a trailing dot, for the purposes of LLMNR, the implicit search order is as follows: [1] Request the name with the current domain appended. [2] Request just the name. This is the behavior suggested by [RFC1536]. LLMNR uses this technique to resolve unqualified host names." To: "If a name is not qualified, for the purposes of LLMNR, the implicit search order is as follows: [1] Request the name with the current domain appended. [2] Request the name with the root domain (".") appended. This is the behavior suggested by [RFC1536]." -------------------------------------------------------------- Issue 45: Handling of Unqualified Names Submitter name: Stuart Cheshire Submitter email address: cheshire@apple.com Date first submitted: August 24, 2003 Reference: Document: LLMNR-22 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: >Today, with the rise of home networking, there are an increasing number >of ad-hoc networks operating without a Domain Name System (DNS) server. I think this is side-stepping the real issue. The real issue is: >Today, with the rise of home networking, there are an increasing number >of home users who do not have ownership of any part of the name space >in which they can assign names. The whole section talking about "unqualified names" seems to be skirting around this issue without being willing to face it head-on and tackle it. Section 3.1 says: >3.1. Unqualified names > >The same host MAY use LLMNR queries for the resolution of unqualified >host names, and conventional DNS queries for resolution of other DNS >names. > >If a name is not qualified and does not end in a trailing dot, for the >purposes of LLMNR, the implicit search order is as follows: > >[1] Request the name with the current domain appended. >[2] Request just the name. You can't "request just the name". There is no way to represent an unqualified name ("no trailing dot") in the DNS packet format. What you mean is: >[1] Request the name with the current domain appended. >[2] Request the name with the root domain (".") appended. What this means is that if a home user calls their TV "tv", and their FM radio receiver "fm", and their CD player "cd", their computer is going to be sending queries for the TLDs "tv.", "fm." and "cd." (Tuvalu, Federal State of Micronesia, and Democratic Republic of the Congo, respectively.) This seems like it invites chaotic uncontrolled pollution of the top-level name space. [BA] I assume you are referring to DNS queries for "tv." Presumably there is no harm in allowing LLMNR queries for this. The draft allows a host to resolve queries for unqualified names only via LLMNR, so this can be avoided. Are you suggesting that this behavior be recommended? Furthermore, because there is no way to represent an unqualified name in the DNS packet format, there is also no way to represent an unqualified name on the right-hand-side of a PTR, CNAME or SRV record. This means that if you do a LLMNR query for an SRV record with an "unqualified" name, what you get back is an SRV record containing a target host name that you can't use with LLMNR because it's not an "unqualified" name. [BA] Agreed. This should be fixed. >3.1. Unqualified names > >The same host MAY use LLMNR queries for the resolution of unqualified >host names Who makes the choice offered by that "MAY"? User? OS vendor? Application writer? [BA] The LLMNR implementation. >If a name is not qualified and does not end in a trailing dot, What does that mean? Do "fully qualified" and "ends in a trailing dot" mean the same thing, or is there a difference? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 14 10:40: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 KAA03206 for <dnsext-archive@lists.ietf.org>; Sun, 14 Sep 2003 10:40:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yXpE-000IQw-RT for namedroppers-data@psg.com; Sun, 14 Sep 2003 14:26:04 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 19yXp8-000IPb-HK for namedroppers@ops.ietf.org; Sun, 14 Sep 2003 14:25:58 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8EDrFc26927 for <namedroppers@ops.ietf.org>; Sun, 14 Sep 2003 06:53:15 -0700 Date: Sun, 14 Sep 2003 06:53:15 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: LLMNR Issue 48: Reachability of routable addresses Message-ID: <Pine.LNX.4.53.0309140652280.26877@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 48: Reachability of routable addresses Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 13, 2003 Reference: Document: LLMNR-23 Comment type: T Priority: S Section: 3 Rationale/Explanation of issue: If a host has both link-scope and routable addresses, it should only prefer the routable address in responses if that routable address is reachable on the interface on which the query was received. Otherwise the query sender could end up resolving a name to an address that would not respond to ARP or ND/NS. In Section 3 change: "[2] 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." To: "[2] A responder with both link-local and routable addresses on an interface MUST respond to LLMNR queries for A/AAAA RRs only with routable address(es) reachable on the interface receiving the query. This encourages use of routable address(es) for establishment of new connections." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 14 10:58: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 KAA03506 for <dnsext-archive@lists.ietf.org>; Sun, 14 Sep 2003 10:58:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yYGN-000OJ2-RP for namedroppers-data@psg.com; Sun, 14 Sep 2003 14:54:07 +0000 Received: from [212.16.99.49] (helo=burp.tkv.asdf.org) by psg.com with esmtp (Exim 4.22) id 19yYFs-000O9z-6C for namedroppers@ops.ietf.org; Sun, 14 Sep 2003 14:53:36 +0000 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) with ESMTP id h8EErCZA020037; Sun, 14 Sep 2003 17:53:12 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-6.4) id h8EErCCI020033; Sun, 14 Sep 2003 17:53:12 +0300 Date: Sun, 14 Sep 2003 17:53:12 +0300 Message-Id: <200309141453.h8EErCCI020033@burp.tkv.asdf.org> From: Markku Savela <msa@burp.tkv.asdf.org> To: aboba@internaut.com CC: namedroppers@ops.ietf.org In-reply-to: <Pine.LNX.4.53.0309140652280.26877@internaut.com> (message from Bernard Aboba on Sun, 14 Sep 2003 06:53:15 -0700 (PDT)) Subject: Re: LLMNR Issue 48: Reachability of routable addresses References: <Pine.LNX.4.53.0309140652280.26877@internaut.com> X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In Section 3 change: > > "[2] 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." > > To: > > "[2] A responder with both link-local and routable addresses > on an interface MUST respond to LLMNR queries for > A/AAAA RRs only with routable address(es) reachable > on the interface receiving the query. This encourages > use of routable address(es) for establishment of new > connections." Object to must "MUST". I want to be able to reply with link-local address, if the query src is using link-local address. And, I reply with global addresses, if query source address is global. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 15 03:52:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15817 for <dnsext-archive@lists.ietf.org>; Mon, 15 Sep 2003 03:52:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19ynzi-000BSR-Pm for namedroppers-data@psg.com; Mon, 15 Sep 2003 07:41:58 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19ynz8-000BKy-Vt for namedroppers@ops.ietf.org; Mon, 15 Sep 2003 07:41:23 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 147CB4FC53; Mon, 15 Sep 2003 09:41:22 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8723B4FC19 for <namedroppers@ops.ietf.org>; Mon, 15 Sep 2003 09:41:21 +0200 (CEST) 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 h8F7fLWt007980 for <namedroppers@ops.ietf.org>; Mon, 15 Sep 2003 09:41:21 +0200 Date: Mon, 15 Sep 2003 09:41:21 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: WGLC Summary wcard-clarify Message-Id: <20030915094121.57be89d8.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.485159 X-RIPE-Signature: 8d212208a308f12db2ac17d3f569c86b X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Colleagues, This is a summary of the WGLC on wcard-clarify-01.txt. The overall consensus of the working-group is that clarification of wildcard behavior is necessary and that the document is to proceed on the standard track. There are a number of textual and style nits that need to be fixed. In addition there has been a mistake in the label definition that will be fixed. Two issues have been opened that will need to be fixed: - multi-wild cards being described in the draft as legal when they are SHOULD NOT in the original - 1034 says not to cache the answer to a QNAME=*.<something>. Essentially this means that special processing is needed. Question is if the document should specify that caching of answers to QNAME=*.<something> is allowed with the provision that the caches must not try to be intelligent and perform synthesis themselves. There were a number of other issues brought up during last call. - It was argued that there are other ways to synthesize records and other ways to transfer this data between servers. The document clarifies the textual representation that is needed for AXFR and in the RFC1034/1035 zone file format. From the IETF perspective (documents in standard, or standard track) there are no other methods for zone file transfers or other rules for record synthesize. Hence this issue is out of scope. - There was an argument over the meaning and the interpretation by caches of name errors. This issue is argued to be out of scope since the document; - Defines the behavior of authoritative servers only and; - Does not redefine the definitions in RFC 1034. How we proceed. I'll start new threads, with deadlines and default actions, on the issues that are still open. The document editor will incorporate the textual nits and the result on the discussion of the open issues and will then send a updated version to the working group for 2 weeks review. If no new issues are raised that document will be forwarded to the IESG. -- Olaf Kolkman DNSEXT Co-Chair. PS. I'll use these two issues to experiment with the issue tracker announced in a previous mail. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 15 03:52: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 DAA15855 for <dnsext-archive@lists.ietf.org>; Mon, 15 Sep 2003 03:52:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yo5x-000CfM-Ak for namedroppers-data@psg.com; Mon, 15 Sep 2003 07:48:25 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19yo53-000CVi-OC for namedroppers@ops.ietf.org; Mon, 15 Sep 2003 07:47:29 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 24E8E4FC53; Mon, 15 Sep 2003 09:47:29 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A17AD4FC19 for <namedroppers@ops.ietf.org>; Mon, 15 Sep 2003 09:47:28 +0200 (CEST) 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 h8F7lSWt009352 for <namedroppers@ops.ietf.org>; Mon, 15 Sep 2003 09:47:28 +0200 Date: Mon, 15 Sep 2003 09:47:28 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: WCARD-CLARIFY ISSUE: caching of !NAME=*.<something> Message-Id: <20030915094728.4cc6f551.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.499936 X-RIPE-Signature: d72e440bb91b9e32dc6832b87c21f2bd X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit name: Olaf Kolkman email: olaf at ripe.net Date: Sep 13, 2003 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01670.html Type: Text Priority: Urgent Document: draft-ietf-dnsext-wcard-clarify-01 Section: 4 Impact of a Wild Card Domain In a Query Message or in an RDATA field Rationale/Explanation of issue: The issue is that the draft updates RFC1034 with respect to *.<something> queries. Does the working group want this to happen. http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01670.html: > > | R4.1 A wild card domain name acting as a QNAME MUST be treated as any > | other QNAME, there MUST be no special processing accorded it. > > > This appear to be over-qualified; it isn't valid in the point of view > of a client. Specifically: RFC 1034 section 4.3.3 says results from > wildcard queries should not be cached. Hence there actually is > special processing accorded to wild card labels in a QNAME. and (among others): http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01721.html > .... > I do not, however, understand why a cache shouldn't remember a response > to a "wildcard" (i.e. "*.<something>") query. Probably that was meant to > discourage synthesis of responses by (non-authoritative) caches. Wildcard > synthesis should of course only be performed by an authoritative server. > Proposed change: Keep the existing text; thereby updating RFC1034, but allowing caches to stick to 1034 behavior as specified by the text below: R4.1 A wild card domain name acting as a QNAME MUST be treated as any other QNAME, caches MAY not cache the result of a wildcard query but there MUST be no other special processing accorded it. If a cache caches the result of a wildcard query it is by virtue of the above not allowed to use the data for synthesis of answers. If a wild card domain name appears in the RDATA of a CNAME RR or any other RR that has a domain name in it, the same rule applies. In the ...etc.. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 15 03:56: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 DAA15970 for <dnsext-archive@lists.ietf.org>; Mon, 15 Sep 2003 03:56:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yo9j-000DWs-Qf for namedroppers-data@psg.com; Mon, 15 Sep 2003 07:52:19 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19yo9E-000DOM-FD for namedroppers@ops.ietf.org; Mon, 15 Sep 2003 07:51:48 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D491C4FC53; Mon, 15 Sep 2003 09:51:47 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 604634FC39 for <namedroppers@ops.ietf.org>; Mon, 15 Sep 2003 09:51:47 +0200 (CEST) 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 h8F7plWt010120 for <namedroppers@ops.ietf.org>; Mon, 15 Sep 2003 09:51:47 +0200 Date: Mon, 15 Sep 2003 09:51:47 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: WCARD-CLARIFY ISSUE: Multi wildcard label dnames Message-Id: <20030915095147.1bee8cfd.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.499865 X-RIPE-Signature: c3382ac28bdb45c76b0825522b4ce966 X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01670.html Type: T Priority: U Document: draft-ietf-dnsext-wcard-clarify-01 Section: last note of section 2, and the entire appendix A Rationale/Explanation of issue: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01670.html: > The last note of section 2, and the entire appendix A, seems at least > partially inconsistent with RFC 1034. Specifically: RFC 1034 says a > wildcard RR look like *.<anydomain> where <anydomain> should not > contain other * labels. So *.*.example is not a valid wild card > according to RFC 1034, contrary to what the draft claims. If > something needs to be clarified, how about making a clarification > saying that <anydomain> 'MUST NOT' contain other * labels? If the > draft intend to redefine RFC 1034 on what <anydomain> may contain, > that should IMHO be made more clear, as the abstract now give the > impression that the draft doesn't alter any definitions. Also see the discussion thread starting with: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01700.html Proposed Change Modify the draft so that it states it updates 1034 (on one point) and in section 2 add the following (the text needs to be mangled in): RFC1034 section 4.3.3 states: # The owner name of the wildcard RRs is of the form "*.<anydomain>", # where <anydomain> is any domain name. <anydomain> should not contain # other * labels, and should be in the authoritative data of the zone. The "should not" in the above sentence implies that the alternative implementation, i.e. domain names with multiple wildcards, are possible. However, there is no specification of the synthesis behavior for those alternative cases. Hence this document updates RFC1034 by replacing the definition as quoted above by R2.1. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 15 12:10: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 MAA09658 for <dnsext-archive@lists.ietf.org>; Mon, 15 Sep 2003 12:10:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yvhn-00036R-W2 for namedroppers-data@psg.com; Mon, 15 Sep 2003 15:55:59 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 19yvhD-000305-VF for namedroppers@ops.ietf.org; Mon, 15 Sep 2003 15:55:24 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h8FFtKM08786; Mon, 15 Sep 2003 22:55:20 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8FFtDH17716; Mon, 15 Sep 2003 22:55:14 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Olaf M. Kolkman" <olaf@ripe.net> cc: namedroppers@ops.ietf.org Subject: Re: WCARD-CLARIFY ISSUE: caching of !NAME=*.<something> In-Reply-To: <20030915094728.4cc6f551.olaf@ripe.net> References: <20030915094728.4cc6f551.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 2003 22:55:13 +0700 Message-ID: <2229.1063641313@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 15 Sep 2003 09:47:28 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> Message-ID: <20030915094728.4cc6f551.olaf@ripe.net> | Proposed change: | | Keep the existing text; thereby updating RFC1034, but allowing caches | to stick to 1034 behavior as specified by the text below: | | R4.1 A wild card domain name acting as a QNAME MUST be treated as any | other QNAME, caches MAY not cache the result of a wildcard query but | there MUST be no other special processing accorded it. I suspect that the document should be a bit more brutal than that. That is, it should say, somewhere very early ... Wildcard processing for a zone is performed only at authoritative servers for the zone. Resolvers, other servers, and caches, MUST NOT attempt to interpret wildcards. There isn't any real need to say that caches aren't required to cache the result of an explicit QNAME='*.domain' lookup - they're not required to cache anything, that is the very nature of a cache. I don't see any particular point in prohibiting the answer from being cached however, so changing that bit of 1034 would be OK. But nor do I believe that this is an important change to make. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 15 12:11: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 MAA09700 for <dnsext-archive@lists.ietf.org>; Mon, 15 Sep 2003 12:11:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19yvrm-00056U-U5 for namedroppers-data@psg.com; Mon, 15 Sep 2003 16:06:18 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 19yvr3-0004wL-0n for namedroppers@ops.ietf.org; Mon, 15 Sep 2003 16:05:37 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h8FG5RM09159; Mon, 15 Sep 2003 23:05:30 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8FG5DH23192; Mon, 15 Sep 2003 23:05:13 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Olaf M. Kolkman" <olaf@ripe.net> cc: namedroppers@ops.ietf.org Subject: Re: WCARD-CLARIFY ISSUE: Multi wildcard label dnames In-Reply-To: <20030915095147.1bee8cfd.olaf@ripe.net> References: <20030915095147.1bee8cfd.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Sep 2003 23:05:13 +0700 Message-ID: <23378.1063641913@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 15 Sep 2003 09:51:47 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> Message-ID: <20030915095147.1bee8cfd.olaf@ripe.net> | Proposed Change | | Modify the draft so that it states it updates 1034 (on one point) and | in section 2 add the following (the text needs to be mangled in): | | | RFC1034 section 4.3.3 states: | | # The owner name of the wildcard RRs is of the form "*.<anydomain>", | # where <anydomain> is any domain name. <anydomain> should not contain | # other * labels, and should be in the authoritative data of the zone. | | The "should not" in the above sentence implies that the alternative | implementation, i.e. domain names with multiple wildcards, are | possible. However, there is no specification of the synthesis behavior | for those alternative cases. Hence this document updates RFC1034 by | replacing the definition as quoted above by R2.1. No, that's never what it meant. Please, do remember that a label can be anything at all (between 1 & 63 octets, inclusive), including '*'. A '*' (in a zone file) as a leaf label is a wildcard. A '*' occurring anywhere else is simply a character. The "should not" in 1034 is because it would lead to confusion, people would have bizarre expectations on what they might expect to happen if one was present at such a place - not because it causes any problems for the specification of the protocol (including the wildcard parts of it) or for implementations. The wildcard stuff in 1034/5 should really need no clarifications, everything is there, nothing really needs to be added or subtracted from what it says. The only real reason we're doing this at all is because so many people manage to mis-interpret it - which mostly really means that they don't read the text (carefully) at all, but simply guess. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Sep 16 00:50:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11187 for <dnsext-archive@lists.ietf.org>; Tue, 16 Sep 2003 00:50:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19z7by-000H5D-4h for namedroppers-data@psg.com; Tue, 16 Sep 2003 04:38:46 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.22) id 19z7bR-000H2G-7H for namedroppers@ops.ietf.org; Tue, 16 Sep 2003 04:38:13 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1DF7118D1 for <namedroppers@ops.ietf.org>; Tue, 16 Sep 2003 00:37:40 -0400 (EDT) Date: Tue, 16 Sep 2003 00:37:40 -0400 From: Rob Austein <sra+namedroppers@hactrn.net> To: namedroppers <namedroppers@ops.ietf.org> Subject: New DNSSECbis -intro and -records drafts User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030916043740.1DF7118D1@thrintun.hactrn.net> X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I just posted draft-ietf-dnsext-dnssec-intro-06.txt and draft-ietf-dnsext-dnssec-records-04.txt to the Internet-Drafts administrator. draft-ietf-dnsext-dnssec-protocol-02.txt will follow later this week if Hurricane Isabel doesn't get too exciting. These are snapshots of work in progress, which we're pushing out now because the previous versions recently expired from the Internet-Drafts repository. We -think- we've got -intro and -records back into a consistant state after incorporating -2525typecode-change (the delay in shipping the snapshot of -protocol is checking to make sure that we've got that cleaned up too). We have not yet incorporated the answers to all the questions that were recently resolved on the mailing list, so ordinarily we'd holding the new drafts until we had that stuff done too, but given that the previous versions are no longer available for review, we felt it best to push out a snapshot now, then continue with the work already on our plates. As always, please send comments either to namedroppers or, in the case of minor editoral junk that's not worth bothering the whole WG, to dnssec-editors@east.isi.edu. Thanks! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Sep 16 03:44: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 DAA28156 for <dnsext-archive@lists.ietf.org>; Tue, 16 Sep 2003 03:44:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zAMw-000KsT-Am for namedroppers-data@psg.com; Tue, 16 Sep 2003 07:35:26 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 19zAMG-000Kia-3W for namedroppers@ops.ietf.org; Tue, 16 Sep 2003 07:34:44 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 627BC4E02C; Tue, 16 Sep 2003 09:34:43 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id D8F9B4E05E; Tue, 16 Sep 2003 09:34:42 +0200 (CEST) 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 h8G7YgWt017831; Tue, 16 Sep 2003 09:34:42 +0200 Date: Tue, 16 Sep 2003 09:34:42 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Robert Elz <kre@munnari.OZ.AU> Cc: namedroppers@ops.ietf.org Subject: Re: WCARD-CLARIFY ISSUE: Multi wildcard label dnames Message-Id: <20030916093442.146f7fc6.olaf@ripe.net> In-Reply-To: <23378.1063641913@munnari.OZ.AU> References: <20030915095147.1bee8cfd.olaf@ripe.net> <23378.1063641913@munnari.OZ.AU> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.0 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.499831 X-RIPE-Signature: e69c22f6c84300bd105629f4fcc86d38 X-Spam-Status: No, hits=-2.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 15 Sep 2003 23:05:13 +0700 Robert Elz <kre@munnari.OZ.AU> wrote: > > | Proposed Change > | > | Modify the draft so that it states it updates 1034 (on one point) and > | in section 2 add the following (the text needs to be mangled in): > | > | > | RFC1034 section 4.3.3 states: > | > | # The owner name of the wildcard RRs is of the form "*.<anydomain>", > | # where <anydomain> is any domain name. <anydomain> should not contain > | # other * labels, and should be in the authoritative data of the zone. > | > | The "should not" in the above sentence implies that the alternative > | implementation, i.e. domain names with multiple wildcards, are > | possible. However, there is no specification of the synthesis behavior > | for those alternative cases. Hence this document updates RFC1034 by > | replacing the definition as quoted above by R2.1. > > No, that's never what it meant. Please, do remember that a label can > be anything at all (between 1 & 63 octets, inclusive), including '*'. > > A '*' (in a zone file) as a leaf label is a wildcard. A '*' occurring > anywhere else is simply a character. I am happy with that explanation -- this document updating 1034 does not feel good -- but I think that the clarification draft should at least give an explanation for the quoted text since some people, including myself, got confused by the "<anydomain> should not contain other * labels" So lets add something along the lines of: # The owner name of the wildcard RRs is of the form "*.<anydomain>", # where <anydomain> is any domain name. <anydomain> should not contain # other * labels, and should be in the authoritative data of the zone. The "should not contain other * labels" should be read as "Occurrences of the label 0x012a any where in <anydomain> must not be interpreted as wildcard labels but as an ordinary character sequences that do not allow for substitution." I am sure this wording can be refined. > The only real reason we're doing this at all is because so many people > manage to mis-interpret it - which mostly really means that they don't > read the text (carefully) at all, but simply guess. Hey this sounds familiar... just let "it" refer to 'the scripture' and we have theology ;-) -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Sep 16 10:29: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 KAA17247 for <dnsext-archive@lists.ietf.org>; Tue, 16 Sep 2003 10:29:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zGhQ-000PJs-6W for namedroppers-data@psg.com; Tue, 16 Sep 2003 14:21:00 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 19zGgO-000P6g-4d for namedroppers@ops.ietf.org; Tue, 16 Sep 2003 14:19:56 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16266; Tue, 16 Sep 2003 10:19:49 -0400 (EDT) Message-Id: <200309161419.KAA16266@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-records-04.txt Date: Tue, 16 Sep 2003 10:19:48 -0400 X-Spam-Status: No, hits=2.1 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_ORBS, TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-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 : Resource Records for DNS Security Extensions Author(s) : R. Arends et al. Filename : draft-ietf-dnsext-dnssec-records-04.txt Pages : 36 Date : 2003-9-16 This document is part of a family of documents that describes the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existance (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-records-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16103656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-records-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-records-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16103656.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Sep 16 10:30: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 KAA17409 for <dnsext-archive@lists.ietf.org>; Tue, 16 Sep 2003 10:30:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19zGgr-000PD2-SO for namedroppers-data@psg.com; Tue, 16 Sep 2003 14:20:25 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 19zGgL-000P5k-Cx for namedroppers@ops.ietf.org; Tue, 16 Sep 2003 14:19:53 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16249; Tue, 16 Sep 2003 10:19:44 -0400 (EDT) Message-Id: <200309161419.KAA16249@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-intro-06.txt Date: Tue, 16 Sep 2003 10:19:44 -0400 X-Spam-Status: No, hits=2.1 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_ORBS, TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Introduction and Requirements Author(s) : R. Arends, R. Austein, D. Massey, M. Larson, S. Rose Filename : draft-ietf-dnsext-dnssec-intro-06.txt Pages : 23 Date : 2003-9-16 The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the group of documents that collectively describe DNSSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dnssec-intro-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-06.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-9-16103640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-intro-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-intro-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16103640.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 19 22:20: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 WAA03612 for <dnsext-archive@lists.ietf.org>; Fri, 19 Sep 2003 22:20:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A0X6v-000MBL-3I for namedroppers-data@psg.com; Sat, 20 Sep 2003 02:04:33 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.22) id 1A0X6P-000M7U-Ub for namedroppers@ops.ietf.org; Sat, 20 Sep 2003 02:04:01 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.9/8.12.9) with ESMTP id h8K241J1006237 for <namedroppers@ops.ietf.org>; Fri, 19 Sep 2003 19:04:01 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id <T64c7a51072118064e1148@mailgate1.apple.com>; Fri, 19 Sep 2003 19:03:33 -0700 Received: from [17.219.194.59] (vpn-scv-x3-59.apple.com [17.219.194.59]) by scv3.apple.com (8.12.9/8.12.9) with SMTP id h8K23cCn024691; Fri, 19 Sep 2003 19:03:38 -0700 (PDT) Message-Id: <200309200203.h8K23cCn024691@scv3.apple.com> Subject: Re: LLMNR interoperability with Rendezvous? Date: Fri, 19 Sep 2003 19:04:01 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire <cheshire@apple.com> To: "John Schnizlein" <jschnizl@cisco.com>, "Michael Richardson" <mcr@sandelman.ottawa.on.ca> cc: <namedroppers@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >This entire episode, including the reversal of the rough consensus >favoring TTL=1 for link-local traffic in the ZeroConf WG, brings to mind >the freshman engineering example in which a column is removed from a >room for aesthetic reasons, rendering the entire building weak. >Please do not mess with the foundation without compelling reasons! John, you have this completely backwards. Up to draft-ietf-dnsext-mdns-17.txt, it said: >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. It was only a couple of months ago, after Apple and other companies had been shipping products for over a year, that DNSEXT decided to reverse its consensus. You may remember that I was one of the people who argued for TTL=1 in the first place, but I was swayed by the working group consensus, so we shipped with TTL=255, and then the working group changed its mind back again. Stuart Cheshire <cheshire@apple.com> * 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Sep 23 10:11: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 KAA14844 for <dnsext-archive@lists.ietf.org>; Tue, 23 Sep 2003 10:11:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1neO-0009t8-Qw for namedroppers-data@psg.com; Tue, 23 Sep 2003 13:56:20 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A1neG-0009rr-Mj for namedroppers@ops.ietf.org; Tue, 23 Sep 2003 13:56:12 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13449; Tue, 23 Sep 2003 09:56:04 -0400 (EDT) Message-Id: <200309231356.JAA13449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-09.txt Date: Tue, 23 Sep 2003 09:56:04 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : KEY RR Secure Entry Point Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-09.txt Pages : 9 Date : 2003-9-23 With the Delegation Signer (DS) resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. The flag bit is intended to assist in oprational procedures to correctly generate DS resource records, or to indicate what keys are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-keyrr-key-signing-flag-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-09.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-9-23101549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-23101549.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Sep 23 10:17: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 KAA15621 for <dnsext-archive@lists.ietf.org>; Tue, 23 Sep 2003 10:17:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1ntK-000B72-G6 for namedroppers-data@psg.com; Tue, 23 Sep 2003 14:11:46 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 1A1nsh-000B3X-Bm for namedroppers@ops.ietf.org; Tue, 23 Sep 2003 14:11:07 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 57A856CC; Tue, 23 Sep 2003 10:10:57 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id ED5CA674 for <namedroppers@ops.ietf.org>; Tue, 23 Sep 2003 10:10:56 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1.3) with ESMTP id 780261; Tue, 23 Sep 2003 10:06:25 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a05111b03bb9603ede706@[192.168.1.100]> Date: Tue, 23 Sep 2003 10:11:00 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <edlewis@arin.net> Subject: list archives Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_10 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The main page of the archives appears to be broken: http://ops.ietf.org/lists/namedroppers/ The only message on there says "welcome to the lamb@psg.com mailing list". The namedroppers messages are still on the site (eg, http://ops.ietf.org/lists/ namedroppers/namedroppers.2003/maillist.html), just not linked to from that page. I have one other request, can the date listing include the date and time of the message? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Sep 23 13:28: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 NAA26154 for <dnsext-archive@lists.ietf.org>; Tue, 23 Sep 2003 13:28:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A1qqB-000PyJ-H0 for namedroppers-data@psg.com; Tue, 23 Sep 2003 17:20:43 +0000 Received: from [195.66.31.71] (helo=paf.se) by psg.com with esmtp (Exim 4.22) id 1A1qpf-000Ptu-1A for namedroppers@ops.ietf.org; Tue, 23 Sep 2003 17:20:11 +0000 Received: by paf.se (CommuniGate Pro PIPE 4.1) with PIPE id 1170352; Tue, 23 Sep 2003 19:19:09 +0200 Received: from localhost [127.0.0.1] by argc.paf.se with SpamAssassin (2.55 1.174.2.19-2003-05-19-exp); Tue, 23 Sep 2003 19:18:55 +0200 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-09.txt Date: Tue, 23 Sep 2003 09:56:04 -0400 Message-Id: <200309231356.JAA13449@ietf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_3F70807F.2FD31CBE" X-Spam-Status: No, hits=3.0 required=5.0 tests=DATE_IN_PAST_03_06,NO_REAL_NAME,TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------------=_3F70807F.2FD31CBE Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit This mail is probably spam. The original message has been attached along with this report, so you can recognize or block similar unwanted mail in future. See http://spamassassin.org/tag/ for more details. Content preview: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : KEY RR Secure Entry Point Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-09.txt Pages : 9 Date : 2003-9-23 [...] Content analysis details: (6.20 points, 5 required) NO_REAL_NAME (0.8 points) From: does not include a real name TO_MALFORMED (1.5 points) To: has a malformed address RCVD_IN_OSIRUSOFT_COM (0.6 points) RBL: Received via a relay in relays.osirusoft.com [RBL check: found 40.6.151.132.relays.osirusoft.com.] X_OSIRU_OPEN_RELAY (2.9 points) RBL: DNSBL: sender is Confirmed Open Relay MIME_BOUND_NEXTPART (0.4 points) Spam tool pattern in MIME boundary The original message did not contain plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. ------------=_3F70807F.2FD31CBE Content-Type: message/rfc822; x-spam-type=original Content-Description: original message before SpamAssassin Content-Disposition: attachment Return-Path: <owner-ietf-announce@ietf.org> Envelope-To: eva@tibbir.se X-Spam-Status: SpamAssassin Failed Received: from asgard.ietf.org ([132.151.6.40] verified) by paf.se (CommuniGate Pro SMTP 4.1) with ESMTP id 1170351 for eva@tibbir.se; Tue, 23 Sep 2003 19:18:43 +0200 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1A1nlj-00087p-Hd for ietf-announce-list@asgard.ietf.org; Tue, 23 Sep 2003 10:03:55 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1A1neH-0005FP-Al for all-ietf@asgard.ietf.org; Tue, 23 Sep 2003 09:56:13 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13449; Tue, 23 Sep 2003 09:56:04 -0400 (EDT) Message-Id: <200309231356.JAA13449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-09.txt Date: Tue, 23 Sep 2003 09:56:04 -0400 Sender: owner-ietf-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : KEY RR Secure Entry Point Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-09.txt Pages : 9 Date : 2003-9-23 With the Delegation Signer (DS) resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. The flag bit is intended to assist in oprational procedures to correctly generate DS resource records, or to indicate what keys are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-keyrr-key-signing-flag-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-09.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-9-23101549.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-23101549.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------=_3F70807F.2FD31CBE-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 02:11: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 CAA10502 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 02:11:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A22fZ-0004G6-9e for namedroppers-data@psg.com; Wed, 24 Sep 2003 05:58:33 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.22) id 1A22fH-0004Di-9Q for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 05:58:15 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.22) id 1A2286-00079A-Dp for namedroppers@ops.ietf.org; Tue, 23 Sep 2003 22:23:58 -0700 Message-Id: <200309232223.h8NMNPI15739@boreas.isi.edu> In-Reply-To: <20030820100735.39120ccd.olaf@ripe.net> from "Olaf M. Kolkman" at "Aug 20, 3 10:07:35 am" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Bill Manning <bmanning@ISI.EDU> Subject: Re: DNSEXT WGLC: Wildcard Clarify To: olaf@ripe.net (Olaf M. Kolkman) Date: Tue, 23 Sep 2003 15:23:24 -0700 (PDT) Cc: namedroppers@ops.ietf.org X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to <listname>-owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] What is the current status of this document? % % This is a last call for the 'Wildcard Clarify' document. % % Title: % Clarifying the Role of Wild Card Domains in the Domain Name System % % URL: % http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-01.txt % % Please read the document, send in motivated statements of support, % opposition, clarifications &c. This protocol is on standards track, % if you disagree with that please speak up and motivate. % % The last call period is a little over 2 weeks and will conclude Sunday % September 7, 2003. % % If there is no discussion about this document the default action by % chairs is to advance it as the need for this document is clearly % motivated by the authors and not opposed in recent discussion. % % % -------------------- % % % % Abstract: % % The definition of wild cards is recast from the original in RFC % 1034, in words that are more specific and in line with RFC 2119. % This document is meant to supplement the definition in RFC 1034 and % to alter neither the spirit nor intent of that definition. % % From the Introduction: % % Why is this document needed? Empirical evidence suggests that the % words in RFC 1034 are not clear enough. There exist a number of % implementations that have strayed (each differently) from that % definition. There also exists a misconception of operators that the % wild card can be used to add a specific RR type to all names, such % as the MX RR example cited above. This document is also needed as % input to efforts to extend DNS, such as the DNS Security Extensions % [RFC 2535]. Lack of a clear base specification has proven to result % in extension documents that have unpredictable consequences. (This % is true in general, not just for DNS.) % % -------------------- % % % % -- Olaf % DNSEXT Co-Chair % % % % -- % to unsubscribe send a message to namedroppers-request@ops.ietf.org with % the word 'unsubscribe' in a single line as the message text body. % archive: <http://ops.ietf.org/lists/namedroppers/> % -- --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 04:07: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 EAA01134 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 04:07:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A24YT-000FRL-H6 for namedroppers-data@psg.com; Wed, 24 Sep 2003 07:59:21 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A24Xt-000FOJ-Dj for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 07:58:45 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id C86764ECF0; Wed, 24 Sep 2003 09:58:44 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 671464ECE9; Wed, 24 Sep 2003 09:58:44 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h8O7wiJO030330; Wed, 24 Sep 2003 09:58:44 +0200 Date: Wed, 24 Sep 2003 09:58:44 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Bill Manning <bmanning@ISI.EDU> Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Wildcard Clarify Message-Id: <20030924095844.117e4742.olaf@ripe.net> In-Reply-To: <200309232223.h8NMNPI15739@boreas.isi.edu> References: <20030820100735.39120ccd.olaf@ripe.net> <200309232223.h8NMNPI15739@boreas.isi.edu> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.012963 X-RIPE-Signature: ad10c3044ac0dda4ab0cdd4d223df8d8 X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 23 Sep 2003 15:23:24 -0700 (PDT) Bill Manning <bmanning@ISI.EDU> wrote: > > What is the current status of this document? > WGLC Summary: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01756.html Open Issues: thread starting at: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01758.html and thread starting at: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01757.html The discussion on the issues has died a quiet death. Review of those by the list would be aprreciated. The issues will need to be addressed by the editor. The editor (Ed Lewis) needs to do this in spare time and he does not have much of that lately. Volunteers to help with finishing this document please contact Ed and the chairs. We would like to get progress on this document. -- Olaf DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 07:28: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 HAA07641 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 07:28:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A27dt-0000a5-9I for namedroppers-data@psg.com; Wed, 24 Sep 2003 11:17:09 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A27dJ-0000YU-0B for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 11:16:33 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 2CF5E4E2B5; Wed, 24 Sep 2003 13:16:32 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C1E744E233 for <namedroppers@ops.ietf.org>; Wed, 24 Sep 2003 13:16:31 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h8OBGVJO007413 for <namedroppers@ops.ietf.org>; Wed, 24 Sep 2003 13:16:31 +0200 Date: Wed, 24 Sep 2003 13:16:31 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional Message-Id: <20030924131631.1dfb4410.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.480655 X-RIPE-Signature: 5cd649f22a698b714dc2de89bcaac200 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I want to point attention to draft-ietf-dnsext-dnssec-records-04 section 1.3.1 1.3.1 Open Technical Issues The cryptographic algorithm types (Appendix A) requires input from the working group. The DSA algorithm was moved to OPTIONAL. This had strong consensus in workshops and various discussions and a separate internet draft solely to move DSA from MANDATORY to OPTIONAL seemed excessive. This draft solicits input on that proposed change. Please speak for or against this. Default action will be to accept DSA moved to OPTIONAL as working-group concensus. Review of this I-D and the dnssec-intro document is appreciated. -- Olaf Kolkman DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 09:22: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 JAA12914 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 09:22:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A29Tz-0007H0-FN for namedroppers-data@psg.com; Wed, 24 Sep 2003 13:15:03 +0000 Received: from [192.52.233.66] (helo=mlbxsmtp2.harris.com) by psg.com with esmtp (Exim 4.22) id 1A29TQ-0007ER-1a for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 13:14:28 +0000 Received: from mail pickup service by mlbxsmtp2.harris.com with Microsoft SMTPSVC; Wed, 24 Sep 2003 09:02:51 -0400 Received: from psg.com ([147.28.0.62]) by mlbxsmtp2.harris.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Sep 2003 07:31:02 -0400 Received: from lserv by psg.com with local (Exim 4.22) id 1A27dt-0000a5-9I for namedroppers-data@psg.com; Wed, 24 Sep 2003 11:17:09 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A27dJ-0000YU-0B for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 11:16:33 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 2CF5E4E2B5; Wed, 24 Sep 2003 13:16:32 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id C1E744E233 for <namedroppers@ops.ietf.org>; Wed, 24 Sep 2003 13:16:31 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h8OBGVJO007413 for <namedroppers@ops.ietf.org>; Wed, 24 Sep 2003 13:16:31 +0200 Date: Wed, 24 Sep 2003 13:16:31 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional Message-Id: <20030924131631.1dfb4410.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.480655 X-RIPE-Signature: 5cd649f22a698b714dc2de89bcaac200 X-OriginalArrivalTime: 24 Sep 2003 11:31:03.0126 (UTC) FILETIME=[55FFAF60:01C3828F] X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I want to point attention to draft-ietf-dnsext-dnssec-records-04 section 1.3.1 1.3.1 Open Technical Issues The cryptographic algorithm types (Appendix A) requires input from the working group. The DSA algorithm was moved to OPTIONAL. This had strong consensus in workshops and various discussions and a separate internet draft solely to move DSA from MANDATORY to OPTIONAL seemed excessive. This draft solicits input on that proposed change. Please speak for or against this. Default action will be to accept DSA moved to OPTIONAL as working-group concensus. Review of this I-D and the dnssec-intro document is appreciated. -- Olaf Kolkman DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 09:49: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 JAA14103 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 09:49:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A29xt-0009Ho-3w for namedroppers-data@psg.com; Wed, 24 Sep 2003 13:45:57 +0000 Received: from [66.92.86.178] (helo=zydeco.netbusters.com) by psg.com with esmtp (Exim 4.22) id 1A29xL-0009Fh-Nb for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 13:45:25 +0000 Received: by zydeco.netbusters.com (Postfix, from userid 513) id AE208B63B2; Wed, 24 Sep 2003 13:43:03 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id AAF097EC1D; Wed, 24 Sep 2003 09:43:03 -0400 (EDT) Date: Wed, 24 Sep 2003 09:43:03 -0400 (EDT) From: Donald Eastlake 3rd <dee3@torque.pothole.com> X-X-Sender: dee3@zydeco.netbusters.com To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-Reply-To: <20030924131631.1dfb4410.olaf@ripe.net> Message-ID: <Pine.LNX.4.44.0309240931060.25181-100000@zydeco.netbusters.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm in favor of the change. 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 On Wed, 24 Sep 2003, Olaf M. Kolkman wrote: > Date: Wed, 24 Sep 2003 13:16:31 +0200 > From: Olaf M. Kolkman <olaf@ripe.net> > To: namedroppers@ops.ietf.org > Subject: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional > > > I want to point attention to draft-ietf-dnsext-dnssec-records-04 section 1.3.1 > > 1.3.1 Open Technical Issues > > The cryptographic algorithm types (Appendix A) requires input from > the working group. The DSA algorithm was moved to OPTIONAL. This > had strong consensus in workshops and various discussions and a > separate internet draft solely to move DSA from MANDATORY to OPTIONAL > seemed excessive. This draft solicits input on that proposed change. > > Please speak for or against this. > > Default action will be to accept DSA moved to OPTIONAL as working-group concensus. > > > Review of this I-D and the dnssec-intro document is appreciated. > > -- Olaf Kolkman > DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 10:47: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 KAA19173 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 10:47:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2Ai2-000Cc7-ID for namedroppers-data@psg.com; Wed, 24 Sep 2003 14:33:38 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.22) id 1A2AhU-000CaC-Lp for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 14:33:04 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [193.12.107.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id DBEB31956E; Wed, 24 Sep 2003 16:33:02 +0200 (CEST) Date: Wed, 24 Sep 2003 16:33:00 +0200 (CEST) From: Jakob Schlyter <jakob@rfc.se> To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-Reply-To: <20030924131631.1dfb4410.olaf@ripe.net> Message-ID: <Pine.OSX.4.56.0309241632150.20267@criollo.schlyter.se> References: <20030924131631.1dfb4410.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 24 Sep 2003, Olaf M. Kolkman wrote: > I want to point attention to draft-ietf-dnsext-dnssec-records-04 section 1.3.1 > > 1.3.1 Open Technical Issues > > The cryptographic algorithm types (Appendix A) requires input from > the working group. The DSA algorithm was moved to OPTIONAL. This > had strong consensus in workshops and various discussions and a > separate internet draft solely to move DSA from MANDATORY to OPTIONAL > seemed excessive. This draft solicits input on that proposed change. > > Please speak for or against this. > > Default action will be to accept DSA moved to OPTIONAL as working-group > concensus. yes, I think we should move DSA to optional. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 11:04: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 LAA20434 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 11:04:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2B7y-000EQr-1A for namedroppers-data@psg.com; Wed, 24 Sep 2003 15:00:26 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A2B7S-000ENl-KN for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 14:59:54 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 074F54FDE7; Wed, 24 Sep 2003 16:59:54 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 8F6824FDE6; Wed, 24 Sep 2003 16:59:53 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h8OExrJO028593; Wed, 24 Sep 2003 16:59:53 +0200 Date: Wed, 24 Sep 2003 16:59:53 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org, Sam Weiler <weiler@watson.org> Cc: scottr@nist.gov Subject: Re: DNSSECbis Q-2: degradation attack Message-Id: <20030924165953.1dcf6641.olaf@ripe.net> In-Reply-To: <Pine.NEB.3.96L.1030911092654.86224A-100000@fledge.watson.org> References: <003501c37858$8217d140$b9370681@barnacle> <Pine.NEB.3.96L.1030911092654.86224A-100000@fledge.watson.org> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.046384 X-RIPE-Signature: 6a686caaa6fc742d3f5aa1d5ff899201 X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_20,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Colleagues, I reviewed the thread on the "degradation attack" to see if there is consensus. Althought there were some off-topic digressions I think it is fair to conclude that Sam's proposal 'to make verification with all algorithms in the keyset mandatory' has support. Please speak up and motivate if you do not agree. I'd like to close this issue by the end of the week. For the most recent and detailed proposed text: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01735.html http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01736.html http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01745.html More discussion in that same threat. -- Olaf Kolkman DNSEXT Co-Chair PS. This is relevant to the question I just posted on "DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional". With the possibility of a degradation attack it is difficult to introduce other algorithms without being vulnarable to the attack which inspired the above thread. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 11:36:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22439 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 11:36:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2Bbb-000Gh7-Oi for namedroppers-data@psg.com; Wed, 24 Sep 2003 15:31:03 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.22) id 1A2BZX-000GXX-H2 for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 15:28:55 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h8OFRgi18931; Wed, 24 Sep 2003 08:27:42 -0700 From: bmanning@karoshi.com Message-Id: <200309241527.h8OFRgi18931@karoshi.com> Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional To: jakob@rfc.se (Jakob Schlyter) Date: Wed, 24 Sep 2003 08:27:42 -0700 (PDT) Cc: olaf@ripe.net (Olaf M. Kolkman), namedroppers@ops.ietf.org In-Reply-To: <Pine.OSX.4.56.0309241632150.20267@criollo.schlyter.se> from "Jakob Schlyter" at Sep 24, 2003 04:33:00 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > On Wed, 24 Sep 2003, Olaf M. Kolkman wrote: > > > I want to point attention to draft-ietf-dnsext-dnssec-records-04 section 1.3.1 > > > > 1.3.1 Open Technical Issues > > > > The cryptographic algorithm types (Appendix A) requires input from > > the working group. The DSA algorithm was moved to OPTIONAL. This > > had strong consensus in workshops and various discussions and a > > separate internet draft solely to move DSA from MANDATORY to OPTIONAL > > seemed excessive. This draft solicits input on that proposed change. > > > > Please speak for or against this. > > > > Default action will be to accept DSA moved to OPTIONAL as working-group > > concensus. > > yes, I think we should move DSA to optional. > > jakob > based on several years of operational experience, DSA to optional seems like a good idea. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 13:33: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 NAA27739 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 13:33:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2DMd-000Oel-CB for namedroppers-data@psg.com; Wed, 24 Sep 2003 17:23:43 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.22) id 1A2DMN-000Oce-6G for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 17:23:27 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h8OHMPa19912; Wed, 24 Sep 2003 10:22:25 -0700 From: bmanning@karoshi.com Message-Id: <200309241722.h8OHMPa19912@karoshi.com> Subject: Re: DNSEXT WGLC: Wildcard Clarify To: olaf@ripe.net (Olaf M. Kolkman) Date: Wed, 24 Sep 2003 10:22:25 -0700 (PDT) Cc: namedroppers@ops.ietf.org, bmanning@karoshi.com In-Reply-To: <20030924095844.117e4742.olaf@ripe.net> from "Olaf M. Kolkman" at Sep 24, 2003 09:58:44 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Open Issues: > thread starting at: > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01758.html e.g. multi-wildcard lable domains. this is a non-issue, although there is some disagreement between R1.2 and R2.2 in the draft. R1.2 is -VERY- clear as to what consitutes a wildcard lable, i.e. a single character. the note in R2.2 is confusing and should be removed to a document that clarifies the distinction between a domain lable (wildcard or no) and a host lable. how would wildcard-clarify accomodate my new laptop, which I have named * and it sits in the domain example.com? *.example.com. in a 192.0.2.2 Same for appendix A. this should be a companion document. > and thread starting at: > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01757.html I like the proposed wording changes for R4.1 > -- Olaf > DNSEXT Co-Chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 15:06: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 PAA01866 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 15:06:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2Eob-0005nT-Ae for namedroppers-data@psg.com; Wed, 24 Sep 2003 18:56:41 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 1A2EnY-0005fJ-EU for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 18:55:36 +0000 Received: from sandelman.ottawa.on.ca ([2002:cd96:c8ed::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8OIs5o12285 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for <namedroppers@ops.ietf.org>; Wed, 24 Sep 2003 14:54:14 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8OIlLal023086 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Wed, 24 Sep 2003 14:47:25 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8ODX5fh029096 for <namedroppers@ops.ietf.org>; Wed, 24 Sep 2003 09:34:50 -0400 To: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-reply-to: Your message of "Wed, 24 Sep 2003 13:16:31 +0200." <20030924131631.1dfb4410.olaf@ripe.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 24 Sep 2003 09:33:05 -0400 Message-ID: <29094.1064410385@marajade.sandelman.ottawa.on.ca> From: Michael Richardson <mcr@sandelman.ottawa.on.ca> X-Spam-Status: No, hits=-7.4 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- The words MANDATORY and OPTIONAL are confusing to me. It says: A DNSSEC aware resolver or name server MUST implement all MANDATORY algorithms. So, I know that MANDATORY is equivalent to 2119's MUST. Is "OPTIONAL" equal to "SHOULD" or "MAY" I feel uncomfortable with DSA as "MAY". I would feel okay with DSA as "SHOULD". If we had a documented third alternative, I might feel okay if it said you MUST implement at least two algorithms. Of course, that wouldn't guarantee that we could "failover" to the other algorithm, since there wouldn't a unique choice of what to failover to. You may want to look at draft-ietf-ipsec-ikev2-algorithms-04.txt for how IPsec is handling this topic. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP3GdBoqHRg3pndX9AQEt8gP+ImSVnbxrn7+xRviXZmtBD5aFqM1DwsvB QWYKfQNpw6qAHPmJK3m+BT50yzC0/76nx/V0ZL47u/Rh1wsj5qRQUyILvy/i243u Sn+Vhy3nY+ZiFTxNaOuilUCAq1leeOqnsJY/6hcZUsZ4eHZcqo0yob/Ll3PdsPOd UlMo1JUzIlM= =Vq/R -----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 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 PAA03024 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 15:16:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2F3i-00075y-TQ for namedroppers-data@psg.com; Wed, 24 Sep 2003 19:12:18 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 1A2F3D-00074s-DS for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 19:11:47 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h8OJB47n002755 for <namedroppers@ops.ietf.org>; Wed, 24 Sep 2003 15:11:05 -0400 (EDT) Message-ID: <010f01c382cf$9aab13d0$b9370681@barnacle> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <200309241722.h8OHMPa19912@karoshi.com> Subject: Re: DNSEXT WGLC: Wildcard Clarify Date: Wed, 24 Sep 2003 15:11:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: <bmanning@karoshi.com> > > > > and thread starting at: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01757.html > > I like the proposed wording changes for R4.1 > I agree, but I think there is a typo: Proposed change: Keep the existing text; thereby updating RFC1034, but allowing caches to stick to 1034 behavior as specified by the text below: R4.1 A wild card domain name acting as a QNAME MUST be treated as any other QNAME, caches MAY not cache the result of a wildcard query but ^^^ there MUST be no other special processing accorded it. If a cache caches the result of a wildcard query it is by virtue of the above not allowed to use the data for synthesis of answers. If a wild card domain name appears in the RDATA of a CNAME RR or any other RR that has a domain name in it, the same rule applies. In the ...etc.. I think it would read better if it read: "...caches MAY cache the result of a wildcard query but there MUST NOT be other special processing accorded it." Scott > > -- Olaf > > DNSEXT Co-Chair > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 15:59:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04748 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 15:59:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2Fh1-0009gp-Pn for namedroppers-data@psg.com; Wed, 24 Sep 2003 19:52:55 +0000 Received: from [62.6.242.6] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.22) id 1A2FgR-0009fa-O2 for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 19:52:20 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [62.6.242.9]) by gromit.rfc1035.com (8.10.1/8.9.0) with ESMTP id h8OJpph20588; Wed, 24 Sep 2003 20:51:51 +0100 (BST) To: Michael Richardson <mcr@sandelman.ottawa.on.ca> cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-reply-to: Your message of "Wed, 24 Sep 2003 09:33:05 EDT." <29094.1064410385@marajade.sandelman.ottawa.on.ca> Date: Wed, 24 Sep 2003 20:51:36 +0100 Message-ID: <20582.1064433096@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I agree with Michael. It would be prudent to have a second algorithm as a safety net. No SPoFs and all that. Even though a vulnerability in RSA looks unlikely and DNSSEC wouldn't be top of the list of things to worry about if that happened. I'd prefer the draft to use 2119 language: MUST, SHOULD, MAY and so on. OPTIONAL is too fluffy. Count this as another vote for a SHOULD for DSA. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Sep 24 17:14: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 RAA08162 for <dnsext-archive@lists.ietf.org>; Wed, 24 Sep 2003 17:14:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2Goz-000CeV-6a for namedroppers-data@psg.com; Wed, 24 Sep 2003 21:05:13 +0000 Received: from [81.2.117.194] (helo=espace.net) by psg.com with esmtp (Exim 4.22) id 1A2Goq-000CdD-7u for namedroppers@ops.ietf.org; Wed, 24 Sep 2003 21:05:04 +0000 Received: from [172.23.227.112] (193.35.129.169) by espace.net with ESMTP (Eudora Internet Mail Server 3.2.2) for <namedroppers@ops.ietf.org>; Wed, 24 Sep 2003 22:04:43 +0100 Mime-Version: 1.0 X-Sender: fm%st-kilda.org@127.0.0.1 Message-Id: <p06002004bb97b6a675eb@[172.23.227.112]> In-Reply-To: <20582.1064433096@gromit.rfc1035.com> References: <20582.1064433096@gromit.rfc1035.com> Date: Wed, 24 Sep 2003 23:03:29 +0200 To: namedroppers@ops.ietf.org From: Fearghas McKay <fm@st-kilda.org> Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:51 +0100 24/9/03, Jim Reid wrote: >I agree with Michael. It would be prudent to have a second algorithm >as a safety net. No SPoFs and all that. Even though a vulnerability in >RSA looks unlikely and DNSSEC wouldn't be top of the list of things to >worry about if that happened. > >I'd prefer the draft to use 2119 language: MUST, SHOULD, MAY and so >on. OPTIONAL is too fluffy. > >Count this as another vote for a SHOULD for DSA. Count this as a another vote for SHOULD. Thanks f -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 03:00: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 DAA10842 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 03:00:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2PwY-000P5f-G9 for namedroppers-data@psg.com; Thu, 25 Sep 2003 06:49:38 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 1A2Pvs-000P21-I1 for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 06:48:56 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h8P6miJ09977; Thu, 25 Sep 2003 13:48:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8P6mP109887; Thu, 25 Sep 2003 13:48:28 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Scott Rose" <scottr@nist.gov> cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Wildcard Clarify In-Reply-To: <010f01c382cf$9aab13d0$b9370681@barnacle> References: <010f01c382cf$9aab13d0$b9370681@barnacle> <200309241722.h8OHMPa19912@karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 2003 13:48:25 +0700 Message-ID: <8777.1064472505@munnari.OZ.AU> X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 24 Sep 2003 15:11:03 -0400 From: "Scott Rose" <scottr@nist.gov> Message-ID: <010f01c382cf$9aab13d0$b9370681@barnacle> | I agree, but I think there is a typo: Actually, I don't think that's a typo, just very bad wording. | R4.1 A wild card domain name acting as a QNAME MUST be treated as any | other QNAME, caches MAY not cache the result of a wildcard query but | ^^^ | there MUST be no other special processing accorded it. | I think it would read better if it read: "...caches MAY cache the result of | a wildcard query but there MUST NOT be other special processing accorded | it." Note that it is "MAY not" and not "MAY NOT" - what it is attempting to say, is that unlike other queries, caches are permitted to fail to cache wildcard queries (by which I believe it really means explicit queries for a '*' name, there is no such thing really as a wildcard query). It really has to say that, as 1034 suggested that behaviour (though, why isn't clear to me). Since the intent here isn't really to alter 1034 at all, it has to permit 1034 mandated actions... Failing to cache the query would be special processing for the '*' lookup in the cache - they cache the results of lookups for every other name. So, if that is permitted, caches are starting to do special things with wildcard lookups - the main point of that sentence is to limit that special processing to just "don't cache", nothing else magic about wildcards at all - that is, if the cache does cache the thing, it isn't then permitted to synthesise answers to other questions based upon the wildcard it now knows exists. Rewriting it the way you suggest makes it read much more sensibly, but turns it into an explicit (rather than just implied) reversal of what 1034 said to do (said not to do), which I don't believe needs to happen here. Perhaps we should just recognise that the 2119 MAY is a meaningless term (using that magic upper case word never really achieves anything in normal documents - but note, as used in 1122/1123 it did have a purpose) and just rewrite the sentence to avoid it. Maybe something like R4.1 A wild card domain name acting as a QNAME MUST be treated as any other QNAME. Caches are not required to cache the results of such a lookup (see RFC1034 section 4.3.3), but there MUST be no other special processing accorded it. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 03:08: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 DAA11054 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 03:08:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2Q9U-0000Bh-2V for namedroppers-data@psg.com; Thu, 25 Sep 2003 07:03:00 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 1A2Q8y-00009Q-Lr for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 07:02:29 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h8P72IJ17838; Thu, 25 Sep 2003 14:02:18 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8P726108039; Thu, 25 Sep 2003 14:02:11 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: bmanning@karoshi.com cc: olaf@ripe.net (Olaf M. Kolkman), namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Wildcard Clarify In-Reply-To: <200309241722.h8OHMPa19912@karoshi.com> References: <200309241722.h8OHMPa19912@karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 2003 14:02:06 +0700 Message-ID: <12393.1064473326@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 24 Sep 2003 10:22:25 -0700 (PDT) From: bmanning@karoshi.com Message-ID: <200309241722.h8OHMPa19912@karoshi.com> | e.g. multi-wildcard lable domains. lable? Really Bill! | this is a non-issue, although there is some disagreement between | R1.2 and R2.2 in the draft. What is R1.2 ? Do you mean section 1.2 ? | R1.2 is -VERY- clear as to what | consitutes a wildcard lable, i.e. a single character. I don't think it says that, and it certainly can't mean that. I believe you're saying that $ORIGIN example.com. @ IN SOA (whatever) * IN MX foo.example.com. is a wildcard, whereas, continuing in the same zone file *.example.com. IN A 10.11.12.13 is not - which is utter nonsense. All names in the label field, '*' or not, which don't end in '.' have the current origin appended to them, before any other processing happens. If the name, within the current zone, is '*', then it is a wildcard, regardless of how that got entered in the master zone file (assuming there even is one). Just think of how the zone gets transferred via AXFR ... | the note in R2.2 is confusing and should be removed to a document | that clarifies the distinction between a domain lable (wildcard or no) | and a host lable. No, it shouldn't me moved elsewhere, it should just be ditched. I thought we had that covered already - it is nonsense. | Same for appendix A. this should be a companion document. Same for that, it just needs to go away. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 10:44: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 KAA28536 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 10:44:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2XB0-0003bb-EP for namedroppers-data@psg.com; Thu, 25 Sep 2003 14:33:02 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.22) id 1A2XAV-0003Ys-2Z for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 14:32:31 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h8PEW77n026122 for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 10:32:08 -0400 (EDT) Message-ID: <019e01c38371$cce971a0$b9370681@barnacle> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> References: <010f01c382cf$9aab13d0$b9370681@barnacle> <200309241722.h8OHMPa19912@karoshi.com> <8777.1064472505@munnari.OZ.AU> Subject: Re: DNSEXT WGLC: Wildcard Clarify Date: Thu, 25 Sep 2003 10:32:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is better text, in my opinion. If the concensus is to allow caching of "*.example.com" queries, that's fine, but the strict restriction on further special processing should remain. That's the important part after all. Scott ----- Original Message ----- From: "Robert Elz" <kre@munnari.OZ.AU> > > Perhaps we should just recognise that the 2119 MAY is a meaningless > term (using that magic upper case word never really achieves anything > in normal documents - but note, as used in 1122/1123 it did have a > purpose) and just rewrite the sentence to avoid it. > > Maybe something like > > R4.1 A wild card domain name acting as a QNAME MUST be treated > as any other QNAME. Caches are not required to cache the > results of such a lookup (see RFC1034 section 4.3.3), but > there MUST be no other special processing accorded it. > > kre > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 12:48: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 MAA05211 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 12:48:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2Z5S-000GTT-LR for namedroppers-data@psg.com; Thu, 25 Sep 2003 16:35:26 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A2Z5H-000GSl-97 for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 16:35:15 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DE3B91390E for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 16:34:41 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Wildcard Clarify In-Reply-To: Message from "Scott Rose" <scottr@nist.gov> of "Thu, 25 Sep 2003 10:32:08 -0400." <019e01c38371$cce971a0$b9370681@barnacle> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 25 Sep 2003 16:34:41 +0000 Message-Id: <20030925163441.DE3B91390E@sa.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is better text, in my opinion. If the concensus is to allow > caching of "*.example.com" queries, that's fine, but the strict > restriction on further special processing should remain. That's the > important part after all. this prohibition would have to be effected by having the authority server set the TTL to 0 on any synthesized responses. synthesis does not occur at the caching server, and caching servers have no insight into whether or not a wildcard exists, or whether a wildcard was used to synthesize the data being cached (or not). i think that the document should make this clearer. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 13:20: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 NAA07826 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 13:20:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2Zgu-000K4H-GO for namedroppers-data@psg.com; Thu, 25 Sep 2003 17:14:08 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.22) id 1A2ZgP-000K1L-1N for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 17:13:37 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h8PHCaB32316; Thu, 25 Sep 2003 10:12:36 -0700 From: bmanning@karoshi.com Message-Id: <200309251712.h8PHCaB32316@karoshi.com> Subject: WC - r4.1 proposed new text To: namedroppers@ops.ietf.org Date: Thu, 25 Sep 2003 10:12:36 -0700 (PDT) Cc: bmanning@karoshi.com X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ok... Ed, are you happy w/ this? R4.1 A wild card domain name acting as a QNAME MUST be treated as any other QNAME. Caches are not required to cache the results of such a lookup (see RFC1034 section 4.3.3), but there MUST be no other special processing accorded it. An atrribute of this synthesized response would be that the authority server set the TTL to 0 on any such synthesized reply. Synthesis does not occur at the caching server. Non-authoritatve servers have no means via the DNS protcol to infer if a wildcard domain name was used to synthesize the data being cached or not. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 13:39: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 NAA08842 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 13:39:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2a1a-000LeD-IS for namedroppers-data@psg.com; Thu, 25 Sep 2003 17:35:30 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.22) id 1A2a0g-000LYC-VZ for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 17:34:35 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 13:34:23 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2003092513342325263 for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 13:34:23 -0400 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2655.55) id <TPLYXNKF>; Thu, 25 Sep 2003 13:34:23 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104D26@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" <GILBERT.R.LOOMIS@saic.com> To: namedroppers@ops.ietf.org Subject: RE: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional Date: Thu, 25 Sep 2003 13:35:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid wrote: > I agree with Michael. It would be prudent to have a second algorithm > as a safety net. No SPoFs and all that. Even though a vulnerability in > RSA looks unlikely and DNSSEC wouldn't be top of the list of things to > worry about if that happened. > > I'd prefer the draft to use 2119 language: MUST, SHOULD, MAY and so > on. OPTIONAL is too fluffy. > > Count this as another vote for a SHOULD for DSA. I agree with Michael R. and Jim R. in that I believe it is acceptable to move DSA to an "optional to implement" status, but that it is appropriate to use RFC 2119 terminology (in this case a SHOULD, to indicate that it's still a Really Good Idea to implement both algorithms). One way to summarize this proposed change: Algorithm: RSA - Mandatory (MUST be implemented) DSA - Optional (SHOULD be implemented) --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 13:39: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 NAA08868 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 13:39:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2a10-000LZk-Cf for namedroppers-data@psg.com; Thu, 25 Sep 2003 17:34:54 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.22) id 1A2a0R-000LXG-MD for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 17:34:20 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h8PHQrIe011605; Fri, 26 Sep 2003 00:26:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8PHVhd21279; Fri, 26 Sep 2003 00:31:45 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Wildcard Clarify In-Reply-To: <20030925163441.DE3B91390E@sa.vix.com> References: <20030925163441.DE3B91390E@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 2003 00:31:43 +0700 Message-ID: <23315.1064511103@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 25 Sep 2003 16:34:41 +0000 From: Paul Vixie <paul@vix.com> Message-ID: <20030925163441.DE3B91390E@sa.vix.com> | this prohibition would have to be effected by having the authority server | set the TTL to 0 on any synthesized responses. synthesis does not occur | at the caching server, and caching servers have no insight into whether | or not a wildcard exists, or whether a wildcard was used to synthesize the | data being cached (or not). i think that the document should make this | clearer. No, Paul, you're misunderstanding the point. 1034 says that is a resolver does an explicit lookup for '*', then the results "should not" be cached. This has nothing at all to do with a lookup of some random other name that happens to match a wildcard - for those, you're right, the cache simply has no way to know. But a cache can see a lookup where the QNAME happens to be "*.whatever.domain" and do magic stuff with it - 1034 says not to cache the answer - but that's the only special processing that the cache is to be allowed to do. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 13:59: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 NAA10182 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 13:59:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2aJ9-000NGj-9O for namedroppers-data@psg.com; Thu, 25 Sep 2003 17:53:39 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.22) id 1A2aIW-000NFd-Fn for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 17:53:01 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h8PHjRIe028236; Fri, 26 Sep 2003 00:45:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8PHo5d11250; Fri, 26 Sep 2003 00:50:10 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: bmanning@karoshi.com cc: namedroppers@ops.ietf.org Subject: Re: WC - r4.1 proposed new text In-Reply-To: <200309251712.h8PHCaB32316@karoshi.com> References: <200309251712.h8PHCaB32316@karoshi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 2003 00:50:05 +0700 Message-ID: <1850.1064512205@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 25 Sep 2003 10:12:36 -0700 (PDT) From: bmanning@karoshi.com Message-ID: <200309251712.h8PHCaB32316@karoshi.com> | ok... Ed, are you happy w/ this? [some fine text deleted ...:-)] | An atrribute of this synthesized response would be that | the authority server set the TTL to 0 on any such synthesized | reply. But that isn't what happens, nor is it what we want to happen, nor do we want caches (or others) starting to infer that a response with a TTL of 0 means that it is the result of a wildcard expansion. Wildcard expansions should get whatever TTL was given to the '*' record in the zone file. Paul's point was that if a server wanted to prevent wildcard expansion results from being cached, it would need to send TTL==0 - which is absolutely correct. The way to achieve that is to put a 0 TTL on the '*'. | Synthesis does not occur at the caching server. That's true, but if that is to be included here, I'd say MUST NOT rather than does not. | Non-authoritatve servers have no means via the DNS protcol | to infer if a wildcard domain name was used to synthesize | the data being cached or not. This is true as well, but I don't thing this belongs here - it would be worthwhile for the draft to say this, or something similar, somewhere, but it doesn't belong in one of these Rn.m paragraphs. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 14:30: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 OAA12541 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 14:30:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2anR-000PNl-Rm for namedroppers-data@psg.com; Thu, 25 Sep 2003 18:24:57 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A2anJ-000PM2-L5 for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 18:24:49 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6C9541396A; Thu, 25 Sep 2003 18:24:19 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: Robert Elz <kre@munnari.OZ.AU> Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Wildcard Clarify In-Reply-To: Message from Robert Elz <kre@munnari.OZ.AU> of "Fri, 26 Sep 2003 00:31:43 +0700." <23315.1064511103@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 25 Sep 2003 18:24:19 +0000 Message-Id: <20030925182419.6C9541396A@sa.vix.com> X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk ok, i get it. so to clarify this document further, one could add a note that says "as a result of not being allowed to cache these names, the caching name server will never have an opportunity to assume the role of synthesis, which is therefore reserved for authority servers." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 15:31: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 PAA17568 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 15:31:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2bhj-0003XE-2n for namedroppers-data@psg.com; Thu, 25 Sep 2003 19:23:07 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.22) id 1A2bgY-0003Tn-R7 for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 19:21:55 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h8PJEVIe012684; Fri, 26 Sep 2003 02:14:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8PJJiQ07379; Fri, 26 Sep 2003 02:19:44 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Wildcard Clarify In-Reply-To: <20030925182419.6C9541396A@sa.vix.com> References: <20030925182419.6C9541396A@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Sep 2003 02:19:43 +0700 Message-ID: <5474.1064517583@munnari.OZ.AU> X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 25 Sep 2003 18:24:19 +0000 From: Paul Vixie <paul@vix.com> Message-ID: <20030925182419.6C9541396A@sa.vix.com> | ok, i get it. so to clarify this document further, one could add a | note that says "as a result of not being allowed to cache these names, | the caching name server will never have an opportunity to assume the | role of synthesis, which is therefore reserved for authority servers." Yes, other than I don't think that we need the logic to deduce that only auth servers can do this - it can simply be stated. I also don't really believe that caches actually go looking for '*' lookups and refuse to cache the results (they perhaps should, to follow 1034, but I find it hard to believe that most do). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 17:22: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 RAA21792 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 17:22:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2dSQ-000G4j-9G for namedroppers-data@psg.com; Thu, 25 Sep 2003 21:15:26 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.22) id 1A2dRu-000Fwl-2F for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 21:14:54 +0000 Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.10/) with ESMTP id h8PLEqSu018349; Thu, 25 Sep 2003 14:14:52 -0700 (PDT) Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <TTLJ70PY>; Thu, 25 Sep 2003 14:14:52 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E011130EC@mou1wnexm02.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Loomis, Rip'" <GILBERT.R.LOOMIS@saic.com>, namedroppers@ops.ietf.org Subject: RE: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional Date: Thu, 25 Sep 2003 14:14:44 -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.3 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There is a security issue with DSA. It requires a random number to be generated for each signature. If the random number used in a signature can ever be guessed the private key can be recovered. This means that implementations of DSA need to have really good implementation to avoid a serous compromise. I think that should accept is reasonable but not should support. http://www.lucent.com/press/0201/010205.bla.html > -----Original Message----- > From: Loomis, Rip [mailto:GILBERT.R.LOOMIS@saic.com] > Sent: Thursday, September 25, 2003 1:35 PM > To: namedroppers@ops.ietf.org > Subject: RE: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional > > > Jim Reid wrote: > > I agree with Michael. It would be prudent to have a second algorithm > > as a safety net. No SPoFs and all that. Even though a > vulnerability in > > RSA looks unlikely and DNSSEC wouldn't be top of the list > of things to > > worry about if that happened. > > > > I'd prefer the draft to use 2119 language: MUST, SHOULD, MAY and so > > on. OPTIONAL is too fluffy. > > > > Count this as another vote for a SHOULD for DSA. > > I agree with Michael R. and Jim R. in that I believe it is acceptable > to move DSA to an "optional to implement" status, but that it is > appropriate to use RFC 2119 terminology (in this case a SHOULD, > to indicate that it's still a Really Good Idea to implement both > algorithms). One way to summarize this proposed change: > > Algorithm: > RSA - Mandatory (MUST be implemented) > DSA - Optional (SHOULD be implemented) > > > --Rip > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 18: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 SAA23787 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 18:05:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2eBG-000Ke7-4E for namedroppers-data@psg.com; Thu, 25 Sep 2003 22:01:46 +0000 Received: from [195.169.222.38] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.22) id 1A2eAh-000KYA-BX for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 22:01:11 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-1) with ESMTP id h8PM197u020296 for <namedroppers@ops.ietf.org>; Fri, 26 Sep 2003 00:01:09 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-1) id h8PM19eO020294 for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 00:01:09 +0200 Date: Fri, 26 Sep 2003 00:01:09 +0200 From: Miek Gieben <miekg@atoom.net> To: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional Message-ID: <20030925220109.GE19820@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <4E25ECBBC03F874CBAD03399254ADFDE104D26@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104D26@US-Columbia-CIST.mail.saic.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 25 Sep, @19:35, Loomis, wrote in "RE: DNSSEC-RECORDS ISSUE: DSA ..."] > I agree with Michael R. and Jim R. in that I believe it is acceptable > to move DSA to an "optional to implement" status, but that it is > appropriate to use RFC 2119 terminology (in this case a SHOULD, > to indicate that it's still a Really Good Idea to implement both > algorithms). One way to summarize this proposed change: > > Algorithm: > RSA - Mandatory (MUST be implemented) > DSA - Optional (SHOULD be implemented) > > > --Rip I support this too, grtz Miek -- "So long and thanks for all the fish" -- Hitchhikers Guide to the Galaxy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 18:15: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 SAA24890 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 18:15:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2eME-000Lb2-L7 for namedroppers-data@psg.com; Thu, 25 Sep 2003 22:13:06 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 1A2eLj-000LXe-0M for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 22:12:35 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8PMDbo02815 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 18:13:43 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8PM7NjO014403 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 18:07:23 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8PM7Mvu014400 for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 18:07:23 -0400 To: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-reply-to: Your message of "Thu, 25 Sep 2003 14:14:44 PDT." <2A1D4C86842EE14CA9BC80474919782E011130EC@mou1wnexm02.vcorp.ad.vrsn.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Sep 2003 18:07:22 -0400 Message-ID: <14399.1064527642@marajade.sandelman.ottawa.on.ca> From: Michael Richardson <mcr@sandelman.ottawa.on.ca> X-Spam-Status: No, hits=-7.6 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Hallam-Baker," == Hallam-Baker, Phillip <pbaker@verisign.com> writes: Hallam-Baker> I think that should accept is reasonable but not should Hallam-Baker> support. Again, I'm not happy with DSA. I'd rather have something we can actually use. If we never use it, it won't get tested. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP3NnGYqHRg3pndX9AQHjWwP+JMsyzEYaC7Yf+a8GEhQWz7tv+MnS2xXu LUNwQt6wSn11lSfy7cUuV7GtKBUrjlu7XvtKW92UePbaDc0iU/rQMi8KJZCtg7SB siJL+uGS3YD/i+EWX/Ip1RtiZhbYiz/UJc2RGvoizF/nMOVBy9FuvDR129WwNQ+M +9ykzTuy0wo= =LPQ1 -----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 20:30: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 UAA29428 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 20:30:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2gMy-0005cd-Py for namedroppers-data@psg.com; Fri, 26 Sep 2003 00:22:00 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 1A2gMq-0005aV-EG for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 00:21:52 +0000 Received: (qmail 94940 invoked by uid 1016); 26 Sep 2003 00:22:11 -0000 Date: 26 Sep 2003 00:22:10 -0000 Message-ID: <20030926002210.94939.qmail@cr.yp.to> From: "D. J. Bernstein" <djb@cr.yp.to> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Wildcard Clarify References: <20030925182419.6C9541396A@sa.vix.com> <5474.1064517583@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > I also don't really believe that caches actually go looking for '*' > lookups and refuse to cache the results I certainly don't bother looking for them. On the other hand, I can imagine an implementor getting into trouble by building a single tree structure for cached data _and_ server-side data, and then adding wildcard support to the tree, not realizing that cached records have to be treated differently. The bottom line is that caches must not invent records. In particular, they must not attempt to apply *.blah records to other names. Some cache implementors might find it most convenient to do this by simply refusing to cache *.blah. ---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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 21:35: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 VAA01890 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 21:35:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2hPf-000B2Y-Ab for namedroppers-data@psg.com; Fri, 26 Sep 2003 01:28:51 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 1A2hPV-000B27-9q for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 01:28:41 +0000 Received: (qmail 49800 invoked by uid 1016); 26 Sep 2003 01:29:00 -0000 Date: 26 Sep 2003 01:29:00 -0000 Message-ID: <20030926012900.49799.qmail@cr.yp.to> From: "D. J. Bernstein" <djb@cr.yp.to> To: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional References: <29094.1064410385@marajade.sandelman.ottawa.on.ca> <20582.1064433096@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: > It would be prudent to have a second algorithm as a safety net. No > SPoFs and all that. Let me see if I understand how you imagine this ``safety net'' working. Users sign their records with, say, 768-bit RSA. Someone announces a 768-bit RSA factorization. Users decide to change their keys to, say, 768-bit DSA. Right? If so, you've now created massive verification failures. Verifiers that don't support DSA will automatically disable all security, allowing the records to be forged by any sniffing (or persistent blind) attacker at far less cost than breaking another 768-bit RSA key. In short, users are _losing_ security in this situation, unless DSA is MANDATORY. It doesn't make sense to have an optional backup algorithm. The only reasonable possibilities are mandatory DSA or no DSA at all. This seems to be yet another example of ``SHOULD'' meaning ``The authors of this document didn't think through the protocol.'' Furthermore---I'll put on my cryptographer's hat for a moment---current methods are going to break 768-bit DSA not long after they break 768-bit RSA. Modern ``combination-of-congruence'' factoring methods can be adapted to compute discrete logarithms at almost the same speed. Using both RSA and DSA is a waste of implementor time that could be better used for, say, implementing RSA signature compression. ---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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 22:25: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 VAA01889 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 21:35:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2hSW-000BJY-6d for namedroppers-data@psg.com; Fri, 26 Sep 2003 01:31:48 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 1A2hSU-000BJM-EO for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 01:31:46 +0000 Received: (qmail 52046 invoked by uid 1016); 26 Sep 2003 01:32:05 -0000 Date: 26 Sep 2003 01:32:05 -0000 Message-ID: <20030926013205.52045.qmail@cr.yp.to> From: "D. J. Bernstein" <djb@cr.yp.to> To: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional References: <2A1D4C86842EE14CA9BC80474919782E011130EC@mou1wnexm02.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hallam-Baker, Phillip writes: > There is a security issue with DSA. It requires a random number to be > generated for each signature. George Barwood and John Wigley solved that several years ago. In short: generate the random number as SHA-256(z,m) mod q, where z is a secret kept by the signer, m is the message, and q is the 160-bit DSA prime. ---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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 22:27: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 WAA03514 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 22:27:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2iGf-000FNo-Qu for namedroppers-data@psg.com; Fri, 26 Sep 2003 02:23:37 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.22) id 1A2iGA-000FNC-Da for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 02:23:06 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 6A279869; Thu, 25 Sep 2003 22:23:02 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 0D38C256 for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 22:23:02 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.136.136.93]) by arin.net (CommuniGate Pro SMTP 4.1) with ESMTP id 808190 for namedroppers@ops.ietf.org; Thu, 25 Sep 2003 22:18:18 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a05111b1abb9953422016@[192.136.136.93]> In-Reply-To: <20030926002210.94939.qmail@cr.yp.to> References: <20030925182419.6C9541396A@sa.vix.com> <5474.1064517583@munnari.OZ.AU> <20030926002210.94939.qmail@cr.yp.to> Date: Thu, 25 Sep 2003 22:22:53 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSEXT WGLC: Wildcard Clarify Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 0:22 +0000 9/26/03, D. J. Bernstein wrote: >The bottom line is that caches must not invent records. In particular, >they must not attempt to apply *.blah records to other names. Some cache >implementors might find it most convenient to do this by simply refusing >to cache *.blah. Yes, yes, yes, yes. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 23:08:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04798 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 23:08:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2it3-000IEq-Or for namedroppers-data@psg.com; Fri, 26 Sep 2003 03:03:17 +0000 Received: from [62.6.242.6] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.22) id 1A2isT-000ID9-Gw for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 03:02:41 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [62.6.242.9]) by gromit.rfc1035.com (8.10.1/8.9.0) with ESMTP id h8Q32bh26627; Fri, 26 Sep 2003 04:02:37 +0100 (BST) To: "D. J. Bernstein" <djb@cr.yp.to> Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-reply-to: Your message of "26 Sep 2003 01:29:00 -0000." <20030926012900.49799.qmail@cr.yp.to> Date: Fri, 26 Sep 2003 04:02:36 +0100 Message-ID: <26625.1064545356@gromit.rfc1035.com> From: Jim Reid <jim@rfc1035.com> X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "djb" == D J Bernstein <djb@cr.yp.to> writes: >> It would be prudent to have a second algorithm as a safety >> net. No SPoFs and all that. djb> Let me see if I understand how you imagine this ``safety djb> net'' working. Your understanding and imagination are wrong. The safety net I have in mind has nothing to do with key lengths. Or having "extra security" by signing the same data with a second key. It's a safety net for the protocol by having a second ALGORITHM, just in case there's a problem with the mandatory one. That problem might be cryptographic though I very much doubt that. It could be a legal problem. For instance someone somewhere passes an idiot law to prohibit RSA or its export. That's happened before. Perhaps lawyers for RSA Inc (or whatever they're calling themselves today) manage to find some sleazy way to extract huge licence fees or revive expired patent rights so that RSA becomes effectively unusable. These scenarios aren't beyond the bounds of possibility. We've all seen the absurdities an army of well-funded lawyers can achieve. Suppose RSA has to be dropped for some reason after there's a non-trivial amount of DNSSEC deployment. Wouldn't it be helpful to be able to switch over to an alternate algorithm that's already implemented in the name servers and resolvers until a new one can be chosen and rolled out? IMO the protocol needs a safety net to guard against those kinds of SPoFs. Now whether that second algorithm should be DSA or something else is another debate. I'm happy for the cryptographers to decide that, just as long as all the DNSSEC eggs don't end up in the one RSA basket. And anyway, what do you care? You're not going to implement DNSSEC or interoperate with it. Or have you finally seen the light? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Sep 25 23:15: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 XAA05057 for <dnsext-archive@lists.ietf.org>; Thu, 25 Sep 2003 23:15:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2j2Z-000J4P-2H for namedroppers-data@psg.com; Fri, 26 Sep 2003 03:13:07 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 1A2j22-000IzY-Lj for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 03:12:34 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8Q3Dbo05729 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 23:13:43 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8Q34pjO021229 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 23:04:51 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8Q34oTx021225 for <namedroppers@ops.ietf.org>; Thu, 25 Sep 2003 23:04:51 -0400 To: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-reply-to: Your message of "26 Sep 2003 01:29:00 -0000." <20030926012900.49799.qmail@cr.yp.to> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 25 Sep 2003 23:04:50 -0400 Message-ID: <21224.1064545490@marajade.sandelman.ottawa.on.ca> From: Michael Richardson <mcr@sandelman.ottawa.on.ca> X-Spam-Status: No, hits=-6.5 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "D" == D J Bernstein <djb@cr.yp.to> writes: D> Furthermore---I'll put on my cryptographer's hat for a D> moment---current methods are going to break 768-bit DSA not long after D> they break 768-bit RSA. Modern ``combination-of-congruence'' factoring D> methods can be adapted to compute discrete logarithms at almost the D> same speed. Using both RSA and DSA is a waste of implementor time that So, you are right. There are two things to consider, however: 1) SHOULD means, "unless you have a very convincing reason not to". This is why I asked what "OPTIONAL" means. SHOULD does not mean "if you feel like it" 2) If we don't suggest that people support at least two algorithms, then the odds of them supporting three when we need a third is zilch. I'd like to think that we'll standardize some other algorithm than DSA, ideally one with very different properties such that they aren't broken by the same miracle. I'm not sure if ElGamal is really different enough. Maybe there are no such algorithms. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP3Os0YqHRg3pndX9AQEyrAP/SO8eL2TKIE48FJqMtdzDGNwC9G4gq+qy +lJxtZrEhHoKa87GSBdQsT4y5qUFZOJ4MZ3iy46BJLU/Nv2ojEjWNeq+Mtxb/NrK XqbMOKVV5kpgYR4Cd3lAwg5wM1hhtIQiKZd9fpFJrwPxMMU2xFk585GGShzG7goz eN0wYPkPBRY= =ud/X -----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 26 00:14: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 AAA06961 for <dnsext-archive@lists.ietf.org>; Fri, 26 Sep 2003 00:14:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2jtU-000MUd-RK for namedroppers-data@psg.com; Fri, 26 Sep 2003 04:07:48 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.22) id 1A2jsp-000MTa-9p for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 04:07:07 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h8Q465l05231; Thu, 25 Sep 2003 21:06:05 -0700 From: bmanning@karoshi.com Message-Id: <200309260406.h8Q465l05231@karoshi.com> Subject: Re: DNSEXT WGLC: Wildcard Clarify To: djb@cr.yp.to (D. J. Bernstein) Date: Thu, 25 Sep 2003 21:06:05 -0700 (PDT) Cc: namedroppers@ops.ietf.org In-Reply-To: <20030926002210.94939.qmail@cr.yp.to> from "D. J. Bernstein" at Sep 26, 2003 12:22:10 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The bottom line is that caches must not invent records. In particular, > they must not attempt to apply *.blah records to other names. Some cache > implementors might find it most convenient to do this by simply refusing > to cache *.blah. I think we tried to capture that in R4.1 text. Did we get it right? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 26 01:11: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 BAA08266 for <dnsext-archive@lists.ietf.org>; Fri, 26 Sep 2003 01:11:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2kmS-0000dd-B4 for namedroppers-data@psg.com; Fri, 26 Sep 2003 05:04:36 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 1A2kmK-0000dK-9j for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 05:04:28 +0000 Received: (qmail 24288 invoked by uid 1016); 26 Sep 2003 05:04:47 -0000 Date: 26 Sep 2003 05:04:47 -0000 Message-ID: <20030926050447.24287.qmail@cr.yp.to> From: "D. J. Bernstein" <djb@cr.yp.to> To: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional References: <20030926012900.49799.qmail@cr.yp.to> <26625.1064545356@gromit.rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: > And anyway, what do you care? You're not going to implement DNSSEC or > interoperate with it. What http://cr.yp.to/djbdns/forgery.html actually says is ``I'm not going to bother implementing DNSSEC until I see (1) a stable, sensible DNSSEC protocol and (2) a detailed, concrete, credible plan for central DNSSEC deployment.'' I'm disappointed that in ten years you've failed to achieve #1 and #2; I'm certainly not going to hold up my own DNS security projects waiting for DNSSEC; but I'm continuing to watch what happens with DNSSEC. > It's a safety net for the protocol by having a second ALGORITHM How exactly does anyone benefit from ``having'' a second algorithm? Let's look at your revised nightmare scenario. Lots of users sign their records with RSA. Suddenly the RSA company threatens them with lawsuits. Users decide to change to DSA. This produces a massive security hole, exactly as I explained before--- unless DSA was already _mandatory_, which is not what you're advocating. Let's take another ``single point of failure'' in your terminology: HTTP. Presumably you think that web servers ``SHOULD implement FTP,'' just in case someone claims patent rights over HTTP. What you're failing to explain is WHY THIS HELPS. How does an _optional_ backup mechanism prevent the problems that you're talking about? ---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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 26 03:53: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 DAA24691 for <dnsext-archive@lists.ietf.org>; Fri, 26 Sep 2003 03:53:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2nHy-000CNx-AU for namedroppers-data@psg.com; Fri, 26 Sep 2003 07:45:18 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A2nHm-000CMM-Dn for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 07:45:06 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id CBE1E4E42D; Fri, 26 Sep 2003 09:45:05 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 6EB104E32F; Fri, 26 Sep 2003 09:45:05 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h8Q7j5JO001371; Fri, 26 Sep 2003 09:45:05 +0200 Date: Fri, 26 Sep 2003 09:45:05 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: "D. J. Bernstein" <djb@cr.yp.to> Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional Message-Id: <20030926094505.49137fce.olaf@ripe.net> In-Reply-To: <20030926050447.24287.qmail@cr.yp.to> References: <20030926012900.49799.qmail@cr.yp.to> <26625.1064545356@gromit.rfc1035.com> <20030926050447.24287.qmail@cr.yp.to> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.004350 X-RIPE-Signature: f11ab63308483709b0199dc4ce4a5a4b X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 26 Sep 2003 05:04:47 -0000 "D. J. Bernstein" <djb@cr.yp.to> wrote: > What http://cr.yp.to/djbdns/forgery.html actually says is ``I'm not > going to bother implementing DNSSEC until I see (1) a stable, sensible > DNSSEC protocol draft-ietf-dnsext-dnssec-records-04, draft-ietf-dnsext-dnssec-intro-04 and forthcoming draft-ietf-dnsext-proto-03 (in a week or two) contain the specifications with all the issues that came up during the rewrite resolved, there are a number of minor textual issues and things that may need a little rewording but the core is solid. A review of those document is appreciated. WGLC may be a weeks from now rather than months. -- Olaf PS. With respect to #2, you are right, nothing there yet. It needs work but lets first get protocol. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 26 08:31: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 IAA02880 for <dnsext-archive@lists.ietf.org>; Fri, 26 Sep 2003 08:31:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2rax-0006Or-20 for namedroppers-data@psg.com; Fri, 26 Sep 2003 12:21:11 +0000 Received: from [151.201.220.65] (helo=budney.homeunix.net) by psg.com with smtp (Exim 4.22) id 1A2rZv-0006MO-3k for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 12:20:07 +0000 Received: (qmail 6569 invoked from network); 26 Sep 2003 12:20:27 -0000 Received: from localhost (HELO localhost.localdomain) (127.0.0.1) by localhost with SMTP; 26 Sep 2003 12:20:27 -0000 Received: from budney.homeunix.net (localhost.localdomain [127.0.0.1]) by localhost.localdomain (AvMailGate-2.0.1.16) id 06562-752001CB; Fri, 26 Sep 2003 08:20:27 -0400 Received: (qmail 6560 invoked from network); 26 Sep 2003 12:20:27 -0000 Received: from localhost (HELO budney.homeunix.net) (127.0.0.1) by localhost with SMTP; 26 Sep 2003 12:20:27 -0000 Date: Fri, 26 Sep 2003 08:20:26 -0400 (EDT) X-X-Sender: budney@budney.homeunix.net To: "namedroppers@ops.ietf.org" <namedroppers@ops.ietf.org> Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-Reply-To: <26625.1064545356@gromit.rfc1035.com> Message-ID: <Pine.LNX.4.44.0309260813330.2899-100000@budney.homeunix.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: lbudney@pobox.com X-Delivery-Agent: TMDA/0.70 (Pensive) X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.21.0.1; VDF: 6.21.0.53; host: budney.homeunix.net) X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,TO_ADDRESS_EQ_REAL, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 26 Sep 2003, Jim Reid wrote: > > Your understanding and imagination are wrong. The safety net I have in > mind...It's a safety net for the protocol by having a second ALGORITHM, > just in case there's a problem with the mandatory one. The objection that remains valid: if the protocol allows multiple algorithms without making support for all of them mandatory, then one of two things will happen. When an algorithm is chosen that is unsupported by the other party, either all data must be rejected, or cryptographic signing must be ignored. The former leads to DoS, and the latter leads to obvious spoofing attacks. Bruce Schneier has written extensively on this issue. Not that Dan needs the backup, being a cryptologist in his own right. The only way to support multiple protocols is to allow the data's owner to select the protocol of his choice, and require clients to accept the choice and support whatever protocol the owner mandates. Any other approach results in one of: DoS; spoofing; or forced use of weak keys. Regards, Len. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 26 08:32: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 IAA02903 for <dnsext-archive@lists.ietf.org>; Fri, 26 Sep 2003 08:32:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2rdO-0006cE-Mh for namedroppers-data@psg.com; Fri, 26 Sep 2003 12:23:42 +0000 Received: from [151.201.220.65] (helo=budney.homeunix.net) by psg.com with smtp (Exim 4.22) id 1A2rcs-0006b8-Ab for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 12:23:10 +0000 Received: (qmail 6633 invoked from network); 26 Sep 2003 12:23:35 -0000 Received: from localhost (HELO localhost.localdomain) (127.0.0.1) by localhost with SMTP; 26 Sep 2003 12:23:35 -0000 Received: from budney.homeunix.net (localhost.localdomain [127.0.0.1]) by localhost.localdomain (AvMailGate-2.0.1.16) id 06626-5D7D55EC; Fri, 26 Sep 2003 08:23:35 -0400 Received: (qmail 6624 invoked from network); 26 Sep 2003 12:23:35 -0000 Received: from localhost (HELO budney.homeunix.net) (127.0.0.1) by localhost with SMTP; 26 Sep 2003 12:23:35 -0000 Date: Fri, 26 Sep 2003 08:23:34 -0400 (EDT) X-X-Sender: budney@budney.homeunix.net To: "namedroppers@ops.ietf.org" <namedroppers@ops.ietf.org> Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-Reply-To: <21224.1064545490@marajade.sandelman.ottawa.on.ca> Message-ID: <Pine.LNX.4.44.0309260821080.2899-100000@budney.homeunix.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: lbudney@pobox.com X-Delivery-Agent: TMDA/0.70 (Pensive) X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.21.0.1; VDF: 6.21.0.53; host: budney.homeunix.net) X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,TO_ADDRESS_EQ_REAL, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 25 Sep 2003, Michael Richardson wrote: > > 1) SHOULD means, "unless you have a very convincing reason not to". In this case, following the suggestion is practically pointless, and therefore shouldn't be a SHOULD. If the only concern is fear of legal silliness over RSA, then forget about RSA, and mandate DSA up front. > 2) If we don't suggest that people support at least two algorithms, then > the odds of them supporting three when we need a third is zilch. If you make two a SHOULD, the odds that people will spontaneously support three is zilch. Regards, Len. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 26 09:26: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 JAA04960 for <dnsext-archive@lists.ietf.org>; Fri, 26 Sep 2003 09:26:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2sXO-000C17-DY for namedroppers-data@psg.com; Fri, 26 Sep 2003 13:21:34 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.22) id 1A2sXG-000C0m-Fs for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 13:21:26 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id h8QDLL74002130; Fri, 26 Sep 2003 06:21:22 -0700 (PDT) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <TK16TXV7>; Fri, 26 Sep 2003 06:21:21 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E011130F1@mou1wnexm02.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Michael Richardson'" <mcr@sandelman.ottawa.on.ca>, namedroppers@ops.ietf.org Subject: RE: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional Date: Fri, 26 Sep 2003 06:21:17 -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=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm not sure if ElGamal is really different enough. Maybe > there are no such algorithms. Well as Dan points out fast factoring methods can be retargetted to be discrete log problems. I guess we could have some people go and define a DSA256 by taking the principles of DSA and extending to a bigger key and a bigger hash algorithm. It is a heck of a lot of work to do right. I am sure this is not the place to do that. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 26 09:45: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 JAA05810 for <dnsext-archive@lists.ietf.org>; Fri, 26 Sep 2003 09:45:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2sqV-000Dkw-BD for namedroppers-data@psg.com; Fri, 26 Sep 2003 13:41:19 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A2sq6-000Diy-Ls for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 13:40:54 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 8C4E74FE6C; Fri, 26 Sep 2003 15:40:02 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 157734FE54; Fri, 26 Sep 2003 15:40:02 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h8QDe2JO012768; Fri, 26 Sep 2003 15:40:02 +0200 Date: Fri, 26 Sep 2003 15:40:01 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: lbudney@pobox.com Cc: namedroppers@ops.ietf.org Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional Message-Id: <20030926154001.17d0fa47.olaf@ripe.net> In-Reply-To: <Pine.LNX.4.44.0309260813330.2899-100000@budney.homeunix.net> References: <26625.1064545356@gromit.rfc1035.com> <Pine.LNX.4.44.0309260813330.2899-100000@budney.homeunix.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.499457 X-RIPE-Signature: 1f745795c88bf148672bba04825febf0 X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The objection that remains valid: if the protocol allows multiple > algorithms without making support for all of them mandatory, then one of > two things will happen. When an algorithm is chosen that is unsupported by > the other party, either all data must be rejected, or cryptographic > signing must be ignored. The former leads to DoS, and the latter leads to > obvious spoofing attacks. I agree with your analysis. But, Regardless of MUST or SHOULD for DSA there may be a point when we need a 3rd algorithm. The underlying requirement is that it should be possible to introduce a new algorithm without creating attacks on resolvers that _do_ implement the new algorithm. (That has been discussed at length and is IMHO solved in another thread, see the archive on the Q2 bis issue). From an operational point of view it is IMHO acceptable for resolvers to ignore cryptographic signing for algorithms that are not understood. In the end it is the choice of the resolving end if it wants to live in a secured world or not; if the new algorithm is needed than you go to your supplier and have the new algorithm implemented. Currently that operational model seems to work since most resolvers understand nor RSA or DSA and therefore ignore cryptographic signing :-). I am agnosic about MUST/SHOULD on the support of the current algorithms. I rather see the specification, and the applications based on it, written in such a way that another algorithm can be made mandatory later. I read the documents to reflect that requirement (Do others?). As an asside: operationally it is more difficult to get rid of the old algorithm than to introduce a new one; think trust anchors. -- Olaf namedroppers participant ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 26 16:48: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 QAA23115 for <dnsext-archive@lists.ietf.org>; Fri, 26 Sep 2003 16:48:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2zHW-0000GI-MP for namedroppers-data@psg.com; Fri, 26 Sep 2003 20:33:38 +0000 Received: from [205.150.200.166] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.22) id 1A2zGX-0000DH-Ij for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 20:32:37 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h8QKXhF09904 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for <namedroppers@ops.ietf.org>; Fri, 26 Sep 2003 16:33:54 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8QKTljO013858 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <namedroppers@ops.ietf.org>; Fri, 26 Sep 2003 16:29:48 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8QKTlUO013854 for <namedroppers@ops.ietf.org>; Fri, 26 Sep 2003 16:29:47 -0400 To: "namedroppers@ops.ietf.org" <namedroppers@ops.ietf.org> Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-reply-to: Your message of "Fri, 26 Sep 2003 08:23:34 EDT." <Pine.LNX.4.44.0309260821080.2899-100000@budney.homeunix.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Sep 2003 16:29:47 -0400 Message-ID: <13852.1064608187@marajade.sandelman.ottawa.on.ca> From: Michael Richardson <mcr@sandelman.ottawa.on.ca> X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_20,IN_REP_TO,PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM, TO_ADDRESS_EQ_REAL autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "lbudney" == lbudney <lbudney@pobox.com> writes: >> 1) SHOULD means, "unless you have a very convincing reason not to". lbudney> In this case, following the suggestion is practically pointless, lbudney> and therefore shouldn't be a SHOULD. If the only concern is fear lbudney> of legal silliness over RSA, then forget about RSA, and mandate lbudney> DSA up front. No, the concern is code space and programmer time. I'm not thinking legal concerns at all. The only time someone might consider dropping DSA is because they ran out of firmware space, *AND* they are operating in some limited environment. >> 2) If we don't suggest that people support at least two algorithms, >> then the odds of them supporting three when we need a third is zilch. lbudney> If you make two a SHOULD, the odds that people will lbudney> spontaneously support three is zilch. No, having said that there are two algroithms, the code path starts to look like: switch(algo) { case RSA: /* do stuff */ break; case DSA: /* do stuff */ break; default: /* complain */ } Adding the third case is much easier at that point. On the other hand, if you start with a single MUST, and the other one is effectively, "do not bother", then if you are lucky, it turns into: assert(algo == RSA); if you are not, the programmer just doesn't check. I've been there. I've managed ID10T programmers. I seldom get the authority to fire them, alas. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBP3ShuYqHRg3pndX9AQGqbgQAhaZzzRM/CmMJriXZeWry+oSZ2RnCgfhI TnXN1M+6/zDEcie9dKaIwUkhnFhFaV/dIo+EavsbgP/ASSztU/61C63LV9hO+DPn ooryLg0TucekeGSTWDiA0Re7lxd1c/wdaserrZUCm0/Aj+X6qfT4pQxRHy/QeUAk pSwUXZX1NJk= =2lSI -----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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Sep 26 17:16:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24358 for <dnsext-archive@lists.ietf.org>; Fri, 26 Sep 2003 17:15:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A2zrZ-0004Wv-Cd for namedroppers-data@psg.com; Fri, 26 Sep 2003 21:10:53 +0000 Received: from [151.201.220.65] (helo=budney.homeunix.net) by psg.com with smtp (Exim 4.22) id 1A2zr3-0004WI-B2 for namedroppers@ops.ietf.org; Fri, 26 Sep 2003 21:10:21 +0000 Received: (qmail 31575 invoked from network); 26 Sep 2003 21:10:45 -0000 Received: from localhost (HELO localhost.localdomain) (127.0.0.1) by localhost with SMTP; 26 Sep 2003 21:10:45 -0000 Received: from budney.homeunix.net (localhost.localdomain [127.0.0.1]) by localhost.localdomain (AvMailGate-2.0.1.16) id 31568-1D1909BA; Fri, 26 Sep 2003 17:10:45 -0400 Received: (qmail 31566 invoked from network); 26 Sep 2003 21:10:45 -0000 Received: from localhost (HELO budney.homeunix.net) (127.0.0.1) by localhost with SMTP; 26 Sep 2003 21:10:45 -0000 Date: Fri, 26 Sep 2003 17:10:44 -0400 (EDT) X-X-Sender: budney@budney.homeunix.net To: "namedroppers@ops.ietf.org" <namedroppers@ops.ietf.org> Subject: Re: DNSSEC-RECORDS ISSUE: DSA from Mandatory to Optional In-Reply-To: <13852.1064608187@marajade.sandelman.ottawa.on.ca> Message-ID: <Pine.LNX.4.44.0309261703500.31218-100000@budney.homeunix.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: lbudney@pobox.com X-Delivery-Agent: TMDA/0.70 (Pensive) X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.16; AVE: 6.21.0.1; VDF: 6.21.0.53; host: budney.homeunix.net) X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,TO_ADDRESS_EQ_REAL, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 26 Sep 2003, Michael Richardson wrote: >> "lbudney" == lbudney <lbudney@pobox.com> writes: >> >> If the only concern is fear of legal silliness over RSA, then forget >> about RSA, and mandate DSA up front. > > No, the concern is code space and programmer time. Then why waste their time telling them they "should" implement two protocols, when the result is a decrease in security anyway? > The only time someone might consider dropping DSA is because they ran > out of firmware space, *AND* they are operating in some limited > environment. Surely that isn't the "only" time. >> If you make two a SHOULD, the odds that people will spontaneously >> support three is zilch. > > No, having said that there are two algroithms, [coders will implement a > switch statement on encryption type, and] Adding the third case is much > easier at that point. Is it just me, or is it a bit bizarre to issue a declaration in the standard which is intended to drive developers toward a particular low-level implementation you think they should use? > I've been there. I've managed ID10T programmers. I seldom get the > authority to fire them, alas. Most programmers are idiots. The goal in writing this standard is not to somehow trick them into producing competent work. The task isn't possible, and the side effect of the failed attempt will be cruft in the standard. Regards, Len. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 08:36:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28795 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 08:36:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3E62-0000z5-6H for namedroppers-data@psg.com; Sat, 27 Sep 2003 12:22:46 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 1A3E5W-0000wa-Bq for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 12:22:14 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8RBm2O00658; Sat, 27 Sep 2003 04:48:17 -0700 Date: Sat, 27 Sep 2003 04:48:01 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Markku Savela <msa@burp.tkv.asdf.org> cc: namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 48: Reachability of routable addresses In-Reply-To: <200309141453.h8EErCCI020033@burp.tkv.asdf.org> Message-ID: <Pine.LNX.4.56.0309270446220.391@internaut.com> References: <Pine.LNX.4.53.0309140652280.26877@internaut.com> <200309141453.h8EErCCI020033@burp.tkv.asdf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Section 1.4 of draft-ietf-zeroconf-ipv4-linklocal-09 states: " In order to prevent use of Link-Local IPv4 addresses in off-link communication, the following cautionary measures are advised: a. Routable addresses should be used within applications whenever they are available. b. Names that are globally resolvable to routable addresses should be used within applications whenever they are available. Names that are resolvable only on the local link (such as through use of protocols such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be used in off-link communication. IPV4 addresses and names which can only be resolved on the local link SHOULD NOT be forwarded, they SHOULD only be sent when a Link-Local address is used as the source address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply. c. Link-Local IPv4 addresses MUST NOT be configured in the DNS." Since a routable address is used within applications whenever it is available, a responder with a routable address receiving an LLMNR query will respond to the LLMNR query using a routable source address. Since the host does not use the Link-Local IPv4 address as the source, it also does not respond with RRs containing the IPv4 Link-Local address. This also has the effect of ensuring that a sender querying via DNS or LLMNR cannot receive conflicting answers. Since Link-Local IPv4 addresses are not registered in DNS, a sender cannot receive an RR containing a Link-Local IPV4 address as a response to a DNS query. If the responder has no routable address to register in DNS, then it cannot register any address, and so the sender will query via LLMNR and can receive an RR in the response containing a Link-Local IPv4 address. If the responder is multi-homed, then it can register a routable address in DNS. If an LLMNR query arrives on the interface using the routable address, then the sender will reply using the routable address. If an LLMNR query arrives on an interface using a Link-Local IPv4 address, then the sender will reply using a Link-Local IPv4 address, since the routable address is not reachable on that interface. Replying with a routable address does no harm regardless of the sender's source address, since a sender with only an IPv4 Link-Local address will "ARP for everything" and will be able to contact the responder on a routable address. On Sun, 14 Sep 2003, Markku Savela wrote: > > > In Section 3 change: > > > > "[2] 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." > > > > To: > > > > "[2] A responder with both link-local and routable addresses > > on an interface MUST respond to LLMNR queries for > > A/AAAA RRs only with routable address(es) reachable > > on the interface receiving the query. This encourages > > use of routable address(es) for establishment of new > > connections." > > Object to must "MUST". I want to be able to reply with link-local > address, if the query src is using link-local address. And, I reply > with global addresses, if query source address is global. > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 09:12: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 JAA29677 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 09:12:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3Ept-0003lw-Ly for namedroppers-data@psg.com; Sat, 27 Sep 2003 13:10:09 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 1A3Epk-0003kW-PD for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 13:10:00 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8RCa7l03438 for <namedroppers@ops.ietf.org>; Sat, 27 Sep 2003 05:36:07 -0700 Date: Sat, 27 Sep 2003 05:36:07 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: LLMNR Issue 49: Security considerations Message-ID: <Pine.LNX.4.56.0309270535180.3390@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Issue 49: Security considerations Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 26, 2003 Reference: Document: LLMNR-23 Comment type: T Priority: S Section: 5 Rationale/Explanation of issue: The security considerations section needs to be updated to provide a more complete discussion of denial of service and spoofing attacks. Replace Section 5 with the following: "5. Security Considerations LLMNR is by nature a peer-to-peer name resolution protocol. It is therefore inherently more vulnerable than DNS, since existing DNS security mechanisms are difficult to apply to LLMNR. While tools exist to alllow an attacker to spoof a response to a DNS query, spoofing a response to an LLMNR query is easier since the query is sent to a link-scope multicast address, which can propagate to multiple switch ports. In order to address the security vulnerabilities, the following mechanisms are contemplated: [1] Scope restrictions. [2] Usage restrictions. [3] Cache and port separation. [4] Authentication. These techniques are described in the following sections. 5.1. Scope restriction With LLMNR it is possible that hosts will allocate conflicting names for a period of time, or that attackers will attempt to deny service to other hosts by allocating the same name. Such attacks also allow hosts to receive packets destined for other hosts. Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on both queries and responses. A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can be used to launch denial of service attacks. For example, were the TTL of an LLMNR Response to be set to a value larger than one (1), an attacker could send a large volume of queries from a spoofed source address, causing an off-link target to be deluged with responses. Utilizing a TTL of one (1) in LLMNR responses ensures that they will not be forwarded off-link. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A/AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender. There also are scenarios such as public "hotspots" where attackers can be present on the same link. These threats are most serious in wireless networks such as 802.11, since attackers on a wired network will require physical access to the home network, while wireless attackers may reside outside the home. Link-layer security can be of assistance against these threats if it is available. 5.2. Usage restrictions As noted in Section 3, LLMNR is intended for usage in a limited set of scenarios. While LLMNR can be used to resolve any name, if an interface has been configured with DNS server address(es), then LLMNR SHOULD NOT be used as the primary name resolution mechanism on that interface, although it MAY be used as a name resolution mechanism of last resort. If an LLMNR query is sent whenever a DNS server does not respond in a timely way, then an attacker can poison the LLMNR cache by responding to the query with incorrect information. To some extent, these vulnerabilities exist today, since DNS response spoofing tools are available that can allow an attacker to respond to a query more quickly than a distant DNS server. Since LLMNR queries are sent and responded to on the local-link, an attacker will need to respond more quickly to provide its own response prior to arrival of the response from a legitimate responder. If an LLMNR query is sent for an off-link host, spoofing a response in a timely way is not difficult, since a legitimate response will never be received. The vulnerability is more serious if LLMNR is given higher priority than DNS among the enabled name resolution mechanisms. In such a configuration, a denial of service attack on the DNS server would not be necessary in order to poison the LLMNR cache, since LLMNR queries would be sent even when the DNS server is available. In addition, the LLMNR cache, once poisoned, would take precedence over the DNS cache, eliminating the benefits of cache separation. As a result, LLMNR is only used as a name resolution mechanism of last resort. Note: enabling LLMNR for use in situations where a DNS server has been configured will result in upgraded hosts changing their default behavior without a simultaneous update to configuration information. Where this is considered undesirable, LLMNR SHOULD NOT be enabled by default, so that hosts will neither listen on the link-scope multicast address, nor will they send queries to that address. 5.3. Cache and port separation In order to prevent responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for LLMNR on each interface. The use of separate caches is most effective when LLMNR is used as a name resolution mechanism of last resort, since this minimizes the opportunities for poisoning the LLMNR cache, and decreases reliance on it. LLMNR operates on a separate port from DNS, reducing the likelihood that a DNS server will unintentionally respond to an LLMNR query. 5.4. Authentication LLMNR does not require use of DNSSEC, and as a result, responses to LLMNR queries may be unauthenticated. If authentication is desired, and a pre-arranged security configuration is possible, then IPsec ESP with a null-transform MAY be used to authenticate LLMNR responses. In a small network without a certificate authority, this can be most easily accomplished through configuration of a group pre-shared key for trusted hosts." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 09:56: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 JAA00649 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 09:56:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3FSt-0006Qb-VN for namedroppers-data@psg.com; Sat, 27 Sep 2003 13:50:27 +0000 Received: from [213.243.180.94] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.22) id 1A3FSN-0006Mf-8d for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 13:49:55 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h8RDnoi1001601; Sat, 27 Sep 2003 16:49:51 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h8RDnndD001600; Sat, 27 Sep 2003 16:49:49 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR Issue 48: Reachability of routable addresses From: Mika Liljeberg <mika.liljeberg@welho.com> To: Bernard Aboba <aboba@internaut.com> Cc: Markku Savela <msa@burp.tkv.asdf.org>, namedroppers@ops.ietf.org In-Reply-To: <Pine.LNX.4.56.0309270446220.391@internaut.com> References: <Pine.LNX.4.53.0309140652280.26877@internaut.com> <200309141453.h8EErCCI020033@burp.tkv.asdf.org> <Pine.LNX.4.56.0309270446220.391@internaut.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1064670589.1405.8.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 27 Sep 2003 16:49:49 +0300 X-Spam-Status: No, hits=-9.8 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.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I also object to the proposed wording. On Sat, 2003-09-27 at 14:48, Bernard Aboba wrote: > Replying with a routable address does no harm regardless of the > sender's source address, since a sender with only an IPv4 > Link-Local address will "ARP for everything" and will be able > to contact the responder on a routable address. The zeroconf specification also recognizes that the "ARP for everything" approach does not work for multihomed hosts. In addition, nodes that rendezvous in an ad-hoc situation may have mismatching netmasks, which will prevent them from communicating using the associated routable addresses. In fact, a LLMNR responder has no reliable way of judging which address may be usable for the sender and which might not. Hence, the responder should just send all addresses it has and let the client decide. Note that the client side stub resolver can be implemented in such a way that it only returns usable addresses (or only the "best" address) to the application. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 10:04: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 KAA01024 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 10:04:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3FdO-0007Y3-16 for namedroppers-data@psg.com; Sat, 27 Sep 2003 14:01:18 +0000 Received: from [213.243.180.94] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.22) id 1A3Fcr-0007WF-Ak for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 14:00:45 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h8RDxni1001626; Sat, 27 Sep 2003 16:59:50 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h8RDxnFq001625; Sat, 27 Sep 2003 16:59:49 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR Issue 48: Reachability of routable addresses From: Mika Liljeberg <mika.liljeberg@welho.com> To: Bernard Aboba <aboba@internaut.com> Cc: Markku Savela <msa@burp.tkv.asdf.org>, namedroppers@ops.ietf.org In-Reply-To: <1064670589.1405.8.camel@hades> References: <Pine.LNX.4.53.0309140652280.26877@internaut.com> <200309141453.h8EErCCI020033@burp.tkv.asdf.org> <Pine.LNX.4.56.0309270446220.391@internaut.com> <1064670589.1405.8.camel@hades> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1064671189.1405.15.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 27 Sep 2003 16:59:49 +0300 X-Spam-Status: No, hits=-9.8 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.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Responding to my own mail but one further point which I forgot to make: A node only needs to configure a link-local address if a) it has no routable address, or b) its routable address is not working. In other words, a node that is compliant with zeroconf will only configure a link-local address in addition to a routable one if it really needs one. This being the case it is not appopriate for LLMNR to decide not to advertise the address. MikaL On Sat, 2003-09-27 at 16:49, Mika Liljeberg wrote: > I also object to the proposed wording. > > On Sat, 2003-09-27 at 14:48, Bernard Aboba wrote: > > Replying with a routable address does no harm regardless of the > > sender's source address, since a sender with only an IPv4 > > Link-Local address will "ARP for everything" and will be able > > to contact the responder on a routable address. > > The zeroconf specification also recognizes that the "ARP for everything" > approach does not work for multihomed hosts. In addition, nodes that > rendezvous in an ad-hoc situation may have mismatching netmasks, which > will prevent them from communicating using the associated routable > addresses. In fact, a LLMNR responder has no reliable way of judging > which address may be usable for the sender and which might not. > > Hence, the responder should just send all addresses it has and let the > client decide. Note that the client side stub resolver can be > implemented in such a way that it only returns usable addresses (or only > the "best" address) to the application. > > 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 10:41: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 KAA02733 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 10:41:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3GD7-0009nO-Ox for namedroppers-data@psg.com; Sat, 27 Sep 2003 14:38:13 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 1A3GCz-0009nB-Po for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 14:38:05 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8RE46o08562; Sat, 27 Sep 2003 07:04:06 -0700 Date: Sat, 27 Sep 2003 07:04:06 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Mika Liljeberg <mika.liljeberg@welho.com> cc: Markku Savela <msa@burp.tkv.asdf.org>, namedroppers@ops.ietf.org, erik.guttman@sun.com Subject: Re: LLMNR Issue 48: Reachability of routable addresses In-Reply-To: <1064670589.1405.8.camel@hades> Message-ID: <Pine.LNX.4.56.0309270649360.7589@internaut.com> References: <Pine.LNX.4.53.0309140652280.26877@internaut.com> <200309141453.h8EErCCI020033@burp.tkv.asdf.org> <Pine.LNX.4.56.0309270446220.391@internaut.com> <1064670589.1405.8.camel@hades> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The zeroconf specification also recognizes that the "ARP for everything" > approach does not work for multihomed hosts. One problematic scenario occurs where the sender has a routable address on one interface and a link-local address on another interface. It sends an LLMNR query on the interface with a link-local address and gets back a response with a routable address. It might then attempt to contact the responder via the interface with the routable address (since presumably this interface also has the default route). If the address is not reachable over that interface, then if the sender does not ARP for the routable address on the link-local interface, then communication will fail. If the responder only has a routable address there is no alternative. If it has both a routable address and an IPv4 LL address, then it could respond with the routable address first, and the IPv4 LL address 2nd. On failing to reach the responder over the interface with the routable address, the sender could try the link-local address over the interface with a link-local address. That would work. However, the IPv4LL draft does not recommend configuring a single interface with both a routable and a link-local address. Perhaps we could say that the responder can only respond with addresses that are valid on the interface on which the query is received, and that routable addresses should be listed first? > In fact, a LLMNR responder has no reliable way of judging > which address may be usable for the sender and which might not. I think this is true. However, the LLMNR responder does have the ability to decide which of its addresses are reachable over the interface on which a query is received. > Hence, the responder should just send all addresses it has and let the > client decide. Sending addresses not reachable over the interface on which the query is received is not helpful. > Note that the client side stub resolver can be > implemented in such a way that it only returns usable addresses (or only > the "best" address) to the application. In practice, I don't think that implementations are that likely to do this. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 10:58: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 KAA03119 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 10:58:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3GRP-000ApX-LZ for namedroppers-data@psg.com; Sat, 27 Sep 2003 14:52:59 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 1A3GRH-000Ap7-Gn for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 14:52:51 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8REIrJ09397; Sat, 27 Sep 2003 07:18:53 -0700 Date: Sat, 27 Sep 2003 07:18:53 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Mika Liljeberg <mika.liljeberg@welho.com> cc: Markku Savela <msa@burp.tkv.asdf.org>, namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 48: Reachability of routable addresses In-Reply-To: <1064671189.1405.15.camel@hades> Message-ID: <Pine.LNX.4.56.0309270718320.9372@internaut.com> References: <Pine.LNX.4.53.0309140652280.26877@internaut.com> <200309141453.h8EErCCI020033@burp.tkv.asdf.org> <Pine.LNX.4.56.0309270446220.391@internaut.com> <1064670589.1405.8.camel@hades> <1064671189.1405.15.camel@hades> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_20,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk How would this work? In Section 3 change: "[2] 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." To: "[2] A responder configuring multiple addresses on an interface MUST respond to LLMNR queries only with address(es) reachable over the link on which the query was received. Routable address(es) MUST be included first in the response. This encourages use of routable address(es) for establishment of new connections." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 11:04: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 LAA03294 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 11:04:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3GaA-000BSZ-87 for namedroppers-data@psg.com; Sat, 27 Sep 2003 15:02:02 +0000 Received: from [213.243.180.94] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.22) id 1A3GZt-000BPx-II for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 15:01:45 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h8RF0pi1001810; Sat, 27 Sep 2003 18:00:51 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h8RF0pT0001809; Sat, 27 Sep 2003 18:00:51 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LLMNR Issue 48: Reachability of routable addresses From: Mika Liljeberg <mika.liljeberg@welho.com> To: Bernard Aboba <aboba@internaut.com> Cc: Markku Savela <msa@burp.tkv.asdf.org>, namedroppers@ops.ietf.org In-Reply-To: <Pine.LNX.4.56.0309270718320.9372@internaut.com> References: <Pine.LNX.4.53.0309140652280.26877@internaut.com> <200309141453.h8EErCCI020033@burp.tkv.asdf.org> <Pine.LNX.4.56.0309270446220.391@internaut.com> <1064670589.1405.8.camel@hades> <1064671189.1405.15.camel@hades> <Pine.LNX.4.56.0309270718320.9372@internaut.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1064674851.1407.39.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 27 Sep 2003 18:00:51 +0300 X-Spam-Status: No, hits=-8.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_XIMIAN,X_AUTH_WARNING autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, much better. This addresses the concern I had. MikaL On Sat, 2003-09-27 at 17:18, Bernard Aboba wrote: > How would this work? > > In Section 3 change: > > "[2] 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." > > To: > > "[2] A responder configuring multiple addresses > on an interface MUST respond to LLMNR queries > only with address(es) reachable over the > link on which the query was received. Routable > address(es) MUST be included first in the response. > This encourages use of routable address(es) > for establishment of new connections." > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 11:15: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 LAA03519 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 11:15:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3Gjh-000CHu-U2 for namedroppers-data@psg.com; Sat, 27 Sep 2003 15:11:53 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 1A3Gin-000CF2-EU for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 15:10:57 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8REaxj10448; Sat, 27 Sep 2003 07:36:59 -0700 Date: Sat, 27 Sep 2003 07:36:58 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: Mika Liljeberg <mika.liljeberg@welho.com> cc: Markku Savela <msa@burp.tkv.asdf.org>, namedroppers@ops.ietf.org, erik.guttman@sun.com Subject: Re: LLMNR Issue 48: Reachability of routable addresses In-Reply-To: <1064674851.1407.39.camel@hades> Message-ID: <Pine.LNX.4.56.0309270734330.10302@internaut.com> References: <Pine.LNX.4.53.0309140652280.26877@internaut.com> <200309141453.h8EErCCI020033@burp.tkv.asdf.org> <Pine.LNX.4.56.0309270446220.391@internaut.com> <1064670589.1405.8.camel@hades> <1064671189.1405.15.camel@hades> <Pine.LNX.4.56.0309270718320.9372@internaut.com> <1064674851.1407.39.camel@hades> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, 27 Sep 2003, Mika Liljeberg wrote: > Yes, much better. This addresses the concern I had. > > MikaL Here is a proposed resolution that integrates with the rest of Section 3 a bit better: "3. Usage model LLMNR is a peer-to-peer name resolution protocol that is not intended as a replacement for DNS. By default, LLMNR requests SHOULD be sent only when no manual or automatic DNS configuration has been performed, when DNS servers do not respond, or when they respond to a query with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. An LLMNR sender may send a request for any name. As noted in [DNSPerf], even when DNS servers are configured, a significant fraction of DNS queries do not receive a response, or result in negative responses due to missing inverse mappings or NS records that point to nonexistent or inappropriate hosts. Given this, support for LLMNR as a secondary name resolution mechanism has the potential to result in a large number of inappropriate queries without the following additional restrictions: [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 for PTR RRs via unicast, as specified in Section 2.3. It is the responsibility of the responder to ensure that 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 names defended using the mechanism described in Section 4. In particular: [1] 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. [2] If an IPv4 address is returned, it MUST be reachable through the link over which LLMNR is used. [3] If a name is returned (for example in a CNAME, MX or SRV RR), the name MUST be valid on the local interface. Routable addresses MUST be included first in the response, if available. This encourages use of routable address(es) for establishment of new connections." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 11:42: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 LAA04041 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 11:42:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3H9j-000E8D-El for namedroppers-data@psg.com; Sat, 27 Sep 2003 15:38:47 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 1A3H9b-000E7y-Se for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 15:38:40 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A3H9b-0004ji-1O; Sat, 27 Sep 2003 08:38:39 -0700 From: Randy Bush <randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 27 Sep 2003 08:38:38 -0700 To: Bernard Aboba <aboba@internaut.com> Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR Issue 48: Reachability of routable addresses References: <Pine.LNX.4.53.0309140652280.26877@internaut.com> <200309141453.h8EErCCI020033@burp.tkv.asdf.org> <Pine.LNX.4.56.0309270446220.391@internaut.com> Message-Id: <E1A3H9b-0004ji-1O@ran.psg.com> X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > a. Routable addresses should be used within applications whenever > they are available. how about "whenever possible" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Sep 27 13:16: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 NAA06605 for <dnsext-archive@lists.ietf.org>; Sat, 27 Sep 2003 13:16:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3IU4-000K3D-En for namedroppers-data@psg.com; Sat, 27 Sep 2003 17:03:52 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.22) id 1A3ITn-000K2g-QM for namedroppers@ops.ietf.org; Sat, 27 Sep 2003 17:03:35 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8RGTfv16728 for <namedroppers@ops.ietf.org>; Sat, 27 Sep 2003 09:29:41 -0700 Date: Sat, 27 Sep 2003 09:29:41 -0700 (PDT) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 48: Reachability of routable addresses Message-ID: <Pine.LNX.4.56.0309270926510.16563@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 48 is enclosed below. The proposed fix is as follows: Change Section 3 to the following: "LLMNR is a peer-to-peer name resolution protocol that is not intended as a replacement for DNS. By default, LLMNR requests SHOULD be sent only when no manual or automatic DNS configuration has been performed, when DNS servers do not respond, or when they respond to a query with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section. An LLMNR sender may send a request for any name. As noted in [DNSPerf], even when DNS servers are configured, a significant fraction of DNS queries do not receive a response, or result in negative responses due to missing inverse mappings or NS records that point to nonexistent or inappropriate hosts. Given this, support for LLMNR as a secondary name resolution mechanism has the potential to result in a large number of inappropriate queries without the following additional restrictions: [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 for PTR RRs via unicast, as specified in Section 2.3. It is the responsibility of the responder to ensure that 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 names defended using the mechanism described in Section 4. In particular: [1] 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. [2] If an IPv4 address is returned, it MUST be reachable through the link over which LLMNR is used. [3] If a name is returned (for example in a CNAME, MX or SRV RR), the name MUST be valid on the local interface. Routable addresses MUST be included first in the response, if available. This encourages use of routable address(es) for establishment of new connections." -------------------------------------------------------------- Issue 48: Reachability of routable addresses Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 13, 2003 Reference: Document: LLMNR-23 Comment type: T Priority: S Section: 3 Rationale/Explanation of issue: If a host has both link-scope and routable addresses, it should only prefer the routable address in responses if that routable address is reachable on the interface on which the query was received. Otherwise the query sender could end up resolving a name to an address that would not respond to ARP or ND/NS. In Section 3 change: "[2] 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." To: "[2] A responder with both link-local and routable addresses on an interface MUST respond to LLMNR queries for A/AAAA RRs only with routable address(es) reachable on the interface receiving the query. This encourages use of routable address(es) for establishment of new connections." [Markku Savela] Object to must "MUST". I want to be able to reply with link-local address, if the query src is using link-local address. And, I reply with global addresses, if query source address is global. [Bernard Aboba] Section 1.4 of draft-ietf-zeroconf-ipv4-linklocal-09 states: " In order to prevent use of Link-Local IPv4 addresses in off-link communication, the following cautionary measures are advised: a. Routable addresses should be used within applications whenever they are available. b. Names that are globally resolvable to routable addresses should be used within applications whenever they are available. Names that are resolvable only on the local link (such as through use of protocols such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be used in off-link communication. IPV4 addresses and names which can only be resolved on the local link SHOULD NOT be forwarded, they SHOULD only be sent when a Link-Local address is used as the source address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply. c. Link-Local IPv4 addresses MUST NOT be configured in the DNS." Since a routable address is used within applications whenever it is available, a responder with a routable address receiving an LLMNR query will respond to the LLMNR query using a routable source address. Since the host does not use the Link-Local IPv4 address as the source, it also does not respond with RRs containing the IPv4 Link-Local address. This also has the effect of ensuring that a sender querying via DNS or LLMNR cannot receive conflicting answers. Since Link-Local IPv4 addresses are not registered in DNS, a sender cannot receive an RR containing a Link-Local IPV4 address as a response to a DNS query. If the responder has no routable address to register in DNS, then it cannot register any address, and so the sender will query via LLMNR and can receive an RR in the response containing a Link-Local IPv4 address. If the responder is multi-homed, then it can register a routable address in DNS. If an LLMNR query arrives on the interface using the routable address, then the sender will reply using the routable address. If an LLMNR query arrives on an interface using a Link-Local IPv4 address, then the sender will reply using a Link-Local IPv4 address, since the routable address is not reachable on that interface. Replying with a routable address does no harm regardless of the sender's source address, since a sender with only an IPv4 Link-Local address will "ARP for everything" and will be able to contact the responder on a routable address. [Mika Liljeberg] I also object to the proposed wording. On Sat, 2003-09-27 at 14:48, Bernard Aboba wrote: > Replying with a routable address does no harm regardless of the > sender's source address, since a sender with only an IPv4 > Link-Local address will "ARP for everything" and will be able > to contact the responder on a routable address. The zeroconf specification also recognizes that the "ARP for everything" approach does not work for multihomed hosts. In addition, nodes that rendezvous in an ad-hoc situation may have mismatching netmasks, which will prevent them from communicating using the associated routable addresses. In fact, a LLMNR responder has no reliable way of judging which address may be usable for the sender and which might not. Hence, the responder should just send all addresses it has and let the client decide. Note that the client side stub resolver can be implemented in such a way that it only returns usable addresses (or only the "best" address) to the application. A node only needs to configure a link-local address if a) it has no routable address, or b) its routable address is not working. In other words, a node that is compliant with zeroconf will only configure a link-local address in addition to a routable one if it really needs one. This being the case it is not appropriate for LLMNR to decide not to advertise the address. [Bernard Aboba] One problematic scenario occurs where the sender has a routable address on one interface and a link-local address on another interface. It sends an LLMNR query on the interface with a link-local address and gets back a response with a routable address. It might then attempt to contact the responder via the interface with the routable address (since presumably this interface also has the default route). If the address is not reachable over that interface, then if the sender does not ARP for the routable address on the link-local interface, then communication will fail. If the responder only has a routable address there is no alternative. If it has both a routable address and an IPv4 LL address, then it could respond with the routable address first, and the IPv4 LL address 2nd. On failing to reach the responder over the interface with the routable address, the sender could try the link-local address over the interface with a link-local address. That would work. However, the IPv4LL draft does not recommend configuring a single interface with both a routable and a link-local address. Perhaps we could say that the responder can only respond with addresses that are valid on the interface on which the query is received, and that routable addresses should be listed first? > In fact, a LLMNR responder has no reliable way of judging > which address may be usable for the sender and which might not. I think this is true. However, the LLMNR responder does have the ability to decide which of its addresses are reachable over the interface on which a query is received. > Hence, the responder should just send all addresses it has and let the > client decide. Sending addresses not reachable over the interface on which the query is received is not helpful. > Note that the client side stub resolver can be > implemented in such a way that it only returns usable addresses (or only > the "best" address) to the application. In practice, I don't think that implementations are that likely to do this. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 11:17: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 LAA21223 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 11:17:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3d5h-000H0I-4k for namedroppers-data@psg.com; Sun, 28 Sep 2003 15:04:05 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A3d5Z-000Gzq-8I for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 15:03:57 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9E8301394B for <namedroppers@ops.ietf.org>; Sun, 28 Sep 2003 15:03:22 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: wcard-clarify's change X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 28 Sep 2003 15:03:22 +0000 Message-Id: <20030928150322.9E8301394B@sa.vix.com> X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk this section 6.3 CNAME RR's at a Wild Card Domain Name specifies a change to rfc1034 behaviour, whereby a cname at a wildcard will be followed. i consider this change to be ill considered, and would like to see the document progress without it. wcard-clarify should only clarify, and not change anything. a longer rant about why this change is not only ill considered but also ill advised will be available for the price of one beer (in minneapolis.) note that bind8 and bind9 both follow cnames at wildcards, in violation of rfc1034, and that i would rather we patch the code than change the spec. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 13:59: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 NAA25338 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 13:59:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3fkv-0001O1-BD for namedroppers-data@psg.com; Sun, 28 Sep 2003 17:54:49 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 1A3fjl-0001J1-H5 for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 17:53:37 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A3fjk-0001Wn-JM; Sun, 28 Sep 2003 10:53:36 -0700 From: Randy Bush <randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 28 Sep 2003 10:53:36 -0700 To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change References: <20030928150322.9E8301394B@sa.vix.com> Message-Id: <E1A3fjk-0001Wn-JM@ran.psg.com> X-Spam-Status: No, hits=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > this section > 6.3 CNAME RR's at a Wild Card Domain Name > specifies a change to rfc1034 behaviour, whereby a cname at a > wildcard will be followed. could you point us to the specific text(s) from rfc 1034 which proscribes following wildcard cnames? 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 15:57: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 PAA28989 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 15:57:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3hVh-0008IG-4s for namedroppers-data@psg.com; Sun, 28 Sep 2003 19:47:13 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A3hUH-0008Cy-UH for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 19:45:45 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 873B713960; Sun, 28 Sep 2003 19:45:15 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change References: <20030928150322.9E8301394B@sa.vix.com> <bl77ru$o81$1@sf1.isc.org> From: Paul Vixie <vixie@vix.com> Date: 28 Sep 2003 19:45:15 +0000 In-Reply-To: <bl77ru$o81$1@sf1.isc.org> Message-ID: <g3brt48zp0.fsf@sa.vix.com> Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > this section > > 6.3 CNAME RR's at a Wild Card Domain Name > > specifies a change to rfc1034 behaviour, whereby a cname at a > > wildcard will be followed. > > could you point us to the specific text(s) from rfc 1034 which > proscribes following wildcard cnames? according to the wcard-clarify draft: 6.3 CNAME RR's at a Wild Card Domain Name The issue of CNAME RR's owned by wild card domain names has prompted a suggested change to the last paragraph of step 3c of the algorithm in 4.3.2. The changed text is this: ...it's section 4.3.2. my own reading shows that this is indeed the case. -- Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 16:05: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 QAA29228 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 16:05:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3hhP-0009Cy-Uj for namedroppers-data@psg.com; Sun, 28 Sep 2003 19:59:19 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 1A3hhI-0009Cg-0x for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 19:59:12 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A3hhH-0004eI-AL; Sun, 28 Sep 2003 12:59:11 -0700 From: Randy Bush <randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 28 Sep 2003 12:59:10 -0700 To: Paul Vixie <vixie@vix.com> Cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change References: <20030928150322.9E8301394B@sa.vix.com> <bl77ru$o81$1@sf1.isc.org> <g3brt48zp0.fsf@sa.vix.com> Message-Id: <E1A3hhH-0004eI-AL@ran.psg.com> X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> this section >>> 6.3 CNAME RR's at a Wild Card Domain Name >>> specifies a change to rfc1034 behaviour, whereby a cname at a >>> wildcard will be followed. >> could you point us to the specific text(s) from rfc 1034 which >> proscribes following wildcard cnames? > ...it's section 4.3.2. my own reading shows that this is indeed > the case. which says If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and so, if qtype == cname then it would seem that a response would be appropriate. though admittedly this is not a very interesting or sorely needed use. if qtype != cname, then it would seem to say return no answer. so please clue me in on how this makes the presence of a wildcard label on a cname illegal in the data? 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 16:14: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 QAA29589 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 16:14:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3hqL-000A0Y-Sx for namedroppers-data@psg.com; Sun, 28 Sep 2003 20:08:33 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 1A3hqJ-000A0E-Pp for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 20:08:31 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A3hqJ-0004su-AO; Sun, 28 Sep 2003 13:08:31 -0700 From: Randy Bush <randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 28 Sep 2003 13:08:30 -0700 To: Paul Vixie <vixie@vix.com> Cc: namedroppers <namedroppers@ops.ietf.org> Subject: Re: wcard-clarify's change References: <20030928150322.9E8301394B@sa.vix.com> <bl77ru$o81$1@sf1.isc.org> <g3brt48zp0.fsf@sa.vix.com> <E1A3hhH-0004eI-AL@ran.psg.com> Message-Id: <E1A3hqJ-0004su-AO@ran.psg.com> X-Spam-Status: No, hits=-0.4 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>> this section >>>> 6.3 CNAME RR's at a Wild Card Domain Name >>>> specifies a change to rfc1034 behaviour, whereby a cname at a >>>> wildcard will be followed. >>> could you point us to the specific text(s) from rfc 1034 which >>> proscribes following wildcard cnames? >> ...it's section 4.3.2. my own reading shows that this is indeed >> the case. > which says > If the "*" label does exist, match RRs at that node > against QTYPE. If any match, copy them into the answer > section, but set the owner of the RR to be QNAME, and > so, if qtype == cname then it would seem that a response would be > appropriate. though admittedly this is not a very interesting or > sorely needed use. > if qtype != cname, then it would seem to say return no answer. > so please clue me in on how this makes the presence of a wildcard > label on a cname illegal in the data? whoops! got it. it may be present in the data, and may indeed be returned if qtype == cname. but the cname rr will not be returned if qtype != cname, which is what wcard-clarify was seeming to fumble toward. therefore, i can see that wcard-clarify is indeed a change not a clarification. and i can see that bind's current behavior is a bug. thanks. what i am not firmly sure of is whether, in the abstract, the proposed change would be good for the internet or not. could you amplify if i send a jpg of a root beer? oh, and would the same theses hold for wildcard dnames? 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 16:28: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 QAA29858 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 16:28:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3i6E-000B00-HH for namedroppers-data@psg.com; Sun, 28 Sep 2003 20:24:58 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.22) id 1A3i5d-000Axm-46 for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 20:24:21 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h8SKGvIe003543; Mon, 29 Sep 2003 03:16:58 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8SKDOH10382; Mon, 29 Sep 2003 03:13:53 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Randy Bush <randy@psg.com> cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <E1A3fjk-0001Wn-JM@ran.psg.com> References: <E1A3fjk-0001Wn-JM@ran.psg.com> <20030928150322.9E8301394B@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Sep 2003 03:13:24 +0700 Message-ID: <10465.1064780004@munnari.OZ.AU> X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sun, 28 Sep 2003 10:53:36 -0700 From: Randy Bush <randy@psg.com> Message-ID: <E1A3fjk-0001Wn-JM@ran.psg.com> | could you point us to the specific text(s) from rfc 1034 which | proscribes following wildcard cnames? There is none. But, if you follow the algorithm in section 4.3.2 precisely (exactly as it is written, with no latitude for common sense) then a wildcard would match a CNAME only for a lookup of type CNAME, and no other. That's because 4.3.2 (3) c says... If the "*" label does exist, match RRs at that node against QTYPE. If any match, ... So, if the '*' is of type CNAME, and QTYPE is A (or AAAA or MX or whatever), then no data gets copied into the answer, and the "goto 6" doesn't happen. Of course, in this case, since nothing says "set an authoritative name error" (as it does if the '*' doesn't exist), one must presume that the correct answer is NODATA (no answer, no error code). An alternative is to assume that this is just dumb, and that having the CNAME exist when you do a CNAME type lookup - which answer can then be cached at a cache, and used to produce an answer there to a later A (or other) lookup of the same name - but not used when the authoritative server generates the same answer is just plain crazy - and that most likely the real intent (had anyone seriously considered it) would have been for "match" in that section to have included the normal CNAME processing (as in 4.3.2 (3) a). I disagree with Paul's suggestion though - I don't think it is rational to simply leave 1034 unchanged here - either CNAME at a '*' label needs to simply be made invalid, or 4.3.2 (3) c needs to be fixed to allow CNAME processing to take place there. Of those, I think I'd prefer the latter, it follows the principle of least astonishment. While a wildcard CNAME would be a pretty stupid thing do do (most uses of wildcards are pretty stupid things to do), I can't think of any really good reason to outlaw it. kre ps: Paul, I won't be in Minneapolis, so if you want to give the longer rant as to why a better change would be to make "* IN CNAME ..." illegal rather than making it effective, you have better do it on the list. I think this is one area however where a fix is essential - and this is a fix to wildcard processing, so this draft is where it should happen. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 18:22: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 SAA03451 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 18:22:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3jp1-000INK-Gl for namedroppers-data@psg.com; Sun, 28 Sep 2003 22:15:19 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 1A3jot-000IN3-II for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 22:15:11 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A3jos-0007z7-DK; Sun, 28 Sep 2003 15:15:10 -0700 From: Randy Bush <randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 28 Sep 2003 15:15:09 -0700 To: Paul Vixie <vixie@vix.com> Cc: namedroppers <namedroppers@ops.ietf.org> Subject: Re: wcard-clarify's change References: <20030928150322.9E8301394B@sa.vix.com> <bl77ru$o81$1@sf1.isc.org> <g3brt48zp0.fsf@sa.vix.com> <E1A3hhH-0004eI-AL@ran.psg.com> <E1A3hqJ-0004su-AO@ran.psg.com> Message-Id: <E1A3jos-0007z7-DK@ran.psg.com> X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit a useful application of wildcard cnames was just pointed out to me. i often get folk asking me o is foo.{gn,lr,ng,...} taken? o if not, how do i register it? and i could simply do *.gn. cname no-domain.psg.com. *.lr. cname no-domain.psg.com. *.ng. cname no-domain.psg.com. ... and use a name-based virtual server to tell them the name is not in use and point them to the forms and procedures to register in the domain(s). otoh, admittedly, i could use up an ip address, and not use a name-based virtual server. but this is still a valid use of 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 19:04: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 TAA04586 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 19:04:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3kVq-000Ljb-IO for namedroppers-data@psg.com; Sun, 28 Sep 2003 22:59:34 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A3kVi-000LjJ-9l for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 22:59:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1640E1390E for <namedroppers@ops.ietf.org>; Sun, 28 Sep 2003 22:58:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: Message from Robert Elz <kre@munnari.OZ.AU> of "Mon, 29 Sep 2003 03:13:24 +0700." <10465.1064780004@munnari.OZ.AU> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 28 Sep 2003 22:58:56 +0000 Message-Id: <20030928225856.1640E1390E@sa.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > But, if you follow the algorithm in section 4.3.2 precisely (exactly as > it is written, with no latitude for common sense) then a wildcard would > match a CNAME only for a lookup of type CNAME, and no other. i consider that the correct, and sensible, interpretation. clarification is needed only because it's astonishing to some, not because it's unclear as written. > That's because 4.3.2 (3) c says... > > If the "*" label does exist, match RRs at that node > against QTYPE. If any match, ... > > So, if the '*' is of type CNAME, and QTYPE is A (or AAAA or MX or > whatever), then no data gets copied into the answer, and the "goto 6" > doesn't happen. right. cname processing happens earlier than, and exclusive of, wildcarding. > Of course, in this case, since nothing says "set an authoritative name > error" (as it does if the '*' doesn't exist), one must presume that > the correct answer is NODATA (no answer, no error code). i think if someone puts a wildcard cname into their zone, then noerror/nodata is the correct answer. (the workaround is, don't put in a wildcard cname.) > I disagree with Paul's suggestion though - I don't think it is rational > to simply leave 1034 unchanged here - either CNAME at a '*' label needs > to simply be made invalid, or 4.3.2 (3) c needs to be fixed to allow > CNAME processing to take place there. then at least our disagreement requires no clarification. > ps: Paul, I won't be in Minneapolis, so if you want to give the longer > rant as to why a better change would be to make "* IN CNAME ..." illegal > rather than making it effective, you have better do it on the list. i don't expect that we'd entertain anybody by such ranting. let's see if anyone else has a view on this topic. > I think this is one area however where a fix is essential - and this is > a fix to wildcard processing, so this draft is where it should happen. at a minimum, i think that this draft should only clarify, not "fix" things. separately, we can rant about whether rfc1034 needs to be "fixed". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 19:08: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 TAA04680 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 19:08:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3kbp-000MJz-Gs for namedroppers-data@psg.com; Sun, 28 Sep 2003 23:05:45 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 1A3kbJ-000MFa-Sy; Sun, 28 Sep 2003 23:05:14 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h8SN3u0o075941; Mon, 29 Sep 2003 09:03:57 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309282303.h8SN3u0o075941@bsdi.dv.isc.org> To: Randy Bush <randy@psg.com> Cc: Paul Vixie <vixie@vix.com>, namedroppers <namedroppers@ops.ietf.org> From: Mark.Andrews@isc.org Subject: Re: wcard-clarify's change In-reply-to: Your message of "Sun, 28 Sep 2003 15:15:09 MST." <E1A3jos-0007z7-DK@ran.psg.com> Date: Mon, 29 Sep 2003 09:03:56 +1000 X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > a useful application of wildcard cnames was just pointed out to me. > > i often get folk asking me > o is foo.{gn,lr,ng,...} taken? > o if not, how do i register it? > > and i could simply do > *.gn. cname no-domain.psg.com. > *.lr. cname no-domain.psg.com. > *.ng. cname no-domain.psg.com. > ... > > and use a name-based virtual server to tell them the name is not in > use and point them to the forms and procedures to register in the > domain(s). > > otoh, admittedly, i could use up an ip address, and not use a > name-based virtual server. but this is still a valid use of > > randy One would hope as technical contact for those tld's that you would actually dissuade this use. > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 19:11: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 TAA04769 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 19:11:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3kfa-000Mbv-5M for namedroppers-data@psg.com; Sun, 28 Sep 2003 23:09:38 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 1A3kfS-000MbM-6o for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 23:09:30 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A3kfR-0009am-Gk; Sun, 28 Sep 2003 16:09:29 -0700 From: Randy Bush <randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 28 Sep 2003 16:09:29 -0700 To: Mark.Andrews@isc.org Cc: namedroppers <namedroppers@ops.ietf.org> Subject: Re: wcard-clarify's change References: <E1A3jos-0007z7-DK@ran.psg.com> <200309282303.h8SN3u0o075941@bsdi.dv.isc.org> Message-Id: <E1A3kfR-0009am-Gk@ran.psg.com> X-Spam-Status: No, hits=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> a useful application of wildcard cnames was just pointed out to me. >> >> i often get folk asking me >> o is foo.{gn,lr,ng,...} taken? >> o if not, how do i register it? >> >> and i could simply do >> *.gn. cname no-domain.psg.com. >> *.lr. cname no-domain.psg.com. >> *.ng. cname no-domain.psg.com. >> ... >> >> and use a name-based virtual server to tell them the name is not in >> use and point them to the forms and procedures to register in the >> domain(s). >> >> otoh, admittedly, i could use up an ip address, and not use a >> name-based virtual server. but this is still a valid use of >> >> randy > One would hope as technical contact for those tld's that > you would actually dissuade this use. perhaps you would care to go beyond hope into technical or social reasons why this is damaging to the internet? 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 19:39: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 TAA05445 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 19:39:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3l2w-000OEW-98 for namedroppers-data@psg.com; Sun, 28 Sep 2003 23:33:46 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 1A3l2Q-000OB2-IB; Sun, 28 Sep 2003 23:33:14 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h8SNVv0o076072; Mon, 29 Sep 2003 09:31:57 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309282331.h8SNVv0o076072@bsdi.dv.isc.org> To: Randy Bush <randy@psg.com> Cc: namedroppers <namedroppers@ops.ietf.org> From: Mark.Andrews@isc.org Subject: Re: wcard-clarify's change In-reply-to: Your message of "Sun, 28 Sep 2003 16:09:29 MST." <E1A3kfR-0009am-Gk@ran.psg.com> Date: Mon, 29 Sep 2003 09:31:57 +1000 X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >> a useful application of wildcard cnames was just pointed out to me. > >> > >> i often get folk asking me > >> o is foo.{gn,lr,ng,...} taken? > >> o if not, how do i register it? > >> > >> and i could simply do > >> *.gn. cname no-domain.psg.com. > >> *.lr. cname no-domain.psg.com. > >> *.ng. cname no-domain.psg.com. > >> ... > >> > >> and use a name-based virtual server to tell them the name is not in > >> use and point them to the forms and procedures to register in the > >> domain(s). > >> > >> otoh, admittedly, i could use up an ip address, and not use a > >> name-based virtual server. but this is still a valid use of You can still use a name-based virtual server with IP addresses. > >> randy > > One would hope as technical contact for those tld's that > > you would actually dissuade this use. > > perhaps you would care to go beyond hope into technical or social > reasons why this is damaging to the internet? > > randy I actually like to get error messages when I mistype a address. bsdi:src 09:17 {1899} % date; telnet xxx.yy.uk ; date Mon Sep 29 09:18:10 EST 2003 xxx.yy.uk: No address associated with hostname Mon Sep 29 09:18:10 EST 2003 bsdi:src 09:18 {1900} % date; telnet this-name-doesnt-exist.com ; date Mon Sep 29 09:18:18 EST 2003 Trying 64.94.110.11... telnet: connect to address 64.94.110.11: Operation timed out telnet: Unable to connect to remote host Mon Sep 29 09:19:33 EST 2003 bsdi:src 09:18 {1901} % Lots of traffic for no real benefit on other techniques for finding out if a name exists or not. Verisign don't even send RST with their sitefinder service. 09:22:03.743383 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 202454889 0> (DF) [tos 0x10] 09:22:06.739395 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 202455189 0> (DF) [tos 0x10] 09:22:09.939438 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 202455509 0> (DF) [tos 0x10] 09:22:13.139500 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 09:22:16.339581 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 09:22:19.539617 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 09:22:25.739726 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 09:22:37.939919 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] 09:23:02.140393 211.29.163.60.3839 > 64.94.110.11.23: S 323070240:323070240(0) win 57344 <mss 1460> (DF) [tos 0x10] -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 19:45: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 TAA05590 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 19:45:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3lCE-000P07-0R for namedroppers-data@psg.com; Sun, 28 Sep 2003 23:43:22 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.22) id 1A3lBp-000Oyu-Kb for namedroppers@ops.ietf.org; Sun, 28 Sep 2003 23:42:57 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A3lBp-000Dr6-4Z; Sun, 28 Sep 2003 16:42:57 -0700 From: Randy Bush <randy@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 28 Sep 2003 16:42:56 -0700 To: Mark.Andrews@isc.org Cc: namedroppers <namedroppers@ops.ietf.org> Subject: Re: wcard-clarify's change References: <E1A3kfR-0009am-Gk@ran.psg.com> <200309282331.h8SNVv0o076072@bsdi.dv.isc.org> Message-Id: <E1A3lBp-000Dr6-4Z@ran.psg.com> X-Spam-Status: No, hits=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> One would hope as technical contact for those tld's that >>> you would actually dissuade this use. >> perhaps you would care to go beyond hope into technical or social >> reasons why this is damaging to the internet? > I actually like to get error messages when I mistype a address. > bsdi:src 09:17 {1899} % date; telnet xxx.yy.uk ; date > Mon Sep 29 09:18:10 EST 2003 > xxx.yy.uk: No address associated with hostname > Mon Sep 29 09:18:10 EST 2003 > bsdi:src 09:18 {1900} % date; telnet this-name-doesnt-exist.com ; date > Mon Sep 29 09:18:18 EST 2003 > Trying 64.94.110.11... > telnet: connect to address 64.94.110.11: Operation timed out > telnet: Unable to connect to remote host > Mon Sep 29 09:19:33 EST 2003 > bsdi:src 09:18 {1901} % yep. but not one of the folk who ask me "is domain name foo taken" would know an error message if windows 95 gave it to them. and they think dig is something done with a shovel, unless they're over 50 and still think they're pretty hep. end users seem to use dns for web lookup and for email addresses. but duane wessels's environmental impact statement is relevant to this as well <http://www.packet-pushers.net/tld-wildcards/>. so, while i don't think i will do it, i suspect other will, and i am not sure i should tell them they absolutely shouldn't. have you tried <http://no-domane.museum/>? 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 20:04: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 UAA05974 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 20:04:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3lT2-0000Q9-3J for namedroppers-data@psg.com; Mon, 29 Sep 2003 00:00:44 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 1A3lSd-0000PL-Fu; Mon, 29 Sep 2003 00:00:19 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h8SNx30o076194; Mon, 29 Sep 2003 09:59:03 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309282359.h8SNx30o076194@bsdi.dv.isc.org> To: Randy Bush <randy@psg.com> Cc: namedroppers <namedroppers@ops.ietf.org> From: Mark.Andrews@isc.org Subject: Re: wcard-clarify's change In-reply-to: Your message of "Sun, 28 Sep 2003 16:42:56 MST." <E1A3lBp-000Dr6-4Z@ran.psg.com> Date: Mon, 29 Sep 2003 09:59:03 +1000 X-Spam-Status: No, hits=1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >>> One would hope as technical contact for those tld's that > >>> you would actually dissuade this use. > >> perhaps you would care to go beyond hope into technical or social > >> reasons why this is damaging to the internet? > > I actually like to get error messages when I mistype a address. > > bsdi:src 09:17 {1899} % date; telnet xxx.yy.uk ; date > > Mon Sep 29 09:18:10 EST 2003 > > xxx.yy.uk: No address associated with hostname > > Mon Sep 29 09:18:10 EST 2003 > > bsdi:src 09:18 {1900} % date; telnet this-name-doesnt-exist.com ; date > > Mon Sep 29 09:18:18 EST 2003 > > Trying 64.94.110.11... > > telnet: connect to address 64.94.110.11: Operation timed out > > telnet: Unable to connect to remote host > > Mon Sep 29 09:19:33 EST 2003 > > bsdi:src 09:18 {1901} % > > yep. but not one of the folk who ask me "is domain name foo taken" > would know an error message if windows 95 gave it to them. and they > think dig is something done with a shovel, unless they're over 50 and > still think they're pretty hep. This is a education process. The still need to learn how to interpert error messages unless you make adding wildcards MANDITORY below every non-wildcard node in the DNS and remove empty nodes. > end users seem to use dns for web lookup and for email addresses. > but duane wessels's environmental impact statement is relevant to > this as well <http://www.packet-pushers.net/tld-wildcards/>. so, > while i don't think i will do it, i suspect other will, and i am > not sure i should tell them they absolutely shouldn't. > > have you tried <http://no-domane.museum/>? But does what museum does work for general tlds verses the very narrow focus of museum? > randy -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 20:13: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 UAA06187 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 20:13:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3lci-0001Dc-P7 for namedroppers-data@psg.com; Mon, 29 Sep 2003 00:10:44 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 1A3lcC-0001CM-SV; Mon, 29 Sep 2003 00:10:13 +0000 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Message-Id: <200309282356.IAA07561@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA07561; Mon, 29 Sep 2003 08:56:09 +0900 Subject: Re: wcard-clarify's change In-Reply-To: <E1A3jos-0007z7-DK@ran.psg.com> from Randy Bush at "Sep 28, 2003 03:15:09 pm" To: Randy Bush <randy@psg.com> Date: Mon, 29 Sep 2003 08:56:09 +0859 () CC: Paul Vixie <vixie@vix.com>, namedroppers <namedroppers@ops.ietf.org> X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy; > a useful application of wildcard cnames was just pointed out to me. > > i often get folk asking me > o is foo.{gn,lr,ng,...} taken? > o if not, how do i register it? > > and i could simply do > *.gn. cname no-domain.psg.com. > *.lr. cname no-domain.psg.com. > *.ng. cname no-domain.psg.com. > ... > > and use a name-based virtual server to tell them the name is not in > use and point them to the forms and procedures to register in the > domain(s). You can do it better (the web server can know the domain name desired) with > *.gn. ns no-domain-ns0.psg.com. > *.gn. ns no-domain-ns1.psg.com. > *.lr. ns no-domain-ns0.psg.com. > *.lr. ns no-domain-ns1.psg.com. > *.ng. ns no-domain-ns0.psg.com. > *.ng. ns no-domain-ns1.psg.com. which is why delegation-only of BIND does not work. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 20:36: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 UAA06710 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 20:36:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3lw8-0002Xj-Oj for namedroppers-data@psg.com; Mon, 29 Sep 2003 00:30:48 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 1A3lvc-0002Uw-3d; Mon, 29 Sep 2003 00:30:16 +0000 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Message-Id: <200309290019.JAA07675@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA07675; Mon, 29 Sep 2003 09:19:14 +0900 Subject: Re: wcard-clarify's change In-Reply-To: <10465.1064780004@munnari.OZ.AU> from Robert Elz at "Sep 29, 2003 03:13:24 am" To: Robert Elz <kre@munnari.OZ.AU> Date: Mon, 29 Sep 2003 09:19:14 +0859 () CC: Randy Bush <randy@psg.com>, Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk kre; > Of course, in this case, since nothing says "set an authoritative name error" > (as it does if the '*' doesn't exist), one must presume that the correct > answer is NODATA (no answer, no error code). That is the best possible interpretation of 4.3.2. However, it is also written in rfc1034 that: CNAME RRs cause special action in DNS software. When a name server fails to find a desired RR in the resource set associated with the domain name, it checks to see if the resource set consists of a CNAME record with a matching class. And it can be said that a domain name matching a wildcard CNAME is associated with the CNAME but no other RRs. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 23:10: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 XAA10356 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 23:10:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3oHj-000CZK-I3 for namedroppers-data@psg.com; Mon, 29 Sep 2003 03:01:15 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A3oHa-000CYM-0b for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 03:01:06 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6FA4A13968 for <namedroppers@ops.ietf.org>; Mon, 29 Sep 2003 03:00:35 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers <namedroppers@ops.ietf.org> Subject: Re: wcard-clarify's change In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 29 Sep 2003 08:56:09 +0859." <200309282356.IAA07561@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 29 Sep 2003 03:00:35 +0000 Message-Id: <20030929030035.6FA4A13968@sa.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > You can do it better (the web server can know the domain name > desired) with > > > *.gn. ns no-domain-ns0.psg.com. > > *.gn. ns no-domain-ns1.psg.com. > > *.lr. ns no-domain-ns0.psg.com. > > *.lr. ns no-domain-ns1.psg.com. > > *.ng. ns no-domain-ns0.psg.com. > > *.ng. ns no-domain-ns1.psg.com. not with bind you won't. perhaps there is software somewhere that misreads and misimplements 1034 in that way, but this once, bind isn't it. it's dimly possible that dname is supposed to work like this, but not NS. > which is why delegation-only of BIND does not work. that being a separate issue, i'll address it anyway. the official position of verisign with regard to their wildcard labels under .com and .net is "users are free to block sitefinder if they want, we're only doing it as a service to the internet community." before they (or indeed the .tk people or any of the others) could hack their name servers to respond with an extra set of NS RRs for this, they would have to make a public statement, "we just want to monetize eyeballs and we'll crush anyone who gets in our way" which i think is a statement they won't make. therefore root-delegation-only is not BIND's answer to a prolonged conflict but rather a way to let people "opt out" of something that at least one gtld administrator has said "opting out of" is okay. had this been an actual "final solution to wildcards" it would likely have been implemented very differently. this is a layer 9 problem, and root-delegation-only is essentially a layer 9 solution 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 23:10: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 XAA10381 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 23:10:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3oMQ-000Cvn-CI for namedroppers-data@psg.com; Mon, 29 Sep 2003 03:06:06 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A3oMO-000CvP-8n for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 03:06:04 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 11D1B1390E for <namedroppers@ops.ietf.org>; Mon, 29 Sep 2003 03:05:34 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 29 Sep 2003 09:19:14 +0859." <200309290019.JAA07675@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 29 Sep 2003 03:05:34 +0000 Message-Id: <20030929030534.11D1B1390E@sa.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Of course, in this case, since nothing says "set an authoritative > > name error" (as it does if the '*' doesn't exist), one must presume > > that the correct answer is NODATA (no answer, no error code). > > That is the best possible interpretation of 4.3.2. i agree. moreover: > However, it is also written in rfc1034 that: > > CNAME RRs cause special action in DNS software. When a name server > fails to find a desired RR in the resource set associated with the > domain name, it checks to see if the resource set consists of a CNAME > record with a matching class. > > And it can be said that a domain name matching a wildcard CNAME > is associated with the CNAME but no other RRs. what 1034 calls a "resource set" is a "set of rrsets" by modern terminology, that is, "all rrsets at a node" or even "all rrs at a node". by "associated with a domain name" in the paragraph quoted above, wildcards are uninvolved. there is no incoherency (on this point) in 1034. wildcard cnames aren't in. the fact that any version of bind ever pretended or still pretends to support this unspecified behaviour is an embarrassment to me personally and to isc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Sep 28 23:24: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 XAA10711 for <dnsext-archive@lists.ietf.org>; Sun, 28 Sep 2003 23:24:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3oas-000E8s-El for namedroppers-data@psg.com; Mon, 29 Sep 2003 03:21:02 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.22) id 1A3oaM-000E3d-J6 for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 03:20:30 +0000 Received: (qmail 31943 invoked by uid 1016); 29 Sep 2003 03:20:49 -0000 Date: 29 Sep 2003 03:20:49 -0000 Message-ID: <20030929032049.31942.qmail@cr.yp.to> From: "D. J. Bernstein" <djb@cr.yp.to> To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change References: <200309282356.IAA07561@necom830.hpcl.titech.ac.jp> <20030929030035.6FA4A13968@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes, paraphrasing VeriSign: > "users are free to block sitefinder if they want, we're > only doing it as a service to the internet community." Spammers say ``Users are free to delete our messages if they want.'' They nevertheless work around every _automated_ anti-spam mechanism as soon as the mechanism becomes popular---making the mechanism useless. That's exactly what VeriSign is going to do to your ``delegation-only'' mechanism if that mechanism becomes popular. They will, of course, continue saying that users are free to block sitefinder. ---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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 04:32: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 EAA00661 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 04:32:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3tHo-000AJ4-PV for namedroppers-data@psg.com; Mon, 29 Sep 2003 08:21:40 +0000 Received: from [192.150.250.67] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.22) id 1A3tGw-000ADL-N4 for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 08:21:01 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h8T8JLIe015436; Mon, 29 Sep 2003 15:19:22 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8T8INA14050; Mon, 29 Sep 2003 15:18:23 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <20030928225856.1640E1390E@sa.vix.com> References: <20030928225856.1640E1390E@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Sep 2003 15:18:23 +0700 Message-ID: <28317.1064823503@munnari.OZ.AU> X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sun, 28 Sep 2003 22:58:56 +0000 From: Paul Vixie <paul@vix.com> Message-ID: <20030928225856.1640E1390E@sa.vix.com> | i consider that the correct, and sensible, interpretation. Yes, but it is your opinion of what is the correct interpretation. It isn't necessarily the only one. | at a minimum, i think that this draft should only clarify, not "fix" things. | separately, we can rant about whether rfc1034 needs to be "fixed". I agree with that where "fix" means "we don't like this behaviour" or "we really should change this because ...". But not where "fix" is applied to "what is stated is logically inconsistent, we have to choose one or the other". In your reply you completely dropped the issue of the activities at caches, and how (assuming your interpretation of 1034 is correct) we end in a state where caches are giving out different answers, depending upon what queries they happen to have processed earlier. That's an absurd state, that I don't believe can be permitted to exist. I don't much care which correction is made, but here I believe a correction is vital, we simply cannot knowingly publish a document that undermines correct DNS operations (makes them impossible). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 07:22: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 HAA04896 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 07:22:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3w0t-000N32-Pb for namedroppers-data@psg.com; Mon, 29 Sep 2003 11:16:23 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A3w0O-000N16-J3 for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 11:15:52 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 015C84ECE6; Mon, 29 Sep 2003 13:15:51 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 9F2974ECE4 for <namedroppers@ops.ietf.org>; Mon, 29 Sep 2003 13:15:51 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h8TBFpJO010993 for <namedroppers@ops.ietf.org>; Mon, 29 Sep 2003 13:15:51 +0200 Date: Mon, 29 Sep 2003 13:15:51 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: FYI: wcard-clarify editor. Message-Id: <20030929131551.56759ec5.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.298537 X-RIPE-Signature: 151b93680ff19e76264f558f3aa1a574 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI: Since Ed Lewis does not have the time needed to finalize the wild-card draft Robert Elz has kindly volunteered take care of the final edits. Please send nits, minor errors, &c directly to him. Robert will post a version that is the same in content but has slightly different formatting today or tomorrow. Content changes will be based on that and will follow in the cause of the next week, given resolution of the open issues. Thanks Ed for the good work on the initial drafts! -- Olaf DNSEXT co-chair -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 08: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 IAA06435 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 08:15:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3wrZ-00010J-PD for namedroppers-data@psg.com; Mon, 29 Sep 2003 12:10:49 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 1A3wr2-0000yz-Ud for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 12:10:17 +0000 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Message-Id: <200309291154.UAA10399@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA10399; Mon, 29 Sep 2003 20:53:55 +0859 Subject: Re: wcard-clarify's change In-Reply-To: <20030929030534.11D1B1390E@sa.vix.com> from Paul Vixie at "Sep 29, 2003 03:05:34 am" To: Paul Vixie <paul@vix.com> Date: Mon, 29 Sep 2003 20:53:55 +0859 () CC: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul; > > However, it is also written in rfc1034 that: > > > > CNAME RRs cause special action in DNS software. When a name server > > fails to find a desired RR in the resource set associated with the > > domain name, it checks to see if the resource set consists of a CNAME > > record with a matching class. > > > > And it can be said that a domain name matching a wildcard CNAME > > is associated with the CNAME but no other RRs. > > what 1034 calls a "resource set" is a "set of rrsets" by modern terminology, "rrsets"? Wrong. In mathematical terminlogy of set theory, which should be used also in all the RFCs, "resource set" is "set of resourcees" or "set of RRs". You should distinguish a "set of RRs" and a "set of sets of RRs", which are mathematically different. "integer set" is "set of integers", not "set of integer sets". "{1, 2, 3, 4}" is a "set of integers", while "{{1}, {2}, {3, 4}}" is a "set of integer sets". > that is, "all rrsets at a node" or even "all rrs at a node". "node"? Wrong again. In the quoted paragraph, it is not a "node", but a "domain name", though the mistake is not so serious. > by "associated > with a domain name" in the paragraph quoted above, wildcards are uninvolved. Unfounded statement. A natural interpretation of rfc1034 is that a domain name matching a wildcard is associated with a set of RRs of the wildcard. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 08:26: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 IAA06735 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 08:26:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3x0x-0001hK-8x for namedroppers-data@psg.com; Mon, 29 Sep 2003 12:20:31 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 1A3x0R-0001fE-5N for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 12:19:59 +0000 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Message-Id: <200309291204.VAA10455@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA10455; Mon, 29 Sep 2003 21:04:20 +0900 Subject: Re: wcard-clarify's change In-Reply-To: <20030929030035.6FA4A13968@sa.vix.com> from Paul Vixie at "Sep 29, 2003 03:00:35 am" To: Paul Vixie <paul@vix.com> Date: Mon, 29 Sep 2003 21:04:19 +0859 () CC: namedroppers <namedroppers@ops.ietf.org> X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul; > > You can do it better (the web server can know the domain name > > desired) with > > > > > *.gn. ns no-domain-ns0.psg.com. > > > *.gn. ns no-domain-ns1.psg.com. > > > *.lr. ns no-domain-ns0.psg.com. > > > *.lr. ns no-domain-ns1.psg.com. > > > *.ng. ns no-domain-ns0.psg.com. > > > *.ng. ns no-domain-ns1.psg.com. > > not with bind you won't. Haven't you read draft-ietf-dnsext-wcard-clarify-01.txt stating: 6.2 NS RR's at a Wild Card Domain Name Is it not a protocol error to have a NS RR owned by a wild card domian name, complimentary to the case of a SOA RR. However, for this to work, an implementation has to know how to synthesize a zone. ? > perhaps there is software somewhere that > misreads and misimplements 1034 in that way, but this once, bind isn't > it. Hmmm. > it's dimly possible that dname is supposed to work like this, but > not NS. Can we obsolete dname? Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 08:33: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 IAA06968 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 08:33:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3x8d-0002M3-BG for namedroppers-data@psg.com; Mon, 29 Sep 2003 12:28:27 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.22) id 1A3x87-0002K8-Eh for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 12:27:55 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D2BBB4E510; Mon, 29 Sep 2003 14:27:54 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7BD6F4E018 for <namedroppers@ops.ietf.org>; Mon, 29 Sep 2003 14:27:54 +0200 (CEST) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id h8TCRsJO027020 for <namedroppers@ops.ietf.org>; Mon, 29 Sep 2003 14:27:54 +0200 Date: Mon, 29 Sep 2003 14:27:53 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change Message-Id: <20030929142753.5e184828.olaf@ripe.net> In-Reply-To: <20030928150322.9E8301394B@sa.vix.com> References: <20030928150322.9E8301394B@sa.vix.com> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.498034 X-RIPE-Signature: 3f82e79c86cb6a81e0574c064f3c338c X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_10,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Namedroppers, Let's try to remain in scope, blocking sitefinder is not, I think. Allow me to try to focus the discussion. The proposal at hand (paraphrased) is: should the suggested change in wcard-clarify ( * CNAME will be processed as a cname-chain irrespective of QTYPE) be adopted or should we stick to the 1034 behaviour ( once at step 4.2.3.c of the algorithm one should only return a match if QTYPE==CNAME and return a nameerror for QTYPE!=CNAME ). Few open questions I could isolate in the thread. - How do caches deal with the two scenarios. - Is the proposed change good, or harmful for the Internet. (harmful behavior being prohibitive for a change, good being an argument in favor of the change) - How about wildcard DNAMEs? I have not seen a counter argument against Roberts statement that caches and authoritative servers will behave differently when a cache has previously stored the result of a QTYPE=CNAME query. --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 09:37: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 JAA14373 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 09:37:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3y4C-00070F-2o for namedroppers-data@psg.com; Mon, 29 Sep 2003 13:27:56 +0000 Received: from [211.29.163.60] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 4.22) id 1A3y2E-0006uU-Qp for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 13:25:55 +0000 Received: from bsdi.dv.isc.org (localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h8TDOb0o077876; Mon, 29 Sep 2003 23:24:37 +1000 (EST) (envelope-from marka@bsdi.dv.isc.org) Message-Id: <200309291324.h8TDOb0o077876@bsdi.dv.isc.org> To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wcard-clarify's change In-reply-to: Your message of "Mon, 29 Sep 2003 14:27:53 +0200." <20030929142753.5e184828.olaf@ripe.net> Date: Mon, 29 Sep 2003 23:24:37 +1000 X-Spam-Status: No, hits=0.3 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Namedroppers, > > Let's try to remain in scope, blocking sitefinder is not, I think. > Allow me to try to focus the discussion. > > The proposal at hand (paraphrased) is: > > should the suggested change in wcard-clarify ( * CNAME will be > processed as a cname-chain irrespective of QTYPE) be adopted or > should we stick to the 1034 behaviour ( once at step 4.2.3.c of the > algorithm one should only return a match if QTYPE==CNAME and return > a nameerror for QTYPE!=CNAME ). > > Few open questions I could isolate in the thread. > > - How do caches deal with the two scenarios. > > - Is the proposed change good, or harmful for the Internet. (harmful > behavior being prohibitive for a change, good being an argument in > favor of the change) RFC 1034's behaviour is broken. Either change (outlaw or make work) is better than the current. Neither change is harmful to the net. A wildcard CNAME is no worse than a wildcard A. > - How about wildcard DNAMEs? Wildcard DNAMES don't make sence. They only have a impact in a cache. *.example.net DNAME example.com Qname a.b.c.example.net After expansion you have "a.b.c.example.net DNAME example.com" This does not result in DNAME processing occuring as it is not above the qname. If the qtype however is DNAME it will be returned and affect subsequent queries to this cache. A qname of presented to the cache of e.f.a.b.c.example.net will become a.b.c.example.net DNAME example.com e.f.a.b.c.example.net CNAME e.f.example.com At the same time you could also have a different cache returning c.example.net DNAME example.com e.f.a.b.c.example.net CNAME e.f.a.b.example.com and to answer Masataka Ohta I think DNAME should remain. It is useful. > I have not seen a counter argument against Roberts statement that > caches and authoritative servers will behave differently when a cache > has previously stored the result of a QTYPE=CNAME query. Robert's description is correct. > --Olaf > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 09:50: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 JAA14870 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 09:50:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3yLD-0008U3-47 for namedroppers-data@psg.com; Mon, 29 Sep 2003 13:45:31 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 1A3yKe-0008QY-Jx for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 13:44:57 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h8TDirr29578; Mon, 29 Sep 2003 20:44:53 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8TDiYI12855; Mon, 29 Sep 2003 20:44:34 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: "Olaf M. Kolkman" <olaf@ripe.net> cc: namedroppers@ops.ietf.org Subject: Re: FYI: wcard-clarify editor. In-Reply-To: <20030929131551.56759ec5.olaf@ripe.net> References: <20030929131551.56759ec5.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Sep 2003 20:44:34 +0700 Message-ID: <14517.1064843074@munnari.OZ.AU> X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 29 Sep 2003 13:15:51 +0200 From: "Olaf M. Kolkman" <olaf@ripe.net> Message-ID: <20030929131551.56759ec5.olaf@ripe.net> | Robert will post a version that is the same in content but has | slightly different formatting today or tomorrow. I have just submitted draft-ietf-dnsext-wcard-clarify-02.txt "Slightly different formatting" is something of an understatement, this version is generated from *roff, rather than manually laid out. That changes just about everything (in terms of formatting). On the other hand, this version was intended to have absolutely no changes in content. It turned out that to make the formatting both easy and clean, I had to make 2 small changes - and then I made one more, just because ... The first was to move the "send comments to" sentence from the end of the boilerplate to the "Editors addresses" section (in my setup the boilerplate gets added automatically - adding extra stuff there is possible, but isn't easy). And in any case, the IESG once told me that adding anything to the boilerplate isn't allowed (that's nonsense, but never mind). The second was to shorten the title of section 4 - the original was too long for the table of contents (which I guess means I should fix my macros to allow for long section titles, but again, the easy way out). And the third, just for the hell of it, change, was to remove a '.' after "R2.2" in the text, so that one is just the same as all of the others (It was R2.2. text..., the others are all R2.1 text ...). The intent of this version is to provide something that can be diff'd against when the next version with real changes appears. However for this to be reasonable, at least a couple of people are going to need to read the -02 draft, and confirm that there are indeed no other changes hidden in there (I'm not promising that, my editing session was quite fast, and I made lots of internal changes - I may have inadvertently deleted or altered something I wasn't intending to alter). So, when the -02 version appears, please do read it, and compare it with the -01 draft (that you should probably make sure you have a copy of it in advance, as -01 will vanish from the I-D directories when -02 is placed there). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 11:04: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 LAA19853 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 11:04:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3zSr-000Ei1-GE for namedroppers-data@psg.com; Mon, 29 Sep 2003 14:57:29 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A3zRI-000EX7-Qr for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 14:55:53 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19060; Mon, 29 Sep 2003 10:55:43 -0400 (EDT) Message-Id: <200309291455.KAA19060@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-keyrr-key-signing-flag-10.txt Date: Mon, 29 Sep 2003 10:55:43 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : KEY RR Secure Entry Point Flag Author(s) : O. Kolkman, J. Schlyter, E. Lewis Filename : draft-ietf-dnsext-keyrr-key-signing-flag-10.txt Pages : 9 Date : 2003-9-29 With the Delegation Signer (DS) resource record the concept of a key acting as a secure entry point has been introduced. During key-exchanges with the parent there is a need to differentiate secure entry point keys from other keys in the KEY resource record (RR) set. A flag bit in the KEY RR is defined to indicate that KEY is to be used as a secure entry point. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what keys are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-keyrr-key-signing-flag-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-10.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-9-29110528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-keyrr-key-signing-flag-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29110528.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 11:04: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 LAA19873 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 11:04:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A3zSH-000EdI-Ms for namedroppers-data@psg.com; Mon, 29 Sep 2003 14:56:53 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A3zRN-000EXD-Gj for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 14:55:57 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19076; Mon, 29 Sep 2003 10:55:48 -0400 (EDT) Message-Id: <200309291455.KAA19076@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-24.txt Date: Mon, 29 Sep 2003 10:55:48 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-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-24.txt Pages : 22 Date : 2003-9-29 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-24.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-24.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-24.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-9-29110609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29110609.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 13:00: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 NAA28662 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 13:00:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A41AE-0000TC-EM for namedroppers-data@psg.com; Mon, 29 Sep 2003 16:46:22 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.22) id 1A419e-0000Pr-6x for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 16:45:46 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 01A2013948; Mon, 29 Sep 2003 16:45:12 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: "Olaf M. Kolkman" <olaf@ripe.net> Cc: namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: Message from "Olaf M. Kolkman" <olaf@ripe.net> of "Mon, 29 Sep 2003 14:27:53 +0200." <20030929142753.5e184828.olaf@ripe.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 29 Sep 2003 16:45:11 +0000 Message-Id: <20030929164512.01A2013948@sa.vix.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I have not seen a counter argument against Roberts statement that > caches and authoritative servers will behave differently when a cache > has previously stored the result of a QTYPE=CNAME query. i think the clarification that bears on that point is that wildcard-synthesized data should have TTL=0 to prevent caching. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 15:48: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 PAA07130 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 15:48:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A43qH-000GqW-4I for namedroppers-data@psg.com; Mon, 29 Sep 2003 19:37:57 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A43pi-000GoV-HK for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 19:37:22 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06350; Mon, 29 Sep 2003 15:37:13 -0400 (EDT) Message-Id: <200309291937.PAA06350@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-wcard-clarify-02.txt Date: Mon, 29 Sep 2003 15:37:13 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-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 : Clarifying the Role of Wild Card Domains in the Domain Name System Author(s) : B. Halley, E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-02.txt Pages : 18 Date : 2003-9-29 The definition of wild cards is recast from the original in RFC 1034, in words that are more specific and in line with RFC 2119. This document is meant to supplement the definition in RFC 1034 and to alter neither the spirit nor intent of that definition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-02.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-wcard-clarify-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29152719.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29152719.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 17:50: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 RAA13440 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 17:50:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A45ky-0000Jz-CD for namedroppers-data@psg.com; Mon, 29 Sep 2003 21:40:36 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with esmtp (Exim 4.22) id 1A45kS-0000Gl-AM for namedroppers@ops.ietf.org; Mon, 29 Sep 2003 21:40:04 +0000 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Message-Id: <200309292126.GAA12355@necom830.hpcl.titech.ac.jp> Received: from mohta@localhost by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA12355; Tue, 30 Sep 2003 06:26:39 +0900 Subject: Re: wcard-clarify's change In-Reply-To: <20030929164512.01A2013948@sa.vix.com> from Paul Vixie at "Sep 29, 2003 04:45:11 pm" To: Paul Vixie <paul@vix.com> Date: Tue, 30 Sep 2003 06:26:38 +0859 () CC: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_30,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I have not seen a counter argument against Roberts statement that > > caches and authoritative servers will behave differently when a cache > > has previously stored the result of a QTYPE=CNAME query. > > i think the clarification that bears on that point is that > wildcard-synthesized data should have TTL=0 to prevent caching. The only recommended behaviour for wildcarded CNAME is, just like other wildcarded RRs, that raw wildcard data should not be cached to prevent faulty implementations use it for synthesis. Wildcard-synthesized data is just as valid as non-synthesized ones. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Sep 29 22:10: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 WAA21505 for <dnsext-archive@lists.ietf.org>; Mon, 29 Sep 2003 22:10:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A49nZ-000Ji8-1s for namedroppers-data@psg.com; Tue, 30 Sep 2003 01:59:33 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.22) id 1A49mr-000JgC-W6 for namedroppers@ops.ietf.org; Tue, 30 Sep 2003 01:58:50 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h8U1wlr25693; Tue, 30 Sep 2003 08:58:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8U1wdd20566; Tue, 30 Sep 2003 08:58:39 +0700 (ICT) From: Robert Elz <kre@munnari.OZ.AU> To: Paul Vixie <paul@vix.com> cc: "Olaf M. Kolkman" <olaf@ripe.net>, namedroppers@ops.ietf.org Subject: Re: wcard-clarify's change In-Reply-To: <20030929164512.01A2013948@sa.vix.com> References: <20030929164512.01A2013948@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 30 Sep 2003 08:58:39 +0700 Message-ID: <8003.1064887119@munnari.OZ.AU> X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,IN_REP_TO,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 29 Sep 2003 16:45:11 +0000 From: Paul Vixie <paul@vix.com> Message-ID: <20030929164512.01A2013948@sa.vix.com> | i think the clarification that bears on that point is that | wildcard-synthesized data should have TTL=0 to prevent caching. That would certainly not be a clarification, that would be a change, without doubt. Making the algorithm explicitly handle wildcard CNAMES can be seen as a clarification (or what was intended) - forcing TTL=0 certainly cannot. Alternatively, if the common view is that wildcard CNAME shouldn't work, then simply outlawing it could also be seen as a clarification (since the algorithm doesn't work, it must have been intended not to be allowed), forcing TTL=0 certainly cannot... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Sep 30 17:19: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 RAA16361 for <dnsext-archive@lists.ietf.org>; Tue, 30 Sep 2003 17:19:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4RgL-000KDK-ON for namedroppers-data@psg.com; Tue, 30 Sep 2003 21:05:17 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.22) id 1A4Rfp-000K8D-FG for namedroppers@ops.ietf.org; Tue, 30 Sep 2003 21:04:45 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 00AA118DB for <namedroppers@ops.ietf.org>; Tue, 30 Sep 2003 17:04:31 -0400 (EDT) Date: Tue, 30 Sep 2003 17:04:31 -0400 From: Rob Austein <sra+namedroppers@hactrn.net> To: namedroppers <namedroppers@ops.ietf.org> Subject: New DNSSECbis -proto draft MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030930210432.00AA118DB@thrintun.hactrn.net> X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I just posted draft-ietf-dnsext-dnssec-protocol-02.txt to the Internet-Drafts administrator. Apologies for the delay, just a hurricane and a few other distractions, nothing to worry about. This is a snapshot of work in progress. We -think- we've got this doc back into a consistant state after incorporating the typecode changes. There are some other things that we're not done with yet (division of material between sections 3 & 4 isn't right yet, examples still need work, and the discussion of NSEC RRs in responses isn't right yet), but we felt it best to push out a snapshot, then continue with the work we already know we have to do. As always, please send comments either to namedroppers or, in the case of minor editoral junk that's not worth bothering the whole WG, to dnssec-editors@east.isi.edu. Thanks! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Sep 30 23:13: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 XAA26819 for <dnsext-archive@lists.ietf.org>; Tue, 30 Sep 2003 23:13:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4XEi-000Hib-7q for namedroppers-data@psg.com; Wed, 01 Oct 2003 03:01:08 +0000 Received: from randy by psg.com with local (Exim 4.22) id 1A4XDd-000Hcq-AH for namedroppers@ops.ietf.org; Wed, 01 Oct 2003 03:00:01 +0000 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: <E1A4XDd-000Hcq-AH@psg.com> From: Randy Bush <randy@psg.com> Date: Wed, 01 Oct 2003 03:00:01 +0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See <http://www.ietf.org/html.charters/dnsext-charter.html> for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at <http://www.ietf.org/html.charters/dnsop-charter.html>. Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". 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 - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format <NAME> ISSUE: <title> Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>