From owner-namedroppers@ops.ietf.org Sun Jun 1 07:10: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 HAA04544 for ; Sun, 1 Jun 2003 07:10:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MQRL-0003KG-00 for namedroppers-data@psg.com; Sun, 01 Jun 2003 10:51:51 +0000 Received: from [2001:6b0:7::26] (helo=bardisk.pilsnet.sunet.se) by psg.com with esmtp (Exim 3.36 #1) id 19MQRE-0003Js-00; Sun, 01 Jun 2003 10:51:49 +0000 Received: from bardisk.pilsnet.sunet.se (localhost [IPv6:::1]) by bardisk.pilsnet.sunet.se (8.12.8/8.12.8) with ESMTP id h51ApfVf070326; Sun, 1 Jun 2003 12:51:41 +0200 (CEST) (envelope-from mansaxel@bardisk.pilsnet.sunet.se) Received: (from mansaxel@localhost) by bardisk.pilsnet.sunet.se (8.12.8/8.12.3/Submit) id h51ApeeJ070325; Sun, 1 Jun 2003 12:51:40 +0200 (CEST) Date: Sun, 1 Jun 2003 12:51:40 +0200 From: Mans Nilsson To: Randy Bush Cc: namedroppers Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt Message-ID: <20030601105140.GA69931@sunet.se> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-synced-from: Pilsnet X-Spam-Status: No, hits=-35.1 required=5.0 tests=BAYES_20,IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt Date: Thu, May= 29, 2003 at 12:17:16PM -0700 Quoting Randy Bush (randy@psg.com): > this initiates a two week wg last call on >=20 > draft-ietf-dnsext-dnssec-2535typecode-change-01.txt >=20 > and, should it be info or ps? i suspect the latter as it modifies > a ps document, but i could be wrong. Good document. PS.=20 Regards,=20 --=20 M=E5ns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE Are we live or on tape? --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE+2dq802/pMZDM1cURAtmeAJ9rcz28j0/Y/6Jlb8ieFwqUJkj9dACfaAB4 yUd+SDuJQnhUtWIoR/BFJhk= =44ex -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 1 11:49: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 LAA17778 for ; Sun, 1 Jun 2003 11:49:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MUtJ-000CqP-00 for namedroppers-data@psg.com; Sun, 01 Jun 2003 15:37:01 +0000 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 19MUsl-000Cnm-00; Sun, 01 Jun 2003 15:36:27 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h51FaLK4030661; Sun, 1 Jun 2003 17:36:22 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h51FaLKj030658; Sun, 1 Jun 2003 17:36:21 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Sun, 1 Jun 2003 17:36:21 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Randy Bush cc: namedroppers Subject: Re: opt-in document In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-37.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 22 May 2003, Randy Bush wrote: > even though opt-in did not gain consensus in the wg, it would be > good to have a permanent document record. the iesg discussed this > recently in the context of a transport area document, and the idea > is something like the following: > > o publish opt-in as an informational rfc for the historical > record > > o with a clear warning on the front of it that this is recording > a protocol that did NOT gain ietf consensus, it documents an > idea that was considered and not adopted > > o the ADs do have expressed concerns to the chairs about when it > gets published; after DS+2535bis would be best. this doesn't > prevent folk from finishing the document now and it can queue > (in the wg or at the AD) on hold until DS+2535bis finishes. I'd like to see opt-in published as experimental. The clear warning is not necessary, 'experimental' says enough. I'm okay with the timeline. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 1 12:51: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 MAA21326 for ; Sun, 1 Jun 2003 12:51:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MVvU-000FGj-00 for namedroppers-data@psg.com; Sun, 01 Jun 2003 16:43:20 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19MVvR-000FGB-00 for namedroppers@ops.ietf.org; Sun, 01 Jun 2003 16:43:17 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A4C7213968; Sun, 1 Jun 2003 16:43:04 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Roy Arends Cc: Randy Bush , namedroppers Subject: Re: opt-in document In-Reply-To: Message from Roy Arends of "Sun, 01 Jun 2003 17:36:21 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 01 Jun 2003 16:43:04 +0000 Message-Id: <20030601164304.A4C7213968@sa.vix.com> X-Spam-Status: No, hits=-11.0 required=5.0 tests=BAYES_10,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk i prefer that we handle this via ed lewis's "silly state" language. re: > X-Original-To: vixie@vix.com > Date: Sun, 1 Jun 2003 17:36:21 +0200 (CEST) > From: Roy Arends > X-X-Sender: roy@elektron.atoom.net > To: Randy Bush > Cc: namedroppers > Subject: Re: opt-in document > X-Virus-Scanned: by amavisd-new > Sender: owner-namedroppers@ops.ietf.org > > On Thu, 22 May 2003, Randy Bush wrote: > > > even though opt-in did not gain consensus in the wg, it would be > > good to have a permanent document record. the iesg discussed this > > recently in the context of a transport area document, and the idea > > is something like the following: > > > > o publish opt-in as an informational rfc for the historical > > record > > > > o with a clear warning on the front of it that this is recording > > a protocol that did NOT gain ietf consensus, it documents an > > idea that was considered and not adopted > > > > o the ADs do have expressed concerns to the chairs about when it > > gets published; after DS+2535bis would be best. this doesn't > > prevent folk from finishing the document now and it can queue > > (in the wg or at the AD) on hold until DS+2535bis finishes. > > I'd like to see opt-in published as experimental. The clear warning is not > necessary, 'experimental' says enough. I'm okay with the timeline. > > Roy > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 1 13:26: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 NAA23658 for ; Sun, 1 Jun 2003 13:26:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MWUB-000GSf-00 for namedroppers-data@psg.com; Sun, 01 Jun 2003 17:19:11 +0000 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 19MWU8-000GSJ-00; Sun, 01 Jun 2003 17:19:08 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h51HJ3K4032414; Sun, 1 Jun 2003 19:19:03 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h51HJ33I032411; Sun, 1 Jun 2003 19:19:03 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Sun, 1 Jun 2003 19:19:03 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Paul Vixie cc: Randy Bush , namedroppers Subject: Re: opt-in document In-Reply-To: <20030601164304.A4C7213968@sa.vix.com> Message-ID: References: <20030601164304.A4C7213968@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-38.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 1 Jun 2003, Paul Vixie wrote: > i prefer that we handle this via ed lewis's "silly state" language. No problem. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 1 22:49: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 WAA10035 for ; Sun, 1 Jun 2003 22:49:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MfDp-0009qL-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 02:38:53 +0000 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 19MfDl-0009q8-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 02:38:50 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h4T8aIN05711 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 29 May 2003 04:36:19 -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 h4T8aISk007532; Thu, 29 May 2003 04:36:18 -0400 Message-Id: <200305290836.h4T8aISk007532@sandelman.ottawa.on.ca> To: itojun@iijlab.net, ipseckey@sandelman.ca cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-ipseckey-rr-02.txt In-reply-to: Your message of "Thu, 29 May 2003 17:19:29 +0900." <20030529081929.E4BE892@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 29 May 2003 04:36:17 -0400 From: Michael Richardson X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "itojun" == itojun writes: itojun> not sure if it is for ipsec wg, or dnsext wg... Thank you for the comments... the answer is neither, new "IPSECKEY" WG. itojun> of a node, 192.0.2.38 that has published its key only." itojun> (gateway field itojun> being ".") confuses me. what does it mean? It might be used by the responder to verify the identity provided by the initiator, without expressing any desire to be contacted. itojun> what kind of value should i put into "gateway" field if i itojun> want to ask people to do transport mode IPsec? Please see thread from last week: http://www.sandelman.ottawa.on.ca/lists/html/ipseckey/msg00170.html :-) itojun> maybe, draft-ietf-ipseckey-rr-02.txt should refer some other itojun> document itojun> like draft-richardson-ipsec-opportunistic-11.txt for its actual itojun> usage/meaning? That document does not specify IPSECKEY, nor will it. Rather, a future document will explain usage. ] ON HUMILITY: to err is human. To moo, bovine. | 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 GNU/Linux using, kernel hacking, security guy"); [ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 04:05: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 EAA27324 for ; Mon, 2 Jun 2003 04:05:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mk79-000Kzm-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 07:52:19 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 19Mk76-000KzY-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 07:52:17 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h527qFWq017739 for ; Mon, 2 Jun 2003 09:52:15 +0200 Date: Mon, 2 Jun 2003 09:52:15 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt Message-Id: <20030602095215.098027d5.olaf@ripe.net> In-Reply-To: References: 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-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > this initiates a two week wg last call on > > draft-ietf-dnsext-dnssec-2535typecode-change-01.txt > > and, should it be info or ps? i suspect the latter as it modifies > a ps document, but i could be wrong. Let's get rolling baby... Full Support, proposed std. --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 05:03:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28783 for ; Mon, 2 Jun 2003 05:03:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ml7b-000NML-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 08:56:51 +0000 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 19Ml7Z-000NLz-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 08:56:49 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h528uf5Y025365 for ; Mon, 2 Jun 2003 10:56:44 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h528ufhr025362 for ; Mon, 2 Jun 2003 10:56:41 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 2 Jun 2003 10:56:41 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: namedroppers Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-39.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 29 May 2003, Randy Bush wrote: > this initiates a two week wg last call on > > draft-ietf-dnsext-dnssec-2535typecode-change-01.txt > > and, should it be info or ps? i suspect the latter as it modifies > a ps document, but i could be wrong. I do not disagree with the chosen path since I don't want more delays. Though I still think this is radical, and not a "minor" update to the protocol. As for the spec, one minor, very minor suggestion: 4. IANA Considerations This document updates the IANA registry for DNS Resource Record Types by assigning types 46, 47, and 48 to the DNSKEY, RRSIG, and NSEC RRs, respectively. I'd like to see the type 48 as the DNSKEY type. The NSEC type code map consists of octets, and bit48=1 introduces a new octet. If bit 48 corresponds to DNSKEY, and not NSEC, we save an octet during transport when DNSKEY is not present. But this is a _very_ local optimization. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 05:54: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 FAA29994 for ; Mon, 2 Jun 2003 05:54:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mlv5-000PJ7-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 09:47:59 +0000 Received: from vhe-530008.sshn.net ([195.169.222.38] helo=elektron.atoom.net) by psg.com with esmtp (Exim 3.36 #1) id 19Mlv3-000PIv-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 09:47:57 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h529lb5Y026241; Mon, 2 Jun 2003 11:47:43 +0200 Received: from localhost (roy@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h529lW9L026238; Mon, 2 Jun 2003 11:47:37 +0200 X-Authentication-Warning: elektron.atoom.net: roy owned process doing -bs Date: Mon, 2 Jun 2003 11:47:32 +0200 (CEST) From: Roy Arends X-X-Sender: roy@elektron.atoom.net To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: Q-10: Reaction to "Silly" NXT's In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-37.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id FAA29994 On Tue, 27 May 2003, Edward Lewis wrote: > When a verifier sees a 0 in EITHER the NXT OR the SIG positions, the > verifier will take corrective action. This proposal recommends the > following action be specified as a MUST: the verifier will first > validate the NXT according to local policy, with the intent that the > presence of the DS RR at the parent points eventually to a zone key > that verifies the SIG (NXT). Once the NXT is proven valid, the > verifier then treats the remainder of the query as if the DS RR did > not exist - essentially treating the query as traversing through or > being answered from an unsigned zone. Okay: So we have a.example. IN A a.example. IN SIG (A) a.example. IN NXT d.example. A SIG !NXT ; aka silly state a.example. IN SIG (NXT) b.example. IN A d.example. IN A d.example. IN SIG (A) d.example. IN NXT example. A SIG NXT d.example. IN SIG (NXT) One queries for (b.example.,A,IN,dnssec-ok) Response: NOERROR b.example. IN A a.example. IN NXT d.example. A !nxt !sig a.example. IN SIG (NXT). corrective action: verify NXT record by verifying SIG(NXT). NXT record is okay: remainder is unsigned, i.e. b.example. IN A is treated as unsigned. > Discussion. > > There are four options I have considered for a reaction to a silly > state NXT. One is to "fall back" to unsecured DNS, which is what I > have chosen to propose. The rationale is that this permits > enhancements to happen, if they prove to be beneficial. I did not > pick this because it resembles opt-in, as some have noted. Although > it resembles opt-in, it is not opt-in as that has more rules and > considerations to follow. I.e., this proposal does not cover the > rules of generating silly state NXT's - they are forbidden in the > First Rule. Okay, Essentially you propose to have corrective action ('treat as unsecured') in case of silly state (NXT or SIG bit = 0). I support this proposal ! Roy Déjà vu encore une fois -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 11:43: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 LAA12534 for ; Mon, 2 Jun 2003 11:43:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MrIM-000Eae-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 15:32:22 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 19MrIH-000EaG-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 15:32:17 +0000 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h52FWBvO014884; Mon, 2 Jun 2003 11:32:12 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h52FWBoC000019; Mon, 2 Jun 2003 11:32:11 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h52FWAFJ003366; Mon, 2 Jun 2003 11:32:10 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id LAA24016; Mon, 2 Jun 2003 11:32:10 -0400 (EDT) To: Roy Arends Cc: Edward Lewis , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q-10: Reaction to "Silly" NXT's References: Date: 02 Jun 2003 11:32:10 -0400 In-Reply-To: Message-ID: Lines: 86 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-35.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Comments near the end... Roy Arends writes: > Okay: > > So we have > > a.example. IN A > a.example. IN SIG (A) > a.example. IN NXT d.example. A SIG !NXT ; aka silly state > a.example. IN SIG (NXT) > b.example. IN A > d.example. IN A > d.example. IN SIG (A) > d.example. IN NXT example. A SIG NXT > d.example. IN SIG (NXT) > > One queries for (b.example.,A,IN,dnssec-ok) > Response: > > NOERROR > b.example. IN A > a.example. IN NXT d.example. A !nxt !sig > a.example. IN SIG (NXT). > > corrective action: > verify NXT record by verifying SIG(NXT). NXT record is okay: remainder > is unsigned, i.e. b.example. IN A is treated as unsigned. > [snip] > > Essentially you propose to have corrective action ('treat as unsecured') > in case of silly state (NXT or SIG bit = 0). > > I support this proposal ! but wait... Let's take a different situation... Same source, different query. One queries for: a.example..,A,IN,dnssec-ok and gets the following response (from an attacker): NXDOMAIN a.example. IN NXT d.example. A sig !nxt a.example. IN SIG (NXT) The NXT will "verify" correctly (the SIG(NXT) is still valid, and the NXT record was not changed). However, we still have the silly-state, so the answer will still be considered unsigned and so the NXDOMAIN will be considered a valid response (even though the NXT record claims there should be an A record). What about the signed A record? It's now lost and hidden by the attacker. Oops! In other words, someone who decides to experiment with opt-in will completely destroy ALL security in their zone for anyone who uses a silly-state-compliant resolver. I don't think this is a good idea. You have effectively outlawed even experimenting with opt-int on a public network with real data. Perhaps that's your goal? If so, you should be extremely explicit about the ramifications. If it wasn't your goal then you've left a big gaping hole in the security of the protocol (or your text was too vague -- either way ;) Keep in mind that not only do you have to properly handle correct responses, but you need to correctly handle bogus/attacker responses as well. An attacker can EASILY return only partial information in an answer, and any DNSSec add-on MUST handle that properly. Unfortunately the current silly-state proposal does not handle attacks effectively. IMHO, even in a silly-state if the qname of the answer matches the qname of the request then I believe the silly-stateness should be ignored. In particular, if the SIG(NXT) verifies properly then you should ignore any silly-state (i.e. if the qnames match your corrective action should be treat it as a non-silly-state NXT). See my above attack example for my reasoning. > Roy -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 12:18: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 MAA13820 for ; Mon, 2 Jun 2003 12:18:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mrsb-000GeC-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 16:09:49 +0000 Received: from host98-203-65-207.isd.net ([207.65.203.98] helo=goose.ehsco.com) by psg.com with esmtp (Exim 3.36 #1) id 19MrsY-000GdO-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 16:09:46 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0) with ESMTP-TLS id 209024 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 11:09:15 -0500 Message-ID: <3EDB76C5.7060704@ehsco.com> Date: Mon, 02 Jun 2003 11:09:41 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers Subject: [Fwd: I-D ACTION:draft-hall-dns-data-00.txt] Content-Type: multipart/mixed; boundary="------------070907000908060201020209" X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_01,MIME_SUSPECT_NAME,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------070907000908060201020209 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'd like to solicit feedback on this I-D please. Would this be useful as an impersonal ("don't blame me") tool for telling people that their proposed usage of the DNS has problems? What's missing from the list? Is there anything you'd take out? Is this a useless effort? Thanks -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ --------------070907000908060201020209 Content-Type: message/rfc822; name="I-D ACTION:draft-hall-dns-data-00.txt" Content-Disposition: attachment; filename="I-D ACTION:draft-hall-dns-data-00.txt" Return-Path: Received: from asgard.ietf.org ([132.151.6.40] verified) by goose.ehsco.com (CommuniGate Pro SMTP 4.0) with ESMTP id 208996 for lists@ehsco.com; Mon, 02 Jun 2003 07:00:13 -0500 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19MnVV-00011B-Sr for ietf-announce-list@asgard.ietf.org; Mon, 02 Jun 2003 07:29:41 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19MnUo-0000y6-FK for all-ietf@asgard.ietf.org; Mon, 02 Jun 2003 07:28:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01673 for ; Mon, 2 Jun 2003 07:28:57 -0400 (EDT) Message-Id: <200306021128.HAA01673@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hall-dns-data-00.txt Date: Mon, 02 Jun 2003 07:28:57 -0400 Sender: owner-ietf-announce@ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations for DNS Resource Records Author(s) : E. Hall Filename : draft-hall-dns-data-00.txt Pages : 12 Date : 2003-5-30 This document discusses some common issues which should be taken into consideration whenever any new service proposes to extend the Domain Name Service A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hall-dns-data-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hall-dns-data-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hall-dns-data-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-30152058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hall-dns-data-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hall-dns-data-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-30152059.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------070907000908060201020209-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 13:39: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 NAA16332 for ; Mon, 2 Jun 2003 13:39:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mt6j-000KLw-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 17:28:29 +0000 Received: from thing.verisignlabs.com ([65.201.175.62] helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 3.36 #1) id 19Mt6f-000KKp-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 17:28:25 +0000 Received: from verisignlabs.com (piston.dyn.verisignlabs.com [::ffff:68.48.27.14]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by cliffie.verisignlabs.com with esmtp; Mon, 02 Jun 2003 13:28:21 -0400 Date: Mon, 2 Jun 2003 13:28:19 -0400 Subject: Re: Q-10: Reaction to "Silly" NXT's Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: namedroppers@ops.ietf.org To: Derek Atkins From: David Blacka In-Reply-To: Message-Id: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-26.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, June 2, 2003, at 11:32 AM, Derek Atkins wrote: > In other words, someone who decides to experiment with opt-in will > completely destroy ALL security in their zone for anyone who uses a > silly-state-compliant resolver. I don't think this is a good idea. > You have effectively outlawed even experimenting with opt-int on a > public network with real data. Perhaps that's your goal? If so, you > should be extremely explicit about the ramifications. If it wasn't > your goal then you've left a big gaping hole in the security of the > protocol (or your text was too vague -- either way ;) Yes, a zone that uses NXT records with these "silly states" is pretty much making the choice to essentially be insecure for those not aware of the experiment. Resolvers that do this "silly-state" processing are not Opt-In aware, and would be pretty confused with actual Opt-In responses. This proposal actually allows Opt-In to be used by those resolvers that understand it and be safely ignored by those that don't. It is true that a zone can't both be fully secure and in a silly-state flagged experiment at the same time. > Keep in mind that not only do you have to properly handle correct > responses, but you need to correctly handle bogus/attacker responses > as well. An attacker can EASILY return only partial information in an > answer, and any DNSSec add-on MUST handle that properly. > Unfortunately the current silly-state proposal does not handle attacks > effectively. I think that was by design, but I could be wrong. > IMHO, even in a silly-state if the qname of the answer matches the > qname of the request then I believe the silly-stateness should be > ignored. In particular, if the SIG(NXT) verifies properly then you > should ignore any silly-state (i.e. if the qnames match your > corrective action should be treat it as a non-silly-state NXT). See > my above attack example for my reasoning. This might actually be a good idea as well. However, the more behavior like this that we specify for the silly-states, the less freedom future experiments that would use them will have. They already don't have a whole lot, since a NXT must be returned to trigger the silly-state processing. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 16:47: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 QAA23337 for ; Mon, 2 Jun 2003 16:47:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mw2o-0002Z5-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 20:36:38 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19Mw2k-0002Yt-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 20:36:34 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 81327317; Mon, 2 Jun 2003 16:36:31 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 6D8D537B; Mon, 2 Jun 2003 16:36:30 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 341517; Mon, 02 Jun 2003 16:34:28 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 2 Jun 2003 14:36:18 -0600 To: Derek Atkins From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Roy Arends , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-27.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:32 -0400 6/2/03, Derek Atkins wrote: >but wait... Let's take a different situation... Same source, different >query. One queries for: > > a.example.,A,IN,dnssec-ok > >and gets the following response (from an attacker): > > NXDOMAIN > a.example. IN NXT d.example. A sig !nxt > a.example. IN SIG (NXT) > >The NXT will "verify" correctly (the SIG(NXT) is still valid, and the >NXT record was not changed). However, we still have the silly-state, >so the answer will still be considered unsigned and so the NXDOMAIN >will be considered a valid response (even though the NXT record claims >there should be an A record). What about the signed A record? It's >now lost and hidden by the attacker. Oops! If an authoritative name error is returned along with records owned by the name, the resolver ought to conclude that the response is coming from a malformed server. This isn't just a security concern, it's a violation of the basic protocol. The rightful response is to ignore this packet and wait up until the time-out period for a possible correctly-formed answer. The best approach to defend this kind of attack is to employ message based security (TSIG or SIG(0)). BTW, there's no way the NXT will validate. Yes, cryptographically it will be verified. But the NXT states that, besides the name being in existence (contrary to the authoritative name error return code), there is a missing piece of data from the answer and that the entry is using an experimental approach. Don't key on the third possibility until you also consider the first two. >In other words, someone who decides to experiment with opt-in will >completely destroy ALL security in their zone for anyone who uses a >silly-state-compliant resolver. I don't think this is a good idea. >You have effectively outlawed even experimenting with opt-int on a >public network with real data. Perhaps that's your goal? If so, you >should be extremely explicit about the ramifications. If it wasn't >your goal then you've left a big gaping hole in the security of the >protocol (or your text was too vague -- either way ;) The goal is pretty explicit - to crisply define the behavior of the protocol. The proposal makes no allowance for opt-in, in fact there is a MUST on the signer/sender to set the NXT and SIG bits to one. On the other hand, if there is a non-compliant signer/server, the resolver is protected. Some would say that anyone deploying a zone compliant with the opt-in proposal are playing with security fire anyway. Due to a lack of closure on this the opt-in proposal is not on the standards track. To address your "In other words" - look at the situations in which the NXT would be returned. Would you get back an NXT if the answer is signed? >Keep in mind that not only do you have to properly handle correct >responses, but you need to correctly handle bogus/attacker responses >as well. An attacker can EASILY return only partial information in an >answer, and any DNSSec add-on MUST handle that properly. >Unfortunately the current silly-state proposal does not handle attacks >effectively. Cryptographic verification is only part of the validation process. See RFC 2181's discussion on credibility. (Why has cache poisoning become less of a problem well before the deployment of DNSSEC?) >IMHO, even in a silly-state if the qname of the answer matches the >qname of the request then I believe the silly-stateness should be >ignored. In particular, if the SIG(NXT) verifies properly then you >should ignore any silly-state (i.e. if the qnames match your >corrective action should be treat it as a non-silly-state NXT). See >my above attack example for my reasoning. Cryptographic verification is only part of the validation process. Of course, if the silly-stated NXT doesn't make since given the query and the answer, you throw it out, even if it verifies. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 17:23: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 RAA24672 for ; Mon, 2 Jun 2003 17:23:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mwb0-0004Hn-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 21:11:58 +0000 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 19Mwaw-0004HU-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 21:11:54 +0000 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 556D961A1 for ; Mon, 2 Jun 2003 23:11:53 +0200 (CEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id 09E2E1D99 for ; Mon, 2 Jun 2003 23:11:53 +0200 (MEST) Date: Mon, 2 Jun 2003 23:11:53 +0200 (CEST) From: Jakob Schlyter To: namedroppers Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-38.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 29 May 2003, Randy Bush wrote: > this initiates a two week wg last call on > > draft-ietf-dnsext-dnssec-2535typecode-change-01.txt > > and, should it be info or ps? i suspect the latter as it modifies > a ps document, but i could be wrong. I support this document and I think it should be published as proposed standard. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 17:35: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 RAA25062 for ; Mon, 2 Jun 2003 17:35:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mwj1-0004ct-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 21:20:15 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19Mwis-0004cS-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 21:20:06 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h52LJma3025747; Mon, 2 Jun 2003 17:19:48 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h52LJY1m021681; Mon, 2 Jun 2003 17:19:47 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h52LDmU8025808; Mon, 2 Jun 2003 17:13:48 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id RAA24709; Mon, 2 Jun 2003 17:13:48 -0400 (EDT) To: Edward Lewis Cc: Roy Arends , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q-10: Reaction to "Silly" NXT's References: Date: 02 Jun 2003 17:13:48 -0400 In-Reply-To: Message-ID: Lines: 138 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-35.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 11:32 -0400 6/2/03, Derek Atkins wrote: > >but wait... Let's take a different situation... Same source, different > >query. One queries for: > > > > a.example.,A,IN,dnssec-ok > > > >and gets the following response (from an attacker): > > > > NXDOMAIN > > a.example. IN NXT d.example. A sig !nxt > > a.example. IN SIG (NXT) > > > >The NXT will "verify" correctly (the SIG(NXT) is still valid, and the > >NXT record was not changed). However, we still have the silly-state, > >so the answer will still be considered unsigned and so the NXDOMAIN > >will be considered a valid response (even though the NXT record claims > >there should be an A record). What about the signed A record? It's > >now lost and hidden by the attacker. Oops! > > If an authoritative name error is returned along with records owned by > the name, the resolver ought to conclude that the response is coming > from a malformed server. This isn't just a security concern, it's a > violation of the basic protocol. The rightful response is to ignore > this packet and wait up until the time-out period for a possible > correctly-formed answer. The best approach to defend this kind of > attack is to employ message based security (TSIG or SIG(0)). I beg your pardon, but the response: NXDOMAIN a.example. IN NXT d.example a.example. IN SIG (NXT) Is a perfectly valid response. Indeed, go read 2535 section 5.4 for this very example. I certainly hope your resolver doesn't throw this out! The question is really what happens based on the in the NXT record. > BTW, there's no way the NXT will validate. Yes, cryptographically it > will be verified. But the NXT states that, besides the name being in > existence (contrary to the authoritative name error return code), > there is a missing piece of data from the answer and that the entry is > using an experimental approach. Don't key on the third possibility > until you also consider the first two. I don't understand your logic here. Returning a NXT + SIG(NXT) is exactly what you're supposed to do to authenticate an NXDOMAIN. So why do you say that the "there's no way the NXT will validate"? Assuming the cryptographic checks pass, I think validation depends on the QNAME and the of the NXT. If the do not contain the QTYPE then it's a perfectly valid response! If the do contain the QTYPE then again it's possibly a valid NXT that was spoofed by an attacker. Let me provide another example: Query: a.example.,A,IN,dnssec-ok Answer: NXDOMAIN a.example. IN NXT d.example. !nxt sig mx a.example. IN SIG (NXT) What should you do in this case? IMHO, this should be treated as an authoritivie denial of existance for the question, but I'm not convinced your text does that due to the silly-stateness of the response. > >In other words, someone who decides to experiment with opt-in will > >completely destroy ALL security in their zone for anyone who uses a > >silly-state-compliant resolver. I don't think this is a good idea. > >You have effectively outlawed even experimenting with opt-int on a > >public network with real data. Perhaps that's your goal? If so, you > >should be extremely explicit about the ramifications. If it wasn't > >your goal then you've left a big gaping hole in the security of the > >protocol (or your text was too vague -- either way ;) > > The goal is pretty explicit - to crisply define the behavior of the > protocol. The proposal makes no allowance for opt-in, in fact there > is a MUST on the signer/sender to set the NXT and SIG bits to one. On > the other hand, if there is a non-compliant signer/server, the > resolver is protected. Protected in what way? I still maintain that it is NOT protected from a misconfigured/broken signer/sender. See my previous example. > Some would say that anyone deploying a zone compliant with the opt-in > proposal are playing with security fire anyway. Due to a lack of > closure on this the opt-in proposal is not on the standards track. > > To address your "In other words" - look at the situations in which the > NXT would be returned. Would you get back an NXT if the answer is > signed? Yes, you would. See my examples. That's why I think this is problematic. > >Keep in mind that not only do you have to properly handle correct > >responses, but you need to correctly handle bogus/attacker responses > >as well. An attacker can EASILY return only partial information in an > >answer, and any DNSSec add-on MUST handle that properly. > >Unfortunately the current silly-state proposal does not handle attacks > >effectively. > > Cryptographic verification is only part of the validation process. See > RFC 2181's discussion on credibility. (Why has cache poisoning become > less of a problem well before the deployment of DNSSEC?) I agree, it's only part of the validation, but I think you are missing part of the validation and removing other parts. Certainly your text is not clear enough on the validation process. If *I* am getting this confused about what you are proposing, what about someone who isn't as familiar with what's going on going to handle it? > >IMHO, even in a silly-state if the qname of the answer matches the > >qname of the request then I believe the silly-stateness should be > >ignored. In particular, if the SIG(NXT) verifies properly then you > >should ignore any silly-state (i.e. if the qnames match your > >corrective action should be treat it as a non-silly-state NXT). See > >my above attack example for my reasoning. > > Cryptographic verification is only part of the validation process. Of > course, if the silly-stated NXT doesn't make since given the query and > the answer, you throw it out, even if it verifies. But that's my point -- there are NXTs are _DO_ make sense given the query and the answer (see both my examples). You can't just throw them out! -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 17:38: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 RAA25323 for ; Mon, 2 Jun 2003 17:38:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MwpE-0004tK-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 21:26:40 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19MwpC-0004t3-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 21:26:38 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 397CD406; Mon, 2 Jun 2003 17:26:38 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id D3400312; Mon, 2 Jun 2003 17:26:37 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 341656; Mon, 02 Jun 2003 17:24:35 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> References: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> Date: Mon, 2 Jun 2003 15:26:34 -0600 To: David Blacka From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Derek Atkins , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:28 -0400 6/2/03, David Blacka wrote: >Yes, a zone that uses NXT records with these "silly states" is pretty much >making the choice to essentially be insecure for those not aware of the >experiment. I think the "damage" is more localized than Derek describes. If just one opt-in span exists in a zone, then the "security damage" is restricted to just the name holding the silly NXT and all names up to the next signed name. Unless I am misinterpreting something in the opt-in draft. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 18:08: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 SAA26586 for ; Mon, 2 Jun 2003 18:08:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MxBj-0005nB-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 21:49:55 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19MxBg-0005jM-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 21:49:52 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id AA0AF662; Mon, 2 Jun 2003 17:47:58 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id E415F677; Mon, 2 Jun 2003 17:47:57 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 341714; Mon, 02 Jun 2003 17:45:55 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> Date: Mon, 2 Jun 2003 15:47:55 -0600 To: Derek Atkins From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Edward Lewis , David Blacka , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:42 -0400 6/2/03, Derek Atkins wrote: >No, that is correct... However I think most people who are interested >in opt-in would want to use it over the whole zone, not just one name. >And by using a silly-state you've not only confused the issue between >the "signed" nodes, but you've just made yourself even less secure >than with opt-in because you now ignore the security of the "signed" >nodes, too! If I as for www.example.com and example.com has a DS RR, what's in the response from the com. server? When would I see the example.com.'s upper NXT appear in a response? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 18:15: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 SAA27183 for ; Mon, 2 Jun 2003 18:15:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MxID-00060l-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 21:56:37 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19MxI9-0005vF-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 21:56:33 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h52LgFa3002977; Mon, 2 Jun 2003 17:42:15 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h52LgF0c023880; Mon, 2 Jun 2003 17:42:15 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h52LgEFJ019266; Mon, 2 Jun 2003 17:42:14 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id RAA24771; Mon, 2 Jun 2003 17:42:14 -0400 (EDT) To: Edward Lewis Cc: David Blacka , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q-10: Reaction to "Silly" NXT's References: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> Date: 02 Jun 2003 17:42:14 -0400 In-Reply-To: Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-35.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 13:28 -0400 6/2/03, David Blacka wrote: > >Yes, a zone that uses NXT records with these "silly states" is pretty much > >making the choice to essentially be insecure for those not aware of the > >experiment. > > I think the "damage" is more localized than Derek describes. If just > one opt-in span exists in a zone, then the "security damage" is > restricted to just the name holding the silly NXT and all names up to > the next signed name. > > Unless I am misinterpreting something in the opt-in draft. No, that is correct... However I think most people who are interested in opt-in would want to use it over the whole zone, not just one name. And by using a silly-state you've not only confused the issue between the "signed" nodes, but you've just made yourself even less secure than with opt-in because you now ignore the security of the "signed" nodes, too! -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 18:17: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 SAA27319 for ; Mon, 2 Jun 2003 18:17:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MxLQ-00068v-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 21:59:56 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19MxLI-00064Q-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 21:59:48 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h52LpXa3005315; Mon, 2 Jun 2003 17:51:33 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h52LpX0c024677; Mon, 2 Jun 2003 17:51:33 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h52LpWU8003240; Mon, 2 Jun 2003 17:51:32 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id RAA24786; Mon, 2 Jun 2003 17:51:32 -0400 (EDT) To: Edward Lewis Cc: Roy Arends , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q-10: Reaction to "Silly" NXT's References: Date: 02 Jun 2003 17:51:32 -0400 In-Reply-To: Message-ID: Lines: 77 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-37.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sorry, s/NXDOMAIN/NOERROR/ -derek Edward Lewis writes: > At 17:13 -0400 6/2/03, Derek Atkins wrote: > >I beg your pardon, but the response: > > > > NXDOMAIN > > a.example. IN NXT d.example > > a.example. IN SIG (NXT) > > > >Is a perfectly valid response. Indeed, go read 2535 section 5.4 for > >this very example. I certainly hope your resolver doesn't throw this > >out! The question is really what happens based on the in the > >NXT record. > > It's a valid response, but what was the question? > > In your previous mail, you had "a.example., A, IN, dnssec-ok" as the > query string. The response has two contradictions - authoritative > name error and records owned by the name, and an A record listed in > the NXT with no A record in the answer section. > > >I don't understand your logic here. Returning a NXT + SIG(NXT) is > >exactly what you're supposed to do to authenticate an NXDOMAIN. So > >why do you say that the "there's no way the NXT will validate"? > > If I ask for "a.example.com,IN, A, dnssec-ok" and I get back > "a.example.org NXT b.example.org" and the latter is cryptographically > okay, the answer is not valid. (It's not germane to the query.) > > >Let me provide another example: > > > >Query: a.example.,A,IN,dnssec-ok > >Answer: > > NXDOMAIN > > a.example. IN NXT d.example. !nxt sig mx > > a.example. IN SIG (NXT) > > > >What should you do in this case? > > Discard the message as being an improperly constructed response. > > >But that's my point -- there are NXTs are _DO_ make sense given the > >query and the answer (see both my examples). You can't just throw them > >out! > > The NXTs do not make sense. According to the NXDOMAIN, the qname is > being declared as not existing, hence, having no data. Then you show > that it has data. Proof by contradiction? > > Your example My commentary > ================= =================== > Query:a.example.,A,IN,dnssec-ok > Answer: > NXDOMAIN | ....a.example. doesn't exist > a.example. IN NXT d.example. !nxt sig mx| ....a.example. exists with ... > a.example. IN SIG (NXT) > ================= ==================== > > contradiction > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 18:25: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 SAA27638 for ; Mon, 2 Jun 2003 18:25:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MxUZ-0006cc-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 22:09:23 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19MxUR-0006Zs-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 22:09:19 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h52M4pa3008564; Mon, 2 Jun 2003 18:04:51 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h52M4p0c025557; Mon, 2 Jun 2003 18:04:51 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h52M4oU8005226; Mon, 2 Jun 2003 18:04:51 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id SAA24809; Mon, 2 Jun 2003 18:04:50 -0400 (EDT) To: Edward Lewis Cc: David Blacka , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q-10: Reaction to "Silly" NXT's References: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> Date: 02 Jun 2003 18:04:50 -0400 In-Reply-To: Message-ID: Lines: 55 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-35.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 17:42 -0400 6/2/03, Derek Atkins wrote: > >No, that is correct... However I think most people who are interested > >in opt-in would want to use it over the whole zone, not just one name. > >And by using a silly-state you've not only confused the issue between > >the "signed" nodes, but you've just made yourself even less secure > >than with opt-in because you now ignore the security of the "signed" > >nodes, too! > > If I as for www.example.com and example.com has a DS RR, what's in the > response from the com. server? Do you want to know the legitimate response or what you might actually see? Well, the .com zone would probably have the following records: example.com. ns .. example.com. nxt foo.com. ns ds sig example.com. sig (nxt) example.com. ds example.com. sig (ds) A legitimate response would give you: NOERROR example.com. ns .. example.com. ds example.com. sig (ds) > When would I see the example.com.'s upper NXT appear in a response? An attack? An attacker could aquire the nxt/sig(nxt) from some other query and respond with it to your query: NOERROR com. soa ... example.com. nxt foo.com. ... example.com. sig (nxt) TSIG only helps if it's a protection between you and your trusted recursive server, but it doesn't help if the attacker feeds this response to that recursive server. So if you assume a silly-state NXT do you accept this empty answer or do you consider it bogus? IMHO, this should be considered a bogus response and dropped/flagged/logged. However it's unclear what to do in the case of your silly-state text. When does silly-state take precedence and when does it not? -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 18: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 SAA27935 for ; Mon, 2 Jun 2003 18:31:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MxdY-0006zj-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 22:18:40 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19MxdU-0006xH-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 22:18:36 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id BDCBD42A; Mon, 2 Jun 2003 17:43:07 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 473182FD; Mon, 2 Jun 2003 17:43:07 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 341701; Mon, 02 Jun 2003 17:41:05 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 2 Jun 2003 15:43:04 -0600 To: Derek Atkins From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Edward Lewis , Roy Arends , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:13 -0400 6/2/03, Derek Atkins wrote: >I beg your pardon, but the response: > > NXDOMAIN > a.example. IN NXT d.example > a.example. IN SIG (NXT) > >Is a perfectly valid response. Indeed, go read 2535 section 5.4 for >this very example. I certainly hope your resolver doesn't throw this >out! The question is really what happens based on the in the >NXT record. It's a valid response, but what was the question? In your previous mail, you had "a.example., A, IN, dnssec-ok" as the query string. The response has two contradictions - authoritative name error and records owned by the name, and an A record listed in the NXT with no A record in the answer section. >I don't understand your logic here. Returning a NXT + SIG(NXT) is >exactly what you're supposed to do to authenticate an NXDOMAIN. So >why do you say that the "there's no way the NXT will validate"? If I ask for "a.example.com,IN, A, dnssec-ok" and I get back "a.example.org NXT b.example.org" and the latter is cryptographically okay, the answer is not valid. (It's not germane to the query.) >Let me provide another example: > >Query: a.example.,A,IN,dnssec-ok >Answer: > NXDOMAIN > a.example. IN NXT d.example. !nxt sig mx > a.example. IN SIG (NXT) > >What should you do in this case? Discard the message as being an improperly constructed response. >But that's my point -- there are NXTs are _DO_ make sense given the >query and the answer (see both my examples). You can't just throw them >out! The NXTs do not make sense. According to the NXDOMAIN, the qname is being declared as not existing, hence, having no data. Then you show that it has data. Proof by contradiction? Your example My commentary ================= =================== Query:a.example.,A,IN,dnssec-ok Answer: NXDOMAIN | ....a.example. doesn't exist a.example. IN NXT d.example. !nxt sig mx| ....a.example. exists with ... a.example. IN SIG (NXT) ================= ==================== contradiction -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 18:32: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 SAA27995 for ; Mon, 2 Jun 2003 18:32:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mxjq-0007F9-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 22:25:10 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19Mxjo-0007Ev-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 22:25:08 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 6CE33272; Mon, 2 Jun 2003 17:59:59 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 9A1E9210; Mon, 2 Jun 2003 17:59:58 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 341749; Mon, 02 Jun 2003 17:57:56 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 2 Jun 2003 15:59:54 -0600 To: Derek Atkins From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Edward Lewis , Roy Arends , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-16.9 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Okay, then let's see that your points are... What is the query that has generated the following response? At 17:51 -0400 6/2/03, Derek Atkins wrote: NOERROR >> > a.example. IN NXT d.example >> > a.example. IN SIG (NXT) ...and what are the bits? >> >Let me provide another example: >> > >> >Query: a.example.,A,IN,dnssec-ok >> >Answer: NOERROR >> > a.example. IN NXT d.example. !nxt sig mx >> > a.example. IN SIG (NXT) In this case, the resolver will conclude that there is no A record and that the source authority is using a newer-than-the-resolver semantics. E.g., it's the same as seeing no error and an answer count of 0. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 18:36: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 SAA28158 for ; Mon, 2 Jun 2003 18:36:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MxfS-00074h-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 22:20:38 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19MxfP-000710-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 22:20:35 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 1A9B63FA; Mon, 2 Jun 2003 18:19:19 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id A307D3E8; Mon, 2 Jun 2003 18:19:18 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 341804; Mon, 02 Jun 2003 18:17:16 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> Date: Mon, 2 Jun 2003 16:19:11 -0600 To: Derek Atkins From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Edward Lewis , David Blacka , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:04 -0400 6/2/03, Derek Atkins wrote: >> If I as for www.example.com and example.com has a DS RR, what's in the >> response from the com. server? >A legitimate response would give you: > > NOERROR > example.com. ns .. > example.com. ds > example.com. sig (ds) > Modulo breaking this into sections, there is no NXT there to show the "silliness". So I don't see a problem. >> When would I see the example.com.'s upper NXT appear in a response? > >An attack? An attacker could aquire the nxt/sig(nxt) from some other >query and respond with it to your query: > > NOERROR > com. soa ... > example.com. nxt foo.com. ... > example.com. sig (nxt) > >TSIG only helps if it's a protection between you and your trusted >recursive server, but it doesn't help if the attacker feeds this >response to that recursive server. So if you assume a silly-state NXT >do you accept this empty answer or do you consider it bogus? > >IMHO, this should be considered a bogus response and >dropped/flagged/logged. However it's unclear what to do in the case >of your silly-state text. When does silly-state take precedence and >when does it not? If the only time in which I would see the NXT is when the message is part of an attack, then, well, the resolver should react to the message as evidence of an active attack. Processing/evaluation stops, there's no examination of the silly stateness. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 18:39:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28225 for ; Mon, 2 Jun 2003 18:39:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MxmK-0007Lg-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 22:27:44 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19MxmC-0007LE-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 22:27:41 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h52MFda3011254; Mon, 2 Jun 2003 18:15:39 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h52MFd0c026321; Mon, 2 Jun 2003 18:15:39 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h52MFdU8006755; Mon, 2 Jun 2003 18:15:39 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id SAA24835; Mon, 2 Jun 2003 18:15:38 -0400 (EDT) To: Edward Lewis Cc: Roy Arends , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q-10: Reaction to "Silly" NXT's References: Date: 02 Jun 2003 18:15:38 -0400 In-Reply-To: Message-ID: Lines: 48 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-36.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > Okay, then let's see that your points are... > > What is the query that has generated the following response? > > At 17:51 -0400 6/2/03, Derek Atkins wrote: > NOERROR > >> > a.example. IN NXT d.example > >> > a.example. IN SIG (NXT) > > ...and what are the bits? Well, that depends, obviously, and is the heart of my issue. > >> >Let me provide another example: > >> > > >> >Query: a.example.,A,IN,dnssec-ok > >> >Answer: > NOERROR > >> > a.example. IN NXT d.example. !nxt sig mx > >> > a.example. IN SIG (NXT) > > In this case, the resolver will conclude that there is no A record and > that the source authority is using a newer-than-the-resolver > semantics. E.g., it's the same as seeing no error and an answer count > of 0. Ok, then my reading it correct, and this is a major security problem. You have now effectively destroyed all security for a site that plans to experiment with silly-state data. Even signed data is now considered unsigned, and authenticated denial has been wiped out, even for signed nodes. I still maintain that if the QNAME of the query matches the QNAME of the answer then silly-state should be ignored. Either that or the whole response should be ignored. In NO CASE should this response be treated the same as a NOERROR with no answers! That's just bad juju and a clear reduction in security, because you are throwing away data that is 99% (I'll leave room for future silly-state changes ;) telling you that the response is bogus and accepting the response. Bad juju. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 18:40: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 SAA28247 for ; Mon, 2 Jun 2003 18:40:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mxrc-0007j0-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 22:33:12 +0000 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 19MxrK-0007i3-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 22:32:58 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h52MWcYK007708; Mon, 2 Jun 2003 18:32:38 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h52MWc0c027397; Mon, 2 Jun 2003 18:32:38 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h52MWbFJ020556; Mon, 2 Jun 2003 18:32:37 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id SAA24875; Mon, 2 Jun 2003 18:32:37 -0400 (EDT) To: Edward Lewis Cc: David Blacka , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q-10: Reaction to "Silly" NXT's References: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> Date: 02 Jun 2003 18:32:37 -0400 In-Reply-To: Message-ID: Lines: 71 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-36.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ed, Edward Lewis writes: > At 18:04 -0400 6/2/03, Derek Atkins wrote: > >> If I as for www.example.com and example.com has a DS RR, what's in the > >> response from the com. server? > > >A legitimate response would give you: > > > > NOERROR > > example.com. ns .. > > example.com. ds > > example.com. sig (ds) > > > > Modulo breaking this into sections, there is no NXT there to show the > "silliness". So I don't see a problem. Well, sure. The problem I have isn't in the handling of legitimate data, the problem is the handling of error cases. Of course legitimate responses are fine. But if all responses were always legitimate we wouldn't need DNSSec, would we? ;) > >> When would I see the example.com.'s upper NXT appear in a response? > > > >An attack? An attacker could aquire the nxt/sig(nxt) from some other > >query and respond with it to your query: > > > > NOERROR > > com. soa ... > > example.com. nxt foo.com. ... > > example.com. sig (nxt) > > > >TSIG only helps if it's a protection between you and your trusted > >recursive server, but it doesn't help if the attacker feeds this > >response to that recursive server. So if you assume a silly-state NXT > >do you accept this empty answer or do you consider it bogus? > > > >IMHO, this should be considered a bogus response and > >dropped/flagged/logged. However it's unclear what to do in the case > >of your silly-state text. When does silly-state take precedence and > >when does it not? > > If the only time in which I would see the NXT is when the message is > part of an attack, then, well, the resolver should react to the > message as evidence of an active attack. Processing/evaluation stops, > there's no examination of the silly stateness. But this is exactly my point. If you're going to act as if it's an attack, then you need to ignore the silly stateness.. That means that it should ignore the silly-stateness, which is what I've been saying. The problem is that the packet doesn't have the Evil bit set. The resolver doesn't know it's under attack. It just receives an answer that looks like this and has to interpret it. So, what does it do? First it tries to cryptographically verify the NXT/SIG. Assume it verifies (the crypto is ok). Then what? Could you please fill in the rest of the verification process (and include whatever silly-state tests you'd include). Please be explicit with the tests? IMHO, whatever the process is, it MUST determine to drop the packet as bogus. IMHO this "response is bogus" result should happen regardless of the silly-stateness of the NXT. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 19:07: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 TAA29319 for ; Mon, 2 Jun 2003 19:07:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MyGa-00097h-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 22:59:00 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19MyGV-00096r-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 22:58:55 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 0762F3EB; Mon, 2 Jun 2003 18:58:55 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 417573DE; Mon, 2 Jun 2003 18:58:54 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 341905; Mon, 02 Jun 2003 18:56:51 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> Date: Mon, 2 Jun 2003 16:43:34 -0600 To: Derek Atkins From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Edward Lewis , David Blacka , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:32 -0400 6/2/03, Derek Atkins wrote: >But if all responses were always >legitimate we wouldn't need DNSSec, would we? ;) Depends on what you mean my "legitimate." Legitimate with respect to the protocol? Legitimate with respect to the data? Don't confuse protocol correctness with data integrity. DNSSEC only says that the covered RR set was "as is" when the signer spit out the signature. DNSSEC does not say whether the RR set is credible in a given response. DNSSEC does not say whether the RR set is germane to the query issued. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 19:10: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 TAA29396 for ; Mon, 2 Jun 2003 19:10:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19MyGb-00097n-00 for namedroppers-data@psg.com; Mon, 02 Jun 2003 22:59:01 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19MyGX-00097A-00 for namedroppers@ops.ietf.org; Mon, 02 Jun 2003 22:58:57 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id AE674425; Mon, 2 Jun 2003 18:58:56 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id D1CD63F9; Mon, 2 Jun 2003 18:58:55 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 341906; Mon, 02 Jun 2003 18:56:53 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 2 Jun 2003 16:58:50 -0600 To: Derek Atkins From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Edward Lewis , Roy Arends , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:15 -0400 6/2/03, Derek Atkins wrote: >I still maintain that if the QNAME of the query matches the QNAME of >the answer then silly-state should be ignored. In what cases might I see an NXT owned by the QNAME in a response? In the answer section for QTYPE=any. This is a debugging situation. I'm not sure that the output of the verifier is all that important here. In the authority section as in RFC 2308, 2.2. Maybe this needs looking at. What if: www.example.com, A, IN is the Q-trinity. response #1 might be: <> no answer example.com IN NXT example.com SOA SIG NXT NS example.com IN SIG (NXT) response #2 might be: <> no answer example.com IN NXT example.com SOA !SIG !NXT NS example.com IN SIG (NXT) response #3 might be: www.example.com IN A 1111.1111.1111 example.com IN NXT example.com SOA !SIG !NXT NS example.com IN SIG (NXT) Response #1 is a non-issue. Response #2 is a non-issue, as it appears to my unknowing eye that the sender is using funky semantics, but still seems to be saying the data isn't there. But I melt back to the old days - which is an unsigned version of #1 Response #3 is quirky, I would be willing to take the 1111.1111.1111.1111 address based on this, but who knows that the funky semantics are here? Undecidable problem. I'd say that any other permutation (save !SIG NXT or SIG !NXT) is a protocol error in any scenario. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 2 20:35: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 UAA01663 for ; Mon, 2 Jun 2003 20:35:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Mzc9-000ChP-00 for namedroppers-data@psg.com; Tue, 03 Jun 2003 00:25:21 +0000 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 19Mzc1-000Ch6-00 for namedroppers@ops.ietf.org; Tue, 03 Jun 2003 00:25:18 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h530P6h5007950; Mon, 2 Jun 2003 20:25:07 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h530P6Mm002166; Mon, 2 Jun 2003 20:25:06 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h530P6U8019066; Mon, 2 Jun 2003 20:25:06 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3p2) id UAA25073; Mon, 2 Jun 2003 20:25:06 -0400 (EDT) To: Edward Lewis Cc: David Blacka , namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: Q-10: Reaction to "Silly" NXT's References: <9A17EC48-951F-11D7-8B21-000393A3322E@verisignlabs.com> Date: 02 Jun 2003 20:25:05 -0400 In-Reply-To: Message-ID: Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-36.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 18:32 -0400 6/2/03, Derek Atkins wrote: > >But if all responses were always > >legitimate we wouldn't need DNSSec, would we? ;) > > Depends on what you mean my "legitimate." Legitimate with respect to > the protocol? Legitimate with respect to the data? Yes. They are linked and are not separable. Ok, yea, they are separable... But looking at the protocol without looking at the data is like asking whether wires can carry electricity without asking whether it's 110 or 220 volts and 50 or 60 hertz. > Don't confuse protocol correctness with data integrity. From the resolver's end how do you tell the difference? Isn't that what DNSSec was all about? > DNSSEC only says that the covered RR set was "as is" when the signer > spit out the signature. DNSSEC does not say whether the RR set is > credible in a given response. DNSSEC does not say whether the RR set > is germane to the query issued. Sure it does.. The whole 2535 processing system is about how to validate whether a response you got is valid based on the question you asked. Integrity and validity are inextricably linked in the process. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 3 06:38: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 GAA26096 for ; Tue, 3 Jun 2003 06:38:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19N8pc-0007FL-00 for namedroppers-data@psg.com; Tue, 03 Jun 2003 10:15:52 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 19N8pX-0007Dx-00 for namedroppers@ops.ietf.org; Tue, 03 Jun 2003 10:15:47 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h53AETWq031494; Tue, 3 Jun 2003 12:14:29 +0200 Date: Tue, 3 Jun 2003 12:14:29 +0200 From: "Olaf M. Kolkman" To: Derek Atkins Cc: roy@logmess.com, edlewis@arin.net, namedroppers@ops.ietf.org Subject: Re: Q-10: Reaction to "Silly" NXT's Message-Id: <20030603121429.66d441dc.olaf@ripe.net> In-Reply-To: References: 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-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 02 Jun 2003 11:32:10 -0400 Derek Atkins wrote: > IMHO, even in a silly-state if the qname of the answer matches the > qname of the request then I believe the silly-stateness should be > ignored. In particular, if the SIG(NXT) verifies properly then you > should ignore any silly-state (i.e. if the qnames match your > corrective action should be treat it as a non-silly-state NXT). See > my above attack example for my reasoning. This made me puzzle a bit. Let me try to document how I would implement NXT verification in a verifier. I'd follow the following algorithm: 1. You only process NXT RRs if the zone from which the NXT RR is returned is supposed to be secured. This is determined either by the DS (or relevant NXT) from the parent zone or by configuration of the zone as an island of trust. 2. Given that the zone is secure you only process NXT RRs to proof non-existence of names or non-existence of RRtypes. 3. If either a NXDOMAIN or NOERROR empty answer section is received one first verifies the SIG over the NXT RR to check if that has not been tampered with. If it has been tampered with mark the answer as BAD. (Bad luck, either the zone served incorrect data or your answer has been tampered with) The SIG(NXT) is correct so we have to verify if the NXT RR is relevant to the answer. (If the answer is NOERROR and a non-empty answer section we have a direct match and the NXT RR is IMHO irrelevant; all the proof for the data in the answer section is enclosed in the answer) 4a. If the answer was a NXDOMAIN answer then one has to check if the original qname is enclosed in the NXT RR's owner name and the NXT RR's nxt_domain_name. 4b. If the answer was NOERROR no data one verifies that the ownername of the NXT RR is the same as the QNAME and verifies that the QNAME is not in the nxt_bitmap. In both 4a and 4b one does never check if the NXT or the SIG bit are actually set. So if Ed's proposal should state that the "listener" would have to do an additional check before step 4 i.e. Verify if the NXT and/or the SIG bits are set and continue with step 4 if the bits are set and go into silly state if the bits are not set. (MUST language) Independent of going "Ed's check" I also think that the protocol ID should state that one should (or maybe even must): - when verifying the NXDOMAIN response not use the NXT bitmap. - when verifying the NOERROR emtpy answer one should only perform the qname==ownername check and one should ignore the nxt_domain_name ignored. To rehash: in my interpretation of the specs the NXT and SIG bits are not looked at at all; one MUST only look at what is relevant to the answer given. Ed's proposal introduces an additional check before actually using the content of the SIG RR to validate answers. --Olaf PS ad 4a:I am aware I ignore the multiple NXTs needed for proving no-wildcard-matches but that does not change the argument that for proving an NXDOMAIN one does not use the bitmap. PPS: Somewhat relevant, because an assumption about validator behaviour was made doing this. Last night I was toying with a server that dynamically synthesizes signed responses for variable QNAMES and QTYPE=TXT. While for every QNAME and QTYPE=TXT the server will magically cooks up an answer there will always be a NOERROR empty answer section if the qtype is not TXT. The NOERROR-empty answer NXT RRs are automatically generated and signed. The problem with that is that there is no structured zone file. So what I did is just use the zones origin for the nxt_domain_name. So for all queries for wich qname is in the zone and for which the qtype does not equal TXT the following NXT is synthesized: QNAME=qname QTYPE=A QCLASS=IN +dnssec qname 10 IN NXT $ORIGIN NXT SIG TXT qname 10 IN SIG NXT ....generated sig .... This should not break validators because I assume, based on the step 4b, that for validation of a NOERROR-empty answer response the nxt_domain_name is irrelevant. Since caches are supposed to cache on the QNAME,QCLASS,QTYPE tripled there should not be any problem putting bogus name intervals in the NXT RRs that proof non-existence of QTYPE for caches either... For an example dig .rp.secret-wg.org TXT +dnssec eg dig 1.1.+.1,3./.rp.secret-wg.org TXT +dnssec (yeah yeah.. this is a sick waste of time) --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 3 09:24: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 JAA03724 for ; Tue, 3 Jun 2003 09:24:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NBfM-000CBw-00 for namedroppers-data@psg.com; Tue, 03 Jun 2003 13:17:28 +0000 Received: from ratree.psu.ac.th ([202.12.73.3]) by psg.com with esmtp (Exim 3.36 #1) id 19NBfK-000CBi-00 for namedroppers@ops.ietf.org; Tue, 03 Jun 2003 13:17:26 +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 h53DH6P06677; Tue, 3 Jun 2003 20:17:08 +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 h53DB7429548; Tue, 3 Jun 2003 20:11:08 +0700 (ICT) From: Robert Elz To: namedroppers@ops.ietf.org cc: rfc@danisch.de Subject: draft-danisch-dns-rr-smtp-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jun 2003 20:11:07 +0700 Message-ID: <220.1054645867@munnari.OZ.AU> X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNS people may want to take a look at draft-danisch-dns-rr-smtp-02.txt and make some comments. In particular... +---+---+---+---+---+---+---+---+ | N | Entry Type Code (4) | +---+---+---+---+---+---+---+---+ | Encoded and Compressed DNS | / Name as described in RFC1035 / +---+---+---+---+---+---+---+---+ is going to be worthy of some comment I suspect (and from a quick glance, probably more). I gave up on careful reading at ... The suggested method is to let the DNS server for the sender domain provide informations about which IP addresses are authorized to use the domain within a sender's address. which I cannot find any possible way to implement. That is, I have no idea at all how I'd specify which IP addresses are authorised to send e-mail claiming to be from munnari.oz.au - as that set is more or less, the IP address where I happen to be this week, and can be anything. What's more, usually, wherever I am, I use whatever is the local mail relay (check this message, you don't find it coming from anywhere near munnari.oz.au - but it is also not forged, I promise...). If there is none, I will send directly from my laptop, but using the local relay allows for it to queue and retry sending mail, while not requiring my laptop to remain active. I simply will not, ever, relay all my mail back to Australia to be sent back (quite often, to wherever I happen to be). That's the only way I can imagine making the scheme in this doc work. What's more, to assist in reducing, as the claim is that this will do, everyone has to do it - it is no good just some small fraction of sites saying "I know where email from my domain name must come from" even allowing for the small chance that they're correct in that assessment. If there aren't enough people implementing this, no-one is going to waste time attempting to verify it. If verification is attempted, it is useful only if mail is permitted only on success - which means everyone has to install RMX records and keep them up to date somehow. Forget 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: From owner-namedroppers@ops.ietf.org Tue Jun 3 11:04: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 LAA08306 for ; Tue, 3 Jun 2003 11:04:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ND4M-0000W7-00 for namedroppers-data@psg.com; Tue, 03 Jun 2003 14:47:22 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19ND4G-0000V3-01 for namedroppers@ops.ietf.org; Tue, 03 Jun 2003 14:47:17 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19NCkW-000JhJ-Ko for namedroppers@ops.ietf.org; Tue, 03 Jun 2003 07:26:52 -0700 Message-ID: <20030603134438.GB7861@danisch.de> References: <220.1054645867@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <220.1054645867@munnari.OZ.AU> From: Hadmut Danisch Date: Tue, 3 Jun 2003 15:44:38 +0200 To: Robert Elz Cc: namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] G'Day, On Tue, Jun 03, 2003 at 08:11:07PM +0700, Robert Elz wrote: > and make some comments. In particular... ... > is going to be worthy of some comment I suspect (and from a quick > glance, probably more). Maybe you could elaborate this a little bit and tell me what exactly you're talking about, because I'm not a fortune teller. > I gave up on careful reading at ... > > The suggested method is to let the DNS server for the sender domain > provide informations about which IP addresses are authorized to use > the domain within a sender's address. > > which I cannot find any possible way to implement. That is, I have no idea > at all how I'd specify which IP addresses are authorised to send e-mail > claiming to be from munnari.oz.au - as that set is more or less, the > IP address where I happen to be this week, and can be anything. Maybe you should have read the whole draft carefully. Or maybe you should have read something in the ASRG IRTF group. The problem that is to be solved is the arbitrary forging of mails. Currently, it is possible to send mail with any sender domain from any IP address. That's a complete lack of security. That's the way spam works. And by the way, you are not required to have an RMX record at all. Or you can give a 0.0.0.0/0 permission, thus allowing any IP address on the planet. But since people urgently need to stop spam, they might reject mails from domains who authorize just anyone to abuse it. To give you a solution to your problem: - Use a dyndns entry - Write a entry of the type host:your.dyndns.domain in your RMX and your problem is solved. > What's more, usually, wherever I am, I use whatever is the local mail > relay (check this message, you don't find it coming from anywhere near > munnari.oz.au - but it is also not forged, I promise...). That's exactly the problem. You "promise" it is not forged, but there is no technical way to determine it, because there is no technical difference. From the technical point of view, this mail is indistinguishable from forged e-mail, even if you promise. And that's the problem RMX is going to solve the easiest and cheapest way. Just answer a question: How do you *receive* e-mail when you're on the road? > I simply will not, ever, relay all my mail back to Australia to be sent > back (quite often, to wherever I happen to be). That's the only way I > can imagine making the scheme in this doc work. - You're doing this for incoming e-mail: munnari.oz.au MX 60 mail-gate.cs.mu.oz.au munnari.oz.au MX 10 munnari.oz.au munnari.oz.au MX 30 mulga.cs.mu.oz.au So why is it a problem for outgoing e-mail? - Get a second relay on the continent of your choice. - Use a DynDNS entry - Use a wide RMX entry - Don't use an RMX entry at all. There are plenty of ways to handle it. > What's more, to assist in reducing, as the claim is that this will do, > everyone has to do it - it is no good just some small fraction of sites > saying "I know where email from my domain name must come from" even allowing > for the small chance that they're correct in that assessment. > > If there aren't enough people implementing this, no-one is going to > waste time attempting to verify it. If verification is attempted, > it is useful only if mail is permitted only on success - which means > everyone has to install RMX records and keep them up to date somehow. Wrong. Hotmail, AOL, Yahoo, T-Online,etc. are in severe trouble due to the extreme amount of spam abusing their sender domains. Once these big providers start to have RMX records, Spammers will move to abuse other domains without RMX records. Domain owners will receive complaints. I received tons of complaints because some spammer abused danisch.de for about half a year, and that's why I developed RMX. So every domain owner who's domain is abused will be happy to volunteer to use RMX. Wait until some spammer chooses your domain for abuse, you will be quite happy to have RMX. So all it takes is the big providers Hotmail, AOL and Yahoo to initiate the avalanche. regards Hadmut -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 3 15:33: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 PAA21573 for ; Tue, 3 Jun 2003 15:33:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NHMg-000AvW-00 for namedroppers-data@psg.com; Tue, 03 Jun 2003 19:22:34 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19NHMa-000Arg-00 for namedroppers@ops.ietf.org; Tue, 03 Jun 2003 19:22:29 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21233; Tue, 3 Jun 2003 15:20:48 -0400 (EDT) Message-Id: <200306031920.PAA21233@ietf.org> To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: The IESG SUBJECT: Last Call: DNS Extensions to support IP version 6 to Draft Standard Reply-to: iesg@ietf.org Date: Tue, 03 Jun 2003 15:20:48 -0400 X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_01,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IESG has received a request from the DNS Extensions Working Group to consider DNS Extensions to support IP version 6 as a Draft Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-6-17. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-03.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 3 18:47: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 SAA28670 for ; Tue, 3 Jun 2003 18:47:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NKPD-000HvD-00 for namedroppers-data@psg.com; Tue, 03 Jun 2003 22:37:23 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 3.36 #1) id 19NKP8-000HtP-00 for namedroppers@ops.ietf.org; Tue, 03 Jun 2003 22:37:18 +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 h53MZYh1001915; Tue, 3 Jun 2003 15:35:34 -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 h53MZYBK010600; Tue, 3 Jun 2003 15:35:34 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h53MZXu9010597; Tue, 3 Jun 2003 15:35:33 -0700 (PDT) Date: Tue, 3 Jun 2003 15:35:33 -0700 (PDT) Message-Id: <200306032235.h53MZXu9010597@guava.araneus.fi> To: rfc@danisch.de Cc: namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <220.1054645867@munnari.OZ.AU> References: <220.1054645867@munnari.OZ.AU> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-33.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On namedroppers, Robert Elz wrote: > DNS people may want to take a look at > > draft-danisch-dns-rr-smtp-02.txt > > and make some comments. Here's a couple of quick comments: This looks similar to the Jim Miller / Paul Vixie "Repudiating MAIL FROM" proposal, only using a new RR type instead of overloading MX; see for example Section 5.5.3 specifies that the domain name in a type "host" entry is compressed. It should specify that it is not compressed; see draft-ietf-dnsext-unknown-rrs-05 for the reasons why. The meaning of the exclamation mark that occurs in some of the zone file syntax examples needs to be defined in the text. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 3 20:31:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01272 for ; Tue, 3 Jun 2003 20:31:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NLz7-000LWc-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 00:18:33 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 19NLz5-000LU1-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 00:18:31 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h540Hfuv020364; Tue, 3 Jun 2003 17:17:41 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jun 2003 17:17:41 -0700 Message-ID: From: "Hallam-Baker, Phillip" To: "'Robert Elz'" , namedroppers@ops.ietf.org Cc: rfc@danisch.de Subject: RE: draft-danisch-dns-rr-smtp-02.txt Date: Tue, 3 Jun 2003 17:17:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > is going to be worthy of some comment I suspect (and from a quick > glance, probably more). OK this group has decided no more compressed addresses, I think you could be a little more constructive and point it out. This is a serious proposal receiving serious attention. It is in the interests of everyone to make sure it works as well as it can. The use of RMX type concepts was mentioned by Microsoft at the FTC workshop as an avenue they are working on with Yahoo and AOL. With the ASRG having collapsed and over half the members left it would be a very good thing if members of this group took a look. I hope that here we can at least have a discussion on the issue without having people called liars, described as 'snakes' etc and every constructive proposal pulled apart by people whose real interest is killing competition to their own schemes. > I gave up on careful reading at ... > > The suggested method is to let the DNS server for the sender domain > provide informations about which IP addresses are authorized to use > the domain within a sender's address. > > which I cannot find any possible way to implement. That is, > I have no idea > at all how I'd specify which IP addresses are authorised to > send e-mail > claiming to be from munnari.oz.au - as that set is more or less, the > IP address where I happen to be this week, and can be anything. That is not an issue, the only clients that need to use this protocol are spam filters and they are not going to simply reject email for not having an RMX. What will happen is that the spam filter will change the estimate of spam probability in response to the presence of valid RMX, the presence of invalid RMX and abscence of RMX. So if an email purports to be from hotmail.com we might have the following probabilities: A) Comes from RMX IP address 5% probability spam B) Does not come from RMX IP address 95% probability spam C) RMX not available 50% probability spam In case A the probability is probably low enough to simply whitelist (note this is assuming that the spam filtering is stateful in the extreeme and the probability for bozo.com with RMX might be 50%, exactly the same for no RMX). Case B is not quite high enough to reject (5% false positive rate is unacceptable). But the threshold for rejection on content inspection would be much lower, we only need to be about 90% sure it is spam to reject at an acceptably low false positive rate, for case C we would have to be 99.5% sure it is not spam to reject with the same level of accuracy. We are not looking for perfect accuracy here, systems with one false positive per 100 messages are usually acceptable. Some people are claiming 1 in a million false positive rates but I have not seen that substantiated. > What's more, usually, wherever I am, I use whatever is the local mail > relay (check this message, you don't find it coming from anywhere near > munnari.oz.au - but it is also not forged, I promise...). OK, you are going to end up having problems sending your email reliably in future as spam filters become steadily more aggressive. RMX is only one authentication option. You could use SSL or S/MIME to authenticate your email and your IP address of the week scheme will work. The problem of forged sender addresses tends to be concentrated at the large providers though. The spammy #$&#$(*&s choose addresses like hotmail or aol because they are familiar to people and more likely to get replies. So a scheme that only works for large ISPs but has very low deployment cost can help reduce the problem. [They are also hijacking the email addresses of people who are active trying to stop spam, I got 15 bounces today from emails I never sent...] > What's more, to assist in reducing, as the claim is that this will do, > everyone has to do it - it is no good just some small > fraction of sites Actually it does have an effect even if only 3 ISPs deploy if they are the right ones. A huge proportion of the spam received at AOL purports to come from hotmail and vice versa. The issue that I am somewhat more concerned about is what might happen if the spam senders start to react to RMX by trying to hijack used IP address blocks. So far they have tended to hijack unused ones but RMX would create an incentive to either hijack real IP addresses or attack the DNS system. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 01:40: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 BAA07714 for ; Wed, 4 Jun 2003 01:40:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NQrV-0006oM-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 05:31:01 +0000 Received: from host98-203-65-207.isd.net ([207.65.203.98] helo=goose.ehsco.com) by psg.com with esmtp (Exim 3.36 #1) id 19NQrT-0006o6-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 05:30:59 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 210046; Wed, 04 Jun 2003 00:30:28 -0500 Message-ID: <3EDD840F.4080504@ehsco.com> Date: Wed, 04 Jun 2003 00:30:55 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 To: rfc@danisch.de CC: namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt References: <220.1054645867@munnari.OZ.AU> In-Reply-To: <220.1054645867@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.1 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've looked at the draft. It's the most-complete of the variants. The discussion text is appropriate for a general draft but most of it should probably be chopped from the final. | This memo suggests a new DNS RR type to provide a very simple | light-weight authentication scheme for the domain part of the It's an authorization scheme, not authentication | simple and robust protection against e-mail fraud and especially | spam. It offers protection against unauthorized use of a mail domain. I'd strongly suggest dropping any reference to spam, except as an example of the kind of mail that often uses unauthorized mail domains. Although it's certain to have some impact on spam, it's going to be very easy for spammers to get around the filter, so its a dead-end for that specific objective. However, it will always work as an anti-forgery device if the sender and receiver both use it. | For any domain name there should not exist more than a single RMX | entry. I'd suggest using one entry per RR. You should also change the zone-file shorthand to numbers instead of strings. It will be simpler to map a decimal value in a zone file to a numeric value in the message. | 5.3. Hostname (Type 3) As was already pointed out, you can't use compression with new RRs. I'd add another entry as an alternate to the "host" type, which would be a plain "domain name" type. Essentially, a receiver would need to issue a pair of reverse and forward lookups, and if the host had a domain name in the specified domain, then it would be allowed. Some folks are in highly distributed environments, and this would keep them from having to add multiple hosts or netblocks to cover their entire domain. Note that issuing a reverse PTR lookup followed by a forward A lookup would be necessary to prevent forgeries, since it's really easy to spoof PTR resource records. | 6. Message Headers My guess is if you're going to specify headers, you need to specify that any such headers in messages received from external sources are to be ignored or removed. That's really something for the SMTP folks to deal with, but my guess is you'll get some pushback. I'd trim most of the text from section 10 down. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 09:02: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 JAA17054 for ; Wed, 4 Jun 2003 09:02:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NXcS-0005lX-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 12:43:56 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19NXcQ-0005lL-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 12:43:54 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h54ChJbd011567; Wed, 4 Jun 2003 08:43:19 -0400 (EDT) Message-ID: <005801c32a96$e136c5b0$b9370681@barnacle> From: "Scott Rose" To: Cc: References: <220.1054645867@munnari.OZ.AU> Subject: Re: draft-danisch-dns-rr-smtp-02.txt Date: Wed, 4 Jun 2003 08:43:20 -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=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I generally agree with the previous comments on this draft. In addition, I have one smaller nit that caught my eye: 5.3.4. Additional Records In order to avoid the need of a second query to resolve the given host name, a DNS server should enclose the A record for that domain name in the additional section of the additional section of the DNS reply, if the server happens to be authoritative. I think the "a DNS server should enclose..." should be replace with a "SHOULD" or (better in my opinion) "MAY". If an A/AAAA RRset is to be placed in the additional section, this needs to be clearly defined, as it is now talking about how responses are generated and what a resolver could expect. Personally, I favor "MAY". This type of rule would require a code change (not major), but also might be mis-interrpreted by older caching servers somewhere in the resolution proces. It is no major feat for a resolver to do another query to get the A RR pointed to by this response. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 09:54:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19628 for ; Wed, 4 Jun 2003 09:54:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NYbZ-000Agk-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 13:47:05 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19NYbX-000AgW-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 13:47:03 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19NYbW-000KRZ-AH for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 06:47:02 -0700 Message-ID: <20030603230742.GA17800@danisch.de> References: <220.1054645867@munnari.OZ.AU> <200306032235.h53MZXu9010597@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306032235.h53MZXu9010597@guava.araneus.fi> From: Hadmut Danisch Date: Wed, 4 Jun 2003 01:07:42 +0200 To: Andreas Gustafsson Cc: namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Tue, Jun 03, 2003 at 03:35:33PM -0700, Andreas Gustafsson wrote: > > Section 5.5.3 specifies that the domain name in a type "host" entry is > compressed. It should specify that it is not compressed; see > draft-ietf-dnsext-unknown-rrs-05 for the reasons why. Good hint, thanks. Since RMX records tend to get rather large, choosing compression is not just a matter of taste. Following your draft and its argumentation, there will never ever be a new RR type with compression. This compression scheme smells broken. Astonishingly, my tests in my local network did not reveal that problem, although an older bind9 was involved. I'll think about that problem. Unfortunately, there is no usable documentation of bind9 and ISC does not provide support. I did not figure out how to store a DNS name correctly without compression. Maybe it will end up in storing simply a string or in using a different compression scheme. > The meaning of the exclamation mark that occurs in some of the zone > file syntax examples needs to be defined in the text. Another good hint, thanks. The exlamation mark has the same meaning as in APL records, it is the symbol for the negation flag. regards Hadmut -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 11:55: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 LAA28341 for ; Wed, 4 Jun 2003 11:55:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NaOm-000LEj-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 15:42:00 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19NaOi-000LDy-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 15:41:56 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 680693FB; Wed, 4 Jun 2003 11:41:55 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 948A03E1; Wed, 4 Jun 2003 11:41:54 -0400 (EDT) Received: from [127.0.0.1] (HELO [204.152.189.21]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 362114; Wed, 04 Jun 2003 11:39:43 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <20030603121429.66d441dc.olaf@ripe.net> References: <20030603121429.66d441dc.olaf@ripe.net> Date: Tue, 3 Jun 2003 22:12:31 -0700 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Derek Atkins , roy@logmess.com, edlewis@arin.net, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-32.2 required=5.0 tests=BAYES_10,DATE_IN_PAST_06_12,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk First I'll assume the context of this is that the NXT is in the authority section and appears in one of the messages as described in RFC 2308, including the referral. At 12:14 +0200 6/3/03, Olaf M. Kolkman wrote: >1. You only process NXT RRs if the zone from which the NXT RR is > returned is supposed to be secured. This is determined either by the > DS (or relevant NXT) from the parent zone or by configuration of the > zone as an island of trust. The right way to do this step is to take the NXT and it's SIG and try to build a chain of trust back to a configured key. It's not important to establish the configuration of the zone when you are starting from an NXT and SIG (NXT) - and can positively verify them. On the other hand, making a determination that a NXT and/or SIG is needed if they are absent from a response. In this case, determining that a zone is signed, ergo, expect NXT and SIG is done. If you do have an NXT and SIG but are unable to establish a chain of trust, you need to determine if the zone is supposed to be signed. It could be that they are stuffed, are replayed, or are just from a cranky old cache with a too-high TTL for the data. Depending on what the reason is (which cannot be decided from the in-band information), you response may vary. But, we have a decidability issue here, so we're stuck. > >2. Given that the zone is secure you only process NXT RRs to proof > non-existence of names or non-existence of RRtypes. I disagree with this...as before. If I can validate the NXT, the zone must be secured. If I can't I need to either get the NXT (absent but expected) or I discard the NXT (present but unexpected). >3. If either a NXDOMAIN or NOERROR empty answer section is received one > first verifies the SIG over the NXT RR to check if that has not been > tampered with. If it has been tampered with mark the answer as > BAD. (Bad luck, either the zone served incorrect data or your answer > has been tampered with) > > The SIG(NXT) is correct so we have to verify if the NXT RR is relevant > to the answer. > > (If the answer is NOERROR and a non-empty answer section we have a > direct match and the NXT RR is IMHO irrelevant; all the proof > for the data in the answer section is enclosed in the answer) This is the step where I realized that there's something missing from the discussion. Once you have cryptographically determined that the NXT is valid (let's assume this is the processing path), then you need to understand the context to see if it is relevant. In a referral message, with a negative indication for the DS, you need to see that the NXT claims that there is no DS but there is a SIG and NXT for the name, as well as NS's. If that's not the case, the NXT is inappropriate - or falls under the silly state proposal. If you are worried that a delegation from a secured zone using an experimental version of NXT to another secured zone will now mean that no secure delegation will work, consider that in such a referral, you do not see the NXT, just the DS. If the answer is an NXDOMAIN, then the NXT is only appropriate if the QNAME is between the owner name and the RDATA's next name. If the answer has NOERROR and an empty answer section, then the QNAME has to equal the ONAME and the QTYPE flag must be absent from the RDATA. If the answer has NOERROR but has 1 or more CNAMEs in the answer, the QNAME has to own a CNAME whose RDATA name (owns another CNAME whose RDATA name) is the same as the NXT. (Can a CNAME chain end in an NXDOMAIN?) If the answer has NOERROR and has data in the answer that is revealed to be a wild card synthesized answer, then the owner of the NXT has to be the closest encloser. So - the context of the NXT determines if it is appropriate. The determination of appropriateness is orthogonal to cryptographic verification. >4a. If the answer was a NXDOMAIN answer then one has to check if the > original qname is enclosed in the NXT RR's owner name and the NXT > RR's nxt_domain_name. > >4b. If the answer was NOERROR no data one verifies that the ownername > of the NXT RR is the same as the QNAME and verifies that the QNAME > is not in the nxt_bitmap. Yeah, but there are a lot more cases (c,d,e,...) as I mention above. (I don't guarantee completeness of my list.) >In both 4a and 4b one does never check if the NXT or the SIG bit are >actually set. So if Ed's proposal should state that the "listener" >would have to do an additional check before step 4 i.e. Verify if the >NXT and/or the SIG bits are set and continue with step 4 if the bits >are set and go into silly state if the bits are not set. (MUST >language) Maybe - you need to make the check go hand-in-hand. Yes, the experimental semantics that make the NXT appear to be in a silly state might redefine appropriateness, but to the simple resolver, it only follows the traditional rules of appropriateness. >Independent of going "Ed's check" I also think that the protocol ID >should state that one should (or maybe even must): > > - when verifying the NXDOMAIN response not use the NXT bitmap. > > - when verifying the NOERROR emtpy answer one should only perform the > qname==ownername check and one should ignore the nxt_domain_name > ignored. Well, you need to also handle the CNAME and wild card "redirects". >To rehash: in my interpretation of the specs the NXT and SIG bits are >not looked at at all; one MUST only look at what is relevant to the >answer given. Ed's proposal introduces an additional check before actually >using the content of the SIG RR to validate answers. > Last night I was toying with a server that dynamically synthesizes "I" == Bert? ;) > This should not break validators because I assume, based on the step > 4b, that for validation of a NOERROR-empty answer response the > nxt_domain_name is irrelevant. Since caches are supposed to cache on > the QNAME,QCLASS,QTYPE tripled there should not be any problem > putting bogus name intervals in the NXT RRs that proof non-existence > of QTYPE for caches either... 'Zackly. > (yeah yeah.. this is a sick waste of time) I expect to see a link and man page on Bert's site in short order. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 16:21: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 QAA11024 for ; Wed, 4 Jun 2003 16:21:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NeXX-000JmM-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 20:07:19 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19NeXT-000Jli-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 20:07:15 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA00493; Wed, 4 Jun 2003 16:02:54 -0400 Date: Wed, 4 Jun 2003 16:04:06 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Robert Elz cc: namedroppers@ops.ietf.org, Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <220.1054645867@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-13.4 required=5.0 tests=BAYES_01,IN_REP_TO,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk General comments ================ Senders of email from a domain are not, in general, attached to an IP address. They may use any IP address from any service provider they please. For example, I have customers which have leased lines from Av8 Internet, but have their email outsourced to Earthlink. Earthlink does not provide them with relay services. So Av8 provides them with relays services. The result is that their email, from their domain (otherwise hosted at Earthlink) comes from our servers. Earthlink also allow them to use @earthlink.net. So email from those addresses may also originate from our server. Limitations on the IP addresses that may be used by users, and thus on the industry of Email Outsourcing, and for private use, tend to subdivide the internet, and seem to violate the ISOC Code of Conduct sections 4 and 14. Dr. Claude Shannon, one of the founders of the science of Information Theory, proved that it is impossible to prove the non-existance of a covert channel. In terms of spam, this means that it is impossible to construct a protocol that cannot be abused, since one cannot prove that it is impossible (the channel can't exist) to send abuse (a covert channel). No protocol can ever be constructed that is spam-free. Radical anti-spammers often try to couch their arguments as though the spammers are "outsiders" who have been let in. This isn't true. All abusers are the customer of some ISP, somewhere. There are no outsiders. The spammers are in fact authorized users of some ISP that are authorized to send email. They remain authorized to send email until they lose service with that ISP. Once this is understood, it is completely obvious even without the formality of Shannon's theorem that protocols such as this will have no effect whatsoever. It goes without saying that the DNS protocol is itself not secure, and can't be used for any type of authorization or authentication scheme. Therefore, I think this proposal will have no effect on the problem of spam control, and leads to a gratuitous change to the DNS protocol. Specific Comments ================== Section 10.1.5 This section asserts that open relays are a "main problem of spam defense". Having operated open relays for many years, I have substantial operational experience to refute this claim. Our open relays are typically only abused by radical antispammers, sometimes with overt threats. In at least one case, an abuse admin (Chris Neill) was fired (according to his own description posted on spaml) for abusing our open relay "to teach me a lesson". Use of an open relay (or a closed relays) includes the connecting clients' IP address in the Recieved: header. This header cannot be altered by the client. Use of an Open relay does not hide the identity of the sender. Use of an open relay does not alter the property of a user's anonymity. Open relays don't ever "make things worse". The section also contains the false statement: "Once the administrative persons refuse to solve the problem, they can be identified as spammers and held responsible." The spammer is the person who sent the spam. It is not the person who operates the relay or the person who operates the router. The spammer sent the spam. No one else did. No one else is responsible for spam. Open relay is the only way to offer SMTP service (as defined in IETF STD 10) to clients outside ones IP address. None of the alleged harms of open relay have ever withstood close scrutiny. Provably false statements like the ones found in Section 10.1.5 should not be propogated in RFCs. Section 7 of the ISOC Code of Conduct requires members to "Only offer or claim to offer opinions or services that lie within the member's actual knowlege or competence". May I ask what direct, current, and relevent experience you have operating open relays? Dean Anderson President, Av8 Internet, Inc > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 16:46: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 QAA11772 for ; Wed, 4 Jun 2003 16:46:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Nex3-000MzK-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 20:33:41 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19Nex2-000MyJ-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 20:33:40 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFZ00GJJ55AUA@eListX.com> for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 16:34:22 -0400 (EDT) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h54KUb27089127 for ; Wed, 04 Jun 2003 16:30:37 -0400 (EDT envelope-from ogud@ogud.com) Date: Wed, 04 Jun 2003 16:33:07 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT IETF-57 (vienna) Agenda items X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030604163145.0289f860@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=-5.4 required=5.0 tests=BAYES_01,RCVD_IN_RFCI version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Send in requests, Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 18:48:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16462 for ; Wed, 4 Jun 2003 18:48:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NgoE-000Asy-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 22:32:42 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19NgoB-000ArU-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 22:32:39 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id SAA30806; Wed, 4 Jun 2003 18:16:45 -0400 Date: Wed, 4 Jun 2003 18:17:58 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Hallam-Baker, Phillip" cc: Robert Elz , , Subject: RE: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D21C6@mou1wnexm02.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-29.4 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 4 Jun 2003, Hallam-Baker, Phillip wrote: > > Senders of email from a domain are not, in general, attached to an IP > > address. They may use any IP address from any service provider they > > please. For example, I have customers which have leased > > lines from Av8 > > Internet, but have their email outsourced to Earthlink. > > Earthlink does not > > provide them with relay services. > > So Earthlink sets the DNS RMX record accordingly, problem solved. What would they set them to? The customers could use any ISP, anywhere. > Or as is likely to be the case anyway we have to go to a certificate based > scheme if we want to get significant coverage. Certificate based scheme? I must have missed that. > this is simply a low hanging fruit exercise, the cost of deployment is low > and the leverage is significant. The cost of altering the worlds DNS servers is usually considered high. THe leverage seems to be non-existant. > > Limitations on the IP addresses that may be used by users, and thus on > > the industry of Email Outsourcing, and for private use, tend to > > subdivide the internet, and seem to violate the ISOC Code of Conduct > > sections 4 and 14. > > Unless the ISOC can propose a better solution to the spam problem the code > of conduct is not going to have much effect. The Code of conduct was not written to reduce spam. > We already have a major problem with the blacklists causing large areas of > the net to be censored because some self important upstart thinks they are > in charge and have the right to use 'collateral damage'. Yes. > We are not discussing people being kicked off the net here, we are talking > about reducing the probability that their email will be unjustly blocked. > > > > Dr. Claude Shannon, one of the founders of the science of Information > > Theory, proved that it is impossible to prove the non-existance of a > > covert channel. In terms of spam, this means that it is impossible to > > construct a protocol that cannot be abused, since one cannot prove > > that it is impossible (the channel can't exist) to send abuse (a > > covert channel). > > That does not follow at all. And invoking Shannon that way hardly helps the > argument. You are not Claude Shannon and Shannon wrote nothing on the > subject of email spam. He didn't have to write about spam. He wrote about communications. Email, and spam, are just a form of communication. Shannon's theorem is a general result about communications. > It is quite possible to solve the problem of long term abuse in a protocol > where there is a means of establishing reputation. Extrapolation from > abstract principles of what is not possible rarely results in correct > statements. A problem may not be perfectly solvable but it can be > sufficiently solvable. This is nothing other than a blacklist scheme. > > It goes without saying that the DNS protocol is itself not secure, and > > can't be used for any type of authorization or authentication scheme. > > That is not my fault or the fault of Hadmut. It is secure enough to > allow a meaningful level of control. This has been disproven. Spoofing UDP DNS replies is significantly easier than spoofing TCP connections. > > Therefore, I think this proposal will have no effect on the problem of > > spam control, and leads to a gratuitous change to the DNS protocol. > > Would you rather the gratuitous change take place in the IETF or some other > forum? I would rather not have gratuitous change. > > Our open relays are typically > > only abused by radical antispammers, sometimes with overt > > threats. > > And a large part of the movement for new anti-spam mechanisms is comming > from ISPs who are as fed up with the anti-spam people than the spam senders. > They want authentication as a way they can start whitelisting the good mail > rather than relying on self appointed anti-spam zealots. It seemed to me at the MIT anti-spam conference that ISPs were working on content analysis methods, and agreed that blacklists were not going to play a large role in the future. At the end of the message, as it were, the spammer has to talk about selling something. In interesting comment at the conference was from the MSN speaker, who indicated that their content filtering was such that MSN approved spam mail was being blocked. Whatever "anti-spam" mechanisms you build into a protocol will simply be adopted by spammers. Spammers are not outsiders. They are frequently regular users, authorized to send email. They are just sending things they shouldn't. No protocol change can stop that. This is the gist of Shannon's Theorem. Dean Anderson President, Av8 Internet, Inc > > > Phill > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 19: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 TAA16790 for ; Wed, 4 Jun 2003 19:10:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NhHt-000EwH-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 23:03:21 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19NhHq-000Ew4-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 23:03:18 +0000 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h54N3D53009291; Wed, 4 Jun 2003 16:03:13 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2003 16:03:13 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21CA@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: Robert Elz , namedroppers@ops.ietf.org, rfc@danisch.de Subject: RE: draft-danisch-dns-rr-smtp-02.txt Date: Wed, 4 Jun 2003 16:03:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > What would they set them to? The customers could use any ISP, > anywhere. Not if they are going to use RMX... But that is only an option. > Certificate based scheme? I must have missed that. RMX is only the starting point, not the destination. > The cost of altering the worlds DNS servers is usually > considered high. > THe leverage seems to be non-existant. This one change adopted by the right 10 ISPs allows something like 25% of spam to be eliminated between those ISPs (until the spam senders react). > The Code of conduct was not written to reduce spam. Why do you think a code of conduct is going to work if it does not provide an answer to the problems the ISPs legitimately face? > He didn't have to write about spam. He wrote about > communications. I have read the paper several times, it does not have the implication you think it does. Spam is not a covert channel, it is an overt channel. > This is nothing other than a blacklist scheme. No, the critical failure of blacklist schemes is that there is no accountability for the blacklist to any party whatsoever. The people who demand accountability from others, loudly and with threats refuse to accept accountability or responsibility themselves. > > That is not my fault or the fault of Hadmut. It is secure enough to > > allow a meaningful level of control. > > This has been disproven. Spoofing UDP DNS replies is > significantly easier > than spoofing TCP connections. It is pretty easy to detect a DNS spoofing attempt if you are looking for it. You can then switch to TCP/IP. > I would rather not have gratuitous change. Then propose a better solution or convince people the problem is not important. Lack of progress or consensus in this forum is not going to affect deployment of these ideas. > It seemed to me at the MIT anti-spam conference that ISPs > were working on > content analysis methods, and agreed that blacklists were not going to > play a large role in the future. At the end of the message, > as it were, the spammer has to talk about selling something. Paul Graham's conference held on the MIT campus but not accredited or in any way endorsed by MIT was about solving spam with content filtering using Bayesian inference. Papers that proposed other approaches were all rejected so the lack of other proposals is not indicative of ISP intentions. > In interesting comment at the conference was from the MSN speaker, who > indicated that their content filtering was such that MSN approved spam > mail was being blocked. At the FTC conference Ryan Hamlin, the general manager of Microsoft's anti-spam initiatives specifically mentioned RMX by name and use of Reverse DNS as indicative of the type of proposal they are considering with Yahoo and AOL. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 19:10: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 TAA16811 for ; Wed, 4 Jun 2003 19:10:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NhL1-000FKe-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 23:06:35 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19NhKr-000FHr-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 23:06:25 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h54N51l3029767; Thu, 5 Jun 2003 09:05:01 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h54N4tK2043846; Thu, 5 Jun 2003 09:04:56 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306042304.h54N4tK2043846@drugs.dv.isc.org> To: Edward Lewis Cc: "Olaf M. Kolkman" , Derek Atkins , roy@logmess.com, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q-10: Reaction to "Silly" NXT's In-reply-to: Your message of "Tue, 03 Jun 2003 22:12:31 MST." Date: Thu, 05 Jun 2003 09:04:55 +1000 X-Spam-Status: No, hits=-7.4 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,UPPERCASE_25_50 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > (Can a CNAME chain end in an NXDOMAIN?) Yes. RFC 2317 is the classic example. -- 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 Jun 4 19: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 TAA17810 for ; Wed, 4 Jun 2003 19:44:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NhpF-000JkP-00 for namedroppers-data@psg.com; Wed, 04 Jun 2003 23:37:49 +0000 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 19NhpA-000Jg0-00 for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 23:37:45 +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 h54Nb5B4016367 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 5 Jun 2003 01:37:07 +0200 To: Dean Anderson Cc: Robert Elz , namedroppers@ops.ietf.org, Subject: Re: draft-danisch-dns-rr-smtp-02.txt References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030604:dean@av8.com:4ca9b362da6d6031 X-Hashcash: 0:030604:dean@av8.com:4ca9b362da6d6031 X-Payment: hashcash 1.2 0:030604:kre@munnari.OZ.AU:2f8dd2da14098a9f X-Hashcash: 0:030604:kre@munnari.OZ.AU:2f8dd2da14098a9f X-Payment: hashcash 1.2 0:030604:namedroppers@ops.ietf.org:3d702c46463a7281 X-Hashcash: 0:030604:namedroppers@ops.ietf.org:3d702c46463a7281 X-Payment: hashcash 1.2 0:030604:rfc@danisch.de:700ddffd75456430 X-Hashcash: 0:030604:rfc@danisch.de:700ddffd75456430 Date: Thu, 05 Jun 2003 01:37:05 +0200 In-Reply-To: (Dean Anderson's message of "Wed, 4 Jun 2003 16:04:06 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Dean Anderson writes: > Therefore, I think this proposal will have no effect on the problem of > spam control, and leads to a gratuitous change to the DNS protocol. .. >> this is simply a low hanging fruit exercise, the cost of deployment is low >> and the leverage is significant. > > The cost of altering the worlds DNS servers is usually considered high. If the world's DNS servers are compatible with d-i-dnsext-unknown-rrs, no changes to them are required to support RMX. Other systems (e.g., DNSSEC) are contingent on d-i-dnsext-unknown-rrs, so I don't think there is much practical merit to this argument against RMX. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 20:32: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 UAA19488 for ; Wed, 4 Jun 2003 20:31:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NiXM-0000V9-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 00:23:24 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19NiXK-0000Ut-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 00:23:22 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HFY00M8FP8OL5@eListX.com> for namedroppers@ops.ietf.org; Wed, 04 Jun 2003 10:50:48 -0400 (EDT) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h54El527088311; Wed, 04 Jun 2003 10:47:05 -0400 (EDT envelope-from ogud@ogud.com) Date: Wed, 04 Jun 2003 10:49:15 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-reply-to: <005801c32a96$e136c5b0$b9370681@barnacle> X-Sender: post@localhost To: rfc@danisch.de, Scott Rose Cc: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030604103909.027a6ec8@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <220.1054645867@munnari.OZ.AU> X-Spam-Status: No, hits=-30.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 08:43 2003-06-04, Scott Rose wrote: >I generally agree with the previous comments on this draft. In addition, I >have one smaller nit that caught my eye: > >5.3.4. Additional Records > > In order to avoid the need of a second query to resolve the given > host name, a DNS server should enclose the A record for that domain > name in the additional section of the additional section of the DNS > reply, if the server happens to be authoritative. > > > > >I think the "a DNS server should enclose..." should be replace with a >"SHOULD" or (better in my opinion) "MAY". If an A/AAAA RRset is to be >placed in the additional section, this needs to be clearly defined, as it is >now talking about how responses are generated and what a resolver could >expect. Personally, I favor "MAY". This type of rule would require a code >change (not major), but also might be mis-interrpreted by older caching >servers somewhere in the resolution proces. It is no major feat for a >resolver to do another query to get the A RR pointed to by this response. I take to opposite position, NO SPECIAL PROCESSING. There is no advantage to having this processing except to sometimes save on network delay at the cost of more complicated authoritative server, and resolver. Additional section processing should only be used to assist in DNS operation not application lookup. Please remove this section it will only delay the deployment of this RR type and authoritative and recursive servers that know about this will take a long time to get deployed, while many existing servers can support this type via the unknown-rr type support. For more background see the discussion on namedroppers on including KEY RR's in additional section. http://psg.com/lists/namedroppers/namedroppers.2003/msg00235.html Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 22:17: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 WAA22568 for ; Wed, 4 Jun 2003 22:17:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Nk7t-000FCb-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 02:05:13 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19Nk7r-000F2l-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 02:05:11 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h5524Wl3029925; Thu, 5 Jun 2003 12:04:33 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h5524UK2044790; Thu, 5 Jun 2003 12:04:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306050204.h5524UK2044790@drugs.dv.isc.org> Cc: namedroppers@ops.ietf.org, rfc@danisch.de From: Mark.Andrews@isc.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-reply-to: Your message of "Wed, 04 Jun 2003 16:03:12 MST." <2A1D4C86842EE14CA9BC80474919782E0D21CA@mou1wnexm02.verisign.com> Date: Thu, 05 Jun 2003 12:04:30 +1000 X-Spam-Status: No, hits=-5.3 required=5.0 tests=BAYES_20,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I doubt if the DNS is the right place to store this data. There is a high probability that the number of acceptable sources will exceed the DNS's ability to transmit. I suspect the correct way to handle this is to have the servers that are located via SRV records validate whether a given address and/or name is a valid source for this particular email address. 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 Jun 4 22: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 WAA22588 for ; Wed, 4 Jun 2003 22:18:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NkAx-000Fio-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 02:08:23 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19NkAv-000Fib-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 02:08:21 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id WAA22342; Wed, 4 Jun 2003 22:01:39 -0400 Date: Wed, 4 Jun 2003 22:02:51 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Simon Josefsson cc: Robert Elz , , Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 5 Jun 2003, Simon Josefsson wrote: > > The cost of altering the worlds DNS servers is usually considered high. > > If the world's DNS servers are compatible with d-i-dnsext-unknown-rrs, > no changes to them are required to support RMX. Other systems (e.g., > DNSSEC) are contingent on d-i-dnsext-unknown-rrs, so I don't think > there is much practical merit to this argument against RMX. Except that, unless I am mistaken, dnsext-unknown-rrs is just a draft. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 23:24: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 XAA24146 for ; Wed, 4 Jun 2003 23:24:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NlFa-000Pv9-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 03:17:14 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19NlFX-000Pux-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 03:17:11 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id XAA03250; Wed, 4 Jun 2003 23:11:55 -0400 Date: Wed, 4 Jun 2003 23:13:07 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Hallam-Baker, Phillip" cc: Robert Elz , , Subject: RE: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D21CA@mou1wnexm02.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk inline On Wed, 4 Jun 2003, Hallam-Baker, Phillip wrote: > > > What would they set them to? The customers could use any ISP, > > anywhere. > > Not if they are going to use RMX... But that is only an option. > > > Certificate based scheme? I must have missed that. > > RMX is only the starting point, not the destination. We can't go off in wild directions. We need to know that we will get a return on the investment. Spam isn't a big problem. Its an annoying problem. It unclear what the breakdown in terms of Type 1, Type 2, and Type 3 spam is. Type 3 spam is already, generally, a federal felony, with a 5 year jail term, because it is illegal to break into a computer with a virus or by other means. > > The cost of altering the worlds DNS servers is usually > > considered high. > > THe leverage seems to be non-existant. > > This one change adopted by the right 10 ISPs allows something like 25% of > spam to be eliminated between those ISPs (until the spam senders react). So, we spend a lot of money, time, and sweat, and get 10 minutes of reduced spam? This doesn't seem worth it. One thought I had some time ago was filtering based on non-routeable, non-RFC1918 addresses in headers. I noticed that when headers are forged, the abusers tends to just pick random numbers. Some percentage of those are not routeable, and probably _weren't routed, thus making an easy indicator of a forged header. Of course, spammers would just adjust to picking routable numbers. The effort isn't worthwhile. But a lot of spam issn't using forged headers (ie Recieved). I recently went in search of a spam with forged headers (I save all my spam). I had to go through 6 messages to find one with forged headers. The most popular method has been use of open proxies, with no header forgery whatsoever (other than forged from: and such). Type 1 and Type 2 spammers include the contact information in the message. they have no need of forged headers, or could trivially avoid it by using a domain that doesn't receive email, if they don't want to get email responses. Type 3 abusers aren't interested in anything besides annoyance. When they crack a computer, or infect a computer with a virus, they steal the legitimate users email identity. Header authentication doesn't stop this kind of abuse. > > The Code of conduct was not written to reduce spam. > > Why do you think a code of conduct is going to work if it does not provide > an answer to the problems the ISPs legitimately face? Most ISPs don't "legitimately" face these problems. See the description of Type 3 abusers I posted earlier. > > He didn't have to write about spam. He wrote about > > communications. > > I have read the paper several times, it does not have the implication you > think it does. Spam is not a covert channel, it is an overt channel. It is a covert channel since the user isn't supposed to send it. In a classified environment, they are not supposed to send the classified documents, but manages to do so anyway via covert channels. The only real difference is the lack of military classification on the document. But the difference isn't significant. You can't create a spam-free protocol. If you could, I (and many others) would like to see it. It would be *real* useful to those that have classified documents. Nor does a covert channel require cooperation. The recent SSL timing exploits demonstrated that side channels are also covert channels. You can't prove a protocol doesn't have covert channels. You have to discover them, and react to them. This means that you always have to detect and respond to spam. Altering protocols is a waste of time. A spammer can't be stopped until their ISP stops them. ISPs are never going to give authority to terminate accounts to people who aren't under its control. Blacklists are simply attempts to take control of an ISP's email. It won't happen, for a variety of technical and legal reasons (anti-trust). But mainly, it won't happen because neither users nor ISPs (in general) want it to happen. But of course, Type 3 abusers are mostly unconvicted felons. That doesn't require voluntary cooperation from anyone. It just requires Law Enforcement to get interested in tracking these people down. This is already an easy task for Law Enforcement. > > This is nothing other than a blacklist scheme. > > No, the critical failure of blacklist schemes is that there is no > accountability for the blacklist to any party whatsoever. The people who > demand accountability from others, loudly and with threats refuse to accept > accountability or responsibility themselves. I agree that this is a critical failure, but I would add that it isn't the only critical failure. Another problem with blacklists is that they require too much human maintenance. Abusers running large numbers of virus-infected machines (Type 3 abusers) can easily outmanuever a blacklist, while simultaneously causing a lot of collateral damage (directly and indirectly through the blacklist). Collateral damage is the goal of a Type 3 abuser. > > > That is not my fault or the fault of Hadmut. It is secure enough to > > > allow a meaningful level of control. > > > > This has been disproven. Spoofing UDP DNS replies is > > significantly easier > > than spoofing TCP connections. > > It is pretty easy to detect a DNS spoofing attempt if you are looking for > it. You can then switch to TCP/IP. In a low volume lab environment, it is easy. In a high volume environment, it is not. It requires keeping counts of packets and request ids and client addresses. > > I would rather not have gratuitous change. > > Then propose a better solution or convince people the problem is not > important. The third alternative is to convince people not to make gratuitous changes that won't solve the problem. > Lack of progress or consensus in this forum is not going to affect > deployment of these ideas. Perhaps reason and non-standardization will affect them. > > It seemed to me at the MIT anti-spam conference that ISPs > > were working on > > content analysis methods, and agreed that blacklists were not going to > > play a large role in the future. At the end of the message, > > as it were, the spammer has to talk about selling something. > > Paul Graham's conference held on the MIT campus but not accredited or in any > way endorsed by MIT was about solving spam with content filtering using > Bayesian inference. Papers that proposed other approaches were all rejected > so the lack of other proposals is not indicative of ISP intentions. Bayesian was a big topic, but not the only topic. You can read the abstracts at http://www.spamconference.org/abstracts.txt You can also (I think) download the video. Proceedings of the 2003 Spam Conference Teodor Zlatanov Gnus vs. Spam Bill Yerazunis Sparse Binary Polynomial Hash Message Filtering and The CRM114 Discriminator Jason Rennie Automatic Feature Induction for Text Classification John Graham-Cumming The Spammers' Compendium Paul Judge Spam Research: Establishing a Foundation and Moving Forward Paul Graham Better Bayesian Filtering Matt Sergeant Internet Level Spam Detection and SpamAssassin 2.50 Joshua Goodman, Spam Filtering: From the Lab to the Real World Michael Salib Heuristics in the Blender David Lewis, (Spam vs.) Forty Years of Machine Learning for Text Classification Jon Praed, A Spam Litigator's View from the Front Lines Ken Schneider Fighting Spam in Real Time Brian Burton Bayesian Spam Filtering > > In interesting comment at the conference was from the MSN speaker, who > > indicated that their content filtering was such that MSN approved spam > > mail was being blocked. > > At the FTC conference Ryan Hamlin, the general manager of Microsoft's > anti-spam initiatives specifically mentioned RMX by name and use of Reverse > DNS as indicative of the type of proposal they are considering with Yahoo > and AOL. Reverse DNS??? That doesn't sound much like the MSN presentation > > > Phill > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 4 23:58:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24699 for ; Wed, 4 Jun 2003 23:58:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NlnA-0005JL-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 03:51:56 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19Nln8-00056e-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 03:51:54 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h553mYl3030003; Thu, 5 Jun 2003 13:48:34 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h553mSK2044967; Thu, 5 Jun 2003 13:48:32 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306050348.h553mSK2044967@drugs.dv.isc.org> To: Dean Anderson Cc: Simon Josefsson , Robert Elz , namedroppers@ops.ietf.org, rfc@danisch.de From: Mark.Andrews@isc.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-reply-to: Your message of "Wed, 04 Jun 2003 22:02:51 -0400." Date: Thu, 05 Jun 2003 13:48:27 +1000 X-Spam-Status: No, hits=-12.6 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > On Thu, 5 Jun 2003, Simon Josefsson wrote: > > > > The cost of altering the worlds DNS servers is usually considered high. > > > > If the world's DNS servers are compatible with d-i-dnsext-unknown-rrs, > > no changes to them are required to support RMX. Other systems (e.g., > > DNSSEC) are contingent on d-i-dnsext-unknown-rrs, so I don't think > > there is much practical merit to this argument against RMX. > > Except that, unless I am mistaken, dnsext-unknown-rrs is just a draft. > > --Dean Compression is not allowed by RFC 1034. dnsext-unknown-rrs just reinforces it. -- 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 Jun 5 02:31: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 CAA08620 for ; Thu, 5 Jun 2003 02:31:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19No6O-000K5L-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 06:19:56 +0000 Received: from 98.in-addr.ehsco.com ([207.65.203.98] helo=goose.ehsco.com) by psg.com with esmtp (Exim 3.36 #1) id 19No6L-000K59-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 06:19:53 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 210348; Thu, 05 Jun 2003 01:19:24 -0500 Message-ID: <3EDEE105.6090203@ehsco.com> Date: Thu, 05 Jun 2003 01:19:49 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers@ops.ietf.org CC: rfc@danisch.de Subject: Re: draft-danisch-dns-rr-smtp-02.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The cost-v-benefit for this RR will vary. Forged mail domains is a point on the spam continuum, but it's also on the security continuum, the worm continuum, and even the legal continuum such as idiots promising giveaways for contests I'm not having. Frankly I don't even care whether this knocks down any spam at all, I just want control over who gets to use my domain name, regardless of their motives. If spammers move to some other domain and keep spamming, then that's actually a victory in my book. This approach gives all domain owners that same offer of protection, assuming their network topology allows them to use it. For me it would be easy since I always send mail through my own mail server no matter where I'm at. For other folks it will mean using dynamic DNS or scripts to append RRs pointing to wherever they happen to be. Other organizations will have other problems, but none of that makes it unusable for the folks who can use it. Trying to block its development because some people can't use it isn't really justified unless it harms the network. It could certainly be improved (please limit the RR data to a single entry) but near as I can tell it isn't a threat to global DNS stability since it is limited to voluntary domains, and nodes have to request that specific RR for those specific domains, and given the kinds of sites that will check this then most of those lookups are likely to happen after the query path has already been cached from other checks anyway, none of which we have any control over. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 04:14: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 EAA11072 for ; Thu, 5 Jun 2003 04:14:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NpjI-000A9c-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 08:04:12 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 19NpjG-000A9Q-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 08:04:10 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h5583VRS001157; Thu, 5 Jun 2003 10:03:32 +0200 Date: Thu, 5 Jun 2003 10:03:31 +0200 From: "Olaf M. Kolkman" To: Mark.Andrews@isc.org Cc: edlewis@arin.net, derek@ihtfp.com, roy@logmess.com, namedroppers@ops.ietf.org Subject: Re: Q-10: Reaction to "Silly" NXT's Message-Id: <20030605100331.66daf810.olaf@ripe.net> In-Reply-To: <200306042304.h54N4tK2043846@drugs.dv.isc.org> References: <200306042304.h54N4tK2043846@drugs.dv.isc.org> 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-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 05 Jun 2003 09:04:55 +1000 Mark.Andrews@isc.org wrote: > > > (Can a CNAME chain end in an NXDOMAIN?) > > But every CNAME RR in the chain has its independed proof. Doesn't it. --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 04:44: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 EAA11822 for ; Thu, 5 Jun 2003 04:44:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NqGn-000Fsr-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 08:38:49 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 19NqGl-000Fsd-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 08:38:47 +0000 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h558cgRT007629 for ; Thu, 5 Jun 2003 10:38:46 +0200 Date: Thu, 5 Jun 2003 10:38:42 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org Subject: RE: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 4 Jun 2003, Dean Anderson wrote: > On Wed, 4 Jun 2003, Hallam-Baker, Phillip wrote: > > > It is quite possible to solve the problem of long term abuse in a protocol > > where there is a means of establishing reputation. Extrapolation from > > abstract principles of what is not possible rarely results in correct > > statements. A problem may not be perfectly solvable but it can be > > sufficiently solvable. > > This is nothing other than a blacklist scheme. Phillip's statement or the draft? The draft appears to be attempting to set out a whitelisting scheme that is controlled by the owners of the domain in question. ( ie, the 'lists' that it provides are those of allowed servers/ranges. ) Phillip's statement could also be considered to be a whitelisting scheme, in that he mentions establishing the reputation (identify) of, I presume, the participants in a transaction over a given protocol. I can't see how either (Phillip's statement or the draft) could be considered to be a 'blacklist' scheme, mainly because neither purport to list servers/ranges which are _not_ allowed. --==-- Bruce. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 05:40: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 FAA12682 for ; Thu, 5 Jun 2003 05:40:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Nr5H-000OMc-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 09:30:59 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 19Nr5E-000OMQ-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 09:30:56 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h559UFRS018378; Thu, 5 Jun 2003 11:30:15 +0200 Date: Thu, 5 Jun 2003 11:30:15 +0200 From: "Olaf M. Kolkman" To: Edward Lewis Cc: derek@ihtfp.com, roy@logmess.com, namedroppers@ops.ietf.org Subject: Re: Q-10: Reaction to "Silly" NXT's Message-Id: <20030605113015.058c7bc5.olaf@ripe.net> In-Reply-To: References: <20030603121429.66d441dc.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-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 3 Jun 2003 22:12:31 -0700 Edward Lewis wrote: > First I'll assume the context of this is that the NXT is in the > authority section and appears in one of the messages as described in > RFC 2308, including the referral. ACK.... If the NXT appears in the answer it is irrelevant to any proof. That is I think that is in the "spirit" of 5.3 of the protocol doc. (It appears in the answer section because of a direct query for QTYPE=NXT or QTYPE=ANY). > The right way to do this step is to take the NXT and it's SIG and try > to build a chain of trust back to a configured key. (... skipped ...) I agree. The assumption below is that you can follow the chain of trust all the way to the key that made the signature. > > > > >2. Given that the zone is secure you only process NXT RRs to proof > > non-existence of names or non-existence of RRtypes. > > I disagree with this...as before. If I can validate the NXT, the > zone must be secured. If I can't I need to either get the NXT > (absent but expected) or I discard the NXT (present but unexpected). Let me rephrase: You will only get a NXT RR to proof the non-existence of a name or the non-existence of an RRtype with a name. We assume the validator has validated the NXT RR i.e. it is present and expected, and the crypto workes out. > >3. If either a NXDOMAIN or NOERROR empty answer section is received one > > first verifies the SIG over the NXT RR to check if that has not been > > tampered with. If it has been tampered with mark the answer as > > BAD. (Bad luck, either the zone served incorrect data or your answer > > has been tampered with) > > > > The SIG(NXT) is correct so we have to verify if the NXT RR is relevant > > to the answer. > > > > (If the answer is NOERROR and a non-empty answer section we have a > > direct match and the NXT RR is IMHO irrelevant; all the proof > > for the data in the answer section is enclosed in the answer) > > This is the step where I realized that there's something missing from > the discussion. Once you have cryptographically determined that the > NXT is valid (let's assume this is the processing path), then you > need to understand the context to see if it is relevant. > Agreed. > In a referral message, with a negative indication for the DS, you > need to see that the NXT claims that there is no DS but there is a > SIG and NXT for the name, as well as NS's. If that's not the case, > the NXT is inappropriate - or falls under the silly state proposal. > More precise based on the current protcol docs: in a referral message: The owner name must be the same as the owner name of the delegation RR besides the NXT bitmap needs to bits set to 1 for the NS, 0 for the DS and 0 for the SOA. This is all what is relevant to the validator for validating the answer A verifier does not _need_ to check any of the other bits. If it chooses to check the bits the NXT and SIG are supposed to be set to 1 and all the other bits are supposed to be set to 0. Anything other is silly state (not only SIG or NXT being set to 0 is silly state but e.g. an AAAA bit set to 1 is also silly state) in a NOERROR empty answer message: The owner name must be the same as the owner name of the returned NXT record. The bit in the NXT RR corresponding to the QTYPE needs to be set to 0. For this query all the other bits are irrelevant so again a verifier does not need to check any of the other bits. If it chooses to check other bits then the NXT and SIG bit are supposed to be set to 1, otherwise it is a silly state (there is another silly state, if the NXT bitmap contains a SOA and an NS there is not supposed to be a DS) The point I was trying to make is essentially that one never uses the bitmap except for checking if a bit has actually been set to "0" (for a NOERROR empty answer reply) or if the SOA bit is set to "1" or "0" at a zone-cut. The protocol does require a check to see if any of the other bits are actually set to 1; without your proposal the NXT and the SIG bit may be completely ignored. In other words your proposal should include a "MUST verify the state of the bits not relevant to proving the answer" otherwise things will become very messy. Alternatively the protocol docs could say that "verifiers MUST only verify the bits that are relevant to the answer", that excludes sily states alltogether; you just do not care about the settings of the other bits. Another worry, the ownername; Do I read correctly that a silly state does not allow for an owner name different than being expected(#) in other words are ownername checks performed before or after the silly state has been determined. (The argumentation above is based on the ownername being as expected.) If in a silly state the owner name is allowed to be different from you should specify that the silly state first needs to be determined and that one then needs to do the ownernameckeck. (A detail is that if you allow for different owner names the silly state indicators reduce to NXT ans SIG only). --Olaf (#) The NXT ownername that is expected is: NXT ownername < QNAME if RCODE=NXDOMAIN NXT ownername == NS ownername in case of delegation NXT ownername == QNAME in case of NOANSWER -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 06: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 GAA13782 for ; Thu, 5 Jun 2003 06:17:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Nrjw-0004h8-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 10:13:00 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 19Nrjt-0004gv-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 10:12:58 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h55ACtRS028669; Thu, 5 Jun 2003 12:12:55 +0200 Date: Thu, 5 Jun 2003 12:12:55 +0200 From: "Olaf M. Kolkman" To: "Scott Rose" Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis question list - not official Message-Id: <20030605121255.7f9aba9f.olaf@ripe.net> In-Reply-To: <001101c32513$2f96e390$b9370681@barnacle> References: <001101c32513$2f96e390$b9370681@barnacle> 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-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This does not seem to be in the list of questions but is a question in 4.1 of the protocol doc. "Should any of the SHOULD NOTs in this paragraph be MUST NOTs instead." I'd argue for MUST NOTs. If you allow security aware servers try to synthesize responses based on on results from information cached from previous queries with different Q-tripleds an end user may end up with different answers depending on which server he or she happens to hide behind; that is not a Good Idea. --Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 07:03: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 HAA14617 for ; Thu, 5 Jun 2003 07:03:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NsOX-0006yO-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 10:54:57 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19NsOR-0006y1-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 10:54:55 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h54Ldp53023319; Wed, 4 Jun 2003 14:39:52 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2003 14:39:51 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21C6@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , Robert Elz Cc: namedroppers@ops.ietf.org, rfc@danisch.de Subject: RE: draft-danisch-dns-rr-smtp-02.txt Date: Wed, 4 Jun 2003 14:39:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Senders of email from a domain are not, in general, attached to an IP > address. They may use any IP address from any service provider they > please. For example, I have customers which have leased > lines from Av8 > Internet, but have their email outsourced to Earthlink. > Earthlink does not > provide them with relay services. So Earthlink sets the DNS RMX record accordingly, problem solved. Or as is likely to be the case anyway we have to go to a certificate based scheme if we want to get significant coverage. this is simply a low hanging fruit exercise, the cost of deployment is low and the leverage is significant. > Limitations on the IP addresses > that may be > used by users, and thus on the industry of Email Outsourcing, and for > private use, tend to subdivide the internet, and seem to > violate the ISOC Code of Conduct sections 4 and 14. Unless the ISOC can propose a better solution to the spam problem the code of conduct is not going to have much effect. We already have a major problem with the blacklists causing large areas of the net to be censored because some self important upstart thinks they are in charge and have the right to use 'collateral damage'. We are not discussing people being kicked off the net here, we are talking about reducing the probability that their email will be unjustly blocked. > Dr. Claude Shannon, one of the founders of the science of Information > Theory, proved that it is impossible to prove the non-existance of a > covert channel. In terms of spam, this means that it is impossible to > construct a protocol that cannot be abused, since one cannot > prove that it > is impossible (the channel can't exist) to send abuse (a > covert channel). That does not follow at all. And invoking Shannon that way hardly helps the argument. You are not Claude Shannon and Shannon wrote nothing on the subject of email spam. It is quite possible to solve the problem of long term abuse in a protocol where there is a means of establishing reputation. Extrapolation from abstract principles of what is not possible rarely results in correct statements. A problem may not be perfectly solvable but it can be sufficiently solvable. > It goes without saying that the DNS protocol is itself not secure, and > can't be used for any type of authorization or authentication scheme. That is not my fault or the fault of Hadmut. It is secure enough to allow a meaningful level of control. > Therefore, I think this proposal will have no effect on the problem of > spam control, and leads to a gratuitous change to the DNS protocol. Would you rather the gratuitous change take place in the IETF or some other forum? > Our open relays are typically > only abused by radical antispammers, sometimes with overt > threats. And a large part of the movement for new anti-spam mechanisms is comming from ISPs who are as fed up with the anti-spam people than the spam senders. They want authentication as a way they can start whitelisting the good mail rather than relying on self appointed anti-spam zealots. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 07:28:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15581 for ; Thu, 5 Jun 2003 07:28:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NspO-0008Ta-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 11:22:42 +0000 Received: from ratree.psu.ac.th ([202.12.73.3]) by psg.com with esmtp (Exim 3.36 #1) id 19NspL-0008SP-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 11:22:39 +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 h55BMW228670; Thu, 5 Jun 2003 18:22:34 +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 h55BMHi07885; Thu, 5 Jun 2003 18:22:18 +0700 (ICT) From: Robert Elz To: Hadmut Danisch cc: namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <20030603134438.GB7861@danisch.de> References: <20030603134438.GB7861@danisch.de> <220.1054645867@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 2003 18:22:17 +0700 Message-ID: <2587.1054812137@munnari.OZ.AU> X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 3 Jun 2003 15:44:38 +0200 From: Hadmut Danisch Message-ID: <20030603134438.GB7861@danisch.de> | Maybe you could elaborate this a little bit and tell me | what exactly you're talking about, because I'm not a fortune | teller. First, apologies - my message wasn't really for you, it was for the namedroppers mailing list, I just added your name as a courtesy 'cc' (also to make it easier for others to reply to where it would do some good). You've already been told that the problem I was referring to was the use of name compression, and to respond to a later message from you, yes, that means that DNS name compression can never be used in any future RR. That's just the nature of the method, the DNS, and the way it was specified, and there's no rational way to change that now (no-one can deploy a different compression scheme as there's no way to expect anyone would be able to understand it). | Or maybe you should have read something in the ASRG IRTF group. I had no idea it existed, and from what I have been told, no desire whatever to have any contact with that at all. | The problem that is to be solved is the arbitrary forging of | mails. We already have a solution to that which actually works. Signed mail. If I sign my mail, then it is possible to verify that i really did send it, and if you want to prefer only signed mail, or rank mail as "signed therefore probably good", "unsigned so we don't know", and "appears to be signed, but forged, so almost certainly bad", then by all means, go ahead. Your problem is that you can't manage to get people to actually use this method, so you're attempting to impose a bogus inferior attempt to achieve similar results upon them, without consent. | That's exactly the problem. You "promise" it is not forged, but | there is no technical way to determine it, because there is no | technical difference. In that message there wasn't, and in this one there isn't, but if I signed it, there would be. And that's easy (there was a time I had my mailer set up so I could easily sign mail, then I upgraded systems, etc, and didn't bother keeping it all up to date - but that would be easily fixed if there was any real point to it). | Just answer a question: How do you *receive* e-mail | when you're on the road? I have it sent to my mailbox, and yes, that means to Australia. But there's very little alternative to that. The same is true of my physical mail, it all goes to a mailbox in Australia as well. But that doesn't stop me dropping mail in a letterbox, anywhere in the world, with my Australian address on it as a return address. Remember that e-mail was (and is) intended to be the electronic analog of paper mail (memos anyway). Do you really expect that anyone would endorse a scheme where letters could only be posted from specially approved mail boxes (or that any posted elsewhere would gain a "probably forged" imprint upon it)? Anyone who takes any mail I have sent, and suggests that that mail is likely to be a forgery is opening themselves to a slander suit - or if they do it in writing, libel instead. | - You're doing this for incoming e-mail: | So why is it a problem for outgoing e-mail? Because I have no option for incoming mail. It is the nature of mail that it get delivered to a particular mailbox. It remains there until I get the opportunity to fetch it (unaffected by loss of connectivity). If senders can't reach my mailbox, they, or some relay, queues the mail and tries again. With sending mail, I want to be able to send it any time - including when I can't reach my mailbox (in particular when I can't reach my mailbox - I want to be able to report that to someone - they might not be able to reply instantly, but they can get the problem fixed). | Hotmail, AOL, Yahoo, T-Online,etc. are in severe trouble due to the | extreme amount of spam abusing their sender domains. Quite likely. But... | Once these big providers start to have RMX records, Those big providers (not as sure of AOL) are the very ones for whom this scheme can't really work. For munnari.oz.au where I am, in practice, just about the only user of the domain, I could probably find some way to handle the problem. But there are millions (I assume) of users of hotmail, and they aren't all going to always want to send their outgoing mail via hotmail - they use that as a convenient mailbox, and (fairly) stable and anonymous address. They send from anywhere. | Wait until some spammer chooses your domain for abuse, you will | be quite happy to have RMX. Already been there (more than once). And no, I will not be using RMX or anything like it. kre ps: spam is just e-mail, there is not, and cannot be, a technical solution to spam. Even if you can prove who is sending the mail, (or who isn't) by locking down everything, spam will still continue to be sent, as long as doing so benefits the sender more than it costs them. The real problem we have is the mis-use of mailing lists (mis-use of personal data). Fix that, and spam will go away, at least as much as being a problem, as there will be no way for lists of people who don't want the mail to be collected. But the fix cannot be technical, it needs to be social/political - that is, we have to get to the stage where the political will is to fix the problem, and that gets serious enough to overcome the mailing list lobby. The more we do technically to reduce the impact of spam, the longer that will take - the best thing we can do to rid ourselves of spam, is not to attempt to control it at 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 Thu Jun 5 09:59:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25882 for ; Thu, 5 Jun 2003 09:59:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Nv5f-000GlW-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 13:47:39 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 19Nv5b-000GkM-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 13:47:35 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h55DlNuv029520; Thu, 5 Jun 2003 06:47:23 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 06:47:23 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21D3@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: Robert Elz , namedroppers@ops.ietf.org, rfc@danisch.de Subject: RE: draft-danisch-dns-rr-smtp-02.txt Date: Thu, 5 Jun 2003 06:47:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > We can't go off in wild directions. We need to know that we will get a > return on the investment. Spam isn't a big problem. Its an annoying > problem. If you don't understand how big a problem spam is then your comments are simply irrelevant. Spam is the method organized crime uses to run confidence tricks on the Internet. The people sending this stuff are hard core criminals with convictions for cocaine trafficking, money laundering, fraud etc. The volume of spam is such that the ISPs are already taking action. The FTC and Congress are taking action. This is not a case where the IETF can say 'we don't think that is a problem', refuse to solve it and remain credible. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 10:14: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 KAA27372 for ; Thu, 5 Jun 2003 10:14:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NvOt-000HvH-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 14:07:31 +0000 Received: from ratree.psu.ac.th ([202.12.73.3]) by psg.com with esmtp (Exim 3.36 #1) id 19NvOq-000Hv4-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 14:07: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 h55E7G226681; Thu, 5 Jun 2003 21:07: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 h55E70i06067; Thu, 5 Jun 2003 21:07:00 +0700 (ICT) From: Robert Elz To: "Hallam-Baker, Phillip" cc: "'Dean Anderson'" , namedroppers@ops.ietf.org, rfc@danisch.de Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D21D3@mou1wnexm02.verisign.com> References: <2A1D4C86842EE14CA9BC80474919782E0D21D3@mou1wnexm02.verisign.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 2003 21:07:00 +0700 Message-ID: <12365.1054822020@munnari.OZ.AU> X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 5 Jun 2003 06:47:21 -0700 From: "Hallam-Baker, Phillip" Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21D3@mou1wnexm02.verisign.com> | The FTC and Congress are taking action. That is certainly good news. It would be useful if those of you with any kind of contacts (direct, indirect, ...) could point out that the real problem is the abuse of the address list - sending spam is just one possible result from that. Much of Europe (I am told) already has legal protection for personal data (which would include e-mail addresses) - it would be good for the US (and yes, Australia too - and the rest of the world) to emulate that, Without address lists, spammers would have nowhere to go. | This is not a case where the IETF can say 'we don't think that is a | problem', refuse to solve it and remain credible. No - there clearly is a problem. But there is zero technical difference between spam and ordinary e-mail. Even the "bulk" that people used to assert as a differentiator has been bent now - much of the spam I get is addressed to me specifically, and includes a salutation aimed at me (or the best they can do using one of many "role" type e-mail addresses they've obtained) - and if often (apparently) from people I know (at first glance anyway - a few seconds examination shows the differences). The definition now is (apparently) not the same mail to many recipients, but similar mail - which is probably why much spam these days has all kinds of random garbage appended, randomly generated I assume, so it doesn't look similar to any other copy of itself. If spam and e-mail are the same thing (content excepted) which I assert they are, there cannot be a technical way of stopping spam without also stopping e-mail. People can limit their own exposure to some spam using technical mechanisms, but that doesn't make it go away, it just hides it from their view. It needs to be made to go away completely - and that means that anyone found with my address in any list of addresses, without having received (and verified) my explicit consent for its use for some particular purpose (or using it for any other purpose) ought to be gaoled (or billion dollar fines for corporations, and gaol for their directors). Of course - just having the address is not going to cause problems, so no-one need be paranoid, as if it isn't used, no-one would no, no complaint, no investigation. Use it, I complain, blam... To make proof easier, evidence of having sent similar e-mail to more than 20 recipients should be primae facie evidence of a list existing. 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 Jun 5 10:17: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 KAA27650 for ; Thu, 5 Jun 2003 10:17:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NvNW-000Hpo-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 14:06:06 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 19NvNS-000HpV-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 14:06:02 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h55E62uv001788; Thu, 5 Jun 2003 07:06:02 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 07:06:02 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21D5@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Bruce Campbell'" , namedroppers@ops.ietf.org Subject: RE: draft-danisch-dns-rr-smtp-02.txt Date: Thu, 5 Jun 2003 07:06:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The difference here is that in a whitelist scheme I go off to get affirmatively included. If the whitelister decides not to continue listing me I know that they have done that and I can require them to give reasons. In a blacklist scheme there is no recourse. There is no way to even know that you are on a blacklist scheme. The blacklister could report you are clear for all enquiries from the blacklisted domains and blacklisted for queries from any other domain. Phill > -----Original Message----- > From: Bruce Campbell [mailto:bc-namedroppers@vicious.dropbear.id.au] > Sent: Thursday, June 05, 2003 4:39 AM > To: namedroppers@ops.ietf.org > Subject: RE: draft-danisch-dns-rr-smtp-02.txt > > > On Wed, 4 Jun 2003, Dean Anderson wrote: > > > On Wed, 4 Jun 2003, Hallam-Baker, Phillip wrote: > > > > > It is quite possible to solve the problem of long term > abuse in a protocol > > > where there is a means of establishing reputation. > Extrapolation from > > > abstract principles of what is not possible rarely > results in correct > > > statements. A problem may not be perfectly solvable but it can be > > > sufficiently solvable. > > > > This is nothing other than a blacklist scheme. > > Phillip's statement or the draft? The draft appears to be > attempting to > set out a whitelisting scheme that is controlled by the owners of the > domain in question. ( ie, the 'lists' that it provides are those of > allowed servers/ranges. ) > > Phillip's statement could also be considered to be a > whitelisting scheme, > in that he mentions establishing the reputation (identify) > of, I presume, > the participants in a transaction over a given protocol. > > I can't see how either (Phillip's statement or the draft) could be > considered to be a 'blacklist' scheme, mainly because neither > purport to > list servers/ranges which are _not_ allowed. > > --==-- > Bruce. > > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 11:24: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 LAA02513 for ; Thu, 5 Jun 2003 11:24:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NwPK-000Laf-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 15:12:02 +0000 Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by psg.com with esmtp (Exim 3.36 #1) id 19NwPF-000LaQ-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 15:11:57 +0000 Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h55F61Nr016550; Thu, 5 Jun 2003 11:06:01 -0400 (EDT) Message-Id: <200306051506.h55F61Nr016550@nic-naa.net> To: Robert Elz cc: "Hallam-Baker, Phillip" , "'Dean Anderson'" , namedroppers@ops.ietf.org, rfc@danisch.de, brunner@nic-naa.net Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: Your message of "Thu, 05 Jun 2003 21:07:00 +0700." <12365.1054822020@munnari.OZ.AU> Date: Thu, 05 Jun 2003 11:06:01 -0400 From: Eric Brunner-Williams in Portland Maine X-Spam-Status: No, hits=-5.1 required=5.0 tests=BAYES_20,IN_REP_TO,OPT_IN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert, I know of one approach for policing the acquisition of data. In that model a data collection policy is announced by a collector, and evaluated by a user agent. The model allows for both by-reference and as-payload forms of policy announcement. Where I personally failed to convince, when attempting to move this model from its original context (http methods), to another client-server context (epp commands), was that policy announcement by data collectors was useful in the first place. An alternative form, a binary opt-in/opt-out label on the command-embedded data, was adopted as manditory-to-implement. Labeling each item of mail sent with a binary opt-* tag is different from being capable of asking a sender how the recipient address was collected, and if the purpose, and period of retention, and other properties present in the approach for http methods, are consistent with the recipient's, or a relay's, policies. Well, back to work that can be done. The http method dingus is P3P, the as-payload mini-dingus is compact-policies. The epp command dingus is the element in the epp session initiation command. Eric -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 11:24:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02590 for ; Thu, 5 Jun 2003 11:24:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NwPX-000Lau-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 15:12:15 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19NwPU-000Lah-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 15:12:12 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id LAA24354; Thu, 5 Jun 2003 11:06:44 -0400 Date: Thu, 5 Jun 2003 11:07:57 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Hallam-Baker, Phillip" cc: Robert Elz , , Subject: RE: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D21D3@mou1wnexm02.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-29.4 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is an over statement. Spam is a problem. It is annoyance. We would *love* to see it go away. But it is not the end of the world, as some would like to think. The actions Congress has been taking have been to protect Type 1 spammers, and clearly separate the Type 1 from the Type 2 and Type 3 spammers. They are not banning spam. If anything, they are promoting it, by addressing the fraud problem. Type 1 spammers are bonafide commerical operations, and will abide by whatever rules are in place. They have a lot of money, and a big lobby. They are not going away, no matter how much Type 3 spam radical anti-spammers send. The actions the FTC has been taking (via press releases) is partly due to misleading statements made to the FTC, and in part due to the FTC excluding participation of people with opposing views, which is a violation of due process, and civil rights, and other rules. FTC attorneys are investing these false statements, particularly with respect to open relays. The IETF also cannot remain credible by attempting to solve problems that can't be solved technically. Nor can it be credible by reacting emotionally instead of calmly. Emotional appeals do not make effective technical arguments. Any schemes to stop spam, would apply equally to terrorist communications, which we also want to stop. "Osama bin Laden prevented from sending instructions to Al Quaeda because open relays were closed. Al Quaeda neutralized as a result". Of course, that's absurd, but no more so than schemes to stop spam. --Dean On Thu, 5 Jun 2003, Hallam-Baker, Phillip wrote: > > We can't go off in wild directions. We need to know that we will get a > > return on the investment. Spam isn't a big problem. Its an annoying > > problem. > > If you don't understand how big a problem spam is then your comments are > simply irrelevant. > > Spam is the method organized crime uses to run confidence tricks on the > Internet. The people sending this stuff are hard core criminals with > convictions for cocaine trafficking, money laundering, fraud etc. > > The volume of spam is such that the ISPs are already taking action. > The FTC and Congress are taking action. > > This is not a case where the IETF can say 'we don't think that is a > problem', refuse to solve it and remain credible. > > Phill > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 12:12: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 MAA05001 for ; Thu, 5 Jun 2003 12:12:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NxEx-000OYV-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 16:05:23 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19NxEv-000OXY-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 16:05:21 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1CE2F13948 for ; Thu, 5 Jun 2003 16:05:08 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: Message from Bruce Campbell of "Thu, 05 Jun 2003 10:38:42 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 05 Jun 2003 16:05:08 +0000 Message-Id: <20030605160508.1CE2F13948@sa.vix.com> X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > It is quite possible to solve the problem of long term abuse in a ... > > > > This is nothing other than a blacklist scheme. > > ... The draft appears to be attempting to set out a whitelisting scheme ... please limit namedroppers@ discussion of this draft to the dns aspects, like whether special processing ought to be a requirement, or whether compression should be used. the application layer aspects of RMX (and RMX vs MAILFROM) will be discussed elsewhere, and i don't think the namedroppers@ audience needs to see that debate, whereas others elsewhere who don't read namedroppers@ *do* need to see that debate. ergo, please don't have it here. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 13:00: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 NAA06385 for ; Thu, 5 Jun 2003 13:00:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NxyN-00013o-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 16:52:19 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19NxyI-00013c-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 16:52:14 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA04092; Thu, 5 Jun 2003 12:48:46 -0400 Date: Thu, 5 Jun 2003 12:49:49 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <20030605160508.1CE2F13948@sa.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Why is this irrelevant to namedroppers? The entire purpose and effect of the proposed changes should be considered. Putting blinders on, and then making a decision is a formula for bad decision making. On Thu, 5 Jun 2003, Paul Vixie wrote: > > > > It is quite possible to solve the problem of long term abuse in a ... > > > > > > This is nothing other than a blacklist scheme. > > > > ... The draft appears to be attempting to set out a whitelisting scheme ... > > please limit namedroppers@ discussion of this draft to the dns aspects, like > whether special processing ought to be a requirement, or whether compression > should be used. the application layer aspects of RMX (and RMX vs MAILFROM) > will be discussed elsewhere, and i don't think the namedroppers@ audience > needs to see that debate, whereas others elsewhere who don't read namedroppers@ > *do* need to see that debate. ergo, please don't have it here. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 13:39:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07528 for ; Thu, 5 Jun 2003 13:39:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NybS-0002wK-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 17:32:42 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19NybP-0002ve-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 17:32:39 +0000 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id F1430137F30; Thu, 5 Jun 2003 10:32:38 -0700 (PDT) To: Dean Anderson Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: Message from Dean Anderson of "Thu, 05 Jun 2003 12:49:49 EDT." Date: Thu, 05 Jun 2003 10:32:38 -0700 Message-ID: <56110.1054834358@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Dean" == Dean Anderson writes: Dean> Why is this irrelevant to namedroppers? The entire purpose Dean> and effect of the proposed changes should be considered. Because the angels-on-a-pinhead debate you're having with Phillip Hallam-Baker does not belong here. If there is a forum for the two of you to go on and on about ISP anti-spam policies, civil rights, the FTC, money laundering, and Al-Queda -- to quote just a few of the random irrelevancies from recent postings -- that forum is definitely not namedroppers. Now will you please stop hijacking this list so it can be returned to its purpose, the discussion of DNS protocol issues? I fail to see how any of these things are even remotely related to a proposed new RR type. And no, please don't bother enlightening me or, more importantly, this list... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 14:39:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10320 for ; Thu, 5 Jun 2003 14:39:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NzRi-0005mo-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 18:26:42 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19NzRf-0005mU-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 18:26:39 +0000 Received: by sentry.rv.nailabs.com; id OAA29292; Thu, 5 Jun 2003 14:27:59 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma029269; Thu, 5 Jun 03 14:27:03 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6p2/8.11.6) with ESMTP id h55IPcE29161; Thu, 5 Jun 2003 14:25:38 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Thu, 5 Jun 2003 14:25:38 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Bob Halley cc: Subject: Re: DNSSECbis Q-9: Dropping SIG(NXT) in authoritative section for neg. response. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 20 May 2003, Bob Halley wrote: > I support keeping the current language. ... > More importantly, separating SIGs from what they sign is something to > avoid. Whenever you separate a SIG, you run into the possibility that > the SIG you subsequently fetch will be for another version of the > data. When the SIG doesn't verify, the validator must not treat that > as a failure of validation, but instead must refetch both data and its > SIG and try again. Querying for SIGs is bad, yes. Querying for NXT, though, gives you the SIG you need. The problem is that wildcard proofs have to return a NXT who's owner name can't be predicted by the validator. If you return that NXT, sans SIG, the validator could query for the NXT and get the SIG, all without TCP fallback, right? Question: are there caches that will see an NXT in an authority section, and reply to NXT queries with that RR, forcing a SIG query? If so, leave the language as is. If not, why not change it? -- 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 Jun 5 14:43:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10467 for ; Thu, 5 Jun 2003 14:43:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19NzaP-0006H3-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 18:35:41 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 19NzaL-0006G1-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 18:35:37 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h55IZOuv011416; Thu, 5 Jun 2003 11:35:24 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 11:35:24 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21D8@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: Robert Elz , namedroppers@ops.ietf.org, rfc@danisch.de Subject: RE: draft-danisch-dns-rr-smtp-02.txt Date: Thu, 5 Jun 2003 11:35:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_10,BULK_EMAIL,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Spam is a problem. It is annoyance. We would *love* to see it > go away. But > it is not the end of the world, as some would like to think. People are going to take actions to make it go away. So far many of the solutions have caused more problems than the spam. If the technical community refuses to provide constructive advice the solutions adopted are going to be ones it really dislikes. > They are not going away, no matter how much > Type 3 spam radical anti-spammers send. Legislation is a blunt tool and an expensive one. So far the majority of enforcement actions have been against spam senders sending pornography to kids and gangs running con schemes. I am trying to get the US Postal Inspectorate to be given the authority to go after the consumer fraud spam. But no, I don't expect a huge enforcement effort against legitimate companies sending bulk email until the worst of the worst are under control. There is an interaction between the legislation and the technology. It is likely that the legislation will ban use of false headers, open relays etc. > The actions the FTC has been taking (via press releases) is > partly due to misleading statements made to the FTC, The FTC has been holding hearings that were attended by many senior Senators and Congressmen and all of the commissioners. This is not a press release process here. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 16:48: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 QAA16384 for ; Thu, 5 Jun 2003 16:48:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O1U2-000D32-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 20:37:14 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19O1Ty-000D2e-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 20:37:10 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA02020; Thu, 5 Jun 2003 16:30:02 -0400 Date: Thu, 5 Jun 2003 16:31:16 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Jim Reid cc: Paul Vixie , Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <56110.1054834358@shell.nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-29.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk You seem to be quoting out of context. It is relevant to this list whether the proposed changes solve the problem which is claimed to be the motivation, and whether there are equivalent alternatives which solve the motivating problem. I'm trying to show that they don't solve the motivating problem, in this case, spam control. To the extent I succeed at demonstrating that failure, then by definition, that makes the changes proposed gratuitous and unnecessary. Of course that's relevant. I think it is interesting (and telling) that precisely when it is obvious that the proposal solves no problem, that its proponents no longer want to discuss that fact. --Dean On Thu, 5 Jun 2003, Jim Reid wrote: > >>>>> "Dean" == Dean Anderson writes: > > Dean> Why is this irrelevant to namedroppers? The entire purpose > Dean> and effect of the proposed changes should be considered. > > Because the angels-on-a-pinhead debate you're having with Phillip > Hallam-Baker does not belong here. If there is a forum for the two of > you to go on and on about ISP anti-spam policies, civil rights, the > FTC, money laundering, and Al-Queda -- to quote just a few of the > random irrelevancies from recent postings -- that forum is definitely > not namedroppers. Now will you please stop hijacking this list so it > can be returned to its purpose, the discussion of DNS protocol issues? > I fail to see how any of these things are even remotely related to a > proposed new RR type. And no, please don't bother enlightening me or, > more importantly, this list... > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 16:54: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 QAA16561 for ; Thu, 5 Jun 2003 16:54:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O1Uc-000D5g-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 20:37:50 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19O1Ua-000D5U-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 20:37:48 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA10051; Thu, 5 Jun 2003 16:34:53 -0400 Date: Thu, 5 Jun 2003 16:36:06 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Hallam-Baker, Phillip" cc: Robert Elz , , Subject: RE: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D21D8@mou1wnexm02.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-27.0 required=5.0 tests=BAYES_10,BULK_EMAIL,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_NJABL, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE, X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The constructive advice provided by the technical community is that spam isn't a technical problem, except for detection, which leads one to things like bayesian filters and such, which aren't in the domain of the IETF, or namedroppers. Attempts at technical solutions just cause more problems. Obviously, you acknowledge that fact below. The very last thing we need is more gratuitous changes to DNS. --Dean On Thu, 5 Jun 2003, Hallam-Baker, Phillip wrote: > > > Spam is a problem. It is annoyance. We would *love* to see it > > go away. But > > it is not the end of the world, as some would like to think. > > People are going to take actions to make it go away. > > So far many of the solutions have caused more problems than the spam. If the > technical community refuses to provide constructive advice the solutions > adopted are going to be ones it really dislikes. > > > > They are not going away, no matter how much > > Type 3 spam radical anti-spammers send. > > Legislation is a blunt tool and an expensive one. So far the majority of > enforcement actions have been against spam senders sending pornography to > kids and gangs running con schemes. > > I am trying to get the US Postal Inspectorate to be given the authority to > go after the consumer fraud spam. But no, I don't expect a huge enforcement > effort against legitimate companies sending bulk email until the worst of > the worst are under control. > > There is an interaction between the legislation and the technology. It is > likely that the legislation will ban use of false headers, open relays etc. > > > The actions the FTC has been taking (via press releases) is > > partly due to misleading statements made to the FTC, > > The FTC has been holding hearings that were attended by many senior Senators > and Congressmen and all of the commissioners. This is not a press release > process here. > > > Phill > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 17:17: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 RAA17528 for ; Thu, 5 Jun 2003 17:17:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O1xC-000EqZ-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 21:07:22 +0000 Received: from host98-203-65-207.isd.net ([207.65.203.98] helo=goose.ehsco.com) by psg.com with esmtp (Exim 3.36 #1) id 19O1x2-000EqI-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 21:07:12 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 240052 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 16:06:42 -0500 Message-ID: <3EDFB0FC.3010502@ehsco.com> Date: Thu, 05 Jun 2003 16:07:08 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 6/5/2003 3:31 PM Dean Anderson wrote: > I'm trying to show that they don't solve the motivating problem, in > this case, spam control. That's why he's been told to change the context from spam to forgeries. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 17:19: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 RAA17638 for ; Thu, 5 Jun 2003 17:19:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O1zN-000Ext-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 21:09:37 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19O1zH-000EwP-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 21:09:31 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h55L86l3031200; Fri, 6 Jun 2003 07:08:07 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h55L7wK2047089; Fri, 6 Jun 2003 07:07:58 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306052107.h55L7wK2047089@drugs.dv.isc.org> To: "Olaf M. Kolkman" Cc: Edward Lewis , derek@ihtfp.com, roy@logmess.com, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q-10: Reaction to "Silly" NXT's In-reply-to: Your message of "Thu, 05 Jun 2003 11:30:15 +0200." <20030605113015.058c7bc5.olaf@ripe.net> Date: Fri, 06 Jun 2003 07:07:57 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Tue, 3 Jun 2003 22:12:31 -0700 > Edward Lewis wrote: > > > First I'll assume the context of this is that the NXT is in the > > authority section and appears in one of the messages as described in > > RFC 2308, including the referral. > > ACK.... If the NXT appears in the answer it is irrelevant to any > proof. That is I think that is in the "spirit" of 5.3 of the protocol > doc. (It appears in the answer section because of a direct query for > QTYPE=NXT or QTYPE=ANY). > > > > The right way to do this step is to take the NXT and it's SIG and try > > to build a chain of trust back to a configured key. > (... skipped ...) > > I agree. The assumption below is that you can follow the chain of > trust all the way to the key that made the signature. > > > > > > > > > >2. Given that the zone is secure you only process NXT RRs to proof > > > non-existence of names or non-existence of RRtypes. > > > > I disagree with this...as before. If I can validate the NXT, the > > zone must be secured. If I can't I need to either get the NXT > > (absent but expected) or I discard the NXT (present but unexpected). > > Let me rephrase: > > You will only get a NXT RR to proof the non-existence of a name or > the non-existence of an RRtype with a name. We assume the validator has > validated the NXT RR i.e. it is present and expected, and the crypto > workes out. > > > > >3. If either a NXDOMAIN or NOERROR empty answer section is received one > > > first verifies the SIG over the NXT RR to check if that has not been > > > tampered with. If it has been tampered with mark the answer as > > > BAD. (Bad luck, either the zone served incorrect data or your answer > > > has been tampered with) > > > > > > The SIG(NXT) is correct so we have to verify if the NXT RR is relevant > > > to the answer. > > > > > > (If the answer is NOERROR and a non-empty answer section we have a > > > direct match and the NXT RR is IMHO irrelevant; all the proof > > > for the data in the answer section is enclosed in the answer) > > > > This is the step where I realized that there's something missing from > > the discussion. Once you have cryptographically determined that the > > NXT is valid (let's assume this is the processing path), then you > > need to understand the context to see if it is relevant. > > > > Agreed. > > > In a referral message, with a negative indication for the DS, you > > need to see that the NXT claims that there is no DS but there is a > > SIG and NXT for the name, as well as NS's. If that's not the case, > > the NXT is inappropriate - or falls under the silly state proposal. > > > > > > More precise based on the current protcol docs: > > in a referral message: > > The owner name must be the same as the owner name of the delegation > RR besides the NXT bitmap needs to bits set to 1 for the NS, 0 for > the DS and 0 for the SOA. This is all what is relevant to the > validator for validating the answer > > A verifier does not _need_ to check any of the other bits. If it > chooses to check the bits the NXT and SIG are supposed to be set to 1 > and all the other bits are supposed to be set to 0. Anything other is > silly state (not only SIG or NXT being set to 0 is silly state but > e.g. an AAAA bit set to 1 is also silly state) > > > in a NOERROR empty answer message: > > The owner name must be the same as the owner name of the returned NXT > record. The bit in the NXT RR corresponding to the QTYPE needs to be > set to 0. For this query all the other bits are irrelevant so again a > verifier does not need to check any of the other bits. If it chooses > to check other bits then the NXT and SIG bit are supposed to be set to > 1, otherwise it is a silly state (there is another silly state, if > the NXT bitmap contains a SOA and an NS there is not supposed to be a > DS) > > > > The point I was trying to make is essentially that one never uses the > bitmap except for checking if a bit has actually been set to "0" (for > a NOERROR empty answer reply) or if the SOA bit is set to "1" or "0" > at a zone-cut. > > The protocol does require a check to see if any of the other bits are > actually set to 1; without your proposal the NXT and the SIG bit may > be completely ignored. > > In other words your proposal should include a "MUST verify the state > of the bits not relevant to proving the answer" otherwise things will > become very messy. Alternatively the protocol docs could say that > "verifiers MUST only verify the bits that are relevant to the answer", > that excludes sily states alltogether; you just do not care about the > settings of the other bits. > > > > Another worry, the ownername; Do I read correctly that a silly state > does not allow for an owner name different than being expected(#) in > other words are ownername checks performed before or after the silly > state has been determined. (The argumentation above is based on the > ownername being as expected.) > > If in a silly state the owner name is allowed to be different from > you should specify that the silly state first needs to be determined > and that one then needs to do the ownernameckeck. (A detail is that if > you allow for different owner names the silly state indicators reduce > to NXT ans SIG only). > > > --Olaf > > > > (#) The NXT ownername that is expected is: > > NXT ownername < QNAME if RCODE=NXDOMAIN + NXT for non-existance of wildcard. > NXT ownername == NS ownername in case of delegation > NXT ownername == QNAME in case of NOANSWER NXT ownername < QNAME if wildcard answer. > > -- > to 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 Jun 5 18:49: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 SAA21370 for ; Thu, 5 Jun 2003 18:48:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O3Qk-000Ju2-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 22:41:58 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19O3Qg-000Jth-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 22:41:54 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h55Mfk53002883; Thu, 5 Jun 2003 15:41:51 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jun 2003 15:41:46 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21DF@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "'Jim Reid'" Cc: "'Paul Vixie'" , "'namedroppers@ops.ietf.org'" Subject: Re: draft-danisch-dns-rr-smtp-02.txt Date: Thu, 5 Jun 2003 15:41:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I do not want to discuss that issue here because the rest of the list does not want to address that issue. The question of what is effective and what is not will be settled by the results of deployment. Phill -----Original Message----- From: Dean Anderson Sent: Thu Jun 05 13:48:09 2003 To: Jim Reid Cc: Paul Vixie; namedroppers@ops.ietf.org Subject: Re: draft-danisch-dns-rr-smtp-02.txt You seem to be quoting out of context. It is relevant to this list whether the proposed changes solve the problem which is claimed to be the motivation, and whether there are equivalent alternatives which solve the motivating problem. I'm trying to show that they don't solve the motivating problem, in this case, spam control. To the extent I succeed at demonstrating that failure, then by definition, that makes the changes proposed gratuitous and unnecessary. Of course that's relevant. I think it is interesting (and telling) that precisely when it is obvious that the proposal solves no problem, that its proponents no longer want to discuss that fact. --Dean On Thu, 5 Jun 2003, Jim Reid wrote: > >>>>> "Dean" == Dean Anderson writes: > > Dean> Why is this irrelevant to namedroppers? The entire purpose > Dean> and effect of the proposed changes should be considered. > > Because the angels-on-a-pinhead debate you're having with Phillip > Hallam-Baker does not belong here. If there is a forum for the two of > you to go on and on about ISP anti-spam policies, civil rights, the > FTC, money laundering, and Al-Queda -- to quote just a few of the > random irrelevancies from recent postings -- that forum is definitely > not namedroppers. Now will you please stop hijacking this list so it > can be returned to its purpose, the discussion of DNS protocol issues? > I fail to see how any of these things are even remotely related to a > proposed new RR type. And no, please don't bother enlightening me or, > more importantly, this list... > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 19:43: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 TAA22490 for ; Thu, 5 Jun 2003 19:43:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O4ID-000NH1-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 23:37:13 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19O4I8-000NGg-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 23:37:09 +0000 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h55NaW51016097; Thu, 5 Jun 2003 19:36:32 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-278.cisco.com [10.21.97.22]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id TAA24343; Thu, 5 Jun 2003 19:36:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20030605193018.03da2318@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 19:36:24 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: Issues in DDNS-DHCP interaction drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The following drafts have passed WG last call: [1] A DNS RR for Encoding DHCP Information (DHCID RR) [2] The DHCP Client FQDN Option [3] Resolution of DNS Name Conflicts Among DHCP Clients Several issues regarding these drafts have been identified during the AD review prior to IESG review for Proposed Standard status. I will initiate discussion threads on each of these issues later today with e-mail to both the dhcwg and namedroppers mailing lists. Please respond just to the dhcwg mailing list to avoid duplicate postings... - Ralph -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 19:49: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 TAA22789 for ; Thu, 5 Jun 2003 19:49:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O4NS-000Nav-00 for namedroppers-data@psg.com; Thu, 05 Jun 2003 23:42:38 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19O4NQ-000NaV-00 for namedroppers@ops.ietf.org; Thu, 05 Jun 2003 23:42:36 +0000 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h55Nfk51016956; Thu, 5 Jun 2003 19:41:47 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-278.cisco.com [10.21.97.22]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id TAA24637; Thu, 5 Jun 2003 19:41:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20030605193716.03d40c28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 19:41:37 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: DDNS-DHCP [1]: Use DHCID RR just for DHCP or extend for other update mechanisms? Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Ralph Droms , Thomas Narten , Erik.Nordmark@eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DDNS-DHCP issue: The DHCID RR represents an advisory lock used by entities using DHCP to resolve conflicts in the use of DNS records. Is it limiting to restrict the RR to use by entities using DHCP, because there might be other scenarios in the future that could use the same advisory lock mechanism? Or, should the DHCID RR be reserved for use in conjunction with DHCP? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 5 22:35: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 WAA25973 for ; Thu, 5 Jun 2003 22:35:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O6tQ-0006SU-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 02:23:48 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by psg.com with esmtp (Exim 3.36 #1) id 19O6tO-0006SI-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 02:23:46 +0000 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h562Mtpi018070; Thu, 5 Jun 2003 22:22:55 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-278.cisco.com [10.21.97.22]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id WAA03181; Thu, 5 Jun 2003 22:22:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20030605221922.00bbc948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Jun 2003 22:22:44 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: DDNS-DHCP [2]: Allow for other identifying data in the DHCID RR? Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Ralph Droms , Thomas Narten , Erik.Nordmark@eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DDNS-DHCP issue: The DHCID RR data consists of a type code and a hash of the identifier of the updater of the record. Should it be generalized (perhaps as a side effect of generalizing the use of the DHCID RR to other types of resolution) to a type code and type-specific data? That is, should the DHCID RR allow for other forms of data in addition to a 16-byte MD5 hash value to be stored with the type code? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 00:38: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 AAA28374 for ; Fri, 6 Jun 2003 00:38:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19O8rB-000Ccd-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 04:29:37 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19O8r8-000CcR-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 04:29:34 +0000 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h564S5LU026537; Fri, 6 Jun 2003 00:28:06 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-278.cisco.com [10.21.97.22]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id AAA13932; Fri, 6 Jun 2003 00:28:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606002703.03d40c28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 00:27:56 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records Cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Ralph Droms , Thomas Narten , Erik.Nordmark@eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DDNS-DHCP issue: The interaction between DHCPv4 and DHCPv6 needs to be carefully defined. Suppose a DHCPv4 server updates the A RR and a DHCPv6 server updates the AAAA RR of the same node? How is the conflict in the use of the DHCID RR for that node resolved? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 06:35:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16728 for ; Fri, 6 Jun 2003 06:35:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OEQU-0004pr-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 10:26:26 +0000 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.36 #1) id 19OEQR-0004pe-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 10:26:23 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h56APkRS026357; Fri, 6 Jun 2003 12:25:46 +0200 Date: Fri, 6 Jun 2003 12:25:46 +0200 From: "Olaf M. Kolkman" To: Mark.Andrews@isc.org Cc: edlewis@arin.net, derek@ihtfp.com, roy@logmess.com, namedroppers@ops.ietf.org Subject: Re: Q-10: Reaction to "Silly" NXT's Message-Id: <20030606122546.57ba0f4b.olaf@ripe.net> In-Reply-To: <200306052107.h55L7wK2047089@drugs.dv.isc.org> References: <20030605113015.058c7bc5.olaf@ripe.net> <200306052107.h55L7wK2047089@drugs.dv.isc.org> 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-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 06 Jun 2003 07:07:57 +1000 Mark.Andrews@isc.org wrote: (Two minor additions to the expected NXT list at the bottom of the original posting) > > Another worry, the ownername; Do I read correctly that a silly state > > does not allow for an owner name different than being expected(#) in > > other words are ownername checks performed before or after the silly > > state has been determined. (The argumentation above is based on the > > ownername being as expected.) > > > > If in a silly state the owner name is allowed to be different from > > you should specify that the silly state first needs to be determined > > and that one then needs to do the ownernameckeck. (A detail is that if > > you allow for different owner names the silly state indicators reduce > > to NXT ans SIG only). > > > > > > --Olaf > > > > > > > > (#) The NXT ownername that is expected is: > > > > NXT ownername < QNAME if RCODE=NXDOMAIN > + NXT for non-existance of wildcard. Ack.. both are NXT ownernames are < QNAME. > > NXT ownername == NS ownername in case of delegation > > NXT ownername == QNAME in case of NOANSWER > NXT ownername < QNAME if wildcard answer. Ouch... But the ownername is still predictable. The one relevant to the proof for NOANSWER is has the wildcard as ownername. (You will also get a NXT RR that proofs there is no closer match than the wildcard but the NXT bitmap of that RR is irrelevant to the proof of non-existence of the QTYPE) Question remains: Are you first going to check the if bits are in a silly state so you know you do not have to expect a NOANSWER proof with the expected owner name (the NXT with the wildcard itself) or is the check simply: Check if ownername is relevant and then check that the bit for QTYPE is set to 0. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 06:35: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 GAA16748 for ; Fri, 6 Jun 2003 06:35:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OELe-0004ba-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 10:21:26 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19OELc-0004bN-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 10:21:24 +0000 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56AKgLV008095; Fri, 6 Jun 2003 06:20:43 -0400 (EDT) Date: Fri, 6 Jun 2003 06:20:42 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org, namedroppers@ops.ietf.org cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com Subject: DDNS-DHCP [3]: 12 bit RCODEs in DHCP FQDN option Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DDNS-DHCP issue: The DHCP FQDN option should carry 12 bit RCODEs, for consistency with the extended RCODEs defined by EDNS0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 07:00: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 HAA17409 for ; Fri, 6 Jun 2003 07:00:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OEry-0006Ii-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 10:54:50 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19OErw-0006I2-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 10:54:48 +0000 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56ArvLV012084; Fri, 6 Jun 2003 06:53:58 -0400 (EDT) Date: Fri, 6 Jun 2003 06:53:57 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org, namedroppers@ops.ietf.org cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com Subject: DDNS-DHCP [4]: 12 bit RCODEs in DHCP FQDN option Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.7 required=5.0 tests=BAYES_01,UPPERCASE_25_50,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DDNS-DHCP issue: The DHCP FQDN option should carry 12 bit RCODEs, for consistency with the extended RCODEs defined by EDNS0. (reposted with corrected issue number...) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 07:10: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 HAA17842 for ; Fri, 6 Jun 2003 07:10:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OEym-0006pz-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 11:01:52 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19OEyk-0006pn-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 11:01:50 +0000 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56B13LV013829; Fri, 6 Jun 2003 07:01:04 -0400 (EDT) Date: Fri, 6 Jun 2003 07:01:03 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org, namedroppers@ops.ietf.org cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com Subject: DDNS-DHCP [5]: IDN in DDNS-DHCP docs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DDNS-DHCP issue: The IDN WG has concluded and the results of its work should be considered in the DDNS-DHCP documents. The changes may be as minimal as specifying the use of the IDN on-the-wire format. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 09:34: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 JAA22918 for ; Fri, 6 Jun 2003 09:34:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OHD3-000Eb6-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 13:24:45 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19OHD0-000Ea9-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 13:24:42 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h56DNMl3032071; Fri, 6 Jun 2003 23:23:23 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h56DNMK2050600; Fri, 6 Jun 2003 23:23:22 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306061323.h56DNMK2050600@drugs.dv.isc.org> To: "Olaf M. Kolkman" Cc: edlewis@arin.net, derek@ihtfp.com, roy@logmess.com, namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q-10: Reaction to "Silly" NXT's In-reply-to: Your message of "Fri, 06 Jun 2003 12:25:46 +0200." <20030606122546.57ba0f4b.olaf@ripe.net> Date: Fri, 06 Jun 2003 23:23:22 +1000 X-Spam-Status: No, hits=-12.6 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Fri, 06 Jun 2003 07:07:57 +1000 > Mark.Andrews@isc.org wrote: > > (Two minor additions to the expected NXT list at the bottom of the original > posting) > > > > > Another worry, the ownername; Do I read correctly that a silly state > > > does not allow for an owner name different than being expected(#) in > > > other words are ownername checks performed before or after the silly > > > state has been determined. (The argumentation above is based on the > > > ownername being as expected.) > > > > > > If in a silly state the owner name is allowed to be different from > > > you should specify that the silly state first needs to be determined > > > and that one then needs to do the ownernameckeck. (A detail is that if > > > you allow for different owner names the silly state indicators reduce > > > to NXT ans SIG only). > > > > > > > > > --Olaf > > > > > > > > > > > > (#) The NXT ownername that is expected is: > > > > > > NXT ownername < QNAME if RCODE=NXDOMAIN > > + NXT for non-existance of wildcard. > > Ack.. both are NXT ownernames are < QNAME. No. The wildcard proof can be after the QNAME. %.example.com #.example.com NXT &.example.com &.example.com NXT example.com > > > NXT ownername == NS ownername in case of delegation > > > NXT ownername == QNAME in case of NOANSWER > > NXT ownername < QNAME if wildcard answer. > > Ouch... > > But the ownername is still predictable. > The one relevant to the proof for NOANSWER is has the wildcard as > ownername. You have two NXT's. One to prove the name didn't exist which also identifies the wildcard name and one to prove the QTYPE doesn't exist which has the wildcard as a owner. > (You will also get a NXT RR that proofs there is no closer > match than the wildcard but the NXT bitmap of that RR is irrelevant to > the proof of non-existence of the QTYPE) > > Question remains: > > Are you first going to check the if bits are in a silly state so you > know you do not have to expect a NOANSWER proof with the expected > owner name (the NXT with the wildcard itself) or is the check simply: > Check if ownername is relevant and then check that the bit for QTYPE > is set to 0. Non-existance of QNAME doesn't depend upon the bits. Non-existance of QTYPE depends upon the bits. > --Olaf > > --------------------------------------------| Olaf M. Kolkman > | www.ripe.net/disi -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 11:05: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 LAA27523 for ; Fri, 6 Jun 2003 11:05:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OIYA-000JNl-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 14:50:38 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19OIY8-000JNY-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 14:50:36 +0000 Received: from mjs-w2k01.cisco.com ([10.86.146.21]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56EnrLV003594; Fri, 6 Jun 2003 10:49:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606103540.01d4e9d0@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 10:49:52 -0400 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] DDNS-DHCP [4]: 12 bit RCODEs in DHCP FQDN option Cc: dhcwg@ietf.org, namedroppers@ops.ietf.org, olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This issue was raised once before. There's some history here, so I'll try to summarize it briefly. The format of the dhcp fqdn option has been around for a long time. It was used in the implementation of some dhcp clients. There are very many of those clients, and they really expect that there are two bytes of data in those RCODE positions. The only RCODEs that are part of the dhcp/dns specs fix in 8 bits. We reached consensus on the mailing list that it was more important to maintain support for the millions of deployed clients than it was to change the physical format of the dhcp option for this purpose. I recorded this decision in section 4.2 of the fqdn option draft. -- Mark At 06:53 AM 6/6/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The DHCP FQDN option should carry 12 bit RCODEs, for > consistency with the extended RCODEs defined by EDNS0. > > >(reposted with corrected issue number...) >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 14:44: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 OAA06841 for ; Fri, 6 Jun 2003 14:44:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OLzr-0008fM-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 18:31:27 +0000 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 19OLzo-0008f8-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 18:31:25 +0000 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h56IVMH05214 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 6 Jun 2003 14:31:22 -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 h56IVLg3008075; Fri, 6 Jun 2003 14:31:21 -0400 Message-Id: <200306061831.h56IVLg3008075@sandelman.ottawa.on.ca> To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: DDNS-DHCP [1]: Use DHCID RR just for DHCP or extend for other update mechanisms? In-reply-to: Your message of "Thu, 05 Jun 2003 19:41:37 EDT." <4.3.2.7.2.20030605193716.03d40c28@funnel.cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Jun 2003 14:31:20 -0400 From: Michael Richardson X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Well, trivially, I can see that a PPP end point might want to use dynamic update for the same reason that DHCP might. (And PPPoE is very popular now). So, I'd say that anything that needs to *interlock* with DHCP needs to use it. But, maybe I misunderstood the question. ] ON HUMILITY: to err is human. To moo, bovine. | 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 GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPuDd94qHRg3pndX9AQHNiwP9GSWc2inQiw2kL4ClDaTgyKzyXxT38/QE 4guuwTUqo5Se9IEqAK/gr1lwN84ZlyzEleNJaX87dUeWq3BY/Gk7B1UziiLTsVor dbAeWS7lYuKnkTBrDF7pu49hDJ/GAcqnjBK2uwRfSrfHdmTacatvDqB1JwjJY26x QC7k8HeIqfc= =oBMX -----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 Jun 6 14:52: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 OAA07152 for ; Fri, 6 Jun 2003 14:52:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OMAE-0009Jc-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 18:42:10 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19OMAA-0009JN-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 18:42:06 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id OAA05390 for ; Fri, 6 Jun 2003 14:39:37 -0400 Date: Fri, 6 Jun 2003 14:40:51 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: namedroppers@ops.ietf.org Subject: Administrator: Returned mail: User unknown (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; REPORT-TYPE=delivery-status; BOUNDARY="QAA18618.1054845356/citation.av8.net" Content-ID: X-Spam-Status: No, hits=-19.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_NJABL, RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --QAA18618.1054845356/citation.av8.net Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Administrator, the following address seems to be broken. Please take the appropriate action to remove this address from the list. Thanks, --Dean ... while talking to sa.vix.com.: >>> RCPT To: <<< 553 Service unavailable; Client host [130.105.12.4] blocked using zombie.dnsbl.sorbs.net; Zombie Netblock [130.105.0.0/16] See: http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.0.0 550 ... User unknown ---------- Forwarded message ---------- Date: Thu, 5 Jun 2003 16:35:56 -0400 From: Mail Delivery Subsystem To: dean@av8.com Subject: Returned mail: User unknown The original message was received at Thu, 5 Jun 2003 16:30:02 -0400 from IDENT:dean@commander.av8.net [130.105.11.4] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to sa.vix.com.: >>> RCPT To: <<< 553 Service unavailable; Client host [130.105.12.4] blocked using zombie.dnsbl.sorbs.net; Zombie Netblock [130.105.0.0/16] See: http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.0.0 550 ... User unknown --QAA18618.1054845356/citation.av8.net Content-Type: MESSAGE/DELIVERY-STATUS; CHARSET=US-ASCII Content-ID: Content-Description: Reporting-MTA: dns; citation.av8.net Arrival-Date: Thu, 5 Jun 2003 16:30:02 -0400 Final-Recipient: RFC822; paul@vix.com Action: failed Status: 5.1.1 Remote-MTA: DNS; sa.vix.com Diagnostic-Code: SMTP; 553 Service unavailable; Client host [130.105.12.4] blocked using zombie.dnsbl.sorbs.net; Zombie Netblock [130.105.0.0/16] See: http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.0.0 Last-Attempt-Date: Thu, 5 Jun 2003 16:35:55 -0400 --QAA18618.1054845356/citation.av8.net Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: Return-Path: Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id QAA02020; Thu, 5 Jun 2003 16:30:02 -0400 Date: Thu, 5 Jun 2003 16:31:16 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: Jim Reid cc: Paul Vixie , Subject: Re: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <56110.1054834358@shell.nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You seem to be quoting out of context. It is relevant to this list whether the proposed changes solve the problem which is claimed to be the motivation, and whether there are equivalent alternatives which solve the motivating problem. I'm trying to show that they don't solve the motivating problem, in this case, spam control. To the extent I succeed at demonstrating that failure, then by definition, that makes the changes proposed gratuitous and unnecessary. Of course that's relevant. I think it is interesting (and telling) that precisely when it is obvious that the proposal solves no problem, that its proponents no longer want to discuss that fact. --Dean On Thu, 5 Jun 2003, Jim Reid wrote: > >>>>> "Dean" == Dean Anderson writes: > > Dean> Why is this irrelevant to namedroppers? The entire purpose > Dean> and effect of the proposed changes should be considered. > > Because the angels-on-a-pinhead debate you're having with Phillip > Hallam-Baker does not belong here. If there is a forum for the two of > you to go on and on about ISP anti-spam policies, civil rights, the > FTC, money laundering, and Al-Queda -- to quote just a few of the > random irrelevancies from recent postings -- that forum is definitely > not namedroppers. Now will you please stop hijacking this list so it > can be returned to its purpose, the discussion of DNS protocol issues? > I fail to see how any of these things are even remotely related to a > proposed new RR type. And no, please don't bother enlightening me or, > more importantly, this list... > --QAA18618.1054845356/citation.av8.net-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 15:18:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09098 for ; Fri, 6 Jun 2003 15:18:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OMdW-000BLu-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 19:12:26 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19OMdQ-000BLY-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 19:12:20 +0000 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56JBZLV019333; Fri, 6 Jun 2003 15:11:35 -0400 (EDT) Date: Fri, 6 Jun 2003 15:11:35 -0400 (EDT) From: Ralph Droms To: namedroppers@ops.ietf.org, dhcwg@ietf.org cc: olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com Subject: DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> Message-ID: References: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-38.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DDNS-DHCP issue: The RR TTLs need careful attention so that it never exceeds the expiration time of the lease on the associated address. This issue was anticipated by Patrick Cosmo: On Fri, 6 Jun 2003, Cosmo, Patrick wrote: > I have found some minor issues with the > , I apologize if they have already > been brought up. > > In particular, this statement in section 5. (DNS RR TTLs) on page 5: > > "The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed > 1/3 of the lease time, and SHOULD be at least 10 minutes." > > 1. This sentence has some bad grammar ("for with" : ... record added for > with a DHCP lease ...). > > 2. The statement is contradictory if the lease time is less than 30 minutes. > When the lease time is less than 30 minutes, which suggestion takes > precendence? : min. 10 minutes, or max or 1/3 lease time? > > 3. The section seems intended to suggest a reasonable TTL for these records, > but doesn't seem to pull through or suggest much of anything (IMHO) other > than "it should be a function of lease time, and it should be configurable". > > > Patrick Cosmo > > Senior Product Engineer > Incognito Software Inc > Vancouver: (604) 688-4332 ext: 254 > Toll-Free: 1-800-877-1856 > http://www.incognito.com > > > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, June 05, 2003 7:36 PM > To: dhcwg@ietf.org; namedroppers@ops.ietf.org > Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts > > > The following drafts have passed WG last call: > > [1] A DNS RR for Encoding DHCP Information (DHCID RR) > > > [2] The DHCP Client FQDN Option > > > [3] Resolution of DNS Name Conflicts Among DHCP Clients > > > Several issues regarding these drafts have been identified > during the AD review prior to IESG review for Proposed > Standard status. I will initiate discussion threads on > each of these issues later today with e-mail to both > the dhcwg and namedroppers mailing lists. Please respond > just to the dhcwg mailing list to avoid duplicate postings... > > - Ralph > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 15:19: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 PAA09120 for ; Fri, 6 Jun 2003 15:19:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OMdk-000BNL-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 19:12:40 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19OMdi-000BMx-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 19:12:38 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id PAA27643; Fri, 6 Jun 2003 15:06:49 -0400 Date: Fri, 6 Jun 2003 15:08:04 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Hallam-Baker, Phillip" cc: "'Bruce Campbell'" , Subject: RE: draft-danisch-dns-rr-smtp-02.txt In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D21D5@mou1wnexm02.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-29.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 5 Jun 2003, Hallam-Baker, Phillip wrote: > The difference here is that in a whitelist scheme I go off to get > affirmatively included. If the whitelister decides not to continue listing > me I know that they have done that and I can require them to give reasons. YOu are correct that this is a whitelist scheme. However, we already have whitelist facilities, and don't need addtitional changes to implement a whitelist. Regular DNS blacklist methods also work as whitelist methods. In fact, I run a whitelist using Dan Bernstein's rbldns software. This proposal serves no purpose whatsoever. We don't need any changes to DNS to implement whitelists. This functionality already exists. ============= divert(-1) # # Sendmail feature/hack M4 file for implementing whitelist # # Copyright 2003, Av8 Internet, Inc # # dnswhitelist.mf # divert(0) ifdef(`_DNSBL_R_',`dnl',`dnl VERSIONID(`$Id: dnswhitelist.m4,v 8.18.16.1 2000/11/22 01:13:21 ca Exp $')') divert(-1) divert(8) # DNS based IP address whitelist _ARG_ R$* $: $&{client_addr} R::ffff:$-.$-.$-.$- $: $(host $4.$3.$2.$1._ARG_. $: OK $) R$-.$-.$-.$- $: $(host $4.$3.$2.$1._ARG_. $: OK $) ROK $: NOTWHITELISTED R$+ $@ WHITELISTEDDONE divert(-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: From owner-namedroppers@ops.ietf.org Fri Jun 6 15:31:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09420 for ; Fri, 6 Jun 2003 15:31:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OMqp-000CGV-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 19:26:11 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19OMqm-000CG5-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 19:26:08 +0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h56JQ753025341 for ; Fri, 6 Jun 2003 12:26:07 -0700 (PDT) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 12:26:08 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21EE@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: namedroppers@ops.ietf.org Subject: RMX and IP hijacking Date: Fri, 6 Jun 2003 12:26:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Re; the zombie bounce. This is simply a demonstration that the blacklists are not a scalable solution to the problem. The full listing is: Netblock 130.105.0.0 / 16 Summary The OSF doesn't exist anymore, making this hijacked. Announced By [1784] Global NAPs Networks Entry Created Wed May 21 11:51:29 2003 AEST Record Updated Wed May 21 11:52:38 2003 AEST Currently active and flagged to be published in DNS Spam has not been received from this netblock. So rightly or wrongly this block is listed as having been hijacked. One of the concerns that I do have with RMX is that it may create perverse incentives for spam senders to start hijacking valid IP addresses with BGP spoofing. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 15:37: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 PAA09614 for ; Fri, 6 Jun 2003 15:37:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OMuH-000CUF-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 19:29:45 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19OMuF-000CTx-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 19:29:43 +0000 Received: from mjs-w2k01.cisco.com ([10.86.146.21]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56JT0LV023777; Fri, 6 Jun 2003 15:29:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606150043.01d94e48@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 15:28:59 -0400 To: "Cosmo, Patrick" From: Mark Stapp Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction drafts Cc: "'Ralph Droms'" , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.c om.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Patrick, Thanks for the comments. I'll fix the typo. The ttl recommendations resulted from a couple of back-and-forths over a period of years, and the current set of numbers is based on recommendations from the dnsext wg chairs. The basic issue is that dns operators don't want stale rrs lying around after dhcp leases have expired, and at the same time they don't want micro-ttls that make caching ineffective. The core goal was to make implementors aware of the issue, and to recommend common sense when twiddling the configuration. The specific values were meant, I think, to be more concrete guidance, but not a substitute for good sense. As you observe, there's a recommendation, but the specifics are meant to be a guide, and that's why they're 'SHOULD'-strength. The '1/3' number is meant to address the 'stale rrs' concern, and the '10 minutes' is meant to address the 'micro-ttl' concern. Is there something else that could be said in section 5 that would make that clearer? -- Mark At 11:31 AM 6/6/2003 -0700, Cosmo, Patrick wrote: >I have found some minor issues with the >, I apologize if they have already >been brought up. > >In particular, this statement in section 5. (DNS RR TTLs) on page 5: > >"The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed >1/3 of the lease time, and SHOULD be at least 10 minutes." > >1. This sentence has some bad grammar ("for with" : ... record added for >with a DHCP lease ...). > >2. The statement is contradictory if the lease time is less than 30 >minutes. When the lease time is less than 30 minutes, which suggestion >takes precendence? : min. 10 minutes, or max or 1/3 lease time? > >3. The section seems intended to suggest a reasonable TTL for these >records, but doesn't seem to pull through or suggest much of anything >(IMHO) other than "it should be a function of lease time, and it should be >configurable". > >Patrick Cosmo > >Senior Product Engineer >Incognito Software Inc >Vancouver: (604) 688-4332 ext: 254 >Toll-Free: 1-800-877-1856 >http://www.incognito.com > > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, June 05, 2003 7:36 PM >To: dhcwg@ietf.org; namedroppers@ops.ietf.org >Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts > >The following drafts have passed WG last call: > >[1] A DNS RR for Encoding DHCP Information (DHCID RR) > > >[2] The DHCP Client FQDN Option > > >[3] Resolution of DNS Name Conflicts Among DHCP Clients > > >Several issues regarding these drafts have been identified >during the AD review prior to IESG review for Proposed >Standard status. I will initiate discussion threads on >each of these issues later today with e-mail to both >the dhcwg and namedroppers mailing lists. Please respond >just to the dhcwg mailing list to avoid duplicate postings... > >- Ralph > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 15:40:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09708 for ; Fri, 6 Jun 2003 15:40:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OMya-000CqV-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 19:34:12 +0000 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 19OMyY-000Cph-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 19:34:10 +0000 Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.9/) with ESMTP id h56JY6uv024687; Fri, 6 Jun 2003 12:34:06 -0700 (PDT) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 12:34:06 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21EF@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , namedroppers@ops.ietf.org Subject: RE: Administrator: Returned mail: User unknown (fwd) Date: Fri, 6 Jun 2003 12:34:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Further to my earlier note, take a look at one of the other sister blacklists: 66.31.xx.xx found in Database of servers sending to spamtrap addresses Address or Block 127.0.0.10 / 32 Description dummy entry Entry Created Thu Jan 1 00:00:00 1970 Entry Last Seen Thu Jan 1 00:00:00 1970 Spam Seen From 127.0.0.10 Currently active and flagged to be published in DNS I have heard of collateral damage, but listing a /32 sounds a bit excessive. This is more proof that this whole reuse DNS as a spam blacklist distribution idea is bogus. People seem to be using DNS as the UDP firewall bypass protocol in the same way that HTTP has become the TCP firewall bypass protocol. Phill > -----Original Message----- > From: Dean Anderson [mailto:dean@av8.com] > Sent: Friday, June 06, 2003 2:41 PM > To: namedroppers@ops.ietf.org > Subject: Administrator: Returned mail: User unknown (fwd) > > > > Administrator, the following address seems to be broken. > Please take the > appropriate action to remove this address from the list. > > Thanks, > > --Dean > > > ... while talking to sa.vix.com.: > >>> RCPT To: > <<< 553 Service unavailable; Client host [130.105.12.4] blocked using > zombie.dnsbl.sorbs.net; Zombie Netblock > [130.105.0.0/16] See: > http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.0.0 > 550 ... User unknown > > > ---------- Forwarded message ---------- > Date: Thu, 5 Jun 2003 16:35:56 -0400 > From: Mail Delivery Subsystem > To: dean@av8.com > Subject: Returned mail: User unknown > > The original message was received at Thu, 5 Jun 2003 16:30:02 -0400 > from IDENT:dean@commander.av8.net [130.105.11.4] > > ----- The following addresses had permanent fatal errors ----- > > > ----- Transcript of session follows ----- > ... while talking to sa.vix.com.: > >>> RCPT To: > <<< 553 Service unavailable; Client host [130.105.12.4] > blocked using zombie.dnsbl.sorbs.net; Zombie Netblock > [130.105.0.0/16] See: > http://www.dnsbl.sorbs.net/cgi-bin/lookup?IP=130.105.0.0 > 550 ... User unknown > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 15:55:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10146 for ; Fri, 6 Jun 2003 15:55:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ONDJ-000DwG-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 19:49:25 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by psg.com with esmtp (Exim 3.36 #1) id 19ONDG-000Dvr-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 19:49:23 +0000 Received: from mjs-w2k01.cisco.com ([10.86.146.21]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56JmcLV028649; Fri, 6 Jun 2003 15:48:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606152905.01da4b50@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 15:48:38 -0400 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: namedroppers@ops.ietf.org, dhcwg@ietf.org, olaf@ripe.net, Bernard Aboba , Rob Austein , Thomas Narten , Erik.Nordmark@eng.sun.com In-Reply-To: References: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've replied to Patrick; I'm not quite sure what more to do with issue [6]. The draft recommends using a ttl that's a fraction of the lease time, and recommends removing rrs promptly when the lease expires. There have been at least a couple of exchanges about this over the years, and the conclusion has always been that it's not possible to come up with a single set of values that are appropriate in every situation. Also, it's not possible to compel updaters to perform additional updates to 'back down' rrs' ttls as a lease approaches its expiration - that'll kill the dns server. As I noted in the other email I sent, the recommendations that are in the draft are the most up-to-date ones that I've been offered. We do have quite a bit of deployment experience with dhcp updates to dns, and this has not been an issue, as far as I can recall. I also don't recall any email to the wg indicating that this has been an issue in anyone else's experience. If someone has followed these recommendations and has found problems with them, then by all means let's come up with better recommendations. -- Mark At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote: >DDNS-DHCP issue: > > The RR TTLs need careful attention so that it never exceeds the > expiration time of the lease on the associated address. > >This issue was anticipated by Patrick Cosmo: > >On Fri, 6 Jun 2003, Cosmo, Patrick wrote: > > > I have found some minor issues with the > > , I apologize if they have already > > been brought up. > > > > In particular, this statement in section 5. (DNS RR TTLs) on page 5: > > > > "The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed > > 1/3 of the lease time, and SHOULD be at least 10 minutes." > > > > 1. This sentence has some bad grammar ("for with" : ... record added for > > with a DHCP lease ...). > > > > 2. The statement is contradictory if the lease time is less than 30 > minutes. > > When the lease time is less than 30 minutes, which suggestion takes > > precendence? : min. 10 minutes, or max or 1/3 lease time? > > > > 3. The section seems intended to suggest a reasonable TTL for these > records, > > but doesn't seem to pull through or suggest much of anything (IMHO) other > > than "it should be a function of lease time, and it should be > configurable". > > > > > > Patrick Cosmo > > > > Senior Product Engineer > > Incognito Software Inc > > Vancouver: (604) 688-4332 ext: 254 > > Toll-Free: 1-800-877-1856 > > http://www.incognito.com > > > > > > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Thursday, June 05, 2003 7:36 PM > > To: dhcwg@ietf.org; namedroppers@ops.ietf.org > > Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts > > > > > > The following drafts have passed WG last call: > > > > [1] A DNS RR for Encoding DHCP Information (DHCID RR) > > > > > > [2] The DHCP Client FQDN Option > > > > > > [3] Resolution of DNS Name Conflicts Among DHCP Clients > > > > > > Several issues regarding these drafts have been identified > > during the AD review prior to IESG review for Proposed > > Standard status. I will initiate discussion threads on > > each of these issues later today with e-mail to both > > the dhcwg and namedroppers mailing lists. Please respond > > just to the dhcwg mailing list to avoid duplicate postings... > > > > - Ralph > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 15:56: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 PAA10169 for ; Fri, 6 Jun 2003 15:56:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ONFx-000E7U-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 19:52:09 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19ONFv-000E7H-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 19:52:07 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id PAA30600; Fri, 6 Jun 2003 15:49:56 -0400 Date: Fri, 6 Jun 2003 15:51:11 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Hallam-Baker, Phillip" cc: namedroppers@ops.ietf.org Subject: Re: RMX and IP hijacking In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D21EE@mou1wnexm02.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-29.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is false, misleading, and defamatory information. Where did you get this information? We have lawyers. --Dean On Fri, 6 Jun 2003, Hallam-Baker, Phillip wrote: > Re; the zombie bounce. This is simply a demonstration that the blacklists > are not a scalable solution to the problem. > > > The full listing is: > > Netblock 130.105.0.0 / 16 > Summary The OSF doesn't exist anymore, making this hijacked. > Announced By [1784] Global NAPs Networks > Entry Created Wed May 21 11:51:29 2003 AEST > Record Updated Wed May 21 11:52:38 2003 AEST > Currently active and flagged to be published in DNS > Spam has not been received from this netblock. > > > So rightly or wrongly this block is listed as having been hijacked. > > One of the concerns that I do have with RMX is that it may create perverse > incentives for spam senders to start hijacking valid IP addresses with BGP > spoofing. > > 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: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 16:52: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 QAA12355 for ; Fri, 6 Jun 2003 16:52:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OO2b-000HRO-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 20:42:25 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19OO2Z-000HR1-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 20:42:23 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id B9A3B65C; Fri, 6 Jun 2003 16:42:22 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 6348A5E2 for ; Fri, 6 Jun 2003 16:42:22 -0400 (EDT) Received: from [127.0.0.1] (HELO [204.152.189.21]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 368105; Fri, 06 Jun 2003 16:40:01 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Fri, 6 Jun 2003 13:42:31 -0700 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: RFC 1035, section 3.3.1 Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.2 required=5.0 tests=BAYES_01,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Can the domain name in question start with the label "*"? What should happen if it does? (Pre-DNSSEC and in DNSSEC.) I'm asking in the context of writing silly-state NXT rules. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Okay, okay, the previous sig wasn't all that good... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 18:04: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 SAA15480 for ; Fri, 6 Jun 2003 18:04:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OPCV-000MNR-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 21:56:43 +0000 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 19OPCS-000MNF-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 21:56:40 +0000 Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h56Lua53021205; Fri, 6 Jun 2003 14:56:36 -0700 (PDT) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jun 2003 14:56:36 -0700 Message-ID: <2A1D4C86842EE14CA9BC80474919782E0D21F9@mou1wnexm02.verisign.com> From: "Hallam-Baker, Phillip" To: "'Dean Anderson'" , "Hallam-Baker, Phillip" Cc: namedroppers@ops.ietf.org Subject: RE: RMX and IP hijacking Date: Fri, 6 Jun 2003 14:56:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I followed up the URI listed in the bounce message. That is the reason it gives for the listing. There is something wierd going on with that blacklist, one of their blacklists is blacklisting my IP address 66.31.xx.xx for being 'in' 127.0.0.10 / 32 I don't know if my IP is being blacklisted because their search algorithm is broken or they use the notation /32 to mean 2^32 addresses rather than just one. So is Dean still convinced that Spam is not a problem? Phill > -----Original Message----- > From: Dean Anderson [mailto:dean@av8.com] > Sent: Friday, June 06, 2003 3:51 PM > To: Hallam-Baker, Phillip > Cc: namedroppers@ops.ietf.org > Subject: Re: RMX and IP hijacking > > > This is false, misleading, and defamatory information. > > Where did you get this information? We have lawyers. > > --Dean > > On Fri, 6 Jun 2003, Hallam-Baker, Phillip wrote: > > > Re; the zombie bounce. This is simply a demonstration that > the blacklists > > are not a scalable solution to the problem. > > > > > > The full listing is: > > > > Netblock 130.105.0.0 / 16 > > Summary The OSF doesn't exist anymore, making this hijacked. > > Announced By [1784] Global NAPs Networks > > Entry Created Wed May 21 11:51:29 2003 AEST > > Record Updated Wed May 21 11:52:38 2003 AEST > > Currently active and flagged to be published in DNS > > Spam has not been received from this netblock. > > > > > > So rightly or wrongly this block is listed as having been hijacked. > > > > One of the concerns that I do have with RMX is that it may > create perverse > > incentives for spam senders to start hijacking valid IP > addresses with BGP > > spoofing. > > > > 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: > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 18:10: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 SAA16076 for ; Fri, 6 Jun 2003 18:10:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OPKc-000N5k-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 22:05:06 +0000 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 19OPKY-000N2y-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 22:05:03 +0000 Received: from sandelman.ottawa.on.ca ([2002:c08b:2e42::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h550UQT22292 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 4 Jun 2003 20:30:32 -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 h541kUmo024288 for ; Tue, 3 Jun 2003 21:46:30 -0400 Message-Id: <200306040146.h541kUmo024288@sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: Q-10: Reaction to "Silly" NXT's In-reply-to: Your message of "Tue, 27 May 2003 10:17:03 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 03 Jun 2003 21:46:29 -0400 From: Michael Richardson X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I have read the entire thread to date. I don't have knowledge about the proposed "experimental" states that !nxt or !sig might indicate, and this concerns me. So we have Ed's situation #2 - where we decide it is unsigned because we found "silly state". Derek suggests that this causes anyone "playing" to become completely insecure - I find that conclusion to be overfast. I think that I agree with Olaf's analysis. We would only care about checking the NXT when we got a NXDOMAIN for a QNAME/QTYPE we were looking for. Only at that point would we check the NXT bits at all, so it would only be at that point that we might notice a "silly state". As such, "silly state" can only be used in experiments that change our notion about non-existance. I think that we should be adding the step 4.0 in Olaf's list - we already have the NXT-DS problem where we screwed up in 2535. Let's not paint ourselves into a corner again. I think it a fair conclusion that if a resolver finds a "silly state" while trying to prove the non-existence of a QNAME/QTYPE, that it SHOULD fail to unsigned - that it is should claim the QNAME does not exist, but it should not set the AD bit. yes, Derek is right - anyone playing with "silly state"s for some experiment may be loosing deniability where they are using it. That sounds fair to me. ] ON HUMILITY: to err is human. To moo, bovine. | 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 GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPt1PcoqHRg3pndX9AQERtwP9E46t0lmja1CKFIJflaqo8GpH3Ho23L5G 74dXMQqieFGROQc0pgTilDXuXS3Ipp8D+V9caZmi8hkeWuywpPrBjyV3Zbxqg32F 4wbEfUg+iAMq/BvDIYi+QwxZJsROtjvRPQeTvh1/PrJOMt3Lq6OQlY4PoV3Yki3Q eeJ8oLRMmrg= =GXav -----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 Jun 6 18:33: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 SAA17153 for ; Fri, 6 Jun 2003 18:33:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OPiY-000OZ3-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 22:29:50 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19OPiW-000OYr-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 22:29:48 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HG2004EUZUXYY@eListX.com> for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 18:30:34 -0400 (EDT) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h56MQTNO096682; Fri, 06 Jun 2003 18:26:30 -0400 (EDT envelope-from ogud@ogud.com) Date: Fri, 06 Jun 2003 18:29:18 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: RE: RMX and IP hijacking In-reply-to: <2A1D4C86842EE14CA9BC80474919782E0D21F9@mou1wnexm02.verisig n.com> X-Sender: (Unverified) To: "Hallam-Baker, Phillip" , "'Dean Anderson'" Cc: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030606182600.02596e20@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=-15.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_RFCI autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:56 2003-06-06, Hallam-Baker, Phillip wrote: >I followed up the URI listed in the bounce message. That is the reason it >gives for the listing. This discussion has nothing to do with DNSEXT, please remove namedroppers from all subsequent messages on this topic or I will put you both on notice that your posting privileges will be suspended. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 18:53: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 SAA17556 for ; Fri, 6 Jun 2003 18:53:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OPuW-000PUK-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 22:42:12 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19OPuU-000PU7-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 22:42:10 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id SAA14825; Fri, 6 Jun 2003 18:39:19 -0400 Date: Fri, 6 Jun 2003 18:40:23 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: "Hallam-Baker, Phillip" cc: namedroppers@ops.ietf.org Subject: RE: RMX and IP hijacking In-Reply-To: <2A1D4C86842EE14CA9BC80474919782E0D21F9@mou1wnexm02.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-29.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_NJABL,RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES, USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 6 Jun 2003, Hallam-Baker, Phillip wrote: > I followed up the URI listed in the bounce message. That is the reason it > gives for the listing. > > There is something wierd going on with that blacklist, one of their > blacklists is blacklisting my IP address 66.31.xx.xx for being 'in' > 127.0.0.10 / 32 > > I don't know if my IP is being blacklisted because their search algorithm is > broken or they use the notation /32 to mean 2^32 addresses rather than just > one. > > > So is Dean still convinced that Spam is not a problem? I am convinced that anti-spammers are bigger liars, generate more abuse, and cause more collateral damage than Type 1 spammers. This just seems to more evidence, of a long string, to prove it. --Dean -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 6 20: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 UAA19060 for ; Fri, 6 Jun 2003 20:04:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OQzJ-0003kT-00 for namedroppers-data@psg.com; Fri, 06 Jun 2003 23:51:13 +0000 Received: from [2001:470:1f00:ffff::5a1] (helo=bsdi.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19OQzH-0003hH-00 for namedroppers@ops.ietf.org; Fri, 06 Jun 2003 23:51:11 +0000 Received: from drugs.dv.isc.org (drugs.dv.isc.org [192.168.191.236]) by bsdi.dv.isc.org (8.12.9/8.12.9) with ESMTP id h56NoXl3035513; Sat, 7 Jun 2003 09:50:34 +1000 (EST) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h56NoXK2054933; Sat, 7 Jun 2003 09:50:33 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306062350.h56NoXK2054933@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: RFC 1035, section 3.3.1 In-reply-to: Your message of "Fri, 06 Jun 2003 13:42:31 MST." Date: Sat, 07 Jun 2003 09:50:33 +1000 X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Can the domain name in question start with the label "*"? > > What should happen if it does? (Pre-DNSSEC and in DNSSEC.) > > I'm asking in the context of writing silly-state NXT rules. The record is allowed but you have but the record is only synthesised if the QTYPE is CNAME. This really needs to cleaned up. Either wildcard CNAMES need to be banned or RFC 1034 Section 4.3.2. Algorithm needs to be fixed. Replace: If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label. Go to step 6. With: If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label. If the data at the node is a CNAME and QTYPE is not CNAME copy it into the answer section, but set the owner of the RR to be QNAME, not the node with the "*" label. Go to step 6. This still leave NS and DNAME as problematical wildcards. -- 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 Sat Jun 7 01:41:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24887 for ; Sat, 7 Jun 2003 01:41:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OWFA-000On3-00 for namedroppers-data@psg.com; Sat, 07 Jun 2003 05:27:56 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 19OWF7-000OmL-00 for namedroppers@ops.ietf.org; Sat, 07 Jun 2003 05:27:54 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D8A4A18C6 for ; Sat, 7 Jun 2003 01:27:21 -0400 (EDT) Date: Sat, 07 Jun 2003 01:27:21 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: RFC 1035, section 3.3.1 In-Reply-To: <200306062350.h56NoXK2054933@drugs.dv.isc.org> References: <200306062350.h56NoXK2054933@drugs.dv.isc.org> 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: <20030607052721.D8A4A18C6@thrintun.hactrn.net> X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Er, -which- DNS name in RFC 1035 3.3.1? Owner name or RDATA? IMIHO: yes, the DNS name in the RDATA can start with the label "*", what happens is the same as always happens with CNAME processing (so after hitting this CNAME doing an explict query for a name with "*" as the first label, so no wildcard sythesis on this link in the CNAME chain), and this is even more twisted than what Mark thought Ed meant. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 7 17:55: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 RAA22645 for ; Sat, 7 Jun 2003 17:55:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OlSO-0001oX-00 for namedroppers-data@psg.com; Sat, 07 Jun 2003 21:42:36 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19OlSM-0001oG-00 for namedroppers@ops.ietf.org; Sat, 07 Jun 2003 21:42:34 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19OlSM-0000HW-Bq for namedroppers@ops.ietf.org; Sat, 07 Jun 2003 14:42:34 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D1980176693F@homer.incognito.com.> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32C59.D6969490" From: "Cosmo, Patrick" To: "'Ralph Droms'" , dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction drafts Date: Fri, 6 Jun 2003 11:31:26 -0700 X-Spam-Status: No, hits=0.8 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_30,HTML_20_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32C59.D6969490 Content-Type: text/plain; charset="iso-8859-1" [ 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. ] I have found some minor issues with the , I apologize if they have already been brought up. In particular, this statement in section 5. (DNS RR TTLs) on page 5: "The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed 1/3 of the lease time, and SHOULD be at least 10 minutes." 1. This sentence has some bad grammar ("for with" : ... record added for with a DHCP lease ...). 2. The statement is contradictory if the lease time is less than 30 minutes. When the lease time is less than 30 minutes, which suggestion takes precendence? : min. 10 minutes, or max or 1/3 lease time? 3. The section seems intended to suggest a reasonable TTL for these records, but doesn't seem to pull through or suggest much of anything (IMHO) other than "it should be a function of lease time, and it should be configurable". Patrick Cosmo Senior Product Engineer Incognito Software Inc Vancouver: (604) 688-4332 ext: 254 Toll-Free: 1-800-877-1856 http://www.incognito.com -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, June 05, 2003 7:36 PM To: dhcwg@ietf.org; namedroppers@ops.ietf.org Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts The following drafts have passed WG last call: [1] A DNS RR for Encoding DHCP Information (DHCID RR) [2] The DHCP Client FQDN Option [3] Resolution of DNS Name Conflicts Among DHCP Clients Several issues regarding these drafts have been identified during the AD review prior to IESG review for Proposed Standard status. I will initiate discussion threads on each of these issues later today with e-mail to both the dhcwg and namedroppers mailing lists. Please respond just to the dhcwg mailing list to avoid duplicate postings... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C32C59.D6969490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Issues in DDNS-DHCP interaction drafts

I have found some minor issues with the = <draft-ietf-dhc-ddns-resolution-05.txt>, I apologize if they have = already been brought up.

In particular, this statement in section 5. (DNS RR = TTLs) on page 5:

"The RR TTL on a DNS record added for with a = DHCP lease SHOULD NOT exceed 1/3 of the lease time, and SHOULD be at = least 10 minutes."

1. This sentence has some bad grammar ("for = with" : ... record added for with a DHCP lease ...).

2. The statement is contradictory if the lease time = is less than 30 minutes. When the lease time is less than 30 minutes, = which suggestion takes precendence? : min. 10 minutes, or max or 1/3 = lease time?

3. The section seems intended to suggest a reasonable = TTL for these records, but doesn't seem to pull through or suggest much = of anything (IMHO) other than "it should be a function of lease = time, and it should be configurable".

Patrick Cosmo
 
Senior Product Engineer
Incognito Software Inc
Vancouver: (604) 688-4332 ext: 254
Toll-Free: 1-800-877-1856
http://www.incognito.com
 


-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, June 05, 2003 7:36 PM
To: dhcwg@ietf.org; namedroppers@ops.ietf.org
Subject: [dhcwg] Issues in DDNS-DHCP interaction = drafts


The following drafts have passed WG last call:

[1] A DNS RR for Encoding DHCP Information (DHCID = RR)
    = <draft-ietf-dnsext-dhcid-rr-06.txt>

[2] The DHCP Client FQDN Option
    = <draft-ietf-dhc-fqdn-option-05.txt>

[3] Resolution of DNS Name Conflicts Among DHCP = Clients
    = <draft-ietf-dhc-ddns-resolution-05.txt>

Several issues regarding these drafts have been = identified
during the AD review prior to IESG review for = Proposed
Standard status.  I will initiate discussion = threads on
each of these issues later today with e-mail to = both
the dhcwg and namedroppers mailing lists.  = Please respond
just to the dhcwg mailing list to avoid duplicate = postings...

- Ralph

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C32C59.D6969490-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 7 17:55: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 RAA22661 for ; Sat, 7 Jun 2003 17:55:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OlXR-0002HK-00 for namedroppers-data@psg.com; Sat, 07 Jun 2003 21:47:49 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19OlXN-0002H2-00 for namedroppers@ops.ietf.org; Sat, 07 Jun 2003 21:47:45 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19OlXN-0000I2-Gn for namedroppers@ops.ietf.org; Sat, 07 Jun 2003 14:47:45 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D19801766941@homer.incognito.com.> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32C6B.D18C46E0" From: "Cosmo, Patrick" To: "'Mark Stapp'" Cc: "'Ralph Droms'" , dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction drafts Date: Fri, 6 Jun 2003 13:40:08 -0700 X-Spam-Status: No, hits=-5.7 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_30,EMAIL_ATTRIBUTION,HTML_20_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32C6B.D18C46E0 Content-Type: text/plain; charset="iso-8859-1" [ 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. ] >Is there something else that could be said >in section 5 that would make that clearer? Is the intention to recommend that the TTL time be 10 minutes or 1/3 of the lease time, whichever is greater? If so: "The RR TTL on a DNS record added for a DHCP lease SHOULD be 1/3 of the lease time or 10 minutes, whichever is greater". Or is the intention to recommend that any time between 10 minutes and 1/3 of the lease time be used for TTL, except when 1/3 of the lease is less than 10 minutes, in which case the TTL should be 10 minutes? If so: "The RR TTL on a DNS record added for a DHCP lease SHOULD NOT exceed 1/3 of the lease time, unless 1/3 of the lease time amounts to less than 10 minutes. The RR TTL on a DNS record added for a DHCP lease SHOULD always be at least 10 minutes." -----Original Message----- From: Mark Stapp [mailto:mjs@cisco.com] Sent: Friday, June 06, 2003 3:29 PM To: Cosmo, Patrick Cc: 'Ralph Droms'; dhcwg@ietf.org; namedroppers@ops.ietf.org Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction drafts Patrick, Thanks for the comments. I'll fix the typo. The ttl recommendations resulted from a couple of back-and-forths over a period of years, and the current set of numbers is based on recommendations from the dnsext wg chairs. The basic issue is that dns operators don't want stale rrs lying around after dhcp leases have expired, and at the same time they don't want micro-ttls that make caching ineffective. The core goal was to make implementors aware of the issue, and to recommend common sense when twiddling the configuration. The specific values were meant, I think, to be more concrete guidance, but not a substitute for good sense. As you observe, there's a recommendation, but the specifics are meant to be a guide, and that's why they're 'SHOULD'-strength. The '1/3' number is meant to address the 'stale rrs' concern, and the '10 minutes' is meant to address the 'micro-ttl' concern. Is there something else that could be said in section 5 that would make that clearer? -- Mark At 11:31 AM 6/6/2003 -0700, Cosmo, Patrick wrote: >I have found some minor issues with the >, I apologize if they have already >been brought up. > >In particular, this statement in section 5. (DNS RR TTLs) on page 5: > >"The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed >1/3 of the lease time, and SHOULD be at least 10 minutes." > >1. This sentence has some bad grammar ("for with" : ... record added for >with a DHCP lease ...). > >2. The statement is contradictory if the lease time is less than 30 >minutes. When the lease time is less than 30 minutes, which suggestion >takes precendence? : min. 10 minutes, or max or 1/3 lease time? > >3. The section seems intended to suggest a reasonable TTL for these >records, but doesn't seem to pull through or suggest much of anything >(IMHO) other than "it should be a function of lease time, and it should be >configurable". > >Patrick Cosmo > >Senior Product Engineer >Incognito Software Inc >Vancouver: (604) 688-4332 ext: 254 >Toll-Free: 1-800-877-1856 >http://www.incognito.com > > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, June 05, 2003 7:36 PM >To: dhcwg@ietf.org; namedroppers@ops.ietf.org >Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts > >The following drafts have passed WG last call: > >[1] A DNS RR for Encoding DHCP Information (DHCID RR) > > >[2] The DHCP Client FQDN Option > > >[3] Resolution of DNS Name Conflicts Among DHCP Clients > > >Several issues regarding these drafts have been identified >during the AD review prior to IESG review for Proposed >Standard status. I will initiate discussion threads on >each of these issues later today with e-mail to both >the dhcwg and namedroppers mailing lists. Please respond >just to the dhcwg mailing list to avoid duplicate postings... > >- Ralph > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman /listinfo/dhcwg > ------_=_NextPart_001_01C32C6B.D18C46E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Issues in DDNS-DHCP interaction drafts

>Is there something else that could be said =
>in section 5 that would make that = clearer?

Is the intention to recommend that the TTL time be 10 = minutes or 1/3 of the lease time, whichever is greater? If so:

"The RR TTL on a DNS record added for a DHCP = lease SHOULD be 1/3 of the lease time or 10 minutes, whichever is = greater".

Or is the intention to recommend that any time = between 10 minutes and 1/3 of the lease time be used for TTL, except = when 1/3 of the lease is less than 10 minutes, in which case the TTL = should be 10 minutes? If so:

"The RR TTL on a DNS record added for a DHCP = lease SHOULD NOT exceed
1/3 of the lease time, unless 1/3 of the lease time = amounts to less than 10 minutes. The RR TTL on a DNS record added for a = DHCP lease SHOULD always be at least 10 minutes."


 

-----Original Message-----
From: Mark Stapp [mailto:mjs@cisco.com]
Sent: Friday, June 06, 2003 3:29 PM
To: Cosmo, Patrick
Cc: 'Ralph Droms'; dhcwg@ietf.org; = namedroppers@ops.ietf.org
Subject: RE: [dhcwg] Issues in DDNS-DHCP interaction = drafts


Patrick,
Thanks for the comments. I'll fix the typo.

The ttl recommendations resulted from a couple of = back-and-forths over a
period of years, and the current set of numbers is = based on recommendations
from the dnsext wg chairs. The basic issue is that = dns operators don't want
stale rrs lying around after dhcp leases have = expired, and at the same time
they don't want micro-ttls that make caching = ineffective. The core goal was
to make implementors aware of the issue, and to = recommend common sense when
twiddling the configuration. The specific values = were meant, I think, to be
more concrete guidance, but not a substitute for = good sense. As you
observe, there's a recommendation, but the specifics = are meant to be a
guide, and that's why they're 'SHOULD'-strength. The = '1/3' number is meant
to address the 'stale rrs' concern, and the '10 = minutes' is meant to
address the 'micro-ttl' concern. Is there something = else that could be said
in section 5 that would make that clearer?

-- Mark

At 11:31 AM 6/6/2003 -0700, Cosmo, Patrick = wrote:

>I have found some minor issues with the
><draft-ietf-dhc-ddns-resolution-05.txt>, I = apologize if they have already
>been brought up.
>
>In particular, this statement in section 5. (DNS = RR TTLs) on page 5:
>
>"The RR TTL on a DNS record added for with = a DHCP lease SHOULD NOT exceed
>1/3 of the lease time, and SHOULD be at least 10 = minutes."
>
>1. This sentence has some bad grammar ("for = with" : ... record added for
>with a DHCP lease ...).
>
>2. The statement is contradictory if the lease = time is less than 30
>minutes. When the lease time is less than 30 = minutes, which suggestion
>takes precendence? : min. 10 minutes, or max or = 1/3 lease time?
>
>3. The section seems intended to suggest a = reasonable TTL for these
>records, but doesn't seem to pull through or = suggest much of anything
>(IMHO) other than "it should be a function = of lease time, and it should be
>configurable".
>
>Patrick Cosmo
>
>Senior Product Engineer
>Incognito Software Inc
>Vancouver: (604) 688-4332 ext: 254
>Toll-Free: 1-800-877-1856
><http://www.incognito.com>http://www.incognito.com
>
>
>-----Original Message-----
>From: Ralph Droms [<mailto:rdroms@cisco.com>mailto:rdroms@cisco.com]
>Sent: Thursday, June 05, 2003 7:36 PM
>To: dhcwg@ietf.org; = namedroppers@ops.ietf.org
>Subject: [dhcwg] Issues in DDNS-DHCP interaction = drafts
>
>The following drafts have passed WG last = call:
>
>[1] A DNS RR for Encoding DHCP Information = (DHCID RR)
>     = <draft-ietf-dnsext-dhcid-rr-06.txt>
>
>[2] The DHCP Client FQDN Option
>     = <draft-ietf-dhc-fqdn-option-05.txt>
>
>[3] Resolution of DNS Name Conflicts Among DHCP = Clients
>     = <draft-ietf-dhc-ddns-resolution-05.txt>
>
>Several issues regarding these drafts have been = identified
>during the AD review prior to IESG review for = Proposed
>Standard status.  I will initiate = discussion threads on
>each of these issues later today with e-mail to = both
>the dhcwg and namedroppers mailing lists.  = Please respond
>just to the dhcwg mailing list to avoid = duplicate postings...
>
>- Ralph
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg =
>

------_=_NextPart_001_01C32C6B.D18C46E0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 7 18:03: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 SAA22975 for ; Sat, 7 Jun 2003 18:03:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Olcv-0002f6-00 for namedroppers-data@psg.com; Sat, 07 Jun 2003 21:53:29 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Olct-0002et-00; Sat, 07 Jun 2003 21:53:27 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19Olct-0000Id-2M; Sat, 07 Jun 2003 14:53:27 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 7 Jun 2003 14:53:26 -0700 To: "Hallam-Baker, Phillip" Cc: "'Dean Anderson'" , namedroppers@ops.ietf.org Subject: RE: RMX and IP hijacking References: <2A1D4C86842EE14CA9BC80474919782E0D21F9@mou1wnexm02.verisign.com> Message-Id: X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I followed up the URI listed in the bounce message. That is the reason it > gives for the listing. > > There is something wierd going on with that blacklist, one of their > blacklists is blacklisting my IP address 66.31.xx.xx for being 'in' > 127.0.0.10 / 32 > > I don't know if my IP is being blacklisted because their search algorithm is > broken or they use the notation /32 to mean 2^32 addresses rather than just > one. > > So is Dean still convinced that Spam is not a problem? this is not a dns protocol issue, and you are responding to a known troll. please take this off-list. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 7 18:25: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 SAA24514 for ; Sat, 7 Jun 2003 18:25:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19OlzD-00046l-00 for namedroppers-data@psg.com; Sat, 07 Jun 2003 22:16:31 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19Olz9-00046U-00 for namedroppers@ops.ietf.org; Sat, 07 Jun 2003 22:16:27 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 3136E3CB; Sat, 7 Jun 2003 18:16:27 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 9E0A53E2; Sat, 7 Jun 2003 18:16:26 -0400 (EDT) Received: from [127.0.0.1] (HELO [204.152.189.21]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 369406; Sat, 07 Jun 2003 18:14:00 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <200306061323.h56DNMK2050600@drugs.dv.isc.org> References: <200306061323.h56DNMK2050600@drugs.dv.isc.org> Date: Fri, 6 Jun 2003 19:24:15 -0700 To: Mark.Andrews@isc.org From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: "Olaf M. Kolkman" , edlewis@arin.net, derek@ihtfp.com, roy@logmess.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-11.8 required=5.0 tests=BAYES_30,DATE_IN_PAST_12_24,IN_REP_TO,REFERENCES, SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have to admit that my head hurts from recent travels and this thread. Here is how I would summarize this, not to squash other's input, but to allow others to check against what I am thinking. Look at the header: is the response code NXDOMAIN or NOERROR? Is the AA bit set? Look at the answer section: this is a bit more convoluted 1) Find the sequence of SNAME (search names) appearing in the answer section. SNAME #1 ought to be QNAME. If there are multiple SNAMEs, then the transition from SNAME #i to SNAME #i+1 has to occur via CNAMEs or DNAMEs. In any case, we need to identify SNAME#n - which is the last name searched. Let's call it TNAME. (QNAME and SNAME appear in RFC 1034. Olafur and I agreed on TNAME.) It's common that QNAME = TNAME. If the QNAME != TNAME, there is a penultimate SNAME, SNAME#n-1, that is significant if there are wild card synthesized answers. If the answer section is empty, there is no penultimate SNAME, QNAME = SNAME#1 = TNAME. Note that the owner of any DNAME is not a member of the SNAME list, but the "on-the-fly CNAME"'s owner is. (A knowledgeable resolver will discard the CNAME and regenerate it on its own as it that is needed it verify the on-the-fly one anyway, a check is then unnecessary.) The DNAME is only needed to validate the on-the-fly CNAME. 2) Determine if TNAME owns data requested and if the data is the result of a wild card synthesis. 3) Any NXT found in the answer section has no special meaning to DNS. Look at the authority section: 1) There will NEVER, NEVER, NEVER be more than two NXT's that are appropriate here. 2) If no wild card synthesized records appear in the answer section, there will NEVER be more than one NXT that is appropriate. 3) If there is a wild card synthesized record, then one NXT MUST span the penultimate SNAME in the list. I.e., the NXT's owner name < SNAME#n-1 < NXT's RDATA next name. 4) The (other) NXT that appears MUST be one of three: 4a) The NXT spans the TNAME - and NXDOMAIN is the return code and an AA bit of 1. 4b) The owner of the NXT is equal to the TNAME and demonstrates that QTYPE is absent with a return code of NOERROR and an AA bit of 1. (And that there is no data corresponding to TNAME, QTYPE in the answer section.) 4c) The owner of the NXT is an ancestor of QNAME and demonstrates that an NS is present at the owner name and that no DS is present - and AA bit is 0. (This is a referral or out-of-server CNAME.) 5) It is possible (common?) that no NXT appears. Any NXT appearing here that does not conform to the rules in 3 or 4 is an error, I would recommend that the reply message MUST be discarded and the resolver continue to wait for a "sane" response. Because of the "on-the-fly" CNAME, the DNAMEs in the answer section can be forgotten once the CNAME is validated. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Okay, okay, the previous sig wasn't all that good... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 8 13:19: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 NAA25742 for ; Sun, 8 Jun 2003 13:19:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19P3e6-000F9m-00 for namedroppers-data@psg.com; Sun, 08 Jun 2003 17:07:54 +0000 Received: from relay2.av8.net ([130.105.12.4] helo=citation.av8.net) by psg.com with esmtp (Exim 3.36 #1) id 19P3e1-000F9V-00 for namedroppers@ops.ietf.org; Sun, 08 Jun 2003 17:07:49 +0000 Received: from commander.av8.net (IDENT:dean@commander.av8.net [130.105.11.4]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA06711; Sun, 8 Jun 2003 12:57:01 -0400 Date: Sun, 8 Jun 2003 12:58:18 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@commander.av8.net To: namedroppers@ops.ietf.org cc: harald@alvestrand.no Subject: Complaint on Inappropriate behavior by the Namedroppers Administrator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.9 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT,RCVD_IN_NJABL, RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This message from Randy Bush is an ad hominem attack in violation of the IETF Code of Conduct (RFC 3184) and the ISOC Code of Conduct. The discussion in question arose from a bounce to email sent to the namedroppers list, for which a complaint was made to the namedroppers administrator. I would like to initiate a complaint about the namedroppers administrator. This is not the first complaint about inappropriate behavior. Several complaints from Dan Bernstein, myself, and others are well documented, and have been continuing despite attempts to modify this behavior. Thanks, Dean Anderson President, Av8 Internet, Inc ---------- Forwarded message ---------- Date: Sat, 7 Jun 2003 14:53:26 -0700 From: Randy Bush To: "Hallam-Baker, Phillip" Cc: 'Dean Anderson' , namedroppers@ops.ietf.org Subject: RE: RMX and IP hijacking > I followed up the URI listed in the bounce message. That is the reason it > gives for the listing. > > There is something wierd going on with that blacklist, one of their > blacklists is blacklisting my IP address 66.31.xx.xx for being 'in' > 127.0.0.10 / 32 > > I don't know if my IP is being blacklisted because their search algorithm is > broken or they use the notation /32 to mean 2^32 addresses rather than just > one. > > So is Dean still convinced that Spam is not a problem? this is not a dns protocol issue, and you are responding to a known troll. please take this off-list. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 8 20:21: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 UAA04439 for ; Sun, 8 Jun 2003 20:21:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PADo-000Ft0-00 for namedroppers-data@psg.com; Mon, 09 Jun 2003 00:09:12 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19PADl-000Fsm-00 for namedroppers@ops.ietf.org; Mon, 09 Jun 2003 00:09:09 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 245DC324; Sun, 8 Jun 2003 20:09:08 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id A8FF131E; Sun, 8 Jun 2003 20:09:07 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 370783; Sun, 08 Jun 2003 20:06:36 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <20030607052721.D8A4A18C6@thrintun.hactrn.net> References: <200306062350.h56NoXK2054933@drugs.dv.isc.org> <20030607052721.D8A4A18C6@thrintun.hactrn.net> Date: Sat, 7 Jun 2003 16:28:17 -0700 To: Rob Austein From: Edward Lewis Subject: Re: RFC 1035, section 3.3.1 Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,DATE_IN_PAST_24_48,EMAIL_ATTRIBUTION,IN_REP_TO, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is what I meant. I was trying some code, but with faulty data. The "logical" thing to me, as well as what the code did once the data was fixed was the same - the first SNAME is QNAME, the second SNAME would qualify as a wild card name. (3.3.1 has RDATA in the title, so maybe that's a trick question.) At 1:27 -0400 6/7/03, Rob Austein wrote: >Er, -which- DNS name in RFC 1035 3.3.1? Owner name or RDATA? > >IMIHO: yes, the DNS name in the RDATA can start with the label "*", >what happens is the same as always happens with CNAME processing (so >after hitting this CNAME doing an explict query for a name with "*" as >the first label, so no wildcard sythesis on this link in the CNAME >chain), and this is even more twisted than what Mark thought Ed meant. > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Okay, okay, the previous sig wasn't all that good... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 8 21:03: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 VAA05343 for ; Sun, 8 Jun 2003 21:03:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PAwN-000JVy-00 for namedroppers-data@psg.com; Mon, 09 Jun 2003 00:55:15 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19PAwK-000JVl-00 for namedroppers@ops.ietf.org; Mon, 09 Jun 2003 00:55:12 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id BAE8732F; Sun, 8 Jun 2003 20:55:11 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id EBA7027A; Sun, 8 Jun 2003 20:55:10 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 370898; Sun, 08 Jun 2003 20:52:39 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <200306061323.h56DNMK2050600@drugs.dv.isc.org> Date: Sun, 8 Jun 2003 17:42:05 -0700 To: Edward Lewis From: Edward Lewis Subject: Re: Q-10: Reaction to "Silly" NXT's Cc: Mark.Andrews@isc.org, "Olaf M. Kolkman" , edlewis@arin.net, derek@ihtfp.com, roy@logmess.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk What's below is wrong, close but wrong...I realized this changing planes in Atlanta. I forgot to account for the substitution of the last SNAME for the wild card in a synthesized record. What's needed is to first make the list of SNAMEs and then, if there is a wild card synthesized name, add the wild card name to the end of the SNAME list. Then, without a wild card synthesized record in the answer, then the only NXT will: 1) span the TNAME if NXDOMAIN and AA 2) be owned by the TNAME with NOERROR and AA to say the data is missing 3) be owned by the TNAME with NOERROR and AA=0 to say that the DS RR is absent (also - NS present, DS not present, ...) If there's a synthesized record, then there may be two (or one or zero) NXT's: 1) one nxt will span the penultimate name in SNAME plus wild card list 2) the other NXT will 2a) span the wild card domain name 2b) be synthesized from the wild card NXT 2c) be the ugly case - stating that a wild card owned delegation is unsecure. It's possible that the above can be done in just one NXT. Perhaps this isn't thought through well enough, maybe I need to talk through this live with someone. The upshot - I'd like to state the rules about how a resolver should interpret an NXT occurring in a message. At 19:24 -0700 6/6/03, Edward Lewis wrote: >I have to admit that my head hurts from recent travels and this thread. >Here is how I would summarize this, not to squash other's input, but to >allow others to check against what I am thinking. > >Look at the header: is the response code NXDOMAIN or NOERROR? Is the AA >bit set? > >Look at the answer section: this is a bit more convoluted > >1) Find the sequence of SNAME (search names) appearing in the answer >section. SNAME #1 ought to be QNAME. If there are multiple SNAMEs, >then the transition from SNAME #i to SNAME #i+1 has to occur via CNAMEs >or DNAMEs. In any case, we need to identify SNAME#n - which is the >last name searched. Let's call it TNAME. (QNAME and SNAME appear in >RFC 1034. Olafur and I agreed on TNAME.) > >It's common that QNAME = TNAME. > >If the QNAME != TNAME, there is a penultimate SNAME, SNAME#n-1, that is >significant if there are wild card synthesized answers. > >If the answer section is empty, there is no penultimate SNAME, QNAME = >SNAME#1 = TNAME. > >Note that the owner of any DNAME is not a member of the SNAME list, but >the "on-the-fly CNAME"'s owner is. (A knowledgeable resolver will >discard the CNAME and regenerate it on its own as it that is needed it >verify the on-the-fly one anyway, a check is then unnecessary.) The >DNAME is only needed to validate the on-the-fly CNAME. > >2) Determine if TNAME owns data requested and if the data is the result >of a wild card synthesis. > >3) Any NXT found in the answer section has no special meaning to DNS. > >Look at the authority section: > >1) There will NEVER, NEVER, NEVER be more than two NXT's that are >appropriate here. > >2) If no wild card synthesized records appear in the answer section, >there will NEVER be more than one NXT that is appropriate. > >3) If there is a wild card synthesized record, then one NXT MUST span >the penultimate SNAME in the list. I.e., the NXT's owner name < >SNAME#n-1 < NXT's RDATA next name. > >4) The (other) NXT that appears MUST be one of three: > >4a) The NXT spans the TNAME - and NXDOMAIN is the return code and an >AA bit of 1. > >4b) The owner of the NXT is equal to the TNAME and demonstrates that >QTYPE is absent with a return code of NOERROR and an AA bit of 1. (And >that there is no data corresponding to TNAME, QTYPE in the answer section.) > >4c) The owner of the NXT is an ancestor of QNAME and demonstrates that >an NS is present at the owner name and that no DS is present - and AA >bit is 0. (This is a referral or out-of-server CNAME.) > >5) It is possible (common?) that no NXT appears. > >Any NXT appearing here that does not conform to the rules in 3 or 4 >is an error, I would recommend that the reply message MUST be discarded >and the resolver continue to wait for a "sane" response. > >Because of the "on-the-fly" CNAME, the DNAMEs in the answer section can >be forgotten once the CNAME is validated. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Okay, okay, the previous sig wasn't all that good... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 8 22: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 WAA07568 for ; Sun, 8 Jun 2003 22:50:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PCeZ-0000Zp-00 for namedroppers-data@psg.com; Mon, 09 Jun 2003 02:44:59 +0000 Received: from zydeco.netbusters.com ([66.92.86.178]) by psg.com with esmtp (Exim 3.36 #1) id 19PCeV-0000ZQ-00 for namedroppers@ops.ietf.org; Mon, 09 Jun 2003 02:44:55 +0000 Received: by zydeco.netbusters.com (Postfix, from userid 513) id EEFA1B63B9; Mon, 9 Jun 2003 02:44:54 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id EC24F7EC1E; Sun, 8 Jun 2003 22:44:54 -0400 (EDT) Date: Sun, 8 Jun 2003 22:44:54 -0400 (EDT) From: Donald Eastlake 3rd X-X-Sender: dee3@zydeco.netbusters.com To: namedroppers@ops.ietf.org Cc: harald@alvestrand.no Subject: Re: Complaint on Inappropriate behavior by the Namedroppers Administrator In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-26.7 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 8 Jun 2003, Dean Anderson wrote: > Date: Sun, 8 Jun 2003 12:58:18 -0400 (EDT) > From: Dean Anderson > To: namedroppers@ops.ietf.org > Subject: Complaint on Inappropriate behavior by the Namedroppers > Administrator > > This message from Randy Bush is an ad hominem attack in violation of the > IETF Code of Conduct (RFC 3184) and the ISOC Code of Conduct. This is the IETF so ISOC rules, if any, are irrelevant. There is no IETF Code of Conduct. I know because I expected misuse of anything entitled a "Code of Conduct" no matter what the body of the document said. I had to argue very long and hard to have RFC 3184 called "IETF Guidelines for Conduct". "GUIDELINES" not "Code". They merely express what is desireable. No IETF Official is required to take any action for any "violation" of RFC 3184. > ... Donald ====================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA Donald.Eastlake@motorola.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 9 03:21: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 DAA23179 for ; Mon, 9 Jun 2003 03:21:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PGmA-000JZM-00 for namedroppers-data@psg.com; Mon, 09 Jun 2003 07:09:06 +0000 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19PGm7-000JZ0-00 for namedroppers@ops.ietf.org; Mon, 09 Jun 2003 07:09:03 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h596jRC09598 for ; Sun, 8 Jun 2003 23:45:27 -0700 Date: Sun, 8 Jun 2003 23:45:27 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 41: When Conflict Detection is Required Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_20,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 41 is enclosed below. The proposed fix is: In Section 4, change: "By default, a host SHOULD be configured to behave as though all RRs are UNIQUE. Uniqueness verification is carried out when the host: - starts up or - is configured to respond to the LLMNR queries on an interface or - is configured to respond to the LLMNR queries using additional UNIQUE resource records." To: "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)" ------------------------------------------------------------------------ Issue 41: When Conflict Detection is Required Submitter: Stuart Cheshire Submitter email address: Stuart.Cheshire@apple.com Date first submitted: May 25, 2003 Reference: Document: LLMNR-20 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: I would have thought it obvious that if a device is powered on without the cable attached, then performing probes without the cable connected is unlikely to yield any useful information, and consequently, when the cable is subsequently connected, any assumption that your name has been verified unique is completely baseless. However, this is evidently not obvious. So there is a need to be explicit about when conflict detection is done: * Upon reboot/startup * Upon wake from sleep (if network interface was inactive during sleep) * Upon bringing up previously inactive network interface * Upon Ethernet hardware link-state change that indicates a cable was attached. * Upon association with a wireless base station, etc. * (but NOT periodically as a matter of course) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 9 03:21: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 DAA23195 for ; Mon, 9 Jun 2003 03:21:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PGkH-000JTS-00 for namedroppers-data@psg.com; Mon, 09 Jun 2003 07:07:09 +0000 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19PGkD-000JTG-00 for namedroppers@ops.ietf.org; Mon, 09 Jun 2003 07:07:05 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h596hTU09400 for ; Sun, 8 Jun 2003 23:43:29 -0700 Date: Sun, 8 Jun 2003 23:43:28 -0700 (PDT) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 40: Admin intervention Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_20,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of Issue 40 is enclosed below. Here is the proposed fix: In Section 4, add after the last paragraph: "When name conflicts are detected, they SHOULD be logged. To detect duplicate use of a name, an administrator can use a name resolution utility which employs LLMNR and list both the responses and the responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure LLMNR responders who should not be configured to respond to the same name." --------------------------------------------- Issue 40: Administrative intervention Submitter: Erik Guttman Submitter email address: Erik.Guttman@sun.com Date first submitted: May 25, 2003 Reference: Document: LLMNR-20 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: I checked out llmnr-20. I like it except there is no mention I could find about administrative intervention. Something like "To detect duplicate use of a name, an administrator could use a name resolution utility which employs LLMNR and list both the responses and the responders. This would allow an administrator to diagnose behavior and potentially to intervene and reconfigure llmnr responders who should not be configured to respond with the same name." This heads off the complaint that dupes won't get detected at all. We can say sure they do - but by an administrator who cares and can intervene. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 9 12:37: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 MAA11135 for ; Mon, 9 Jun 2003 12:37:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PPT1-00051C-00 for namedroppers-data@psg.com; Mon, 09 Jun 2003 16:25:55 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19PPSu-00050O-00 for namedroppers@ops.ietf.org; Mon, 09 Jun 2003 16:25:48 +0000 Received: by sentry.rv.nailabs.com; id MAA23358; Mon, 9 Jun 2003 12:27:09 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma023344; Mon, 9 Jun 03 12:26:34 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6p2/8.11.6) with ESMTP id h59GP7p16848; Mon, 9 Jun 2003 12:25:07 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Mon, 9 Jun 2003 12:25:07 -0400 (EDT) From: Sam Weiler X-X-Sender: To: namedroppers cc: Scott Rose Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-16.9 required=5.0 tests=BAYES_01,IN_REP_TO,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Should the type code roll exclude SIG(0), leaving type 24 for SIG(0) use only? The current draft implies that SIG(0) changes too, but I've heard rumors of a desire to asign SIG(0) its own type code, and leaving it type 24 might accomplish that. Gating questions: are enough people using SIG(0) that breaking it would set back the protocol? Are there any technical issues with leaving it as is (an unrolled type 24 SIG) but rolling SIG for everything else? -- 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 Jun 9 18:48: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 SAA24558 for ; Mon, 9 Jun 2003 18:48:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PVFM-000NG9-00 for namedroppers-data@psg.com; Mon, 09 Jun 2003 22:36:12 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19PVFK-000NFr-00 for namedroppers@ops.ietf.org; Mon, 09 Jun 2003 22:36:10 +0000 Received: by sentry.rv.nailabs.com; id SAA01638; Mon, 9 Jun 2003 18:37:32 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma001615; Mon, 9 Jun 03 18:36:51 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6p2/8.11.6) with ESMTP id h59MZOJ06996 for ; Mon, 9 Jun 2003 18:35:24 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Mon, 9 Jun 2003 18:35:23 -0400 (EDT) From: Sam Weiler X-X-Sender: To: namedroppers Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-16.9 required=5.0 tests=BAYES_01,IN_REP_TO,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Another series of clarifications, this time re: the relationship of this document to draft-ietf-dnsext-unknown-rrs-05.txt Proposals: 1) Compression of domain names in RRSIGs and NSECs is prohibited. (The same update the unknown-rrs is making.) 2) DNSSEC canonical form and ordering: do the embedded domain names in NSECs and RRSIGs get downcased? I propose that they do -- if you understand DNSSEC, you can handle special processing for the new types. 3) Equality comparison. Here I'm not sure what to do. It looks like a case-sensitive comparison, as would be done for any unknown RR, is appropriate, but I'd like more guidance. -- 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 Jun 9 23:47: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 XAA29779 for ; Mon, 9 Jun 2003 23:47:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PZvS-000BY3-00 for namedroppers-data@psg.com; Tue, 10 Jun 2003 03:35:58 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19PZvQ-000BXg-00 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 03:35:56 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 73A3B44C; Mon, 9 Jun 2003 23:35:55 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id E041D447 for ; Mon, 9 Jun 2003 23:35:54 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 373118; Mon, 09 Jun 2003 23:33:18 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 (Unverified) Message-Id: Date: Mon, 9 Jun 2003 23:30:28 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: opcode value 2 Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.4 required=5.0 tests=BAYES_10,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Has anyone ever implemented OPCODE=STATUS? Does anyone know where it is specified - beyond section 3.8 of 1034? From rfc 1034: # 3.8. Status queries (Experimental) # # To be defined. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Okay, okay, the previous sig wasn't all that good... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 10 04:36: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 EAA17066 for ; Tue, 10 Jun 2003 04:36:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PeMo-000OS0-00 for namedroppers-data@psg.com; Tue, 10 Jun 2003 08:20:30 +0000 Received: from sa.vix.com ([204.152.187.1]) by psg.com with esmtp (Exim 3.36 #1) id 19PeMJ-000OPv-00 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 08:19:59 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 104EC1396C; Tue, 10 Jun 2003 08:19:46 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: opcode value 2 References: From: Paul Vixie Date: 10 Jun 2003 08:19:45 +0000 In-Reply-To: Message-ID: Lines: 13 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=-31.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Has anyone ever implemented OPCODE=STATUS? Does anyone know where it > is specified - beyond section 3.8 of 1034? In RFC833, opcode=2 was to mean CQUERYM. I think RFC1034's STATUS remains unspecified. A cautionary note to protocol tweakers... a DNS message can carry whatever you want it to, as long as it looks like a QUERY. The OPCODE field is not a discriminator. All messages regardless of opcode have four sections and those sections have things that look like RR's. In RFC2136 we found a way to carry updates in this format, and almost got away with making it look like it was supposed to be done this way all along. If someone wants to define STATUS, please be clever and find a use for all four "sections." -- 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: From owner-namedroppers@ops.ietf.org Tue Jun 10 04:48: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 EAA17308 for ; Tue, 10 Jun 2003 04:48:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Peg6-000PGe-00 for namedroppers-data@psg.com; Tue, 10 Jun 2003 08:40:26 +0000 Received: from ratree.psu.ac.th ([202.12.73.3]) by psg.com with esmtp (Exim 3.36 #1) id 19Pefw-000PE0-00 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 08:40:17 +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 h5A8dd211458; Tue, 10 Jun 2003 15:39:43 +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 h5A8cUo03941; Tue, 10 Jun 2003 15:38:36 +0700 (ICT) From: Robert Elz To: Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: opcode value 2 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Jun 2003 15:38:30 +0700 Message-ID: <4685.1055234310@munnari.OZ.AU> X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've never seen it implemented, or specified, anywhere. 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 Tue Jun 10 05:06: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 FAA17862 for ; Tue, 10 Jun 2003 05:06:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PezE-0000El-00 for namedroppers-data@psg.com; Tue, 10 Jun 2003 09:00:12 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19PezD-0000EY-00 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 09:00:11 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19PezC-0005z6-FF for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 18:00:10 +0900 Message-Id: <200306100457.h5A4vY120710@karoshi.com> In-Reply-To: from "Edward Lewis" at Jun 09, 2003 11:30:28 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bmanning@karoshi.com Subject: Re: opcode value 2 To: edlewis@arin.net (Edward Lewis) Date: Mon, 9 Jun 2003 21:57:34 -0700 (PDT) Cc: namedroppers@ops.ietf.org, edlewis@arin.net X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] there was some discussion, back in the day, and I think Daisy Chen used status for her load balancing code that IBM used. At least this has better docs than UINFO/GINFO rr types. > Has anyone ever implemented OPCODE=STATUS? Does anyone know where it > is specified - beyond section 3.8 of 1034? > > From rfc 1034: > # 3.8. Status queries (Experimental) > # > # To be defined. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > Okay, okay, the previous sig wasn't all that good... > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 10 05:18: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 FAA18189 for ; Tue, 10 Jun 2003 05:18:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PfAZ-0000pT-00 for namedroppers-data@psg.com; Tue, 10 Jun 2003 09:11:55 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19PfAW-0000nF-00 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 09:11:52 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HG8007FUXKIJ9@eListX.com> for namedroppers@ops.ietf.org; Mon, 09 Jun 2003 23:26:47 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h5A3M8NO010025; Mon, 09 Jun 2003 23:22:08 -0400 (EDT envelope-from ogud@ogud.com) Date: Mon, 09 Jun 2003 23:25:46 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt In-reply-to: X-Sender: post@localhost To: Sam Weiler , namedroppers Message-id: <5.1.1.6.2.20030609231147.02793510@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: X-Spam-Status: No, hits=-24.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:35 2003-06-09, Sam Weiler wrote: >Another series of clarifications, this time re: the relationship of >this document to draft-ietf-dnsext-unknown-rrs-05.txt > >Proposals: > >1) Compression of domain names in RRSIGs and NSECs is prohibited. >(The same update the unknown-rrs is making.) YES, YES, YES (did I mention that I hate RFC1035 name compression). >2) DNSSEC canonical form and ordering: do the embedded domain names in >NSECs and RRSIGs get downcased? I propose that they do -- if you >understand DNSSEC, you can handle special processing for the new >types. No, they should NOT get down cased, the ONLY reason for DNSSEC down casing, is the fact that name compression looses case. This goes into the category, no-new-special cases. For existing code this change causes little bit more changes in code than just copy the old code. For new code this simplifies things a lot. >3) Equality comparison. Here I'm not sure what to do. It looks like >a case-sensitive comparison, as would be done for any unknown RR, is >appropriate, but I'd like more guidance. See above, name compression is the reason for all these special cases. NSEC is a machine generated singleton so there is only one choice for order. RRSIG is machine generated and as a RRSIG is never[*] calculated over it order does not really matter, in any case given that the signers name starts in octet 18 is quite unlikely that the signers name is a tie breaker, and in any case the singers name should be the same in all the RRSIG in a set. [*] SIG(0) and TSIG are an exception, but in both cases the signature is over a message on the wire, and the order in each RRset does not matter. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 10 06:05: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 FAA18188 for ; Tue, 10 Jun 2003 05:18:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PfAX-0000pH-00 for namedroppers-data@psg.com; Tue, 10 Jun 2003 09:11:53 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19PfAS-0000nJ-00 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 09:11:48 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HG8007JPXSIMJ@eListX.com> for namedroppers@ops.ietf.org; Mon, 09 Jun 2003 23:31:31 -0400 (EDT) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3p2/8.12.3) with ESMTP id h5A3QwNO010041; Mon, 09 Jun 2003 23:26:59 -0400 (EDT envelope-from ogud@ogud.com) Date: Mon, 09 Jun 2003 23:30:37 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: draft-ietf-dnsext-dnssec-2535typecode-change-01.txt In-reply-to: X-Sender: post@localhost To: Sam Weiler , namedroppers Cc: Scott Rose Message-id: <5.1.1.6.2.20030609232710.0281fe70@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii References: X-Spam-Status: No, hits=-27.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 12:25 2003-06-09, Sam Weiler wrote: >Should the type code roll exclude SIG(0), leaving type 24 for SIG(0) >use only? The current draft implies that SIG(0) changes too, but I've >heard rumors of a desire to asign SIG(0) its own type code, and >leaving it type 24 might accomplish that. I personally think this is a good thing, SIG(0) had almost nothing to do with SIG(n) than the record format. Separating them is IMHO a good thing. If you change your draft to leave SIG(0) at 24 then there is no need for the other draft. >Gating questions: are enough people using SIG(0) that breaking it >would set back the protocol? Are there any technical issues with >leaving it as is (an unrolled type 24 SIG) but rolling SIG for >everything else? my guess is that right now SIG(0) is in more common use than DNSSEC :-) and there is no reason to break something that works. Olafur >-- 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 Jun 10 09:53: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 JAA00182 for ; Tue, 10 Jun 2003 09:53:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PjOT-000Byr-00 for namedroppers-data@psg.com; Tue, 10 Jun 2003 13:42:33 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19PjOR-000Byf-00 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 13:42:31 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id BA116362; Tue, 10 Jun 2003 09:42:30 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B01BE357 for ; Tue, 10 Jun 2003 09:42:29 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 374041; Tue, 10 Jun 2003 09:39:51 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Tue, 10 Jun 2003 09:35:34 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: NXT processing at resolvers, the anomalies... Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_20,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Probably the weakest link in the DNSSEC documentation has been on how a resolver and verifier need to work with the protocol. I've started in, part time now, on trying to clarify topics in this area. I've decided that the NXT is the first area that looks interesting to me. (As opposed to the area that needs the most work, etc.) This is a bit of the outgrowth of the wild card draft (the -00 WG version is being discussed by Bob and myself) and a bit of an outgrowth of the silly state thread. My approach is to walk through the traditional DNS message definitions and try to figure out how NXT's play a role and vice versa. The first stop is the OPCODE. So far OPCODE 0 is the query/response, including the "normal messages" as well as AXFR and IXFR. There's quite a bit of work to do here, especially with QR=1. OPCODE 1 has been deprecated, OPCODE 2 seems to have been a non-starter, or whatever happened died early on. OPCODE 3 is listed as reserved by IANA. OPCODE 4 is NOTIFY and OPCODE 5 is UPDATE. I plan to say that the presence of an NXT in OPCODE 1,2,3 are undefined as those messages ought not to be seen in the wild. I can't imagine a need to see an NXT in a NOTIFY message. Is there one? Ought it be outlawed? I also can't imagine a need to see an NXT in an UPDATE message. Same question here as before. What I am intending to state as an "error" reaction is that if an NXT seems out of place to the resolver, the resolver ought to cease processing on the message and discard it and return to the code point where new network input is retrieved. This is meant to counter act anyone inserting messages that are meant to confuse the resolver by throwing in malformed messages. This is a bit drastic in one sense. It means that if we decide later to define NXT's as being valid in NOTIFY or UPDATE, a resolver we define today will discard the message. On the other hand, this definition is safer and is crisper. Finally, one other question. Besides looking at OPCODE, it seems that the only times in which an NXT would appear in a message is when the RCODE is either NoError or NXDomain. FormErr, ServFail, NotImp, and Refused will cancel the regular processing earlier in the algorithm. All other RCODE's are associated with UPDATE, TSIG, TKEY, or EDNS0 - the latter three won't involve NXTs - I think. So - is it safe to assume that if RCODE != NoError or NXDomain, then an NXT is not supposed to be there? PS - When looking at this, assume you are only concerned with being the resolver. Don't wonder how the data got there, but that it's there and you have to figure out what it means. For now, I'm trying to throw away the non-sense cases - with OPCODE=0, QR=1, and RCODE=0 or 3, there's a lot of fun stuff to write. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Okay, okay, the previous sig wasn't all that good... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 10 10:34: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 KAA03242 for ; Tue, 10 Jun 2003 10:34:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Pk1j-000Dz1-00 for namedroppers-data@psg.com; Tue, 10 Jun 2003 14:23:07 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19Pk1h-000Dyp-00 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 14:23:05 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 6B5C2359; Tue, 10 Jun 2003 10:23:04 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 12F44352; Tue, 10 Jun 2003 10:23:04 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 374151; Tue, 10 Jun 2003 10:20:25 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 10 Jun 2003 10:22:59 -0400 To: Paul Vixie From: Edward Lewis Subject: Re: opcode value 2 Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:19 +0000 6/10/03, Paul Vixie wrote: >unspecified. A cautionary note to protocol tweakers... a DNS message can >carry whatever you want it to, as long as it looks like a QUERY. The OPCODE >field is not a discriminator. All messages regardless of opcode have four >sections and those sections have things that look like RR's. True. What I'm after is using the OPCODE to know how to interpret the data in the section. I.e., if an NXT in the second of the four sections means anything special. The header and the four sections are sacrosanct, just like the Q-trinity ought to be. (Thanks EDNS0 flags. ;)) Oh well, that ship has sailed. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Okay, okay, the previous sig wasn't all that good... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 10 11:41: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 LAA06003 for ; Tue, 10 Jun 2003 11:40:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Pl7Z-000HOc-00 for namedroppers-data@psg.com; Tue, 10 Jun 2003 15:33:13 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19Pl7X-000HOM-00 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 15:33:11 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 6BE631396C for ; Tue, 10 Jun 2003 15:32:58 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NXT processing at resolvers, the anomalies... In-Reply-To: Message from Edward Lewis of "Tue, 10 Jun 2003 09:35:34 -0400." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 10 Jun 2003 15:32:58 +0000 Message-Id: <20030610153258.6BE631396C@sa.vix.com> X-Spam-Status: No, hits=-9.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I plan to say that the presence of an NXT in OPCODE 1,2,3 are undefined as > those messages ought not to be seen in the wild. hmmmm. > I can't imagine a need to see an NXT in a NOTIFY message. Is there one? > Ought it be outlawed? the NOTIFY spec says the "answer" section only pertains to SOA "at this time" and i think that's all we need to (not) say about NXT. > I also can't imagine a need to see an NXT in an UPDATE message. Same > question here as before. i guess i can imagine an online signer that used UPDATE to put NXT RR's in. > What I am intending to state as an "error" reaction is that if an NXT seems > out of place to the resolver, the resolver ought to cease processing on the > message and discard it and return to the code point where new network input > is retrieved. This is meant to counter act anyone inserting messages that > are meant to confuse the resolver by throwing in malformed messages. > > This is a bit drastic in one sense. It means that if we decide later to > define NXT's as being valid in NOTIFY or UPDATE, a resolver we define today > will discard the message. On the other hand, this definition is safer and > is crisper. if someone puts an NXT into an UPDATE or NOTIFY (or QUERY with QR=0) then a receiver will either ignore it or FORMERR or act on later knowledge, all of which would be reasonable. i don't think we need to specify it directly. > Finally, one other question. Besides looking at OPCODE, it seems that the > only times in which an NXT would appear in a message is when the RCODE is > either NoError or NXDomain. FormErr, ServFail, NotImp, and Refused will > cancel the regular processing earlier in the algorithm. All other RCODE's > are associated with UPDATE, TSIG, TKEY, or EDNS0 - the latter three won't > involve NXTs - I think. So - is it safe to assume that if RCODE != NoError > or NXDomain, then an NXT is not supposed to be there? for QUERY with QR=1 where NXT is actually specified, yes, those other bit patterns would be invalid. > PS - When looking at this, assume you are only concerned with being the > resolver. Don't wonder how the data got there, but that it's there and you > have to figure out what it means. For now, I'm trying to throw away the > non-sense cases - with OPCODE=0, QR=1, and RCODE=0 or 3, there's a lot of > fun stuff to write. i think that going at this from the OPCODE standpoint isn't useful. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 10 22:47: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 WAA27259 for ; Tue, 10 Jun 2003 22:47:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PvSw-0000A7-00 for namedroppers-data@psg.com; Wed, 11 Jun 2003 02:35:58 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19PvSt-00009t-00 for namedroppers@ops.ietf.org; Wed, 11 Jun 2003 02:35:56 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 1807E372; Tue, 10 Jun 2003 22:35:55 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id B66E9355 for ; Tue, 10 Jun 2003 22:35:54 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 375910 for namedroppers@ops.ietf.org; Tue, 10 Jun 2003 22:33:13 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030610153258.6BE631396C@sa.vix.com> References: <20030610153258.6BE631396C@sa.vix.com> Date: Tue, 10 Jun 2003 22:35:50 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: NXT processing at resolvers, the anomalies... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:32 +0000 6/10/03, Paul Vixie wrote: >i think that going at this from the OPCODE standpoint isn't useful. Well, the OPCODE tells how to interpret the message - i.e., instead of question, answer, authority and additional, an UPDATE is zone, prereq, update, additional. NXT's in the authority mean something, in update they are just data. In NOTIFY, there's nothing special about NXT's. That's as far as I'd go. Would it be safe to say that the only special processing we need to be concerned with is if the NXT is in the authority section of a QUERY? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Okay, okay, the previous sig wasn't all that good... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 10 23:38: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 XAA28135 for ; Tue, 10 Jun 2003 23:38:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19PwKl-0002xC-00 for namedroppers-data@psg.com; Wed, 11 Jun 2003 03:31:35 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19PwKj-0002wc-00 for namedroppers@ops.ietf.org; Wed, 11 Jun 2003 03:31:33 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id DC8331396A for ; Wed, 11 Jun 2003 03:31:20 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: NXT processing at resolvers, the anomalies... In-Reply-To: Message from Edward Lewis of "Tue, 10 Jun 2003 22:35:50 -0400." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 11 Jun 2003 03:31:20 +0000 Message-Id: <20030611033120.DC8331396A@sa.vix.com> X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Would it be safe to say that the only special processing we need to be > concerned with is if the NXT is in the authority section of a QUERY? yes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 11 08:03: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 IAA04266 for ; Wed, 11 Jun 2003 08:03:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Q4B7-000Nrj-00 for namedroppers-data@psg.com; Wed, 11 Jun 2003 11:54:09 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19Q4B4-000NrX-00 for namedroppers@ops.ietf.org; Wed, 11 Jun 2003 11:54:06 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03707; Wed, 11 Jun 2003 07:54:04 -0400 (EDT) Message-Id: <200306111154.HAA03707@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-21.txt Date: Wed, 11 Jun 2003 07:54:04 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-21.txt Pages : 21 Date : 2003-6-10 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name Service (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-21.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-21.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-21.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-6-10110848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-10110848.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 13 19:27: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 TAA28347 for ; Fri, 13 Jun 2003 19:27:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Qxc6-0003TJ-00 for namedroppers-data@psg.com; Fri, 13 Jun 2003 23:05:42 +0000 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 19Qxc2-0003T4-00 for namedroppers@ops.ietf.org; Fri, 13 Jun 2003 23:05:39 +0000 Received: from esunmail ([129.147.58.120]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h5DN5cht002753 for ; Fri, 13 Jun 2003 17:05:38 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HGG001E905DXW@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Fri, 13 Jun 2003 17:05:38 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HGG003J705C3H@mail.sun.net> for namedroppers@ops.ietf.org; Fri, 13 Jun 2003 17:05:37 -0600 (MDT) Date: Fri, 13 Jun 2003 16:07:29 -0700 From: Alain Durand Subject: Re: I-D ACTION:draft-ietf-dnsext-mdns-21.txt In-reply-to: <200306111154.HAA03707@ietf.org> To: aboba@internaut.com Cc: namedroppers@ops.ietf.org, Michael.Hunter@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT This might have been previously discussed, but: > In composing LLMNR queries, the sender MUST set the Hop Limit field in > the IPv6 header and the TTL field in IPv4 header of the response to one > (1). Even when LLMNR queries are sent to a link-scope multicast > address, it is possible that some routers may not properly implement > link-scope multicast, or that link-scope multicast addresses may leak > into the multicast routing system. Therefore setting the IPv6 Hop Limit > or IPv4 TTL field to one provides an additional precaution against > leakage of LLMNR queries. > > In composing a response to an LLMNR query, the responder MUST set the > Hop Limit field in the IPv6 header and the TTL field in IPv4 header of > the response to one (1). This is done so as to prevent the use of LLMNR > for denial of service attacks across the Internet. ==> this is different from Neighbor Discovery which require to set the hop-count to 255. Is there a good enough reason not to use the same algorithm here? Also, I'm a bit confused on http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html where issue #2 says to use TTL=255 and issue #35 says to use TTL=1..... - Alain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 14 01:21: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 BAA06869 for ; Sat, 14 Jun 2003 01:21:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19R3HT-000Feq-00 for namedroppers-data@psg.com; Sat, 14 Jun 2003 05:08:47 +0000 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by psg.com with esmtp (Exim 3.36 #1) id 19R3HQ-000FeK-00 for namedroppers@ops.ietf.org; Sat, 14 Jun 2003 05:08:44 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h5E4icE18226; Fri, 13 Jun 2003 21:44:38 -0700 Date: Fri, 13 Jun 2003 21:44:38 -0700 (PDT) From: Bernard Aboba To: Alain Durand cc: namedroppers@ops.ietf.org, Michael.Hunter@Sun.COM Subject: Re: I-D ACTION:draft-ietf-dnsext-mdns-21.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ==> this is different from Neighbor Discovery which require to set the > hop-count to 255. Is there a good enough reason not to use the same > algorithm here? The IPv4 LL draft now uses TTL=1. Where TCP is used for a query (recommended for unicast), setting TTL=1 makes it difficult to spoof a response, due to the three way handshake. Setting TTL=1 in responses (UDP or TCP) ensures that a multicast LLMNR query can't be used for a DoS attack against a victim on another LAN. Setting TTL=255 doesn't accomplish this. The remaining case is a multicast query answered with a UDP response. Here it would be possible for the response to be spoofed with TTL=1 but not TTL=255 (with check). But the DoS prevention benefits were judged to overide this. > Also, I'm a bit confused on > http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > where issue #2 says to use TTL=255 and issue #35 says to use TTL=1..... Different Issues filed by different individuals with different points of view :) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 16 10:32: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 KAA16173 for ; Mon, 16 Jun 2003 10:32:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19RumJ-0009Qj-00 for namedroppers-data@psg.com; Mon, 16 Jun 2003 14:16:11 +0000 Received: from smtp2.arin.net ([192.149.252.32]) by psg.com with esmtp (Exim 3.36 #1) id 19RumH-0009QV-00 for namedroppers@ops.ietf.org; Mon, 16 Jun 2003 14:16:09 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 24D5C33F; Mon, 16 Jun 2003 10:16:08 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id A97EF31A for ; Mon, 16 Jun 2003 10:16:07 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 400428; Mon, 16 Jun 2003 10:13:00 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Mon, 16 Jun 2003 10:16:06 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wild cards and NS's Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-0.6 required=5.0 tests=SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'm writing up some more text for the wild card draft and am stuck on something. As background, a few of us talked about wild card CNAMEs and concluded that because of the text in 4.3.2c and then looking at 4.3.2a, these things are useless. Besides strengthening that a wild card-CNAME doesn't continue the search and is only returned when asked for directly, we added a SHOULD saying that a server ought to complain (refuse to load) when seeing a '* CNAME' in the input. When it comes to NS's though, it's not so clearly cut that this is a "bad thing" (tm). I can't bring myself to record the same bad words for NS's that I did for CNAME's, no matter how evil NS's at * might seem to be. I'm likely to add text explaining why only wayward youth would want to have * NS, but then explain how it could be pulled off. As I'm (one of the) editor(s) of this text, I'd like to get folks to make statements on this that I could then plagiarize for the document. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 16 23:15: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 XAA14236 for ; Mon, 16 Jun 2003 23:15:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19S6oB-000C3R-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 03:06:55 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19S6o8-000C3D-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 03:06:53 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 494B53BB; Mon, 16 Jun 2003 23:06:52 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id CCFD93A4 for ; Mon, 16 Jun 2003 23:06:51 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 402130; Mon, 16 Jun 2003 23:03:42 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Mon, 16 Jun 2003 23:06:43 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: question regarding wildcards and 2672 Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk With a light bulb supplied by Mark Andrews, in the never ending effort to clarify wild cards... In RFC 2672, section 4.1: # c. If at some label, a match is impossible (i.e., the # corresponding label does not exist), look to see whether the # last label matched has a DNAME record. # # If a DNAME record exists at that point, ... SHOULD synthesize a # CNAME record ... Go back to step 1. # ... # # If the "*" label does exist, match RRs at that node against # QTYPE. If any match, copy them into the answer section, but # set the owner of the RR to be QNAME, and not the node with the # "*" label. Go to step 6. There's a problem with this. Let's say an authoritative server has '*.example. DNAME example.org.' in a zone. ACT I: Cache issues a query for '1.2.example. DNAME IN' and gets the synthesized answer. Cache is then asked for '0.1.2.example. A IN' ACT II: Cache issues a query for '2.example. DNAME IN' and gets the synthesized answer. Cache is then asked for '0.1.2.example. A IN' (same query as in ACT I). In ACT I, the response will include: 0.1.2.example. CNAME 0.example.org. In ACT II, the response to the SAME query will include: 0.1.2.example. CNAME 0.1.example.org. Note that the first query changes what the second query gets. (And unlike the ANY situation, the two answers are incoherent.) One reason for the problem is that a wild card is allowed to own a DNAME record. Another reason for the problem is that there is no restriction on how many labels a wild card domain matches. How do people feel about barring DNAME records at wild cards? How do people feel about limiting the DNAME to matching just one label? (I.e., In ACT I, the reply to '1.2.example. DNAME IN' would be: 2.example. DNAME example.org. 1.2.example. CNAME 1.example.org) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 16 23:19: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 XAA14510 for ; Mon, 16 Jun 2003 23:19:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19S6tu-000CDP-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 03:12:50 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19S6tt-000CDD-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 03:12:49 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 921413BB; Mon, 16 Jun 2003 23:12:48 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 4062B394 for ; Mon, 16 Jun 2003 23:12:48 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 402137; Mon, 16 Jun 2003 23:09:38 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Mon, 16 Jun 2003 23:09:27 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wild card draft coming Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.0 required=5.0 tests=BAYES_30,OPT_IN,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The wild card clarify draft will go into the ID system soon. It will leave hanging a few issues for now, but we want to get some review on what's there: 1) * CNAME 2) * NS 3) * DNAME (you have a question before you 4) removal of opt-in language 5) clean up of text 6) a 'recipe' summing up the proof There will be suggestions for the above appearing in the coming days. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 03:06:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01456 for ; Tue, 17 Jun 2003 03:06:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SAKj-000Jp1-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 06:52:45 +0000 Received: from c17200.carlnfd2.nsw.optusnet.com.au ([211.29.163.60] helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19SAKg-000Jop-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 06:52:42 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h5H6qF6A038010; Tue, 17 Jun 2003 16:52:16 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306170652.h5H6qF6A038010@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: question regarding wildcards and 2672 In-reply-to: Your message of "Mon, 16 Jun 2003 23:06:43 -0400." Date: Tue, 17 Jun 2003 16:52:15 +1000 X-Spam-Status: No, hits=-7.0 required=5.0 tests=BAYES_30,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > With a light bulb supplied by Mark Andrews, in the never ending > effort to clarify wild cards... > > In RFC 2672, section 4.1: > > # c. If at some label, a match is impossible (i.e., the > # corresponding label does not exist), look to see whether the > # last label matched has a DNAME record. > # > # If a DNAME record exists at that point, ... SHOULD synthesize a > # CNAME record ... Go back to step 1. > # > ... > # > # If the "*" label does exist, match RRs at that node against > # QTYPE. If any match, copy them into the answer section, but > # set the owner of the RR to be QNAME, and not the node with the > # "*" label. Go to step 6. > > There's a problem with this. > > Let's say an authoritative server has '*.example. DNAME example.org.' > in a zone. > > ACT I: > > Cache issues a query for '1.2.example. DNAME IN' and gets the > synthesized answer. Cache is then asked for '0.1.2.example. A IN' > > ACT II: > > Cache issues a query for '2.example. DNAME IN' and gets the > synthesized answer. Cache is then asked for '0.1.2.example. A IN' > (same query as in ACT I). > > In ACT I, the response will include: > > 0.1.2.example. CNAME 0.example.org. > > In ACT II, the response to the SAME query will include: > > 0.1.2.example. CNAME 0.1.example.org. > > Note that the first query changes what the second query gets. (And > unlike the ANY situation, the two answers are incoherent.) > > One reason for the problem is that a wild card is allowed to own a > DNAME record. > Another reason for the problem is that there is no restriction on how > many labels a wild card domain matches. > > How do people feel about barring DNAME records at wild cards? This would be my preferred option. > How do people feel about limiting the DNAME to matching just one label? > (I.e., In ACT I, the reply to '1.2.example. DNAME IN' would be: > 2.example. DNAME example.org. > 1.2.example. CNAME 1.example.org) Note the presence of a DNAME would cause all other type to also match just one label otherwise you get inconsistant answers. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > ...as graceful as a blindfolded bull in a china shop... > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 08:08: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 IAA09067 for ; Tue, 17 Jun 2003 08:08:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SF5O-0003GK-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 11:57:14 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19SF5M-0003G8-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 11:57: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 HAA08425; Tue, 17 Jun 2003 07:57:11 -0400 (EDT) Message-Id: <200306171157.HAA08425@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-stjohns-secure-notify-00.txt Date: Tue, 17 Jun 2003 07:57:10 -0400 X-Spam-Status: No, hits=1.5 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using DNSSEC-secured NOTIFY to Trigger Parent Zone Updating Author(s) : M. StJohns Filename : draft-stjohns-secure-notify-00.txt Pages : 10 Date : 2003-6-16 This document describes an extension or revision to the DNS NOTIFY mechanism which would allow a child zone to securely notify a parent zone of the need to update records that appear in the parent zone, but are related to records in the child zone. At this time, the two resource record types are the NS or Name Server record, and the DS or Delegation Signer record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stjohns-secure-notify-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stjohns-secure-notify-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-stjohns-secure-notify-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stjohns-secure-notify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-stjohns-secure-notify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075411.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 09:26: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 JAA14342 for ; Tue, 17 Jun 2003 09:26:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SGHI-0005qA-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 13:13:36 +0000 Received: from one.elistx.com ([209.116.252.130]) by psg.com with esmtp (Exim 3.36 #1) id 19SGHD-0005pT-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 13:13:31 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HGM00780NFUA1@eListX.com> for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 09:14:20 -0400 (EDT) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h5HDDb9O014745; Tue, 17 Jun 2003 09:13:37 -0400 (EDT envelope-from ogud@ogud.com) Date: Tue, 17 Jun 2003 09:13:11 -0400 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: question regarding wildcards and 2672 In-reply-to: X-Sender: post@localhost To: Edward Lewis , namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030617090055.00b78b88@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=-10.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_RFCI autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 23:06 2003-06-16, Edward Lewis wrote: >With a light bulb supplied by Mark Andrews, in the never ending effort to >clarify wild cards... >One reason for the problem is that a wild card is allowed to own a DNAME >record. >Another reason for the problem is that there is no restriction on how many >labels a wild card domain matches. > >How do people feel about barring DNAME records at wild cards? >How do people feel about limiting the DNAME to matching just one label? >(I.e., In ACT I, the reply to '1.2.example. DNAME IN' would be: > 2.example. DNAME example.org. > 1.2.example. CNAME 1.example.org) As DNAME is a "zone terminator" it just feels wrong that wildcard DNAME can be expanded more than one label, and in my mind should not be allowed. Having said that, I do not think the wildcard clarify document should spend much time on updating a experimental RFC. Having said that I think wildcard [CD]NAME is bogus and was not indented in RFC103[45], but in the case of CNAME the genie is out of the bottle. I think the "right thing to do" for the wildcard clarify document, is to put in a strongly worded warning that wildcard DNAME leads to unintended and strange results. Thus is it strongly discouraged. Of course I realize this will leave us in the same position as with with multiple CNAME RRs in a set, someone will find use and refuse to give it up when shown the documents, because it works. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 09:52:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15866 for ; Tue, 17 Jun 2003 09:52:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SGnM-0006yF-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 13:46:44 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19SGnJ-0006xx-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 13:46:41 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id EE46935E; Tue, 17 Jun 2003 09:46:40 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 802BA320; Tue, 17 Jun 2003 09:46:40 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 403048; Tue, 17 Jun 2003 09:43:28 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <5.1.1.6.2.20030617090055.00b78b88@localhost> References: <5.1.1.6.2.20030617090055.00b78b88@localhost> Date: Tue, 17 Jun 2003 09:46:35 -0400 To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= From: Edward Lewis Subject: Re: question regarding wildcards and 2672 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15866 At 9:13 -0400 6/17/03, Ólafur Guðmundsson wrote: >Having said that, I do not think the wildcard clarify document should spend >much time on updating a experimental RFC. What's intended are paragraphs on what are apparently the three resource records (known to date) that have an impact on wild cards. The three are NS, CNAME, and DNAME. (As a measure of the need to document something - a few of us have spent a couple of on-line hours in the past week discussing DNAME. When a topic takes so much time among folks that know DNS, you know it needs some deeper documenting.) The DNAME paragraph in the wild card clarify document will be the shortest of the three - for one thing, DNAME is experimental. I think it's important to place the text in the wild card draft as I don't think anyone is currently editing a follow-on to DNAME. (2026 makes no statement about the need to review experimental rfcs, unlike standards track rfcs.) >Having said that I think wildcard [CD]NAME is bogus and was not indented >in RFC103[45], but in the case of CNAME the genie is out of the bottle. > >I think the "right thing to do" for the wildcard clarify document, >is to put in a strongly worded warning that wildcard DNAME leads to >unintended and strange results. Thus is it strongly discouraged. >Of course I realize this will leave us in the same position as with >with multiple CNAME RRs in a set, someone will find use and refuse to >give it up when shown the documents, because it works. Perhaps there will be a catch all requirement like - any RR defined (from here on out) MUST describe how it is handled if it is owned by a wild card domain name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 10:06: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 KAA16820 for ; Tue, 17 Jun 2003 10:06:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SH0R-0007Us-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 14:00:15 +0000 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 19SH0P-0007Ua-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 14:00:13 +0000 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id EF241137F05; Tue, 17 Jun 2003 07:00:10 -0700 (PDT) To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: question regarding wildcards and 2672 In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= of "Tue, 17 Jun 2003 09:13:11 EDT." <5.1.1.6.2.20030617090055.00b78b88@localhost> Date: Tue, 17 Jun 2003 07:00:10 -0700 Message-ID: <49553.1055858410@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> As DNAME is a "zone terminator" it just feels wrong that >> wildcard DNAME can be expanded more than one label, and in my >> mind should not be allowed. Having said that, I do not think >> the wildcard clarify document should spend much time on >> updating a experimental RFC. If we accept wildcard DNAMEs are just too awful, it should be OK for the document to say something like: "wildcard DNAMEs are forbidden". Either as a general rule or in the specific case of DNSSEC. >> Having said that I think wildcard [CD]NAME is bogus and was not >> indented in RFC103[45], but in the case of CNAME the genie is >> out of the bottle. True, but let's not provide another bottle for another genie. There's not much use of DNAME yet so this particular stable door could get closed before the horse has bolted. Apologies for the mixed metaphors. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 10:08:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17153 for ; Tue, 17 Jun 2003 10:08:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SH4E-0007g0-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 14:04:10 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19SH4C-0007fo-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 14:04:08 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19SH4B-000Kxx-Ky; Tue, 17 Jun 2003 07:04:07 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Jun 2003 07:04:06 -0700 To: Edward Lewis Cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: question regarding wildcards and 2672 References: <5.1.1.6.2.20030617090055.00b78b88@localhost> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Having said that, I do not think the wildcard clarify document >> should spend much time on updating a experimental RFC. > What's intended are paragraphs on what are apparently the three > resource records (known to date) that have an impact on wild > cards. The three are NS, CNAME, and DNAME. and, if there are any complications solely for the experimental DNAME RR, then do not complicate. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 10:08:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17179 for ; Tue, 17 Jun 2003 10:08:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SH3t-0007fa-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 14:03:49 +0000 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 19SH3q-0007fE-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 14:03:46 +0000 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h5HE3hI24889; Tue, 17 Jun 2003 07:03:43 -0700 (PDT) From: Bill Manning Message-Id: <200306171403.h5HE3hI24889@boreas.isi.edu> Subject: Re: question regarding wildcards and 2672 In-Reply-To: from Edward Lewis at "Jun 17, 3 09:46:35 am" To: edlewis@arin.net (Edward Lewis) Date: Tue, 17 Jun 2003 07:03:43 -0700 (PDT) Cc: ogud@ogud.com, edlewis@arin.net, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % What's intended are paragraphs on what are apparently the three % resource records (known to date) that have an impact on wild cards. % The three are NS, CNAME, and DNAME. what! no SOA? % Perhaps there will be a catch all requirement like - any RR defined % (from here on out) MUST describe how it is handled if it is owned by % a wild card domain name. amen. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 10:29:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19435 for ; Tue, 17 Jun 2003 10:29:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SHKn-0008Ph-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 14:21:17 +0000 Received: from c17200.carlnfd2.nsw.optusnet.com.au ([211.29.163.60] helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19SHKk-0008PV-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 14:21:14 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h5HEKV6A039025; Wed, 18 Jun 2003 00:20:31 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306171420.h5HEKV6A039025@drugs.dv.isc.org> To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: question regarding wildcards and 2672 In-reply-to: Your message of "Tue, 17 Jun 2003 09:13:11 -0400." <5.1.1.6.2.20030617090055.00b78b88@localhost> Date: Wed, 18 Jun 2003 00:20:31 +1000 X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 23:06 2003-06-16, Edward Lewis wrote: > >With a light bulb supplied by Mark Andrews, in the never ending effort to > >clarify wild cards... > > > > > >One reason for the problem is that a wild card is allowed to own a DNAME > >record. > >Another reason for the problem is that there is no restriction on how many > >labels a wild card domain matches. > > > >How do people feel about barring DNAME records at wild cards? > >How do people feel about limiting the DNAME to matching just one label? > >(I.e., In ACT I, the reply to '1.2.example. DNAME IN' would be: > > 2.example. DNAME example.org. > > 1.2.example. CNAME 1.example.org) > > > As DNAME is a "zone terminator" it just feels wrong that wildcard DNAME > can be expanded more than one label, and in my mind should not be allowed. > Having said that, I do not think the wildcard clarify document should spend > much time on updating a experimental RFC. Network Working Group M. Crawford Request for Comments: 2672 Fermilab Category: Standards Track August 1999 Please cite the RFC that moves DNAME to experimental. Note it is *not* RFC 3363. Plain DNAMEs provide a useful tool. Wildcard DNAMEs on the other hand I have a hard time trying to envision a sensible use for them even with single label expansion. > Having said that I think wildcard [CD]NAME is bogus and was not indented > in RFC103[45], but in the case of CNAME the genie is out of the bottle. I agree that wildcard CNAMEs are out of the bottle and the algorithm should be updated to make it clear that they should be returned even when the QTYPE does not match and be followed if appropriate. > I think the "right thing to do" for the wildcard clarify document, > is to put in a strongly worded warning that wildcard DNAME leads to > unintended and strange results. Thus is it strongly discouraged. > Of course I realize this will leave us in the same position as with > with multiple CNAME RRs in a set, someone will find use and refuse to > give it up when shown the documents, because it works. > > Olafur > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 12:34: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 MAA25612 for ; Tue, 17 Jun 2003 12:34:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SJDm-000DJ6-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 16:22:10 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 19SJDj-000DIE-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 16:22:07 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8EDBD1396A for ; Tue, 17 Jun 2003 16:21:54 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: question regarding wildcards and 2672 In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= of "Tue, 17 Jun 2003 09:13:11 -0400." <5.1.1.6.2.20030617090055.00b78b88@localhost> X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 17 Jun 2003 16:21:54 +0000 Message-Id: <20030617162154.8EDBD1396A@sa.vix.com> X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >How do people feel about barring DNAME records at wild cards? i think this is the right thing. > ... > As DNAME is a "zone terminator" it's not, though. see isc-tn-2002-1.txt (at www.isc.org/tn) for an example of "DNAME and other data" all at the apex of a zone. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 13:17: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 NAA27022 for ; Tue, 17 Jun 2003 13:17:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SJx8-000FH0-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 17:09:02 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19SJx2-000FGe-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 17:08:56 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id A9386316; Tue, 17 Jun 2003 13:08:55 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 53E5A3BE; Tue, 17 Jun 2003 13:08:55 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 403780; Tue, 17 Jun 2003 13:05:42 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200306171403.h5HE3hI24889@boreas.isi.edu> References: <200306171403.h5HE3hI24889@boreas.isi.edu> Date: Tue, 17 Jun 2003 11:52:19 -0400 To: Bill Manning From: Edward Lewis Subject: Re: question regarding wildcards and 2672 Cc: edlewis@arin.net (Edward Lewis), ogud@ogud.com, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:03 -0700 6/17/03, Bill Manning wrote: >% What's intended are paragraphs on what are apparently the three >% resource records (known to date) that have an impact on wild cards. >% The three are NS, CNAME, and DNAME. > > what! no SOA? No - the SOA is already restricted to the apex, so far as I know. So, unless you do something stooopid like have a zone that starts with a "*." name - Umm, wait, perhaps there ought to be text covering that. I ain't naming names. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 13:51: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 NAA28034 for ; Tue, 17 Jun 2003 13:51:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SKTd-000GdU-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 17:42:37 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19SKTa-000GdD-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 17:42:34 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id C013C38A; Tue, 17 Jun 2003 13:42:33 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 6E3C5356; Tue, 17 Jun 2003 13:42:33 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 403904; Tue, 17 Jun 2003 13:39:21 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200306171420.h5HEKV6A039025@drugs.dv.isc.org> References: <200306171420.h5HEKV6A039025@drugs.dv.isc.org> Date: Tue, 17 Jun 2003 13:13:56 -0400 To: Mark.Andrews@isc.org From: Edward Lewis Subject: Re: question regarding wildcards and 2672 Cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 0:20 +1000 6/18/03, Mark.Andrews@isc.org wrote: >Network Working Group M. Crawford >Request for Comments: 2672 Fermilab >Category: Standards Track August 1999 > > Please cite the RFC that moves DNAME to experimental. Note > it is *not* RFC 3363. I missed that. I thought DNAME was experimental. So DNAME is another standards document that is falling through the cracks. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 15:34: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 PAA06484 for ; Tue, 17 Jun 2003 15:34:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SM6s-000LQa-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 19:27:14 +0000 Received: from ran.psg.com ([209.20.253.166]) by psg.com with esmtp (Exim 3.36 #1) id 19SM6p-000LQM-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 19:27:11 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19SM6o-0003nn-VT for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 12:27:11 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Jun 2003 12:27:10 -0700 To: namedroppers Subject: need to update opt-in to info Message-Id: X-Spam-Status: No, hits=1.6 required=5.0 tests=BAYES_30,OPT_IN,SEARCH_ENGINE_PROMO version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit this message is a follow-up to the messages that summarized the result of wg last call for opt-in. see http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01007.html http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01129.html to execute the plan outlined in the message above, the chairs in coordination with the area director have agreed on the following actions: 1. create an opt-in-05 document updated in the following manner: 1.1 with the following paragraph at the beginning of introduction section This document archives a proposed protocol extension to DNSSEC [normative ref to 2535bis] which was reviewed in the IETF, but the IETF decided not to adopt this a part of the DNSsec standard. Implementation of this specification is therefor not recommended. 1.2 add a normative reference to rfc2535bis, the records and protocol documents. 2. then the chairs will ask the area directors to ask the iesg to publish the document as informational 3. the iesg will forward the document to rfc editor, where it will wait for the rfc2535bis documents to be published. so this message is a request to the document editors to apply the changes above and submit the revised document to the internet-drafts directory. thank you. randy & Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 16:03: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 QAA08258 for ; Tue, 17 Jun 2003 16:03:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SMUU-000MXv-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 19:51:38 +0000 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 19SMUS-000MXj-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 19:51:36 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 1AD86414; Tue, 17 Jun 2003 15:51:36 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id A171043B for ; Tue, 17 Jun 2003 15:51:35 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 404290; Tue, 17 Jun 2003 15:48:22 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Tue, 17 Jun 2003 15:51:25 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wild cards, CNAMEs and 1034's 4.3.2 Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.4 required=5.0 tests=BAYES_10,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The second of three records that have come under question in looking at wild cards are CNAME's. (A DNAME is just a CNAME synthesizer, I've already asked about them.) When noodling over the server algorithm in 1034's 4.3.2, in step 3 we come to three steps - a,b and c. In step 'a' exact matches (QNAME) are considered. If the matching name owns a CNAME, the CNAME is followed. The outcome of this step is either an answer or a CNAME referral. In step 'b' zone cuts are considered. All that is returned here are NS referrals. In step 'c' wild card synthesis is considered. (DNAME's definition extends what's in this step.) If the QNAME can be matched by a wild card domain name, an answer is synthesized at this step. In staring at step c, and looking at some implementations, it seems that step c could allow for '* CNAME' as having the same impact as 'QNAME CNAME' does in step 'a'. Now, purity to 1034 would say no, stop the search once we hit the wild card as the source of the answer. But some are suggesting that we follow the CNAME. If we follow the CNAME at a wild card, this would change the rule of having no more than 2 NXT's in a secured answer. We'd have one NXT for each wild card matched, which maybe a string of '* CNAMEs'. Here is what one person suggested for step c: If the "*" label does exist, look for a CNAME at that node. If found and QTYPE doesn't match CNAME, copy the CNAME RR into the answer section of the response, using QNAME as the owner name, and then change QNAME to the canonical name in the CNAME RR, and go back to step 1. Otherwise, match RRs at the node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label. Go to step 6. Any thoughts on this? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 16:08: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 QAA08564 for ; Tue, 17 Jun 2003 16:08:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SMeH-000Myh-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 20:01:45 +0000 Received: from pushme.nist.gov ([129.6.16.92] helo=postmark.nist.gov) by psg.com with esmtp (Exim 3.36 #1) id 19SMeD-000Mxv-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 20:01:41 +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 h5HK1Cbd014420 for ; Tue, 17 Jun 2003 16:01:12 -0400 (EDT) Message-ID: <002301c3350b$34c60190$b9370681@barnacle> From: "Scott Rose" To: Subject: Keeping the KEY and SIG typecodes active Date: Tue, 17 Jun 2003 16:01:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Not given a DNSSECbis Question number, as it isn't a DNSSEC question per se. This came up at a meeting on Friday over wildcards, CNAME, and some corner cases in DNSSEC at Olafur's house. The idea of removing the subtyping of DNSKEY to be both zone keys and entity keys came up. The idea is to keep the KEY RR for transaction authentication (entity keys) and DNSKEY for zone keys. Topic: Keeping the KEY (typcode 24) and SIG (25) for transaction authentication only. With the typecode rollover of the KEY RR to the DNSKEY RR, we are left with a three typecodes now retired. However, there is still a viable currently deployed codebase and use for these record types. The KEY RR would continue to be used for transaction authentication key storage only (SIG(0) validating keys, TKEY operations). SIG would be used only for SIG(0) operations. The only change that is necessary is that servers/resolvers that use the new typecodes should recognize the old typcodes in these functions. The format of these records will remain largely unchanged from their current specification. The KEY RR will be regarded as any other data RR with regards to handling and placement in a zone. The definitions of the KEY RDATA fields will be: Flags: All flag bits are RESERVED and MUST be zero (especially bit 7, the zone key bit). Changes to flag bit definition must be done by IETF consensus. Protocol field: MUST be 3 (old DNSSEC). All other fields remain as they are described in RFC 2535 and subsequent updates. The SIG RR will remain as described in RFC's 2535, 2931 and 3008 Currently deployed code that recognizes and handles SIG(0)'s will be able to function as before. New servers that see the new typecodes (DNSKEY, RRSIG, etc) that choose to support SIG(0) MUST also be able to process the KEY and SIG RRs during transaction authentication. This will not go into the DNSSECbis specification drafts, as they deal with transaction authentication, which is not one of the goals stated in the DNSSEC specification. This will either be a new draft, or rolled into Sam Weiler's typecode rollover draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 17:52: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 RAA12783 for ; Tue, 17 Jun 2003 17:52:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SO9T-0000sn-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 21:38:03 +0000 Received: from c17200.carlnfd2.nsw.optusnet.com.au ([211.29.163.60] helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 19SO9M-0000sY-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 21:37:56 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h5HLbF6A040586; Wed, 18 Jun 2003 07:37:15 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306172137.h5HLbF6A040586@drugs.dv.isc.org> To: Edward Lewis Cc: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_?= =?iso-8859-1?Q?Gu=F0mundsson?= , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: question regarding wildcards and 2672 In-reply-to: Your message of "Tue, 17 Jun 2003 13:13:56 -0400." Date: Wed, 18 Jun 2003 07:37:15 +1000 X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 0:20 +1000 6/18/03, Mark.Andrews@isc.org wrote: > >Network Working Group M. Crawford > >Request for Comments: 2672 Fermilab > >Category: Standards Track August 1999 > > > > Please cite the RFC that moves DNAME to experimental. Note > > it is *not* RFC 3363. > > I missed that. I thought DNAME was experimental. So DNAME is > another standards document that is falling through the cracks. I was well aware the draft-ietf-dnsext-ipv6-addresses was not making DNAME experimental. I would have fought any attempts to make it experimental. I think I even said at one point "just remove the section on DNAME" in it. Mark > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > ...as graceful as a blindfolded bull in a china shop... -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 18:19:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14572 for ; Tue, 17 Jun 2003 18:19:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SOeJ-0001yy-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 22:09:55 +0000 Received: from [2002:c08b:2e21:3:250:baff:fe2d:b704] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #1) id 19SOeD-0001yY-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 22:09:50 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5HM9iq18310 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 17 Jun 2003 18:09:46 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5HMBKm14375 for ; Tue, 17 Jun 2003 18:11:20 -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 h5HM9T5l021244 for ; Tue, 17 Jun 2003 18:09:32 -0400 Message-Id: <200306172209.h5HM9T5l021244@sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: Keeping the KEY and SIG typecodes active In-reply-to: Your message of "Tue, 17 Jun 2003 16:01:14 EDT." <002301c3350b$34c60190$b9370681@barnacle> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 17 Jun 2003 18:09:29 -0400 From: Michael Richardson X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_20,IN_REP_TO,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Scott" == Scott Rose writes: Scott> Topic: Keeping the KEY (typcode 24) and SIG (25) for transaction Scott> authentication only. Scott> With the typecode rollover of the KEY RR to the DNSKEY RR, we are Scott> left with Scott> a three typecodes now retired. However, there is still a viable Scott> currently Scott> deployed codebase and use for these record types. Yes, please don't make DHCPD, etc. change. This is a sensible proposal. ] ON HUMILITY: to err is human. To moo, bovine. | 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 GNU/Linux using, kernel hacking, security guy"); [ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 18:40: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 SAA15135 for ; Tue, 17 Jun 2003 18:40:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SP2l-0002kz-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 22:35:11 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19SP2d-0002jt-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 22:35:03 +0000 Received: by sentry.rv.nailabs.com; id SAA16957; Tue, 17 Jun 2003 18:36:27 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma016940; Tue, 17 Jun 03 18:35:33 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6p2/8.11.6) with ESMTP id h5HMWZg23187; Tue, 17 Jun 2003 18:32:35 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Tue, 17 Jun 2003 18:32:35 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Scott Rose cc: Subject: Re: Keeping the KEY and SIG typecodes active In-Reply-To: <002301c3350b$34c60190$b9370681@barnacle> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-19.3 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Topic: Keeping the KEY (typcode 24) and SIG (25) for transaction > authentication only. draft-ietf-dnsext-dnssec-2535typecode-change-02.txt (which finally cleared the i-d editor queue late this afternoon after being sent in on Thursday morning) keeps SIG for SIG(0), but still deprecates KEY. I'd appreciate it if folks would review the new sections of the draft -- there's a change list at the top of the document. Keeping KEY worries me a bit more, since it will appear in-zone and some 2535-aware things pay attention to it. Must we really keep it? Do any of the SIG(0) _clients_ actually look at KEYs? -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 18:51: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 SAA15433 for ; Tue, 17 Jun 2003 18:51:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SPBV-000348-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 22:44:13 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19SPBN-00033p-00; Tue, 17 Jun 2003 22:44:05 +0000 Received: by sentry.rv.nailabs.com; id SAA17081; Tue, 17 Jun 2003 18:45:29 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma017065; Tue, 17 Jun 03 18:45:05 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6p2/8.11.6) with ESMTP id h5HMg7h23348; Tue, 17 Jun 2003 18:42:08 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Tue, 17 Jun 2003 18:42:07 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Randy Bush cc: namedroppers Subject: Re: need to update opt-in to info In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-28.4 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_PINE, X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 17 Jun 2003, Randy Bush wrote: > 1.2 add a normative reference to rfc2535bis, the records and > protocol documents. One of the cited messages says: > o the ADs do have expressed concerns to the chairs about when it > gets published; after DS+2535bis would be best. this doesn't > prevent folk from finishing the document now and it can queue > (in the wg or at the AD) on hold until DS+2535bis finishes. Those concerns weren't shared with the list, and without them, I don't see the need for a normative reference to the bis docs. Normative on DS, sure, but I don't see the need to wait for the whole rewrite to complete. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 17 19:08: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 TAA15707 for ; Tue, 17 Jun 2003 19:08:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19SPT8-0003j9-00 for namedroppers-data@psg.com; Tue, 17 Jun 2003 23:02:26 +0000 Received: from sentry.rv.nailabs.com ([204.254.155.100]) by psg.com with esmtp (Exim 3.36 #1) id 19SPSr-0003iY-00 for namedroppers@ops.ietf.org; Tue, 17 Jun 2003 23:02:09 +0000 Received: by sentry.rv.nailabs.com; id TAA17397; Tue, 17 Jun 2003 19:03:33 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma017387; Tue, 17 Jun 03 19:03:11 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6p2/8.11.6) with ESMTP id h5HN0Dc23896; Tue, 17 Jun 2003 19:00:13 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Tue, 17 Jun 2003 19:00:13 -0400 (EDT) From: Sam Weiler X-X-Sender: To: cc: ipseckey Subject: IPSECKEY inheritance of DNSSEC algorithm registry In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-13.4 required=5.0 tests=BAYES_20,IN_REP_TO,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The IPSECKEY RR definition draft is nearing WG last call -- this would be a good time to review the document. The chairs would particularly like feedback on whether or not the IPSECKEY record should inherit format definitions from the DNS Security Algorithm registry -- if someone defines a (DNS)KEY RR format for Sam's Public Key Algorithm, does it automagically show up as an IPSECKEY format? The text in draft-ietf-ipseckey-rr-04.txt is internally inconsistent, but the intent with this version was that, yes, the formats are inherited. Please send all comments to the IPSECKEY list. General Discussion: ipseckey@sandelman.ca To Subscribe: ipseckey-request@sandelman.ca Archive: http://www.sandelman.ca/lists/html/ipseckey/ http://www.ietf.org/html.charters/ipseckey-charter.html http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-04.txt -- 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 Jun 18 07:59: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 HAA28760 for ; Wed, 18 Jun 2003 07:59:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SbTG-0003a8-Eb for namedroppers-data@psg.com; Wed, 18 Jun 2003 11:51:22 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19SbTC-0003Zi-V4 for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 11:51:19 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27761; Wed, 18 Jun 2003 07:51:17 -0400 (EDT) Message-Id: <200306181151.HAA27761@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-00.txt Date: Wed, 18 Jun 2003 07:51:17 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Clarifying the Role of Wild Card Domains in the Domain Name System Author(s) : B. Halley, E. Lewis Filename : draft-ietf-dnsext-wcard-clarify-00.txt Pages : 0 Date : 2003-6-17 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-wcard-clarify-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17144128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-wcard-clarify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-wcard-clarify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144128.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 07:59:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28795 for ; Wed, 18 Jun 2003 07:59:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SbTK-0003aU-9P for namedroppers-data@psg.com; Wed, 18 Jun 2003 11:51:26 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19SbTH-0003aB-6G for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 11:51:23 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27777; Wed, 18 Jun 2003 07:51:21 -0400 (EDT) Message-Id: <200306181151.HAA27777@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-2535typecode-change-02.txt Date: Wed, 18 Jun 2003 07:51:21 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Legacy Resolver Compatibility for Delegation Signer Author(s) : S. Weiler Filename : draft-ietf-dnsext-dnssec-2535typecode-change-02.txt Pages : 5 Date : 2003-6-17 As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed. Many deployed nameservers understand variants of these semantics. Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document proposes that these interactions be avoided by changing the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-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-dnssec-2535typecode-change-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-dnssec-2535typecode-change-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-6-17144145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-2535typecode-change-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-2535typecode-change-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144145.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 08:54: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 IAA02268 for ; Wed, 18 Jun 2003 08:54:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ScNq-0006qk-42 for namedroppers-data@psg.com; Wed, 18 Jun 2003 12:49:50 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.14) id 19ScNn-0006qM-OY for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 12:49: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 h5ICnQbd024332; Wed, 18 Jun 2003 08:49:26 -0400 (EDT) Message-ID: <005201c33598$0e3d5ef0$b9370681@barnacle> From: "Scott Rose" To: "Sam Weiler" Cc: References: Subject: Re: Keeping the KEY and SIG typecodes active Date: Wed, 18 Jun 2003 08:49:28 -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=-11.9 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As long as the KEY RR does not have the zone key flag bit set, it should be alright. However, the KEY will be signed by a RRSIG in the zone, which would cause old (RFC2535) validators to consider it unsigned. As for SIG(0) clients, if they don't now, that doesn't mean they won't later, especially since that was the idea of SIG(0). Scott ----- Original Message ----- From: "Sam Weiler" To: "Scott Rose" Cc: Sent: Tuesday, June 17, 2003 6:32 PM Subject: Re: Keeping the KEY and SIG typecodes active > > Topic: Keeping the KEY (typcode 24) and SIG (25) for transaction > > authentication only. > > draft-ietf-dnsext-dnssec-2535typecode-change-02.txt (which finally > cleared the i-d editor queue late this afternoon after being sent in > on Thursday morning) keeps SIG for SIG(0), but still deprecates KEY. > I'd appreciate it if folks would review the new sections of the draft > -- there's a change list at the top of the document. > > Keeping KEY worries me a bit more, since it will appear in-zone and > some 2535-aware things pay attention to it. Must we really keep it? > Do any of the SIG(0) _clients_ actually look at KEYs? > > -- 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 Jun 18 09:19: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 JAA05437 for ; Wed, 18 Jun 2003 09:19:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Scm4-00081H-5P for namedroppers-data@psg.com; Wed, 18 Jun 2003 13:14:52 +0000 Received: from [64.102.124.12] (helo=rtp-core-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Scm0-0007ze-EB for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 13:14:48 +0000 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5IDDjwH016289; Wed, 18 Jun 2003 09:13:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-244.cisco.com [10.82.240.244]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id JAA03051; Wed, 18 Jun 2003 09:13:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jun 2003 09:12:03 -0400 To: dhcwg@ietf.org, namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I originally posed the issue: The RR TTLs need careful attention so that it never exceeds the expiration time of the lease on the associated address. Ed Lewis has suggested an alternative wording (based on his e-mail, included below): The RR TTLs need careful attention so that cached DNS information is never in conflict with the current assignment of an IP address to a host. That is, the important problem to avoid is cached DNS information about an address that has been assigned to a different host. Based on Ed's take on the problem, an alternative solution to the TTL problem is to: * the DHCP server adds an RR for host H with TTL set to some fixed value t * the DHCP server removes the RR when the lease on the address assigned to H expires at time T * the DHCP server does not make the address previously assigned to H available for reassignment until T+t Another observation - is it possible that the issue of stale cached DNS information has never been an issue in practice because DNS information installed by a DHCP server is rarely used, so that stale DNS information is insignificant? Put another way, do we have any experience with DDNS updates for a host that has obtained its IP address through DHCP and that is the target of frequent DNS queries; for example, a host running a web server whose address is found through a DNS query? If the RRs installed by the DHCP server are rarely queried, another alternative would be to simply set the TTL to 0, or to set the TTL initially to t, and then t seconds before the expiration of the lease on the address, set the TTL to 0. It seems that the guidance currently given in draft-ietf-dhc-ddns-resolution-05 will lead to a period of time equal to 1/3 the original lease time during which cached DNS data may associate a DNS name with an IP address that has been reassigned to a different host. This potential problem may not have been realized in practice because the DNS information about a host updated by a DHCP server is rarely queried. - Ralph At 08:19 PM 6/11/2003 -0400, Edward Lewis wrote: >Let's face it, DNS doesn't handle change well. And, worse yet, neither does security. That and DHCP , the reason we are here, loves change. > >One problem is that we are once again (to DNS'ers) mixing relative time (TTLs) and absolute time (a lease is from fixed time A to fixed time B). (I realize a lease can be extended, renewed, etc., but at any moment, it's a fixed span.) The same problem exists in DNSSEC's signature records and their validity spans. The concrete dilemma is - if I set the TTL to be (B-A)/3, as suggested, then the PTR/A[AAA] record will have the same value whether t=A or t=B. > >The best thing would be for a merge of the DNS server and DHCP server so that the TTL is always set to (B-NOW)-fudge, which is what we really want. 'Course, if we also wanted DNSSEC, we'd have to sign on the fly (which is why I mentioned security above). > >I'd suggest that if the DHCP server has a period of time in which it will not reassign/reallocate an address after a lease has been allowed to elapse, that this is the period to use for the TTL. It represents the amount of time that erroneous information in a DNS cache can exist and not be of harm to an active node. > >The DNS data is just as "dirty" but if the DHCP hasn't given the address to another node, there's a win in there somewhere. > >At 15:48 -0400 6/6/03, Mark Stapp wrote: >>I've replied to Patrick; I'm not quite sure what more to do with issue [6]. >> >>The draft recommends using a ttl that's a fraction of the lease time, and recommends removing rrs promptly when the lease expires. There have been at least a couple of exchanges about this over the years, and the conclusion has always been that it's not possible to come up with a single set of values that are appropriate in every situation. Also, it's not possible to compel updaters to perform additional updates to 'back down' rrs' ttls as a lease approaches its expiration - that'll kill the dns server. As I noted in the other email I sent, the recommendations that are in the draft are the most up-to-date ones that I've been offered. >> >>We do have quite a bit of deployment experience with dhcp updates to dns, and this has not been an issue, as far as I can recall. I also don't recall any email to the wg indicating that this has been an issue in anyone else's experience. If someone has followed these recommendations and has found problems with them, then by all means let's come up with better recommendations. >> >>-- Mark >> >>At 03:11 PM 6/6/2003 -0400, Ralph Droms wrote: >>>DDNS-DHCP issue: >>> >>> The RR TTLs need careful attention so that it never exceeds the >>> expiration time of the lease on the associated address. >>> >>>This issue was anticipated by Patrick Cosmo: >>> >>>On Fri, 6 Jun 2003, Cosmo, Patrick wrote: >>> >>> > I have found some minor issues with the >>> > , I apologize if they have already >>> > been brought up. >>> > >>> > In particular, this statement in section 5. (DNS RR TTLs) on page 5: >>> > >>> > "The RR TTL on a DNS record added for with a DHCP lease SHOULD NOT exceed >>> > 1/3 of the lease time, and SHOULD be at least 10 minutes." >>> > >>> > 1. This sentence has some bad grammar ("for with" : ... record added for >>> > with a DHCP lease ...). >>> > >>> > 2. The statement is contradictory if the lease time is less than 30 minutes. >>> > When the lease time is less than 30 minutes, which suggestion takes >>> > precendence? : min. 10 minutes, or max or 1/3 lease time? >>> > >>> > 3. The section seems intended to suggest a reasonable TTL for these records, >>> > but doesn't seem to pull through or suggest much of anything (IMHO) other >>> > than "it should be a function of lease time, and it should be configurable". >>> > >>> > >>> > Patrick Cosmo >>> > >>> > Senior Product Engineer >>> > Incognito Software Inc >>> > Vancouver: (604) 688-4332 ext: 254 >>> > Toll-Free: 1-800-877-1856 >>> > http://www.incognito.com >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: Ralph Droms [mailto:rdroms@cisco.com] >>> > Sent: Thursday, June 05, 2003 7:36 PM >>> > To: dhcwg@ietf.org; namedroppers@ops.ietf.org >>> > Subject: [dhcwg] Issues in DDNS-DHCP interaction drafts >>> > >>> > >>> > The following drafts have passed WG last call: >>> > >>> > [1] A DNS RR for Encoding DHCP Information (DHCID RR) >>> > >>> > >>> > [2] The DHCP Client FQDN Option >>> > >>> > >>> > [3] Resolution of DNS Name Conflicts Among DHCP Clients >>> > >>> > >>> > Several issues regarding these drafts have been identified >>> > during the AD review prior to IESG review for Proposed >>> > Standard status. I will initiate discussion threads on >>> > each of these issues later today with e-mail to both >>> > the dhcwg and namedroppers mailing lists. Please respond >>> > just to the dhcwg mailing list to avoid duplicate postings... >>> > >>> > - Ralph >>> > >>> > _______________________________________________ >>> > dhcwg mailing list >>> > dhcwg@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/dhcwg >>> > >>>_______________________________________________ >>>dhcwg mailing list >>>dhcwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dhcwg >> >> >>-- >>to unsubscribe send a message to namedroppers-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-703-227-9854 >ARIN Research Engineer > >Okay, okay, the previous sig wasn't all that good... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 09:36: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 JAA06319 for ; Wed, 18 Jun 2003 09:36:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sd49-0008pi-Io for namedroppers-data@psg.com; Wed, 18 Jun 2003 13:33:33 +0000 Received: from [131.254.10.33] (helo=w3.irisa.fr) by psg.com with esmtp (Exim 4.14) id 19Sd47-0008pV-4Z for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 13:33:31 +0000 Received: from irisa.fr (estephe.irisa.fr [131.254.70.3]) by w3.irisa.fr (Postfix) with ESMTP id 2207F8502; Wed, 18 Jun 2003 15:20:44 +0200 (MEST) Message-ID: <3EF0672C.6070500@irisa.fr> Date: Wed, 18 Jun 2003 15:20:44 +0200 From: Olivier Courtay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: fr-fr, en-us, en MIME-Version: 1.0 Newsgroups: comp.protocols.dns.std To: Mike.StJohns@nominum.com Cc: namedroppers@ops.ietf.org Subject: Comment on draft-stjohns-secure-notify-00 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.9 required=5.0 tests=BAYES_30,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We are also currently working on the Key RollOver subject and we have some comments on your draft. you propose three methods : Automatic, Manual and Parent Pull. Our solution is very similar to your Parent Pull method. In our opinion we think that Parent Pull is a better choice because with this method SIG(0) is not needed anymore. For example for the DS records update case, we have the following scenario: - child send a NOTIFY (including only his SOA record), - parent receives this NOTIFY, - parent retrieves needed information from his child, - parent checks if DS is present on his zone for the child zone, - parent checks if a KEY in the KEY RRset is validated by a DS, - parent validates the KEY RRSet with this KEY, -> Now, the parent can trust all KEY in the KEY RRset and can build the right keyset, - parent responds to the child by a NOTIFY Response. There are three advantages with this method: - SIG(0) is not necessary (therefore the private key is not necessarily on the server), - the NOTIFY message contains the serial number of the child zone, so the parent can deduce that the child zone has changed or not, - parent has checked the child zone configuration status and the chain of trust is validated. For NS record update, Notify and changes validation are used on the same manner. For NS record update, two solutions: if the private key is present on the server, it can immediately sign the zone with new glue (Automatic case) or put in a file the new glue for this child (in the same manner than a keyset file) which will take effect after the next zone signature (Manual case). In the parent Pull method, the parent has more work to do, but this work could be delegated to an other service (to avoid Deny Of Service attack problem too). In this case, the parent only has to forward the NOTIFY to this other service. The problem is that these methods can not be used for the initialization of the chain of trust, i.e. the first time a zone is secured. At the beginning of the DNS delegation, the parent can not identify his child because no DS exists. We work on the automatization of DNSsec administration and will provide some results in a near future. Regards, -- Olivier COURTAY Research engineer IDsA Project (www.idsa.prd.fr) ENST Bretagne( www.enst-bretagne.fr) Gilles GUETTE Ph.D student Armor Project Irisa/Inria (www.irisa.fr) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 09:54:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07098 for ; Wed, 18 Jun 2003 09:54:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SdLt-0009j6-1X for namedroppers-data@psg.com; Wed, 18 Jun 2003 13:51:53 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.14) id 19SdLn-0009gi-VE for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 13:51:48 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 32237407; Wed, 18 Jun 2003 09:51:17 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id B1A9D46A for ; Wed, 18 Jun 2003 09:51:16 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 406318; Wed, 18 Jun 2003 09:48:00 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Wed, 18 Jun 2003 09:51:13 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: wild cards and NS records Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.4 required=5.0 tests=BAYES_10,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The third 'special type' for the wild card is the NS record. There are a couple of ways to look at this. One, NS referrals are handled in step b of the algorithm, and wild cards are synthesized in step c. From this observation, NS's at a wild card ought not be 'seen' in the search unless the QTYPE matches NS. There's a complication with NS that is not present with CNAME. When asking for the CNAME RR at a name, we get the authoritative answer. Swapping NS for CNAME here gives the non-authoritative name as the NS in the parent zone isn't the authoritative answer. Grumble. Barring NS's from being at a wild card domain name isn't being suggested, but strongly discouraged. NS's have been legal for some time (well, since 1034) at wild cards. It would take a serious detrimental impact on the protocol to now bar them - and empirically speaking, this isn't happening. However, discouraging them seems to be a good idea. Synthesized delegations, if not done just right (as in to a name server that knows it will synthesizing zones for step 2 of its search algorithm) will likely lead to lame delegations. So, the suggestion for this case is to state: o Name servers MAY reject (refuse to load) zones with any wild card domain name owning an NS RR set. o Name servers MAY refuse to accept updates to add NS RR sets to a wild card domain name. MAY, not MUST. ? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 10:29:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09791 for ; Wed, 18 Jun 2003 10:29:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SdpU-000AxM-SJ for namedroppers-data@psg.com; Wed, 18 Jun 2003 14:22:28 +0000 Received: from [2001:7b8:206:1003:280:48ff:feb3:26eb] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.14) id 19SdpR-000Ax9-Qw for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 14:22:26 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5IEMBIj005121; Wed, 18 Jun 2003 16:22:11 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) id h5IEMBoh005120; Wed, 18 Jun 2003 16:22:11 +0200 Date: Wed, 18 Jun 2003 16:22:11 +0200 From: Miek Gieben To: Olivier Courtay Cc: Mike.StJohns@nominum.com, namedroppers@ops.ietf.org Subject: Re: Comment on draft-stjohns-secure-notify-00 Message-ID: <20030618142211.GA4695@atoom.net> Mail-Followup-To: Olivier Courtay , Mike.StJohns@nominum.com, namedroppers@ops.ietf.org References: <3EF0672C.6070500@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF0672C.6070500@irisa.fr> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 18 Jun, @15:20, Olivier wrote in "Comment on draft-stjohns-secur ..."] > Hi, > > We are also currently working on the Key RollOver subject and we have > some comments on your draft. this triggered me to also comment :) In the draft the notify is signed with the private key from the child's zone. The experiment currently running in nl (SECREG) also uses the child's key as a mechanism to authenticate child zone administrators. But this has severe impact on how a registry operates. In SECREG the holder of the private key of a domain is called the sec-c, the security contact. This draft describes ways for the sec-c to directly contact the registry, thereby bypassing the registrar. Also if something goes wrong with the private key of the sec-c, the registry is involved since it allowed access with that key. I'm currently documenting this kind of stuff for SIDN. A registry could continue to use the current registrant <-> registrar <-> registry model. This would mean that it cannot use the mechanism described in this draft. A registrar would not be in the possession of the private key of a (child) domain. If a registry want to use such a mechanism a lot of other things also have to be decided of which the most important one is: are we still going to use registrars? > you propose three methods : Automatic, Manual and Parent Pull. > Our solution is very similar to your Parent Pull method. > In our opinion we think that Parent Pull is a better choice because with > this method SIG(0) is not needed anymore. > > For example for the DS records update case, we have the following scenario: > - child send a NOTIFY (including only his SOA record), > - parent receives this NOTIFY, > - parent retrieves needed information from his child, > - parent checks if DS is present on his zone for the child zone, > - parent checks if a KEY in the KEY RRset is validated by a DS, > - parent validates the KEY RRSet with this KEY, > -> Now, the parent can trust all KEY in the KEY RRset and can > build the right keyset, > - parent responds to the child by a NOTIFY Response. Why is this different (expect for the inband NOTIFY mesg) than sending an encrypted email with the NOTIFY in it. Which can be handled by the registrar, just like the normal DNS operations are handled today? Maybe this email is a bit cryptic, but what I want to say boils down to this. Be very carefull when using the key information in DNSSEC. It has implication on almost every aspect of DNS, esp. the registration side of it. grtz Miek -- NLnet Labs :wq! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 10:51: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 KAA10774 for ; Wed, 18 Jun 2003 10:51:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SeEk-000C0Y-TN for namedroppers-data@psg.com; Wed, 18 Jun 2003 14:48:34 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.14) id 19SeEh-000ByJ-9N for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 14:48:31 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id B54B540A; Wed, 18 Jun 2003 10:48:00 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 13049362 for ; Wed, 18 Jun 2003 10:48:00 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 406467; Wed, 18 Jun 2003 10:44:43 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Wed, 18 Jun 2003 10:47:56 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: type code roll draft comments Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-6.4 required=5.0 tests=BAYES_10,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk # Legacy Resolver Compatibility for Delegation Signer # draft-ietf-dnsext-dnssec-2535typecode-change-02.txt # # Abstract # # As the DNS Security (DNSSEC) specifications have evolved, the # syntax and semantics of the DNSSEC resource records (RRs) have # changed. Many deployed nameservers understand variants of these # semantics. Dangerous interactions can occur when a resolver that # understands an earlier version of these semantics queries an # authoritative server that understands the new delegation signer # semantics, including at least one failure scenario that will cause # an unsecured zone to be unresolvable. This document proposes that # these interactions be avoided by changing the type codes and # mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). One thorny issue is that it is not just name servers that understand some variants, but that some DHCP servers do also, and this is why SIG(0) has become an annoying issue. (Yes, I'm being a PITA about documenting the rationale again.) # 1. Introduction # # incompatible with the semantics in [RFC2535]. Answers provided by A nit: For consistency (see also text in 1.2), refer to RFC 2535 as "RFC 2535", with the reference ("[RFC2535]") appearing just once. I'd recommend this for other RFC's too. # 1.1 Terminology # # In this document, the term "unsecure delegation" means any # delegation for which no DS record appears at the parent. An # "unsecure referral" is an answer from the parent containing an NS # RRset and a proof that no DS record exists for that name. And you are referring (heh) to "NS referrals" and not "CNAME referrals". # 1.2 The Problem The "trigger" or last straw prompting this. There are many decent reasons to change the protocol parameters when a standard recycles at a certain level, especially Proposed, but there is one problem in particular that launched this effort. I would also add the observation that in RFC 2308 (NCACHE), looking at "NODATA REPSONSE: TYPE 1." and then considering that in the olden days an NXT was thought to be an SOA-replacement in negative answers, it seems as if the presence of the no-DS record is indicating a negative answer, not a positive answer indicating an "end of security." # 2.1. Change SIG, KEY, and NXT type codes # # include NXT records in the authority section. The simplest way to # do that is to change the type codes for SIG, KEY, and NXT. Well, "simplest" would be to just change NXT as you mention in 2.2. Changing all three would be conceptually nicer, especially given that blindly changing SIG and KEY leaves us in a hung state with SIG(0) (as non-DNS elements are already experimenting with it). # 2.5. Do nothing # # and, due to underspecification in those documents, interpret any s/s/ s/ # 3. Protocol changes # # If a resolver receives the old types, it SHOULD treat them as You mean KEY and NXT.?. # Authoritative servers SHOULD NOT serve SIG, KEY, or NXT records. Authoritative servers ought not edit the zones they have loaded. Are you saying that the server ought to refuse to load zones with these and ought to refuse updates that attempt to add these records? I'm confused. If a SIG(0) is seen and a DNSKEY isn't allowed to have generated it, where does the public key come from to validate the SIG(0) at the end of the message? # 4. IANA Considerations # Types 24 (SIG) is retained for SIG(0) [RFC2931] use only. Types 25 # and 30 (KEY and NXT) should be marked as Obsolete. I can see NXT being obsoleted. But I am not clear from the text whey the KEY is also. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 11:13:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11870 for ; Wed, 18 Jun 2003 11:13:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SeZo-000DBe-UR for namedroppers-data@psg.com; Wed, 18 Jun 2003 15:10:20 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19SeZl-000DBG-Uu for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 15:10:18 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19SeZl-000PPj-Fh for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 08:10:17 -0700 Message-ID: <3EF036B2.5000508@nomadiclab.com> MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 18 Jun 2003 12:53:54 +0300 From: Pekka Nikander To: Sam Weiler Cc: namedroppers@ops.ietf.org, ipseckey Subject: Re: [IPSECKEY] IPSECKEY inheritance of DNSSEC algorithm registry X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Sam Weiler wrote: > The chairs would particularly like feedback on whether or not the > IPSECKEY record should inherit format definitions from the DNS > Security Algorithm registry -- if someone defines a (DNS)KEY RR format > for Sam's Public Key Algorithm, does it automagically show up as an > IPSECKEY format? I am in favour of inheriting the definitions. The same definitions are currently being reused in HIP, and I am proposing that we use those also in SEND. (SEND currently specifies ASN.1 OIDs, but I personally see little value in that.) In particular, what comes to the following: > 2.3 RDATA format - algorithm type > .... > The public key field contains the algorithm-specific portion of the > KEY RR RDATA, omitting the first four octets of the KEY RR RDATA. > This is the same portion of the KEY RR that must be specified by > documents that define a DNSSEC algorithm. Those documents also > specify a message digest to be used for generation of SIG RRs; that > specification is not relevant to the IPSECKEY usage of the public key > format. I think the intention of the text is excellent. It aligns very well with the current HIP usage of RFC2535 key formats. However, it might be good to explicitly mention that the first four octets would contain the flags, protocol, and algorithm fields, which are now left away. A couple of comments: Should there be a reserved octed before the gateway field, thereby aligning the gateway field to 32-bit boundary? AAAA RDATA format is defined in Section 2.2 (not 3.2) of RFC1886. --Pekka Nikander -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 11:18: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 LAA12155 for ; Wed, 18 Jun 2003 11:18:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sefa-000DUb-Jf for namedroppers-data@psg.com; Wed, 18 Jun 2003 15:16:18 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19SefX-000DU6-VS; Wed, 18 Jun 2003 15:16:16 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5IFGDYU025469; Wed, 18 Jun 2003 09:16:14 -0600 (MDT) Received: from lillen (vpn-129-156-96-163.EMEA.Sun.COM [129.156.96.163]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5IFG7Q12665; Wed, 18 Jun 2003 17:16:08 +0200 (MEST) Date: Wed, 18 Jun 2003 10:21:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: need to update opt-in to info To: Sam Weiler Cc: Randy Bush , namedroppers In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-11.7 required=5.0 tests=BAYES_01,DATE_IN_PAST_06_12,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Those concerns weren't shared with the list, and without them, I don't > see the need for a normative reference to the bis docs. Normative on > DS, sure, but I don't see the need to wait for the whole rewrite to > complete. The concern is that, due to folks not being good a differentiating between INFO and STANDARDs, that having an opt-in informational document appear when RFC 2535 is known to be undeployable poses a larger risk that opt-in be viewed as a fix to 2535. Having the 2535bis document set reduces this risk. Since the goal of this exercise is to document opt-in in the historical record (something the IETF doesn't do well and something it makes sense to improve) the added delay for opt-in becoming an RFC should be irrelevant. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 12:00: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 MAA14367 for ; Wed, 18 Jun 2003 12:00:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SfGY-000F7F-JD for namedroppers-data@psg.com; Wed, 18 Jun 2003 15:54:30 +0000 Received: from [131.254.10.33] (helo=w3.irisa.fr) by psg.com with esmtp (Exim 4.14) id 19SfGU-000F71-4W for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 15:54:26 +0000 Received: from irisa.fr (estephe.irisa.fr [131.254.70.3]) by w3.irisa.fr (Postfix) with ESMTP id 995848417; Wed, 18 Jun 2003 17:54:24 +0200 (MEST) Message-ID: <3EF08B30.5060305@irisa.fr> Date: Wed, 18 Jun 2003 17:54:24 +0200 From: Olivier Courtay User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: fr-fr, en-us, en MIME-Version: 1.0 To: Miek Gieben Cc: Mike.StJohns@nominum.com, namedroppers@ops.ietf.org Subject: Re: Comment on draft-stjohns-secure-notify-00 References: <3EF0672C.6070500@irisa.fr> <20030618142211.GA4695@atoom.net> In-Reply-To: <20030618142211.GA4695@atoom.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-45.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Miek Gieben wrote: >[On 18 Jun, @15:20, Olivier wrote in "Comment on draft-stjohns-secur ..."] > >>Hi, >> >>We are also currently working on the Key RollOver subject and we have >>some comments on your draft. >> > >this triggered me to also comment :) > Hello Miek, > >In the draft the notify is signed with the private key from >the child's zone. The experiment currently running in nl (SECREG) >also uses the child's key as a mechanism to authenticate child >zone administrators. But this has severe impact on how a registry >operates. In SECREG the holder of the private key of a domain is >called the sec-c, the security contact. > >This draft describes ways for the sec-c to directly contact the >registry, thereby bypassing the registrar. Also if something >goes wrong with the private key of the sec-c, the registry is >involved since it allowed access with that key. I'm currently >documenting this kind of stuff for SIDN. > >A registry could continue to use the current registrant <-> registrar ><-> registry model. This would mean that it cannot use the mechanism >described in this draft. A registrar would not be in the possession >of the private key of a (child) domain. > Yes, in our model, the private key isn't needed, the validation of data is done using DNSsec validation (chain of trust). New keyset are generated automaticaly but not immediately integrated on the zone (like a CA with Certificate request). I'am right with you that relations between entity are very important. For encrypted email, how authenticated the peer ? you need X509 certificate, Pre-Shared Key or use the private DNSsec Key? If you decide to use the private key, thus the sec-c is connected to Internet, it's not good..... Our proposed scheme (read with a fixed font): +----------------------+ | Parent sec-c |----------- 9 off-line -----------------+ +----------------------+ | /\ | | | | (off-line) | | 7 \/ L__ 8 __ Key Roll Over Service <--------- 4 ------- Parent Server /\ /\ | | | | L---- ----------- 5 and 6 -------+ 3 | | | | +----------------------+ \/ | | Child sec-c |--------------- 2 -------------> Child Server +----------------------+ (off-line) 1 1) the Child sec-c sign his zone. 2) the zone's file is transfered off-line to the child server. 3) the child server see that there is glue change and send a NOTIFY (not crypted and with the SOA) to the parent server. 4) the parent server forward the NOTIFY to the Key Roll Over Service (we have begin to implemented this) . 5 and 6) the Key Roll Over Service collect needed informations (child KEY RRset). 7) the Key Roll Over Service validate the data using DNSsec chain of trust (with the DNSsecToolKit available at www.dnnsec.net ;-) ) 8) the keyset is generated and available to the parent sec-c by an off-line transfert. 9) when he wants the parent sec-c sign the zone file........ > > >If a registry want to use such a mechanism a lot of other things also have to be >decided of which the most important one is: are we still going to use >registrars? > > >>you propose three methods : Automatic, Manual and Parent Pull. >>Our solution is very similar to your Parent Pull method. >>In our opinion we think that Parent Pull is a better choice because with >>this method SIG(0) is not needed anymore. >> >>For example for the DS records update case, we have the following scenario: >> - child send a NOTIFY (including only his SOA record), >> - parent receives this NOTIFY, >> - parent retrieves needed information from his child, >> - parent checks if DS is present on his zone for the child zone, >> - parent checks if a KEY in the KEY RRset is validated by a DS, >> - parent validates the KEY RRSet with this KEY, >> -> Now, the parent can trust all KEY in the KEY RRset and can >>build the right keyset, >> - parent responds to the child by a NOTIFY Response. >> > >Why is this different (expect for the inband NOTIFY mesg) than sending >an encrypted email with the NOTIFY in it. Which can be handled by the >registrar, just like the normal DNS operations are handled today? > The result is the same but private-key isn't used and sec-c stay off-line. All work can be done automaticaly except when informations are transfered off-line (human validation can be done here). If you want a total automatization, you can replace off-line mechanism by on-line and automated mechanism (At your own risk). > > >Maybe this email is a bit cryptic, but what I want to say boils down to this. >Be very carefull when using the key information in DNSSEC. It has implication >on almost every aspect of DNS, esp. the registration side of it. > >grtz Miek > >-- >NLnet Labs >:wq! > -- Olivier COURTAY Research engineer IDsA Project (www.idsa.prd.fr) ENST Bretagne( www.enst-bretagne.fr) Gilles GUETTE Ph.D student Armor Project Irisa/Inria (www.irisa.fr) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 12:31: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 MAA15326 for ; Wed, 18 Jun 2003 12:31:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SfkB-000GgY-A7 for namedroppers-data@psg.com; Wed, 18 Jun 2003 16:25:07 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.14) id 19Sfk8-000Gel-HA for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 16:25:04 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 624DD13948 for ; Wed, 18 Jun 2003 16:24:51 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: wild cards and NS records In-Reply-To: Message from Edward Lewis of "Wed, 18 Jun 2003 09:51:13 -0400." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 18 Jun 2003 16:24:51 +0000 Message-Id: <20030618162451.624DD13948@sa.vix.com> X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > So, the suggestion for this case is to state: > > o Name servers MAY reject (refuse to load) zones with any wild card domain > name owning an NS RR set. > o Name servers MAY refuse to accept updates to add NS RR sets to a wild > card domain name. > > MAY, not MUST. ? i'd like SHOULD. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 13:02: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 NAA16289 for ; Wed, 18 Jun 2003 13:02:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SgGA-000Ier-Rf for namedroppers-data@psg.com; Wed, 18 Jun 2003 16:58:10 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.14) id 19SgFz-000IdG-Tp for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 16:57:59 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1983113948 for ; Wed, 18 Jun 2003 16:57:47 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: need to update opt-in to info In-Reply-To: Message from Erik Nordmark of "Wed, 18 Jun 2003 10:21:02 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 18 Jun 2003 16:57:47 +0000 Message-Id: <20030618165747.1983113948@sa.vix.com> X-Spam-Status: No, hits=-11.8 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Since the goal of this exercise is to document opt-in in the > historical record (something the IETF doesn't do well and something it > makes sense to improve) the added delay for opt-in becoming an RFC > should be irrelevant. > > Erik well, but, that's not the goal at all. but i digress. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 14:19: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 OAA19715 for ; Wed, 18 Jun 2003 14:19:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ShR9-000MFG-6U for namedroppers-data@psg.com; Wed, 18 Jun 2003 18:13:35 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.14) id 19ShR6-000MEi-AX for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 18:13:32 +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 h5IICxbd027084; Wed, 18 Jun 2003 14:12:59 -0400 (EDT) Message-ID: <042601c335c5$4191a7c0$b9370681@barnacle> From: "Scott Rose" To: Cc: References: Subject: Re: wild cards and NS records Date: Wed, 18 Jun 2003 14:13:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Paul on this. It should be a SHOULD or a MUST and not MAY. MAY sounds too non-commital and someone who thinks they have a good reason to use *.somedomain IN NS would be tempted to use it. Scott ----- Original Message ----- From: "Edward Lewis" To: Cc: Sent: Wednesday, June 18, 2003 9:51 AM Subject: wild cards and NS records > The third 'special type' for the wild card is the NS record. > > There are a couple of ways to look at this. > > One, NS referrals are handled in step b of the algorithm, and wild > cards are synthesized in step c. From this observation, NS's at a > wild card ought not be 'seen' in the search unless the QTYPE matches > NS. > > There's a complication with NS that is not present with CNAME. When > asking for the CNAME RR at a name, we get the authoritative answer. > Swapping NS for CNAME here gives the non-authoritative name as the NS > in the parent zone isn't the authoritative answer. Grumble. > > Barring NS's from being at a wild card domain name isn't being > suggested, but strongly discouraged. NS's have been legal for some > time (well, since 1034) at wild cards. It would take a serious > detrimental impact on the protocol to now bar them - and empirically > speaking, this isn't happening. > > However, discouraging them seems to be a good idea. Synthesized > delegations, if not done just right (as in to a name server that > knows it will synthesizing zones for step 2 of its search algorithm) > will likely lead to lame delegations. > > So, the suggestion for this case is to state: > > o Name servers MAY reject (refuse to load) zones with any wild card domain > name owning an NS RR set. > o Name servers MAY refuse to accept updates to add NS RR sets to a wild > card domain name. > > MAY, not MUST. ? > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > ...as graceful as a blindfolded bull in a china shop... > > -- > to 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 Jun 18 14:30: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 OAA20031 for ; Wed, 18 Jun 2003 14:30:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Shdt-000Ms3-Hb for namedroppers-data@psg.com; Wed, 18 Jun 2003 18:26:45 +0000 Received: from [129.70.136.107] (helo=momotombo.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.14) id 19Shdo-000MrX-VP for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 18:26:41 +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 h5IIQdQ22178 for ; Wed, 18 Jun 2003 20:26:39 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h5IIQcB28858 for ; Wed, 18 Jun 2003 20:26:39 +0200 (MEST) Message-Id: <200306181826.h5IIQcB28858@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: wild cards and NS records In-reply-to: Your message of "Wed, 18 Jun 2003 14:13:01 EDT." <042601c335c5$4191a7c0$b9370681@barnacle> 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: <28855.1055960797.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Wed, 18 Jun 2003 20:26:38 +0200 From: Peter Koch X-Spam-Status: No, hits=-13.6 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I agree with Paul on this. It should be a SHOULD or a MUST and not MAY. > MAY sounds too non-commital and someone who thinks they have a good reason > to use *.somedomain IN NS would be tempted to use it. This decision should not be left to the implementation because a valid zone should be predictably served in a mixed implementation master/slave environment. So, a MAY would add confusion as would a SHOULD in my opinion. A MUST wouldn't hurt. Any "really special" application requiring wildcard NS RRs would work on a case by case base anyway, as do those load balancing or route optimizing "DNS servers", which know nothing but A RRs today. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 14:36:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20255 for ; Wed, 18 Jun 2003 14:36:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ShkM-000NFT-Rc for namedroppers-data@psg.com; Wed, 18 Jun 2003 18:33:26 +0000 Received: from [2001:7b8:206:1003:280:48ff:feb3:26eb] (helo=elektron.atoom.net) by psg.com with esmtp (Exim 4.14) id 19ShkH-000NEu-2e for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 18:33:21 +0000 Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) with ESMTP id h5IIXAIj010822; Wed, 18 Jun 2003 20:33:11 +0200 Received: (from miekg@localhost) by elektron.atoom.net (8.12.3/8.12.3/Debian-6.4) id h5IIXAZk010819; Wed, 18 Jun 2003 20:33:10 +0200 Date: Wed, 18 Jun 2003 20:33:10 +0200 From: Miek Gieben To: Olivier Courtay Cc: Mike.StJohns@nominum.com, namedroppers@ops.ietf.org Subject: Re: Comment on draft-stjohns-secure-notify-00 Message-ID: <20030618183310.GA10557@atoom.net> Mail-Followup-To: Olivier Courtay , Mike.StJohns@nominum.com, namedroppers@ops.ietf.org References: <3EF0672C.6070500@irisa.fr> <20030618142211.GA4695@atoom.net> <3EF08B30.5060305@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF08B30.5060305@irisa.fr> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 18 Jun, @17:54, Olivier wrote in "Re: Comment on draft-stjohns-s ..."] > >> > > > >this triggered me to also comment :) > > > Hello Miek, > SNIP > Yes, in our model, the private key isn't needed, the validation of data > is done using DNSsec validation (chain of trust). > New keyset are generated automaticaly but not immediately integrated on > the zone (like a CA with Certificate request). > > I'am right with you that relations between entity are very important. > > For encrypted email, how authenticated the peer ? you need X509 > certificate, Pre-Shared Key or use the private DNSsec Key? yes, another mechanism is needed, but current registries already have that mechanism. The make and give out password to their registrars. (that some still use plain-text and the registrars are sloppy with their password is one more reason to _not_ use the DNS keys for this kind of work) > 1) the Child sec-c sign his zone. > 2) the zone's file is transfered off-line to the child server. > 3) the child server see that there is glue change and send a NOTIFY (not > crypted and with the SOA) to the parent server. > 4) the parent server forward the NOTIFY to the Key Roll Over Service (we > have begin to implemented this) . > 5 and 6) the Key Roll Over Service collect needed informations (child > KEY RRset). > 7) the Key Roll Over Service validate the data using DNSsec chain of > trust (with the DNSsecToolKit available at www.dnnsec.net ;-) ) > 8) the keyset is generated and available to the parent sec-c by an > off-line transfert. > 9) when he wants the parent sec-c sign the zone file........ I'm fully aware that this works, i've implemented it for SECREG and it is working for more than six months now. > The result is the same but private-key isn't used and sec-c stay off-line. > All work can be done automaticaly except when informations are > transfered off-line (human validation can be done here). > If you want a total automatization, you can replace off-line mechanism > by on-line and automated mechanism (At your own risk). The issue i'm referring to is not if these methods for updating keys/DS/NS/whatever work, 'cause they _do_ work. The issue here is how people see the future of registries in a DNSSEC world. If you give the sec-c rights to access the registry _directly_ you almost have done away with registrars... 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 Jun 18 14:42: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 OAA20550 for ; Wed, 18 Jun 2003 14:42:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Shp0-000Nbo-A0 for namedroppers-data@psg.com; Wed, 18 Jun 2003 18:38:14 +0000 Received: from [216.168.239.87] (helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 4.14) id 19Shox-000NZU-P6 for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 18:38:11 +0000 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id 5934B9BE21; Wed, 18 Jun 2003 14:37:41 -0400 (EDT) Date: Wed, 18 Jun 2003 14:37:41 -0400 From: Matt Larson To: Randy Bush Cc: namedroppers Subject: Re: need to update opt-in to info Message-ID: <20030618183741.GP2465@chinook.rgy.netsol.com> References: 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=-36.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 17 Jun 2003, Randy Bush wrote: > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01007.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01129.html > > to execute the plan outlined in the message above, the chairs in > coordination with the area director have agreed on the following > actions: Randy, The plan outlined would move Opt-In to informational. However, upon re-reading the responses to both messages listed above, several people suggesting moving Opt-In to experimental. No one suggested informational. This decision to move to informational appears to have been reached outside the WG. The WG's opinion was not solicited nor was consensus determined. Could you please explain the process that led to this plan to move Opt-In to informational? Why can we not let the WG weigh in on this topic? I personally support Opt-In going to experimental. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 15:10: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 PAA23084 for ; Wed, 18 Jun 2003 15:10:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SiGk-000Pcs-Pn for namedroppers-data@psg.com; Wed, 18 Jun 2003 19:06:54 +0000 Received: from [216.168.239.87] (helo=chinook.rgy.netsol.com) by psg.com with esmtp (Exim 4.14) id 19SiGh-000Pag-UF for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 19:06:52 +0000 Received: by chinook.rgy.netsol.com (Postfix, from userid 500) id 94BBB9BE21; Wed, 18 Jun 2003 15:06:21 -0400 (EDT) Date: Wed, 18 Jun 2003 15:06:21 -0400 From: Matt Larson To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: wild cards and NS records Message-ID: <20030618190621.GQ2465@chinook.rgy.netsol.com> References: 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=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 18 Jun 2003, Edward Lewis wrote: > One, NS referrals are handled in step b of the algorithm, and wild > cards are synthesized in step c. From this observation, NS's at a > wild card ought not be 'seen' in the search unless the QTYPE matches > NS. That is my interpretation of the algorithm. > There's a complication with NS that is not present with CNAME. When > asking for the CNAME RR at a name, we get the authoritative answer. > Swapping NS for CNAME here gives the non-authoritative name as the NS > in the parent zone isn't the authoritative answer. Grumble. I'm sorry, but I'm having trouble parsing the last sentence of the paragraph and relating the whole paragraph to the topic at hand. > Barring NS's from being at a wild card domain name isn't being > suggested, but strongly discouraged. NS's have been legal for some > time (well, since 1034) at wild cards. I'm not sure what you're implying. I agree that "*" for an owner name of an NS RRset is legal, but I disagree that an implementation following the algorithm in section 4.3.2 of RFC 1034 would support wildcard NS records in any useful way. The wildcard secret sauce is in the final paragraph of step 3(c). Here's all of 3(c) for completeness: c. If at some label, a match is impossible (i.e., the corresponding label does not exist), look to see if a the "*" label exists. If the "*" label does not exist, check whether the name we are looking for is the original QNAME in the query or a name we have followed due to a CNAME. If the name is original, set an authoritative name error in the response and exit. Otherwise just exit. If the "*" label does exist, match RRs at that node against QTYPE. If any match, copy them into the answer section, but set the owner of the RR to be QNAME, and not the node with the "*" label. Go to step 6. Clearly, wildcard synthesis only occurs when the QTYPE of the query matches the type of the wildcard. In other words, a wildcard synthesis resulting from a wildcard NS RRset would only apply when QTYPE is NS. This algorithm cannot generate a valid referral when QTYPE is not NS. > It would take a serious > detrimental impact on the protocol to now bar them I don't know that I agree with that, but I don't have enough data about usage (or lack thereof) in the wild to back up my skepticism. > However, discouraging them seems to be a good idea. Synthesized > delegations, if not done just right (as in to a name server that > knows it will synthesizing zones for step 2 of its search algorithm) > will likely lead to lame delegations. Synthesizing delegations is one thing, but that can't happen as a result of the algorithm in section 4.3.2. The same is true of CNAME processing--that happens before wildcard substitution in the algorithm I believe we either need to clarify the existing algorithm and point out that it does not allow wildcard CNAME and NS records in the manner they are sometimes implemented, or we need to change the algorithm to allow them. I don't care either way, but the current discrepancy between standard and practice is untenable. I'm afraid in particular that ambiguity surrounding wildcard CNAME has repercussions for DNSSEC validation. > So, the suggestion for this case is to state: > > o Name servers MAY reject (refuse to load) zones with any wild card domain > name owning an NS RR set. > o Name servers MAY refuse to accept updates to add NS RR sets to a wild > card domain name. > > MAY, not MUST. ? I don't think this is the way to go. I believe this is your chain of logic: 1. Wildcard NS records can be used to synthesize delegations. 2. Synthesized delegations are fraught with danger (i.e., lame delegations) and should be avoided by the unwary. 3. Let us discourage them with the language I propose. My contention is that #1 is incorrect, so better alternatives would be to either 1) explain that wildcard NS records only work when QTYPE=NS (and a similar clarification/explanation for CNAME) or 2) change the algorithm to support them in the way one intuitively expects them to work. Matt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 15:38: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 PAA25082 for ; Wed, 18 Jun 2003 15:38:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SihA-0000zM-U8 for namedroppers-data@psg.com; Wed, 18 Jun 2003 19:34:12 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.14) id 19Sih8-0000xC-90 for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 19:34:10 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id CDAF53A0; Wed, 18 Jun 2003 15:33:39 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 5D60E3DE; Wed, 18 Jun 2003 15:33:39 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 407561; Wed, 18 Jun 2003 15:30:21 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030618190621.GQ2465@chinook.rgy.netsol.com> References: <20030618190621.GQ2465@chinook.rgy.netsol.com> Date: Wed, 18 Jun 2003 15:33:32 -0400 To: Matt Larson From: Edward Lewis Subject: Re: wild cards and NS records Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-26.6 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:06 -0400 6/18/03, Matt Larson wrote: Clarifying... >> Swapping NS for CNAME here gives the non-authoritative name as the NS >> in the parent zone isn't the authoritative answer. Grumble. > >I'm sorry, but I'm having trouble parsing the last sentence of the >paragraph and relating the whole paragraph to the topic at hand. Assuming I'm looking at example.com: labela CNAME labelc labelb NS labeld A query for labela.example.com, CNAME, IN yields an authoritative answer, "labela CNAME labelc". A query for labelb.example.com, NS, IN yields a (non-auth) referral to labeld.example.com. I was pointing this out because, in step c, once I match a wild card name, the proper response, according to the text as written, is to just return the CNAME for QTYPE=CNAME - but extending this to just returning the NS for QTYPE=NS isn't a straight forward leap. (And for QTYPE=any, axfr, ixfr.) I was trying to point out that solving for CNAME in this instance doesn't help solve for NS...;( Using the CNAMe as an analog for NS doesn't help. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 15:55: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 PAA26031 for ; Wed, 18 Jun 2003 15:55:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Siyv-00026p-2o for namedroppers-data@psg.com; Wed, 18 Jun 2003 19:52:33 +0000 Received: from [204.254.155.100] (helo=sentry.rv.nailabs.com ident=firewall-user) by psg.com with esmtp (Exim 4.14) id 19Siys-00026W-MD for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 19:52:30 +0000 Received: by sentry.rv.nailabs.com; id PAA13109; Wed, 18 Jun 2003 15:53:54 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma013098; Wed, 18 Jun 03 15:53:51 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6p2/8.11.6) with ESMTP id h5IJoEh15399 for ; Wed, 18 Jun 2003 15:50:14 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Wed, 18 Jun 2003 15:50:14 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Subject: Re: Keeping the KEY and SIG typecodes active In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 17 Jun 2003, Sam Weiler wrote: > > Keeping KEY worries me a bit more, since it will appear in-zone and > some 2535-aware things pay attention to it. Must we really keep it? > Do any of the SIG(0) _clients_ actually look at KEYs? In thinking about this more: if a zone includes KEY RRs, 1) there should be no bad interactions with DS-aware (and DNSKEY-aware) code. DS-aware code should do the right thing with KEYs. 2) if there are bad interactions with 2535-aware code, then those interactions are already out there -- this draft isn't causing them. And if things need to be fixed later, then they can be fixed later. So I see no new harm in leaving KEY for SIG(0) use. Absent further commentary, -03 will retain KEY for SIG(0) use only. -- 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 Jun 18 16:20: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 QAA27568 for ; Wed, 18 Jun 2003 16:20:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SjKe-0003EH-2o for namedroppers-data@psg.com; Wed, 18 Jun 2003 20:15:00 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.14) id 19SjKc-0003D1-7y for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 20:14:58 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 66FC113948 for ; Wed, 18 Jun 2003 20:14:45 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: need to update opt-in to info In-Reply-To: Message from Matt Larson of "Wed, 18 Jun 2003 14:37:41 -0400." <20030618183741.GP2465@chinook.rgy.netsol.com> X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 18 Jun 2003 20:14:45 +0000 Message-Id: <20030618201445.66FC113948@sa.vix.com> X-Spam-Status: No, hits=-8.0 required=5.0 tests=BAYES_01,IN_REP_TO,OPT_IN,OPT_IN_CAPS autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > I personally support Opt-In going to experimental. > > Matt while i second matt's questions as to the process which led to the "let's make opt-in informational" plan, i want to follow up on the above "let's make it experimental instead" metaplan. ed's silly-state analysis is germane, and i believe antecedent to, any decision as to what non-standards-track status opt-in can have. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 16:54: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 QAA29351 for ; Wed, 18 Jun 2003 16:54:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sjqg-0004nn-Qg for namedroppers-data@psg.com; Wed, 18 Jun 2003 20:48:06 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.14) id 19Sjqb-0004lk-Nj for namedroppers@ops.ietf.org; Wed, 18 Jun 2003 20:48:01 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 3DD9C5685F; Wed, 18 Jun 2003 13:47:47 -0700 (PDT) Message-Id: <5.2.1.1.2.20030618154112.026f7fa8@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 18 Jun 2003 16:47:47 -0400 To: Olivier Courtay From: Mike StJohns Subject: Re: Comment on draft-stjohns-secure-notify-00 Cc: namedroppers@ops.ietf.org In-Reply-To: <3EF0672C.6070500@irisa.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_190234923==.ALT" X-Spam-Status: No, hits=-20.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO,OPT_IN, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --=====================_190234923==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Olivier... Some problems with your approach: At 09:20 6/18/2003, Olivier Courtay wrote: >For example for the DS records update case, we have the following scenario: > - child send a NOTIFY (including only his SOA record), Won't work - see below... child needs to send a notify which points at either the KEY or NS records. > - parent receives this NOTIFY, > - parent retrieves needed information from his child, > - parent checks if DS is present on his zone for the child zone, This should come after the NOTIFY is received and the parent should respond to the NOTIFY yea/nay based on whether a DS is present... cheap and fast test that happens without requiring the parent to query the child. > - parent checks if a KEY in the KEY RRset is validated by a DS, > - parent validates the KEY RRSet with this KEY, > -> Now, the parent can trust all KEY in the KEY RRset and can > build the right keyset, > - parent responds to the child by a NOTIFY Response. >There are three advantages with this method: > - SIG(0) is not necessary (therefore the private key is not > necessarily on the server), But the private key is available when the child signs the zone, its not a stretch that the NOTIFY can be signed at that time. > - the NOTIFY message contains the serial number of the child zone, so > the parent can deduce that the child zone has changed or not, This goes back to my "won't work" comment. The parent zone does not and should not contain a copy of the child SOA. Without this, the parent doesn't have the old serial number so it can't figure out if it needs to do a retrieval. There are also a *lot* of changes in the child zone that the parent doesn't and shouldn't care about - the parent ONLY cares about changes to glue NS and the KEY records pointed to by the DS records it holds. However, the serial number MUST change with ANY change in the zone contents. > - parent has checked the child zone configuration status and the chain > of trust is validated. How is this different from the entity who holds the KSK or ZSK sending a NOTIFY which chains to the DS held by the parent for the child zone? And as above, the parent shouldn't care about the child zone configuration, only about the glue it holds that points to the child zone. >For NS record update, Notify and changes validation are used on the same >manner. >For NS record update, two solutions: if the private key is present on the >server, it can immediately sign the zone with new glue (Automatic case) or >put in a file the new glue for this child (in the same manner than a >keyset file) which will take effect after the next zone signature (Manual >case). Per RFC2535 and its replacement - the NS records at the parent aren't signed by the parent (emphasis mine): "Every name in a secured zone will have associated with it at least one SIG resource record for each resource type under that name EXCEPT for glue address RRs and delegation point NS RRs. " >In the parent Pull method, the parent has more work to do, but this work >could be delegated to an other service (to avoid Deny Of Service attack >problem too). In this case, the parent only has to forward the NOTIFY to >this other service. One day I'm going two write a "how to design a protocol" and three things that will go in it are the "Complexity Principle", the "Selfishness Principle" and the "Load Balancing" principle. 1) Complexity Principle: When facing two separate choices to accomplish the same thing in a protocol, generally the simpler choice is the correct choice. Having to have yet another service/server act as a proxy to the parent to do this is an order of magnitude increase in complexity and probably not a good idea unless there's a substantial benefit. 2) Selfishness Principle: In general, its a good idea to place the responsibility for an action on the party who benefits most from the action. In this case, the child is the beneficiary and anything it can do to make it easier for the parent to update the data pointing to the child improves the chances the data will actually get updated. If the child has to depend on the parent to take notice of the NOTIFY, suck in the records, notice the changes, derive the new data, etc... it might not get done. I refer you to the general tone of the opt-in discussion. 3) Load Balancing Principle: In general, when you have a choice between having one entity responsible for many actions or having many entities responsible for a few actions, the latter is preferable. This is a corollary to the selfishness principle in that it generally makes sense for clients to track their own state, especially if you can by doing so make the server stateless. E.g. keeping persistent state for a few clients is OK, but trying to keep persistent state for 10s of 1000s of clients who have their own notion of the world can be daunting and require a lot of state resynchronization. Basically, I'd rather not have to have the parent zone track anything more than whether or not an accepted change is still requiring signature and publishing. >The problem is that these methods can not be used for the initialization >of the chain of trust, i.e. the first time a zone is secured. >At the beginning of the DNS delegation, the parent can not identify his >child because no DS exists. Yup - this is the general enrollment problem. Not being considered here. I assume there are some manual interactions that need to take place to do the original delegation, but that once that's done I want the key management system (e.g. the DNSSEC system) to do the right thing as keys change. Later, Mike >We work on the automatization of DNSsec administration and will provide >some results in a near future. > >Regards, > >-- >Olivier COURTAY >Research engineer >IDsA Project (www.idsa.prd.fr) >ENST Bretagne( www.enst-bretagne.fr) > > >Gilles GUETTE >Ph.D student >Armor Project >Irisa/Inria (www.irisa.fr) --=====================_190234923==.ALT Content-Type: text/html; charset="us-ascii" Hi Olivier... 

Some problems with your approach:

At 09:20 6/18/2003, Olivier Courtay wrote:


For example for the DS records update case, we have the following scenario:
   - child send a NOTIFY (including only his SOA record),

Won't work - see below... child needs to send a notify which points at either the KEY or NS records.

   - parent receives this NOTIFY,
   - parent retrieves needed information from his child,
   - parent checks if DS is present on his zone for the child zone,

This should come after the NOTIFY is received and the parent should respond to the NOTIFY yea/nay based on whether a DS is present... cheap and fast test that happens without requiring the parent to query the child.

   - parent checks if a KEY in the KEY RRset is validated by a DS,
   - parent validates the KEY RRSet with this KEY,
       -> Now, the parent can trust all KEY in the KEY RRset and can build the right keyset,
   - parent responds to the child by a NOTIFY Response.




There are three advantages with this method:
   - SIG(0) is not necessary (therefore the private key is not necessarily on the server),

But the private key is available when the child signs the zone, its not a stretch that the NOTIFY can be signed at that time.

   - the NOTIFY message contains the serial number of the child zone, so the parent can deduce that the child zone has changed or not,

This goes back to my "won't work" comment.  The parent zone does not and should not contain a copy of the child SOA.  Without this, the parent doesn't have the old serial number so it can't figure out if it needs to do a retrieval.  There are also a *lot* of changes in the child zone that the parent doesn't and shouldn't care about  - the parent ONLY cares about changes to glue NS and the KEY records pointed to by the DS records it holds.  However, the serial number MUST change with ANY change in the zone contents.

   - parent has checked the child zone configuration status and the chain of trust is validated.

How is this different from the entity who holds the KSK or ZSK sending a NOTIFY which chains to the DS held by the parent for the child zone?  And as above, the parent shouldn't care about the child zone configuration, only about the glue it holds that points to the child zone.

For NS record update, Notify and changes validation are used on the same manner.
For NS record update, two solutions: if the private key is present on the server, it can immediately sign the zone with new glue (Automatic case) or put in a file the new glue for this child (in the same manner than a keyset file) which will take effect after the next zone signature (Manual case).

Per  RFC2535 and its replacement - the NS records at the parent aren't signed by the parent (emphasis mine):


   "Every name in a secured zone will have associated
with it at least
   one SIG resource record for each resource type under that
name EXCEPT
   for glue address RRs and delegation point NS RRs.
"
In the parent Pull method, the parent has more work to do, but this work could be delegated to an other service (to avoid Deny Of Service attack problem too). In this case, the parent only has to forward the NOTIFY to this other service.

One day I'm going two write a "how to design a protocol" and three things that will go in it are the "Complexity Principle", the "Selfishness Principle" and the "Load Balancing" principle.

1) Complexity Principle:  When facing two separate choices to accomplish the same thing in a protocol, generally the simpler choice is the correct choice.   

Having to have yet another service/server act as a proxy to the parent to do this is an order of magnitude increase in complexity and probably not a good idea unless there's a substantial benefit.

2) Selfishness Principle:  In general, its a good idea to place the responsibility for an action on the party who benefits most from the action. 

In this case, the child is the beneficiary and anything it can do to make it easier for the parent to update the data pointing to the child improves the chances the data will actually get updated.  If the child has to depend on the parent to take notice of the NOTIFY, suck in the records, notice the changes, derive the new data, etc... it might not get done.  I refer you to the general tone of the opt-in discussion.

3)  Load Balancing Principle: In general, when you have a choice between having one entity responsible for many actions or having many entities responsible for a few actions, the latter is preferable.

This is a corollary to the selfishness principle in that it generally makes sense for clients to track their own state, especially if you can by doing so make the server stateless.  E.g. keeping persistent state for a few clients is OK, but trying to keep persistent state for 10s of 1000s of clients who have their own notion of the world can be daunting and require a lot of state resynchronization.

Basically, I'd rather not have to have the parent zone track anything more than whether or not an accepted change is still requiring signature and publishing. 

The problem is that these methods can not be used for the initialization of the chain of trust, i.e. the first time a zone is secured.
At the beginning of the DNS delegation, the parent can not identify his child because no DS exists.

Yup - this is the general enrollment problem.  Not being considered here.  I assume there are some manual interactions that need to take place to do the original delegation, but that once that's done I want the key management system (e.g. the DNSSEC system) to do the right thing as keys change.

Later, Mike



We work on the automatization of DNSsec administration and will provide some results in a near future.

Regards,

--
Olivier COURTAY
Research engineer
IDsA Project (www.idsa.prd.fr)
ENST Bretagne( www.enst-bretagne.fr)


Gilles GUETTE
Ph.D student
Armor Project
Irisa/Inria (www.irisa.fr)
--=====================_190234923==.ALT-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 18 20:24: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 UAA08371 for ; Wed, 18 Jun 2003 20:24:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sn8n-000Efu-TL for namedroppers-data@psg.com; Thu, 19 Jun 2003 00:19:01 +0000 Received: from [2001:470:1f00:820:208:74ff:fe9f:eeae] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.14) id 19Sn8i-000EeQ-UZ for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 00:18:57 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h5J0IA6A046564; Thu, 19 Jun 2003 10:18:10 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306190018.h5J0IA6A046564@drugs.dv.isc.org> To: Matt Larson Cc: Edward Lewis , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wild cards and NS records In-reply-to: Your message of "Wed, 18 Jun 2003 15:06:21 -0400." <20030618190621.GQ2465@chinook.rgy.netsol.com> Date: Thu, 19 Jun 2003 10:18:09 +1000 X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Wed, 18 Jun 2003, Edward Lewis wrote: > > One, NS referrals are handled in step b of the algorithm, and wild > > cards are synthesized in step c. From this observation, NS's at a > > wild card ought not be 'seen' in the search unless the QTYPE matches > > NS. > > That is my interpretation of the algorithm. > > > There's a complication with NS that is not present with CNAME. When > > asking for the CNAME RR at a name, we get the authoritative answer. > > Swapping NS for CNAME here gives the non-authoritative name as the NS > > in the parent zone isn't the authoritative answer. Grumble. > > I'm sorry, but I'm having trouble parsing the last sentence of the > paragraph and relating the whole paragraph to the topic at hand. > > > Barring NS's from being at a wild card domain name isn't being > > suggested, but strongly discouraged. NS's have been legal for some > > time (well, since 1034) at wild cards. > > I'm not sure what you're implying. I agree that "*" for an owner name > of an NS RRset is legal, but I disagree that an implementation > following the algorithm in section 4.3.2 of RFC 1034 would support > wildcard NS records in any useful way. > > The wildcard secret sauce is in the final paragraph of step 3(c). > Here's all of 3(c) for completeness: > > c. If at some label, a match is impossible (i.e., the > corresponding label does not exist), look to see if a > the "*" label exists. > > If the "*" label does not exist, check whether the name > we are looking for is the original QNAME in the query > or a name we have followed due to a CNAME. If the name > is original, set an authoritative name error in the > response and exit. Otherwise just exit. > > If the "*" label does exist, match RRs at that node > against QTYPE. If any match, copy them into the answer > section, but set the owner of the RR to be QNAME, and > not the node with the "*" label. Go to step 6. > > Clearly, wildcard synthesis only occurs when the QTYPE of the query > matches the type of the wildcard. In other words, a wildcard > synthesis resulting from a wildcard NS RRset would only apply when > QTYPE is NS. This algorithm cannot generate a valid referral when > QTYPE is not NS. > > > It would take a serious > > detrimental impact on the protocol to now bar them > > I don't know that I agree with that, but I don't have enough data > about usage (or lack thereof) in the wild to back up my skepticism. > > > However, discouraging them seems to be a good idea. Synthesized > > delegations, if not done just right (as in to a name server that > > knows it will synthesizing zones for step 2 of its search algorithm) > > will likely lead to lame delegations. > > Synthesizing delegations is one thing, but that can't happen as a > result of the algorithm in section 4.3.2. The same is true of CNAME > processing--that happens before wildcard substitution in the algorithm > > I believe we either need to clarify the existing algorithm and point > out that it does not allow wildcard CNAME and NS records in the manner > they are sometimes implemented, or we need to change the algorithm to > allow them. I don't care either way, but the current discrepancy > between standard and practice is untenable. I'm afraid in particular > that ambiguity surrounding wildcard CNAME has repercussions for DNSSEC > validation. > > > So, the suggestion for this case is to state: > > > > o Name servers MAY reject (refuse to load) zones with any wild card domai > n > > name owning an NS RR set. > > o Name servers MAY refuse to accept updates to add NS RR sets to a wild > > card domain name. > > > > MAY, not MUST. ? > > I don't think this is the way to go. I believe this is your chain of > logic: > > 1. Wildcard NS records can be used to synthesize delegations. > 2. Synthesized delegations are fraught with danger (i.e., lame > delegations) and should be avoided by the unwary. > 3. Let us discourage them with the language I propose. > > My contention is that #1 is incorrect, so better alternatives would be > to either 1) explain that wildcard NS records only work when QTYPE=NS > (and a similar clarification/explanation for CNAME) or 2) change the > algorithm to support them in the way one intuitively expects them to > work. To make them work wild card NS record would hace to occult all other non DNSSEC types. Also "*" would have to be a single label match. You could have glue address records at the label but not below it. My preferred solution to wildcard NS records is a MUST NOT appear. The only place where I have seen them attempted is in the IN-ADDR.ARPA tree. Worst case senario is 256 delegations under IN-ADDR.ARPA. For IP6.ARPA it is 16. Named has $GENERATE to cope with this. I havn't looked to see what the other vendors have. > Matt > > -- > to 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 Jun 19 07:29: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 HAA08955 for ; Thu, 19 Jun 2003 07:29:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SxV7-000FUa-Ey for namedroppers-data@psg.com; Thu, 19 Jun 2003 11:22:45 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.14) id 19SxUy-000FTv-Sy for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 11:22:42 +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 h5JBMEr07640; Thu, 19 Jun 2003 18:22:15 +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 h5JBJGY01881; Thu, 19 Jun 2003 18:19:16 +0700 (ICT) From: Robert Elz To: Ralph Droms cc: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> References: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Jun 2003 18:19:16 +0700 Message-ID: <14436.1056021556@munnari.OZ.AU> X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 18 Jun 2003 09:12:03 -0400 From: Ralph Droms Message-ID: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> | That is, the important problem to avoid is cached DNS | information about an address that has been assigned | to a different host. Maybe there's something missing here, but I don't understand why this is supposed to be an important problem. That is, reworded, to make sure my understanding is correct, the problem to be avoided is having a name referring to an address that is now to be assigned to a different name ? Who cares? I mean, it is nice to have everything cleaned up, but there's nothing that can be done that can possibly guarantee that there isn't another name around referring to a particular address (there's no practical way to locate one - that would require IQUERY which we don't have...) The problem that you want to avoid, is having an old address still associated with the name to which a new address is being assigned. That's because it starts to be a gamble which address you will get when the name is looked up (depending upon which server happens to respond, and which cache contains what information). | Based on Ed's take on the problem, an alternative solution | to the TTL problem is to: | | * the DHCP server adds an RR for host H with TTL set | to some fixed value t | * the DHCP server removes the RR when the lease on the | address assigned to H expires at time T At this point, the old address for H is still potentially floating around the DNS until T+R+r*n+t (worst case, T+E+t) - where R is the "refresh" timer in the SOA, 'r' is the retry timer, n is the number of refresh retries it takes (n >= 0), and 'E' is the zone expire timer). | * the DHCP server does not make the address previously | assigned to H available for reassignment until T+t That achieves nothing useful in any practical sense. What is needed would be to not assign H a new (different) address until after (at least T+t) (but to be ultra safe, T+E+t). Of course, doing that means causing H to be without an address for something (which in some zones) may be as long as a month. Hardly practical. | Another observation - is it possible that the issue of | stale cached DNS information has never been an issue | in practice because DNS information installed by a DHCP | server is rarely used, so that stale DNS information | is insignificant? Most likely, yes. If 't' isn't set very large (which for dynamically assigned addresses it should not be) and the DNS servers communicate with each other properly, the only effect is that someone attempting to contact the host with the dnuamic address, by name, might fail for a while after a new assignment has been made. Most hosts with dynamic addresses aren't contacted by name anyway. | If the RRs installed by the DHCP server are rarely queried, | another alternative would be to simply set the TTL to 0, | or to set the TTL initially to t, and then t seconds | before the expiration of the lease on the address, set | the TTL to 0. Those can help, but the 't' interval isn't really the one to worry about, the hard case is where a secondary server has the old information and then loses contact with the primary server - and you have to wait for its copy of the zone to expire before it stops handing out the bad address. | It seems that the guidance currently given in | draft-ietf-dhc-ddns-resolution-05 will lead to a period | of time equal to 1/3 the original lease time during | which cached DNS data may associate a DNS name with | an IP address that has been reassigned to a different | host. This potential problem may not have been realized | in practice because the DNS information about a host | updated by a DHCP server is rarely queried. That potential problem hasn't been realised because no-one would care in the slightest if it happened. This is simply irrelevant. I'm sure the problem of attempting to contact a host, and being told to try its previous address, has been seen, but rarely. 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 Jun 19 07:42: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 HAA09936 for ; Thu, 19 Jun 2003 07:42:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sxhq-000GDF-Cj for namedroppers-data@psg.com; Thu, 19 Jun 2003 11:35:54 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.14) id 19Sxhn-000GCy-TK for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 11:35:51 +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 h5JBZKbd008938; Thu, 19 Jun 2003 07:35:21 -0400 (EDT) Message-ID: <004101c33656$de3af900$b9370681@barnacle> From: "Scott Rose" To: "Sam Weiler" , References: Subject: Re: Keeping the KEY and SIG typecodes active Date: Thu, 19 Jun 2003 07:35:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One thing I am unsure of: Is there a widely deployed base of DS-aware resolvers out there now that won't update with the typecode rollover? I ask this because if a DS-aware resolver/recursive server sees a DS, it will know to look for a KEY RR in the child zone, and not a DNSKEY RR. I don't think this will be a big problem at all, but thinking "that'll never happen!" usually comes right before the buglike alien starts chewing the space crew... Scott ----- Original Message ----- From: "Sam Weiler" To: Sent: Wednesday, June 18, 2003 3:50 PM Subject: Re: Keeping the KEY and SIG typecodes active > On Tue, 17 Jun 2003, Sam Weiler wrote: > > > > Keeping KEY worries me a bit more, since it will appear in-zone and > > some 2535-aware things pay attention to it. Must we really keep it? > > Do any of the SIG(0) _clients_ actually look at KEYs? > > In thinking about this more: if a zone includes KEY RRs, > > 1) there should be no bad interactions with DS-aware (and > DNSKEY-aware) code. DS-aware code should do the right thing > with KEYs. > > 2) if there are bad interactions with 2535-aware code, then > those interactions are already out there -- this draft isn't > causing them. And if things need to be fixed later, then they > can be fixed later. > > So I see no new harm in leaving KEY for SIG(0) use. Absent further > commentary, -03 will retain KEY for SIG(0) use only. > > -- Sam > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 19 08:01: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 IAA11061 for ; Thu, 19 Jun 2003 08:01:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Sy3y-000HUm-UU for namedroppers-data@psg.com; Thu, 19 Jun 2003 11:58:46 +0000 Received: from [204.254.155.100] (helo=sentry.rv.nailabs.com ident=firewall-user) by psg.com with esmtp (Exim 4.14) id 19Sy3w-000HUV-PJ for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 11:58:44 +0000 Received: by sentry.rv.nailabs.com; id IAA02689; Thu, 19 Jun 2003 08:00:09 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma002673; Thu, 19 Jun 03 07:59:45 -0400 Received: from localhost (weiler@localhost) by raven.rv.nailabs.com (8.11.6p2/8.11.6) with ESMTP id h5JBtdX19964; Thu, 19 Jun 2003 07:55:39 -0400 (EDT) X-Authentication-Warning: raven.rv.nailabs.com: weiler owned process doing -bs Date: Thu, 19 Jun 2003 07:55:39 -0400 (EDT) From: Sam Weiler X-X-Sender: To: Scott Rose cc: Subject: Re: Keeping the KEY and SIG typecodes active In-Reply-To: <004101c33656$de3af900$b9370681@barnacle> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 19 Jun 2003, Scott Rose wrote: > Is there a widely deployed base of DS-aware resolvers out there now that > won't update with the typecode rollover? I ask this because if a DS-aware > resolver/recursive server sees a DS, it will know to look for a KEY RR in > the child zone, and not a DNSKEY RR. As far as I know, no. Besides, if there were, the problem would probably not appear at a delegation; it would appear at a secure entry point. ("Hey -- I have a trusted key configured for .com and the zone doesn't have an apex KEYset. Or SIGs. Maybe I should SERVFAIL now.") -- 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 Jun 19 08: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 IAA15211 for ; Thu, 19 Jun 2003 08:49:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19SynR-000JiL-73 for namedroppers-data@psg.com; Thu, 19 Jun 2003 12:45:45 +0000 Received: from [131.254.130.36] (helo=sky.irisa.fr) by psg.com with esmtp (Exim 4.14) id 19SynO-000Ji3-4l for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 12:45:42 +0000 Received: from irisa.fr (medoc.irisa.fr [131.254.70.2]) by sky.irisa.fr (8.11.4/8.11.4) with ESMTP id h5JCjUp18632; Thu, 19 Jun 2003 14:45:34 +0200 (MET DST) Message-ID: <3EF1B06A.8000804@irisa.fr> Date: Thu, 19 Jun 2003 14:45:30 +0200 From: Gilles Guette Organization: Irisa/Inria - Rennes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr, en MIME-Version: 1.0 To: Mike StJohns CC: Olivier Courtay , namedroppers@ops.ietf.org Subject: Re: Comment on draft-stjohns-secure-notify-00 References: <5.2.1.1.2.20030618154112.026f7fa8@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Mike StJohns wrote: > Hi Olivier... > > Some problems with your approach: > > At 09:20 6/18/2003, Olivier Courtay wrote: > > >> For example for the DS records update case, we have the following >> scenario: >> - child send a NOTIFY (including only his SOA record), > > > Won't work - see below... child needs to send a notify which points at > either the KEY or NS records. SNIP > This goes back to my "won't work" comment. The parent zone does not and > should not contain a copy of the child SOA. Without this, the parent > doesn't have the old serial number so it can't figure out if it needs to > do a retrieval. There are also a *lot* of changes in the child zone > that the parent doesn't and shouldn't care about - the parent ONLY > cares about changes to glue NS and the KEY records pointed to by the DS > records it holds. However, the serial number MUST change with ANY > change in the zone contents. The use of serial number was just an optimization. It wasn't a problem if you don't use serial number. Moreover if you want to use serial number verification, parent don't care about every serial number changes. It do it ONLY if it receives a NOTIFY. >> - parent has checked the child zone configuration status and the >> chain of trust is validated. > > > How is this different from the entity who holds the KSK or ZSK sending a > NOTIFY which chains to the DS held by the parent for the child zone? > And as above, the parent shouldn't care about the child zone > configuration, only about the glue it holds that points to the child zone. > >> For NS record update, Notify and changes validation are used on the >> same manner. >> For NS record update, two solutions: if the private key is present on >> the server, it can immediately sign the zone with new glue (Automatic >> case) or put in a file the new glue for this child (in the same manner >> than a keyset file) which will take effect after the next zone >> signature (Manual case). > > > Per RFC2535 and its replacement - the NS records at the parent aren't > signed by the parent (emphasis mine): > > > "Every name in a secured zone will have associated > with it at least > one SIG resource record for each resource type under that > name EXCEPT > for glue address RRs and delegation point NS RRs. > " We know this text but tell my if I'm wrong, in the child zone NS RR are signed. This NS RR and SIG(RR) can be retrieve by parent zone in order to verify their validity. After validation NS RR (glue) are included in the parent zone file, without SIG(NS). This method avoid the use of SIG(0) that is not, in my opinion, a simple process. > One day I'm going two write a "how to design a protocol" and three > things that will go in it are the "Complexity Principle", the > "Selfishness Principle" and the "Load Balancing" principle. > > 1) Complexity Principle: When facing two separate choices to accomplish > the same thing in a protocol, generally the simpler choice is the > correct choice. > > Having to have yet another service/server act as a proxy to the parent > to do this is an order of magnitude increase in complexity and probably > not a good idea unless there's a substantial benefit. Using such a service is to protect against eventual DoS attack and not increase the burden on the the parent name server but this is not the heart of our method, we can totally include this service in parent server. SNIP >> The problem is that these methods can not be used for the >> initialization of the chain of trust, i.e. the first time a zone is >> secured. >> At the beginning of the DNS delegation, the parent can not identify >> his child because no DS exists. > > > Yup - this is the general enrollment problem. Not being considered > here. I assume there are some manual interactions that need to take > place to do the original delegation, but that once that's done I want > the key management system (e.g. the DNSSEC system) to do the right thing > as keys change. OK > Later, Mike -- Olivier COURTAY Research engineer IDsA Project (www.idsa.prd.fr ) ENST Bretagne( www.enst-bretagne.fr ) Gilles GUETTE Ph.D student Armor Project Irisa/Inria (www.irisa.fr ) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 19 09:47: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 JAA17790 for ; Thu, 19 Jun 2003 09:47:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Szh9-000M8v-SW for namedroppers-data@psg.com; Thu, 19 Jun 2003 13:43:19 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.14) id 19Szh5-000M7F-Kx for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 13:43:15 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 231112FD; Thu, 19 Jun 2003 09:42:45 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id BB4C2171 for ; Thu, 19 Jun 2003 09:42:44 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 409468; Thu, 19 Jun 2003 09:39:23 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: Date: Thu, 19 Jun 2003 09:42:46 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Fwd: Re: NOTIFY + SIG(0) + DS => secure parent update? Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-7.2 required=5.0 tests=BAYES_01,SIGNATURE_SHORT_SPARSE version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This was part of a private discussion a few weeks ago, and it was suggested that this appear on the list before the next edit of SEP comes out. >Date: Fri, 30 May 2003 14:02:31 -0400 >To: a bunch of folks >From: Edward Lewis >Subject: Re: NOTIFY + SIG(0) + DS => secure parent update? > >Quoting the -06 version's intro, which seems to have fallen out of >the -07 (my fault): > ># There is a need to differentiate between a KSK and a ZSK by the zone ># administrator. This need is driven by knowing which keys are to be ># sent for DS RRs, which keys are to be distributed to resolvers, and ># which keys are fed to the signer application at the appropriate time. > >That is the requirement motivating the draft. Evidently it needs to go back >in. Here are some other comments: >The DNS protocol is not just exchanged between resolvers (which, when >architecturally dissected reveals, e.g., the verifier) and servers (which >can similarly be dissected to reveal the authoritative data storage). The >SEP flag is to be of no interest to the flow between the verifier and the >authoritative data store. > >The SEP flag is important in the flow into the signer application and then >from the signer to resolver configuration and signer to the parent's key >collector. These flows are not well automated, so it may not be obvious. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 19 10:01: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 KAA18754 for ; Thu, 19 Jun 2003 10:01:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Szuv-000NNN-Du for namedroppers-data@psg.com; Thu, 19 Jun 2003 13:57:33 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.14) id 19Szus-000NKJ-VH for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 13:57:31 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id AC701312; Thu, 19 Jun 2003 09:57:00 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 59D066A for ; Thu, 19 Jun 2003 09:57:00 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 409497; Thu, 19 Jun 2003 09:53:39 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <004101c33656$de3af900$b9370681@barnacle> References: <004101c33656$de3af900$b9370681@barnacle> Date: Thu, 19 Jun 2003 09:57:01 -0400 To: From: Edward Lewis Subject: Re: Keeping the KEY and SIG typecodes active Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:35 -0400 6/19/03, Scott Rose wrote: >One thing I am unsure of: > >Is there a widely deployed base of DS-aware resolvers out there now that >won't update with the typecode rollover? The only versions of BIND that support DS have been snapshots. I've not seen any other code (non-BIND) made public that did DS. (Anyone who uses a snapshot version of BIND in production is likely to buy expired milk products on a regular basis.) >I don't think this will be a big problem at all, but thinking "that'll never >happen!" usually comes right before the buglike alien starts chewing the >space crew... That's it, no more MST3000 episodes for you until the Vienna meetings. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 19 10:36: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 KAA21886 for ; Thu, 19 Jun 2003 10:36:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T0Qw-0001Kg-0e for namedroppers-data@psg.com; Thu, 19 Jun 2003 14:30:38 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19T0Qs-0001Fw-Ma for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 14:30:34 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5JEU3Lv003767 for ; Thu, 19 Jun 2003 07:30:03 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5JEU0Q15225; Thu, 19 Jun 2003 16:30:00 +0200 (MEST) Date: Thu, 19 Jun 2003 16:29:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Change of chairs To: Erik.Nordmark@sun.com Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After long service as the co-chair of DNSIND and DNSEXT working groups Randy Bush has decided to step down as chair. Many thanks to Randy for this long and dedicated service. Olaf Kolkman has generously offered to co-chair together with Olafur. Welcome Olaf. The chair transition will happen between now and the meeting in Vienna so you might see all 3 acting as chairs over the next few weeks. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 19 11: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 LAA24306 for ; Thu, 19 Jun 2003 11:16:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T10q-0005XE-HR for namedroppers-data@psg.com; Thu, 19 Jun 2003 15:07:44 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19T10l-0005Wv-Eh for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 15:07:40 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19855; Thu, 19 Jun 2003 10:11:55 -0400 (EDT) Message-Id: <200306191411.KAA19855@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-delegation-signer-15.txt Date: Thu, 19 Jun 2003 10:11:55 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Delegation Signer Resource Record Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-delegation-signer-15.txt Pages : 16 Date : 2003-6-19 The delegation signer (DS) resource record is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and the implications of this record on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC1035, RFC2535, RFC3008 and RFC3090. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-delegation-signer-15.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-delegation-signer-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19103046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-delegation-signer-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-delegation-signer-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19103046.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 19 11:17: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 LAA24440 for ; Thu, 19 Jun 2003 11:17:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T16C-0005rn-Kr for namedroppers-data@psg.com; Thu, 19 Jun 2003 15:13:16 +0000 Received: from [209.116.252.130] (helo=one.elistx.com) by psg.com with esmtp (Exim 4.14) id 19T16A-0005rV-Ke for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 15:13:14 +0000 Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0HGQ00DPKIBKNU@eListX.com> for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 11:14:08 -0400 (EDT) Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.8p1/8.12.8) with ESMTP id h5JFD9HT025596 for ; Thu, 19 Jun 2003 11:13:09 -0400 (EDT envelope-from ogud@ogud.com) Date: Thu, 19 Jun 2003 10:59:29 -0400 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: WG administrate X-Sender: (Unverified) To: namedroppers@ops.ietf.org Message-id: <5.1.1.6.2.20030619104458.02b19798@localhost> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_10,RCVD_IN_RFCI version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Thanks, to Randy for his long service as DNSIND and DNSEXT working group chair. Please welcome Olaf as the new co-chair. I will be off the air until the meeting in Vienna, Olaf will take care of scheduling for the meeting, he has all the ones I have received so far. Olaf will also take the lead on getting the new charter for the working group done, expect a draft of a charter in the next few days. thanks, Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 19 17:42: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 RAA20258 for ; Thu, 19 Jun 2003 17:42:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T74Y-0003hw-Sv for namedroppers-data@psg.com; Thu, 19 Jun 2003 21:35:58 +0000 Received: from [64.102.124.12] (helo=rtp-core-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19T74V-0003fD-LH for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 21:35:55 +0000 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JLYmO1009111; Thu, 19 Jun 2003 17:34:49 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-720.cisco.com [10.82.242.208]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id RAA02180; Thu, 19 Jun 2003 17:34:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20030619173047.047deaf0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 17:33:07 -0400 To: Ted Lemon From: Ralph Droms Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: Robert Elz , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <200306191240.56057.mellon@fugue.com> References: <14436.1056021556@munnari.OZ.AU> <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I agree with Ted ... in fact, I had a conversation about exactly this problem earlier today. In theory, any application shouldn't depend on just DNS to identify and establish contact with the correct endpoint (server). In practice, we have many such applications deployed today, so we should be careful not to provide another path for breakage... - Ralph At 12:40 PM 6/19/2003 -0500, Ted Lemon wrote: >On Thursday 19 June 2003 06:19, Robert Elz wrote: > > That is, reworded, to make sure my understanding is correct, the > > problem to be avoided is having a name referring to an address that > > is now to be assigned to a different name ? > > > > Who cares? > >Let's say machine X has an SMTP listener, and machine Y also has an SMTP >listener. Machine X gets an IP address, Z, from the DHCP server. Then the >owner of Machine X wanders away, leaving the lease active. The lease >expires, and then machine Y gets the address. But there is still an A >record for machine X pointing at IP address Z. So now, machine Q connects >to Z because of that A record, and tries to drop mail for X on Y. Y will >either bounce it immediately, or bounce it after it notices that the A record >for X is pointing at it. So we'd really like it if the time that the A >record goes away and the time that the lease goes away are fairly close >together, so that the chances of this happening are slim. > >Of course, I would say that this is a broken configuration anyway - you >really >want to use protocols that verify who they're talking to if you have a mobile >computer. But that's the basis for caring about this sort of thing, and >while I don't think we can completely solve the problem, it's worth setting >things up to minimize the damage that occurs in cases like this. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 19 17:45:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20518 for ; Thu, 19 Jun 2003 17:45:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T79o-0003wU-G3 for namedroppers-data@psg.com; Thu, 19 Jun 2003 21:41:24 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19T79m-0003wE-5h for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 21:41:22 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19T79l-000G7f-4t for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 14:41:21 -0700 References: <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> In-Reply-To: <14436.1056021556@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306191240.56057.mellon@fugue.com> From: Ted Lemon To: Robert Elz Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Date: Thu, 19 Jun 2003 12:40:56 -0500 Cc: dhcwg@ietf.org, namedroppers@ops.ietf.org X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] On Thursday 19 June 2003 06:19, Robert Elz wrote: > That is, reworded, to make sure my understanding is correct, the > problem to be avoided is having a name referring to an address that > is now to be assigned to a different name ? > > Who cares? Let's say machine X has an SMTP listener, and machine Y also has an SMTP listener. Machine X gets an IP address, Z, from the DHCP server. Then the owner of Machine X wanders away, leaving the lease active. The lease expires, and then machine Y gets the address. But there is still an A record for machine X pointing at IP address Z. So now, machine Q connects to Z because of that A record, and tries to drop mail for X on Y. Y will either bounce it immediately, or bounce it after it notices that the A record for X is pointing at it. So we'd really like it if the time that the A record goes away and the time that the lease goes away are fairly close together, so that the chances of this happening are slim. Of course, I would say that this is a broken configuration anyway - you really want to use protocols that verify who they're talking to if you have a mobile computer. But that's the basis for caring about this sort of thing, and while I don't think we can completely solve the problem, it's worth setting things up to minimize the damage that occurs in cases like 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: From owner-namedroppers@ops.ietf.org Thu Jun 19 17:48: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 RAA20699 for ; Thu, 19 Jun 2003 17:48:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T7E4-0004En-Tj for namedroppers-data@psg.com; Thu, 19 Jun 2003 21:45:48 +0000 Received: from [203.146.155.25] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.14) id 19T7Dz-0004EG-1m for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 21:45:44 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h5JLiqlw018239; Fri, 20 Jun 2003 04:44:52 +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 h5JLcPF14809; Fri, 20 Jun 2003 04:38:27 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <200306191240.56057.mellon@fugue.com> References: <200306191240.56057.mellon@fugue.com> <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jun 2003 04:38:25 +0700 Message-ID: <22680.1056058705@munnari.OZ.AU> X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 19 Jun 2003 12:40:56 -0500 From: Ted Lemon Message-ID: <200306191240.56057.mellon@fugue.com> | So now, machine Q connects to Z because of that A record, and tries | to drop mail for X on Y. Y will either bounce it immediately, | or bounce it after it notices that the A record for X is pointing at it. And if the A record had been deleted, the mail would just have bounced. That's a lot of diffrence... (yes, I know in the latter case there could be a lower priority MX, which would take the mail, but then it would ...) | So we'd really like it if the time that the A | record goes away and the time that the lease goes away are fairly close | together, so that the chances of this happening are slim. No problem with that, I agree that cleanup is a good idea, and getting rid of old stuff ought be done. I just don't see the particular problem as being anything so serious that it warrants particular attention. That is, the more serious problem is not being able to connect to a host that you should be able to connect to, because you were given an out of date address, than not being able to connect to a host that you cannot possibly connect to anyway, because its address is now in use by someone different. | Of course, I would say that this is a broken configuration anyway Agree, but broken or not, those are configurations that people use, so if it did cause serious problems, we'd need to worry about, and fix them. I just don't see the problems as so serious that anyone needs to devote much attention to them. Or, put it another way, anyone, anywhere, can stick any address in a A (or AAAA) record. That can easily cause some random other name to refer to a host which has its own name mapped to the same address. This is with or without DHCP being involved. You cannot possibly hope to make that name go away, or change its A record (you cannot even find it). I suspect though, that if the dhcp server, when updating the DNS, does the best job it can to make sure that old addresses aren't floating around for the name it is managing, that will (by some happy co-incidence) also cause the problem that was mentioned as being serious (which isn't) to get solved at the same time. That is, there are 2 names involved, each being managed by a separate instance of the state machine - rather than having one of those attempt to clean up the other one (by not allowing the address to be allocated for an extra delay period - which would be a nightmare in some address deprived environments) just allow each to clean up after itself. That way the old address for name X gets deleted, when the lease expires, or as close to that as practical, which also means that X no longer has the address that we want to now assign to Y, and we don't have to delay that assignment to make it happen. 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 Jun 19 18:10: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 SAA22459 for ; Thu, 19 Jun 2003 18:10:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T7ZA-0005Zp-28 for namedroppers-data@psg.com; Thu, 19 Jun 2003 22:07:36 +0000 Received: from [64.102.124.12] (helo=rtp-core-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19T7Z7-0005Yl-9d for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 22:07:33 +0000 Received: from mjs-w2k01.cisco.com ([10.86.146.21]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5JM6SO2017321; Thu, 19 Jun 2003 18:06:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20030619174731.01fe6eb8@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jun 2003 18:06:23 -0400 To: Ted Lemon From: Mark Stapp Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: Robert Elz , dhcwg@ietf.org, namedroppers@ops.ietf.org In-Reply-To: <200306191240.56057.mellon@fugue.com> References: <14436.1056021556@munnari.OZ.AU> <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Would this be a reasonable summary of the discussion on this topic? 1. the looseness of the coupling among primary, secondary, and caching dns servers makes it unrealistic to guarantee that no query will see stale records. the deployment experience that we have does not indicate that this is a problem. 2. this section of the draft should make the issues about dns ttls and caching more explicit, so that it's clearer what the operational consequences of 'stale' records might be. I'll add text about the benefits to removing dhcp-added dns records when leases expire. 3. the simple ttl guidelines that are in the draft are present to give implementors (and administrators) some clue about reasonable ranges and defaults. the guidelines are meant to help folks avoid hare-brained configurations (what Robert calls "minimizing damage"); the guidelines aren't intended to provide a guarantee about how long it may be before changes to the dns become universally visible. 4. it's not worthwhile to impose new requirements on DHCP servers to put names or addresses in limbo in some way for some period of time after leases expire. -- Mark At 12:40 PM 6/19/2003 -0500, Ted Lemon wrote: >On Thursday 19 June 2003 06:19, Robert Elz wrote: > > That is, reworded, to make sure my understanding is correct, the > > problem to be avoided is having a name referring to an address that > > is now to be assigned to a different name ? > > > > Who cares? > >Let's say machine X has an SMTP listener, and machine Y also has an SMTP >listener. Machine X gets an IP address, Z, from the DHCP server. Then the >owner of Machine X wanders away, leaving the lease active. The lease >expires, and then machine Y gets the address. But there is still an A >record for machine X pointing at IP address Z. So now, machine Q connects >to Z because of that A record, and tries to drop mail for X on Y. Y will >either bounce it immediately, or bounce it after it notices that the A record >for X is pointing at it. So we'd really like it if the time that the A >record goes away and the time that the lease goes away are fairly close >together, so that the chances of this happening are slim. > >Of course, I would say that this is a broken configuration anyway - you >really >want to use protocols that verify who they're talking to if you have a mobile >computer. But that's the basis for caring about this sort of thing, and >while I don't think we can completely solve the problem, it's worth setting >things up to minimize the damage that occurs in cases like this. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 19 20:03: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 UAA26191 for ; Thu, 19 Jun 2003 20:03:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19T9Ig-0009sj-10 for namedroppers-data@psg.com; Thu, 19 Jun 2003 23:58:42 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.14) id 19T9Ib-0009sG-G9 for namedroppers@ops.ietf.org; Thu, 19 Jun 2003 23:58:37 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 04BAF33F; Thu, 19 Jun 2003 19:58:06 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 8DD3732F; Thu, 19 Jun 2003 19:58:06 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 411438; Thu, 19 Jun 2003 19:54:43 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.2.20030619174731.01fe6eb8@goblet.cisco.com> References: <14436.1056021556@munnari.OZ.AU> <4.3.2.7.2.20030618091029.00b76578@funnel.cisco.com> <14436.1056021556@munnari.OZ.AU> <4.3.2.7.2.20030619174731.01fe6eb8@goblet.cisco.com> Date: Thu, 19 Jun 2003 19:55:15 -0400 To: Mark Stapp From: Edward Lewis Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Cc: Ted Lemon , Robert Elz , dhcwg@ietf.org, namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 18:06 -0400 6/19/03, Mark Stapp wrote: >Would this be a reasonable summary of the discussion on this topic? > >1. the looseness of the coupling among primary, secondary, and caching dns >servers makes it unrealistic to guarantee that no query will see stale >records. the deployment experience that we have does not indicate that this >is a problem. That's certainly true. My suggestion neglected the fact that a slave server could be out of date with respect to a master. (It's a problem less and less though with NOTIFY, but it's a possibility still.) >2. this section of the draft should make the issues about dns ttls and caching >more explicit, so that it's clearer what the operational consequences of >'stale' records might be. I'll add text about the benefits to removing >dhcp-added dns records when leases expire. Yup. >3. the simple ttl guidelines that are in the draft are present to give >implementors (and administrators) some clue about reasonable ranges and >defaults. the guidelines are meant to help folks avoid hare-brained >configurations (what Robert calls "minimizing damage"); the guidelines aren't >intended to provide a guarantee about how long it may be before changes to >the dns become universally visible. Yup. >4. it's not worthwhile to impose new requirements on DHCP servers to put names >or addresses in limbo in some way for some period of time after leases expire. Perhaps, I suppose that it isn't DHCP's problem if the DNS has too much persistence...;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 20 05:53: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 FAA23293 for ; Fri, 20 Jun 2003 05:53:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TISc-0006lI-CV for namedroppers-data@psg.com; Fri, 20 Jun 2003 09:45:34 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.14) id 19TISZ-0006l2-KD for namedroppers@ops.ietf.org; Fri, 20 Jun 2003 09:45:31 +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 h5K9jCr11939; Fri, 20 Jun 2003 16:45: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 h5K9iFH25906; Fri, 20 Jun 2003 16:44:15 +0700 (ICT) From: Robert Elz To: Michael Richardson cc: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> References: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jun 2003 16:44:14 +0700 Message-ID: <15427.1056102254@munnari.OZ.AU> X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 19 Jun 2003 21:03:52 -0400 From: Michael Richardson Message-ID: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> First, Mark's summary looked fine to me. But ... | As such, what I really want is a dynamic update operation which actually | says "install this record with TTL=XXX, deleting the record after YYY" | (Clearly, XXX < YYY, and some may argue YYY:=XXX. I'm undecided) The XXX & YYY relationship isn't important here but XXX << YYY (in the mathematical << sense, not "shift left") if this were to have any hope of working. But yes, that's what almost everyone wanted when dynamic update was being defined - and a lot of effort was spend attempting to find something which would actually work like that. Unfortunately, nothing reliable could be found, so that is not what exists. You can try and dream up a protocol to allow this to work, but first please go and review all the archives from when dynamic update was being designed, and then again since then whenever anyone has suggested it since - it is not nearly as simple to make work properly as it seems it should be - and if it can't be guaranteed to work, then the host has to deal with it other ways anyway. | I have really no problem sending a new update every couple of minutes. | In fact, I'd prefer to do this. Unfortunately, by itself, that doesn't help - that was the original plan for this (you need to investigate the way the whole DNS works, including the primary/secondary relationship, and servers that crash at inconvenient times, to see the problems). 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 Jun 20 11:41: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 LAA13457 for ; Fri, 20 Jun 2003 11:41:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TNqu-000JTM-0f for namedroppers-data@psg.com; Fri, 20 Jun 2003 15:31:00 +0000 Received: from [64.102.124.12] (helo=rtp-core-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19TNqr-000JSC-8k for namedroppers@ops.ietf.org; Fri, 20 Jun 2003 15:30:57 +0000 Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5KFTrO1029480; Fri, 20 Jun 2003 11:29:54 -0400 (EDT) Received: from cisco.com ([161.44.65.124]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA20087; Fri, 20 Jun 2003 11:29:52 -0400 (EDT) Message-ID: <3EF32870.1040007@cisco.com> Date: Fri, 20 Jun 2003 11:29:52 -0400 From: Josh Littlefield User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms CC: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [3]: Resolving conflicts between updates to A and AAAA records References: <4.3.2.7.2.20030606002703.03d40c28@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ralph Droms wrote: > DDNS-DHCP issue: > > The interaction between DHCPv4 and DHCPv6 needs to be carefully > defined. Suppose a DHCPv4 server updates the A RR and a DHCPv6 > server updates the AAAA RR of the same node? How is the conflict > in the use of the DHCID RR for that node resolved? With the current definition of the DHCID RR and the proposed algorithm in draft-ietf-dhc-ddns-resolution-05.txt, there is clearly an issue to be resolved. The resolution could take the form of changing the DHCID RR definition to be v4-only, and adding a new DHCIDv6 RR for v6, or if could take the form of changing the algorithm in the dhc-ddns I-D. The issue is the algorithm's implicit expectation that just one DHCID RR will be present on a name. That may not be the case for a dual-stack client, where 2 different DHCID RRs would be generated. The implicit expectation that DHCID is effectively a singleton occurs in 2 places in the algorithm: 1) In 6.1 (Adding A RRs): The first update asserts the name does not exist. Failing that, the next update asserts the name exists with the expected DHCID. When this fails (as it will if a v6 DHCID is already there with now v4 DHCID), the entire update fails, concluding the name is in use by someone else. This second update will also fail if the anticipated v4 DHCID is already there, but a v6 DHCID is there as well. This is because DNS Update does not allow one to assert the presence of only one RR in an RR set. Instead, one must assert the entire RR set looks a certain way. So for this second update to succeed, it would need to include the v6 DHCID RR. 2) In 6.3 (Removing Entries): Again, an assertion problem with the DHCID (in the case of removing A/AAAA records). To succeed, the assertion would have to include all DHCID RRs on the name. In order to allow the coexistence of both v4 and v6 DHCID RRs on the same name, the algorithm would need change, to add additional steps, as follows: In 6.1, the last paragraph (before the DISCUSSION), on receiving NXRRSET to the second query (Update), the updater would then need to send a Query to learn the existing DHCID RR set on the name. The updater would then need to examine this DHCID RR set, and determine whether the update should, or should not occur. Most likely, the only case in which the update should occur is when the updater is able to determine that the existing DHCID RRs correspond to the same DHCP client. (This is not an easy determination to make if, for example, a v6 DHCID RR exists when making a v4 update, unless the updater generated the existing DHCID RR.) If it is determined by the updater that the update should proceed, the update sent should employ prerequisites asserting the state of the entire existing DHCID RR set. This is to ensure the RR set has not changed, since its state formed the basis for the update decision. A similar additional 2 steps (query and update) would need to be added to section 6.3 when removing A or AAAA RRs. I believe it may be acceptable to make these additional steps optional, at least in the forward (A, AAAA) update case. An v4 (or v6) updater who finds an existing v6 (or v4) DHCID RR may be unable to tell that the existing RR corresponds to the same client, since the RR data is a hash of something that updater doesn't know. So querying the existing DHCID RRs may provide no information to persuade the updater to update that name. By not implementing the additional algorithm steps, that updater would be implementing a strict policy of name segregation, which may be the best it can do. Clearly, an updater than can determine that v4 and v6 DHCID RRs correspond to the same client (most likely because it was the source of both) should implement the additional steps. There may be benefit to recommending (in a separate document?) that dual stack DHCP clients form DUIDs and client-IDs from the same data, to increase the likelihood that an updator would be able to predict the data of a v6 DHCID from a v4 DHCP packet, and vice versa. -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 20 15: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 PAA05009 for ; Fri, 20 Jun 2003 15:53:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TRqk-000AUX-3h for namedroppers-data@psg.com; Fri, 20 Jun 2003 19:47:06 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19TRqg-000AUJ-5W for namedroppers@ops.ietf.org; Fri, 20 Jun 2003 19:47:02 +0000 Received: (qmail 50841 invoked by uid 1016); 20 Jun 2003 19:47:34 -0000 Date: 20 Jun 2003 19:47:34 -0000 Message-ID: <20030620194734.50840.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length References: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> <15427.1056102254@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk tinydns has supported time-to-die since version 0.85 in February 2000. It automatically reduces the TTL as the time-to-die approaches, and then eliminates the record. See http://cr.yp.to/djbdns/tinydns-data.html. The obsolete AXFR replication protocol is unable to copy time-to-die information. This is one of the many reasons that I recommend rsync for replication. See http://cr.yp.to/djbdns/tcp.html#intro-axfr. Client systems running the clueless ``nscd'' program will keep data for an hour no matter what the TTL says, but at least there's some limit. Perhaps nscd will be fixed someday. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 20 17:01: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 RAA08675 for ; Fri, 20 Jun 2003 17:01:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TStm-000EBW-Ax for namedroppers-data@psg.com; Fri, 20 Jun 2003 20:54:18 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.14) id 19TSte-000EAM-2L for namedroppers@ops.ietf.org; Fri, 20 Jun 2003 20:54:10 +0000 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 01E701B2003; Fri, 20 Jun 2003 15:52:27 -0500 (CDT) From: Ted Lemon To: "D. J. Bernstein" , dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Date: Fri, 20 Jun 2003 10:54:05 -0500 User-Agent: KMail/1.5 References: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> <15427.1056102254@munnari.OZ.AU> <20030620194734.50840.qmail@cr.yp.to> In-Reply-To: <20030620194734.50840.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306201054.05150.mellon@nominum.com> X-Spam-Status: No, hits=-32.2 required=5.0 tests=BAYES_01,DATE_IN_PAST_03_06,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Friday 20 June 2003 14:47, D. J. Bernstein wrote: > tinydns has supported time-to-die since version 0.85 in February 2000. > It automatically reduces the TTL as the time-to-die approaches, and then > eliminates the record. See http://cr.yp.to/djbdns/tinydns-data.html. We discussed and rejected time-to-die as a solution to this problem a couple of meetings back (I think in Tokyo) because we were concerned that if you do something like this, the effect is going to be a refresh storm as the time to die gets closer. So I'm very interested to know that somebody has actually tried this experiment. What's your experience with this - do you have any measurements about what happens in practice as the time to die approaches? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 20 18:20: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 SAA12878 for ; Fri, 20 Jun 2003 18:20:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TU8N-000I5x-Aq for namedroppers-data@psg.com; Fri, 20 Jun 2003 22:13:27 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.14) id 19TU8G-000I4Z-TB for namedroppers@ops.ietf.org; Fri, 20 Jun 2003 22:13:20 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 0965B13948 for ; Fri, 20 Jun 2003 22:13:08 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: Message from Ted Lemon of "Fri, 20 Jun 2003 10:54:05 EST." <200306201054.05150.mellon@nominum.com> X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Fri, 20 Jun 2003 22:13:08 +0000 Message-Id: <20030620221308.0965B13948@sa.vix.com> X-Spam-Status: No, hits=-8.3 required=5.0 tests=BAYES_10,DRASTIC_REDUCED,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,SEARCH_ENGINE_PROMO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > tinydns has supported time-to-die since version 0.85 in February 2000. > > It automatically reduces the TTL as the time-to-die approaches, and then > > eliminates the record. See http://cr.yp.to/djbdns/tinydns-data.html. > > We discussed and rejected time-to-die as a solution to this problem a > couple of meetings back (I think in Tokyo) because we were concerned > that if you do something like this, the effect is going to be a > refresh storm as the time to die gets closer. ... when the i-d below was proposed, time-to-die was roundly dismissed, for that reason and plenty of others. DNSIND Working Group Paul Vixie (ISC) INTERNET-DRAFT May 1996 Amends: RFC 1035, [UPDATE] Deferred Dynamic Updates in the Domain Name System (DNS DEFUPD) Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Not all applications that perform dynamic updates using the protocol specified in [UPDATE] want their updates applied immediately. A case in point is [DHCP], wherein the DHCP lease time should control the lifetime of associated DNS data even if the DHCP client or server is not available at the time the DHCP lease expires. The essence of this proposal is that DNS Dynamic Updates should be deferrable for some time delay period, after which they will be executed normally. Furthermore, RRs added or updated by a deferred update can have expiration times specified for them, as enforced by the automatic Dynamic Updates. Automatic serial number changes (as in [UPDATE]), dynamic zone slave notification (see [NOTIFY]) and incremental zone transfer (see [IXFR]) will jointly see to it that the zone changes are propagated with expedience. Expires November 1996 [Page 1] INTERNET-DRAFT DNS DEFUPD May 1996 1 - New Assigned Numbers Opcode: DEFUPD (6?) RRtype: TUU (34?) RRtype: TUE (35?) 2 - Message Format The format and encoding of a DEFUPD is identical to that of UPDATE as defined in [UPDATE 2], except that the Opcode is DEFUPD rather than UPDATE, and there are two new RR types that can be used in the Additional Data section. 2.1 - Additional Data Section: TUU RR In addition to the optional uses described in [UPDATE 2.6], a DEFUPD request's Additional Data section can include a TUU (Time Until Update) RR as follows: Owner: same as ZNAME (see [UPDATE 2.3]) Class: same as ZCLASS (see [UPDATE 2.3]) Type: TUU (new RRtype for this protocol) TTL: deferral time, relative, in seconds RDLENGTH: 0 RDATA: empty Of particular note is the TTL, which contains the relative time delay, in seconds, starting from the time this DEFUPD is received by the primary master, before operations contained in the Update Section (see [UPDATE 2.5]) will actually be performed. Expires November 1996 [Page 2] INTERNET-DRAFT DNS DEFUPD May 1996 2.2 - Additional Data Section: TUE RR In addition to the optional uses described in [UPDATE 2.6], a DEFUPD request's Additional Data section can include a TUU (Time Until Expiry) RR as follows: Owner: same as ZNAME (see [UPDATE 2.3]) Class: same as ZCLASS (see [UPDATE 2.3]) Type: TUE (new RRtype for this protocol) TTL: expiry time, relative, in seconds RDLENGTH: 0 RDATA: empty Of particular note is the TTL, which contains the expiration time delay, in seconds, starting from the time this DEFUPD is received by the primary master, of all RRs added or updated by operations in the Update Section (see [UPDATE 2.5]). 3 - Server Behavior A server, upon receiving a DEFUPD request, will first scan the request's Additional Data section in search of TUU or TUE RRs. If no RRs of either type TUU or TUE are found, then this request will be processed as a normal UPDATE with no special behaviour. If any TUU or TUE RRs are found, then processing continues as follows. 3.1 - Verify TUU RR If any TUU RRs are found in the Additional Data section, this update will be processed with Deferral as explained below. If more than one TUU RR is found, signal FORMERR to requestor. The TUU RR's owner name and class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal FORMERR to requestor. The TUU RR's RDLENGTH/RDATA is ignored by implementations of this specification, but future specifications may make use of this field. 3.2 - Verify TUE RR If any TUE RRs are found in the Additional Data section, this update will be processed with Expiry as explained below. If more than one TUE RR is found, signal FORMERR to requestor. The TUE RR's owner name and class are compared to ZNAME and ZCLASS; if a mismatch occurs, signal FORMERR to requestor. The TUE RR's RDLENGTH/RDATA is ignored by implementations of this specification, but future specifications may make use of this field. Expires November 1996 [Page 3] INTERNET-DRAFT DNS DEFUPD May 1996 3.3 - Deferral If a TUU RR was specified in the Additional Data section, this update will be processed with Deferral. Deferral means that the update will not be applied synchronously to the requestor's transaction cycle, but instead will be applied asynchronously at some potentially later time. The delay period is measured in seconds and expressed in the TUU's TTL. 3.3.1 - Store Deferred Update Subject to per-server, per-zone, and per-RRset quotas, this UPDATE message is stored, persistently, on the name server. If per-RRset quotas are implemented, it is recommended that a DEFUPD ``count against'' all RRsets mentioned in the Update Section. If an implementation defined quota is exceeded by this deferred update, or if persistent storage is unavailable, signal SERVFAIL to requestor (leaving the zone in its former state). Note that even a deferred update whose TUU's TTL is zero (0), specifying immediate application, should be subject to quotas if the name server implements quotas. 3.3.2 - Send Early Response Signal NOERROR to requestor. 3.3.3 - Apply Deferred Update When a period of time equal to or greater than the TUU's TTL (measured in seconds) has elapsed since a DEFUPD was first received at the primary master, the DEFUPD message is applied to the zone as an UPDATE would be, except that no error can be signalled to the requestor. Thus, all errors not found and reported at the time the DEFUPD request was received are silent, affecting only the continued processing of the deferred update. Note that all sections are processed, including those processed before the deferred update were stored. Thus, prerequisites must hold before and after the deferral period. Expires November 1996 [Page 4] INTERNET-DRAFT DNS DEFUPD May 1996 3.4 - Expiry Processing When a DEFUPD is applied, either during the requestor's transaction cycle or following the optional Deferral period, the inclusion of a TUE RR in the Additional Data section will cause this update to be processed with Expiry. Expiry as expressed in the TUE's TTL is the time, in seconds, before all RRs added or modified by the Update Section will be automatically deleted by the primary master server. This time is relative to the time the DEFUPD message is processed, which might be after the delay period specified by a TUU RR. 3.4.1 - Initial TTL Limits The TTL of all added or updated RRs in the Update Section will be maximized silently to one half of the Expiry time. This will cause downstream caching name servers to purge RRsets containing this RR at least once before expiry. 3.4.2 - TTL Half Life Each time an RR's expiry reaches half of its previous value, that RR's TTL will be reduced to half of its previous value, until the TTL reaches a value less than or equal to sixty (60), i.e., one minute of real time, at which time the TTL will not be automatically reduced further by the primary master. It should be noted that RRs held in a server's memory need not be swept for half life processing, as long as the TTL changes appear when the RR next becomes externally visible, and as long as the ``zone has changed'' processing (see below) is done at the time of the half life expiration. Whenever the TTL is automatically reduced by this process, the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (see [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]). Expires November 1996 [Page 5] INTERNET-DRAFT DNS DEFUPD May 1996 3.4.3 - Automatic Deletion When the time since an RR was added or updated by a DEFUPD with Expiry exceeds the TUE's TTL as specified in that update, all RRs added or updated by that DEFUPD's Update Section will be automatically deleted by the primary master. This deletion can be deferred until the deleted RRs would next become visible, so long as the ``zone has changed'' processing (see below) is done at the time of expiration (i.e., when the automatic deletion is first deferred.) Whenever automatic deletion occurs, the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (see [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]). 3.5 - Requirements for Persistence Stored deferred updates should persist across name server restarts. 3.5.1 - Restarts and Deferral In the event of a name server restart, all deferred updates whose TUU has expired must take effect before any network requests are processed using data from the affected zone, and before any Expiry processing takes place on RRs in the affected zone. 3.5.2 - Restarts and Expiry In the event of a name server restart, all expiries must be checked as of the current time before any network responses are generated using data from the affected zone. If an RR's expiry time has been reached while the name server was not running, that RR will be deleted. Otherwise, the RR's TTL will be set to one half of the time remaining before expiration, and half life processing as specified in Section 3.4.2 will be restarted. If any RR is deleted or if an RR's TTL is changed during startup, then the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (see [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]). Expires November 1996 [Page 6] INTERNET-DRAFT DNS DEFUPD May 1996 4 - Requestor Behaviour A requestor will generate and transmit a DEFUPD request as specified in [UPDATE 4], except that TUU and TUE RRs can be included in the Additional Data section. 4.1. The TUU RR, if specified, must have an owner name and class equal to the ZNAME and ZCLASS (see [UPDATE 2.3]). The TTL should be set to the delay, measured in seconds, before this update should be processed by the primary master. RDLENGTH should be set to 0, and RDATA should therefore be empty. 4.2. The TUE RR, if specified, must have an owner name and class equal to the ZNAME and ZCLASS (see [UPDATE 2.3]). The TTL should be set to the delay, measured in seconds, before all RRs added or changed by the Update Section will be automatically deleted by the primary master. This delay is measured starting from the time the update is applied, which could follow a deferral delay if a TUU RR was also included in this update. 5 - Notes on Resource Consumption A TUE RR will require the primary master will initiate an automatic update approximately O(log2(TTL)) times over the life of an expiring RR. Even for massively sized zones, this is not considered an inappropriate load on the primary master server itself. The network bandwidth consumed due to the use of TUE RRs is more noticeable, although for massively sized zones, the bandwidth requirements should flatten somewhat as many RRs will be automatically updated during any given cycle of NOTIFY and AXFR/IXFR. 6 - Security Considerations This protocol suffers the same abject and intentional lack of security as [UPDATE], from which it inherits its basic semantics. In the absence of DNS Secure Updates, this protocol should not be used outside of an enterprise network, and only with great care within an enterprise network. Expires November 1996 [Page 7] INTERNET-DRAFT DNS DEFUPD May 1996 7 - Discussion Items for DNSIND and Namedroppers Should the server's response to a DEFUPD include an opaque cookie called a ``deferred update ID'' which could be used in future DEFUPD requests to cancel or replace a previous deferred update? Should automatic updates caused by a TUE RR be required to be batched up and processed at some minimum interval? For example, if we only checked for half life and expiration once per minute, this might drastically reduce the number of NOTIFY/AXFR/IXFR cycles caused by any given zone. We would have to recommend that all zones in a given server not be synchronized to the same timer, lest a server with many zones cause all of its zones to change and require NOTIFY/AXFR/IXFR in the same second. Astute readers will have noticed that this proposal is a precise superset of [UPDATE], and by adding the optional behaviour and definitions of TUU and TUE to [UPDATE], we could do away with the separate Opcode for DEFUPD. This was only possible up until the time [UPDATE] went to proposed standard, but hopefully the intent was clear. 8 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [IXFR] M. Ohta, ``Incremental Zone Transfer,'' Internet Draft, February 1996, . [NOTIFY] P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes,'' Internet Draft, March 1996, . [UPDATE] P. Vixie (Ed), et al, ``Dynamic Updates in the Domain Name System,'' Internet Draft, March 1996, . [DHCP] Y. Rechter, ``Interaction between DHCP and DNS,'' Internet Draft, February 1996, . Expires November 1996 [Page 8] INTERNET-DRAFT DNS DEFUPD May 1996 9 - Acknowledgements Yakov Rechter assisted in the design of this protocol. Robert Elz assisted in the requirements definition. 10 - Author's Addresses Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 +1 415 747 0204 Expires November 1996 [Page 9] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 20 18: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 SAA13429 for ; Fri, 20 Jun 2003 18:45:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TUbF-000Jgy-GP for namedroppers-data@psg.com; Fri, 20 Jun 2003 22:43:17 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19TUbC-000Jgl-VI for namedroppers@ops.ietf.org; Fri, 20 Jun 2003 22:43:15 +0000 Received: (qmail 48647 invoked by uid 1016); 20 Jun 2003 22:43:47 -0000 Date: 20 Jun 2003 22:43:47 -0000 Message-ID: <20030620224347.48646.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length References: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> <15427.1056102254@munnari.OZ.AU> <20030620194734.50840.qmail@cr.yp.to> <200306201054.05150.mellon@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ted Lemon writes: > What's your experience with this - do you have any measurements about what > happens in practice as the time to die approaches? Clients throw the record away shortly after the time-to-die, and ask for new data when they need it, exactly as desired. Exception: some broken programs like nscd keep the record for a while. The overall effect is similar to what happens when you manually set a low TTL. The advantage is that setting a time-to-die allows extra caching before the time-to-die; a low TTL doesn't. (There's also a user-interface advantage of scheduling the change in advance, but this isn't a protocol issue.) > we were concerned that if you do something like this, the effect is > going to be a refresh storm as the time to die gets closer Please define ``refresh storm.'' Do you describe TTL-0 records as causing ``refresh storms''? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 20 20:17: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 UAA15256 for ; Fri, 20 Jun 2003 20:17:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TW07-000OU0-Tu for namedroppers-data@psg.com; Sat, 21 Jun 2003 00:13:03 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.14) id 19TVzx-000OSt-Td for namedroppers@ops.ietf.org; Sat, 21 Jun 2003 00:12:54 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 2229C49D; Fri, 20 Jun 2003 20:12:23 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 9E77A3FC for ; Fri, 20 Jun 2003 20:12:22 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 414033; Fri, 20 Jun 2003 20:08:54 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Fri, 20 Jun 2003 20:12:15 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: wild cards, CNAMEs and 1034's 4.3.2 Cc: edlewis@arin.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:51 -0400 6/17/03, Edward Lewis wrote: >Here is what one person suggested for step c: > > If the "*" label does exist, look for a CNAME at that node. > If found and QTYPE doesn't match CNAME, copy the CNAME RR into > the answer section of the response, using QNAME as the owner > name, and then change QNAME to the canonical name in the CNAME > RR, and go back to step 1. Otherwise, match RRs at the node > against QTYPE. If any match, copy them into the answer > section, but set the owner of the RR to be QNAME, and not the > node with the "*" label. Go to step 6. > >Any thoughts on this? No one has put a reply to this on namedroppers. I wanted to point this out - With 1034 as it stands now (amended by DNAME), there will only ever be up to two NXT's in the authority section. One for any negative answer and one for the sole possible wild card. If the above change is made, this limit is removed - since CNAME's at wild cards would be 'followed' now, it is possible to perform multiple wild card synthesis in chasing an answer. Each needs an NXT (possibly) to prove that the name had to be changed. Unlike the fear of uncountable NXTs we had before, the limit here is 1:1 with respect to the number of CNAME "jumps" with the sole legit NXT easily identifiable at each "hop." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 20 20:47: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 UAA15587 for ; Fri, 20 Jun 2003 20:47:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TWTl-0000qd-4m for namedroppers-data@psg.com; Sat, 21 Jun 2003 00:43:41 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.14) id 19TWTb-0000qP-1B for namedroppers@ops.ietf.org; Sat, 21 Jun 2003 00:43:31 +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 h5L0hPh1027596; Fri, 20 Jun 2003 17:43:25 -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 h5L0hPBK019607; Fri, 20 Jun 2003 17:43:25 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h5L0hOTt019604; Fri, 20 Jun 2003 17:43:24 -0700 (PDT) Date: Fri, 20 Jun 2003 17:43:24 -0700 (PDT) Message-Id: <200306210043.h5L0hOTt019604@guava.araneus.fi> To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: question regarding wildcards and 2672 In-Reply-To: References: X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-36.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Monday, Edward Lewis wrote: > With a light bulb supplied by Mark Andrews, in the never ending > effort to clarify wild cards... > > In RFC 2672, section 4.1: > > # c. If at some label, a match is impossible (i.e., the > # corresponding label does not exist), look to see whether the > # last label matched has a DNAME record. > # > # If a DNAME record exists at that point, ... SHOULD synthesize a > # CNAME record ... Go back to step 1. > # > ... > # > # If the "*" label does exist, match RRs at that node against > # QTYPE. If any match, copy them into the answer section, but > # set the owner of the RR to be QNAME, and not the node with the > # "*" label. Go to step 6. > > There's a problem with this. > > Let's say an authoritative server has '*.example. DNAME example.org.' > in a zone. > > ACT I: > > Cache issues a query for '1.2.example. DNAME IN' and gets the > synthesized answer. Elaborating to check that I'm understanding you correctly, the synthesized answer you refer to above would be "1.2.example. DNAME example.org.", and the type of synthesis performed by the authoritative server in this case is wildcard expansion, not DNAME redirection. When the cache follows the algorithm of RFC2672 section 4.2, it ends up caching this DNAME in step 4a of the algorithm (not step 4d - this DNAME is simply the answer to the question, not a DNAME being redirected through to find the answer). > Cache is then asked for '0.1.2.example. A IN' This is where we get into murky waters. When the cache resolves this query, at what step of the resolver algorithm does the DNAME we just cached come into play, if any? As far as I can see, the text of RFC2672 section 4.2 doesn't say. Clearly in step 1 the answer is not in local information, so we proceed to step 2, "find the best servers to ask", but what happens in that step is unclear. I see the following possible interpretations: 1) Finding the best servers to ask means looking for the closest parent node with cached NS records, just as it did when DNAME was not yet invented. In this case, the cache ends up sending the "0.1.2.example. A" query to the authoritative server which responds with a noerror/nodata response because there is no A record at "*.example.", and there is no inconsistency between Act I and II. 2) Finding the best servers to ask means looking for the closest parent node with cached NS records or a parent node with a cached DNAME record. If a cached DNAME is found, the SNAME is rewritten, a DNAME and optional synthetic CNAME are added to the response, and the search for the best servers is restarted at the SNAME, in a way similar to what authoritative servers do in section 4.1 step 3c. In this case, the response will contain the cached "1.2.example. DNAME example.org." and a synthetic CNAME "0.1.2.example. CNAME 0.example.org.". This is the outcome you described, which will lead to the inconsistency between Acts I and II. 3) Finding the best servers to ask means looking for the closest parent node with cached NS records or a parent node with a DNAME record that was cached in step 4d of the algorithm (due to being involved in a rewrite), disregarding any DNAME record that was cached in step 4a (due to being the answer to a query). If the former kind of DNAME is found, we rewrite as in 2) above. This will give the same consistent result for your example queries as interpretation 1), but has the advantage of avoiding making queries to the authoritative servers in some situations where a server doing 1) would make them. Of these interpretations, 1) seems closest to the letter of RFC2672. The two implementations I am familiar with do 2) and 3), respectively. Note that this lack of clarity of the algorithm is not limited to the wildcard case - it is equally unclear how a DNAME cached as a result of a direct query or a normal DNAME rewrite not involving wildcards is taken into account by the resolver. > Note that the first query changes what the second query gets. (And > unlike the ANY situation, the two answers are incoherent.) Based on the above, it is far from clear that a correct implementation of DNAME will produce the inconsistency. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Jun 21 18:34: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 SAA17899 for ; Sat, 21 Jun 2003 18:34:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Tqog-000Jnc-JF for namedroppers-data@psg.com; Sat, 21 Jun 2003 22:26:38 +0000 Received: from [2001:470:1f00:820:208:74ff:fe9f:eeae] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.14) id 19TqoW-000Jm7-20 for namedroppers@ops.ietf.org; Sat, 21 Jun 2003 22:26:28 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9/8.12.9) with ESMTP id h5LMPj6A060541; Sun, 22 Jun 2003 08:25:46 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200306212225.h5LMPj6A060541@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: wild cards, CNAMEs and 1034's 4.3.2 In-reply-to: Your message of "Fri, 20 Jun 2003 20:12:15 -0400." Date: Sun, 22 Jun 2003 08:25:45 +1000 X-Spam-Status: No, hits=-11.8 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 15:51 -0400 6/17/03, Edward Lewis wrote: > >Here is what one person suggested for step c: > > > > If the "*" label does exist, look for a CNAME at that node. > > If found and QTYPE doesn't match CNAME, copy the CNAME RR into > > the answer section of the response, using QNAME as the owner > > name, and then change QNAME to the canonical name in the CNAME > > RR, and go back to step 1. Otherwise, match RRs at the node > > against QTYPE. If any match, copy them into the answer > > section, but set the owner of the RR to be QNAME, and not the > > node with the "*" label. Go to step 6. > > > >Any thoughts on this? > > No one has put a reply to this on namedroppers. I wanted to point this out - > > With 1034 as it stands now (amended by DNAME), there will only ever > be up to two NXT's in the authority section. One for any negative > answer and one for the sole possible wild card. > > If the above change is made, this limit is removed - since CNAME's at > wild cards would be 'followed' now, it is possible to perform > multiple wild card synthesis in chasing an answer. Each needs an NXT > (possibly) to prove that the name had to be changed. > > Unlike the fear of uncountable NXTs we had before, the limit here is > 1:1 with respect to the number of CNAME "jumps" with the sole legit > NXT easily identifiable at each "hop." The additional NXT is not a reason to reject this change. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > ...as graceful as a blindfolded bull in a china shop... > > -- > to 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 Sun Jun 22 02:29: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 CAA06208 for ; Sun, 22 Jun 2003 02:29:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TyEk-000BDJ-Fc for namedroppers-data@psg.com; Sun, 22 Jun 2003 06:22:02 +0000 Received: from [192.139.46.78] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.14) id 19TyEh-000BD3-Ao for namedroppers@ops.ietf.org; Sun, 22 Jun 2003 06:21:59 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5K145q29771 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Thu, 19 Jun 2003 21:04:07 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5K15hr12678; Thu, 19 Jun 2003 21:05:43 -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 h5K13rWl030720; Thu, 19 Jun 2003 21:03:53 -0400 Message-Id: <200306200103.h5K13rWl030720@sandelman.ottawa.on.ca> To: dhcwg@ietf.org, namedroppers@ops.ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-reply-to: Your message of "Fri, 20 Jun 2003 04:38:25 +0700." <22680.1056058705@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Jun 2003 21:03:52 -0400 From: Michael Richardson X-Spam-Status: No, hits=-8.4 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I came to this thread late. I can understand why this topic came up in the context of DHCP, but it is really a dynamic update issue. I use nsupdate to update the location of my laptop. I do this from my dhcp-client, my ppp "ip-up", and from some manual scripts that I use when all of the above is not useful. (which is less often, fortunately) The reason that I say that dhcp is not involved is because it is my laptop (not the dhcp server) that has the relationship with my forward domain server. As such, what I really want is a dynamic update operation which actually says "install this record with TTL=XXX, deleting the record after YYY" (Clearly, XXX < YYY, and some may argue YYY:=XXX. I'm undecided) I have really no problem sending a new update every couple of minutes. In fact, I'd prefer to do this. That way, the record goes away sometime after I go away or I loose connectivity, which is a lot better than the next time I get online! (And there are lots of places where DNS is forced-proxy, and dyn-update does not work. I started a list earlier this month, even: http://www.sandelman.ca/mcr/hotels/ actually) In the reverse map space, and in the places where the dhcpd server does control the forward map, sure - TTL should be less than lease time, and the dhcpd server SHOULD remove the record when the lease is returned to the pool. A timed-dynamic update would be easier for that situation too, I think. ] ON HUMILITY: to err is human. To moo, bovine. | 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 GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPvJddoqHRg3pndX9AQG6CAP+Pz9gE5VzA5zmVyRrp7Lam7nMb/9USI5L nkQUQe7vqrVbwk6Ss8AMFM5+ZLRTCZEJ/3KfBMZqcrhMdaTDhIaOM3LnsPXYhn7p 15QkliFrn5DMd4AZKfgOLxgUN+EKEq/PY3E8bR0a2eWyrJct5nuQbRyeu/9Of2DQ 7/Jeme7A2Cw= =5++K -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 22 02:28: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 CAA06203 for ; Sun, 22 Jun 2003 02:28:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19TyEt-000BDl-4R for namedroppers-data@psg.com; Sun, 22 Jun 2003 06:22:11 +0000 Received: from [192.139.46.78] (helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 4.14) id 19TyEi-000BD3-SR for namedroppers@ops.ietf.org; Sun, 22 Jun 2003 06:22:01 +0000 Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [192.139.46.2]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h5JI5Cq28406 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Thu, 19 Jun 2003 14:05:14 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by lox.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h5JI6or20102 for ; Thu, 19 Jun 2003 14:06:50 -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 h5JI4vsd021335 for ; Thu, 19 Jun 2003 14:04:58 -0400 Message-Id: <200306191804.h5JI4vsd021335@sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org Subject: Re: wild cards and NS records In-reply-to: Your message of "Wed, 18 Jun 2003 09:51:13 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Jun 2003 14:04:56 -0400 From: Michael Richardson X-Spam-Status: No, hits=-10.0 required=5.0 tests=BAYES_30,IN_REP_TO,PGP_SIGNATURE,RCVD_IN_OSIRUSOFT_COM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Edward" == Edward Lewis writes: Edward> So, the suggestion for this case is to state: Edward> o Name servers MAY reject (refuse to load) zones with any wild Edward> card domain Edward> name owning an NS RR set. When you write "refuse to load" do you mean from disk, or do you mean xfer from primary? Or both? The reason that I ask is that people are often not in control of their secondaries (this is often good I argue, as it isolates extent of a screw up). So, having a secondary updated, and then go lame, often without the knowledge of either the primary operator or the secondary operator, is really bad. Edward> o Name servers MAY refuse to accept updates to add NS RR sets Edward> to a wild Edward> card domain name. This means dyn-update? ] ON HUMILITY: to err is human. To moo, bovine. | 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 GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPvH7RYqHRg3pndX9AQGKzgP9F/lccMIBFGbUEsQDG+g0P05LpZjvibcL QQ6z0WwvmWEcfeHYsbrbtwA91JpWGBD74Lc4hQwpNTGFjADzdr+72BJz1JNd7Xyd hVsD0OPYA7RHCxAtwaXxiHH/W4SWgxlIU7ww9zk8FajrVvAJome4nfQMozeFNnDm 7wmIURl+rXk= =KxLC -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jun 22 02:48: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 CAA06489 for ; Sun, 22 Jun 2003 02:48:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Tyav-000CON-26 for namedroppers-data@psg.com; Sun, 22 Jun 2003 06:44:57 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.14) id 19Tyat-000CNz-Fs for namedroppers@ops.ietf.org; Sun, 22 Jun 2003 06:44:55 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 9382513948 for ; Sun, 22 Jun 2003 06:44:42 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: wild cards and NS records In-Reply-To: Message from Michael Richardson of "Thu, 19 Jun 2003 14:04:56 -0400." <200306191804.h5JI4vsd021335@sandelman.ottawa.on.ca> X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 22 Jun 2003 06:44:42 +0000 Message-Id: <20030622064442.9382513948@sa.vix.com> X-Spam-Status: No, hits=-9.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > When you write "refuse to load" do you mean from disk, or do you > mean xfer from primary? Or both? what i meant when i agreed with ed's proposal was: "both." > The reason that I ask is that people are often not in control of > their secondaries (this is often good I argue, as it isolates extent > of a screw up). according to dns's definitions, the zone owner has the ultimate authority, which may include choosing different slave servers if necessary to enforce zone policy or support the necessary protocol feature set (like DNAME for example). > So, having a secondary updated, and then go lame, often without the > knowledge of either the primary operator or the secondary operator, is > really bad. that's what soa-serial-number monitoring tools are for, methinks. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 04:06: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 EAA12346 for ; Mon, 23 Jun 2003 04:06:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UME9-000CCZ-7g for namedroppers-data@psg.com; Mon, 23 Jun 2003 07:59:01 +0000 Received: from [193.0.1.96] (helo=birch.ripe.net) by psg.com with esmtp (Exim 4.14) id 19UME6-000CBm-CJ for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 07:58:58 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with SMTP id h5N7wvRS004158 for ; Mon, 23 Jun 2003 09:58:57 +0200 Date: Mon, 23 Jun 2003 09:58:57 +0200 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Draft Charter. Message-Id: <20030623095857.1d2da0bb.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-Spam-Status: No, hits=-1.0 required=5.0 tests=BAYES_30,OPT_IN_CAPS version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Below is a draft for a charter revision. Please send in your comments, we want to get this to the IESG shortly. -- Olaf Kolkman, DNSEXT co-chair. ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC DNSEXT DNS Extensions Working group --------------------------------------------------- Charter Last Modified: 20-June-2003 Current Status: Active Working Group (being re-chartered) Chair(s): Olafur Gudmundsson Olaf Kolkman Internet Area Director(s): Thomas Narten Erik Nordmark Internet Area Advisor: Erik Nordmark Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: Description of Working Group: DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are protocol issues, including message formats, message handling, and data formats. New work items and milestones may be added from time-to-time with the approval of the Working Group and the IESG. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter. These issues are considered in other venues, such as the DNS Operations Working Group. Broad topics include changes to the DNS protocol and advance DNS protocol documents along the standards track. This includes advance zone transfer, update, notify, security documents to Draft standard. Specific work items are: o Protocol clarifications and corrections for DNSSEC, initially these clarifications will be done as separate RFCs which will later be folded into a document that we refer to as the RFC 2535bis document standard These include plans and changes that simplify the operation of DNSSEC. o Generate new specification documents of DNSSEC (the RFC 2535bis document set) that includes all changes to RFC2535. This includes the following RFCs 2931, 3007, 3008, 3090 and 3226 and a number of Internet Drafts including DS, AD-is-secure, Key Signing Flag, etc. Advance this document set through the standard process. o Clarification of RFC1034/1035 + Clarification of wildcard processing rules. + Case Insensitivity Clarification. o Advance the following existing proposed and draft standards on the standard track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Norify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard. + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2835 (TSIG)to Draft standard. + RFC2930 ( TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3??? AXFR clarify to Draft Standard. + RFC3??? GSS/TSIG to Draft Standard o IPv6 support in DNS records and IPv6 DNS services + RFC1886bis to Draft Standard. o Investigate how protocol changes, use of multicast, etc. might support zeroconf environments, of the two approaches considdered, the WG targets LLMNR as proposed standard and Discover as experimental. The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. o Advance relevant documents to full standard. Goals and Milestones: Where there is no milestone for a work item mentioned above, the working group has not yet decided upon the priority for the item, or, in some cases, whether active work will be undertaken, and no target milestone has yet been set. The milestones will be reviewed about 3 times per year, coinciding with the IETF meeting. Jun 03 Submit to IESG OPT-IN as Informational (nomative to RFC2535-bis) Jul 03 Forward IPv6 auto-registration to IESG for Experimental Jul 03 Submit to IESG DHCID RR for Proposed Standard. Jul 03 Forward LLMNR IESG for Proposed Standard. Jul 03 Submit to IESG Delegation Signer for Proposed Standard. Aug 03 WG last call on the DNSSEC document set(RFC2535-bis). Aug 03 WG last call on IESG Wildcard clarification Aug/Sep 03 Submit to IESG KEY algorithm documents RFC253[69] and RFC3110 to Sep/Oct 03 Forward RFC2535-bis to IESG for to IESG for Proposed standard. Q3/Q4 03 Submit to IESG Case insensitive clarification for proposed standard. Q1 04 Submit to IESG RFC2835 (TSIG)to Draft standard. Q1 04 Submit to IESG RFC2930 (TKEY) to Draft standard. After ownership of interop test has been taken the following items will be assigned milestones. o RFC1995 (IXFR) to Draft standard o RFC1996 (Notify) to Draft Standard. o RFC2136bis (Dynamic Update) to Draft Standard. o RFC2181 (Clarify) to Draft Standard. o RFC2308 (Neg Caching) to Draft Standard. o RFC2535bis (DNSSEC) to Draft standard. o RFC2671 (EDNS0) to Draft Standard. o RFC3007 (Secure Update) to Draft standard. o RFC3??? (AXFR clarify) to Draft Standard. o RFC3??? (GSS/TSIG) to Draft Standard o RFC3??? (Unkown RR) to Draft Standard $Id: Charter.txt,v 1.7 2003/06/20 15:17: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: From owner-namedroppers@ops.ietf.org Mon Jun 23 10:23: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 KAA22395 for ; Mon, 23 Jun 2003 10:23:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19US6O-0000zc-Ai for namedroppers-data@psg.com; Mon, 23 Jun 2003 14:15:24 +0000 Received: from [193.0.1.96] (helo=birch.ripe.net) by psg.com with esmtp (Exim 4.14) id 19US6L-0000z5-Cj for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 14:15:21 +0000 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h5NEEJRT029442; Mon, 23 Jun 2003 16:14:19 +0200 Date: Mon, 23 Jun 2003 16:14:19 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org cc: dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <20030620224347.48646.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-27.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 20 Jun 2003, D. J. Bernstein wrote: > Ted Lemon writes: > > What's your experience with this - do you have any measurements about what > > happens in practice as the time to die approaches? > > Clients throw the record away shortly after the time-to-die, and ask for > new data when they need it, exactly as desired. So far, its server-specific, and the information about the exact time for ttd to take effect isn't transferrable via AXFR ( which can only transfer offsets via TTL ). What do clients see from tinydns? Eg, for a record of 'dying.example.com' which should expire at T+1500, would it be: Client A requesting 'dying.example.com' at time T receives: dying.example.com 1500 IN A 192.168.1.2 Client B requesting 'dying.example.com' at time T+100 receives: dying.example.com 1400 IN A 192.168.1.2 ? So, Client A and Client B have _nearly_ the same RR set, just with different TTLs. The end effect is that both Client A and Client B will drop the record from their cache at the appropriate time. This is good, right? So, the next question is, since Client A and Client B received different (authoritative) responses, does that mean that there were different versions of the zone 'example.com' at time T and T+100 ? If yes, there were different versions of the zone at T and T+100, then the SOA serial needs to be updated, with the consequent flurry of AXFR requests from the 'example.com' slaves when they noticed the SOA having changed. If no, there were not different versions of the zone (and no SOA serial change) at T and T+100, then we run into problems with the 'example.com' slaves giving different TTL values for 'dying.example.com' depending on when they retrieved the zone. ( This space left blank for an 'AXFR is bad, use rsync' comment ) > > we were concerned that if you do something like this, the effect is > > going to be a refresh storm as the time to die gets closer > > Please define ``refresh storm.'' Do you describe TTL-0 records as > causing ``refresh storms''? Section 3.4.2 of Vixies 1996 draft (related to implementation of time-to-die) has the wording: 3.4.2 - TTL Half Life Each time an RR's expiry reaches half of its previous value, that RR's TTL will be reduced to half of its previous value, until the TTL reaches a value less than or equal to sixty (60), i.e., one minute of real time, Whenever the TTL is automatically reduced by this process, the zone will be considered ``changed'' for the purpose of automatic SOA SERIAL increment (see [UPDATE 3.6]) and real time zone slave notification (see [NOTIFY]). You could probably do wording such that the only time an SOA serial change occurs (due to TTL/TTD behaviour) is when an SOA request comes in (so the version of the zone on your non-time-to-die-internal-magic slave is correct), but you've still got the problem of differing clients getting differing versions of RRs in the zone without SOA serial change, which is not a good precedent. --==-- Bruce. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 10:31: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 KAA22785 for ; Mon, 23 Jun 2003 10:31:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19USHA-0001TH-O7 for namedroppers-data@psg.com; Mon, 23 Jun 2003 14:26:32 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.14) id 19USH8-0001Sd-H3 for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 14:26:30 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id AF80C684; Mon, 23 Jun 2003 10:25:59 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id EC27066B; Mon, 23 Jun 2003 10:25:58 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 417496; Mon, 23 Jun 2003 10:22:18 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200306191804.h5JI4vsd021335@sandelman.ottawa.on.ca> References: <200306191804.h5JI4vsd021335@sandelman.ottawa.on.ca> Date: Mon, 23 Jun 2003 10:25:59 -0400 To: Michael Richardson From: Edward Lewis Subject: Re: wild cards and NS records Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-33.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 14:04 -0400 6/19/03, Michael Richardson wrote: > When you write "refuse to load" do you mean from disk, or do you mean xfer >from primary? Or both? Both. > Edward> o Name servers MAY refuse to accept updates to add NS RR sets > Edward> to a wild > Edward> card domain name. > > This means dyn-update? Yep. I think of updates as degenerate cases of the zone loading process. Reading zones from disk and receiving them via 'xfr's are the same to me as receiving an update request - all three are preludes to a possible zone change. They differ in the number of records 'ordinarily' changed, but if you look at the before and after effect on the server (eg the serial number), it all looks the same. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 10:47:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23244 for ; Mon, 23 Jun 2003 10:47:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19USYI-0002VQ-74 for namedroppers-data@psg.com; Mon, 23 Jun 2003 14:44:14 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19USYF-0002V8-RI for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 14:44:11 +0000 Received: (qmail 28168 invoked by uid 1016); 23 Jun 2003 14:44:43 -0000 Date: 23 Jun 2003 14:44:43 -0000 Message-ID: <20030623144443.28167.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: ietf@ietf.org Subject: axfr-clarify, again References: <20030623095857.1d2da0bb.olaf@ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-14.6 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Olaf M. Kolkman writes: > + RFC3??? AXFR clarify to Draft Standard. Replacement charter item: ``See whether consensus can be achieved on AXFR clarifications.'' I fully understand the desire to clarify how the DNS protocol works---but that doesn't justify pushing a horribly flawed document to ``Proposed Standard,'' never mind ``Draft Standard.'' At least seven people have gone on record as objecting to axfr-clarify; see http://cr.yp.to/djbdns/axfr-clarify.html for details. The BIND company admits that axfr-clarify does not correctly describe the behavior of most DNS servers on the Internet. My web page http://cr.yp.to/djbdns/axfr-notes.html contains an accurate description of the AXFR protocol, quite different from axfr-clarify. Along the way, it identifies nine clear errors in axfr-clarify: six points where axfr-clarify (in violation of RFC 2119 section 6) prohibits existing working behavior, and three points where axfr-clarify creates new interoperability problems. What the BIND company has given us is not, in fact, ``clarification.'' It is BIND 9 documentation fraudulently posing as clarification. It is blatantly biased in favor of one vendor---the same vendor that produced the document, that has generated most of the messages supporting the document, and that previously paid one of the WG chairs (Gudmundsson) to work on its software. The problems with axfr-clarify, both in content and in procedure, have been thoroughly documented. Anyone who wants to ignore IETF documents--- even the occasional high-quality ones, the ones that are important for interoperability---simply has to point to the progress of axfr-clarify as an IETF ``standard.'' A legitimate standards organization would never have allowed axfr-clarify to get anywhere. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 11:11: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 LAA23948 for ; Mon, 23 Jun 2003 11:11:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19USvr-0007TS-Gr for namedroppers-data@psg.com; Mon, 23 Jun 2003 15:08:35 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19USvp-0007T6-1u for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 15:08:33 +0000 Received: (qmail 48341 invoked by uid 1016); 23 Jun 2003 15:09:05 -0000 Date: 23 Jun 2003 15:09:05 -0000 Message-ID: <20030623150905.48340.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length References: <20030620224347.48646.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-25.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bruce Campbell writes: > So, the next question is, since Client A and Client B received different > (authoritative) responses, does that mean that there were different > versions of the zone 'example.com' at time T and T+100 ? Of course not; that would be silly. The TTD---which is what caches actually store anyway---is the same. Queries at different times will interpret the same TTD as different TTLs, of course, but that doesn't mean the zone has changed. If you insist on corrupting the zone by retrieving it through AXFR, you'll get 2-second TTLs from my AXFR server. Of course, the record also won't disappear until the next AXFR. The effects on the secondary, and on clients talking to the secondary, are the same as if you had manually set a 2-second TTL in the first place. If you transfer the zone accurately (for example, through rsync), the secondary will allow more caching before the time-to-die than it would have with a 2-second TTL, and it will remove the record at exactly the right time without another transfer. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 12:15: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 MAA26930 for ; Mon, 23 Jun 2003 12:15:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UTuN-000Aqi-V6 for namedroppers-data@psg.com; Mon, 23 Jun 2003 16:11:07 +0000 Received: from [130.105.12.4] (helo=citation.av8.net) by psg.com with esmtp (Exim 4.14) id 19UTuL-000Aq6-Hg for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 16:11:05 +0000 Received: from vista.av8.net (vista.av8.net [130.105.36.10]) by citation.av8.net (8.9.3/8.9.3) with ESMTP id MAA18443; Mon, 23 Jun 2003 12:08:09 -0400 Date: Mon, 23 Jun 2003 12:08:10 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@vista.av8.net To: "Olaf M. Kolkman" cc: namedroppers@ops.ietf.org, Subject: Re AXFR clarify to Draft standard In-Reply-To: <20030623095857.1d2da0bb.olaf@ripe.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-19.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_NJABL, RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE,X_NJABL_OPEN_PROXY autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document was previously shown to be a major change and an unnecessary change at that. There is quite obviously no consensus on the merits of the document. While a clarification on AXFR is order due to vague language in the present specification, such clarification should take into account how multiple existing implementations interpreted the vague specification, rather than try to push through an unnecessary change made by the Bind9 developers. --Dean On Mon, 23 Jun 2003, Olaf M. Kolkman wrote: > + RFC3??? AXFR clarify to Draft Standard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 13:28: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 NAA29992 for ; Mon, 23 Jun 2003 13:28:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UV3t-000MoU-RW for namedroppers-data@psg.com; Mon, 23 Jun 2003 17:25:01 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.14) id 19UV3p-000Mm1-BB for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 17:24:57 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 24E233C2; Mon, 23 Jun 2003 13:24:27 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id ABCB238F; Mon, 23 Jun 2003 13:24:26 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 417982; Mon, 23 Jun 2003 13:20:45 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200306210043.h5L0hOTt019604@guava.araneus.fi> References: <200306210043.h5L0hOTt019604@guava.araneus.fi> Date: Mon, 23 Jun 2003 13:24:24 -0400 To: gson@nominum.com (Andreas Gustafsson) From: Edward Lewis Subject: Re: question regarding wildcards and 2672 Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:43 -0700 6/20/03, Andreas Gustafsson wrote: >Of these interpretations, 1) seems closest to the letter of RFC2672. >The two implementations I am familiar with do 2) and 3), respectively. I like this, it is akin to the way negative answers are understood to work in a cache. A cache doesn't infer a negative answer from previously seen data, a cache shouldn't infer a DNAME from previously seen data. In this case, it seems that it won't matter if the wild card matches one or more labels in synthesizing the DNAME. From that I think that trying to restrict the wild card to matching just one label (for DNAME or NS) isn't the right path to clarification. Perhaps a wild card owning a DNAME is innocuous after all. (Keeping in mind that a non-DNAME-aware cache won't use it in forming an answer anyway.) >Note that this lack of clarity of the algorithm is not limited to the >wildcard case - it is equally unclear how a DNAME cached as a result >of a direct query or a normal DNAME rewrite not involving wildcards is >taken into account by the resolver. I'm not going to tackle the rest of DNAME, that's clearly not my intent. (But someone one day will.) My only concern is what happens at the wild card. Caches don't do wild card synthesis, so I'm less concerned about that topic. They don't have enough information to do that, even when they know, thanks to the SIG record, that the answer was the result of a synthesis - label count. PS - In deference to a request by a chair who is now on vacation, I'll include dictionary references at times. ;) innocuous = producing no injury : HARMLESS "in deference to" DNAME "in consideration of" ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 13:43: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 NAA00442 for ; Mon, 23 Jun 2003 13:43:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UVIu-000NlB-F6 for namedroppers-data@psg.com; Mon, 23 Jun 2003 17:40:32 +0000 Received: from [2001:4f8:3:bb:209:5bff:fe05:1a73] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.14) id 19UVIr-000NkZ-VA for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 17:40:30 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B97901396A; Mon, 23 Jun 2003 17:40:16 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: Message from Bruce Campbell of "Mon, 23 Jun 2003 16:14:19 +0200." X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 23 Jun 2003 17:40:16 +0000 Message-Id: <20030623174016.B97901396A@sa.vix.com> X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [robert campbell] > What do clients see from tinydns? Eg, for a record of 'dying.example.com' > which should expire at T+1500, would it be: > > Client A requesting 'dying.example.com' at time T receives: > dying.example.com 1500 IN A 192.168.1.2 > > Client B requesting 'dying.example.com' at time T+100 receives: > dying.example.com 1400 IN A 192.168.1.2 > > ? > > So, Client A and Client B have _nearly_ the same RR set, just with > different TTLs. no. ttl does not affect rrset identity. per [rfc2136 1.1.1] et al. > The end effect is that both Client A and Client B will drop the record > from their cache at the appropriate time. This is good, right? yes. > So, the next question is, since Client A and Client B received different > (authoritative) responses, does that mean that there were different > versions of the zone 'example.com' at time T and T+100 ? no. see above. > If yes, there were different versions of the zone at T and T+100, then > the SOA serial needs to be updated, with the consequent flurry of AXFR > requests from the 'example.com' slaves when they noticed the SOA > having changed. no. any authoritative server could clamp its ttl's for local policy reasons without affecting zone identity. they can't be made longer but they could absolutely be made shorter without invalidating the zone soa:content mapping. > Section 3.4.2 of Vixies 1996 draft (related to implementation of > time-to-die) has the wording: > > 3.4.2 - TTL Half Life > > Each time an RR's expiry reaches half of its previous value, that RR's > TTL will be reduced to half of its previous value, until the TTL reaches > a value less than or equal to sixty (60), i.e., one minute of real time, > > > > Whenever the TTL is automatically reduced by this process, the zone will > be considered ``changed'' for the purpose of automatic SOA SERIAL > increment (see [UPDATE 3.6]) and real time zone slave notification (see > [NOTIFY]). > > You could probably do wording such that the only time an SOA serial change > occurs (due to TTL/TTD behaviour) is when an SOA request comes in (so the > version of the zone on your non-time-to-die-internal-magic slave is > correct), but you've still got the problem of differing clients getting > differing versions of RRs ... they aren't differing versions of rr's. ttl is not considered in rr comparisons. > ... in the zone without SOA serial change, which is not a good precedent. see also [rfc2136 3.6]. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 15:12: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 PAA05155 for ; Mon, 23 Jun 2003 15:12:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UWea-0002Cl-Fd for namedroppers-data@psg.com; Mon, 23 Jun 2003 19:07:00 +0000 Received: from [193.0.1.96] (helo=birch.ripe.net) by psg.com with esmtp (Exim 4.14) id 19UWeY-0002CQ-9L for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 19:06:58 +0000 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 h5NJ6vRS005058 for ; Mon, 23 Jun 2003 21:06:57 +0200 Message-Id: <200306231906.h5NJ6vRS005058@birch.ripe.net> To: namedroppers@ops.ietf.org Subject: Draft Agenda Date: Mon, 23 Jun 2003 21:06:57 +0200 From: Olaf Kolkman X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Based on the input after Olafur's call for items we came up with the following agenda. Comments, suggestions, &c, &c, are welcomed. --Olaf DNS Extensions WG (dnsext) Tuesday, July 15, 1300-1400 Afternoon Sessions I Chairs: Olafur Gudmundsson, Olaf Kolkman. ------------------------------------------------------------ - Administrivia 3 min agenda bashing appointing scribes - Charter 7 min - Bernard Aboba Linklocal Multicast Name Resolution (LLMNR) (summary of changes since IETF56) draft-ietf-dnsext-mdns-21.txt 5 min - DNSSEC editors report 7 min presentation 10 min discussion - Ed Lewis 5 min Wildcard Clarification - Mike St Johns. 5 min Using DNSSEC-secured NOTIFY to Trigger Parent Zone Updating draft-stjohns-secure-notify-00 - Vladimir Ksinant Update on RFC2845 (TSIG) interop tests 5 min - AOB 5 min Please inform chairs in advance of the meeting. ------------------------------------------------------------ $Id: agenda.txt,v 1.1 2003/06/23 19:00:28 olaf Exp olaf $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 15:52: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 PAA07819 for ; Mon, 23 Jun 2003 15:52:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UXIw-0003tP-Qo for namedroppers-data@psg.com; Mon, 23 Jun 2003 19:48:42 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.14) id 19UXIs-0003s9-K8 for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 19:48:38 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id 0318D435; Mon, 23 Jun 2003 15:48:07 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id C67D9256; Mon, 23 Jun 2003 15:48:06 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 418303; Mon, 23 Jun 2003 15:44:25 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20030623095857.1d2da0bb.olaf@ripe.net> References: <20030623095857.1d2da0bb.olaf@ripe.net> Date: Mon, 23 Jun 2003 15:47:16 -0400 To: "Olaf M. Kolkman" From: Edward Lewis Subject: Re: Draft Charter. Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-28.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,OPT_IN_CAPS, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Keep in mind that a charter is a statement of scope. Excepting the milestone list that is attached, the charter lists the work items vague enough to provide scope without preventing us from making decisions based on the results of lessons not yet learned. The latter sentence refers in part to the quagmire that is AXFR clarify. Whether or not consensus has been reached, we do need to clarify this topic. At 9:58 +0200 6/23/03, Olaf M. Kolkman wrote: >Below is a draft for a charter revision. Please send in your comments, we >want to get this to the IESG shortly. > >Description of Working Group: > > DNS was originally specified in RFC's 1034 and 1035, with subsequent > updates. Within the scope of this WG are protocol issues, including > message formats, message handling, and data formats. New work items > and milestones may be added from time-to-time with the approval of > the Working Group and the IESG. You need to caveat that the WG is looking at specific (class of) EXTENSIONS to the protocol. I would drop the last sentence as that is always true. >Specific work items are: You need to do a wording nits pass, but I'll stick to issues only for now. Looks like 'o' 1 and 2 are the same. > > o Clarification of RFC1034/1035 > + Clarification of wildcard processing rules. > + Case Insensitivity Clarification. I'd be careful here. There's a lot of clarification to be done if this is a main work item. Clarifications should only be undertaken if they are in support of other extension work. Otherwise the group might well consider the clarification DNS into DNS++ within scope. > o Advance the following existing proposed and draft standards on > the standard track. I think that specifying the level of standard as being Draft Standard is a good scoping of the work, but keep in mind what that means. Draft Standard is not the end of the line for a body of work, but it could be the end of the line for the WG formed to achieve that level. Perhaps the WG ought to consider it's scope to take things that have once hit PS and get them to DS. I.e., no new ideas. (Yes, I'm serious, sometimes new ideas belong in newer WG's.) > o Investigate how protocol changes, use of multicast, > etc. might support zeroconf environments, of the two > approaches considdered, the WG targets LLMNR as proposed > standard and Discover as experimental. Okay, nothing new but that. > The lifetime of the group is set by the work items above but while > these are ongoing the working group has additional tasks: > > o Advance relevant documents to full standard. This I find possibly unsettling. If DNS was well documented, etc., the different extension efforts (DNSSEC, LLMNR) could run off at independent paces with some matrix-management coordination. But it isn't well documented and maybe we need a monolith. Although leaving DS as a goal for the WG (above), FS possibilities are needed because of the RFC2026 "progress or die" section (6.2, top of page 21). On the other hand, I'd rather see the above added if/when the time comes (heck, we had nothing get to DS in nearly, what, a decade) and we decide to re-charter. > >Goals and Milestones: > > Where there is no milestone for a work item mentioned above, the > working group has not yet decided upon the priority for the item, or, > in some cases, whether active work will be undertaken, and no target > milestone has yet been set. I would strongly encourage that every effort be made to make this milestone list as detailed as possible. Milestones are easily changed (AD permission and mail to ietf-action). With more detail, it'll encourage more maintenance of them. (The one thing this group needs is more attention to detail and process.) There should be no need for any prose in the milestone section...no excuses! > The milestones will be reviewed about 3 times per year, coinciding > with the IETF meeting. Not a milestone, and, should be reviewed every time a milestone is hit/passed. The review takes a few seconds per month and is a good habit to be in. > Jun 03 Submit to IESG OPT-IN as Informational (nomative to RFC2535-bis) It's already June 23rd and I for one don't see that there's any support in the WG for doing this. I am objecting to the milestone date here as we talking about the charter. I can't see this being met. (One of my pet peeves are management plans that try to have deadlines that are too soon for the group to react to.) > o RFC1995 (IXFR) to Draft standard > o RFC1996 (Notify) to Draft Standard. > o RFC2136bis (Dynamic Update) to Draft Standard. > o RFC2181 (Clarify) to Draft Standard. > o RFC2308 (Neg Caching) to Draft Standard. > o RFC2535bis (DNSSEC) to Draft standard. > o RFC2671 (EDNS0) to Draft Standard. > o RFC3007 (Secure Update) to Draft standard. > o RFC3??? (AXFR clarify) to Draft Standard. > o RFC3??? (GSS/TSIG) to Draft Standard > o RFC3??? (Unkown RR) to Draft Standard Off the top of my head, I'd like to add DNAME to that - if we really are trying to get all the PS's progressed. Geezer - RFC 1995? Wasn't that published in, like, 1940? When was the last time a DNS document achieved Draft Standard status? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 17:40: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 RAA11393 for ; Mon, 23 Jun 2003 17:40:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UYz1-00087R-Lb for namedroppers-data@psg.com; Mon, 23 Jun 2003 21:36:15 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.14) id 19UYyy-00086v-V3 for namedroppers@ops.ietf.org; Mon, 23 Jun 2003 21:36:13 +0000 Received: from incognito.wl.nominum.com (dhcp-105.wl.nominum.com [81.200.65.105]) by shell-ng.nominum.com (Postfix) with ESMTP id 667EB56871 for ; Mon, 23 Jun 2003 14:35:59 -0700 (PDT) Received: from incognito.wl.nominum.com (incognito.wl.nominum.com [127.0.0.1]) by incognito.wl.nominum.com (8.12.8/8.12.8) with ESMTP id h5NLZsja002855; Mon, 23 Jun 2003 14:35:54 -0700 Received: from localhost (bwelling@localhost) by incognito.wl.nominum.com (8.12.8/8.12.8/Submit) with ESMTP id h5NLZqFg002851; Mon, 23 Jun 2003 14:35:53 -0700 X-Authentication-Warning: incognito.wl.nominum.com: bwelling owned process doing -bs Date: Mon, 23 Jun 2003 14:35:52 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@incognito.wl.nominum.com To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: Draft Charter. In-Reply-To: <20030623095857.1d2da0bb.olaf@ripe.net> Message-ID: References: <20030623095857.1d2da0bb.olaf@ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-39.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 23 Jun 2003, Olaf M. Kolkman wrote: > o Advance the following existing proposed and draft standards on > the standard track. > > + RFC1995 (IXFR) to Draft standard. > + RFC1996 (Norify) to Draft standard. > + RFC2136bis (Dynamic Update) to Draft Standard. > + RFC2181 (Clarify) to IESG for advancement to Draft Standard. > + RFC2308 (Neg Caching) to Draft Standard. > + RFC2671 (EDNS0) to Draft Standard. > + RFC2835 (TSIG)to Draft standard. > + RFC2930 ( TKEY) to Draft standard. > + RFC3007 (Secure Update) to Draft standard. > + RFC3??? AXFR clarify to Draft Standard. > + RFC3??? GSS/TSIG to Draft Standard Any chance of retrieving ad-is-secure from the IESG black hole? Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 21:46: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 VAA17783 for ; Mon, 23 Jun 2003 21:46:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UckO-000Ftv-33 for namedroppers-data@psg.com; Tue, 24 Jun 2003 01:37:24 +0000 Received: from [66.92.86.178] (helo=zydeco.netbusters.com) by psg.com with esmtp (Exim 4.14) id 19UckM-000Ftj-0W for namedroppers@ops.ietf.org; Tue, 24 Jun 2003 01:37:22 +0000 Received: by zydeco.netbusters.com (Postfix, from userid 513) id 28B7FB63B1; Tue, 24 Jun 2003 01:37:21 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id 275757EC1D; Mon, 23 Jun 2003 21:37:21 -0400 (EDT) Date: Mon, 23 Jun 2003 21:37:21 -0400 (EDT) From: Donald Eastlake 3rd X-X-Sender: dee3@zydeco.netbusters.com To: "Olaf M. Kolkman" Cc: namedroppers@ops.ietf.org Subject: Re: Draft Charter. In-Reply-To: <20030623095857.1d2da0bb.olaf@ripe.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-21.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Is "Case Insensitivity" considered too minor to mention? As far as I know, its ready for WG last call. 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 Mon, 23 Jun 2003, Olaf M. Kolkman wrote: > Date: Mon, 23 Jun 2003 09:58:57 +0200 > From: Olaf M. Kolkman > To: namedroppers@ops.ietf.org > Subject: Draft Charter. > > > Below is a draft for a charter revision. Please send in your comments, we > want to get this to the IESG shortly. > > > -- Olaf Kolkman, DNSEXT co-chair. > > ---------------------------------| Olaf M. Kolkman > ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 23 22:05: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 WAA18207 for ; Mon, 23 Jun 2003 22:05:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Ud7M-000GkK-1K for namedroppers-data@psg.com; Tue, 24 Jun 2003 02:01:08 +0000 Received: from [192.149.252.33] (helo=smtp1.arin.net) by psg.com with esmtp (Exim 4.14) id 19Ud7J-000GiP-M8 for namedroppers@ops.ietf.org; Tue, 24 Jun 2003 02:01:05 +0000 Received: by smtp1.arin.net (Postfix, from userid 5003) id 2DCB43EF; Mon, 23 Jun 2003 22:00:35 -0400 (EDT) Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id D079F38E; Mon, 23 Jun 2003 22:00:34 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 418966; Mon, 23 Jun 2003 21:56:52 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 23 Jun 2003 22:00:37 -0400 To: Donald Eastlake 3rd From: Edward Lewis Subject: Re: Draft Charter. Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It's in the milestones... " Q3/Q4 03 Submit to IESG Case insensitive clarification for proposed standard. " At 21:37 -0400 6/23/03, Donald Eastlake 3rd wrote: >Is "Case Insensitivity" considered too minor to mention? As far as I >know, its ready for WG last call. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 24 07:39: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 HAA12374 for ; Tue, 24 Jun 2003 07:39:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Um1t-000A3L-C2 for namedroppers-data@psg.com; Tue, 24 Jun 2003 11:32:05 +0000 Received: from [193.0.1.96] (helo=birch.ripe.net) by psg.com with esmtp (Exim 4.14) id 19Um1o-000A2q-BK for namedroppers@ops.ietf.org; Tue, 24 Jun 2003 11:32:00 +0000 Received: from x22.ripe.net (x22.ripe.net [193.0.1.22]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h5OBTKRT004063; Tue, 24 Jun 2003 13:29:20 +0200 Date: Tue, 24 Jun 2003 13:29:20 +0200 (CEST) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: namedroppers@ops.ietf.org cc: dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length In-Reply-To: <20030623174016.B97901396A@sa.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ TTD for clients ] On Mon, 23 Jun 2003, David Vixie wrote: > [robert campbell] > > What do clients see from tinydns? Eg, for a record of 'dying.example.com' > > which should expire at T+1500, would it be: > > > > So, Client A and Client B have _nearly_ the same RR set, just with > > different TTLs. > > no. ttl does not affect rrset identity. per [rfc2136 1.1.1] et al. Right. So it would be easy to implement TTD inside a nameserver (ref tinnydns), and provide records to clients with appropriate TTLs without fear of increasing traffic abnormally (the clients won't come back until the record expires), and, theres no protocol change involved. End of argument as far as DNSEXT is concerned. [ propagating TTD information to slaves ] Paul Bernstein wrote: > If you insist on corrupting the zone by retrieving it through AXFR, > you'll get 2-second TTLs from my AXFR server. Of course, the record also > won't disappear until the next AXFR. The effects on the secondary, and > on clients talking to the secondary, are the same as if you had manually > set a 2-second TTL in the first place. So... if a record is due to expire in 1500 seconds, and you know that the slave 'should' transfer the zone again via axfr in 1300 seconds (via SOA values), you will merrily supply a 2 second TTL on said records, thus causing the slave to incur unneeded traffic from clients who effectively cannot cache the record at all and must requery for the record each time they want it. ( For instance, someone taking 3 seconds to reach a web page and clicking on the 'Next' link, resulting in the record being looked up again ) Of course, you'd argue that its because the slaves are using an outdated protocol, but it strikes me that you've coded your nameserver to be intentionally irritating. 'Wow'. Supplying TTLs for expiring records based on the SOA TTL/etc values (with dropping back to 2 second TTLs for those records which should be expired before the slaves next refresh themselves) would be more sensible. Still, when new records are created, you have to propagate the information outwards. Rsync, AXFR and IXFR are all unsuitable for this in a frequently changing environment due to their associated overhead. Dynamic updates sent from the master to each slave are more prompt, although you still have the housekeeping of removing the records once they should have expired (in the absence of remove-after values being able to be sent), and liable to be lost (but will get picked up on the next zone transfer). Wait, aren't we back at the start again? --==-- Bruce. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 24 09:41: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 JAA15893 for ; Tue, 24 Jun 2003 09:41:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Uny8-000EdR-KR for namedroppers-data@psg.com; Tue, 24 Jun 2003 13:36:20 +0000 Received: from [66.92.86.178] (helo=zydeco.netbusters.com) by psg.com with esmtp (Exim 4.14) id 19Uny6-000EdF-3A for namedroppers@ops.ietf.org; Tue, 24 Jun 2003 13:36:18 +0000 Received: by zydeco.netbusters.com (Postfix, from userid 513) id 3C239B63B1; Tue, 24 Jun 2003 13:36:17 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by zydeco.netbusters.com (Postfix) with ESMTP id 3AF007EC1E; Tue, 24 Jun 2003 09:36:17 -0400 (EDT) Date: Tue, 24 Jun 2003 09:36:17 -0400 (EDT) From: Donald Eastlake 3rd X-X-Sender: dee3@zydeco.netbusters.com To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: Draft Charter. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-28.2 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Ooops, sorry. 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 Mon, 23 Jun 2003, Edward Lewis wrote: > Date: Mon, 23 Jun 2003 22:00:37 -0400 > From: Edward Lewis > To: Donald Eastlake 3rd > Cc: Olaf M. Kolkman , namedroppers@ops.ietf.org > Subject: Re: Draft Charter. > > It's in the milestones... > > " Q3/Q4 03 Submit to IESG Case insensitive clarification for proposed > standard. > " > > At 21:37 -0400 6/23/03, Donald Eastlake 3rd wrote: > >Is "Case Insensitivity" considered too minor to mention? As far as I > >know, its ready for WG last call. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jun 24 15:34: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 PAA06487 for ; Tue, 24 Jun 2003 15:34:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UtQt-0001fK-OZ for namedroppers-data@psg.com; Tue, 24 Jun 2003 19:26:23 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19UtQr-0001ex-7u for namedroppers@ops.ietf.org; Tue, 24 Jun 2003 19:26:21 +0000 Received: (qmail 79373 invoked by uid 1016); 24 Jun 2003 19:26:53 -0000 Date: 24 Jun 2003 19:26:53 -0000 Message-ID: <20030624192653.79372.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length References: <20030623174016.B97901396A@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bruce Campbell writes: > So... if a record is due to expire in 1500 seconds, and you know that the > slave 'should' transfer the zone again via axfr in 1300 seconds (via SOA > values), you will merrily supply a 2 second TTL on said records Correct. Yes, short TTLs cause minor increases in the frequency of DNS lookups, but long TTLs cause administrative headaches. If the next AXFR is delayed, the old data will stick around longer than it should. > Still, when new records are created, you have to propagate the information > outwards. Rsync, AXFR and IXFR are all unsuitable for this in a > frequently changing environment due to their associated overhead. Actually, rsync and tinydns-data can make any number of updates to a multiple-megabyte database in well under a second on a typical computer. ---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 Tue Jun 24 17:40: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 RAA12185 for ; Tue, 24 Jun 2003 17:39:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Uv3m-0006iV-NF for namedroppers-data@psg.com; Tue, 24 Jun 2003 21:10:38 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.14) id 19Uv3f-0006iI-JM for namedroppers@ops.ietf.org; Tue, 24 Jun 2003 21:10:31 +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 h5OLAPh1015477; Tue, 24 Jun 2003 14:10:25 -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 h5OLAOBK011327; Tue, 24 Jun 2003 14:10:24 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h5OLAOd7011324; Tue, 24 Jun 2003 14:10:24 -0700 (PDT) Date: Tue, 24 Jun 2003 14:10:24 -0700 (PDT) Message-Id: <200306242110.h5OLAOd7011324@guava.araneus.fi> To: namedroppers@ops.ietf.org Cc: Subject: Re: wild cards and NS records In-Reply-To: <042601c335c5$4191a7c0$b9370681@barnacle> References: <042601c335c5$4191a7c0$b9370681@barnacle> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-20.8 required=5.0 tests=BAYES_01,IN_REP_TO,RCVD_IN_RFCI,REFERENCES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I see no reason to specify that servers SHOULD or even MUST reject a zone merely because it contains a wildcard NS record. It's not like such records cause any harm just by existing - the issue is just that users are confused over what they do (or more precisely, what they don't do, namely create multiple delegations). Documenting the issue and encouraging servers to issue warnings would be a better approach. -- 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 Jun 24 21:24: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 VAA01127 for ; Tue, 24 Jun 2003 21:24:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19UxGs-000Ct9-GU for namedroppers-data@psg.com; Tue, 24 Jun 2003 23:32:18 +0000 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19UxGo-000CsD-O2 for namedroppers@ops.ietf.org; Tue, 24 Jun 2003 23:32:14 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19UsqI-0003vF-Jj for namedroppers@ops.ietf.org; Tue, 24 Jun 2003 11:48:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: Message from Bruce Campbell of "Tue, 24 Jun 2003 13:29:20 +0200." Message-Id: <20030624161310.DFAD313968@sa.vix.com> From: Paul Vixie To: namedroppers@ops.ietf.org, dhcwg@ietf.org Subject: Re: [dhcwg] DDNS-DHCP [6]: Relationship between DNS TTL and DHCP lease length Date: Tue, 24 Jun 2003 16:13:10 +0000 X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Still, when new records are created, you have to propagate the > information outwards. Rsync, AXFR and IXFR are all unsuitable for > this in a frequently changing environment due to their associated > overhead. ... "sez you." before it was called dnsext, this wg was called dnsind. that stood for Incrementalzonetransfer, Notificationofchanges, and Dynamicupdate; these were the three features that the powers that were decided were needed in order to support DHCP and IPv6, which were the New things in ~1994. the architectural paradigm was to use Update to get things into the master, Notify to make the slaves aware of these new changes without waiting for an SOA timer to expire, and IXFR to get these changes distributed to the slaves without having to transfer all the unchanged data as well. interestingly, ohta-san preferred a different, masterless model, but he still did IXFR when consensus went in favour of the i-n-d model. also interesting was microsoft, who went for a masterless model using non-DNS channels for synchronization (but they never did implement healing after a partition event.) now as to performance. a company who was bundling BIND8 into a dhcp/dns integration product stress tested the i-n-d model, and found all kinds of early (pre-Y2K) data corruption bugs in our IXFR implementation. their goal was to be able to shoot thousands of DHCP-originated PTR updates per second through BIND8 and have the slaves remain synchronized -- and it all works fine. therefore i dispute ("sez you") your assertion of "unsuitable". various other commercial entities, mostly non-BIND based, have also reached these transaction volumes, using the i-n-d model. you may not think it's pretty, but noone has yet found a real world workload that the model can't address if you use the right hardware and software to support the load. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 25 03:58: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 DAA04256 for ; Wed, 25 Jun 2003 03:58:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19V51I-00020v-61 for namedroppers-data@psg.com; Wed, 25 Jun 2003 07:48:44 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.14) id 19V51G-000201-CV for namedroppers@ops.ietf.org; Wed, 25 Jun 2003 07:48:42 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5P7mAKo025376; Wed, 25 Jun 2003 00:48:10 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5P7m9Q16467; Wed, 25 Jun 2003 09:48:09 +0200 (MEST) Date: Wed, 25 Jun 2003 07:04:54 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Draft Charter. To: Brian Wellington Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Any chance of retrieving ad-is-secure from the IESG black hole? It's in my plate - not the IESG as a whole. One of the things I intend to finish before I depart in Vienna. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 25 04:52: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 DAA04257 for ; Wed, 25 Jun 2003 03:58:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19V50p-00020F-KK for namedroppers-data@psg.com; Wed, 25 Jun 2003 07:48:15 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19V50n-000203-JR for namedroppers@ops.ietf.org; Wed, 25 Jun 2003 07:48:13 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5P7mAvc022911; Wed, 25 Jun 2003 01:48:11 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5P7m9Q16471; Wed, 25 Jun 2003 09:48:09 +0200 (MEST) Date: Wed, 25 Jun 2003 07:10:14 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Draft Charter. To: Edward Lewis Cc: "Olaf M. Kolkman" , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The latter sentence refers in part to the quagmire that is AXFR > clarify. Whether or not consensus has been reached, we do need to > clarify this topic. As I understand the process the WG has submitted the document to the IESG and it is up to the IESG to interpret the IETF last call comments (recommending to the IESG how to proceed is the second DNSEXT thing I need to finish before Vienna). Until this has been done I think it is perfectly reasonable for the WG to assume that the document will become a proposed standard since it is out of the WG's hands. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jun 25 15:53:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28589 for ; Wed, 25 Jun 2003 15:53:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VGBf-0002uC-Im for namedroppers-data@psg.com; Wed, 25 Jun 2003 19:44:11 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.14) id 19VGBc-0002t0-U6 for namedroppers@ops.ietf.org; Wed, 25 Jun 2003 19:44:09 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 41C0118E1 for ; Wed, 25 Jun 2003 15:43:08 -0400 (EDT) Date: Wed, 25 Jun 2003 15:43:08 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-dns-threats-03.txt 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: <20030625194308.41C0118E1@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20,USER_AGENT version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I just discovered that, although Derek and I had already incorporated all of the last call comments to the -threats draft, we had, er, forgotten to post the revised draft. Oops. So I just did. For now, you can find the new version at: http://www.hactrn.net/ietf/dns/threats/ draft-ietf-dnsext-dns-threats-03.txt and an "htmlwdiff" (thanks, fenner!) at: http://www.hactrn.net/ietf/dns/threats/changes-from-02-to-03.html --Rob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 26 03:27: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 DAA11017 for ; Thu, 26 Jun 2003 03:26:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VR2f-0000Ft-It for namedroppers-data@psg.com; Thu, 26 Jun 2003 07:19:37 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19VR2d-0000F8-MA for namedroppers@ops.ietf.org; Thu, 26 Jun 2003 07:19:35 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5Q7J3fU002722 for ; Thu, 26 Jun 2003 00:19:04 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5Q7J3Q17380 for ; Thu, 26 Jun 2003 09:19:03 +0200 (MEST) Date: Thu, 26 Jun 2003 09:18:38 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Last Call: Domain Name System Uniform Resource Identifiers to Proposed Standard (Fwd) To: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200306242031.QAA09843@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-7.5 required=5.0 tests=BAYES_01,IN_REP_TO,SUBJ_HAS_SPACES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >----------------Begin Forwarded Message----------------< Date: Tue, 24 Jun 2003 16:31:51 -0400 From: "The IESG" Subject: Last Call: Domain Name System Uniform Resource Identifiers to Proposed Standard To: IETF-Announce@, @ The IESG has received a request to consider Domain Name System Uniform Resource Identifiers as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-7-22. Files can be obtained via http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-08.txt >----------------End Forwarded Message----------------< -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 26 09:44:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24566 for ; Thu, 26 Jun 2003 09:44:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VWuJ-000DeK-79 for namedroppers-data@psg.com; Thu, 26 Jun 2003 13:35:23 +0000 Received: from [193.0.1.96] (helo=birch.ripe.net) by psg.com with esmtp (Exim 4.14) id 19VWuG-000De6-Nj for namedroppers@ops.ietf.org; Thu, 26 Jun 2003 13:35:20 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h5QDZJRS010529 for ; Thu, 26 Jun 2003 15:35:19 +0200 Message-Id: <200306261335.h5QDZJRS010529@birch.ripe.net> To: namedroppers@ops.ietf.org Subject: Delegation Signer Document Done. Date: Thu, 26 Jun 2003 15:35:19 +0200 From: Olaf Kolkman X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Lectori Salutem, With reference to draft-ietf-dnsext-delegation-signer-15.txt After Olafurs message dd. May22, 2003 (see URL below) the draft has been updated based on a number of comments directed to the author. Below is the summary of changes I identified (excluding minor style and typo corrections) between the version that was in the repository the 22nd of May and the current version. I am ready to inform the AD that the document is done and will do so unless there are objections by Tuesday Jul 1 around noon CEST (Note the timezone :-)) --Olaf Changes 14->15 (Date: 2003-6-19) - Throughout the document a number of minor style and typo errors where corrected. - Included Table of content - In section 1: Added explicit reference to RFC3445 - In section 2.2.2.1 (Special processing for DS queries) "point and receives a query for the DS record at that name, it will return the DS from the parent zone. This is true whether or not it is also authoritative for the child zone." was rewritten to: "point and receives a query for the DS record at that name, it MUST answer based on data in the parent zone, return DS or negative answer. This is true whether or not it is also authoritative for the child zone." "MAY" was capitalized in the following sentence: ".. DS record at the delegation point, or MAY return the DS record from its cache..." - In section 2.2.1.2 "When a server receives a query for (, DS, IN)," was replaced by: "When a server receives a query for (, DS, )," -In section 2.2.1.3 "RFC2535 included rules to in add KEY records to additional section when SOA or NS records where included in an answer. The is was done to reduce round trips (in the case of SOA) and to force out NULL KEY's (in the NS case), as this document obsoletes NULL keys there is no need for the second case, the first case causes redundant transfers of KEY RRset as SOA is included in the authority section of negative answers. RFC2535 section 3.5 also included rule for adding KEY RRset to query for A and AAAA, as Restrict KEY[RFC3445] eliminated use of KEY RR by all applications therefore the rule is not needed anymore." was rewritten to: "RFC2535 specified that KEY records be added to the additional section when SOA or NS records where included in an answer. This was done to reduce round trips (in the case of SOA) and to force out NULL KEYs (in the NS case). As this document obsoletes NULL keys there is no need for the inclusion of KEYs with NSs. Furthermore as SOAs are included in the authority section of negative answers, including the KEYs each time will cause redundant transfers of KEYs. RFC2535 section 3.5 also included rule for adding the KEY RRset to the response for a query for A and AAAA types. As Restrict KEY[RFC3445] eliminated use of KEY RR by all applications this rule is no longer needed." - In section 2.2.2. "MAY" was capitalized in the following sentence: "for DNSSEC validation; local policy MAY override the standard policy." - In section 2.4: " For interoperability reasons, as few digest algorithms as possible should be reserved. The only reason to reserve additional digest types is to increase security." was reworded to: "For interoperability reasons, keeping number of digest algorithms low is strongly RECOMMENDED. The only reason to reserve additional digest types is to increase security." - In section 2.6.2 "enough change to cause a flag day." changed to: "enough change that a flag day is required." Olafurs message can be found at: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01130.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jun 26 10:09: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 KAA26204 for ; Thu, 26 Jun 2003 10:08:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19VXNh-000FBk-44 for namedroppers-data@psg.com; Thu, 26 Jun 2003 14:05:45 +0000 Received: from [193.0.1.96] (helo=birch.ripe.net) by psg.com with esmtp (Exim 4.14) id 19VXNe-000FBM-EG for namedroppers@ops.ietf.org; Thu, 26 Jun 2003 14:05:42 +0000 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.9/8.11.6) with ESMTP id h5QE51RS016757; Thu, 26 Jun 2003 16:05:01 +0200 Message-Id: <200306261405.h5QE51RS016757@birch.ripe.net> To: namedroppers@ops.ietf.org cc: agenda@ietf.org Subject: DNSEXT agenda Date: Thu, 26 Jun 2003 16:05:01 +0200 From: Olaf Kolkman X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk LS, After receiving a few off-line comments the agenda for the coming meeting has been updated. --Olaf Kolkman ---------------------------------------------------------------------- DNS Extensions WG (dnsext) Tuesday, July 15, 1300-1400 Afternoon Sessions I Chairs: Olafur Gudmundsson, Olaf Kolkman. ------------------------------------------------------------ - Administrivia 3 min agenda bashing appointing scribes - Charter 7 min For draft, see mailing list dd Mon, 23 Jun 2003 - Bernard Aboba Linklocal Multicast Name Resolution (LLMNR) (summary of changes since IETF56) draft-ietf-dnsext-mdns-21.txt 5 min - DNSSEC editors report 5 min presentation 10 min discussion draft-ietf-dnsext-dnssec-intro-05.txt draft-ietf-dnsext-dnssec-protocol-01.txt draft-ietf-dnsext-dnssec-records-03.txt - Ed Lewis 10 min Wildcard Clarification draft-lewis-dns-wildcard-clarify-00.tx - Mike St Johns. 5 min Using DNSSEC-secured NOTIFY to Trigger Parent Zone Updating draft-stjohns-secure-notify-00 - Mohsen Souissi Update on RFC2845 (TSIG) interop tests 5 min - AOB 5 min Please inform chairs in advance of the meeting. ------------------------------------------------------------ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 27 03:51: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 DAA19992 for ; Fri, 27 Jun 2003 03:50:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Vnvn-00066R-4z for namedroppers-data@psg.com; Fri, 27 Jun 2003 07:46:03 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.14) id 19Vnvk-00063j-2f for namedroppers@ops.ietf.org; Fri, 27 Jun 2003 07:46:00 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h5R7jSKo027201; Fri, 27 Jun 2003 00:45:29 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5R7jRQ00332; Fri, 27 Jun 2003 09:45:27 +0200 (MEST) Date: Fri, 27 Jun 2003 09:45:00 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Delegation Signer Document Done. To: Olaf Kolkman Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200306261335.h5QDZJRS010529@birch.ripe.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Some quick review comments. If there are no comments requring changes from the WG these comments can be addressed after the IETF last call is done. Let me know when you want me to start the IETF last call. The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", There is no "MAY NOT" in RFC 2119. 5) If the server is not authoritative for any part of the QNAME, a response indicating a lame server for QNAME is given. I'm concerned that implementors might not know how to format such a response. (Is it a delegation up the tree? something else?) I haven't seen a definition of a lame response in an RFC so I think this needs to spell out more about the response to send. Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 27 04:05: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 EAA20206 for ; Fri, 27 Jun 2003 04:05:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Vndx-0005K2-Qq for namedroppers-data@psg.com; Fri, 27 Jun 2003 07:27:37 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19Vndt-0005Iv-2P for namedroppers@ops.ietf.org; Fri, 27 Jun 2003 07:27:33 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5R7RUvc017840; Fri, 27 Jun 2003 01:27:30 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5R7RTQ27664; Fri, 27 Jun 2003 09:27:29 +0200 (MEST) Date: Fri, 27 Jun 2003 09:25:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Delegation Signer Document Done. To: Olaf Kolkman Cc: namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200306261335.h5QDZJRS010529@birch.ripe.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Some quick comments. If there aren't more substantial comments from the WG these can be fixed after the IETF last call. 1.2 Reserved Words The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", There is no such thing as "MAY NOT" in RFC 2119. 5) If the server is not authoritative for any part of the QNAME, a response indicating a lame server for QNAME is given. Is the format of a response indicating a lame server well defined? Well known? I haven't seen an actual definition in a RFC. Or does it make sense to spell out what the response will contain? Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 27 04:13:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20358 for ; Fri, 27 Jun 2003 04:13:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Vo9e-0006tD-LF for namedroppers-data@psg.com; Fri, 27 Jun 2003 08:00:22 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19Vo9b-0006pS-QL for namedroppers@ops.ietf.org; Fri, 27 Jun 2003 08:00:19 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h5R7xlfU018634; Fri, 27 Jun 2003 00:59:48 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h5R7xlQ01682; Fri, 27 Jun 2003 09:59:47 +0200 (MEST) Date: Fri, 27 Jun 2003 09:59:20 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknown DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown-rrs-05 To: Andreas Gustafsson Cc: Erik Nordmark , namedroppers@ops.ietf.org In-Reply-To: "Your message with ID" <200305181739.h4IHd0pq005037@guava.araneus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Therefore, my suggestion is to simply remove the IANA Considerations > section from the draft. Any objections? How about respinning the draft with this change and I'll get it in front of the IESG in two weeks? Let me know when the draft is submitted since it might take a while before it is announced. Thanks, Erik -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jun 27 13:38: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 NAA08259 for ; Fri, 27 Jun 2003 13:38:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Vx31-0000vA-7q for namedroppers-data@psg.com; Fri, 27 Jun 2003 17:30:07 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.14) id 19Vx2t-0000ti-G4 for namedroppers@ops.ietf.org; Fri, 27 Jun 2003 17:29:59 +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 h5RHTvh1005458; Fri, 27 Jun 2003 10:29:57 -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 h5RHTv8o000535; Fri, 27 Jun 2003 10:29:57 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h5RHTsY7000532; Fri, 27 Jun 2003 10:29:54 -0700 (PDT) Date: Fri, 27 Jun 2003 10:29:54 -0700 (PDT) Message-Id: <200306271729.h5RHTsY7000532@guava.araneus.fi> To: Erik Nordmark Cc: namedroppers@ops.ietf.org Subject: RE: Evaluation: draft-ietf-dnsext-unknown-rrs -Handling of Unknown DNS Resource Record Types to Proposed Standardraft-ietf-dnsext-unknown-rrs-05 In-Reply-To: References: <200305181739.h4IHd0pq005037@guava.araneus.fi> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-37.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Erik Nordmark writes: > > Therefore, my suggestion is to simply remove the IANA Considerations > > section from the draft. Any objections? > > How about respinning the draft with this change and I'll get it in front > of the IESG in two weeks? Will do. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 07:48: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 HAA11437 for ; Mon, 30 Jun 2003 07:48:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Wwzb-0001ns-0Z for namedroppers-data@psg.com; Mon, 30 Jun 2003 11:38:43 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19WwzY-0001nS-1g for namedroppers@ops.ietf.org; Mon, 30 Jun 2003 11:38:40 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10762; Mon, 30 Jun 2003 07:37:45 -0400 (EDT) Message-Id: <200306301137.HAA10762@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-dns-threats-03.txt Date: Mon, 30 Jun 2003 07:37:45 -0400 X-Spam-Status: No, hits=3.1 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Threat Analysis Of The Domain Name System Author(s) : D. Atkins, R. Austein Filename : draft-ietf-dnsext-dns-threats-03.txt Pages : 15 Date : 2003-6-27 Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-dns-threats-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-27150122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dns-threats-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dns-threats-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-27150122.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 16:46: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 QAA15178 for ; Mon, 30 Jun 2003 16:46:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19X5Qe-000OFg-1g for namedroppers-data@psg.com; Mon, 30 Jun 2003 20:39:12 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.14) id 19X5QX-000OEx-6U for namedroppers@ops.ietf.org; Mon, 30 Jun 2003 20:39:05 +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 h5UKd3h1026528; Mon, 30 Jun 2003 13:39:03 -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 h5UKd3m8003273; Mon, 30 Jun 2003 13:39:03 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h5UKd2df003270; Mon, 30 Jun 2003 13:39:02 -0700 (PDT) Date: Mon, 30 Jun 2003 13:39:02 -0700 (PDT) Message-Id: <200306302039.h5UKd2df003270@guava.araneus.fi> To: namedroppers@ops.ietf.org CC: Mike.StJohns@nominum.com Subject: draft-stjohns-secure-notify-00.txt From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, SATISFACTION autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk In draft-stjohns-secure-notify-00.txt, M. StJohns writes: > In fact, best practice requires that a zone be served by at least one > server that can be referenced by a name not within that zone. My interpretation of RFC2182 is that a zone should have at least one server on a geographically and topologically distinct network, but I see no requirement that it be referenced by a name in a different zone. > The parent zone MUST verify the names pointed to by the NS are > resolvable, that at least one name points to a server not named in > the child zone, and that it has glue A records for any server named > in the child zone. [Q: Does this make sense, or is it better to just > trust the child?] If these conditions are not satisfied, the parent > server MUST NOT install the new records, and MUST log the problem I don't think this makes sense. Whether the best practice is to have a server in a different zone or just on a different network, it is just an operational recommendation and not something that should be enforced as part of the protocol. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 17:07: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 RAA16385 for ; Mon, 30 Jun 2003 17:07:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19X5nz-0000gt-RG for namedroppers-data@psg.com; Mon, 30 Jun 2003 21:03:19 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.14) id 19X5nt-0000fE-NM for namedroppers@ops.ietf.org; Mon, 30 Jun 2003 21:03:13 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 46B3556842; Mon, 30 Jun 2003 14:03:00 -0700 (PDT) Message-Id: <5.2.1.1.2.20030630165223.026f4008@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 30 Jun 2003 17:03:01 -0400 To: Andreas.Gustafsson@nominum.com (Andreas Gustafsson), namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: draft-stjohns-secure-notify-00.txt In-Reply-To: <200306302039.h5UKd2df003270@guava.araneus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-25.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,SATISFACTION autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:39 6/30/2003, Andreas Gustafsson wrote: >In draft-stjohns-secure-notify-00.txt, M. StJohns writes: > > In fact, best practice requires that a zone be served by at least one > > server that can be referenced by a name not within that zone. > >My interpretation of RFC2182 is that a zone should have at least one >server on a geographically and topologically distinct network, but I >see no requirement that it be referenced by a name in a different >zone. yeah - I can actually read 2182 either way - specifically section 6 discussion of the selection of secondaries. I'd be interested in understanding what others think is best practice here. The reason I like the name diversity constraint is because it provides one more resolution path to the delegated zone, even if the glue records in the parent are messed up or more probably, missing. > > The parent zone MUST verify the names pointed to by the NS are > > resolvable, that at least one name points to a server not named in > > the child zone, and that it has glue A records for any server named > > in the child zone. [Q: Does this make sense, or is it better to just > > trust the child?] If these conditions are not satisfied, the parent > > server MUST NOT install the new records, and MUST log the problem > >I don't think this makes sense. Whether the best practice is to have >a server in a different zone or just on a different network, it is >just an operational recommendation and not something that should be >enforced as part of the protocol. To be clear, your issue is with "that at least one name points to a server not named in the child zone" and not with the rest of it as above? Yeah - this might either be a) removed, b) turned into a policy configuration item (e.g. something the parent zone wants to enforce on the child - in which case this section become MAY) or c) left as a MUST. My guess is that either a or b is probably appropriate given our off line discussion. >-- >Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 17:28: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 RAA17122 for ; Mon, 30 Jun 2003 17:28:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19X69B-0002iT-56 for namedroppers-data@psg.com; Mon, 30 Jun 2003 21:25:13 +0000 Received: from [198.151.13.15] (helo=portal.east.saic.com) by psg.com with smtp (Exim 4.14) id 19X696-0002hO-IS for namedroppers@ops.ietf.org; Mon, 30 Jun 2003 21:25:08 +0000 Received: from mcl-its-dq.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; Mon, 30 Jun 2003 17:25:08 -0400 Received: from mcl-its-ieg01.mail.saic.com by mcl-its-dq.saic.com for namedroppers@ops.ietf.org; Mon, 30 Jun 2003 17:24:52 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.2.21) with SMTP id M2003063017245122114 for ; Mon, 30 Jun 2003 17:24:51 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 17:24:06 -0400 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104BE0@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: namedroppers@ops.ietf.org Subject: RE: draft-stjohns-secure-notify-00.txt Date: Mon, 30 Jun 2003 17:25:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,SATISFACTION autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > In fact, best practice requires that a zone be served > > > by at least one > > > server that can be referenced by a name not within that zone. > > > >My interpretation of RFC2182 is that a zone should have at least one > >server on a geographically and topologically distinct network, but I > >see no requirement that it be referenced by a name in a different > >zone. > > yeah - I can actually read 2182 either way My interpretation of it, upon re-reading, still matches Andreas. > I'd be interested in understanding what others think is best practice > here. I think that the "name diversity constraint" (as you refer to it) is a great idea to suggest, but not something that even rates a SHOULD in terms of an IETF document. It's not realistic for many folks... anyone who happens to have umptyscrumpty.com should now also have a nameserver for that zone living under .net or another TLD??? Please demonstrate the clear overall benefit... > > > The parent zone MUST verify the names pointed to by the NS are > > > resolvable, that at least one name points to a server > not named in > > > the child zone, and that it has glue A records for any > server named > > > in the child zone. [Q: Does this make sense, or is it > better to just > > > trust the child?] If these conditions are not > satisfied, the parent > > > server MUST NOT install the new records, and MUST log > the problem > > > >I don't think this makes sense. Whether the best practice is to have > >a server in a different zone or just on a different network, it is > >just an operational recommendation and not something that should be > >enforced as part of the protocol. > > To be clear, your issue is with "that at least one name > points to a server not named in the child zone" and not > with the rest of it as above? Yeah - > this might either be a) removed, [...] I recommend (a), removing that requirement. I don't think that the wording makes sense (a server not named in the child zone? Do you really mean a server that is not "under" the child zone, or one that is not the RHS of an NS RR in the child zone, or what?) but I think that you're trying to spell out a MUST based on the item above which I don't think even rates a SHOULD. -- Rip Loomis, CISSP Senior Systems Security Engineer, SAIC Enterprise Security Solutions -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 17:54: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 RAA17843 for ; Mon, 30 Jun 2003 17:54:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19X6XK-00050f-8W for namedroppers-data@psg.com; Mon, 30 Jun 2003 21:50:10 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.14) id 19X6XE-0004xs-5l for namedroppers@ops.ietf.org; Mon, 30 Jun 2003 21:50:04 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id EB6FF5683D; Mon, 30 Jun 2003 14:49:50 -0700 (PDT) Message-Id: <5.2.1.1.2.20030630173307.01d94678@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 30 Jun 2003 17:49:51 -0400 To: "Loomis, Rip" , namedroppers@ops.ietf.org From: Mike StJohns Subject: RE: draft-stjohns-secure-notify-00.txt In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104BE0@US-Columbia-CIST.ma il.saic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,SATISFACTION autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:25 6/30/2003, Loomis, Rip wrote: > > > > In fact, best practice requires that a zone be served > > > > by at least one > > > > server that can be referenced by a name not within that zone. > > > > > >My interpretation of RFC2182 is that a zone should have at least one > > >server on a geographically and topologically distinct network, but I > > >see no requirement that it be referenced by a name in a different > > >zone. > > > > yeah - I can actually read 2182 either way >My interpretation of it, upon re-reading, still matches Andreas. > > > I'd be interested in understanding what others think is best practice > > here. >I think that the "name diversity constraint" (as you refer to it) is >a great idea to suggest, but not something that even rates a SHOULD >in terms of an IETF document. It's not realistic for many folks... >anyone who happens to have umptyscrumpty.com should now also have >a nameserver for that zone living under .net or another TLD??? >Please demonstrate the clear overall benefit... Nope - if I'm running zone foo.com, what I mean to say is that I'll need to have a NS record pointing to a host that does not end in foo.com - that's all. Benefit? Let's assume for foo.com at master.foo.com, secondaries at secondary.foo.com and foreignsecondary.bar.com. There will be NS records for master.foo.com, secondary.foo.com and foreignsecondary.bar.com and hopefully glue records for the first two. In the event that the glue records get screwed up, there's still the possibility of completing the resolution by following the delegation chain for bar.com which has its own glue records. Think of it as one further way of reducing fate sharing. > > > > The parent zone MUST verify the names pointed to by the NS are > > > > resolvable, that at least one name points to a server > > not named in > > > > the child zone, and that it has glue A records for any > > server named > > > > in the child zone. [Q: Does this make sense, or is it > > better to just > > > > trust the child?] If these conditions are not > > satisfied, the parent > > > > server MUST NOT install the new records, and MUST log > > the problem > > > > > >I don't think this makes sense. Whether the best practice is to have > > >a server in a different zone or just on a different network, it is > > >just an operational recommendation and not something that should be > > >enforced as part of the protocol. > > > > To be clear, your issue is with "that at least one name > > points to a server not named in the child zone" and not > > with the rest of it as above? Yeah - > > this might either be a) removed, [...] > >I recommend (a), removing that requirement. I don't think that the >wording makes sense (a server not named in the child zone? Do you >really mean a server that is not "under" the child zone, or one that >is not the RHS of an NS RR in the child zone, or what?) but I think >that you're trying to spell out a MUST based on the item above which >I don't think even rates a SHOULD. Actually, I did mean "a server not named in the child zone". For a delegation for "foo.com" "secondary.foo.com" "another.level.foo.com" are all named in the child zone "foo.com". "myhost.bar.com" is not. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 21:00:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24930 for ; Mon, 30 Jun 2003 21:00:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19X9Oe-000LKf-VB for namedroppers-data@psg.com; Tue, 01 Jul 2003 00:53:24 +0000 Received: from [2001:4f8:3:ba:2d0:a8ff:fe00:5581] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.14) id 19X9OZ-000LJs-CM for namedroppers@ops.ietf.org; Tue, 01 Jul 2003 00:53:19 +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 h610rGh1027232; Mon, 30 Jun 2003 17:53:16 -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 h610rHm8004496; Mon, 30 Jun 2003 17:53:17 -0700 (PDT) Received: (from gson@localhost) by guava.araneus.fi (8.12.9/8.12.6/Submit) id h610rEh1004493; Mon, 30 Jun 2003 17:53:14 -0700 (PDT) Date: Mon, 30 Jun 2003 17:53:14 -0700 (PDT) Message-Id: <200307010053.h610rEh1004493@guava.araneus.fi> To: Mike StJohns Cc: namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt In-Reply-To: <5.2.1.1.2.20030630165223.026f4008@localhost> References: <200306302039.h5UKd2df003270@guava.araneus.fi> <5.2.1.1.2.20030630165223.026f4008@localhost> X-Mailer: VM 7.04 under Emacs 20.7.1 From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-36.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI,REFERENCES,REPLY_WITH_QUOTES,SATISFACTION, USER_AGENT_VM autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mike StJohns writes: > > > The parent zone MUST verify the names pointed to by the NS are > > > resolvable, that at least one name points to a server not named in > > > the child zone, and that it has glue A records for any server named > > > in the child zone. [Q: Does this make sense, or is it better to just > > > trust the child?] If these conditions are not satisfied, the parent > > > server MUST NOT install the new records, and MUST log the problem > > > >I don't think this makes sense. Whether the best practice is to have > >a server in a different zone or just on a different network, it is > >just an operational recommendation and not something that should be > >enforced as part of the protocol. > > To be clear, your issue is with "that at least one name points to a server > not named in the child zone" and not with the rest of it as above? That was the specific issue I wanted to address, but since you ask, I don't think the rest of the paragraph is a good idea, either. It seems to me that the parent refusing the update would leave an NS and/or DS inconsistency that in itself is more harmful than the glue inconsistency the parent is reacting to. -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 21:19: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 VAA25308 for ; Mon, 30 Jun 2003 21:19:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19X9kU-000NYS-PI for namedroppers-data@psg.com; Tue, 01 Jul 2003 01:15:58 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.14) id 19X9kS-000NX1-79 for namedroppers@ops.ietf.org; Tue, 01 Jul 2003 01:15:56 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 8935A56837; Mon, 30 Jun 2003 18:15:42 -0700 (PDT) Message-Id: <5.2.1.1.2.20030630210443.0260e780@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 30 Jun 2003 21:15:43 -0400 To: Andreas.Gustafsson@nominum.com (Andreas Gustafsson) From: Mike StJohns Subject: Re: draft-stjohns-secure-notify-00.txt Cc: namedroppers@ops.ietf.org In-Reply-To: <200307010053.h610rEh1004493@guava.araneus.fi> References: <5.2.1.1.2.20030630165223.026f4008@localhost> <200306302039.h5UKd2df003270@guava.araneus.fi> <5.2.1.1.2.20030630165223.026f4008@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-31.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SATISFACTION autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 20:53 6/30/2003, Andreas Gustafsson wrote: >Mike StJohns writes: > > > > The parent zone MUST verify the names pointed to by the NS are > > > > resolvable, that at least one name points to a server not named in > > > > the child zone, and that it has glue A records for any server named > > > > in the child zone. [Q: Does this make sense, or is it better to just > > > > trust the child?] If these conditions are not satisfied, the parent > > > > server MUST NOT install the new records, and MUST log the problem > > > > > >I don't think this makes sense. Whether the best practice is to have > > >a server in a different zone or just on a different network, it is > > >just an operational recommendation and not something that should be > > >enforced as part of the protocol. > > > > To be clear, your issue is with "that at least one name points to a server > > not named in the child zone" and not with the rest of it as above? > >That was the specific issue I wanted to address, but since you ask, I >don't think the rest of the paragraph is a good idea, either. It >seems to me that the parent refusing the update would leave an NS >and/or DS inconsistency that in itself is more harmful than the glue >inconsistency the parent is reacting to. >-- Yeah -- the right answer might be to conditionally accept the update, but wait for approval from a human. On the other hand, there are some meta protocol things that should take place. For example, if you're deleting a server, you need to update the NS records to delete the server, then confirm they've been updated before taking the server out of service. Operationally, there should never be wholesale changes - the adds/deletes/changes are generally 3 phase commits. I've got a set of slides on how to do DS updates that I can provide - pdf format that describes some of the broader process issues. There will be some inconsistency, but that can be managed somewhat automatically with the server flagging the exception points. Actually, now that I've thought about it, rejecting records where the servers aren't routable/reachable, where the extra-zone names can't resolve, and where the glue records aren't correct is probably more correct than accepting them. As long as the check can be done as part of the notify transaction and the child is given the rejection then, there shouldn't be any consistency issue (or rather no issue worse than what happens currently?). >Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 22:59:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27657 for ; Mon, 30 Jun 2003 22:59:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XBI2-00071I-Kp for namedroppers-data@psg.com; Tue, 01 Jul 2003 02:54:42 +0000 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.14) id 19XBI0-00070s-3C for namedroppers@ops.ietf.org; Tue, 01 Jul 2003 02:54:40 +0000 Received: (qmail 3569 invoked by uid 1016); 1 Jul 2003 02:55:11 -0000 Date: 1 Jul 2003 02:55:11 -0000 Message-ID: <20030701025511.3568.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: draft-stjohns-secure-notify-00.txt References: <200306302039.h5UKd2df003270@guava.araneus.fi> <5.2.1.1.2.20030630165223.026f4008@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=-25.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mike StJohns writes: > The reason I like the name diversity constraint is because it provides > one more resolution path to the delegated zone, even if the glue > records in the parent are messed up or more probably, missing. You have the situation backwards. Forcing the resolution process to go through extra servers doesn't help reliability; it hurts reliability. Gluelessness is the single most common source of DNS lookup failures. (If you don't have enough DNS experience to realize this, why are you writing DNS documents?) Best practice is to have completely glued names everywhere. VeriSign's software used to have trouble with this practice, but they recognized their mistake and fixed it. This has nothing to do with the physical location of servers. Sites should, of course, have their DNS servers spread just as widely as their HTTP servers, SMTP servers, etc. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jun 30 23:03: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 XAA27725 for ; Mon, 30 Jun 2003 23:03:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XBNF-0007bh-9K for namedroppers-data@psg.com; Tue, 01 Jul 2003 03:00:05 +0000 Received: from randy by psg.com with local (Exim 4.14) id 19XBNB-0007ai-8C for namedroppers@ops.ietf.org; Tue, 01 Jul 2003 03:00:01 +0000 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Tue, 01 Jul 2003 03:00:01 +0000 X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. posts are only accepted from subscribers. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to namedroppers-owner@ops.ietf.org and ask to have your alternate address added to the list of addresses from which submissions are automatically accepted. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: