From scottr.nist@gmail.com Wed Jun 1 04:22:39 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E9EE074A for ; Wed, 1 Jun 2011 04:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBh+UQ52sUBg for ; Wed, 1 Jun 2011 04:22:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB7F8E06D8 for ; Wed, 1 Jun 2011 04:22:36 -0700 (PDT) Received: by wyb29 with SMTP id 29so4727113wyb.31 for ; Wed, 01 Jun 2011 04:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=AZpWIhPtOfFxAmQ2d4YmAlqXYFK8AxQMQjX+Ejl1BYc=; b=qsEZNmm8mMvQR5KaC4/sJZeX1Cbwrlj/PhKIVauvT0IRniKQmQzo3oVGdb6ECe+v4U 5uXy6XDZ9A1gl43ZRCdRgx3s62SxFXo3ClRt84nwqKP2DIkhiVpt3yu5Pl1hpj2u+BHG BQMQSwymnKRCZqkHvRniGC5zC+YskabbkzoPk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=EZ3lZbD7e13Sm+t/er1f/nJqMVj4RWq8cDz5d6G8Mzhhu5FPj/NMCiiSG5//AIq81q 6+0yazYnrBZ+1UEpgtsqOUHBDAssYs0lxJpXFGB3SRdDhtQ2WbksxW9/e4JqLAu8kHP/ 24ZnbqyAYsHs9w7UfIZfch6199TxsyxuMGEco= MIME-Version: 1.0 Received: by 10.216.145.206 with SMTP id p56mr4648619wej.80.1306927355436; Wed, 01 Jun 2011 04:22:35 -0700 (PDT) Received: by 10.216.87.21 with HTTP; Wed, 1 Jun 2011 04:22:35 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2011 07:22:35 -0400 Message-ID: From: Scott Rose To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=0016e6de0444c49e6f04a4a4bc60 Subject: Re: [dnsext] Small proposed change to draft-registry-fixes X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 11:22:39 -0000 --0016e6de0444c49e6f04a4a4bc60 Content-Type: text/plain; charset=ISO-8859-1 I'd say a firm "Probably never". So "Reserved" will work for the foreseeable future of DNSSEC. Scott On Tue, May 31, 2011 at 1:32 PM, Edward Lewis wrote: > At 13:18 -0400 5/31/11, Scott Rose wrote: > > Or should it simply be "Reserved" and leave it at that? >> > > How soon are we going to run out of numbers? > > (It's not like we haven't been sloppy before. See RR type code > 3,4,7,8,10,...,40, or my favorites 32 [double useless] and 33 [half > useless].) > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > Now, don't say I'm always complaining. > Wait, that's a complaint, isn't it? > --0016e6de0444c49e6f04a4a4bc60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd say a firm "Probably never".

So "= Reserved" will work for the=A0foreseeable=A0future of DNSSEC.

Scott


On Tue, May 31, 2011 at 1:32 PM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:=
At 13:18 -0400 5/31/11, Scott Rose wrote:

Or should it simply be "Reserved" and leave it at that?

How soon are we going to run out of numbers?

(It's not like we haven't been sloppy before. =A0See RR type code 3= ,4,7,8,10,...,40, or my favorites 32 [double useless] and 33 [half useless]= .)

--
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -
Edward Lewis
NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice messag= e at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?

--0016e6de0444c49e6f04a4a4bc60-- From Ed.Lewis@neustar.biz Wed Jun 1 06:01:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D83E09DF for ; Wed, 1 Jun 2011 06:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.435 X-Spam-Level: X-Spam-Status: No, score=-106.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZazKIW4ei7F for ; Wed, 1 Jun 2011 06:01:22 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCF9E0A0E for ; Wed, 1 Jun 2011 05:42:11 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p51Cg7bL050267; Wed, 1 Jun 2011 08:42:08 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.168] by Work-Laptop-2.local (PGP Universal service); Wed, 01 Jun 2011 08:42:09 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 01 Jun 2011 08:42:09 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 1 Jun 2011 08:37:46 -0400 To: "dnsext@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Request for discussion on special dnssec processing policy. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:01:23 -0000 At 22:43 +0000 5/31/11, Roy Arends wrote: >As an example, the CDS draft states that the CDS type MUST be signed by a >DNSKEY with the SEP flag set. Such a requirement is a problem. >RFC 5395 does not address these concerns, hence my request for discussion. How about a section on validator special processing? That is what the above requirement amounts to being. We found that trying to encode and interpret flags indicating roles and/or strength of keys to be problematic when doing the early designs of DNSSEC. The SEP bit was defined with the understanding that it would never influence validation. If this type definition wants to change that, it had better be given a good review. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From ogud@ogud.com Wed Jun 1 07:52:43 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79693E0671 for ; Wed, 1 Jun 2011 07:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U00FKiFKRHZ0 for ; Wed, 1 Jun 2011 07:52:43 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 44680E072D for ; Wed, 1 Jun 2011 07:52:29 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p51EqSuM051108 for ; Wed, 1 Jun 2011 10:52:28 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4DE65225.1060505@ogud.com> Date: Wed, 01 Jun 2011 10:52:21 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] Request for discussion on special dnssec processing policy. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:52:43 -0000 On 01/06/2011 8:37 AM, Edward Lewis wrote: > At 22:43 +0000 5/31/11, Roy Arends wrote: > >> As an example, the CDS draft states that the CDS type MUST be signed by a >> DNSKEY with the SEP flag set. > > Such a requirement is a problem. > >> RFC 5395 does not address these concerns, hence my request for >> discussion. > > How about a section on validator special processing? That is what the > above requirement amounts to being. > > We found that trying to encode and interpret flags indicating roles > and/or strength of keys to be problematic when doing the early designs > of DNSSEC. The SEP bit was defined with the understanding that it would > never influence validation. > > If this type definition wants to change that, it had better be given a > good review. CDS is not a DNS control plane type it is an informational type for Key/Trust-Anchor Management Systems/Components" signaling what a zone wants its TA's to be advertised/used as. The presence of this type MUST NOT affect normal validation at all, thus talking about this in a validation context is a red herring. Normal validator ought to be "blind" to the role of this type. Olafur From Ed.Lewis@neustar.biz Wed Jun 1 08:04:13 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A137E06D9; Wed, 1 Jun 2011 08:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.456 X-Spam-Level: X-Spam-Status: No, score=-106.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3HZ+IsSbfLr; Wed, 1 Jun 2011 08:04:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 68F09E06FC; Wed, 1 Jun 2011 08:04:12 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p51F49BX051218; Wed, 1 Jun 2011 11:04:10 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.168] by Work-Laptop-2.local (PGP Universal service); Wed, 01 Jun 2011 11:04:10 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 01 Jun 2011 11:04:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2011 11:03:57 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: The IESG , ed.lewis@neustar.biz, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:04:13 -0000 At 8:22 -0700 5/26/11, The IESG wrote: >The IESG has received a request from the DNS Extensions WG (dnsext) to >consider the following document: >- 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA > Registry' > as a Proposed Standard As someone that would implement against this document, I find its role confusing. The title is # Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA # Registry Is this title meant to tell me that this is defining or redefining the DNSKEY Algorithm Registry run by IANA? The "Applicability" part is a little confusing. I mention this because of the following text in the Introduction: # This document replaces the original list with a new table that includes the # current compliance status for certain algorithms. # # This compliance status indication is only to be considered for # implementation, not deployment or operations. Operators are free to # deploy any digital signature algorithm available in implementations # or algorithms chosen by local security policies. This status is to # measure compliance to this RFC only. The first sentence seems to be refining the registry. Then there are words saying that this document relates only to code development and not use. The final sentence mentions "compliance to this RFC" and this is where I lose it. I am all for a document to define a registry. And in my experience, a registry is supposed to map objects to entities (in this case DNSKEY algorithms to values in a protocol field) in a fairly neutral way. I am all for a document to define an operational profile, requiring certain choices to be made to be conformant to some standard of service delivery. I would like to be able to advertise that "we conform with RFC wxyz" and have that say we operate with certain algorithms. But I don't think it is correct to do both in the same document. This gets very confusing when trying to deal with RFPs (Request for Propsals and the like) that list RFCs that should be complied with. One issue is the conflict between the neutrality of a registry's function and the advocacy of a profile document. I fail to see the rationale that all implementations must support specific algorithms. (Interoperability doesn't need that.) I understand that if the topic is "general purpose implementations" there are a common set of algorithms such implementations should support. There are, however, turnkey DNS deployments in which these algorithms may not make sense. Any implementation is free to ignore an algorithm or to treat responses as "bad" if it wants to. A strong tenet of the DNSSEC policy is that "local policy" is the trump card in all security decisions. The cache that is being protected gets to choose it's own policy. By creating a registry that commands what is implemented and not implemented, there's a conflict with "local policy". I don't mean that the implementation of the cache is restricted, but the authority and other middle DNS servers are restricted. My recommendation is to turn this document into something called a "Public Internet General Purpose DNSKEY ALgorithm Profile", make it a BCP (that can be updated) and let it summarily list the algorithms that should or shouldn't be included. Leave these designations out of the registry (table) and don't have this document try to change the registry. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From Ed.Lewis@neustar.biz Wed Jun 1 08:08:05 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F6AE0674 for ; Wed, 1 Jun 2011 08:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6R-17ehHFpD for ; Wed, 1 Jun 2011 08:08:05 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id BB196E08C0 for ; Wed, 1 Jun 2011 08:07:27 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p51F7PC5051279; Wed, 1 Jun 2011 11:07:26 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.168] by Work-Laptop-2.local (PGP Universal service); Wed, 01 Jun 2011 11:07:26 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 01 Jun 2011 11:07:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DE65225.1060505@ogud.com> References: <4DE65225.1060505@ogud.com> Date: Wed, 1 Jun 2011 11:07:12 -0400 To: Olafur Gudmundsson From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Request for discussion on special dnssec processing policy. X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:08:05 -0000 At 10:52 -0400 6/1/11, Olafur Gudmundsson wrote: >CDS is not a DNS control plane type it is an informational type for >Key/Trust-Anchor Management Systems/Components" signaling what a zone >wants its TA's to be advertised/used as. > >The presence of this type MUST NOT affect normal validation at all, >thus talking about this in a validation context is a red herring. > >Normal validator ought to be "blind" to the role of this type. Proving Roy's point...need for review/discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From scottr.nist@gmail.com Wed Jun 1 10:18:14 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F53E089F; Wed, 1 Jun 2011 10:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pab5zx+yBw4g; Wed, 1 Jun 2011 10:18:13 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2D1E0824; Wed, 1 Jun 2011 10:18:12 -0700 (PDT) Received: by wyb29 with SMTP id 29so12546wyb.31 for ; Wed, 01 Jun 2011 10:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=deIb7UMYJfsnovlSnRYKrfcK9XuYFZp3t74rd0jmJuE=; b=j9gIatn7k9bl3qncQ/KqbiLgDt7UCGJEi1r5jBLdRaSESgo5RWAVVl3ki7P0Jk2PpV CLMd5zrUXroOKozb1P06YdXOc6ELxg/h0P52ASWaEh7cisLPpsJoGZ77XyGTrOGpOws/ Inv+2IrDYBQEvRYjLe813JsgTCFrrTFkf1Xmg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=wyFu9JtIUq9McZr5bFHrxBP4Y9fqK7WiRYzeLq4fUt7BBD8Qg0cz3dKItMUKY8uOYA QcqBFkJmCA0NS1v8RBVeNngX3Wq3hpIsLQLnd0VAxqEex8Bf6abE+Ssyx1V07YBQthjt SEgJ5bbyffIEj2zInaQIY5eq7RLdQtKje0lGY= MIME-Version: 1.0 Received: by 10.216.145.206 with SMTP id p56mr5040350wej.80.1306948691337; Wed, 01 Jun 2011 10:18:11 -0700 (PDT) Received: by 10.216.87.21 with HTTP; Wed, 1 Jun 2011 10:18:11 -0700 (PDT) In-Reply-To: References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2011 13:18:11 -0400 Message-ID: From: Scott Rose To: Edward Lewis Content-Type: multipart/alternative; boundary=0016e6de04447ca19704a4a9b4a2 Cc: The IESG , ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:18:14 -0000 --0016e6de04447ca19704a4a9b4a2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 1, 2011 at 11:03 AM, Edward Lewis wrote: > At 8:22 -0700 5/26/11, The IESG wrote: > >> The IESG has received a request from the DNS Extensions WG (dnsext) to >> consider the following document: >> - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA >> Registry' >> as a Proposed Standard >> > > As someone that would implement against this document, I find its role > confusing. > > The title is > # Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA > # Registry > > Is this title meant to tell me that this is defining or redefining the > DNSKEY Algorithm Registry run by IANA? The "Applicability" part is a little > confusing. > Technically redefining if you want to split hairs. > > I mention this because of the following text in the Introduction: > > # This document replaces the original list with a new table that includes > the > # current compliance status for certain algorithms. > # > # This compliance status indication is only to be considered for > # implementation, not deployment or operations. Operators are free to > # deploy any digital signature algorithm available in implementations > # or algorithms chosen by local security policies. This status is to > > # measure compliance to this RFC only. > > The first sentence seems to be refining the registry. Then there are words > saying that this document relates only to code development and not use. The > final sentence mentions "compliance to this RFC" and this is where I lose > it. > > I am all for a document to define a registry. And in my experience, a > registry is supposed to map objects to entities (in this case DNSKEY > algorithms to values in a protocol field) in a fairly neutral way. > > I am all for a document to define an operational profile, requiring certain > choices to be made to be conformant to some standard of service delivery. I > would like to be able to advertise that "we conform with RFC wxyz" and have > that say we operate with certain algorithms. > > But I don't think it is correct to do both in the same document. This gets > very confusing when trying to deal with RFPs (Request for Propsals and the > like) that list RFCs that should be complied with. One issue is the conflict > between the neutrality of a registry's function and the advocacy of a > profile document. > > I fail to see the rationale that all implementations must support specific > algorithms. (Interoperability doesn't need that.) I understand that if the > topic is "general purpose implementations" there are a common set of > algorithms such implementations should support. There are, however, turnkey > DNS deployments in which these algorithms may not make sense. Any > implementation is free to ignore an algorithm or to treat responses as "bad" > if it wants to. > > This doc doesn't change that at all. You can still implement whatever you want, just not claim conformance to this doc. > A strong tenet of the DNSSEC policy is that "local policy" is the trump > card in all security decisions. The cache that is being protected gets to > choose it's own policy. By creating a registry that commands what is > implemented and not implemented, there's a conflict with "local policy". I > don't mean that the implementation of the cache is restricted, but the > authority and other middle DNS servers are restricted. > > Local policy is already restricted by implementations. This doc really doesn't change that - it only really reflects the current state of crypto in DNSSEC. Something that has been more oral history than written down. > My recommendation is to turn this document into something called a "Public > Internet General Purpose DNSKEY ALgorithm Profile", make it a BCP (that can > be updated) and let it summarily list the algorithms that should or > shouldn't be included. Leave these designations out of the registry (table) > and don't have this document try to change the registry. > > Our main reason for replacing the registry table with a doc containing a new table was that not all implementors may be good at sorting through the IETF archives looking for every DNSSEC related RFC and BCP. Have a simple table at a well known repository will hopefully reduce that document hunt. Scott > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NeuStar You can leave a voice > message at +1-571-434-5468 > > Now, don't say I'm always complaining. > Wait, that's a complaint, isn't it? > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --0016e6de04447ca19704a4a9b4a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 1, 2011 at 11:03 AM, Edward = Lewis <Ed.Lewi= s@neustar.biz> wrote:
At 8:22 -0700 5/26/11, The IESG wrote:
The IESG has received a request from the DNS Extensions WG (dnsext) to
consider the following document:
- 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA=
=A0 Registry'
=A0<draft-ietf-dnsext-dnssec-registry-fixes-08.txt> as a Proposed St= andard

As someone that would implement against this document, I find its role conf= using.

The title is
# =A0 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA<= br> # =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Registry
Is this title meant to tell me that this is defining or redefining the DNSK= EY Algorithm Registry run by IANA? =A0The "Applicability" part is= a little confusing.

Technically redefi= ning if you want to split hairs.
=A0

I mention this because of the following text in the Introduction:

# This document replaces the original list with a new table that includes t= he
# current compliance status for certain algorithms.
#
# This compliance status indication is only to be considered for
# implementation, not deployment or operations. =A0Operators are free to # deploy any digital signature algorithm available in implementations
# or algorithms chosen by local security policies. =A0This status is to
# measure compliance to this RFC only.

The first sentence seems to be refining the registry. =A0Then there are wor= ds saying that this document relates only to code development and not use. = =A0The final sentence mentions "compliance to this RFC" and this = is where I lose it.

I am all for a document to define a registry. =A0And in my experience, a re= gistry is supposed to map objects to entities (in this case DNSKEY algorith= ms to values in a protocol field) in a fairly neutral way.

I am all for a document to define an operational profile, requiring certain= choices to be made to be conformant to some standard of service delivery. = =A0I would like to be able to advertise that "we conform with RFC wxyz= " and have that say we operate with certain algorithms.

But I don't think it is correct to do both in the same document. This g= ets very confusing when trying to deal with RFPs (Request for Propsals and = the like) that list RFCs that should be complied with. One issue is the con= flict between the neutrality of a registry's function and the advocacy = of a profile document.

I fail to see the rationale that all implementations must support specific = algorithms. =A0(Interoperability doesn't need that.) =A0I understand th= at if the topic is "general purpose implementations" there are a = common set of algorithms such implementations should support. =A0There are,= however, turnkey DNS deployments in which these algorithms may not make se= nse. =A0Any implementation is free to ignore an algorithm or to treat respo= nses as "bad" if it wants to.

This doc doesn't change that at all. =A0You can s= till implement whatever you want, just not claim conformance to this doc. = =A0
=A0
A strong tenet of the DNSSEC policy is that "local policy" is the= trump card in all security decisions. =A0The cache that is being protected= gets to choose it's own policy. =A0By creating a registry that command= s what is implemented and not implemented, there's a conflict with &quo= t;local policy". =A0I don't mean that the implementation of the ca= che is restricted, but the authority and other middle DNS servers are restr= icted.

Local policy is already restricted by implementations= . =A0This doc really doesn't change that - it only really reflects the = current state of crypto in DNSSEC. =A0Something that has been more oral his= tory than written down. =A0 =A0

=A0
My recommendation is to turn this document into something called a "Pu= blic Internet General Purpose DNSKEY ALgorithm Profile", make it a BCP= (that can be updated) and let it summarily list the algorithms that should= or shouldn't be included. =A0Leave these designations out of the regis= try (table) and don't have this document try to change the registry.

Our main reason for replacing t= he registry table with a doc containing a new table was that not all implem= entors may be good at sorting through the IETF archives looking for every D= NSSEC related RFC and BCP. =A0Have a simple table at a well known repositor= y will hopefully reduce that document hunt.


Scott

=A0
=
--
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -
Edward Lewis =A0 =A0 =A0 =A0 =A0 =A0 NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?

_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext

--0016e6de04447ca19704a4a9b4a2-- From ajs@anvilwalrusden.com Wed Jun 1 10:52:44 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58D5E078F; Wed, 1 Jun 2011 10:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfZfUEcQLcaC; Wed, 1 Jun 2011 10:52:43 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 09733E0860; Wed, 1 Jun 2011 10:52:19 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 520561ECB422; Wed, 1 Jun 2011 17:52:18 +0000 (UTC) Date: Wed, 1 Jun 2011 13:52:17 -0400 From: Andrew Sullivan To: ietf@ietf.org, dnsext@ietf.org Message-ID: <20110601175216.GX26780@shinkuro.com> References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 17:52:44 -0000 On Wed, Jun 01, 2011 at 01:18:11PM -0400, Scott Rose wrote: > > The title is > > # Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA > > # Registry > > > > Is this title meant to tell me that this is defining or redefining the > > DNSKEY Algorithm Registry run by IANA? The "Applicability" part is a little > > confusing. > > > > Technically redefining if you want to split hairs. We could remove the "Applicability Statement" in the title, if that would help. Ed? > Our main reason for replacing the registry table with a doc containing a new > table was that not all implementors may be good at sorting through the IETF > archives looking for every DNSSEC related RFC and BCP. Have a simple table > at a well known repository will hopefully reduce that document hunt. I think this is the key point, and I want to make it more strongly than Scott does: we already tried that. We have some documents that say which algorithms are mandatory to implement. Other RFCs have defined algorithms but were silent on whether something needed to be implemented -- quite correctly, since it is meaningless for a document to define what MUST be done for anything other than conformance with it. Finally, the DNS world has a long history of requirements littered throughout various RFCs, but without a codex that would allow you to find all the RFCs you need to read to understand what you ought to do for your particular implementation. We received feedback at a meeting (in Maastricht, I think, and from Steve Kent, I think) that the DNSEXT WG should pick some algorithms and make it clear that those are the ones everyone ought to be able to use, if they want to be interoperable with everyone else. We were also advised to make clear the one(s) we believe to be "up next", on the grounds that implementers and deployers can be ready. So, the goal here is threefold: (1) to collect all those MUSTs and MUST NOTs into one RFC: anything not defined in that RFC as required is completely optional; (2) to provide a single place where implementers can find out where that advice is located; (3) to make sure that we don't somehow end up with conflicting advice. The list of requirements in this draft satisfies (1). One conforms to an RFC, and if it is published as an RFC then this document is the one to which one should refer in RFPs and so on, assuming one wants this sort of general-purpose conformance. (If you only wanted GOST, for instance, you wouldn't require conformance to this document. That's just a different decision.) Now, of course, (2) could be solved in more than one way. We could put up http://tools.ietf.org/wg/dnsext/guide-to-the-perplexed and include a link to this document (if it becomes an RFC). But that would not solve (3). (3) is the real reason to use the registry for this. Registries are not just there to have a single convenient place to look everything up. They also exist because they prevent collisions and so on. Only one entry can be in the registry for code point _n_. The "conformance to RFC TBD1" column is yet anothe such condition: only RFC TBD1 is allowed to add things to that column. So if anything comes along and tries to add things to that column, we know we have a failure, and the registry entry doesn't get created until the problem is solved. In this way, the draft is using the registry exactly as it was intended: it is a control point that makes sure a given assignment happens in a co-ordinated way. In this case, the assignment is "DNS community current best advice about what will be maximally interoperable." It's not a blessing; it's just another entry that ensures co-ordination on the Internet in a way that ensures interoperability is maximized. Best, A (document shepherd) -- Andrew Sullivan ajs@anvilwalrusden.com From ogud@ogud.com Wed Jun 1 11:38:08 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B84130055 for ; Wed, 1 Jun 2011 11:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8AUHU5noChR for ; Wed, 1 Jun 2011 11:38:08 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id D578D130052 for ; Wed, 1 Jun 2011 11:38:05 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p51Ic4nn052757; Wed, 1 Jun 2011 14:38:04 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4DE68705.9050806@ogud.com> Date: Wed, 01 Jun 2011 14:37:57 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Edward Lewis References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 18:38:08 -0000 On 01/06/2011 11:03 AM, Edward Lewis wrote: > At 8:22 -0700 5/26/11, The IESG wrote: >> The IESG has received a request from the DNS Extensions WG (dnsext) to >> consider the following document: >> - 'Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA >> Registry' >> as a Proposed Standard > > As someone that would implement against this document, I find its role > confusing. > > The title is > # Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA > # Registry > > Is this title meant to tell me that this is defining or redefining the > DNSKEY Algorithm Registry run by IANA? The "Applicability" part is a > little confusing. > See: RFC2026/BCP9 section 3.2 Applicability Statement (AS) Olafur From Ed.Lewis@neustar.biz Wed Jun 1 12:28:56 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFA0130052; Wed, 1 Jun 2011 12:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.495 X-Spam-Level: X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUgGZg2Qcub8; Wed, 1 Jun 2011 12:28:55 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 86DF9E0833; Wed, 1 Jun 2011 12:28:53 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p51JSoTU053111; Wed, 1 Jun 2011 15:28:50 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.168] by Work-Laptop-2.local (PGP Universal service); Wed, 01 Jun 2011 15:28:52 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 01 Jun 2011 15:28:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> Date: Wed, 1 Jun 2011 15:28:46 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org, Edward Lewis , ietf@ietf.org, The IESG Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 19:28:56 -0000 At 13:18 -0400 6/1/11, Scott Rose wrote: >This doc doesn't change that at all. You can still implement whatever >you want, just not claim conformance to this doc. If that's the case, then there should be no IANA changes from this document. >Our main reason for replacing the registry table with a doc containing a >new table was that not all implementors may be good at sorting through >the IETF archives looking for every DNSSEC related RFC and BCP. Have a >simple table at a well known repository will hopefully reduce that >document hunt. I think there's a misunderstanding about the role of a registry table and a profile when it comes to conformance. E.g., look at the DNS registry of RR type codes. Implementations would support a type by using the directions in the documents indicated in the last column. This does not indicate whether the type is a good idea to support or not, just indicates the definition. There is no list of types that "are actually in use." That would be nice to have. If this document is trying to fill that role, then fine, but don't change the underlying registry table. As far as "Applicability Statement" in the title, which Olafur notes is defined in RFC 2026 (an unreferenced document, need to add that then), then make this document an applicability statement and not a change to a registry. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From Ed.Lewis@neustar.biz Wed Jun 1 12:45:56 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC43C130070; Wed, 1 Jun 2011 12:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy4oHCULL-aE; Wed, 1 Jun 2011 12:45:56 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 317A7130048; Wed, 1 Jun 2011 12:45:56 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p51Jjokm053229; Wed, 1 Jun 2011 15:45:51 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.168] by Work-Laptop-2.local (PGP Universal service); Wed, 01 Jun 2011 15:45:52 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 01 Jun 2011 15:45:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110601175216.GX26780@shinkuro.com> References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> <20110601175216.GX26780@shinkuro.com> Date: Wed, 1 Jun 2011 15:45:48 -0400 To: Andrew Sullivan From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 19:45:57 -0000 At 13:52 -0400 6/1/11, Andrew Sullivan wrote: >We could remove the "Applicability Statement" in the title, if that would >help. Ed? I think the issue is where to put what conventional wisdom considers the current algorithms to use. No matter how much I think about it, I think putting this in a registry is a mistake. The problem is that a registry is a current state of affairs. It is not versionable. I don't say my implementation is compliant with the IANA registry of 1999. If I did, there's no way to check that. However, I can say my implementation is compliant (as in built to the contents of) RFC 2065. 'Course, RFC 2065 is obsolete, but my code may not have been changed. If I re-implement to meet RFC 2535 and then later to RFC 4033-4035, you can verify this via the history of documents. The types in the IANA registry show the current definitions, but the RFCs keep the history. >We received feedback at a meeting (in Maastricht, I think, and from >Steve Kent, I think) that the DNSEXT WG should pick some algorithms >and make it clear that those are the ones everyone ought to be able to >use, if they want to be interoperable with everyone else. We were >also advised to make clear the one(s) we believe to be "up next", on >the grounds that implementers and deployers can be ready. Then just issue a document called "DNSEXT's Preferred Algorithms 2011" and make it an RFC. This way, in 10 years, we can sit back and laugh at what was fashionable back in the day. >So, the goal here is threefold: (1) to collect all those MUSTs and >MUST NOTs into one RFC: anything not defined in that RFC as required >is completely optional; (2) to provide a single place where >implementers can find out where that advice is located; (3) to make >sure that we don't somehow end up with conflicting advice. That would be nice, I just think a registry is the wrong place to put that - because registries change and old (deployed) implementations don't. >In this way, the draft is using the registry exactly as it was >intended: it is a control point that makes sure a given assignment >happens in a co-ordinated way. In this case, the assignment is "DNS >community current best advice about what will be maximally >interoperable." It's not a blessing; it's just another entry that >ensures co-ordination on the Internet in a way that ensures >interoperability is maximized. But the "current best advice" changes. And old versions of software don't. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From ajs@anvilwalrusden.com Wed Jun 1 13:34:27 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDD1E0976; Wed, 1 Jun 2011 13:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojG5hfZgGvuX; Wed, 1 Jun 2011 13:34:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B0CD2E0977; Wed, 1 Jun 2011 13:33:58 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C241A1ECB422; Wed, 1 Jun 2011 20:33:56 +0000 (UTC) Date: Wed, 1 Jun 2011 16:33:55 -0400 From: Andrew Sullivan To: ietf@ietf.org, dnsext@ietf.org Message-ID: <20110601203355.GB26780@shinkuro.com> References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> <20110601175216.GX26780@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:34:27 -0000 On Wed, Jun 01, 2011 at 03:45:48PM -0400, Edward Lewis wrote: > >So, the goal here is threefold: (1) to collect all those MUSTs and > >MUST NOTs into one RFC: anything not defined in that RFC as required > >is completely optional; (2) to provide a single place where > >implementers can find out where that advice is located; (3) to make > >sure that we don't somehow end up with conflicting advice. > > That would be nice, I just think a registry is the wrong place to > put that - because registries change and old (deployed) > implementations don't. > >In this way, the draft is using the registry exactly as it was > >intended: it is a control point that makes sure a given assignment > >happens in a co-ordinated way. In this case, the assignment is "DNS > >community current best advice about what will be maximally > >interoperable." It's not a blessing; it's just another entry that > >ensures co-ordination on the Internet in a way that ensures > >interoperability is maximized. > > But the "current best advice" changes. And old versions of software don't. Right. And the RFC to which those old versions of software conforms doesn't change either. You cannot claim conformance to the registry, because registries are not an archival series and because they do change. We agree on that. But you don't seem to think that the registry of RRTYPE code points changing is a bad idea, even though early software didn't have the RRTYPE for DNAME or DNSKEY. In the same way, the registry of these algorithm types might change, and it wouldn't matter. But nobody is allowed to put _anything_ into that "Compliance to RFC TBD1" column. If the WG wants in future to make some shiny new algorithm "RECOMMENDED TO IMPLEMENT" according to the latest guidance, and wants that to be reflected in a registry somewhere, then the answer is to write a new document that obsoletes the draft we're talking about, and completely replace the typecode registry again, with the new values (presumably, a new column, called "Compliance to RFC TBD2", and dropping the analagous column from the current version). I believe that nothing anywhere in the document suggests that one ought to guage conformance of software against the registry, and if you think it says that somewhere, I'd like a pointer to where. It would need to be fixed if it said that, but as far as I can tell it does not. A -- Andrew Sullivan ajs@anvilwalrusden.com From Ed.Lewis@neustar.biz Thu Jun 2 05:53:03 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5686EE0915; Thu, 2 Jun 2011 05:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnBJjCF+EC9a; Thu, 2 Jun 2011 05:53:02 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 50C44E09B8; Thu, 2 Jun 2011 05:52:59 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p52CqtQ6059180; Thu, 2 Jun 2011 08:52:56 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.168] by Work-Laptop-2.local (PGP Universal service); Thu, 02 Jun 2011 08:52:56 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 02 Jun 2011 08:52:56 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110601203355.GB26780@shinkuro.com> References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> <20110601175216.GX26780@shinkuro.com> <20110601203355.GB26780@shinkuro.com> Date: Thu, 2 Jun 2011 08:51:48 -0400 To: Andrew Sullivan From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 12:53:03 -0000 At 16:33 -0400 6/1/11, Andrew Sullivan wrote: >I believe that nothing anywhere in the document suggests that one >ought to guage conformance of software against the registry, and if >you think it says that somewhere, I'd like a pointer to where. It >would need to be fixed if it said that, but as far as I can tell it >does not. I believe the opposite. From the abstract: This status is to measure compliance to this RFC only. This document replaces that registry table with a new IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers that lists (or assigns) each algorithm's status based on the current reference. Seeing these two sentences alone tells me that this document is setting up a registry and is setting up something to be compliant to the registry. Bolstering my confusion is comments from the editor/Scott in a recent message (granted this is not in the draft): "This doc doesn't change that at all. You can still implement whatever you want, just not claim conformance to this doc." Is the document an applicability statement to which software can conform, or is it a definition of a registry? Jumping backwards in your message: >You cannot claim conformance to the registry, because registries are >not an archival series and because they do change. We agree on that. >But you don't seem to think that the registry of RRTYPE code points >changing is a bad idea, even though early software didn't have the >RRTYPE for DNAME or DNSKEY. In the same way, the registry of these Why did you use the word "but" in there? I can't make sense out of that paragraph, especially the second sentence. Change happens, and the registry has to keep up to be relevant. A software version is written to a static set of requirements (like an RFC). Software (referring to the process of producing a series of versions) can be said to be compliant to a registry in the sense that the latest version reflects what is in a registry. That might give a hint of why I find this draft's mission confusing. And why I really think it is a bad idea to codify recommendations to implement in a registry, which is what I read in this document. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From ajs@anvilwalrusden.com Thu Jun 2 09:52:48 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8BFE0820 for ; Thu, 2 Jun 2011 09:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuGexQ0V3Z-5 for ; Thu, 2 Jun 2011 09:52:48 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3C8E07FC for ; Thu, 2 Jun 2011 09:52:47 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 935351ECB422 for ; Thu, 2 Jun 2011 16:52:46 +0000 (UTC) Date: Thu, 2 Jun 2011 12:52:45 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110602165245.GJ26780@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] No meeting planned for IETF 81 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:52:48 -0000 Dear colleagues, We have not received any requests for meeting time in Quebec, and there has not been, on the list, discussion of the sort that leads us to believe there are things to resolve in a face to face session. Therefore, we do not plan to request a meeting slot in Quebec. If you think this to be in error, please raise it with us immediately. Our ADs require an agenda to give us a meeting slot, so you must raise any issue in time for us to prepare an agenda. Best regards, Andrew and Olafur -- Andrew Sullivan ajs@anvilwalrusden.com From dougb@dougbarton.us Thu Jun 2 10:08:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5135E07DA for ; Thu, 2 Jun 2011 10:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.779 X-Spam-Level: X-Spam-Status: No, score=-3.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCnDvJu3E-Hh for ; Thu, 2 Jun 2011 10:08:23 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2888CE0692 for ; Thu, 2 Jun 2011 10:08:22 -0700 (PDT) Received: (qmail 4304 invoked by uid 399); 2 Jun 2011 17:08:15 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 2 Jun 2011 17:08:15 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DE7C37B.4020202@dougbarton.us> Date: Thu, 02 Jun 2011 10:08:11 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Andrew Sullivan References: <20110602165245.GJ26780@shinkuro.com> In-Reply-To: <20110602165245.GJ26780@shinkuro.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: [dnsext] CLONE (Was: Re: No meeting planned for IETF 81) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:08:24 -0000 On 06/02/2011 09:52, Andrew Sullivan wrote: > Dear colleagues, > > We have not received any requests for meeting time in Quebec, and > there has not been, on the list, discussion of the sort that leads us > to believe there are things to resolve in a face to face session. > Therefore, we do not plan to request a meeting slot in Quebec. > > If you think this to be in error, please raise it with us immediately. > Our ADs require an agenda to give us a meeting slot, so you must raise > any issue in time for us to prepare an agenda. I am still holding out hope that there will be interest in my draft, http://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit. I'm told that due to the title some people have assumed that it's a joke, but I assure you that it's intended as a serious offering. I will not be able to attend the meeting in person, but I would be happy to prepare a presentation if there is interest, and could do a phone-in if that were possible/desirable. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From ajs@anvilwalrusden.com Thu Jun 2 10:46:10 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909FDE06FB for ; Thu, 2 Jun 2011 10:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8X6kIPH+xIZ for ; Thu, 2 Jun 2011 10:46:10 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 17D92E0693 for ; Thu, 2 Jun 2011 10:46:10 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D6C681ECB422 for ; Thu, 2 Jun 2011 17:46:08 +0000 (UTC) Date: Thu, 2 Jun 2011 13:46:07 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110602174607.GL26780@shinkuro.com> References: <20110602165245.GJ26780@shinkuro.com> <4DE7C37B.4020202@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE7C37B.4020202@dougbarton.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] CLONE (Was: Re: No meeting planned for IETF 81) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 17:46:10 -0000 On Thu, Jun 02, 2011 at 10:08:11AM -0700, Doug Barton wrote: > > I am still holding out hope that there will be interest in my draft, > http://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit. Even if there were interest in that draft, it states explicitly that it is aiming at solving the problems outlined in I-D.ietf-dnsext-aliasing-requirements. That draft hasn't been updated since March, and our plan was not to start work on particular solutions to the problems before we came to consensus on the requirements. My impression from Prague was that there was another round of comments, at least, to be folded into the requirements document, so we're not in a position to talk about some way of implementing it yet. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From scottr.nist@gmail.com Thu Jun 2 11:10:32 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD76E0709; Thu, 2 Jun 2011 11:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvQxlpkTNBtx; Thu, 2 Jun 2011 11:10:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70FF6E0819; Thu, 2 Jun 2011 11:10:30 -0700 (PDT) Received: by wyb29 with SMTP id 29so951087wyb.31 for ; Thu, 02 Jun 2011 11:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=VQGQXpyoJJX9eCoUTg5emD/ist+GnP+SJqXtRjywuiI=; b=HVfohr4/HoUc4VuZET83sZlZ+taPd8F7aL2CBjp3hCmwzaH26mNqSbZ8tORS/2NmfX 8KR6JzaBD1Ac5AwdTWfTQ0mDgdLkmyshsONAzbnsfMAuEHQjGgyk6PWjWbyiz1Am0ln8 +NGhBX7JZRLU2QFjFuYU3quDttrG3myJevXuk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=hTrd80cfvrPwwvhbdkPuUwdORaW8ZIpxka/wpM4FQIFKf8ZAXSnrF+LDRZSshq97Pq QS00JRvnBUZ5NkuWnRpr64GBTJM85o+i4RX0IflU3umMp96Rj8PKJAEU7ncRF4+qAZ9Y FTVYTVOcmjhqftWF/AF2EkSuIpWiYZp25jp7A= MIME-Version: 1.0 Received: by 10.216.201.163 with SMTP id b35mr980035weo.80.1307038229487; Thu, 02 Jun 2011 11:10:29 -0700 (PDT) Received: by 10.216.87.21 with HTTP; Thu, 2 Jun 2011 11:10:29 -0700 (PDT) In-Reply-To: References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> <20110601175216.GX26780@shinkuro.com> <20110601203355.GB26780@shinkuro.com> Date: Thu, 2 Jun 2011 14:10:29 -0400 Message-ID: From: Scott Rose To: ietf@ietf.org, dnsext@ietf.org Content-Type: multipart/alternative; boundary=0016e6db2a8f6061f604a4be8dac Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:10:32 -0000 --0016e6db2a8f6061f604a4be8dac Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 2, 2011 at 8:51 AM, Edward Lewis wrote: > At 16:33 -0400 6/1/11, Andrew Sullivan wrote: > > I believe that nothing anywhere in the document suggests that one >> ought to guage conformance of software against the registry, and if >> you think it says that somewhere, I'd like a pointer to where. It >> would need to be fixed if it said that, but as far as I can tell it >> does not. >> > > I believe the opposite. > Then perhaps a wording change? It seems that it is confusion over the language rather than the purpose. Scott --0016e6db2a8f6061f604a4be8dac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 2, 2011 at 8:51 AM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:=
At 16:33 -0400 6/1/11, Andrew Sullivan wrote:

I believe that nothing anywhere in the document suggests that one
ought to guage conformance of software against the registry, and if
you think it says that somewhere, I'd like a pointer to where. =A0It would need to be fixed if it said that, but as far as I can tell it
does not.

I believe the opposite.

Then perhaps a = wording change? =A0It seems that it is confusion over the language rather t= han the purpose.


=A0Scott


--0016e6db2a8f6061f604a4be8dac-- From Ed.Lewis@neustar.biz Thu Jun 2 11:34:39 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3577FE07E6; Thu, 2 Jun 2011 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7rzOP6OZCoc; Thu, 2 Jun 2011 11:34:38 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id E5146E06FB; Thu, 2 Jun 2011 11:34:37 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p52IYWf3061792; Thu, 2 Jun 2011 14:34:32 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.168] by Work-Laptop-2.local (PGP Universal service); Thu, 02 Jun 2011 14:34:33 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 02 Jun 2011 14:34:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110526152257.21795.30012.idtracker@ietfa.amsl.com> <20110601175216.GX26780@shinkuro.com> <20110601203355.GB26780@shinkuro.com> Date: Thu, 2 Jun 2011 14:31:55 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz, ietf@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 18:34:39 -0000 At 14:10 -0400 6/2/11, Scott Rose wrote: >Then perhaps a wording change? It seems that it is confusion over the >language rather than the purpose. A wording change is probably needed, but I can't suggest one because I can't determine what the goal is from what's currently written. I know that sounds like a cheap shot, but I'm definitely not getting something here. E.g., I'm assuming the document is suggesting that the IANA registry have the new column and that is my main complaint. (That it shouldn't.) If the matrix with the compliance column only appears in the document, while the IANA registry omits the column, I have no complaint. Perhaps IANA lists the document as a reference at the end of the matrix, but the registry contents itself doesn't hold "recommendations." Does that make sense? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From wwwrun@rfc-editor.org Mon Jun 6 05:52:07 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F63F11E813D for ; Mon, 6 Jun 2011 05:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6p4MJpw7-j+G for ; Mon, 6 Jun 2011 05:52:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id B4FF511E813F for ; Mon, 6 Jun 2011 05:52:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 62D2E98C4F7; Mon, 6 Jun 2011 05:52:06 -0700 (PDT) To: roy.arends@telin.nl, sra@isc.org, mlarson@verisign.com, massey@cs.colostate.edu, scott.rose@nist.gov, rdroms.ietf@gmail.com, jari.arkko@piuha.net, ogud@ogud.com, ajs@anvilwalrusden.com From: RFC Errata System Message-Id: <20110606125206.62D2E98C4F7@rfc-editor.org> Date: Mon, 6 Jun 2011 05:52:06 -0700 (PDT) X-Mailman-Approved-At: Mon, 06 Jun 2011 08:14:48 -0700 Cc: ed.lewis@neustar.biz, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Editorial Errata Reported] RFC4034 (2824) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 12:52:07 -0000 The following errata report has been submitted for RFC4034, "Resource Records for the DNS Security Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4034&eid=2824 -------------------------------------- Type: Editorial Reported by: Edward Lewis Section: 3.1.3 Original Text ------------- The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the wildcard label (if present). Corrected Text -------------- The value of the Labels field MUST NOT count either the null (root) label that terminates the owner name or the leftmost label if it is a wildcard. Notes ----- In RFC 4035, section 2.2, describing the same count uses this: ... "and not counting the leftmost label if it is a wildcard" to omit the leading wildcard label. (In 4034, the wildcard label is defined as "*" earlier in the same problematic section.) The text in 4034 could be confused with having to count "wildcard labels" in the middle of a name, such as in name.*.tld. The reason for suggesting this errata is for compliance considerations. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4034 (draft-ietf-dnsext-dnssec-records-11) -------------------------------------- Title : Resource Records for the DNS Security Extensions Publication Date : March 2005 Author(s) : R. Arends, R. Austein, M. Larson, D. Massey, S. Rose Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From Ed.Lewis@neustar.biz Mon Jun 6 13:12:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBC411E8182 for ; Mon, 6 Jun 2011 13:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIK8p7s7rqCt for ; Mon, 6 Jun 2011 13:12:06 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id B69FA11E816B for ; Mon, 6 Jun 2011 13:12:05 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p56KBwnd007058; Mon, 6 Jun 2011 16:11:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.203] by Work-Laptop-2.local (PGP Universal service); Mon, 06 Jun 2011 16:11:59 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 06 Jun 2011 16:11:59 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> Date: Mon, 6 Jun 2011 16:11:55 -0400 To: Edward Lewis From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz, dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 20:12:06 -0000 At 16:16 -0400 5/25/11, Edward Lewis wrote: Since someone misread this, I'll add for clarification: >This is incorrect in 3.4.1: > ># A validating recursive resolver MUST set the DO bit [RFC4035] to ># indicate that it wishes to receive DNSSEC RRs in the response. If > >Try this, as an example: "$ dig @a.dns.jp jp dnskey" > >(No EDNS0, no DO, but I get DNSKEY records back.) What's incorrect (in my opinion) is the use of "MUST" in the quoted text. As in, referring to the example dig, I don't "MUST set the DO bit" to see DNSKEY records. I can indicate I want to see DNSSEC-related records merely by asking for them specifically or via QTYPE=ANY. I'm quibbling over the wording, yes. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From brian.peter.dickson@gmail.com Mon Jun 6 13:47:29 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8BC21F849D for ; Mon, 6 Jun 2011 13:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-FEXgAdGyNF for ; Mon, 6 Jun 2011 13:47:29 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFD821F849C for ; Mon, 6 Jun 2011 13:47:28 -0700 (PDT) Received: by fxm15 with SMTP id 15so3109666fxm.31 for ; Mon, 06 Jun 2011 13:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M0gHV5g7Mpd3kwYPlDWCe9gioZkLuCpOu7bjvtYyxf4=; b=AYoLkXowj28q2inrfRUXmfJEa9iByIYKna0YE6dVJ0CQcuALNXIkemmDPDs126ZDqd c8Gutn0hEoxNIO5wmyMhB1CSYEhPtMkoUuOwIg4/tDEVa4KfdPfqV/qUZI1CzNUpAwgN kIaJa2VpD4E+Bwz8SR43+A4rWRCEkTYcgSA08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PyqktNYavtHWWYdQQLhXsKu5JnsfnBLYI0aVSQxajg6VzyvjMTBWg2J4Uoxf/Tvmyb ZDLK9Ek0TFb8snTPtK+N+L3o1lQx+In5hBbyYuXCokBNE3pmUHvxqqV7qRQz2fcIgI6o inOQx5oVboqIwBocNhLyzDROTnFoMyX7l+qz0= MIME-Version: 1.0 Received: by 10.223.38.149 with SMTP id b21mr215424fae.18.1307393246097; Mon, 06 Jun 2011 13:47:26 -0700 (PDT) Received: by 10.223.115.84 with HTTP; Mon, 6 Jun 2011 13:47:26 -0700 (PDT) In-Reply-To: References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> Date: Mon, 6 Jun 2011 16:47:26 -0400 Message-ID: From: Brian Dickson To: Edward Lewis Content-Type: multipart/alternative; boundary=00151747358603f07204a51136f7 Cc: dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 20:47:29 -0000 --00151747358603f07204a51136f7 Content-Type: text/plain; charset=ISO-8859-1 Suggested replacement text: Change from: wishes to receive DNSSEC RRs in the response to: wishes to have DNSSEC RRs added to the response, where appropriate. Brian On Mon, Jun 6, 2011 at 4:11 PM, Edward Lewis wrote: > At 16:16 -0400 5/25/11, Edward Lewis wrote: > > Since someone misread this, I'll add for clarification: > > > This is incorrect in 3.4.1: >> >> # A validating recursive resolver MUST set the DO bit [RFC4035] to >> # indicate that it wishes to receive DNSSEC RRs in the response. If >> >> Try this, as an example: "$ dig @a.dns.jp jp dnskey" >> >> (No EDNS0, no DO, but I get DNSKEY records back.) >> > > What's incorrect (in my opinion) is the use of "MUST" in the quoted text. > As in, referring to the example dig, I don't "MUST set the DO bit" to see > DNSKEY records. I can indicate I want to see DNSSEC-related records merely > by asking for them specifically or via QTYPE=ANY. > > I'm quibbling over the wording, yes. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > Now, don't say I'm always complaining. > Wait, that's a complaint, isn't it? > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --00151747358603f07204a51136f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Suggested replacement text:

Change from:
wishes to receive DNSSEC= RRs in the response
to:
wishes to have DNSSEC RRs added to the respo= nse, where appropriate.

Brian

On M= on, Jun 6, 2011 at 4:11 PM, Edward Lewis <Ed.Lewis@neustar.biz> wrote:
At 16:16 -0400 5/= 25/11, Edward Lewis wrote:

Since someone misread this, I'll add for clarification:


This is incorrect in 3.4.1:

# =A0 A validating recursive resolver MUST set the DO bit [RFC4035] to
# =A0 indicate that it wishes to receive DNSSEC RRs in the response. =A0If<= br>
Try this, as an example: =A0"$ dig @a.dns.jp jp dnskey"

(No EDNS0, no DO, but I get DNSKEY records back.)

What's incorrect (in my opinion) is the use of "MUST" in the = quoted text. =A0As in, referring to the example dig, I don't "MUST= set the DO bit" to see DNSKEY records. =A0I can indicate I want to se= e DNSSEC-related records merely by asking for them specifically or via QTYP= E=3DANY.

I'm quibbling over the wording, yes.
<= br> --
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -
Edward Lewis
NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice messag= e at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?
_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext

--00151747358603f07204a51136f7-- From paul.hoffman@vpnc.org Mon Jun 6 13:50:39 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA8121F8531 for ; Mon, 6 Jun 2011 13:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQavFuS3s7lc for ; Mon, 6 Jun 2011 13:50:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9F221F8530 for ; Mon, 6 Jun 2011 13:50:38 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p56KoXFm023141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jun 2011 13:50:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 6 Jun 2011 13:50:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4288C7A3-BBAC-43FC-BBC9-EC075BB5699C@vpnc.org> References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1084) Cc: Edward Lewis Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 20:50:40 -0000 How about instead "A validating recursive resolver sets the DO bit...", = eliminating the (clearly not correct) "MUST"? --Paul Hoffman From marka@isc.org Mon Jun 6 16:34:26 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68501F0C51 for ; Mon, 6 Jun 2011 16:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNRG5iM+uxER for ; Mon, 6 Jun 2011 16:34:26 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 060641F0C50 for ; Mon, 6 Jun 2011 16:34:26 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id B36D8C94B0; Mon, 6 Jun 2011 23:34:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4F77C216C7A; Mon, 6 Jun 2011 23:33:45 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C102510601C4; Tue, 7 Jun 2011 09:33:39 +1000 (EST) To: Edward Lewis From: Mark Andrews References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> In-reply-to: Your message of "Mon, 06 Jun 2011 16:11:55 -0400." Date: Tue, 07 Jun 2011 09:33:39 +1000 Message-Id: <20110606233339.C102510601C4@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 23:34:27 -0000 In message , Edward Lewis writes: > At 16:16 -0400 5/25/11, Edward Lewis wrote: > > Since someone misread this, I'll add for clarification: > > >This is incorrect in 3.4.1: > > > ># A validating recursive resolver MUST set the DO bit [RFC4035] to > ># indicate that it wishes to receive DNSSEC RRs in the response. If > > > >Try this, as an example: "$ dig @a.dns.jp jp dnskey" > > > >(No EDNS0, no DO, but I get DNSKEY records back.) A validating recursive resolver MUST set the DO bit [RFC4035] to indicate that it is willing to receive DNSSEC RRs associated with the answer that were not directly requested. > What's incorrect (in my opinion) is the use of "MUST" in the quoted > text. As in, referring to the example dig, I don't "MUST set the DO > bit" to see DNSKEY records. I can indicate I want to see > DNSSEC-related records merely by asking for them specifically or via > QTYPE=ANY. > > I'm quibbling over the wording, yes. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Now, don't say I'm always complaining. > Wait, that's a complaint, isn't it? > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From alex@alex.org.uk Mon Jun 6 23:33:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880A521F85BE for ; Mon, 6 Jun 2011 23:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akf6khf9iHKe for ; Mon, 6 Jun 2011 23:33:23 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA9621F85BD for ; Mon, 6 Jun 2011 23:33:22 -0700 (PDT) Received: from [192.168.100.157] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 15EDAC560C8; Tue, 7 Jun 2011 07:33:19 +0100 (BST) Date: Tue, 07 Jun 2011 07:33:18 +0100 From: Alex Bligh To: Edward Lewis Message-ID: <140494A4D8B4D1715F1F0591@nimrod.local> In-Reply-To: References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ed.lewis@neustar.biz, dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 06:33:24 -0000 --On 6 June 2011 16:11:55 -0400 Edward Lewis wrote: >> This is incorrect in 3.4.1: >> >># A validating recursive resolver MUST set the DO bit [RFC4035] to >># indicate that it wishes to receive DNSSEC RRs in the response. If >> >> Try this, as an example: "$ dig @a.dns.jp jp dnskey" >> >> (No EDNS0, no DO, but I get DNSKEY records back.) > > What's incorrect (in my opinion) is the use of "MUST" in the quoted text. > As in, referring to the example dig, I don't "MUST set the DO bit" to see > DNSKEY records. I can indicate I want to see DNSSEC-related records > merely by asking for them specifically or via QTYPE=ANY. If we want to pick nits, there are 2 problems. One, as you've set out, there are other ways to get DNSSEC RRs. More significantly perhaps, this isn't an RFC2119 "MUST" at all. Consider the ambiguous and analagous sentence "You must take 280 to get to SFO quickly". What this probably means is not that you MUST got to SFO quickly, nor MUST go to SFO at all, but that if you want to get to SFO quickly, taking 280 is the way to do it; it is not saying you "MUST" take 280 at all. I think the same applies to the sentence above. I think Paul's fix is right: "A validating recursive resolver sets the DO bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response." -- Alex Bligh From jim@rfc1035.com Tue Jun 7 02:33:51 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AF711E80CA for ; Tue, 7 Jun 2011 02:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9V6B1zDx-1J for ; Tue, 7 Jun 2011 02:33:51 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9C511E80C6 for ; Tue, 7 Jun 2011 02:33:50 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id E406715420A1 for ; Tue, 7 Jun 2011 10:33:41 +0100 (BST) Message-Id: From: Jim Reid To: dnsext@ietf.org In-Reply-To: <140494A4D8B4D1715F1F0591@nimrod.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 7 Jun 2011 10:33:41 +0100 References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> <140494A4D8B4D1715F1F0591@nimrod.local> X-Mailer: Apple Mail (2.936) Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 09:33:51 -0000 On 7 Jun 2011, at 07:33, Alex Bligh wrote: > I think Paul's fix is right: > "A validating recursive resolver sets the DO bit [RFC4035] to > indicate that it wishes to receive DNSSEC RRs in the response." Although this ship has already sailed, the text above could be further improved IMO by inserting "and validate" after "receive". From Ed.Lewis@neustar.biz Tue Jun 7 04:56:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E4611E80DD for ; Tue, 7 Jun 2011 04:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKowMgsQuvMw for ; Tue, 7 Jun 2011 04:56:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4A711E80BF for ; Tue, 7 Jun 2011 04:56:10 -0700 (PDT) Received: from dste-lt500.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p57Bu87o012853; Tue, 7 Jun 2011 07:56:08 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.129.11] by dste-lt500.cis.neustar.com (PGP Universal service); Tue, 07 Jun 2011 07:56:09 -0400 X-PGP-Universal: processed; by dste-lt500.cis.neustar.com on Tue, 07 Jun 2011 07:56:09 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4288C7A3-BBAC-43FC-BBC9-EC075BB5699C@vpnc.org> References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> <4288C7A3-BBAC-43FC-BBC9-EC075BB5699C@vpnc.org> Date: Tue, 7 Jun 2011 07:49:40 -0400 To: DNSEXT Working Group From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 11:56:11 -0000 At 13:50 -0700 6/6/11, Paul Hoffman wrote: >How about instead "A validating recursive resolver sets the DO bit...", >eliminating the (clearly not correct) "MUST"? At 16:47 -0400 6/6/11, Brian Dickson wrote: >Suggested replacement text: > >Change from: >wishes to receive DNSSEC RRs in the response >to: >wishes to have DNSSEC RRs added to the response, where appropriate. At 9:33 +1000 6/7/11, Mark Andrews wrote: >A validating recursive resolver MUST set the DO bit [RFC4035] to >indicate that it is willing to receive DNSSEC RRs associated with >the answer that were not directly requested. At 7:33 +0100 6/7/11, Alex Bligh wrote: >I think Paul's fix is right: >"A validating recursive resolver sets the DO bit [RFC4035] to > indicate that it wishes to receive DNSSEC RRs in the response." Looking at the three suggestions, I agree with the rationale that Alex used. I'm tempted to use more analogies, but he has sufficiently flogged the horse. All three are options (Paul's, Brian's and Mark's) are valid alternatives but Alex is right that the problem here is the use of the RFC 2119 MUST, so I'd lean with Paul's option. (I've had my head up the "compliance" pipe recently. That's where this nit-picking is coming from.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From rjsparks@nostrum.com Tue Jun 7 14:29:01 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9C711E818F; Tue, 7 Jun 2011 14:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1s+BgE47+Zd; Tue, 7 Jun 2011 14:29:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E173211E80C2; Tue, 7 Jun 2011 14:28:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Robert Sparks To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110607212859.3057.86566.idtracker@ietfa.amsl.com> Date: Tue, 07 Jun 2011 14:28:59 -0700 X-Mailman-Approved-At: Tue, 07 Jun 2011 14:32:26 -0700 Cc: dnsext-chairs@tools.ietf.org, dnsext@ietf.org, draft-ietf-dnsext-dnssec-registry-fixes@tools.ietf.org Subject: [dnsext] Robert Sparks' Discuss on draft-ietf-dnsext-dnssec-registry-fixes-08: (with DISCUSS) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:29:01 -0000 Robert Sparks has entered the following ballot position for draft-ietf-dnsext-dnssec-registry-fixes-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Would the following approach achieve the goals the working group desires wi= th this document? Instead of keeping the Compliance information in the IANA registry as a new= column, keep it entirely within this RFC. Add a sentence to the registry t= hat says "See RFCXXXX for the IETF Consensus on which subset of these algor= ithms are required or recommended to implement or avoid." = The RFC could then say that any changes to the RFC affecting that column sh= ould be done through obsoleting the RFC, replacing it with a new one. That= way, you would have a single document to refer to for conformance purposes= , and a clear history of what changes were made. This would avoid Pete's co= ncerns with the potential unintended consequences of the new proposed mecha= nics for maintaining the registry. It would also avoid an issue I have with= the sentence that tries to constrain any updates to this RFC to _only_ use= the obsoletes mechanism. It allows the working group to maintain any chang= es by only using a series of obsoletes, and guides future maintainers shoul= d the working group go away. As long as the consensus was to only use obso= letes, that's exactly what will happen. If IETF consensus changes in the fu= ture, it would override any attempt to constrain the document maintenance a= nyway. If a path like this was considered and rejected, documenting what it wouldn= 't achieve would help motivate the current proposal. From Ed.Lewis@neustar.biz Tue Jun 7 16:33:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBBC11E8120; Tue, 7 Jun 2011 16:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bGCr9Rma4Cy; Tue, 7 Jun 2011 16:33:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id C6C4D11E8071; Tue, 7 Jun 2011 16:33:09 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p57NX4fx017651; Tue, 7 Jun 2011 19:33:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.100] by Work-Laptop-2.local (PGP Universal service); Tue, 07 Jun 2011 19:33:07 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 07 Jun 2011 19:33:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110607212859.3057.86566.idtracker@ietfa.amsl.com> References: <20110607212859.3057.86566.idtracker@ietfa.amsl.com> Date: Tue, 7 Jun 2011 19:33:00 -0400 To: Robert Sparks From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext-chairs@tools.ietf.org, draft-ietf-dnsext-dnssec-registry-fixes@tools.ietf.org, The IESG , dnsext@ietf.org Subject: Re: [dnsext] Robert Sparks' Discuss on draft-ietf-dnsext-dnssec-registry-fixes-08: (with DISCUSS) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 23:33:11 -0000 At 14:28 -0700 6/7/11, Robert Sparks wrote: >Instead of keeping the Compliance information in the IANA registry as a >new column, keep it entirely within this RFC. Add a sentence to the >registry that says "See RFCXXXX for the IETF Consensus on which subset >of these algorithms are required or recommended to implement or avoid." FWIW, this is exactly what I had in mind. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From matt@mattmccutchen.net Tue Jun 7 16:49:33 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551FF21F84F7; Tue, 7 Jun 2011 16:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIT6pKOvLcQe; Tue, 7 Jun 2011 16:49:32 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 742AD21F84F2; Tue, 7 Jun 2011 16:49:32 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 3773734806C; Tue, 7 Jun 2011 16:49:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=fdtWh9REuC6lTf2EsBSM09Qtrc6bpEm9NbtY+iWkXWa zTMJ3mq6kwqIzblbUl5OQdFeMOl0gEuvlj9lfZge/LK1FZXeRQDq1fKqs5xB3cWX 1wYEysEpcPN1iiPSm6DYo/Hjp4I3I7wSsFX0jC2GD226rCCBfEpE3I6je5V97Jr8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=NMQd+BVvtmQReQBeuI3nyq+nVds=; b=Kdv1ehq5Cd EPAaXL5HsE3N7Pj5ks84Gj8dnpBoNpXt9uMCNXmX2lekLsjmL5BB53Bfta/7HuAp O8Skc+uvcgTNuB9ipfpmj9LgG616+LDHn8FSacDTwAv3uewbNXCvD8cuRAWTbKJF be6ZOZa+MdSZgY4yElqRq33w+9vJFYdME= Received: from [192.168.1.40] (pool-74-96-43-195.washdc.east.verizon.net [74.96.43.195]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPSA id 50B8834806B; Tue, 7 Jun 2011 16:49:31 -0700 (PDT) From: Matt McCutchen To: Robert Sparks , The IESG , dnsext@ietf.org, draft-ietf-dnsext-dnssec-registry-fixes@tools.ietf.org, dnsext-chairs@tools.ietf.org In-Reply-To: <20110607212859.3057.86566.idtracker@ietfa.amsl.com> References: <20110607212859.3057.86566.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 07 Jun 2011 19:49:25 -0400 Message-ID: <1307490565.2038.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Robert Sparks' Discuss on draft-ietf-dnsext-dnssec-registry-fixes-08: (with DISCUSS) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 23:49:33 -0000 On Tue, 2011-06-07 at 14:28 -0700, Robert Sparks wrote: > Add a sentence to the registry that says "See RFCXXXX for the IETF > Consensus on which subset of these algorithms are required or > recommended to implement or avoid." I would expect a registry to do what the name says, no more. We have another system whose express purpose is to track the latest RFC on a subject: STD numbers. The registry could just mention the STD number. -- Matt From s.posner@telekom.de Wed Jun 8 04:07:33 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B8011E809D for ; Wed, 8 Jun 2011 04:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9H6h1+tCHPR for ; Wed, 8 Jun 2011 04:07:33 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0082C11E8097 for ; Wed, 8 Jun 2011 04:07:32 -0700 (PDT) Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail71.telekom.de with ESMTP; 08 Jun 2011 13:02:59 +0200 Received: from QEO40065.de.t-online.corp (QEO40065.de.t-online.corp [10.224.209.65]) by G8DBSE01.krf01.telekom.de with ESMTP; Wed, 8 Jun 2011 13:02:58 +0200 Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40065.de.t-online.corp ([::1]) with mapi; Wed, 8 Jun 2011 13:02:58 +0200 From: "Posner, Sebastian" To: Alex Bligh , Edward Lewis Date: Wed, 8 Jun 2011 13:02:57 +0200 Thread-Topic: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal Thread-Index: Acwk3XgZry2aYJj6TG6FlmWlA7hcYAA7VEiw Message-Id: <63366D5A116E514AA4A9872D3C53353956F676BB64@QEO40072.de.t-online.corp> References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> <140494A4D8B4D1715F1F0591@nimrod.local> In-Reply-To: <140494A4D8B4D1715F1F0591@nimrod.local> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 11:07:34 -0000 Alex Bligh wrote: > If we want to pick nits, there are 2 problems. One, as you've set out, > there are other ways to get DNSSEC RRs. More significantly perhaps,=20 > this isn't an RFC2119 "MUST" at all. Consider the ambiguous and=20 > analagous sentence "You must take 280 to get to SFO quickly".=20 > What this probably means is not that you MUST got to SFO quickly,=20 > nor MUST go to SFO at all, but that if you want to get to SFO quickly,=20 > taking 280 is the way to do it; it is not saying you "MUST" take 280=20 > at all. I think the same applies to the sentence above. >=20 > I think Paul's fix is right: > "A validating recursive resolver sets the DO bit [RFC4035] to > indicate that it wishes to receive DNSSEC RRs in the response." Why not rephrase it like you stated in your example: FIRST the=20 condition THEN the measures that must be taken IF the condition is met. "A validating recursive resolver that wishes to receive DNSSEC RRs=20 in the response MUST set the DO bit [RFC4035] (in the question=20 packet to indicate this)." This points out that is is a 2119-MUST, but only if the condition is met. Greets, Sebastian --=20 Sebastian Posner From alex@alex.org.uk Wed Jun 8 04:47:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D15D21F845F for ; Wed, 8 Jun 2011 04:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id licecEgYmwkn for ; Wed, 8 Jun 2011 04:47:10 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by ietfa.amsl.com (Postfix) with ESMTP id B1D4D21F845E for ; Wed, 8 Jun 2011 04:47:10 -0700 (PDT) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 81797C560E6; Wed, 8 Jun 2011 12:47:05 +0100 (BST) Date: Wed, 08 Jun 2011 12:47:04 +0100 From: Alex Bligh To: "Posner, Sebastian" , Edward Lewis Message-ID: In-Reply-To: <63366D5A116E514AA4A9872D3C53353956F676BB64@QEO40072.de.t-online.corp> References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> <140494A4D8B4D1715F1F0591@nimrod.local> <63366D5A116E514AA4A9872D3C53353956F676BB64@QEO40072.de.t-online.corp> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 11:47:11 -0000 --On 8 June 2011 13:02:57 +0200 "Posner, Sebastian" wrote: > Why not rephrase it like you stated in your example: FIRST the > condition THEN the measures that must be taken IF the condition is met. > > "A validating recursive resolver that wishes to receive DNSSEC RRs > in the response MUST set the DO bit [RFC4035] (in the question > packet to indicate this)." > > This points out that is is a 2119-MUST, but only if the condition is met. Because the "MUST" is not a requirement of draft-ietf-dnsext-dnssec-algo-signal but a requirement of RFC4035 (from memory). We, after all, don't specify all the other things they "MUST" do to get DNSSEC to work. -- Alex Bligh From marka@isc.org Wed Jun 8 06:28:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D944711E80D2 for ; Wed, 8 Jun 2011 06:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id netc0JloTYqE for ; Wed, 8 Jun 2011 06:28:11 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 210B011E80BE for ; Wed, 8 Jun 2011 06:28:10 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id D6517C94AE; Wed, 8 Jun 2011 13:27:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 76CEA216C7B; Wed, 8 Jun 2011 13:27:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 101C6107F9AC; Wed, 8 Jun 2011 23:27:49 +1000 (EST) To: Alex Bligh From: Mark Andrews References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> <140494A4D8B4D1715F1F0591@nimrod.local> <63366D5A116E514AA4A9872D3C53353956F676BB64@QEO40072.de.t-online.corp> In-reply-to: Your message of "Wed, 08 Jun 2011 12:47:04 +0100." Date: Wed, 08 Jun 2011 23:27:48 +1000 Message-Id: <20110608132749.101C6107F9AC@drugs.dv.isc.org> Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:28:12 -0000 In message , Alex Bligh writes: > > > --On 8 June 2011 13:02:57 +0200 "Posner, Sebastian" > wrote: > > > Why not rephrase it like you stated in your example: FIRST the > > condition THEN the measures that must be taken IF the condition is met. > > > > "A validating recursive resolver that wishes to receive DNSSEC RRs > > in the response MUST set the DO bit [RFC4035] (in the question > > packet to indicate this)." > > > > This points out that is is a 2119-MUST, but only if the condition is met. > > Because the "MUST" is not a requirement of > draft-ietf-dnsext-dnssec-algo-signal but a requirement of RFC4035 (from > memory). We, after all, don't specify all the other things they "MUST" > do to get DNSSEC to work. The problem is that DNSSEC RRs includes DNSKEY, DS, RRSIG, NSEC and NSEC3 some of which can be queried for directly without setting DO. > -- > Alex Bligh > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From alex@alex.org.uk Wed Jun 8 07:07:27 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DB721F8520 for ; Wed, 8 Jun 2011 07:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQMaUZOIyr+2 for ; Wed, 8 Jun 2011 07:07:22 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by ietfa.amsl.com (Postfix) with ESMTP id 58B6821F851F for ; Wed, 8 Jun 2011 07:07:22 -0700 (PDT) Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 075AAC560C8; Wed, 8 Jun 2011 15:07:16 +0100 (BST) Date: Wed, 08 Jun 2011 15:07:16 +0100 From: Alex Bligh To: Mark Andrews Message-ID: <4D5412884ABEBA088EFD4A38@Ximines.local> In-Reply-To: <20110608132749.101C6107F9AC@drugs.dv.isc.org> References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> <140494A4D8B4D1715F1F0591@nimrod.local> <63366D5A116E514AA4A9872D3C53353956F676BB64@QEO40072.de.t-online.corp> <20110608132749.101C6107F9AC@drugs.dv.isc.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:07:27 -0000 --On 8 June 2011 23:27:48 +1000 Mark Andrews wrote: >> Because the "MUST" is not a requirement of >> draft-ietf-dnsext-dnssec-algo-signal but a requirement of RFC4035 (from >> memory). We, after all, don't specify all the other things they "MUST" >> do to get DNSSEC to work. > > The problem is that DNSSEC RRs includes DNSKEY, DS, RRSIG, NSEC and NSEC3 > some of which can be queried for directly without setting DO. That is one problem. But there is another, as I wrote previously: > If we want to pick nits, there are 2 problems. One, as you've set out, > there are other ways to get DNSSEC RRs. More significantly perhaps, this > isn't an RFC2119 "MUST" at all. Consider the ambiguous and analagous > sentence "You must take 280 to get to SFO quickly". What this probably > means is not that you MUST got to SFO quickly, nor MUST go to SFO at all, > but that if you want to get to SFO quickly, taking 280 is the way to do > it; it is not saying you "MUST" take 280 at all. I think the same applies > to the sentence above. This document does not mandate that DO is set for such a query; that is the job of RFC4035. It is using "must" other than in an RFC2219 sense. -- Alex Bligh From Ed.Lewis@neustar.biz Wed Jun 8 07:26:33 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF9511E80C5 for ; Wed, 8 Jun 2011 07:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=-2.510, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az8iPz6+-qEU for ; Wed, 8 Jun 2011 07:26:29 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 06E5711E80BE for ; Wed, 8 Jun 2011 07:26:28 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p58EQQjs023867; Wed, 8 Jun 2011 10:26:27 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.222] by Work-Laptop-2.local (PGP Universal service); Wed, 08 Jun 2011 10:26:27 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 08 Jun 2011 10:26:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110608132749.101C6107F9AC@drugs.dv.isc.org> References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> <140494A4D8B4D1715F1F0591@nimrod.local> <63366D5A116E514AA4A9872D3C53353956F676BB64@QEO40072.de.t-online.corp> <20110608132749.101C6107F9AC@drugs.dv.isc.org> Date: Wed, 8 Jun 2011 10:26:21 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 14:26:33 -0000 At 23:27 +1000 6/8/11, Mark Andrews wrote: >The problem is that DNSSEC RRs includes DNSKEY, DS, RRSIG, NSEC and NSEC3 >some of which can be queried for directly without setting DO. Why does everyone forget NSEC3PARAM? Poor little record, gets no respect. ;) All of the DNSSEC records can be queried "directly" without setting the DO. All but NSEC3 match the query type any/all ("*"). Even the NSEC3 can be found in the answer section - if the QTYPE is AXFR or IXFR. The sum of this is - Alex's comment is right. It's certainly not a MUST and not even really a "must." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From scottr.nist@gmail.com Wed Jun 8 11:59:29 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF1911E8152 for ; Wed, 8 Jun 2011 11:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3ZcLbepdmqT for ; Wed, 8 Jun 2011 11:59:27 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 518E211E811D for ; Wed, 8 Jun 2011 11:59:27 -0700 (PDT) Received: by wyb29 with SMTP id 29so674356wyb.31 for ; Wed, 08 Jun 2011 11:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ei/UN4q5nAsRtshL4s34zd8UkYfiyel/67V0rgxNiJU=; b=JZkViMXwZ8lWMnacsSr0P417LbtTYcT/vt7X5UDO5EcPsDAeylAzC61IfkkYM00yDg tlcTAiEVuoesotcfPH2va247DH4NlpZir0eA3RRlc29bTqwQ+cVZwNYxY48gvss2Y014 aUcZIC03r+yeWapbzlVbCJnEshC8kYHZhNxRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=hwTVib4b+gyQFnZFrk1Q2mXyWVy/hOeEBZIzBQaL2yh4PL4OT2I8EEDmMJWbV0npjD LcQe/ua8+UX8qrZwmDZS8WD45tp+HM2/ytPHMEfU/SmygnnpORhzcch9piK2tBHi+vCy CSVme8jI/O3CiUI9FkW31G3KXuXRnY0Ikt5gU= MIME-Version: 1.0 Received: by 10.216.79.5 with SMTP id h5mr7658106wee.110.1307559565661; Wed, 08 Jun 2011 11:59:25 -0700 (PDT) Received: by 10.216.87.21 with HTTP; Wed, 8 Jun 2011 11:59:25 -0700 (PDT) In-Reply-To: References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> Date: Wed, 8 Jun 2011 14:59:25 -0400 Message-ID: From: Scott Rose To: Edward Lewis Content-Type: multipart/alternative; boundary=000e0ce0d80c6f160a04a537ef31 Cc: dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: scott.rose@nist.gov List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 18:59:29 -0000 --000e0ce0d80c6f160a04a537ef31 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/5/25 Edward Lewis > At 14:51 -0400 5/25/11, Patrik F=E4ltstr=F6m wrote: > >> As the wg shepherd on the document draft-ietf-dnsext-dnssec-algo-signal,= I >> am hereby informing we today start a four week working group last call. >> > > I'm assuming you mean this document: > http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-01 > > I don't support this document even though I support this ideal: > > # This proposed EDNS option serves to measure the acceptance and use of > # new digital signing and hash algorithms. > > (That is - I don't think this document achieves its goal.) > > I get that it is good to know what the right algorithm (in the DNSSEC > sense) to use is. But I don't like the thought that a client's algorithm > request would be used to alter the contents of an response. It would be > better to be aware of algorithms, what's deployed, and what to signed wit= h > in a strategic posture, not a tactical posture. > > In the document there is this in section 5: > > # When an authoritative server sees the DAU option in the OPT meta-RR > # in a request the normal algorithm for servicing requests is followed. > > However, in 3.1 it says this: > > # Typically, stub resolvers rely on an upstream recursive server (or > # cache) to provide a response; any algorithm support on the stub > # resolver's side SHOULD be honored (if possible) by an upstream > # recursive cache. > > Propose change: "Typically, stub resolvers rely on an upstream recursive server (or cache) to provide a response. So optimal use of the AU option depends on if the stub resolver performs its own DNSSEC validation." What if a server is both authoritative and an upstream recursive cache? If= , > "honored" (in the latter draft fragment) means to send only the algorithm > that is in the stub's request OPT RR, there's a conflict with > "normal...servicing." > > I feel that this draft has the potential to open up a can of worms with > interactions between signaling bits (namely DNSSEC OK in EDNS0 and the CD > bit in the header) and having to deal up and down the authority to > (validating) forwarder to (validating) cache to stub resolvers. > > I don't think that algorithm roll (or choice) is the issue we thought it > was a few years ago when the idea behind this draft came up, i.e., I don'= t > see the draft solving a real problem. For example, it could be more like= ly > that a recommendation will come out to change key size from 1024 to 2048 > than change from SHA-1 to SHA-256. Recent haggling over hash algorithms = has > convinced me that attacks on hash algorithms aren't much of a threat beca= use > of the limited syntax of DNS records. Perhaps even less of a threat than > the difference in key lengths. > > Not sure if I agree 100% (hence the draft). See draft-ietf-dnsext-ecdsa-00 for an example. The two algorithm codes refer to the same algorithm, but with different curves as well as different hash algorithms. > I don't think this option is needed now, and could cause architectural pa= in > later on. > > PS : > > Section 4 shouldn't be there (at least not standalone). And there is no > reference or definition of "middlebox." > > Section 4 was added because of a comment on an earlier version that requested the section. Propose changing to a more generic "Intermediate System". > This is incorrect in 3.4.1: > > # A validating recursive resolver MUST set the DO bit [RFC4035] to > # indicate that it wishes to receive DNSSEC RRs in the response. If > > Try this, as an example: "$ dig @a.dns.jp jp dnskey" > > (No EDNS0, no DO, but I get DNSKEY records back.) > Changed to remove the MUST based on on the thread comments. > -- > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= - > Edward Lewis NeuStar You can leave a voice > message at +1-571-434-5468 > > Now, don't say I'm always complaining. > Wait, that's a complaint, isn't it? > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --000e0ce0d80c6f160a04a537ef31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/5/25 Edward Lewis <Ed.Lewis@neustar.biz>
At 14:51 -0400 5/25/11, Patrik F=E4ltstr=F6m wrote:
As the wg shepherd on the document draft-ietf-dnsext-dnssec-algo-signal, I<= br> am hereby informing we today start a four week working group last call.

=A0
I'm assuming you mean this document:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-a= lgo-signal-01

I don't support this document even though I support this ideal:

# =A0 This proposed EDNS option serves to measure the acceptance and use of=
# =A0 new digital signing and hash algorithms.

(That is - I don't think this document achieves its goal.)

I get that it is good to know what the right algorithm (in the DNSSEC sense= ) to use is. =A0But I don't like the thought that a client's algori= thm request would be used to alter the contents of an response. =A0It would= be better to be aware of algorithms, what's deployed, and what to sign= ed with in a strategic posture, not a tactical posture.

In the document there is this in section 5:

# =A0 When an authoritative server sees the DAU option in the OPT meta-RR # =A0 in a request the normal algorithm for servicing requests is followed.=

However, in 3.1 it says this:

# =A0 Typically, stub resolvers rely on an upstream recursive server (or # =A0 cache) to provide a response; any algorithm support on the stub
# =A0 resolver's side SHOULD be honored (if possible) by an upstream # =A0 recursive cache.


Propose change: =A0
=A0"= ;Typically, stub resolvers rely on an upstream recursive server (or cache) = to provide a response. So optimal use of the AU option depends on if the stub resolv= er performs its own DNSSEC validation."


What if a server is both authoritative and an upstream recursive cache? =A0= If, "honored" (in the latter draft fragment) means to send only t= he algorithm that is in the stub's request OPT RR, there's a confli= ct with "normal...servicing."

I feel that this draft has the potential to open up a can of worms with int= eractions between signaling bits (namely DNSSEC OK in EDNS0 and the CD bit = in the header) and having to deal up and down the authority to (validating)= forwarder to (validating) cache to stub resolvers.

I don't think that algorithm roll (or choice) is the issue we thought i= t was a few years ago when the idea behind this draft came up, i.e., I don&= #39;t see the draft solving a real problem. =A0For example, it could be mor= e likely that a recommendation will come out to change key size from 1024 t= o 2048 than change from SHA-1 to SHA-256. =A0Recent haggling over hash algo= rithms has convinced me that attacks on hash algorithms aren't much of = a threat because of the limited syntax of DNS records. =A0Perhaps even less= of a threat than the difference in key lengths.


Not sure if I agree 100% (hence the dr= aft). =A0See draft-ietf-dnsext-ecdsa-00 for an example. =A0The two algorith= m codes refer to the same algorithm, but with different curves as well as d= ifferent hash algorithms.

=A0
I don't think this option is needed now, and could cause architectural = pain later on.

PS :

Section 4 shouldn't be there (at least not standalone). =A0And there is= no reference or definition of "middlebox."


Section 4 was added because of a comme= nt on an earlier version that requested the section. =A0Propose changing to= a more generic "Intermediate System".

=A0
This is incorrect in 3.4.1:

# =A0 A validating recursive resolver MUST set the DO bit [RFC4035] to
# =A0 indicate that it wishes to receive DNSSEC RRs in the response. =A0If<= br>
Try this, as an example: =A0"$ dig @a.dns.jp jp dnskey"

(No EDNS0, no DO, but I get DNSKEY records back.)

=
Changed to remove the MUST based on on the thread comments.


=A0
--
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -
Edward Lewis =A0 =A0 =A0 =A0 =A0 =A0 NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?
_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext

--000e0ce0d80c6f160a04a537ef31-- From lutz@iks-jena.de Wed Jun 8 14:13:22 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582B71F0C35 for ; Wed, 8 Jun 2011 14:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKH6HvksmXXU for ; Wed, 8 Jun 2011 14:13:22 -0700 (PDT) Received: from annwfn.iks-jena.de (annwfn-eth.iks-jena.de [IPv6:2001:4bd8:0:104:20a:e4ff:fe80:3138]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4AE1F0C43 for ; Wed, 8 Jun 2011 14:13:20 -0700 (PDT) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.14.3/8.14.1) with ESMTP id p58LDF5Q026895 for ; Wed, 8 Jun 2011 23:13:18 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id p58LDEwD031453; Wed, 8 Jun 2011 23:13:14 +0200 From: Lutz Donnerhacke Message-Id: <201106082113.p58LDEwD031453@belenus.iks-jena.de> To: dnsext@ietf.org In-Reply-To: References: Date: Wed, 8 Jun 2011 23:13:14 +0200 User-Agent: slrn/pre0.9.9-77 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 21:13:22 -0000 Edward Lewis wrote: > Why does everyone forget NSEC3PARAM? Poor little record, gets no respect. That's not a record. It's a configuration entity at a terrible wrong place. From ogud@ogud.com Thu Jun 9 05:36:01 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E04D21F84D0 for ; Thu, 9 Jun 2011 05:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAJDWD206Nzw for ; Thu, 9 Jun 2011 05:36:00 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6F621F84CF for ; Thu, 9 Jun 2011 05:36:00 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p59CZxgO032479 for ; Thu, 9 Jun 2011 08:35:59 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4DF0BE26.2010606@ogud.com> Date: Thu, 09 Jun 2011 08:35:50 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <201106082113.p58LDEwD031453@belenus.iks-jena.de> In-Reply-To: <201106082113.p58LDEwD031453@belenus.iks-jena.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 12:36:01 -0000 On 08/06/2011 5:13 PM, Lutz Donnerhacke wrote: > Edward Lewis wrote: >> Why does everyone forget NSEC3PARAM? Poor little record, gets no respect. > > That's not a record. It's a configuration entity at a terrible wrong place. Just like the SOA record it is instructing Authoritative servers how to behave for a particular zone, I guess the SOA was also a mistake :-) Olafur Ps: Feel free to blame me for the existence of the NSEC3PARAM record it From Ed.Lewis@neustar.biz Thu Jun 9 07:28:16 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D959B11E808B for ; Thu, 9 Jun 2011 07:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.591 X-Spam-Level: X-Spam-Status: No, score=-105.591 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNsjun2nLb62 for ; Thu, 9 Jun 2011 07:28:15 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id D3FFB11E80BA for ; Thu, 9 Jun 2011 07:28:14 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p59ESDwt033139; Thu, 9 Jun 2011 10:28:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.222] by work-laptop-2 (PGP Universal service); Thu, 09 Jun 2011 10:28:13 -0400 X-PGP-Universal: processed; by work-laptop-2 on Thu, 09 Jun 2011 10:28:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DF0BE26.2010606@ogud.com> References: <201106082113.p58LDEwD031453@belenus.iks-jena.de> <4DF0BE26.2010606@ogud.com> Date: Thu, 9 Jun 2011 10:23:41 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] Respect for the NSEC3PARAM Re: 4 week WGLC ... X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:28:16 -0000 At 8:35 -0400 6/9/11, Olafur Gudmundsson wrote: >Just like the SOA record it is instructing Authoritative servers how to >behave for a particular zone, I guess the SOA was also a mistake :-) Oddly, I had the same reaction as Olafur. Where are my meds? >Ps: Feel free to blame me for the existence of the NSEC3PARAM record it Sigh, we'll just add *that* to the list -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From Ed.Lewis@neustar.biz Thu Jun 9 07:57:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D55D21F850E for ; Thu, 9 Jun 2011 07:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASPFJ9e1mxCw for ; Thu, 9 Jun 2011 07:57:22 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 68A9D21F850B for ; Thu, 9 Jun 2011 07:57:22 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p59EvEpZ033404; Thu, 9 Jun 2011 10:57:18 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.222] by work-laptop-2 (PGP Universal service); Thu, 09 Jun 2011 10:57:19 -0400 X-PGP-Universal: processed; by work-laptop-2 on Thu, 09 Jun 2011 10:57:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <48D5ECC8-4FB1-4CAA-A87A-FDEE07B2CBCD@cisco.com> Date: Thu, 9 Jun 2011 10:57:12 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] 4 week WGLC on draft-ietf-dnsext-dnssec-algo-signal X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:57:23 -0000 At 14:59 -0400 6/8/11, Scott Rose wrote: >Proposed change: > "Typically, stub resolvers rely on an upstream recursive server (or cache) to >provide a response. So optimal use of the AU option depends on if the stub >resolver performs its own DNSSEC validation." The latter sentence - The most appropriate use of the AU option is by a validating stub resolver performing validation only for its own protection, i.e., it does not intend to answer queries itself. >Section 4 was added because of a comment on an earlier version that requested >the section. Propose changing to a more generic "Intermediate System". Either way - the adjective used for "system" needs to be defined (in situ or via reference) at a minimum. And there might be more expansion needed to justify it being a separate section. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it? From touch@isi.edu Sun Jun 12 06:51:40 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E126F11E8085; Sun, 12 Jun 2011 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYUBljSuJ5KU; Sun, 12 Jun 2011 06:51:40 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6044411E80F8; Sun, 12 Jun 2011 06:51:40 -0700 (PDT) Received: from [128.9.176.27] (c1-vpn1.isi.edu [128.9.176.27]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5CDpGPF013880 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 12 Jun 2011 06:51:17 -0700 (PDT) Message-ID: <4DF4C454.7070904@isi.edu> Date: Sun, 12 Jun 2011 06:51:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "tsv-ads@tools.ietf.org" , IETF discussion list , draft-ietf-dnsext-rfc2672bis-dname@tools.ietf.org, dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Mon, 13 Jun 2011 04:43:02 -0700 Cc: TSV Dir Subject: [dnsext] TSVDIR review of draft-ietf-dnsext-rfc2672bis-dname X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 13:51:41 -0000 Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. The document discusses change to the DNAME DNS record. Such changes are discussed in their impact to both the DNS in general, and to SRV records in particular. These are the key ways in which this change affects transport protocols, and are sufficiently addressed; there do not appear to be any other transport issues. I do have some other concerns which are noted below, and which are offered for consideration. I hope this feedback will be useful to the authors, and will be glad to provide further assistance either on- or off-list as useful. Joe --------------------------------------------------------------------- The document fails to explain exactly how it changes RFC 2672. At best this is noted obliquely in the end of section 2.5 (is this all?). These changes should be made clear in the abstract, the intro, and in a separate section summarizing the exact ways in which this document overrides RFC 2672. The same advice applies for other RFCs this document updates (though this does appear to occur in Sec 4). Further, it is not clear whether this document changes only part of RFC2672. It includes some parts of that RFC unmodified (Sec 3.2). If this document *obsoletes* that RFC, is this document complete in the absence of that RFC? (this should be made clear in the document explicitly). The abstract explains this is an update and which RFCs are affected, but should also briefly state how and why. I.e., the abstract should be self-contained. "Punycode" should be described when introduced, with a reference. Wherever this document includes advice from RFCs it does not update (e.g., Sec 3.3), it should explicitly indicate whether it is copying advice verbatim or clarifying it. Sec 6 should be revised to clarify the relationship between IANA and the registries it operates. I.e.: The DNAME Resource Record type code 39 (decimal) originally has been registered by [RFC2672]. IANA should update the DNS resource record registry to point to this document for RR type 39. should read: The DNAME Resource Record type code 39 (decimal) originally and currently refers to [RFC2672], the document that initiated its assignment. IANA should update the DNS resource record registry to refer to this document for RR type 39. --- ----- From ondrej.sury@nic.cz Thu Jun 16 00:50:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9FD21F8592 for ; Thu, 16 Jun 2011 00:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTBCj1-A6tTg for ; Thu, 16 Jun 2011 00:50:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A55AF21F84E7 for ; Thu, 16 Jun 2011 00:50:22 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id B2D842A0949 for ; Thu, 16 Jun 2011 09:50:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1308210621; bh=Et4chrUFrjhTrjmY02I6jKNZKws7OmIag4UwPRg+bMw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FSbJt3Ggll/F43pAFWDZOkGEG5BcwSri51F781RP0055eL4kl/RmJTxjSBtJfDq0e 5Rd0LxVX79l3SuEasKLcbpOGVEE5X1ulZfDuSWjg/Hrr2Z52bGluSmnMIS4huaNasd 2a8bbXOW4z6L48xycq+s506fT5ON7fczeW+00Yd4= Message-ID: <4DF9B5BD.7010900@nic.cz> Date: Thu, 16 Jun 2011 09:50:21 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <4DB81069.3080404@nic.cz> In-Reply-To: <4DB81069.3080404@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 07:50:23 -0000 Hi, since I didn't receive any comments I guess: a) it's not exciting b) it's so good that it doesn't need any improvement [which I doubt] I would like to ask the WG for adoption of this document, so we can move on... after all this is just a clarification document with few things added (no name sameness I promise! :)). O. On 27.4.2011 14:47, Ondřej Surý wrote: > Diff is here: > > https://tools.ietf.org/rfcdiff?url1=draft-ah-dnsext-rfc1995bis-ixfr-01&difftype=--html&submit=Go!&url2=draft-ah-dnsext-rfc1995bis-ixfr-02 > > > Sorry it took me so long to prepare -02, which we believe is as good as > it gets. Many thanks for Alfred for doing most of the work. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From Ed.Lewis@neustar.biz Thu Jun 16 12:22:09 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA67511E8239 for ; Thu, 16 Jun 2011 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.168 X-Spam-Level: X-Spam-Status: No, score=-105.168 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP+rz3UK9abT for ; Thu, 16 Jun 2011 12:22:09 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 96C2111E8224 for ; Thu, 16 Jun 2011 12:22:08 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5GJM555096157; Thu, 16 Jun 2011 15:22:06 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.201.23] by Work-Laptop-2.local (PGP Universal service); Thu, 16 Jun 2011 15:22:06 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Thu, 16 Jun 2011 15:22:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DF9B5BD.7010900@nic.cz> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> Date: Thu, 16 Jun 2011 15:22:03 -0400 To: =?iso-8859-1?Q?Ond=DEej_Sur=98?= From: Edward Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 19:22:10 -0000 At 9:50 +0200 6/16/11, Ond=DEej Sur=98 wrote: >Hi, > >since I didn't receive any comments I guess: > >a) it's not exciting >b) it's so good that it doesn't need any improvement [which I doubt] c) was unaware of the document's existence despite thinking "it would be about time to tackle this" ;) I began reading the draft and started listing a=20 lot of comments. It would take me a long time to=20 complete, so I thought I'd raise two things here. 1. The document talks a lot about the context of=20 an IXFR exchange. Can this be removed and stick=20 to just the actions of an IXFR client and server?=20 I mean, it doesn't matter why the IXFR is being=20 kicked off. (BTW, the statement that IXFRs are=20 mostly kicked off by NOTIFY isn't really true, we=20 oversee a lot of zones that do not change thus do=20 not cause NOTIFY's to fly. This factoid applies=20 to different places but in the end, doesn't=20 really matter when you are describing the=20 protocol.) 2. For the first time I have thought abotu=20 IXFR-only and I don't get it at all. The reason=20 is I don't accept that "If this is not possible,=20 in the case of bare IXFR, the server falls back=20 to AXFR, i.e. it provides the full zone content."=20 Yes, there's a AXFR-style IXFR (all in one UDP=20 message) but I don't think that is what is meant. When a server indicates that IXFR can't be used,=20 the server can not switch to AXFR. The switch=20 that is observed in operations comes from the=20 client deciding to switch. If the reason for=20 IXFR-only is that a client, having failed to IXFR=20 from IP address #1 will try AXFR instead of=20 trying IXFR from IP address #2, then my response=20 is that this is an implementation issue, not a=20 protocol issue. RFC 1995 never specifies that a failed IXFR will=20 cause an AXFR to happen. Maybe that's an=20 accident of history, because implementations do=20 this that we think that is what is supposed to=20 happen. It's not in the specification that way,=20 as far as I can find. The closest passage is in section 2 of RFC 1995: Thus, a client should first make an IXFR query using UDP. If the query type is not recognized by the server, an AXFR (preceded by a UDP SOA query) should be tried, ensuring backward compatibility. Note that this is if the IXFR QTYPE is not=20 recognized, not a refusal to use IXFR. And note=20 that this is for backward compatibility. Thinking in another vein, if a client chooses not=20 to ever use AXFR, then what happens when IXFR=20 requests can't be satisfied? Let the zone=20 EXPIRE? Is a dead server better than a server=20 that is taking time to sync up? (This calls out=20 the motivation for IXFR-only.) --- As I mentioned, there is a need to refresh this=20 RFC - well, maybe. I want to suggest specifying=20 that a IXFR client will verify the RRSIG of the=20 first SOA returned. This will close one more=20 place a forger might be able to insert into or=20 remove records from a DNSSEC signed zone without=20 detection (assuming there's no VPN, TSIG, TKEY or=20 similar protection). -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From brian.peter.dickson@gmail.com Thu Jun 16 13:48:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B75111E8293 for ; Thu, 16 Jun 2011 13:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAK---Q6vpbW for ; Thu, 16 Jun 2011 13:48:22 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76D7E11E8170 for ; Thu, 16 Jun 2011 13:48:22 -0700 (PDT) Received: by fxm15 with SMTP id 15so1561971fxm.31 for ; Thu, 16 Jun 2011 13:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2UwGkXZkV1CkO/zPzzDY69ZgRJcrEOdAubxpx0GwJ6w=; b=tTaUzRmv80BmjUZtgDhGgl4qgpjPCaCgXKoNt4JuVtA0IElIQrvUsXHO8DtpmI593l GAqXlDo/CrH1Ackdur9Ddf7Vow4QXaBqDJNj9KE7K9oLa1JcvNzhEnAdR2PCf0nLqHOt 27nNFiGz/YKaihuQarS/BQyBL4ot4KFF3PMIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fG9MElr+F9UZ/mZii1zownEN2Za7hIagQ27iruhnqmZObUcBbyVurzDMh260IimLWh IRPhumrKkB2EzbvFH+z9XMxIFP30rRkXWedelvVwN1fIMoEEIXOgbL9HofLKySIOK+WE t0XfPWwOh8PIkqaqZptNikjH9i65UFuZoLyU8= MIME-Version: 1.0 Received: by 10.223.73.133 with SMTP id q5mr1631872faj.127.1308257301486; Thu, 16 Jun 2011 13:48:21 -0700 (PDT) Received: by 10.223.123.79 with HTTP; Thu, 16 Jun 2011 13:48:21 -0700 (PDT) In-Reply-To: References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> Date: Thu, 16 Jun 2011 16:48:21 -0400 Message-ID: From: Brian Dickson To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 20:48:23 -0000 On Thu, Jun 16, 2011 at 3:22 PM, Edward Lewis wrote: > 2. For the first time I have thought abotu IXFR-only and I don't get it a= t > all. =A0The reason is I don't accept that "If this is not possible, in th= e > case of bare IXFR, the server falls back to AXFR, i.e. it provides the fu= ll > zone content." > [snip] > > RFC 1995 never specifies that a failed IXFR will cause an AXFR to happen. Actually, it does, right at the beginning of section 4. Quoting the text: 4. Response Format If incremental zone transfer is not available, the entire zone is returned. The first and the last RR of the response is the SOA record of the zone. I.e. the behavior is the same as an AXFR response except the query type is IXFR. > Thinking in another vein, if a client chooses not to ever use AXFR, then > what happens when IXFR requests can't be satisfied? =A0Let the zone EXPIR= E? > =A0Is a dead server better than a server that is taking time to sync up? > =A0(This calls out the motivation for IXFR-only.) Those fall under the scope of operator, rather than implementer, issues. Presumably the operator will act sensibly, trying all available sources for IXFR-ONLY, before giving up and doing an explicit AXFR. The need for IXFR-ONLY is the desire to have interoperable implementations. Suggesting that non-interoperable implementations of IXFR, to support IXFR-= ONLY, goes against common sense. It is reasonable to expect zone administrators to operate multiple authority servers for their zones. It is reasonable to expect that zone administrators will want to have zones instances be identical. It is reasonable to expect that zone administrators may want to operate servers from multiple vendors. When you combine "multiple vendors" with "zone instances identical", and add in "efficient transport", you get the requirement for inter-vendor, interoperable IXFR, quite possibly with IXFR-ONLY as a desired capability. The problem is, there is no current work-around, and adding this without -bis standardization, isn't necessarily interoperable. Better to update the standard. It's a no-brainer= . (End of flogging of the deceased quadroped.) Brian From marka@isc.org Thu Jun 16 17:17:56 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5226C1F0C56 for ; Thu, 16 Jun 2011 17:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, MANGLED_FULL=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8+MtiSK4jte for ; Thu, 16 Jun 2011 17:17:55 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 109E91F0C3B for ; Thu, 16 Jun 2011 17:17:54 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id AAC1BC94B3; Fri, 17 Jun 2011 00:17:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DCE90216C7B; Fri, 17 Jun 2011 00:17:42 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D2B9F10D52C8; Fri, 17 Jun 2011 10:17:40 +1000 (EST) To: Brian Dickson From: Mark Andrews References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> In-reply-to: Your message of "Thu, 16 Jun 2011 16:48:21 -0400." Date: Fri, 17 Jun 2011 10:17:40 +1000 Message-Id: <20110617001740.D2B9F10D52C8@drugs.dv.isc.org> Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 00:17:56 -0000 In message , Brian Dickson writes: > On Thu, Jun 16, 2011 at 3:22 PM, Edward Lewis wrote: > > > 2. For the first time I have thought abotu IXFR-only and I don't get it at > > all. =A0The reason is I don't accept that "If this is not possible, in the > > case of bare IXFR, the server falls back to AXFR, i.e. it provides the fu= > ll > > zone content." > > > [snip] > > > > RFC 1995 never specifies that a failed IXFR will cause an AXFR to happen. > > Actually, it does, right at the beginning of section 4. Quoting the text: > > 4. Response Format > > > If incremental zone transfer is not available, the entire zone is > returned. The first and the last RR of the response is the SOA > record of the zone. I.e. the behavior is the same as an AXFR > response except the query type is IXFR. > > > > Thinking in another vein, if a client chooses not to ever use AXFR, then > > what happens when IXFR requests can't be satisfied? =A0Let the zone EXPIR= > E? > > =A0Is a dead server better than a server that is taking time to sync up? > > =A0(This calls out the motivation for IXFR-only.) > > Those fall under the scope of operator, rather than implementer, issues. > Presumably the operator will act sensibly, trying all available > sources for IXFR-ONLY, > before giving up and doing an explicit AXFR. > > The need for IXFR-ONLY is the desire to have interoperable implementations. > > Suggesting that non-interoperable implementations of IXFR, to support IXFR-= > ONLY, > goes against common sense. > > It is reasonable to expect zone administrators to operate multiple > authority servers for their zones. > It is reasonable to expect that zone administrators will want to have > zones instances be identical. > It is reasonable to expect that zone administrators may want to > operate servers from multiple vendors. > > When you combine "multiple vendors" with "zone instances identical", > and add in "efficient transport", > you get the requirement for inter-vendor, interoperable IXFR, quite > possibly with IXFR-ONLY as a desired > capability. > > The problem is, there is no current work-around, and adding this > without -bis standardization, isn't > necessarily interoperable. Better to update the standard. It's a no-brainer. > > (End of flogging of the deceased quadroped.) > > Brian > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext Ed, the problem is that in some ixfr implementations there is no way to turn off, the optional, delta consolidation. If your then have a server being fed from two+ intermediate servers (for redundancy) that are in turn being fed servers that consolidate deltas you get lots of AXFR style responses when you switch between intermediate servers. With this setup the intermediate servers don't have all the changes that have occurred to the zone so they can't always generate a delta style response as they don't have the starting point. This exact senario was warned about in Section 6 of RFC 1995. But, this feature may not be so useful if an IXFR client has access to two IXFR servers: A and B, with inconsistent condensation results. The current version of the IXFR client, received from server A, may be unknown to server B. In such a case, server B can not provide incremental data from the unknown version and a full zone transfer is necessary. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohta@necom830.hpcl.titech.ac.jp Thu Jun 16 18:08:48 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B64811E80F8 for ; Thu, 16 Jun 2011 18:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8+vc3i2Rtca for ; Thu, 16 Jun 2011 18:08:47 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 5BA9011E80CC for ; Thu, 16 Jun 2011 18:08:47 -0700 (PDT) Received: (qmail 73381 invoked from network); 17 Jun 2011 01:17:02 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 17 Jun 2011 01:17:02 -0000 Message-ID: <4DFAA8CC.5040802@necom830.hpcl.titech.ac.jp> Date: Fri, 17 Jun 2011 10:07:24 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <20110617001740.D2B9F10D52C8@drugs.dv.isc.org> In-Reply-To: <20110617001740.D2B9F10D52C8@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 01:08:48 -0000 Mark Andrews wrote: > the problem is that in some ixfr implementations there is no > way to turn off, the optional, delta consolidation. That's not a problem. However, if the implementations blindly consolidate ignoring the paragraph: Information about older versions should be purged if the total length of an IXFR response would be longer than that of an AXFR response. Given that the purpose of IXFR is to reduce AXFR overhead, this strategy is quite reasonable. The strategy assures that the amount of storage required is at most twice that of the current zone information. they are poor implementations to be avoided by rational operators, unless there are fair reasons of the ignorance. Consolidations following the paragraph above may still cause transient inefficiency. But, does that matter and worth protocol extensions and additional operational complexities? Masataka Ohta From marka@isc.org Thu Jun 16 18:28:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6A11E80E8 for ; Thu, 16 Jun 2011 18:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO41-2Yi1Z7l for ; Thu, 16 Jun 2011 18:28:54 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E15A711E8130 for ; Thu, 16 Jun 2011 18:28:53 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 3DD765F98D3; Fri, 17 Jun 2011 01:28:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CE447216C7B; Fri, 17 Jun 2011 01:28:30 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5A8AD10D5D42; Fri, 17 Jun 2011 11:28:27 +1000 (EST) To: Masataka Ohta From: Mark Andrews References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <20110617001740.D2B9F10D52C8@drugs.dv.isc.org> <4DFAA8CC.5040802@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Fri, 17 Jun 2011 10:07:24 +0900." <4DFAA8CC.5040802@necom830.hpcl.titech.ac.jp> Date: Fri, 17 Jun 2011 11:28:27 +1000 Message-Id: <20110617012827.5A8AD10D5D42@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 01:28:55 -0000 In message <4DFAA8CC.5040802@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > > the problem is that in some ixfr implementations there is no > > way to turn off, the optional, delta consolidation. > > That's not a problem. However, if the implementations blindly > consolidate ignoring the paragraph: > > Information about older versions should be purged if the total length > of an IXFR response would be longer than that of an AXFR response. > Given that the purpose of IXFR is to reduce AXFR overhead, this > strategy is quite reasonable. The strategy assures that the amount > of storage required is at most twice that of the current zone > information. > > they are poor implementations to be avoided by rational operators, > unless there are fair reasons of the ignorance. > > Consolidations following the paragraph above may still cause > transient inefficiency. But, does that matter and worth protocol > extensions and additional operational complexities? > > Masataka Ohta Ohta san, you totally missed the point. Sending a AXFR style response when you have the requested starting serial is *not* a problem. The problem is sending a AXFR style response when you don't have the requested starting serial but do have a potential starting serial that is before the requested starting serial. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohta@necom830.hpcl.titech.ac.jp Thu Jun 16 18:45:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1645A11E8145 for ; Thu, 16 Jun 2011 18:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7W2Uqzj-0YQ for ; Thu, 16 Jun 2011 18:45:22 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 0D88211E812C for ; Thu, 16 Jun 2011 18:45:21 -0700 (PDT) Received: (qmail 73634 invoked from network); 17 Jun 2011 01:53:43 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 17 Jun 2011 01:53:43 -0000 Message-ID: <4DFAB161.8030108@necom830.hpcl.titech.ac.jp> Date: Fri, 17 Jun 2011 10:44:01 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Andrews References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <20110617001740.D2B9F10D52C8@drugs.dv.isc.org> <4DFAA8CC.5040802@necom830.hpcl.titech.ac.jp> <20110617012827.5A8AD10D5D42@drugs.dv.isc.org> In-Reply-To: <20110617012827.5A8AD10D5D42@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 01:45:23 -0000 Mark Andrews wrote: > The problem is sending a AXFR style > response when you don't have the requested starting serial but do > have a potential starting serial that is before the requested > starting serial. I wrote: >> Consolidations following the paragraph above may still cause >> transient inefficiency. But, does that matter and worth protocol >> extensions and additional operational complexities? Masataka Ohta From Ed.Lewis@neustar.biz Fri Jun 17 06:37:13 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AA111E8075 for ; Fri, 17 Jun 2011 06:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.99 X-Spam-Level: X-Spam-Status: No, score=-105.99 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keSoHLZzdzQe for ; Fri, 17 Jun 2011 06:37:08 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 21CB711E8070 for ; Fri, 17 Jun 2011 06:37:08 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5HDb2ph002645; Fri, 17 Jun 2011 09:37:03 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.201.23] by work-laptop-2 (PGP Universal service); Fri, 17 Jun 2011 09:37:03 -0400 X-PGP-Universal: processed; by work-laptop-2 on Fri, 17 Jun 2011 09:37:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> Date: Fri, 17 Jun 2011 09:29:02 -0400 To: Brian Dickson From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 13:37:13 -0000 At 16:48 -0400 6/16/11, Brian Dickson wrote: >Actually, it does, right at the beginning of section 4. Quoting the text: > >4. Response Format > > > If incremental zone transfer is not available, the entire zone is > returned. The first and the last RR of the response is the SOA > record of the zone. I.e. the behavior is the same as an AXFR > response except the query type is IXFR. No, that is not a fallback to AXFR. The spec is not saying that an unsatisfactory IXFR session leads to an AXFR session (with the same remote address). What is confusing is the phrase "is the same as." If the query type is IXFR, the response will be an IXFR response that contains all of the records in one (UDP) datagram, which functionally is the same as a AXFR having all of the records appear in multiple DNS messages over a stream - the same for only small to very small zones. The response is limited to 512 bytes or whatever is in the EDNS0 buffer size of the requestor. Think of it this way. If I send an IXFR request over UDP, how could a response be an AXFR? AXFR can only be sent on TCP. In a way, the net result of an AXFR-Style IXFR (as I've heard that called) and an AXFR is that you get the entire zone in one shot. Functionally the result is the same. But the delivery mechanism is much different. No spec ever said that an implementation had to back up IXFR with AXFR (except for backwards compatibility - the passage I quoted). >Those fall under the scope of operator, rather than implementer, issues. >Presumably the operator will act sensibly, trying all available >sources for IXFR-ONLY, before giving up and doing an explicit AXFR. Operators generally use the tools implementers give them. > >The need for IXFR-ONLY is the desire to have interoperable implementations. I said this in another context earlier this week, the desire to have interoperable implementations is subsidiary to having features that make sense. >When you combine "multiple vendors" with "zone instances identical", >and add in "efficient transport", you get the requirement for >inter-vendor, interoperable IXFR, That's obvious, but, wait for it... >quite possibly with IXFR-ONLY as a desired capability. Note here you drop to "quite possibly" - but after reading up on IXFR-only I wouldn't go along with even that. My beef here is that IXFR-only isn't needed (in the protocol) not that there shouldn't be a standard spec for it. IXFR-all-sources-before-AXFR makes more sense than IXFR-only. And even that is what I would consider an implementation optimization. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From Ed.Lewis@neustar.biz Fri Jun 17 06:54:09 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5211E815C for ; Fri, 17 Jun 2011 06:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.045 X-Spam-Level: X-Spam-Status: No, score=-106.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiQrl-IcxlKW for ; Fri, 17 Jun 2011 06:54:09 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id DFAA711E8139 for ; Fri, 17 Jun 2011 06:54:08 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5HDs0gA002754; Fri, 17 Jun 2011 09:54:04 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.201.23] by work-laptop-2 (PGP Universal service); Fri, 17 Jun 2011 09:54:07 -0400 X-PGP-Universal: processed; by work-laptop-2 on Fri, 17 Jun 2011 09:54:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DFAB161.8030108@necom830.hpcl.titech.ac.jp> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <20110617001740.D2B9F10D52C8@drugs.dv.isc.org> <4DFAA8CC.5040802@necom830.hpcl.titech.ac.jp> <20110617012827.5A8AD10D5D42@drugs.dv.isc.org> <4DFAB161.8030108@necom830.hpcl.titech.ac.jp> Date: Fri, 17 Jun 2011 09:53:57 -0400 To: Masataka Ohta From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 13:54:09 -0000 At 10:44 +0900 6/17/11, Masataka Ohta wrote: >Mark Andrews wrote: > >> The problem is sending a AXFR style >> response when you don't have the requested starting serial but do >> have a potential starting serial that is before the requested >> starting serial. > >I wrote: > >>> Consolidations following the paragraph above may still cause >>> transient inefficiency. But, does that matter and worth protocol >>> extensions and additional operational complexities? I'm arguing the same as Ohta-san. I think RFC 1995's description is pretty clear, and whatever IXFR-only is trying to solve is just to address what implementations have done at the cost of muddying up the protocol further. I had been thinking of requesting IXFR be updated for DNSSEC, but even that idea is really just about hardening implementations, not changing the IXFR protocol at all. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From ondrej.sury@nic.cz Fri Jun 17 07:15:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352D611E80D5 for ; Fri, 17 Jun 2011 07:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y0UMLcs3X7m for ; Fri, 17 Jun 2011 07:15:25 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A881D11E8087 for ; Fri, 17 Jun 2011 07:15:21 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 02C852A0BE8; Fri, 17 Jun 2011 16:15:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1308320116; bh=QQYNHFAfCZGJklQ8n8iXPKI8ApfnrmWPLl0cyeL/zMU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aawRsJIctPQnbmAIquYdna8rgr0JRSbq0j+6hSeKjS+zeBHexL/9rsGhnQyrAg+ND wPJJSSDCL7AEpsygEWq7D6Ukz39/ymipqo81ERFGPr7scat2Clz4ERHtGoRxvKUGgo DXBXBUctIx59XBJ2STbm9vQFISWHwXBsjbMPhrRA= Message-ID: <4DFB6173.5080802@nic.cz> Date: Fri, 17 Jun 2011 16:15:15 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Edward Lewis References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: Alfred Hoenes , dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 14:15:28 -0000 On 17.6.2011 15:29, Edward Lewis wrote: > At 16:48 -0400 6/16/11, Brian Dickson wrote: > >> Actually, it does, right at the beginning of section 4. Quoting the text: >> >> 4. Response Format >> >> >> If incremental zone transfer is not available, the entire zone is >> returned. The first and the last RR of the response is the SOA >> record of the zone. I.e. the behavior is the same as an AXFR >> response except the query type is IXFR. > > No, that is not a fallback to AXFR. The spec is not saying that an > unsatisfactory IXFR session leads to an AXFR session (with the same > remote address). > > What is confusing is the phrase "is the same as." > > If the query type is IXFR, the response will be an IXFR response that > contains all of the records in one (UDP) datagram, which functionally is > the same as a AXFR having all of the records appear in multiple DNS > messages over a stream - the same for only small to very small zones. > The response is limited to 512 bytes or whatever is in the EDNS0 buffer > size of the requestor. > > Think of it this way. If I send an IXFR request over UDP, how could a > response be an AXFR? AXFR can only be sent on TCP. > > In a way, the net result of an AXFR-Style IXFR (as I've heard that > called) and an AXFR is that you get the entire zone in one shot. > Functionally the result is the same. But the delivery mechanism is much > different. No spec ever said that an implementation had to back up IXFR > with AXFR (except for backwards compatibility - the passage I quoted). But the fact is that you get a full zone. Also the new draft says: In case of fallback to AXFR, the answer contains the same RRs (and is subject to the same ordering rules) as specified in Sections 2.2 through 3 of RFC 5936, with the single difference being the echoed QCODE (i.e., IXFR) in the Question section. The fact is that the it's the behaviour which is "AXFR" (that is what we talk about), but the QCODE/RCODE is not "AXFR", but IXFR. >> Those fall under the scope of operator, rather than implementer, issues. >> Presumably the operator will act sensibly, trying all available >> sources for IXFR-ONLY, before giving up and doing an explicit AXFR. > > Operators generally use the tools implementers give them. > >> >> The need for IXFR-ONLY is the desire to have interoperable >> implementations. > > I said this in another context earlier this week, the desire to have > interoperable implementations is subsidiary to having features that make > sense. The IXFR-only is backwards compatible both ways in Client+, Server- and Client-,Server+ scenarios. Client+,Server- C: Query IXFR-ONLY S: NotImpl C: Query IXFR S: ... Client-,Server+ C: Query IXFR S: ... > IXFR-all-sources-before-AXFR makes more sense > than IXFR-only. And even that is what I would consider an > implementation optimization. It is optimization (look into archive, we talked about that before and it should be written in Motivations for IXFR-only section of the I-D). And you cannot do IXFR-all-sources-before-AXFR without IXFR-only. O. P.S.: I'll reply to your first mail later, but bear in mind that it's written in context of AXFR clarify. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From Ed.Lewis@neustar.biz Fri Jun 17 07:53:53 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A4D11E8191 for ; Fri, 17 Jun 2011 07:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.243 X-Spam-Level: X-Spam-Status: No, score=-105.243 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEP4Q++AlunI for ; Fri, 17 Jun 2011 07:53:52 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6120F11E817D for ; Fri, 17 Jun 2011 07:53:52 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5HErnkE003160; Fri, 17 Jun 2011 10:53:49 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.201.23] by work-laptop-2 (PGP Universal service); Fri, 17 Jun 2011 10:53:50 -0400 X-PGP-Universal: processed; by work-laptop-2 on Fri, 17 Jun 2011 10:53:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DFB6173.5080802@nic.cz> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFB6173.5080802@nic.cz> Date: Fri, 17 Jun 2011 10:50:15 -0400 To: =?iso-8859-1?Q?Ond=DEej_Sur=98?= From: Edward Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Alfred Hoenes , Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 14:53:53 -0000 At 16:15 +0200 6/17/11, Ond=DEej Sur=98 wrote: >But the fact is that you get a full zone. > >Also the new draft says: > > In case of fallback to AXFR, the answer contains the same RRs (and is > subject to the same ordering rules) as specified in Sections 2.2 > through 3 of RFC 5936, with the single difference being the echoed > QCODE (i.e., IXFR) in the Question section. > >The fact is that the it's the behaviour which is "AXFR" (that is what we >talk about), but the QCODE/RCODE is not "AXFR", but IXFR. My impression is that the issue surrounding=20 IXFR-only is about load on processing and network=20 latency. I fail to see that the problem is that=20 you get all of the zone at once. The problem is=20 that you have to do a lot of work to get all of=20 the records of an large zone when all you really=20 need is a just a small increment. Why else would IXFR-only be needed? Is it just to discover all of the increments?=20 That sounds like a poor reason. The increments=20 aren't important except to satisfy onward IXFR=20 answers and even then, if the zone is small, why=20 not just use AXFR-style IXFR? >It is optimization (look into archive, we talked about that before and >it should be written in Motivations for IXFR-only section of the I-D). The archives are not searchable - have links? -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From brian.peter.dickson@gmail.com Fri Jun 17 08:02:10 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB7311E809C for ; Fri, 17 Jun 2011 08:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEl26o0HxjBJ for ; Fri, 17 Jun 2011 08:02:10 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBE011E81A6 for ; Fri, 17 Jun 2011 08:02:05 -0700 (PDT) Received: by fxm15 with SMTP id 15so2081928fxm.31 for ; Fri, 17 Jun 2011 08:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pGYGQch+TCArrdm4cc3nTb4h8NGuV/IOjHVNo3pGajY=; b=Hew/RkHEmzGW6CoIMsD5E3MdPODiJqqPRLGMW81r4ILIKSlmZOVSPf/hN/CJvm0JuQ p4iJAFGvR4voUA7LYv0TFKgq4Pae/97h1XoC1X+ChsrNvYw1gqFKX6K1vVkblQ24ZIvC hzIsfEg9EF+8NsZRGm/yqxsWiLDAjiETfm0A4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lv6Y6WZ7kbFFrvs9ADQdDXEjd24AJ22cQDZ5jKGJ3nT4xjiKAE1Z8IHULNEN1evnjF 0DYDoGJ+dB0wCi7zB5XKQ5j/rO31+QOxqtS2FaXZkfBnoJUolzGZKk5543d7DBr+cr21 M54VZFBIwRNV0r+u3OinpsQYSU3kNk7xchHKY= MIME-Version: 1.0 Received: by 10.223.156.9 with SMTP id u9mr108941faw.70.1308322925124; Fri, 17 Jun 2011 08:02:05 -0700 (PDT) Received: by 10.223.123.79 with HTTP; Fri, 17 Jun 2011 08:02:05 -0700 (PDT) In-Reply-To: References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> Date: Fri, 17 Jun 2011 11:02:05 -0400 Message-ID: From: Brian Dickson To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:02:11 -0000 On Fri, Jun 17, 2011 at 9:29 AM, Edward Lewis wrote: > If the query type is IXFR, the response will be an IXFR response that > contains all of the records in one (UDP) datagram, which functionally is = the > same as a AXFR having all of the records appear in multiple DNS messages > over a stream - the same for only small to very small zones. =A0The respo= nse > is limited to 512 bytes or whatever is in the EDNS0 buffer size of the > requestor. IXFR does not need to be over UDP. In RFC 1995, it even describes falling b= ack to doing IXFR over TCP, if IXFR over UDP fails for anything other than a few specific RCODEs. If the IXFR query is sent over TCP, the answer will either be an IXFR (for real), or an IXFR which includes the whole zone. IXFR-ONLY is designed specifically to handle the latter case, preventing the "or..." from being done. There are plenty of zones that require IXFR-ONLY in order to efficiently and effectively process zone updates. The motivation and justification for this is clear, IMHO. If there is no workaround possible, which I assert is the case for some zones, then IXFR-ONLY is required. I see no reason not to include it in the protocol specification, if it is going to be implemented by more than one implementation. And I assert that the latter is certainly the case. Brian From Ed.Lewis@neustar.biz Fri Jun 17 08:41:33 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4424911E81BB for ; Fri, 17 Jun 2011 08:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.065 X-Spam-Level: X-Spam-Status: No, score=-106.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnBqD-43ddeS for ; Fri, 17 Jun 2011 08:41:32 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 56DE811E8179 for ; Fri, 17 Jun 2011 08:41:32 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5HFfRhZ003495; Fri, 17 Jun 2011 11:41:28 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.201.23] by work-laptop-2 (PGP Universal service); Fri, 17 Jun 2011 11:41:28 -0400 X-PGP-Universal: processed; by work-laptop-2 on Fri, 17 Jun 2011 11:41:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> Date: Fri, 17 Jun 2011 11:41:24 -0400 To: Brian Dickson From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:41:33 -0000 At 11:02 -0400 6/17/11, Brian Dickson wrote: >IXFR does not need to be over UDP. The point is that IXFR can be over UDP, not that it could be over TCP. >If the IXFR query is sent over TCP, the answer will either be an IXFR >(for real), or an IXFR which includes the whole zone. I don't think there is an understanding of IXFR. I'd suggest reading 1995 again and checking it against your code. Perhaps your code missed something. >There are plenty of zones that require IXFR-ONLY in order to >efficiently and effectively process zone updates. > Can you give me an example how your implementation is less "efficient" without IXFR-only and how you would alter your implementation to make use of it. That would help establish a justification... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From brian.peter.dickson@gmail.com Fri Jun 17 11:05:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E862B11E814C for ; Fri, 17 Jun 2011 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-ob9H7APAml for ; Fri, 17 Jun 2011 11:05:06 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C488711E8118 for ; Fri, 17 Jun 2011 11:05:05 -0700 (PDT) Received: by fxm15 with SMTP id 15so2188714fxm.31 for ; Fri, 17 Jun 2011 11:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RPpAxWifFfoUxmhEHcGff7H+dUsuISRKQagXRIger9Y=; b=TLH7CiWhWrNLVGyn8gtJQ1Pd3YVpH5XCZuM5YpOAA17ERxjmdjVW9bS7+x6KX/Pm6H pox2Zt77aBsMpUw2hXqGKfNv62Wz5bCQ2iwauXjzvKnnOv8X68z41QkdKfhTnKnutaC7 NVauwZBNdrFc21jTRJUPwbNBizLxmgVSO2ZFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FKjX8Nan6s5VLQI4tVRA83IrfTQcpMKbWSOf65vk/A+7lbYmkVA7my8M2M569AqYX7 n7SKibCJXa7UO86I4qBDZIY5cmRfuNgMCRrFWdatMgTZAVomDIP704auoI7Zry5EdYRf E0bbFcNxtoNBfmewkXVO7+8ueETqfnwfkp77A= MIME-Version: 1.0 Received: by 10.223.156.9 with SMTP id u9mr327611faw.70.1308333904810; Fri, 17 Jun 2011 11:05:04 -0700 (PDT) Received: by 10.223.123.79 with HTTP; Fri, 17 Jun 2011 11:05:04 -0700 (PDT) In-Reply-To: References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> Date: Fri, 17 Jun 2011 14:05:04 -0400 Message-ID: From: Brian Dickson To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 18:05:07 -0000 On Fri, Jun 17, 2011 at 11:41 AM, Edward Lewis wrote= : > At 11:02 -0400 6/17/11, Brian Dickson wrote: > >> IXFR does not need to be over UDP. > > The point is that IXFR can be over UDP, not that it could be over TCP. > >> If the IXFR query is sent over TCP, the answer will either be an IXFR >> (for real), or an IXFR which includes the whole zone. > > I don't think there is an understanding of IXFR. =A0I'd suggest reading 1= 995 > again and checking it against your code. =A0Perhaps your code missed > something. I am pretty sure I didn't miss anything. The point is, that there could be a situation, for a large zone, such that: - IXFR over UDP is never possible (too much flux for the capacity of UDP) - "real" IXFR might or might not be possible due to purging - AXFR is orders of magnitude bigger (e.g. 10^4 or more) than IXFR The "clever" trick of "AXFR" (IXFR fallback) being too big for UDP, can't be used. Either a protocol change (non-standard, or standards-based) between the client is needed, or the client is forced to be very unfriendly, and abort the IXFR if it doesn't see its own Serial as the second RR of the IXFR. Closing the TCP socket is the only mechanism it would have to do that. >> There are plenty of zones that require IXFR-ONLY in order to >> efficiently and effectively process zone updates. >> > > Can you give me an example how your implementation is less "efficient" > without IXFR-only and how you would alter your implementation to make use= of > it. > > That would help establish a justification... I'll do my best. First, let's presume there's a non-trivial amount of IXFR needed, and a non-trivial number of servers involved. The smallest non-trivial arrangement that comes to mind is the following: - 1 hidden master (source of truth, originator of all zone data) - a set of distribution servers (hidden again, feeding non-hidden servers) - authority servers to the world, who get their zones via XFR from the distribution servers This can be scaled upward by adding additional layers of distribution, if needed. Redundancy across multiple servers at each layer is presumed. (The redundancy on the hidden master itself is out of scope.) Now, presume some kind of command-and-control infrastructure, directing/coordinating the activities and functions of the servers. Call it the MCP (master control program). And also presume some kind of mini-command-and-control scripting on each of the non-hidden authority servers, i.e. for when they boot up. Call it the bcp (boot control program). Here's an example design: The MCP keeps track of the current Hidden Master Serial Number (HMSN). The MCP also keeps track of the Distribution Server Serial Numbers (DSSN), along with the DS state (up/down/booting/whatever). And the MCP keeps track of the Authority Server Serial Numbers (ASSN), along with AS state (up/down/booting/whatever). The MCP can tell each DS to purge its IXFR database. The MCP keeps track of what DSSN's are available for IXFR on a server-by-server basis. Every time the HMSN changes, the MCP cycles through the currently "up" DS's, telling all but the "next" one to purge. Thus, if there are "X" number of DS's up, there are as many as X-1 different IXFR's possible, based on the respective DSSN's. If an Authority Server is down for a relatively brief period of time (crash/reboot), there is a good chance it can get itself up to date by an IXFR-ONLY. It "goes around the circle", in the reverse order, looking for the DS that can give it an IXFR-ONLY to bring it current. Once it goes once around the circle without succeeding, it falls back to an AXFR. If it takes less time to reboot than it takes for "X-1" serial number changes, the IXFR-ONLY will be possible. Similarly, the HM->DS updates can also be via IXFR-ONLY, possibly involving the use of DS->DS IXFR-ONLY for scalability. The overall objective is to reduce the probability of requiring an AXFR to near zero, and to also limit the overhead in terms of IXFR state needed to achieve this. Removing AXFR from anywhere but the edge, under normal operational conditions, is important for big zones that change frequently. If it were not for IXFR-ONLY, there would be no "clean" way to do this - since IXFR fallback to pseudo-AXFR would interfere with the attempts. Observation: A query for "what SNs do you have available for IXFR" would be the equivalent", or similarly, an "can you IXFR me SN foo" query would also do the trick. However, both of these are non-atomic and introduce race conditions. An IXFR-ONLY is atomic - if it is possible, the IXFR occurs; if not, it says so. Doing two queries (with non-trivial (network + cpu) delay between a "can you IXFR me SN foo", and an "IXFR foo"), means a "yes" followed by an unexpected AXFR, is the race condition. Brian From mohta@necom830.hpcl.titech.ac.jp Sat Jun 18 05:38:44 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C94111E80A2 for ; Sat, 18 Jun 2011 05:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+DZmfTmvx0y for ; Sat, 18 Jun 2011 05:38:43 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id CB2B711E8082 for ; Sat, 18 Jun 2011 05:38:40 -0700 (PDT) Received: (qmail 4654 invoked from network); 18 Jun 2011 12:47:20 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 18 Jun 2011 12:47:20 -0000 Message-ID: <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> Date: Sat, 18 Jun 2011 21:37:52 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 12:38:44 -0000 Brian Dickson wrote: > Now, presume some kind of command-and-control infrastructure, > directing/coordinating the activities and functions of the servers. > The MCP also keeps track of the Distribution Server Serial Numbers > (DSSN), along with the DS state (up/down/booting/whatever). > And the MCP keeps track of the Authority Server Serial Numbers (ASSN), > along with AS state (up/down/booting/whatever). If you want to have complex solutions for a simple problem, have a command-and-control infrastructure which can tell ASes from which DS to IXFR. If you don't, > The MCP can tell each DS to purge its IXFR database. never purge purposelessly. Masataka Ohta From brian.peter.dickson@gmail.com Sat Jun 18 17:24:56 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F1711E8098 for ; Sat, 18 Jun 2011 17:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nrKZ8A2ypLx for ; Sat, 18 Jun 2011 17:24:55 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3709E11E807F for ; Sat, 18 Jun 2011 17:24:55 -0700 (PDT) Received: by fxm15 with SMTP id 15so531751fxm.31 for ; Sat, 18 Jun 2011 17:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wmwScCivWgG6HDXR99QXy2TI6ZSL36lFpolQxmIoe0k=; b=ClnaDEALqRQfsuFewmpGCIPaudyci0D80tnJHIqpxbcVUL63QiSxB0Av5f+vmm10oR b2CNSX0QvZgeNczsj1l0BCGonodIdc0PIkG2fPcQlZW/LQuJocJSxziGgvfKejO3Klxp r1hlnqCKhjX55tHu83IdnoPcVEu23GAtGuPlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rHeflEbblpMuoBufGDK3AbE4PX8Lra8GJcJZAoJSAWiUS5ucZmQguF5gZXDbYsbS7U 5zMfBrUSqYKn72BSgdukMTt6vsEoobTgbclJvTS1hih+7Cg+4JtkbDh+r+nRRr1fVMz7 U9OKiVqBwGjUR1s5MBDrCmDb+ftEJL4VbaHE4= MIME-Version: 1.0 Received: by 10.223.145.24 with SMTP id b24mr4108170fav.89.1308443094069; Sat, 18 Jun 2011 17:24:54 -0700 (PDT) Received: by 10.223.123.79 with HTTP; Sat, 18 Jun 2011 17:24:54 -0700 (PDT) In-Reply-To: <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> Date: Sat, 18 Jun 2011 20:24:54 -0400 Message-ID: From: Brian Dickson To: Masataka Ohta Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 00:24:56 -0000 On Sat, Jun 18, 2011 at 8:37 AM, Masataka Ohta wrote: > Brian Dickson wrote: > >> Now, presume some kind of command-and-control infrastructure, >> directing/coordinating the activities and functions of the servers. > >> The MCP also keeps track of the Distribution Server Serial Numbers >> (DSSN), along with the DS state (up/down/booting/whatever). >> And the MCP keeps track of the Authority Server Serial Numbers (ASSN), >> along with AS state (up/down/booting/whatever). > > If you want to have complex solutions for a simple problem, > have a command-and-control infrastructure which can tell ASes > from which DS to IXFR. You are in fact correct. The only problem is that, telling an AS to IXFR from a DS, does not necessarily mean that the DS is able to provide the requested IXFR. Yes, most of the time it should be able to, and will. However, the rare time that it can't, IXFR-ONLY is important to have, to avoid fallback. > If you don't, > >> The MCP can tell each DS to purge its IXFR database. > > never purge purposelessly. Exactly. Thank you for demonstrating that you understand what I wrote. (I realize that understand is not synonymous with agree.) From wouter@nlnetlabs.nl Mon Jun 20 00:51:03 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581C811E80F9 for ; Mon, 20 Jun 2011 00:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcokMgFOSK1g for ; Mon, 20 Jun 2011 00:51:01 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0134C11E80DA for ; Mon, 20 Jun 2011 00:50:59 -0700 (PDT) Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p5K7osMo038757 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 20 Jun 2011 09:50:54 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4DFEFBDE.4030303@nlnetlabs.nl> Date: Mon, 20 Jun 2011 09:50:54 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 20 Jun 2011 09:50:54 +0200 (CEST) Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 07:51:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian, On 06/17/2011 08:05 PM, Brian Dickson wrote: > On Fri, Jun 17, 2011 at 11:41 AM, Edward Lewis wrote: >> I don't think there is an understanding of IXFR. I'd suggest reading 1995 >> again and checking it against your code. Perhaps your code missed >> something. > > Either a protocol change (non-standard, or standards-based) between > the client is needed, > or the client is forced to be very unfriendly, and abort the IXFR if > it doesn't see its own Serial > as the second RR of the IXFR. Closing the TCP socket is the only > mechanism it would have to do that. What is wrong with closing the TCP socket? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN/vvYAAoJEJ9vHC1+BF+N1xcP/1a63KC8Rs3Nne/GNqCR6aMJ pF+eAPg0vxZAgfEHRRDYJmkNrWeTxTXY/AUVc1uHz8xGTLHfHnNw+TSW33NpL93J huA3QyCEkZOy6i1zvpJRNu77JzJxfjYXv0XEvzce+9jccnvqCinGuLcs0rRhO3mR Pt4zThfM3iSQKmDTt0ZAVOGw8ZXnDrGRuJoFqfV2TjDku9F3Yhno1Rl6j/ouIpyz enET7YzJbEtp98eLKU2aM8voLyc+6PbK2lPqawupIyfUjLCchSkIhSAiMURfK4gq +UQ/zbBqD/QjmOgFPph0s38bn4IZd7D4YWkEhYBQAXQq5BIZEh7WSWSfYTwqCb4F u1jY1anmVsV7wNrXGJpj1MNgBAA/Lm8igeZ1xLJKqzaitDRw0qoN6Ny53p4yr8C6 c7bQ3APTLnEideAs2iCocnCyXe7cBO4Ni4bjpSbjLlNbAMBW9peLyRKYC16fnO0b bmm+fbl7rHCt8a+/+dzKdPtQRmTkZO5aNYn8MNmt5LbyFOPTX3JSNFlrfIj0QAkc m+hGC9Vfojzz7ukOxtIzu8vyUW5v9zrp+ak15/IyAcU4rqitlzOzO2NOWtlkgftA wxqaJxUlg1As+Jy8RG0jTbBLYe10DY1b45/yDHd0HBRuRZDasYvyOut382iLgvox OWOZTc2BkNio+I567aBq =iREP -----END PGP SIGNATURE----- From shane@isc.org Mon Jun 20 05:11:13 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B2311E815F for ; Mon, 20 Jun 2011 05:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1yGNMoRJO9N for ; Mon, 20 Jun 2011 05:11:12 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 498C411E815C for ; Mon, 20 Jun 2011 05:11:12 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1DB4FC9428; Mon, 20 Jun 2011 12:11:07 +0000 (UTC) (envelope-from shane@isc.org) Received: from [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00] (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 7BFC9216C83; Mon, 20 Jun 2011 12:11:05 +0000 (UTC) (envelope-from shane@isc.org) From: Shane Kerr To: Edward Lewis In-Reply-To: References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFB6173.5080802@nic.cz> Content-Type: text/plain; charset="UTF-8" Organization: ISC Date: Mon, 20 Jun 2011 14:11:01 +0200 Message-ID: <1308571861.2742.34.camel@shane-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit Cc: dnsext@ietf.org Subject: [dnsext] Use case for IXFR-only, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:11:13 -0000 Ed, On Fri, 2011-06-17 at 10:50 -0400, Edward Lewis wrote: > At 16:15 +0200 6/17/11, OndÞej Sur˜ wrote: > > >But the fact is that you get a full zone. > > > >Also the new draft says: > > > > In case of fallback to AXFR, the answer contains the same RRs (and is > > subject to the same ordering rules) as specified in Sections 2.2 > > through 3 of RFC 5936, with the single difference being the echoed > > QCODE (i.e., IXFR) in the Question section. > > > >The fact is that the it's the behaviour which is "AXFR" (that is what we > >talk about), but the QCODE/RCODE is not "AXFR", but IXFR. > > My impression is that the issue surrounding > IXFR-only is about load on processing and network > latency. I fail to see that the problem is that > you get all of the zone at once. The problem is > that you have to do a lot of work to get all of > the records of an large zone when all you really > need is a just a small increment. Yes, the problem is CPU, memory, network bandwidth, and latency. If you have multiple masters, and one is missing a particular version of a zone for whatever reason (for example if the server needs to be restarted and has a long fsck), then if your slave is unlucky and sends IXFR to that master, then it will get the entire version of the zone, even if other masters can happily supply just the differences in the zone. If your zone is large or your connections are slow, this can be a problem. The reason this came up is that two operators (Ondrej and me) both encountered the problem in the real world and it adversely affected our operations. IXFR-only specifies that you do not want the behavior to fall back to an AXFR-style transfer, to avoid this issue. That's all. In my mind, it turns IXFR into "Do What I Said" instead of "Do What You Think Might Be Helpful". :) -- Shane From shane@isc.org Mon Jun 20 05:14:20 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C954011E807A for ; Mon, 20 Jun 2011 05:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdDK-QP+ZE4x for ; Mon, 20 Jun 2011 05:14:20 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF1511E8078 for ; Mon, 20 Jun 2011 05:14:20 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id B28DEC94B7; Mon, 20 Jun 2011 12:14:11 +0000 (UTC) (envelope-from shane@isc.org) Received: from [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00] (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3E15F216C86; Mon, 20 Jun 2011 12:14:10 +0000 (UTC) (envelope-from shane@isc.org) From: Shane Kerr To: "W.C.A. Wijngaards" In-Reply-To: <4DFEFBDE.4030303@nlnetlabs.nl> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> Content-Type: text/plain; charset="UTF-8" Organization: ISC Date: Mon, 20 Jun 2011 14:14:07 +0200 Message-ID: <1308572047.2742.37.camel@shane-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:14:20 -0000 Wouter, On Mon, 2011-06-20 at 09:50 +0200, W.C.A. Wijngaards wrote: > On 06/17/2011 08:05 PM, Brian Dickson wrote: > > On Fri, Jun 17, 2011 at 11:41 AM, Edward Lewis wrote: > >> I don't think there is an understanding of IXFR. I'd suggest reading 1995 > >> again and checking it against your code. Perhaps your code missed > >> something. > > > > Either a protocol change (non-standard, or standards-based) between > > the client is needed, > > or the client is forced to be very unfriendly, and abort the IXFR if > > it doesn't see its own Serial > > as the second RR of the IXFR. Closing the TCP socket is the only > > mechanism it would have to do that. > > What is wrong with closing the TCP socket? There's nothing especially wrong with that, and IIRC we did consider this option when discussing IXFR-only over beers several years ago. While you will not get the entire zone, you'll likely still get a lot of extra data. Your operating system will be happily filling its TCP buffer until your application notices that it is getting a AXFR-style transfer and then closes the connection. Granted this is probably only a few tens of MB at most, but I don't think the changes on the slave side are much more complicated for IXFR-only, and solve the problem. -- Shane From Ed.Lewis@neustar.biz Mon Jun 20 05:35:09 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0B9E801F for ; Mon, 20 Jun 2011 05:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.103 X-Spam-Level: X-Spam-Status: No, score=-106.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT88HpMI7yK8 for ; Mon, 20 Jun 2011 05:35:08 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEAC9E801A for ; Mon, 20 Jun 2011 05:35:08 -0700 (PDT) Received: from bsul-lt500.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5KCZ5WF025352; Mon, 20 Jun 2011 08:35:05 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.30] by bsul-lt500.cis.neustar.com (PGP Universal service); Mon, 20 Jun 2011 08:35:06 -0400 X-PGP-Universal: processed; by bsul-lt500.cis.neustar.com on Mon, 20 Jun 2011 08:35:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1308571861.2742.34.camel@shane-desktop> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFB6173.5080802@nic.cz> <1308571861.2742.34.camel@shane-desktop> Date: Mon, 20 Jun 2011 08:28:57 -0400 To: Shane Kerr From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Use case for IXFR-only, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:35:09 -0000 At 14:11 +0200 6/20/11, Shane Kerr wrote: >The reason this came up is that two operators (Ondrej and me) both >encountered the problem in the real world and it adversely affected our >operations. I get what you are saying. But was this caused by the way the tools available worked or was there something wrong with the protocol that forced the tools to react this way? That's my central question. >IXFR-only specifies that you do not want the behavior to fall back to an >AXFR-style transfer, to avoid this issue. That's all. What I'm contending is that the fall back is done by an impementation and not part of the protocol. >In my mind, it turns IXFR into "Do What I Said" instead of "Do What You >Think Might Be Helpful". :) What I began to think about, because of this thread, is that there's no reason why server B - acting as a NOTIFY server - has to request an IXFR from server A - acting as a NOTIFY client - but collectively we have thought of it this way. Not that NOTIFY is the only lead into an IXFR or AXFR, it's just one of the ways to illustrate this. If server A tells server B "I have a new zone", the protocol does not tell B it has to go to A for an update. It's conceivable that server B will try to get the update from C. B can send AXFR/IXFR requests to C without a NOTIFY (timer expiration would be one reason now). It sounds to me that IXFR-only is more like try-all-possible-sources-for-IXFR-first. And that can be done in code. NOTIFY/IXFR/AXFR are all distinct and independent mechanisms within the DNS architecture. They aren't necessarily linked but implementers have linked them. It's natural to do so - I'm not saying implementers are the cause of all evil here (although they generally are) - but again this is is maybe just a mass adoption of a bad assumption. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From Ed.Lewis@neustar.biz Mon Jun 20 05:35:13 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC26711E8169 for ; Mon, 20 Jun 2011 05:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.136 X-Spam-Level: X-Spam-Status: No, score=-106.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTtHB4m3tEFe for ; Mon, 20 Jun 2011 05:35:13 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE1611E8168 for ; Mon, 20 Jun 2011 05:35:12 -0700 (PDT) Received: from bsul-lt500.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5KCZ5WH025352; Mon, 20 Jun 2011 08:35:11 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.30] by bsul-lt500.cis.neustar.com (PGP Universal service); Mon, 20 Jun 2011 08:35:12 -0400 X-PGP-Universal: processed; by bsul-lt500.cis.neustar.com on Mon, 20 Jun 2011 08:35:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1308572047.2742.37.camel@shane-desktop> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> Date: Mon, 20 Jun 2011 08:35:01 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:35:13 -0000 At 14:14 +0200 6/20/11, Shane Kerr wrote: >While you will not get the entire zone, you'll likely still get a lot of >extra data. Your operating system will be happily filling its TCP buffer >until your application notices that it is getting a AXFR-style transfer >and then closes the connection. I really think there's a misunderstanding of the AXFR-style IXFR. Even if IXFR is on TCP, it's the same protocol that runs over UDP. I once tried to write up an AXFR over UDP and in writing the draft learned that AXFR is fundamentally unable to run over UDP. AXFR and IXFR responses are different. You don't get an AXFR response from an IXFR query. If you have an open TCP connection and see a IXFR query lead to an AXFR response, you have to see an IXFR response and AXFR query in there too - and also an SOA query/response. Of else something was mis-reporting the AXFR-style IXFR. Or maybe the IXFR server was buggy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From marka@isc.org Mon Jun 20 05:54:37 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE161F0C44 for ; Mon, 20 Jun 2011 05:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4PTdvIQ7Ibf for ; Mon, 20 Jun 2011 05:54:37 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id EF35C1F0C41 for ; Mon, 20 Jun 2011 05:54:36 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 4E745C94D8; Mon, 20 Jun 2011 12:54:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E19DB216C80; Mon, 20 Jun 2011 12:54:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id E9F9D10EF90C; Mon, 20 Jun 2011 22:54:20 +1000 (EST) To: Edward Lewis From: Mark Andrews References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> In-reply-to: Your message of "Mon, 20 Jun 2011 08:35:01 -0400." Date: Mon, 20 Jun 2011 22:54:20 +1000 Message-Id: <20110620125420.E9F9D10EF90C@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 12:54:37 -0000 In message , Edward Lewis writes: > At 14:14 +0200 6/20/11, Shane Kerr wrote: > > >While you will not get the entire zone, you'll likely still get a lot of > >extra data. Your operating system will be happily filling its TCP buffer > >until your application notices that it is getting a AXFR-style transfer > >and then closes the connection. > > I really think there's a misunderstanding of the AXFR-style IXFR. > > Even if IXFR is on TCP, it's the same protocol that runs over UDP. I > once tried to write up an AXFR over UDP and in writing the draft > learned that AXFR is fundamentally unable to run over UDP. AXFR and > IXFR responses are different. You don't get an AXFR response from an > IXFR query. They differ by the QTYPE is the question section of the response otherwise they are identical. > If you have an open TCP connection and see a IXFR query lead to an > AXFR response, you have to see an IXFR response and AXFR query in > there too - and also an SOA query/response. Of else something was > mis-reporting the AXFR-style IXFR. Or maybe the IXFR server was > buggy. The following is legal with IXFR and results in a AXFR style IXFR response. Query: 1 message Question: example.net IN IXFR Answer: example.net IN SOA 1000 .... Response: 1+ messages. Question: example.net IN IXFR Answer: example.net IN SOA 1001 .... example.net IN NS .... Answer: .... Answer: ..... example.net IN SOA 1001 .... > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > I'm overly entertained. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Mon Jun 20 06:20:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AC11F0C4A for ; Mon, 20 Jun 2011 06:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMIno+qfqHkq for ; Mon, 20 Jun 2011 06:20:21 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id F0B571F0C44 for ; Mon, 20 Jun 2011 06:20:19 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id B5D185F98EF; Mon, 20 Jun 2011 13:20:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 96F18216C81; Mon, 20 Jun 2011 13:20:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D548E10EFB6D; Mon, 20 Jun 2011 23:19:59 +1000 (EST) To: Edward Lewis From: Mark Andrews References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFB6173.5080802@nic.cz> <1308571861.2742.34.camel@shane-desktop> In-reply-to: Your message of "Mon, 20 Jun 2011 08:28:57 -0400." Date: Mon, 20 Jun 2011 23:19:59 +1000 Message-Id: <20110620131959.D548E10EFB6D@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Use case for IXFR-only, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:20:21 -0000 In message , Edward Lewis writes: > At 14:11 +0200 6/20/11, Shane Kerr wrote: > > >The reason this came up is that two operators (Ondrej and me) both > >encountered the problem in the real world and it adversely affected our > >operations. > > I get what you are saying. But was this caused by the way the tools > available worked or was there something wrong with the protocol that > forced the tools to react this way? That's my central question. It's a mixture of a known limitation of a optional extension of the protocol, configuration and how the tools work (i.e. always doing the extension). > >IXFR-only specifies that you do not want the behavior to fall back to an > >AXFR-style transfer, to avoid this issue. That's all. > > What I'm contending is that the fall back is done by an impementation > and not part of the protocol. Fallback is part of the protocol. There are 4 possible responses to a IXFR request. 1. "up to date" or "switch to TCP". 2. a delta response over UDP/TCP with optional compression. 3. a "up to date" response over TCP (response serial <= query serial). 4. a "AXFR style" response over TCP. > >In my mind, it turns IXFR into "Do What I Said" instead of "Do What You > >Think Might Be Helpful". :) > > What I began to think about, because of this thread, is that there's > no reason why server B - acting as a NOTIFY server - has to request > an IXFR from server A - acting as a NOTIFY client - but collectively > we have thought of it this way. Not that NOTIFY is the only lead > into an IXFR or AXFR, it's just one of the ways to illustrate this. The problem still exists even if the client only talks to the server that has sent the notify. > If server A tells server B "I have a new zone", the protocol does not > tell B it has to go to A for an update. It's conceivable that server > B will try to get the update from C. B can send AXFR/IXFR requests > to C without a NOTIFY (timer expiration would be one reason now). > > It sounds to me that IXFR-only is more like > try-all-possible-sources-for-IXFR-first. And that can be done in > code. Every thing is done in code. If you meant by the client, then no it can't be done by the client cleanly as the client doesn't have access to the data to do so. The server needs to make the decision on the clients behalf. > NOTIFY/IXFR/AXFR are all distinct and independent mechanisms within > the DNS architecture. They aren't necessarily linked but > implementers have linked them. It's natural to do so - I'm not > saying implementers are the cause of all evil here (although they > generally are) - but again this is is maybe just a mass adoption of a > bad assumption. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > I'm overly entertained. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ed.Lewis@neustar.biz Mon Jun 20 06:24:15 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9821F0C44 for ; Mon, 20 Jun 2011 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nXn9b9MFT3Y for ; Mon, 20 Jun 2011 06:24:04 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id ABBA31F0C37 for ; Mon, 20 Jun 2011 06:24:03 -0700 (PDT) Received: from bsul-lt500.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5KDO1jM025779; Mon, 20 Jun 2011 09:24:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.30] by bsul-lt500.cis.neustar.com (PGP Universal service); Mon, 20 Jun 2011 09:24:02 -0400 X-PGP-Universal: processed; by bsul-lt500.cis.neustar.com on Mon, 20 Jun 2011 09:24:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110620125420.E9F9D10EF90C@drugs.dv.isc.org> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> <20110620125420.E9F9D10EF90C@drugs.dv.isc.org> Date: Mon, 20 Jun 2011 09:22:07 -0400 To: Mark Andrews From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:24:19 -0000 At 22:54 +1000 6/20/11, Mark Andrews wrote: >They differ by the QTYPE is the question section of the response otherwise >they are identical. >The following is legal with IXFR and results in a AXFR style IXFR response. My assumption is that IXFR is a single query, single response message mechanism, so I would disagree with the example shown. But I can see why there's a disagreement here, based on this passage from RFC 1995. Transport of a query may be by either UDP or TCP. If an IXFR query is via UDP, the IXFR server may attempt to reply using UDP if the entire response can be contained in a single DNS packet. If the UDP reply does not fit, the query is responded to with a single SOA record of the server's current version to inform the client that a TCP query should be initiated. Thus, a client should first make an IXFR query using UDP. If the query type is not recognized by the server, an AXFR (preceded by a UDP SOA query) should be tried, ensuring backward compatibility. If the query response is a single packet with the entire new zone, or if the server does not have a newer version than the client, everything is done. Otherwise, a TCP IXFR query should be tried. When reading the first paragraph I get that IXFR is one message query, one message response ("single DNS packet"). However, the "may attempt to reply" is not correct, the RFC should read "and will reply with one of three kinds of responses." One being the "no IXFR possible", the other being the ordinary IXFR, and then the AXFR-style IXFR. BTW, the latter is not a term used in the RFC. From that I have always assumed that the IXFR response is one DNS message. Even on TCP. The second paragraph adds to the confusion over fallback. It talks about trying AXFR, but only if the IXFR is not understood. And the has one line tacked on to the end of the paragraph of TCP IXFR being tried. What needs to be fixed is how IXFR behaves on TCP. It should be limited in its resource consumption. That's what I'd go after. I suppose I never assumed an implementation try IXFR over TCP. That's why I've never seen this issue in code or operations. I think that the change here is not to cut off AXFR-stype IXFRs but to limit what a IXFR server considers an acceptable IXFR response. On TCP though you don't have a forced limit (512, EDNS0). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From wouter@nlnetlabs.nl Mon Jun 20 06:36:17 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D136911E8149 for ; Mon, 20 Jun 2011 06:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnPJwW7d6mL0 for ; Mon, 20 Jun 2011 06:36:17 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5113E11E8125 for ; Mon, 20 Jun 2011 06:36:14 -0700 (PDT) Received: from gary.nlnetlabs.nl (gary.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:1853]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id p5KDa8YU037809 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 Jun 2011 15:36:09 +0200 (CEST) (envelope-from wouter@nlnetlabs.nl) Message-ID: <4DFF4CC8.4090303@nlnetlabs.nl> Date: Mon, 20 Jun 2011 15:36:08 +0200 From: "W.C.A. Wijngaards" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Shane Kerr References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> In-Reply-To: <1308572047.2742.37.camel@shane-desktop> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Mon, 20 Jun 2011 15:36:09 +0200 (CEST) Cc: dnsext@ietf.org Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 13:36:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Shane, On 06/20/2011 02:14 PM, Shane Kerr wrote: >> What is wrong with closing the TCP socket? > > There's nothing especially wrong with that, and IIRC we did consider > this option when discussing IXFR-only over beers several years ago. So, maybe this can solve the problem. No RFC needed. > While you will not get the entire zone, you'll likely still get a lot of > extra data. Your operating system will be happily filling its TCP buffer > until your application notices that it is getting a AXFR-style transfer > and then closes the connection. Your fast-update-slave will look at this very quickly, the first bytes hold the first two records. So it'll stop the transfer after a couple msec. At 10 Mbyte per second, that is about 64k or so that was sent? > Granted this is probably only a few tens of MB at most, but I don't > think the changes on the slave side are much more complicated for > IXFR-only, and solve the problem. It is larger than the notify-only option, but 64k hardly bursts the traffic and time limits? Since it it about fast update, the close TCP socket is just as fast as ixfr-only, in ping-time, since it has to decide when the response gets back. It does have more traffic. I was asking in case the close was 'unfriendly' in an uninteroperable way. The ixfr-only option is there to look pretty? Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN/0zIAAoJEJ9vHC1+BF+N1ikQAKjIg41MST5vCpZI6u2OZx5i 0zt/2VOHPcCMNY02vQnOXlTmzPG/tehIV0WN+7JB4P3KNCRpCmI2cgmyvTu/jwb+ MqcjD8LjQTRu80BQi//FM3LgKCuCf7nIN47dRIgWwoJnCdKVNJjag6gH2i1o9zdW gZy2nNEmyqB/QdZTK1HIUJXnN/E1+SL0ObkEcxAEGGhfDYYZXWLjSfmWvMpq9Rw3 3yfRYgttDMiOdLSkuDPn4lCgjEmkviIX2QnP0UZn9l5nfF8rn03QabLj+MQNl3PK HMSXgXQ2p0A8e6ZBS/89CZn+tZdn+60KPRAfpRwP2v1hOISmyMQcCSxtjSHgS8Z3 AWly8nBZC9l7D/3ntWxzkZg1HOzfjus1KQzuc5WQt5x3zpBe0B1KtgiXNl7D0RRH 019mWp0Pa0Xk1d5QKRfoBXZGEJUeJsyUo3EMiSEW8B7VCZHEKfsVPowiwvV08Uba hRSqe8eVq3MwKn+ED6s9QoBjfX8TvWNaaMhr0mI8uFkJPpfskeNXpt6qYehw2Q2b yXMUHCprq/Ee3NvKUDfK1dcSkWhij+Nf6dXiFGP8CdOjjd3oRmUgGZl+IWWHihwu JxmwnipRIwa9usXav3qFIIcBO6FW4ehhUIijxF1tmUoZJ7N7nPWe+BMsDxglLOSL 4FjvvRWQTlGGXXE7Hfmq =HN3q -----END PGP SIGNATURE----- From joshl@cisco.com Mon Jun 20 11:31:38 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D920711E81D4 for ; Mon, 20 Jun 2011 11:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UtbTg+GuYKC for ; Mon, 20 Jun 2011 11:31:38 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id ECB0411E81D3 for ; Mon, 20 Jun 2011 11:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=joshl@cisco.com; l=2205; q=dns/txt; s=iport; t=1308594697; x=1309804297; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Th+M9Dy4Iu4bA5fke8ChZ/POPsio36GRtrIThso1AgY=; b=N+tyso6BhC0AIb9QUR6rRnJRWXpO4UrUqEoHuLW52+b2znT3vWsSruYU TLbCBnveqOX8yxyDKdwzTpDuEuevPTw0bLhzOwuQg4th6dkFoC7n+xl9Q hHdjnvYCyVIimK4gQ1ILzRASIRPyPgTlGyzJPBzGUAj7idmDpixBBkxL+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANaR/02tJV2c/2dsb2JhbABNBqZid4hzoWWeCQKDNYJzBJFehGCLPQ X-IronPort-AV: E=Sophos;i="4.65,395,1304294400"; d="scan'208";a="287764323" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 20 Jun 2011 18:31:26 +0000 Received: from [161.44.71.232] ([161.44.71.232]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5KIVPsj031353; Mon, 20 Jun 2011 18:31:25 GMT Message-ID: <4DFF91FD.9010508@cisco.com> Date: Mon, 20 Jun 2011 14:31:25 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Edward Lewis References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> <20110620125420.E9F9D10EF90C@drugs.dv.isc.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 18:31:39 -0000 On 6/20/2011 9:22 AM, Edward Lewis wrote: > At 22:54 +1000 6/20/11, Mark Andrews wrote: > >> They differ by the QTYPE is the question section of the response >> otherwise >> they are identical. > >> The following is legal with IXFR and results in a AXFR style IXFR >> response. > > My assumption is that IXFR is a single query, single response message > mechanism, so I would disagree with the example shown. But I can see > why there's a disagreement here, based on this passage from RFC 1995. That assumption is incorrect over TCP. Whether communicating deltas, or communicating an "AXFR-style" full zone response, IXFR can be multiple packets over TCP. The "framing" of the response data into packets for IXFR and AXFR is the same. And the difference between IXFR's use of UDP and TCP is just the ability to use message framing in TCP. Unfortunately RFC 1995 spells that out no more clearly than RFC 1034, but we've had interoperable implementations that understood the proper framing of IXFR for more than a decade. > > I think that the change here is not to cut off AXFR-stype IXFRs but to > limit what a IXFR server considers an acceptable IXFR response. On TCP > though you don't have a forced limit (512, EDNS0). I don't see why you would limit anything. TCP framing does have a per-message limit of 16K, due to the 2-byte length field. But IXFR already easily supports sending the full zone response, and there is nothing wrong with that. The issue addressed by the draft in question is that you might sometimes prefer not to get that response (when the zone has 1M RRs) until you've exhausted other potential sources of changesets. Since you can tell the difference between a delta response and a full response by the second answer section record, it is currently possible to just shut the TCP connection if the response is not the type you prefer. That's a bit ugly, and the server sees it as an aborted IXFR. -josh -- Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue Phone: +1 978-936-0001 Boxborough, MA 01719-2205 From joshl@cisco.com Mon Jun 20 11:44:10 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34BE21F8563 for ; Mon, 20 Jun 2011 11:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaKpHpPBp0Qv for ; Mon, 20 Jun 2011 11:44:10 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id E7DC221F8562 for ; Mon, 20 Jun 2011 11:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=joshl@cisco.com; l=558; q=dns/txt; s=iport; t=1308595450; x=1309805050; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PhwBh5w2MwCIhoh/c32216nWddfTLN9Nft+VjbCcgEI=; b=KNha501Clyu1+fsnMVSoM0XFT+RQez0Ob0/EKmTIm9praj3RTX/cpAat TkxFFZ0lfhDcQEZK0OZ9yOR1/kKFvgG2I1804u3qjNPuQ9QQ/9AJqu8TX fWUGlDYfp5f3ELcFMNANUe6cALMM/jZYZDuUDPrlq40HIY83m83t+gm2c s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN2T/02tJXHB/2dsb2JhbABNBqZid6pingYCgzWCcwSRXoRgiz0 X-IronPort-AV: E=Sophos;i="4.65,395,1304294400"; d="scan'208";a="237493193" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-2.cisco.com with ESMTP; 20 Jun 2011 18:44:08 +0000 Received: from [161.44.71.232] ([161.44.71.232]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p5KIi7bT004134; Mon, 20 Jun 2011 18:44:08 GMT Message-ID: <4DFF94F7.7050001@cisco.com> Date: Mon, 20 Jun 2011 14:44:07 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Edward Lewis References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> <20110620125420.E9F9D10EF90C@drugs.dv.isc.org> <4DFF91FD.9010508@cisco.com> In-Reply-To: <4DFF91FD.9010508@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 18:44:10 -0000 On 6/20/2011 2:31 PM, Josh Littlefield wrote: > > I don't see why you would limit anything. TCP framing does have a > per-message limit of 16K, due to the 2-byte length field. But IXFR > already easily supports sending the full zone response, and there is > nothing wrong with that. FYI: Of course, I meant 64K above. -josh -- Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue Phone: +1 978-936-0001 Boxborough, MA 01719-2205 From vixie@isc.org Mon Jun 20 14:44:19 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE2611E80C5 for ; Mon, 20 Jun 2011 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eSKCJOwKHqb for ; Mon, 20 Jun 2011 14:44:19 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4B89611E808E for ; Mon, 20 Jun 2011 14:44:19 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id C4E01A1051 for ; Mon, 20 Jun 2011 21:44:15 +0000 (UTC) (envelope-from vixie@isc.org) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 9D14CA103E for ; Mon, 20 Jun 2011 21:44:15 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org In-Reply-To: Your message of "Mon, 20 Jun 2011 14:44:07 -0400." <4DFF94F7.7050001@cisco.com> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> <20110620125420.E9F9D10EF90C@drugs.dv.isc.org> <4DFF91FD.9010508@cisco.com> <4DFF94F7.7050001@cisco.com> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 20 Jun 2011 21:44:15 +0000 Message-ID: <5234.1308606255@nsa.vix.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 21:44:20 -0000 > Date: Mon, 20 Jun 2011 14:44:07 -0400 > From: Josh Littlefield > > On 6/20/2011 2:31 PM, Josh Littlefield wrote: > > I don't see why you would limit anything. TCP framing does have a > > per-message limit of 16K, due to the 2-byte length field. But IXFR > > already easily supports sending the full zone response, and there is > > nothing wrong with that. > > FYI: Of course, I meant 64K above. in fairness to you, anything above 16K is useless, since compression pointers are only 14 bits in size. the change in header amortization if you go above 16K is negligible compared to the loss of compression reach. so while you didn't mean 16K, it's actually a good TCP/53 limit for things like IXFR/AXFR. From Ed.Lewis@neustar.biz Mon Jun 20 15:12:42 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D699E8045 for ; Mon, 20 Jun 2011 15:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.191 X-Spam-Level: X-Spam-Status: No, score=-106.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KncRUoTPicdP for ; Mon, 20 Jun 2011 15:12:42 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC1228015 for ; Mon, 20 Jun 2011 15:12:40 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5KMCTmM029552; Mon, 20 Jun 2011 18:12:31 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.104] by Work-Laptop-2.local (PGP Universal service); Mon, 20 Jun 2011 18:12:36 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 20 Jun 2011 18:12:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DFF91FD.9010508@cisco.com> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> <20110620125420.E9F9D10EF90C@drugs.dv.isc.org> <4DFF91FD.9010508@cisco.com> Date: Mon, 20 Jun 2011 18:08:40 -0400 To: Josh Littlefield From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 22:12:43 -0000 At 14:31 -0400 6/20/11, Josh Littlefield wrote: >Unfortunately RFC 1995 spells that out no more clearly than RFC 1034, >but we've had interoperable implementations that understood the proper >framing of IXFR for more than a decade. Well, that clears things up. I then prefer leaving the IXFR-only proposal as is in the draft. Slamming the connection closed seems wasteful, especially in the cases when you may have already received the whole zone while deciding to look elsewhere. I don't think there's text that needs fixing. What got me was that I see IXFR as a UDP thing and think of it in constrained environments. The last paragraph of section 5 talks more (than RFC 1995 did) about IXFR over TCP. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From mohta@necom830.hpcl.titech.ac.jp Mon Jun 20 20:10:55 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCDF11E8071 for ; Mon, 20 Jun 2011 20:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebLjCgTP82y3 for ; Mon, 20 Jun 2011 20:10:54 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 0A36411E809A for ; Mon, 20 Jun 2011 20:10:53 -0700 (PDT) Received: (qmail 45652 invoked from network); 21 Jun 2011 03:20:15 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jun 2011 03:20:15 -0000 Message-ID: <4E000B93.3030306@necom830.hpcl.titech.ac.jp> Date: Tue, 21 Jun 2011 12:10:11 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian Dickson References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 03:10:55 -0000 Brian Dickson wrote: > However, the rare time that it can't, IXFR-ONLY is important to have, > to avoid fallback. OK. >>> The MCP can tell each DS to purge its IXFR database. >> never purge purposelessly. > Exactly. Thank you for demonstrating that you understand what I wrote. > (I realize that understand is not synonymous with agree.) Are you saying that: 1) plain IXFR is fine 2) some operators can't properly operate a little complicated IXFR with a dial to tweak purge behavior, which rarely causes bandwidth inefficient IXFR. 3) to help the poor operators, yet another dial to tweak IXFR behavior MUST be added ? Shane Kerr wrote: > The reason this came up is that two operators (Ondrej and me) both > encountered the problem in the real world and it adversely affected > our operations. Are your examples essentially different from Brian Dickson's? Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Mon Jun 20 20:10:59 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CF811E811C for ; Mon, 20 Jun 2011 20:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd6u5yKPmwE7 for ; Mon, 20 Jun 2011 20:10:59 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id A4E3511E8100 for ; Mon, 20 Jun 2011 20:10:57 -0700 (PDT) Received: (qmail 45657 invoked from network); 21 Jun 2011 03:20:40 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jun 2011 03:20:40 -0000 Message-ID: <4E000BAC.70000@necom830.hpcl.titech.ac.jp> Date: Tue, 21 Jun 2011 12:10:36 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> <20110620125420.E9F9D10EF90C@drugs.dv.isc.org> <4DFF91FD.9010508@cisco.com> In-Reply-To: <4DFF91FD.9010508@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 03:10:59 -0000 Josh Littlefield wrote: > The "framing" of the response data into packets for > IXFR and AXFR is the same. And the difference between IXFR's use of UDP > and TCP is just the ability to use message framing in TCP. > > Unfortunately RFC 1995 spells that out no more clearly than RFC 1034, It was intentional, because I didn't want to be involved in a discussion on how AXFR should be clarified only to delay publication of IXFR. > but we've had interoperable implementations that understood the proper > framing of IXFR for more than a decade. With RFC1995, anyone who can implement AXFR should be able to implement IXFR, which should be just enough as an incremental specification. :-) Masataka Ohta From george.barwood@blueyonder.co.uk Tue Jun 21 00:57:53 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D2811E80F0 for ; Tue, 21 Jun 2011 00:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKgtupVBqynk for ; Tue, 21 Jun 2011 00:57:53 -0700 (PDT) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by ietfa.amsl.com (Postfix) with ESMTP id F397A11E80BD for ; Tue, 21 Jun 2011 00:57:52 -0700 (PDT) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.2]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110621075744.PGZL16165.mtaout02-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net> for ; Tue, 21 Jun 2011 08:57:44 +0100 Received: from [82.46.65.24] (helo=GeorgeLaptop) by know-smtpout-4.server.virginmedia.net with smtp (Exim 4.63) (envelope-from ) id 1QYvqC-00035s-Oa for dnsext@ietf.org; Tue, 21 Jun 2011 08:57:44 +0100 Message-ID: <396B6F93A3774482A4DFAFD458C56BA0@local> From: "George Barwood" To: Date: Tue, 21 Jun 2011 08:57:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=3NElcqgl2aoA:10 a=8nJEP1OIZ-IA:10 a=48vgC7mUAAAA:8 a=OZkxgivlXquplG-npk8A:9 a=wPNLvfGTeEIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 07:57:53 -0000 VGhlIEROU0tFWSBSUnNldCBmb3IgdGhlIC51cy4gVExEIGN1cnJlbnRseSBoYXMgYW4gdXBwZXIt Y2FzZSBzaWduZXIgbmFtZSBmb3Igb25lIG9mIHRoZSBzaWduYXR1cmVzLg0KDQpkaWcgZG5za2V5 IHVzIEBhLmNjdGxkLnVzICtkbnNzZWMNCg0KLi4NCg0KdXMuICA1MTg0MDAgIElOICAgICAgUlJT SUcgICBETlNLRVkgNSAxIDUxODQwMCAyMDExMDcxMDEwMDAwMA0KIDIwMTEwNjEwMDkwMDAwIDIw NTggVVMuIFpyNk5qSHV3a055RklEZ2l4Rm1wTGpFdERyYlBTY2kwWUx1UnFNZ2xVOUV4cHVIdTQy QjdjLzUNCmYgaDdlRWU5MDlDbTlrSmJsbUNOM0dWbEYzQWVOcFdMZDEzMjBvdWtmSmtMdzhaaStz aDYzVE40N3YgdUhCWnlqdkhmNUt5QWd1dkwvVzcrDQpxb1FJRWNmVlV6aEFIaDR5SlBteWpnbWFm MXlmUCtmS1lUeCA4UER6R1dydWJqa0lJdHNCVkpCdlgwdWwyU2dkKzduRndNL281WVdmMDg5Ug0K VGhjK2VVOURlby9aIDdXbVlnTjdVVzZkVFB6eitMaS9ic2xqU2tDUWs2SlpBa2tCbE1RbGp0dnZM ZnFEUXYzN3hOdWxTIGhCZ2xEZVVpYXQNCktscDltcTFoc3hOQ3ZsT2NBZzhFNldScnlTblRTZkFX emR6azlvNDN1bmpIZjQgc0ZvdEdnPT0NCg0KSXQgc2VlbXMgdGhhdCB0aGUgc2lnbmVyIG5hbWUg aGFzIHRvIGJlIGRvd24tY2FzZWQgZm9yIHRoaXMgc2lnbmF0dXJlIHRvIHZlcmlmeS4NCg0KSG93 ZXZlciB0aGlzIGlzIGNvbnRyYXJ5IHRvIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtZG5zZXh0LWRuc3NlYy1iaXMtdXBkYXRlcy0xMiNzZWN0aW9uLTUuMQ0KDQogICBXaGVu IGNhbm9uaWNhbGl6aW5nIEROUyBuYW1lcywgRE5TIG5hbWVzIGluIHRoZSBSREFUQSBzZWN0aW9u IG9mIE5TRUMNCiAgIGFuZCBSUlNJRyByZXNvdXJjZSByZWNvcmRzIGFyZSBub3QgZG93bmNhc2Vk Lg0KDQpCdXQgZXhpc3RpbmcgdmFsaWRhdG9ycyBkb24ndCBmYWlsLCBzbyBpdCBzZWVtcyB0aGV5 IGRvIGRvd24tY2FzZS4NCg0KSGVuY2UgSSdtIGNvbmZ1c2VkLiBJcyBkbnNzZWMtYmlzLXVwZGF0 ZXMgIndyb25nIj8gDQoNCkdlb3JnZQ0KDQo= From fweimer@bfk.de Tue Jun 21 04:48:59 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3168311E808D for ; Tue, 21 Jun 2011 04:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui4MECUVDXtE for ; Tue, 21 Jun 2011 04:48:58 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3962311E80D4 for ; Tue, 21 Jun 2011 04:48:58 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QYzRr-0004EM-Qw; Tue, 21 Jun 2011 11:48:51 +0000 Received: by bfk.de with local id 1QYzRr-0000ZA-HS; Tue, 21 Jun 2011 11:48:51 +0000 From: Florian Weimer To: Shane Kerr References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop> Date: Tue, 21 Jun 2011 11:48:51 +0000 In-Reply-To: <1308572047.2742.37.camel@shane-desktop> (Shane Kerr's message of "Mon, 20 Jun 2011 14:14:07 +0200") Message-ID: <82mxhb5rrw.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 11:48:59 -0000 * Shane Kerr: > While you will not get the entire zone, you'll likely still get a lot of > extra data. Your operating system will be happily filling its TCP buffer > until your application notices that it is getting a AXFR-style transfer > and then closes the connection. Is it possible to reach that conclusion early during the connection? Would the window be fully opened at that point? Anyway, if you close a socket while there is pending data to read, modern TCP implementations are expected to abort the connection. So all that data will be discarded, and the sender can be notified before the data currently in flight is acknowledged. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Ed.Lewis@neustar.biz Tue Jun 21 06:38:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4176911E8096 for ; Tue, 21 Jun 2011 06:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.213 X-Spam-Level: X-Spam-Status: No, score=-106.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmowqCN+1OhC for ; Tue, 21 Jun 2011 06:38:23 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0193111E809F for ; Tue, 21 Jun 2011 06:38:22 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5LDcI5s035169; Tue, 21 Jun 2011 09:38:19 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.119] by Work-Laptop-2.local (PGP Universal service); Tue, 21 Jun 2011 09:38:19 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 21 Jun 2011 09:38:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <396B6F93A3774482A4DFAFD458C56BA0@local> References: <396B6F93A3774482A4DFAFD458C56BA0@local> Date: Tue, 21 Jun 2011 09:38:10 -0400 To: George Barwood From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:38:24 -0000 At 8:57 +0100 6/21/11, George Barwood wrote: >It seems that the signer name has to be down-cased for this >signature to verify. > >However this is contrary to >http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.1 > > When canonicalizing DNS names, DNS names in the RDATA section of NSEC > and RRSIG resource records are not downcased. > >But existing validators don't fail, so it seems they do down-case. > >Hence I'm confused. Is dnssec-bis-updates "wrong"? This discussion came up recently on some list. The answer is that the case doesn't matter, uh, in this case. The only time a domain name in the RDATA has to be down cased is when it can be compressed. The reason is - without compression, the RR will appear in a response the same as it was generated (outside of forgeries, which is what DNSSEC is about). With compression, the case used for the domain name in the RDATA depends on what comes first in the response. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From Ed.Lewis@neustar.biz Tue Jun 21 06:52:41 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44F911E814A for ; Tue, 21 Jun 2011 06:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.234 X-Spam-Level: X-Spam-Status: No, score=-106.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akaXleF6o1wJ for ; Tue, 21 Jun 2011 06:52:41 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id EA1EF11E8148 for ; Tue, 21 Jun 2011 06:52:40 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5LDqXrj035268; Tue, 21 Jun 2011 09:52:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.119] by Work-Laptop-2.local (PGP Universal service); Tue, 21 Jun 2011 09:52:37 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 21 Jun 2011 09:52:37 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E000B93.3030306@necom830.hpcl.titech.ac.jp> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> Date: Tue, 21 Jun 2011 09:52:31 -0400 To: Masataka Ohta From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 13:52:41 -0000 At 12:10 +0900 6/21/11, Masataka Ohta wrote: > 3) to help the poor operators, yet another dial to tweak IXFR > behavior MUST be added Ohta-san, Times have changed since the days of RFC 1995, the requirements have changed. Although the network has seen an increase in capacity (bits per second) the distance between endpoints has actually increased (we send zones further and further from home). In addition the size of zones has grown greatly and the number of large zones has grown greatly. I know that 15 years ago, even COM was under a million records. Now a million records is an average sized TLD. And thanks to dynamic update (which was published after RFC 1995), the role of IXFR has grown to surpass AXFR as the standard transfer mechanism. It makes sense for a server, when told there is a new version, to do what it can to efficiently seek a new version. It makes sense that a server would, when it knows that there is a new version to be had, contact all the places where it can get just the update before locking on to an AXFR. From a recovery perspective, what if the master server loses it's increment memory and cannot do AXFR? Each slave might be called on to do AXFRs when it would be more efficient for one slave to do the AXFR and then answer IXFR requests until the system stabilizes. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From mohta@necom830.hpcl.titech.ac.jp Tue Jun 21 08:09:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0756A21F8595 for ; Tue, 21 Jun 2011 08:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np-32miR6JRK for ; Tue, 21 Jun 2011 08:09:22 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 38FD821F8594 for ; Tue, 21 Jun 2011 08:09:22 -0700 (PDT) Received: (qmail 51715 invoked from network); 21 Jun 2011 15:19:06 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jun 2011 15:19:06 -0000 Message-ID: <4E00B3F2.9030204@necom830.hpcl.titech.ac.jp> Date: Wed, 22 Jun 2011 00:08:34 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Edward Lewis References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:09:23 -0000 Edward Lewis wrote: >> 3) to help the poor operators, yet another dial to tweak IXFR >> behavior MUST be added > > Ohta-san, > > Times have changed since See 2) to see an example of the current situation. > And thanks to dynamic update (which was published after RFC 1995), the > role of IXFR has grown to surpass AXFR as the standard transfer mechanism. I'm afraid you don't know the history of DNSIND. > From a recovery perspective, what if the master server loses it's > increment memory and cannot do AXFR? Each slave might be called on to do > AXFRs when it would be more efficient for one slave to do the AXFR and > then answer IXFR requests until the system stabilizes. What if what? Masataka Ohta From Ed.Lewis@neustar.biz Tue Jun 21 08:37:51 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315C511E8268 for ; Tue, 21 Jun 2011 08:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.252 X-Spam-Level: X-Spam-Status: No, score=-106.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhqEemQ8TALm for ; Tue, 21 Jun 2011 08:37:50 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 450E311E807E for ; Tue, 21 Jun 2011 08:37:50 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5LFblX8036148; Tue, 21 Jun 2011 11:37:48 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.204.119] by Work-Laptop-2.local (PGP Universal service); Tue, 21 Jun 2011 11:37:48 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 21 Jun 2011 11:37:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E00B3F2.9030204@necom830.hpcl.titech.ac.jp> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <4E00B3F2.9030204@necom830.hpcl.titech.ac.jp> Date: Tue, 21 Jun 2011 11:33:49 -0400 To: Masataka Ohta From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:37:51 -0000 At 0:08 +0900 6/22/11, Masataka Ohta wrote: >See 2) to see an example of the current situation. It would be a real shame to make something operationally smooth, eh? >> And thanks to dynamic update (which was published after RFC 1995), the >> role of IXFR has grown to surpass AXFR as the standard transfer mechanism. > >I'm afraid you don't know the history of DNSIND. RFC 1995 - August 1996 RFC 2136 - April 1997. Didn't say that they weren't discussed closely in time, just referenced the publish date. >> From a recovery perspective, what if the master server loses it's >> increment memory and cannot do AXFR? Each slave might be called on to do >> AXFRs when it would be more efficient for one slave to do the AXFR and >> then answer IXFR requests until the system stabilizes. > >What if what? "Each slave might be called on to do AXFRs when it would be more efficient for one slave to do the AXFR and then answer IXFR requests until the system stabilizes." Which is what happens today. The desire is to make it better. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From rdroms.ietf@gmail.com Tue Jun 21 11:01:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42A611E80E9; Tue, 21 Jun 2011 11:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JiwFtoznac4; Tue, 21 Jun 2011 11:01:28 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EED8411E809C; Tue, 21 Jun 2011 11:01:27 -0700 (PDT) Received: by qwc23 with SMTP id 23so11635qwc.31 for ; Tue, 21 Jun 2011 11:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=kdimksgSaKOoy2rPp3VrtkRg0+Kz8JL6yfnJiJTdyXg=; b=a7ailyFFRhhMLvja/kehBHpeURtaC34dknhFwA1oHTmtd5v10amF59K941CUxm1WO4 AEHaZwp0vvQ3NFO3doQvNQ/CMB6nLCC8Pv7KiDxqLFGG2QzVoAk3WC6+iJpbG5lmDFBM MUfpZKnNf0bWe0Qw57B+HPQLJLG1mWdoWSnvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=RItU63H25bvgQXNtZjeQxrZvW81Fdab0d1t0OyQ8DTSNdgnOQmN3DpijdWbY5kzBJV bFMqYEZugvBn+MiUAAWbC2CtjLjFZWvyTuy4Gd64PkMenOmV31pbKxeE9b8C5NzEg21u 7UVatqFIXFEezwxG/+kjfGo4fEQ95AxLwX9zc= Received: by 10.224.186.76 with SMTP id cr12mr5461963qab.274.1308679287314; Tue, 21 Jun 2011 11:01:27 -0700 (PDT) Received: from [161.44.65.177] ([161.44.65.177]) by mx.google.com with ESMTPS id p10sm5098573qcu.13.2011.06.21.11.01.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 11:01:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <20110607212859.3057.86566.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2011 14:01:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1C91AB97-41DC-4F45-89BD-72A2689ABD9A@gmail.com> References: <20110607212859.3057.86566.idtracker@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dnsext-dnssec-registry-fixes@tools.ietf.org, dnsext-chairs@tools.ietf.org, dnsext@ietf.org, Ralph Droms , The IESG Subject: Re: [dnsext] Robert Sparks' Discuss on draft-ietf-dnsext-dnssec-registry-fixes-08: (with DISCUSS) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 18:01:28 -0000 Robert - following up on your suggestion, for which there seems to be = some consensus of support in the IESG, I have a couple of questions in = line. I'd like to get additional dnsext feedback on the proposed updates to = the document. - Ralph On Jun 7, 2011, at 5:28 PM 6/7/11, Robert Sparks wrote: > Robert Sparks has entered the following ballot position for > draft-ietf-dnsext-dnssec-registry-fixes-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Would the following approach achieve the goals the working group = desires with this document? >=20 > Instead of keeping the Compliance information in the IANA registry as = a new column, keep it entirely within this RFC. Add a sentence to the = registry that says "See RFCXXXX for the IETF Consensus on which subset = of these algorithms are required or recommended to implement or avoid."=20= >=20 > The RFC could then say that any changes to the RFC affecting that = column should be done through obsoleting the RFC, replacing it with a = new one. Do you intend an RFC 2119 SHOULD in this sentence? The separation you suggest would, if I understand RFC 6014 and the first = paragraph of section 2.3 of dnsext-dnssec-registry-fixes correctly, = avoid the problem of the IANA registry and the most recent RFC registry = getting out of sync because of additions to the IANA registry through = RFC 6014 that did not require obsoleting dnsext-dnssec-registry-fixes. > That way, you would have a single document to refer to for = conformance purposes, and a clear history of what changes were made. = This would avoid Pete's concerns with the potential unintended = consequences of the new proposed mechanics for maintaining the registry. I don't see how this process does any more to capture the history of = changes than the process currently in the doc. In either case, I think = there needs to be some explicit requirement in the RFC that the reasons = for any changes in the implementation requirements MUST be documented in = the RFC (although this requirement still requires chasing a chain of = RFCs for the entire history of the implementation requirements). > It would also avoid an issue I have with the sentence that tries to = constrain any updates to this RFC to _only_ use the obsoletes mechanism. = It allows the working group to maintain any changes by only using a = series of obsoletes, and guides future maintainers should the working = group go away. As long as the consensus was to only use obsoletes, = that's exactly what will happen. If IETF consensus changes in the = future, it would override any attempt to constrain the document = maintenance anyway. Hence the SHOULD above? >=20 > If a path like this was considered and rejected, documenting what it = wouldn't achieve would help motivate the current proposal. Agreed. >=20 >=20 >=20 >=20 >=20 From rjsparks@nostrum.com Tue Jun 21 11:28:42 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DCC11E80E9; Tue, 21 Jun 2011 11:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpxuRF30hc5X; Tue, 21 Jun 2011 11:28:41 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by ietfa.amsl.com (Postfix) with ESMTP id 2028E11E808A; Tue, 21 Jun 2011 11:28:40 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p5LIRHJM016431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Jun 2011 13:27:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <1C91AB97-41DC-4F45-89BD-72A2689ABD9A@gmail.com> Date: Tue, 21 Jun 2011 13:27:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4648550A-80C2-4A8C-9303-C7008AA9199B@nostrum.com> References: <20110607212859.3057.86566.idtracker@ietfa.amsl.com> <1C91AB97-41DC-4F45-89BD-72A2689ABD9A@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 21 Jun 2011 11:50:50 -0700 Cc: The IESG , dnsext-chairs@tools.ietf.org, dnsext@ietf.org, draft-ietf-dnsext-dnssec-registry-fixes@tools.ietf.org Subject: Re: [dnsext] Robert Sparks' Discuss on draft-ietf-dnsext-dnssec-registry-fixes-08: (with DISCUSS) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 18:28:42 -0000 On Jun 21, 2011, at 1:01 PM, Ralph Droms wrote: > Robert - following up on your suggestion, for which there seems to be = some consensus of support in the IESG, I have a couple of questions in = line. >=20 > I'd like to get additional dnsext feedback on the proposed updates to = the document. >=20 > - Ralph >=20 > On Jun 7, 2011, at 5:28 PM 6/7/11, Robert Sparks wrote: >=20 >> Robert Sparks has entered the following ballot position for >> draft-ietf-dnsext-dnssec-registry-fixes-08: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Would the following approach achieve the goals the working group = desires with this document? >>=20 >> Instead of keeping the Compliance information in the IANA registry as = a new column, keep it entirely within this RFC. Add a sentence to the = registry that says "See RFCXXXX for the IETF Consensus on which subset = of these algorithms are required or recommended to implement or avoid."=20= >>=20 >> The RFC could then say that any changes to the RFC affecting that = column should be done through obsoleting the RFC, replacing it with a = new one. >=20 > Do you intend an RFC 2119 SHOULD in this sentence? I didn't. I can see how you might want to use 2119, but I don't think it = actually helps.=20 >=20 > The separation you suggest would, if I understand RFC 6014 and the = first paragraph of section 2.3 of dnsext-dnssec-registry-fixes = correctly, avoid the problem of the IANA registry and the most recent = RFC registry getting out of sync because of additions to the IANA = registry through RFC 6014 that did not require obsoleting = dnsext-dnssec-registry-fixes. >=20 >> That way, you would have a single document to refer to for = conformance purposes, and a clear history of what changes were made. = This would avoid Pete's concerns with the potential unintended = consequences of the new proposed mechanics for maintaining the registry. >=20 > I don't see how this process does any more to capture the history of = changes than the process currently in the doc. In either case, I think = there needs to be some explicit requirement in the RFC that the reasons = for any changes in the implementation requirements MUST be documented in = the RFC (although this requirement still requires chasing a chain of = RFCs for the entire history of the implementation requirements). >=20 >> It would also avoid an issue I have with the sentence that tries to = constrain any updates to this RFC to _only_ use the obsoletes mechanism. = It allows the working group to maintain any changes by only using a = series of obsoletes, and guides future maintainers should the working = group go away. As long as the consensus was to only use obsoletes, = that's exactly what will happen. If IETF consensus changes in the = future, it would override any attempt to constrain the document = maintenance anyway. >=20 > Hence the SHOULD above? Again, I don't see how it helps, but if you really feel the need to = invoke 2119 here, SHOULD is closer in spirit than MUST. I think this would be healthier (more likely to produce the long term = results the group wants) expressed as guidance to future maintainers = rather than restrictions on process. That said, I won't object if you choose to use 2119. >=20 >>=20 >> If a path like this was considered and rejected, documenting what it = wouldn't achieve would help motivate the current proposal. >=20 > Agreed. >=20 >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From rdroms.ietf@gmail.com Tue Jun 21 12:18:48 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C921F0C4F; Tue, 21 Jun 2011 12:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEuqG5ZNYHCW; Tue, 21 Jun 2011 12:18:47 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 501AD1F0C46; Tue, 21 Jun 2011 12:18:47 -0700 (PDT) Received: by qyk29 with SMTP id 29so64097qyk.10 for ; Tue, 21 Jun 2011 12:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=m827M/LcQgIsGHGgFEqQIZwSqwTTI9ZNuXe2G2aIFhs=; b=MxHSJXX+yiESYrKwZ1uXLCsdO2KUEwcHpZcLJUunrX1ckCijxVxuN58EYjXniv4T5U uydfF3iUfpBuGHhp5LD6OufsM9TRcuzYMNn/diieTCnvWo34B5+y0MUMBpVO7dTO9Mqg S4vTrAEVUyxbJuyGD92wl97hj65T/vTgJVIGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=N+mA6pb/uXlC/Is2YQhlqiUSe2h1JMziD9hUIh0csESHP5hGJVSh1//d4tO+EtHn7f /OFNgTP3LqpyaruTrJOd/HhJ+pje4DB7hfF5OYsbTezNtMHLPtNAqDb0eYXaY3Kifn9y gMIYvZrfVo5H9Pxp+GO0SD2ioPykyj0zxs8Jk= Received: by 10.229.106.69 with SMTP id w5mr5662806qco.41.1308683918292; Tue, 21 Jun 2011 12:18:38 -0700 (PDT) Received: from [161.44.65.177] ([161.44.65.177]) by mx.google.com with ESMTPS id t21sm3412677qcs.38.2011.06.21.12.18.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 12:18:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <4648550A-80C2-4A8C-9303-C7008AA9199B@nostrum.com> Date: Tue, 21 Jun 2011 15:18:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93AA1822-C34C-4585-9D38-866746B95A0E@gmail.com> References: <20110607212859.3057.86566.idtracker@ietfa.amsl.com> <1C91AB97-41DC-4F45-89BD-72A2689ABD9A@gmail.com> <4648550A-80C2-4A8C-9303-C7008AA9199B@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-dnsext-dnssec-registry-fixes@tools.ietf.org, dnsext-chairs@tools.ietf.org, dnsext@ietf.org, Ralph Droms , The IESG Subject: Re: [dnsext] Robert Sparks' Discuss on draft-ietf-dnsext-dnssec-registry-fixes-08: (with DISCUSS) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:18:48 -0000 On Jun 21, 2011, at 2:27 PM 6/21/11, Robert Sparks wrote: >=20 > On Jun 21, 2011, at 1:01 PM, Ralph Droms wrote: >=20 >> Robert - following up on your suggestion, for which there seems to be = some consensus of support in the IESG, I have a couple of questions in = line. >>=20 >> I'd like to get additional dnsext feedback on the proposed updates to = the document. >>=20 >> - Ralph >>=20 >> On Jun 7, 2011, at 5:28 PM 6/7/11, Robert Sparks wrote: >>=20 >>> Robert Sparks has entered the following ballot position for >>> draft-ietf-dnsext-dnssec-registry-fixes-08: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> Would the following approach achieve the goals the working group = desires with this document? >>>=20 >>> Instead of keeping the Compliance information in the IANA registry = as a new column, keep it entirely within this RFC. Add a sentence to the = registry that says "See RFCXXXX for the IETF Consensus on which subset = of these algorithms are required or recommended to implement or avoid."=20= >>>=20 >>> The RFC could then say that any changes to the RFC affecting that = column should be done through obsoleting the RFC, replacing it with a = new one. >>=20 >> Do you intend an RFC 2119 SHOULD in this sentence? >=20 > I didn't. I can see how you might want to use 2119, but I don't think = it actually helps. OK, agreed... > =20 >>=20 >> The separation you suggest would, if I understand RFC 6014 and the = first paragraph of section 2.3 of dnsext-dnssec-registry-fixes = correctly, avoid the problem of the IANA registry and the most recent = RFC registry getting out of sync because of additions to the IANA = registry through RFC 6014 that did not require obsoleting = dnsext-dnssec-registry-fixes. >>=20 >>> That way, you would have a single document to refer to for = conformance purposes, and a clear history of what changes were made. = This would avoid Pete's concerns with the potential unintended = consequences of the new proposed mechanics for maintaining the registry. >>=20 >> I don't see how this process does any more to capture the history of = changes than the process currently in the doc. In either case, I think = there needs to be some explicit requirement in the RFC that the reasons = for any changes in the implementation requirements MUST be documented in = the RFC (although this requirement still requires chasing a chain of = RFCs for the entire history of the implementation requirements). >>=20 >>> It would also avoid an issue I have with the sentence that tries to = constrain any updates to this RFC to _only_ use the obsoletes mechanism. = It allows the working group to maintain any changes by only using a = series of obsoletes, and guides future maintainers should the working = group go away. As long as the consensus was to only use obsoletes, = that's exactly what will happen. If IETF consensus changes in the = future, it would override any attempt to constrain the document = maintenance anyway. >>=20 >> Hence the SHOULD above? >=20 > Again, I don't see how it helps, but if you really feel the need to = invoke 2119 here, SHOULD is closer in spirit than MUST. > I think this would be healthier (more likely to produce the long term = results the group wants) expressed as guidance to future maintainers = rather than restrictions on process. > That said, I won't object if you choose to use 2119. Right, we can work out some text that gives guidance and motivates that = guidance. - Ralph >=20 >>=20 >>>=20 >>> If a path like this was considered and rejected, documenting what it = wouldn't achieve would help motivate the current proposal. >>=20 >> Agreed. >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From mohta@necom830.hpcl.titech.ac.jp Tue Jun 21 14:48:26 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BE911E813B for ; Tue, 21 Jun 2011 14:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1XIO50oLLCr for ; Tue, 21 Jun 2011 14:48:25 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 4A8F211E812C for ; Tue, 21 Jun 2011 14:48:25 -0700 (PDT) Received: (qmail 55156 invoked from network); 21 Jun 2011 21:57:59 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 21 Jun 2011 21:57:59 -0000 Message-ID: <4E011158.5050005@necom830.hpcl.titech.ac.jp> Date: Wed, 22 Jun 2011 06:47:04 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Edward Lewis References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <4E00B3F2.9030204@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 21:48:26 -0000 Edward Lewis wrote: > Didn't say that they weren't discussed closely in time, just referenced > the publish date. Irrelevant. >>> From a recovery perspective, what if the master server loses it's >>> increment memory and cannot do AXFR? Each slave might be called on to do >>> AXFRs when it would be more efficient for one slave to do the AXFR and >>> then answer IXFR requests until the system stabilizes. >> >> What if what? > > "Each slave might be called on to do AXFRs when it would be more > efficient for one slave to do the AXFR and then answer IXFR requests > until the system stabilizes." Wrong. What you are assuming is a crash of the master database along with its local copies, which is a very serious but classical problem with a classical solution. First, note that it should not occur and occurs very rarely, if the database is important and operated with reasonable care. But, yes, it still occurs. The most important thing to do, then, is restoration of recent updates, not past history. You can't assume the recent most data, which is most fragile, is magically retained. Classically, important database is equipped with restoration mechanism with snapshots and journal, which happen to be information stored in secondaries through IXFR. But, because of IXFR delay, the recent most updates may be retained only in dynamic update clients. So, operators first restore recent data from a secondary with the recent most version number. Rational operators should and will restore not only the current most database but also all the history, which is not absolutely necessary but makes IXFR-only unnecessary. Then, as much journal information as possible is collected from dynamic update clients, sorted by time and used for restoration, which is a manual operation, only after which, the master server start operating again. During the restoration of the master, secondaries have enough time to synchronize there databases with efficient IXFR that they and the master should have the same version, which means there is no room for IXFR-only after the restoration of the master, even if history of the master is, quite irrationally, not restored. > Which is what happens today. You are saying DNS operators know nothing about the very basic (thus, classical) points of database maintenance. I hope its your imaginary example not happening anywhere in the real world today. Masataka Ohta From Ed.Lewis@neustar.biz Tue Jun 21 17:34:30 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E015911E8092 for ; Tue, 21 Jun 2011 17:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.268 X-Spam-Level: X-Spam-Status: No, score=-106.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDE74eKUKcKZ for ; Tue, 21 Jun 2011 17:34:30 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD4F11E8079 for ; Tue, 21 Jun 2011 17:34:29 -0700 (PDT) Received: from tken-lt60.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5M0YQx3003265; Tue, 21 Jun 2011 20:34:27 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.128.251] by tken-lt60.cis.neustar.com (PGP Universal service); Tue, 21 Jun 2011 20:34:27 -0400 X-PGP-Universal: processed; by tken-lt60.cis.neustar.com on Tue, 21 Jun 2011 20:34:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4E011158.5050005@necom830.hpcl.titech.ac.jp> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <4E00B3F2.9030204@necom830.hpcl.titech.ac.jp> <4E011158.5050005@necom830.hpcl.titech.ac.jp> Date: Tue, 21 Jun 2011 20:34:24 -0400 To: Masataka Ohta From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 00:34:31 -0000 At 6:47 +0900 6/22/11, Masataka Ohta wrote: >You are saying DNS operators know nothing about the very basic >(thus, classical) points of database maintenance. You have a vivid imagination. What I am saying is that operators, other than me, have proposed updating the tired old definition of IXFR based on what is see in practice today. And I am agreeing that there is a reason to do so. Times have changed and older definitions sometimes need to be brought up to current standards. In addition, you yourself said yesterday that parts of RFC 1995 were left somewhat unfinished so as to not have to redefine AXFR. Well, now AXFR has been redefined, so the time has come to complete IXFR's documentation. Just to refresh... At 12:10 +0900 6/21/11, Masataka Ohta wrote: >Josh Littlefield wrote: > >> Unfortunately RFC 1995 spells that out no more clearly than RFC 1034, > >It was intentional, because I didn't want to be involved in a >discussion on how AXFR should be clarified only to delay >publication of IXFR. So, it seems that you have laid down a justification to now update RFC 1995. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From patrik@frobbit.se Thu Jun 23 15:11:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B87B11E8125 for ; Thu, 23 Jun 2011 15:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKdpwe8zEFpg for ; Thu, 23 Jun 2011 15:11:57 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 847A411E80E1 for ; Thu, 23 Jun 2011 15:11:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id EE9BF1153ACF7 for ; Fri, 24 Jun 2011 00:11:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if5559N+SzeA for ; Fri, 24 Jun 2011 00:11:55 +0200 (CEST) Received: from [10.0.1.2] (unknown [61.8.214.3]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 3B48E1153ACF3 for ; Fri, 24 Jun 2011 00:11:54 +0200 (CEST) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jun 2011 06:11:51 +0800 Message-Id: To: dnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 23 Jun 2011 16:42:56 -0700 Subject: [dnsext] What kind of use of TXT is this? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 22:11:58 -0000 People on this list must know I am against use of TXT records, or = records that you just do not know what it is you parse in general. = Things must be typed. I just stumbled on a new thing that I have not seen. Maybe it is because = I have not been alert enough. $ dig tv4.se. txt +short "( http://tv4.se )" Any ideas? Patrik From regnauld@bluepipe.net Thu Jun 23 16:49:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8E811E80D8 for ; Thu, 23 Jun 2011 16:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzWCav9RYv6P for ; Thu, 23 Jun 2011 16:49:05 -0700 (PDT) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by ietfa.amsl.com (Postfix) with ESMTP id E0FDD11E808B for ; Thu, 23 Jun 2011 16:49:04 -0700 (PDT) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id 930A84D1A82; Fri, 24 Jun 2011 01:49:02 +0200 (CEST) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id bcbfFQZdHNzy; Fri, 24 Jun 2011 01:49:02 +0200 (CEST) Received: from macbook.catpipe.net (unknown [203.118.14.76]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTP id 9A4564D1A75; Fri, 24 Jun 2011 01:49:01 +0200 (CEST) Received: by macbook.catpipe.net (Postfix, from userid 1001) id 19B0E3CAEB56; Fri, 24 Jun 2011 07:48:55 +0800 (SGT) Date: Fri, 24 Jun 2011 07:48:55 +0800 From: Phil Regnauld To: Patrik =?utf-8?B?RsOkbHRzdHLDtm0=?= Message-ID: <20110623234855.GJ7001@macbook.catpipe.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Darwin 10.7.0 i386 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] What kind of use of TXT is this? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 23:49:06 -0000 Patrik Fältström (patrik) writes: > People on this list must know I am against use of TXT records, or records that you just do not know what it is you parse in general. Things must be typed. > > I just stumbled on a new thing that I have not seen. Maybe it is because I have not been alert enough. > > $ dig tv4.se. txt +short > "( http://tv4.se )" > > Any ideas? From here it looks like a http URI :) Not any less or more correct than dig dk. txt +short or dig fr. txt +short Cheers, Phil From patrik@frobbit.se Thu Jun 23 16:55:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F2411E8084 for ; Thu, 23 Jun 2011 16:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL+nYXLYj306 for ; Thu, 23 Jun 2011 16:55:57 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 58C7111E8081 for ; Thu, 23 Jun 2011 16:55:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 5960B1153C8B3; Fri, 24 Jun 2011 01:55:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NptNOrQn+kFi; Fri, 24 Jun 2011 01:55:56 +0200 (CEST) Received: from sjc-vpn7-1297.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id B7FEA1153C8B0; Fri, 24 Jun 2011 01:55:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20110623234855.GJ7001@macbook.catpipe.net> Date: Fri, 24 Jun 2011 07:55:47 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8660E04D-6BF9-4B15-AB90-E69E9E00B338@frobbit.se> References: <20110623234855.GJ7001@macbook.catpipe.net> To: Phil Regnauld X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] What kind of use of TXT is this? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 23:55:58 -0000 On 24 jun 2011, at 07.48, Phil Regnauld wrote: > Patrik F=E4ltstr=F6m (patrik) writes: >> People on this list must know I am against use of TXT records, or = records that you just do not know what it is you parse in general. = Things must be typed. >>=20 >> I just stumbled on a new thing that I have not seen. Maybe it is = because I have not been alert enough. >>=20 >> $ dig tv4.se. txt +short >> "( http://tv4.se )" >>=20 >> Any ideas? >=20 > =46rom here it looks like a http URI :) >=20 > Not any less or more correct than >=20 > dig dk. txt +short > or > dig fr. txt +short Ha ha ha, yeah, I could get that myself... But I was thinking (of = course) more in terms of "what is supposed to digest that?". Specifically as we now have the URI resource record. Patrik From lconroy@insensate.co.uk Fri Jun 24 02:08:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAA111E80A0 for ; Fri, 24 Jun 2011 02:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMVNc0SXXjte for ; Fri, 24 Jun 2011 02:08:24 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id BA07F11E8093 for ; Fri, 24 Jun 2011 02:08:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 3C1C069DC12; Fri, 24 Jun 2011 10:08:22 +0100 (BST) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pM-aGQptYM3; Fri, 24 Jun 2011 10:08:21 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 390EE69DC07; Fri, 24 Jun 2011 10:08:21 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Lawrence Conroy In-Reply-To: <8660E04D-6BF9-4B15-AB90-E69E9E00B338@frobbit.se> Date: Fri, 24 Jun 2011 10:08:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110623234855.GJ7001@macbook.catpipe.net> <8660E04D-6BF9-4B15-AB90-E69E9E00B338@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] What kind of use of TXT is this? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 09:08:25 -0000 Hi Patrik, folks, We have an SPF record, but that doesn't stop a lot of extant relying = systems apparently requiring the TXT version. There are simply not enough batteries in the world to charge the cattle = prods needed. Re. original question -- I'm not aware of any "common" indexer that = expects that format of record. Hanlon's Razor? all the best, Lawrence On 24 Jun 2011, at 00:55, Patrik F=E4ltstr=F6m wrote: > On 24 jun 2011, at 07.48, Phil Regnauld wrote: >> Patrik F=E4ltstr=F6m (patrik) writes: >>> People on this list must know I am against use of TXT records, or = records that you just do not know what it is you parse in general. = Things must be typed. >>>=20 >>> I just stumbled on a new thing that I have not seen. Maybe it is = because I have not been alert enough. >>>=20 >>> $ dig tv4.se. txt +short >>> "( http://tv4.se )" >>>=20 >>> Any ideas? >>=20 >> =46rom here it looks like a http URI :) >>=20 >> Not any less or more correct than >>=20 >> dig dk. txt +short >> or >> dig fr. txt +short >=20 > Ha ha ha, yeah, I could get that myself... But I was thinking (of = course) more in terms of "what is supposed to digest that?". >=20 > Specifically as we now have the URI resource record. >=20 > Patrik From internet-drafts@ietf.org Fri Jun 24 07:25:03 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A06811E80B5; Fri, 24 Jun 2011 07:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0yD9+XsUSGS; Fri, 24 Jun 2011 07:25:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE889228005; Fri, 24 Jun 2011 07:25:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110624142502.15771.29685.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2011 07:25:02 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc2672bis-dname-23.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 14:25:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the I= ETF. Title : Update to DNAME Redirection in the DNS Author(s) : Scott Rose Wouter Wijngaards Filename : draft-ietf-dnsext-rfc2672bis-dname-23.txt Pages : 20 Date : 2011-06-24 The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision to the original specification in RFC 2672 as well as updating RFC 3363 and RFC 4294 to align with this revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-23.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-23.txt From scottr.nist@gmail.com Fri Jun 24 07:36:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068DA21F8538 for ; Fri, 24 Jun 2011 07:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9h4kZAFDrkq for ; Fri, 24 Jun 2011 07:36:53 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id D4EB521F8535 for ; Fri, 24 Jun 2011 07:36:52 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p5OEaeWY029978 for ; Fri, 24 Jun 2011 10:36:42 -0400 From: Scott Rose Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jun 2011 10:36:40 -0400 Message-Id: <3F8C7369-90B3-4BCE-AD4A-E11570A0C0D8@gmail.com> To: dnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com Subject: [dnsext] new version of dname-bis posted X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 14:36:54 -0000 As you may have seen, a new version of DNAME-bis is posted based on = comments received during Last Call. 1. added back some sections from RFC 2762 on client considerations and = examples of use. =20 See 3.4 and 3.4.1 for the resolver algorithm and Sec. 6 for = examples of use in a zone. 2. fixed some ID-nits bugs. Scott & Wouter From hallam@gmail.com Fri Jun 24 18:25:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C30B11E808E for ; Fri, 24 Jun 2011 18:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em88gHstMci1 for ; Fri, 24 Jun 2011 18:25:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4A11E8078 for ; Fri, 24 Jun 2011 18:25:22 -0700 (PDT) Received: by gya6 with SMTP id 6so1922163gya.31 for ; Fri, 24 Jun 2011 18:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xj83yUP03nW5UNaBuSbxLqk02htRmto69rjDi09Odro=; b=QB2hMOVgNweziQfSIZU+OcJ2gYzIyiigPbNNNVBwggg37yfFPjylyg4uNjJvoOtnoW mK0m1mXuMmUDjwvyyV0KO1Wrxd9Fi47benmX5ricBBz3kQnc6C7/Dz+L7yva43MSS6gH BFQi2psIwFGMlIUje4geH/w2UmEItLG7HROxU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ufiAhsrJd5Ri0DI2uTfLAx9A5MGG7dZD88pLGfdF/NOyL7cYUi2zPdT2T4NBgm+5XA dCOxO2jyNGgBfRNDsYvNdFZynkm+nGdFhID7SRJuriympQYgwprg9rpInEUk7ah/6nPU kzf1jdP89xeki8zHSrQgVRPXhRWcU18LYn+zs= MIME-Version: 1.0 Received: by 10.101.2.1 with SMTP id e1mr4346847ani.18.1308965121853; Fri, 24 Jun 2011 18:25:21 -0700 (PDT) Received: by 10.100.111.17 with HTTP; Fri, 24 Jun 2011 18:25:21 -0700 (PDT) In-Reply-To: <8660E04D-6BF9-4B15-AB90-E69E9E00B338@frobbit.se> References: <20110623234855.GJ7001@macbook.catpipe.net> <8660E04D-6BF9-4B15-AB90-E69E9E00B338@frobbit.se> Date: Fri, 24 Jun 2011 21:25:21 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/alternative; boundary=001636c594ff1c8bf504a67f311d Cc: dnsext@ietf.org Subject: Re: [dnsext] What kind of use of TXT is this? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 01:25:24 -0000 --001636c594ff1c8bf504a67f311d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well the DNS admin might well have just written that out as a reminder to himself as to what he was up to. Or it could be in use by a site local management tool. Or any number of reasonable uses. In fact I created one just like it this morning as I was creating a config file for my local DNS server to implement a testbed for ESRV and URI. Since my version of bind does not understand the URI record format, I am going to either have to hack the source code of bind to add it or I am goin= g to have to extend my RR generator to do URI as well. So to remind myself as to what I was doing I created the line: $ORIGIN test _owcp_cd._ws IN TXT "URI 1 1 http://host1.test/.well-known/owcp_ce.ws" Next I have to look at the BIND code and work out whether it is going to be easier to hack that to add in URI and CAA myself or continue to work with m= y record generation tool which seemed like a good idea until I discovered tha= t xedit on the Mac does not accept cut and paste. Presumably looking for a button on the mouse that existeth not. 2011/6/23 Patrik F=E4ltstr=F6m > > On 24 jun 2011, at 07.48, Phil Regnauld wrote: > > > Patrik F=E4ltstr=F6m (patrik) writes: > >> People on this list must know I am against use of TXT records, or > records that you just do not know what it is you parse in general. Things > must be typed. > >> > >> I just stumbled on a new thing that I have not seen. Maybe it is becau= se > I have not been alert enough. > >> > >> $ dig tv4.se. txt +short > >> "( http://tv4.se )" > >> > >> Any ideas? > > > > From here it looks like a http URI :) > > > > Not any less or more correct than > > > > dig dk. txt +short > > or > > dig fr. txt +short > > Ha ha ha, yeah, I could get that myself... But I was thinking (of course) > more in terms of "what is supposed to digest that?". > > Specifically as we now have the URI resource record. > > Patrik > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --=20 Website: http://hallambaker.com/ --001636c594ff1c8bf504a67f311d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well the DNS admin might well have just written that out as a reminder to h= imself as to what he was up to.

Or it could be in use by= a site local management tool. Or any number of reasonable uses.


In fact I created one just like it this morni= ng as I was creating a config file for my local DNS server to implement a t= estbed for ESRV and URI.

Since my version of bind = does not understand the URI record format, I am going to either have to hac= k the source code of bind to add it or I am going to have to extend my RR g= enerator to do URI as well.

So to remind myself as to what I was doing I created th= e line:

$ORIGIN test
_owcp_cd._ws =A0 IN= TXT "URI 1 1 htt= p://host1.test/.well-known/owcp_ce.ws"


Next I have to look at the BIND code and work out w= hether it is going to be easier to hack that to add in URI and CAA myself o= r continue to work with my record generation tool which seemed like a good = idea until I discovered that xedit on the Mac does not accept cut and paste= . Presumably looking for a button on the mouse that existeth not.=A0


2011/6/23 Patrik F=E4lts= tr=F6m <patrik@fr= obbit.se>

On 24 jun 2011, at 07.48, Phil Regnauld wrote:

> Patrik F=E4ltstr=F6m (patrik) writes:
>> People on this list must know I am against use of TXT records, or = records that you just do not know what it is you parse in general. Things m= ust be typed.
>>
>> I just stumbled on a new thing that I have not seen. Maybe it is b= ecause I have not been alert enough.
>>
>> $ dig tv4.se. txt = +short
>> "( http://tv4.se<= /a> )"
>>
>> Any ideas?
>
> =A0 =A0 =A0 From here it looks like a http URI :)
>
> =A0 =A0 =A0 Not any less or more correct than
>
> =A0 =A0 =A0 dig dk. txt +short
> =A0 =A0 =A0 or
> =A0 =A0 =A0 dig fr. txt +short

Ha ha ha, yeah, I could get that myself... But I was thinking (of cou= rse) more in terms of "what is supposed to digest that?".

Specifically as we now have the URI resource record.

=A0 Patrik



--
Website: http://hallambaker.com/

--001636c594ff1c8bf504a67f311d-- From ajs@anvilwalrusden.com Fri Jun 24 19:02:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AEB11E8124 for ; Fri, 24 Jun 2011 19:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRYnusVhZ-wS for ; Fri, 24 Jun 2011 19:02:21 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0438B11E808E for ; Fri, 24 Jun 2011 19:02:20 -0700 (PDT) Received: from shinkuro.com (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 60F8C1ECB41D for ; Sat, 25 Jun 2011 02:02:18 +0000 (UTC) Date: Fri, 24 Jun 2011 22:02:14 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110625020213.GD97941@shinkuro.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] [nomcom-chair@ietf.org: Please help the Nomcom] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 02:02:21 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear colleagues, The Nomcom needs help. Please consider volunteering. A -- Andrew Sullivan ajs@anvilwalrusden.com --liOOAslEiF7prFVr Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: ajs@anvilwalrusden.com Delivered-To: ajs@anvilwalrusden.com Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by mail.yitter.info (Postfix) with ESMTP id 3107F1ECB41D for ; Fri, 24 Jun 2011 20:51:38 +0000 (UTC) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FEB11E8223; Fri, 24 Jun 2011 13:51:38 -0700 (PDT) X-Original-To: wgchairs@ietf.org Delivered-To: wgchairs@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 7035311E81A8; Fri, 24 Jun 2011 11:35:13 -0700 (PDT) From: NomCom Chair To: Working Group Chairs Subject: Please help the Nomcom Message-Id: <20110624183513.7035311E81A8@ietfa.amsl.com> Date: Fri, 24 Jun 2011 11:35:13 -0700 (PDT) X-Mailman-Approved-At: Fri, 24 Jun 2011 13:51:37 -0700 X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: wgchairs-bounces@ietf.org Errors-To: wgchairs-bounces@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Hi WG chairs, We have had a good response to the first call for volunteers but the rate at which new volunteers are coming in is slowing down. The Nomcom process is best served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. Where else would we find this wide spectrum if not in the WG mailing lists. I would really appreciate it if you can forward the message onto your working group mailing lists. The latest volunteer status and the second call for volunteers can be found at https://datatracker.ietf.org/ann/nomcom/2964/ Thanks in advance for your help. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com --liOOAslEiF7prFVr-- From patrik@frobbit.se Sat Jun 25 03:34:29 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0E21F8537 for ; Sat, 25 Jun 2011 03:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ApfEUGS8SgD for ; Sat, 25 Jun 2011 03:34:29 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 14D5021F84F5 for ; Sat, 25 Jun 2011 03:34:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 25F9111560FC8; Sat, 25 Jun 2011 12:34:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgouF6kEnFI7; Sat, 25 Jun 2011 12:34:23 +0200 (CEST) Received: from dhcp-10-55-93-158.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id C5CAA11560FC4; Sat, 25 Jun 2011 12:34:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Sat, 25 Jun 2011 12:34:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <193B4288-79B4-4C86-8305-6E2D1B424F57@frobbit.se> References: <20110623234855.GJ7001@macbook.catpipe.net> <8660E04D-6BF9-4B15-AB90-E69E9E00B338@frobbit.se> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] What kind of use of TXT is this? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 10:34:29 -0000 On 25 jun 2011, at 03.25, Phillip Hallam-Baker wrote: > $ORIGIN test > _owcp_cd._ws IN TXT "URI 1 1 = http://host1.test/.well-known/owcp_ce.ws" If I have not done enything wrong here, you can do this: $ORIGIN test _owcp_cd._wc IN TYPE256 \# 46 = 00010001746870742f3a682f736f3174742e73652f74772e6c652d6c6e6b776f2f6e776f70= 63635f2e657377000a Patrik From hallam@gmail.com Sat Jun 25 08:03:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F6F21F8455 for ; Sat, 25 Jun 2011 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=-1.698, BAYES_00=-2.599, FR_TEST_BASE64_BAD=3.189, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4mb3q-GF1LC for ; Sat, 25 Jun 2011 08:03:22 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E7D0821F8454 for ; Sat, 25 Jun 2011 08:03:21 -0700 (PDT) Received: by ywp31 with SMTP id 31so2133826ywp.31 for ; Sat, 25 Jun 2011 08:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=IJJ5ZiHDqq5cgAOf1kpkx7j3mOblKg9w8qylTQIpWCU=; b=rqfJERqgFC6SAYoMT+ObvnY+tS4JCZR1zrUTVBx78IcdwRkYMgjgq/lI380M/XmNCh +FuseTWXg6hpUYNym1fve3xEnmPJxq+sVqW0inGNOVXIcLMAVsJXpQGZhqCCCqKPtArg Ck6ia5U6kRNbHs5blLSxAMMgTCHRwP82/p574= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f6UiqrvLLQKr9m6iULiBM495I5QCe6Af4uKkefy67GGcf0/au2yfw9blVmThQKOHFx xWpd119zB7BnmptewmgeAnuqr8d4e4lp5/sVFqkDHWZLhrRm8nWKK7xC9JPXLk1iBgaO qUED8mwLGfX88XYC0eGxCRY8ZOYi6JNDCIGjI= MIME-Version: 1.0 Received: by 10.101.177.8 with SMTP id e8mr1931500anp.128.1309014200212; Sat, 25 Jun 2011 08:03:20 -0700 (PDT) Received: by 10.100.111.17 with HTTP; Sat, 25 Jun 2011 08:03:20 -0700 (PDT) In-Reply-To: <193B4288-79B4-4C86-8305-6E2D1B424F57@frobbit.se> References: <20110623234855.GJ7001@macbook.catpipe.net> <8660E04D-6BF9-4B15-AB90-E69E9E00B338@frobbit.se> <193B4288-79B4-4C86-8305-6E2D1B424F57@frobbit.se> Date: Sat, 25 Jun 2011 11:03:20 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Content-Type: multipart/alternative; boundary=001636c92c6268dbe704a68a9ea3 Cc: dnsext@ietf.org Subject: Re: [dnsext] What kind of use of TXT is this? X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 15:03:23 -0000 --001636c92c6268dbe704a68a9ea3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, that will be very useful for testing my URI patch to BIND. I just copied over the definitions from srv_33.c to uri_256.c and got a clean compile. For the first round of testing I am going to get the named running with URI having the exact same syntax as srv. Now I can slot in your record into the config file, modify it to change the type of target from dns name to string and I can test dig first against your record and then test named. CAA/ESRV will be a little trickier with the OID encoding. Might decide to wimp out there and just do a choice of base64 or a string value. 2011/6/25 Patrik F=E4ltstr=F6m > > On 25 jun 2011, at 03.25, Phillip Hallam-Baker wrote: > > > $ORIGIN test > > _owcp_cd._ws IN TXT "URI 1 1 http://host1.test/.well-known/owcp_ce.ws= " > > If I have not done enything wrong here, you can do this: > > $ORIGIN test > _owcp_cd._wc IN TYPE256 \# 46 > 00010001746870742f3a682f736f3174742e73652f74772e6c652d6c6e6b776f2f6e776f7= 063635f2e657377000a > > Patrik > > --=20 Website: http://hallambaker.com/ --001636c92c6268dbe704a68a9ea3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, that will be very useful for testing my URI patch to BIND.

=
I just copied over the definitions from srv_33.c to uri_256.c an= d got a clean compile.


For the firs= t round of testing I am going to get the named running with URI having the = exact same syntax as srv. Now I can slot in your record into the config fil= e, modify it to change the type of target from dns name to string and I can= test dig first against your record and then test named.


CAA/ESRV will be a little trickier with the OID enc= oding. Might decide to wimp out there and just do a choice of base64 or a s= tring value.


2011/6= /25 Patrik F=E4ltstr=F6m <patrik@frobbit.se>

On 25 jun 2011, at 03.25, Phillip Hallam-Baker wrote:

> $ORIGIN test
> _owcp_cd._ws =A0 IN TXT "URI 1 1 http://host1.test/.well-known/owcp_c= e.ws"

If I have not done enything wrong here, you can do this:

$ORIGIN test
_owcp_cd._wc IN TYPE256 \# 46 00010001746870742f3a682f736f3174742e73652f747= 72e6c652d6c6e6b776f2f6e776f7063635f2e657377000a

=A0 Patrik




--
Website: http://hallambaker.com/

--001636c92c6268dbe704a68a9ea3-- From sm@resistor.net Sat Jun 25 13:01:31 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29B011E8125; Sat, 25 Jun 2011 13:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j43b3PHiZJQl; Sat, 25 Jun 2011 13:01:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AF011E811B; Sat, 25 Jun 2011 13:01:29 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p5PK1JQM016002; Sat, 25 Jun 2011 13:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1309032087; bh=4GcySkDCMyAafKlBTMWlkYu4bZeG/AdX6ChDqKDjFXU=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=PJ7FCAUs+95L+lu3mtMiNUWPWRMwUjoVIX0q4pQtbA0I+UANdIC4WeHoBlDkvvfjx T5q8SWV+0bzOqH9KGzmaYkpezV7eat2MAWSVK0K8DyO4/2kQjp0YzhWsKp9Gc3IMgW BfNZ1WkSr9bsa8vnbafeLGv9A87Mo/sJ85ZCqEn0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1309032087; bh=4GcySkDCMyAafKlBTMWlkYu4bZeG/AdX6ChDqKDjFXU=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=NVUxG11ljvBsdSoqJFik0GmtT/0bv05bTAr6NqpeUEg8GoksGE4uEjsuDPsG7Kinf 6CwbXVo1dFh8jKoIg70dO5FAxNVahNBux0UJ45001sk7NUWwZmN6BJrrryfDiE8/Rv lni7OkKDL2r0L7aoruSdowITlsHVBu6dC67IdYds= Message-Id: <6.2.5.6.2.20110625123633.02e3ddb8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 25 Jun 2011 13:01:09 -0700 To: ietf@ietf.org From: SM In-Reply-To: <20110526205629.21816.5196.idtracker@ietfa.amsl.com> References: <20110526205629.21816.5196.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Last Call: (Update to DNAME Redirection in the DNS) to Proposed Standard X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 20:01:31 -0000 At 13:56 26-05-2011, The IESG wrote: >The IESG has received a request from the DNS Extensions WG (dnsext) to >consider the following document: >- 'Update to DNAME Redirection in the DNS' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2011-06-09. Exceptionally, comments may be I apologize for sending these comments after the end of the Last Call. Quoting Section 4: 'Based on the experience gained in the meantime, [RFC3363] is revised, dropping all constraints on having DNAME RRs in these zones. This would greatly improve the manageability of the IPv6 reverse tree. These changes are made explicit below. In [RFC3363], the paragraph "The issues for DNAME in the reverse mapping tree appears to be closely tied to the need to use fragmented A6 in the main tree: if one is necessary, so is the other, and if one isn't necessary, the other isn't either. Therefore, in moving RFC 2874 to experimental, the intent of this document is that use of DNAME RRs in the reverse tree be deprecated." is to be replaced with the word "DELETED".' Is the intent to allow the use of DNAME RRs in the reverse tree? if so, replacing the paragraph with the word "DELETED" does not make that clear. Regards, -sm From matt@mattmccutchen.net Sun Jun 26 12:11:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ECB1F0C39; Sun, 26 Jun 2011 12:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h40FExey13tb; Sun, 26 Jun 2011 12:11:57 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3055E1F0C38; Sun, 26 Jun 2011 12:11:47 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 39D38284071; Sun, 26 Jun 2011 12:11:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:content-type:date:message-id:mime-version: content-transfer-encoding; q=dns; s=mattmccutchen.net; b=eYxggq7 63X/JJVRc3Pq4OCxlM7yaEKZQVbpn6jcHoHduWf7azTWgeQr+KOYdDP7EINsCmCT Mw9eGTHoxFMykI1sb9+4baqsWV5svi0W/hU0FgrKCH7o4TEhEpzN6AfiT3Da5jq/ 558rGxuUntiQa9R7V5Uyg6GLoDIxJUAlx7G0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:content-type:date:message-id:mime-version: content-transfer-encoding; s=mattmccutchen.net; bh=zlh2sipIG+SYg grEMp7lYMBPW/g=; b=IxgM/NoOnuunhzErkA5UQQ0kfWlQAkXN2Qf8IzmaXnKWG RRq0O0OUQRAkgSl9LsvYoAiVq6vWGmXCR5KLtj6C2Qmd+eIdwtlO0tHiyg6DybMV jlbzUNT/I09Uy9VMoXGh0T8sspnrJEvkvlMtxbNOpOkHb+wYK+6Korm6el4FXI= Received: from [192.168.1.41] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id A8FC928406E; Sun, 26 Jun 2011 12:11:46 -0700 (PDT) From: Matt McCutchen To: dnsext@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 15:11:44 -0400 Message-ID: <1309115504.2118.69.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane Subject: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 19:11:58 -0000 DNSSEC folks, I'm looking forward to DANE positive assertions making TLS server deployment significantly more convenient. More generally, DNSSEC holds enormous potential utility as a repository of integrity-protected authoritative information about DNS names, including configuration for new opt-in security schemes. However, each of these schemes may increase the degree of exposure to malfeasance by the DNS operator (who may not be the same entity as the authoritative holder of the domain) in some or all cases, compared to traditional practice. Proper governance of DNSSEC data to ensure that it reflects authoritative intent is essential to be able to use these schemes and realize their compelling benefits. I would much rather resolve this issue once in a principled way than come to an unsatisfactory compromise in the context of each individual scheme. Is it viable to put registrants with signed zones on notice that clients will begin to assume the data is fully authoritative, and give them a deadline by which they should establish proper governance or revert the zone to unsigned? Alternatively, do we want a flag in the DS record (which can only be set by the parent at the registrant's request) that indicates the data is fully authoritative? Note well, I propose only to enable the ascription of strong security semantics to new RR types (or subtypes) such as DANE's TLSA and not to ascribe new semantics to existing types such as CNAME or CERT, because then signing a zone could suddenly introduce vulnerabilities. -- Matt From johnl@iecc.com Sun Jun 26 13:44:16 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C272D21F8496 for ; Sun, 26 Jun 2011 13:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.34 X-Spam-Level: X-Spam-Status: No, score=-109.34 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVih5chrFlad for ; Sun, 26 Jun 2011 13:44:16 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CF76A21F8489 for ; Sun, 26 Jun 2011 13:44:15 -0700 (PDT) Received: (qmail 60726 invoked from network); 26 Jun 2011 20:44:13 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 26 Jun 2011 20:44:13 -0000 Received: (qmail 52233 invoked from network); 26 Jun 2011 20:44:13 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 26 Jun 2011 20:44:13 -0000 Date: 26 Jun 2011 20:43:51 -0000 Message-ID: <20110626204351.14432.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <1309115504.2118.69.camel@localhost> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 20:44:16 -0000 > However, each of these schemes may increase the degree of exposure > to malfeasance by the DNS operator (who may not be the same entity > as the authoritative holder of the domain) in some or all cases, > compared to traditional practice. Current practice for SSL signers is to scrape e-mail addresses from the domain's WHOIS, and send a confirmation message with a URL the applicant clicks on. It's hard for me to imagine a process more dependent on the DNS than that. > Is it viable to put registrants with signed zones on notice that > clients will begin to assume the data is fully authoritative, and > give them a deadline by which they should establish proper > governance or revert the zone to unsigned? I think the answer to this question is "no". Let's say, I'm the registrant of examp1e.com. What, exactly, am I supposed to do to persuade the registrar and/or registry that I have established proper governance. Or if I suspect that someone else's zone is improperly governed, how do I denounce them, and to whom? R's, John From regnauld@bluepipe.net Sun Jun 26 14:03:40 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB0E21F84CB for ; Sun, 26 Jun 2011 14:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBBPS63PI9wW for ; Sun, 26 Jun 2011 14:03:40 -0700 (PDT) Received: from moof.catpipe.net (moof.catpipe.net [194.28.252.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2692321F84CA for ; Sun, 26 Jun 2011 14:03:39 -0700 (PDT) Received: from localhost (moof.catpipe.net [194.28.252.64]) by localhost.catpipe.net (Postfix) with ESMTP id CD6EC4D1AAD; Sun, 26 Jun 2011 23:03:37 +0200 (CEST) Received: from moof.catpipe.net ([194.28.252.64]) by localhost (moof.catpipe.net [194.28.252.64]) (amavisd-new, port 10024) with ESMTP id LUulClBtMDV4; Sun, 26 Jun 2011 23:03:37 +0200 (CEST) Received: from macbook.catpipe.net (unknown [113.20.89.71]) (Authenticated sender: relayuser) by moof.catpipe.net (Postfix) with ESMTP id A2E1A4D1AA0; Sun, 26 Jun 2011 23:03:35 +0200 (CEST) Received: by macbook.catpipe.net (Postfix, from userid 1001) id CFE813D1107F; Mon, 27 Jun 2011 09:03:29 +1200 (FJT) Date: Mon, 27 Jun 2011 09:03:29 +1200 From: Phil Regnauld To: John Levine Message-ID: <20110626210329.GG22800@macbook.catpipe.net> References: <1309115504.2118.69.camel@localhost> <20110626204351.14432.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110626204351.14432.qmail@joyce.lan> X-Operating-System: Darwin 10.7.0 i386 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dnsext@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 21:03:40 -0000 John Levine (johnl) writes: > > However, each of these schemes may increase the degree of exposure > > to malfeasance by the DNS operator (who may not be the same entity > > as the authoritative holder of the domain) in some or all cases, > > compared to traditional practice. > > Current practice for SSL signers is to scrape e-mail addresses from > the domain's WHOIS, and send a confirmation message with a URL the > applicant clicks on. It's hard for me to imagine a process more > dependent on the DNS than that. That's susually not the case. Increasingly, SSL issuers will require ssladmin@ or hostmaster@ domain to be active. Still depends on the DNS for sending the mail of course. Assumption is that DNS can be trusted for cheap certificates. EV will require something else. And whois, if it's available, is not DNS specific, and may not have the email address of the registrant. Cheers, Phil From matt@mattmccutchen.net Sun Jun 26 14:05:44 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1718C21F84CE; Sun, 26 Jun 2011 14:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo91xHyJsZcm; Sun, 26 Jun 2011 14:05:43 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 599B121F84CD; Sun, 26 Jun 2011 14:05:43 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 0BD3F51C063; Sun, 26 Jun 2011 14:05:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=J1S7A4DNIrqA77YCw5MApnSnCt4lYpNn5Iy857JbdB+ cMpf2WOLo1vbZKFoYwDJQrxnISeeZ9pHAW5DP1v2fUYLY/74wK+ujYgc4PB3x2kV cLMsKPRHJEr0/j6ExufJ67ZtNQaS5ZVSM9XVnTtEL0ZGQSGx5EnxF0A3Zpp1CWDo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=+gnhmUv8Rcdjh0pk8T99lXkFLTM=; b=MAENB3J5Wb Y36ppFyGkNfkYbqxy5Pdd59siaPIgg2SrE2ybLx9/VJbVVp2H13yUC0JRMJ1JB9L ok8sH6EpkCDVt4XMV6NWqxlYBt9iAhCoQoTtXE1gWxixdZcMRFjSvYGXDXKJTgUs Vo+UKyk38OUhyQatBN1VPPOVSYTO0ULm0= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 7619C51C062; Sun, 26 Jun 2011 14:05:42 -0700 (PDT) From: Matt McCutchen To: John Levine In-Reply-To: <20110626204351.14432.qmail@joyce.lan> References: <20110626204351.14432.qmail@joyce.lan> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 17:05:38 -0400 Message-ID: <1309122338.2118.82.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 21:05:44 -0000 On Sun, 2011-06-26 at 20:43 +0000, John Levine wrote: > > However, each of these schemes may increase the degree of exposure > > to malfeasance by the DNS operator (who may not be the same entity > > as the authoritative holder of the domain) in some or all cases, > > compared to traditional practice. > > Current practice for SSL signers is to scrape e-mail addresses from > the domain's WHOIS, and send a confirmation message with a URL the > applicant clicks on. It's hard for me to imagine a process more > dependent on the DNS than that. Not if you asked for paypal.com. We already went through this on the dane list (https://www.ietf.org/mail-archive/web/dane/current/msg02736.html). > > Is it viable to put registrants with signed zones on notice that > > clients will begin to assume the data is fully authoritative, and > > give them a deadline by which they should establish proper > > governance or revert the zone to unsigned? > > I think the answer to this question is "no". Let's say, I'm the > registrant of examp1e.com. A strange example, given that the schemes I'm talking about address only the security of interactions with a DNS name given as input and not how the name is chosen, but sure. > What, exactly, am I supposed to do to > persuade the registrar and/or registry that I have established proper > governance. Or if I suspect that someone else's zone is improperly > governed, how do I denounce them, and to whom? Maybe the question wasn't clear. The registrant (in effect, the holder of the login information with the registrar, or the WHOIS contacts) is authoritative for the zone. The question is whether the zone data carries the full authority of the registrant. If she says it does, it does. I.e., this would be a box you check on the registrar control panel, next to where you enter the DS records. Suppose you're the registrant of myhighvaluesite.com and have special agreements with your registrar and all the public CAs so they visit your headquarters before doing anything to your domain. To cut costs, you outsource the DNS to your friend. You figure you might as well enable DNSSEC too. But now if clients start to accept DANE positive assertions, your friend can MITM your customers. With my proposal, clients would not accept positive assertions from your zone unless and until you ask your registrar to check the box, and you wouldn't do that unless you were using a DNSSEC service provider you fully trust with your site. -- Matt From matt@mattmccutchen.net Sun Jun 26 14:11:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BBD21F84CE; Sun, 26 Jun 2011 14:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwT5k19x5kPZ; Sun, 26 Jun 2011 14:11:22 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id C6E9E21F84C8; Sun, 26 Jun 2011 14:11:21 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 945CC70406E; Sun, 26 Jun 2011 14:11:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=oi6czgdgVmkeg+zab+e340liuc+Hls2SeJ9roSGX6Zv +X5DerCHme7/bfGJmIpBb5/goOJogsRMKfXmYY+4Awbbm9nFdFpXdWNGg65GhWQw hnbycOG5qyQHGFIVp+LAMQLJG/gOWibHcTloJYGBeLqnkQ2X1MWW0Gqsdy+oKlz4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=y7eLjxlB0r12mStnu+MJI8TDdeI=; b=LzKlT+2W2G ezrzMT/t8MJ7qAtP2C/iKUEgXACMXHBEEn8i3ll9pbsHijBd9hvsUSQMUAiOLcmd gg5K2DCCWz56ngsSfL00scZHN/D/oS1LjzZISDS4+a+ct+LdpYpDSwsCOaPAdA3l ujwSd+IB9L5HaUPUDnUdFxXdwTkJfvL24= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id D769270406A; Sun, 26 Jun 2011 14:11:20 -0700 (PDT) From: Matt McCutchen To: John Levine In-Reply-To: <1309122338.2118.82.camel@localhost> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 17:11:18 -0400 Message-ID: <1309122678.2118.85.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 21:11:23 -0000 On Sun, 2011-06-26 at 17:05 -0400, Matt McCutchen wrote: > Maybe the question wasn't clear. The registrant (in effect, the holder > of the login information with the registrar, or the WHOIS contacts) is > authoritative for the zone. The question is whether the zone data > carries the full authority of the registrant. If she says it does, it > does. I.e., this would be a box you check on the registrar control > panel, next to where you enter the DS records. > > Suppose you're the registrant of myhighvaluesite.com and have special > agreements with your registrar and all the public CAs so they visit your > headquarters before doing anything to your domain. To cut costs, you > outsource the DNS to your friend. You figure you might as well enable > DNSSEC too. But now if clients start to accept DANE positive > assertions, your friend can MITM your customers. > > With my proposal, clients would not accept positive assertions from your > zone unless and until you ask your registrar to check the box, and you > wouldn't do that unless you were using a DNSSEC service provider you > fully trust with your site. To restate my question: is an opt-in process necessary, or could we just give registrants with signed zones a deadline to get their house in order? If it is necessary, is what I described viable? Is there an alternative? Otherwise we'll never realize the full benefit of DNSSEC. -- Matt From matt@mattmccutchen.net Sun Jun 26 14:51:00 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44531228010; Sun, 26 Jun 2011 14:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPf0rkpSCOuG; Sun, 26 Jun 2011 14:50:59 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8A022800F; Sun, 26 Jun 2011 14:50:59 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 0D8B43BC063; Sun, 26 Jun 2011 14:50:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=sSbc/roDeAL0fUcK2Q90/gd47oCmE7vFXIgBZidzdEP mXCXiJMy1YdcfZ5D/Lmo9zbYTzb2J+xyDTgMKVkg8pAzTFnuQMo5WZydGwMezL0D 0AnPUKK6QaB5bNhBEcKt+scOPUFyCxPNMmyeLLO9LYos6xuKTa0pkKTEw/eqbnqM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=3lU5efJw1d85p1VrPHZmXR8V3Qs=; b=VL0C3MMKZo moOtWjXyWQAbuKISsXFD41Zm+XVR0W76bf164iinFYaDl/9T+1IJJ8KRpD6kL0VA iSs3zHAmIONBLeFJmgz4Nybd97J3bdcjbeGOfwZIU2Y4yRCvJNxnXJP5RD9ri4yT VIiUz4MHQzPmX0r0MSULWlFznytkC+Q8E= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id 7A14F3BC062; Sun, 26 Jun 2011 14:50:58 -0700 (PDT) From: Matt McCutchen To: "John R. Levine" In-Reply-To: References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> <1309122678.2118.85.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 17:50:55 -0400 Message-ID: <1309125055.2118.98.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 21:51:00 -0000 On Sun, 2011-06-26 at 17:31 -0400, John R. Levine wrote: > [ note to people on the dane list: I just noticed this is cross-posted > there, so my apologies if this is a dead horse. I'll go read some > archives before arguing further] > > > To restate my question: is an opt-in process necessary, or could we just > > give registrants with signed zones a deadline to get their house in > > order? > > Who is "we" The Internet community, with IETF playing its customary leadership role. > and how do "we" enforce the deadline? It would be enforced in the sense that IETF encourages clients to start honoring DNSSEC-signed positive assertions on that date and no sooner, so sites that still have untrustworthy DNSSEC providers will become vulnerable. > > With my proposal, clients would not accept positive assertions from your > > zone unless and until you ask your registrar to check the box, and you > > wouldn't do that unless you were using a DNSSEC service provider you > > fully trust with your site. > > I'm trying to imagine the utility of a feature that allows zone managers > to say "well, yes, I signed this, but I was just kidding." Absolutely, this should not be necessary, but in practice it might be the only way to make a safe transition from the present state, which we have fallen into as a result of DANE not being on everyone's mind as DNSSEC was first deployed. At this point I don't have any data on how bad the situation is. I would like nothing better to find out that nobody is using untrustworthy DNSSEC providers. But I know if I don't raise this concern now, the public CAs will. -- Matt From matt@mattmccutchen.net Sun Jun 26 15:17:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7787421F84AE; Sun, 26 Jun 2011 15:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rRVLWvH6PVx; Sun, 26 Jun 2011 15:17:27 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id E0E1C21F84AC; Sun, 26 Jun 2011 15:17:27 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id A4C9128406E; Sun, 26 Jun 2011 15:17:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=s13UBmUkUo3ikAsESxTs8aBbdxAKbqwfI0eyBc9YYuX wS6k6qVFzla2RhYTYZ5p5Bdw7HdPNTIrHtAOeWB/7kBeEU4yq01GZHNo2Wc+j4u4 1fzJHKQFgayomp/AH1WY0qA3+Hetbwyr+kogvewlb5lYcPf5OCvKS6qr/p8UnwcQ = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=R1RGNF+qPowH8ShaTBO6e+U+wU0=; b=Q7Pi34HsbP I3t0id2GtEYndxKvFOfojg6f7yUQ6y31PTiBXH0KwzEAV1a/LZ4KSqu3WefGD8dz /TMqSV63H/iolHU6ZmcqjW4FMtzicvq/OFrPCPs5Dz4blCgXBIHyZrjuzwhe+WiP hSsoCzqLks1B50+jA1j0m7a9SsfwkU1p4= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 1F12028406C; Sun, 26 Jun 2011 15:17:26 -0700 (PDT) From: Matt McCutchen To: dnsext@ietf.org In-Reply-To: <1309115504.2118.69.camel@localhost> References: <1309115504.2118.69.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Jun 2011 18:17:25 -0400 Message-ID: <1309126645.2118.109.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dane Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 22:17:28 -0000 On Sun, 2011-06-26 at 15:11 -0400, Matt McCutchen wrote: > Proper governance > of DNSSEC data to ensure that it reflects authoritative intent is > essential to be able to use these schemes and realize their compelling > benefits. To restate, the upshot of DANE and similar schemes to come is that Alice, a registrant with a signed zone, will need to apply the same standard of governance to their zones as she currently does to her relationships with public CAs. This common standard may be anything from a subscriber username and password on a sticky note on the monitor to multiple two-factor-authenticated approvals of each change. Alice may consider that the best way to achieve the above is to outsource the DNS to a company she trusts, with an interface for submitting DNS changes comparable to those for obtaining certificates from public CAs. Maybe the company can also get her publicly-recognized certs for legacy clients; maybe her registrar even provides this service. That's great. But now she will also have the option to manage the certs herself and still have the world recognize them as authoritative for her domain. It's her choice, and thereby the ideal of DNS delegation will finally be realized with respect to authentication of TLS services bound to DNS names. -- Matt From johnl@iecc.com Sun Jun 26 15:19:59 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8DF21F84D6 for ; Sun, 26 Jun 2011 15:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYAC2tfRQSXL for ; Sun, 26 Jun 2011 15:19:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E4FD421F84D1 for ; Sun, 26 Jun 2011 15:19:58 -0700 (PDT) Received: (qmail 61641 invoked from network); 26 Jun 2011 22:19:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=f0c8.4e07b08e.k1106; bh=tLgvP6RCEAMx5BCYhtyfsfx54ademPKStKY0kAfcKiE=; b=HB/HeIvGxKVtLF6JmexnbZ0EiMxG1VLNwluF17RWAvCj8b7AYNL6rnCU+Vb3Cm5D5wmfLwczOCgogoA7+mex3rYowG1BsfgJmI9OhhhTMB7xHdN+M8Iq8B/kC7zRsP82V9yTWuuGK7UAi3ua/a2n1YT1xwA5btAlsLbzOE4AHrg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Jun 2011 22:19:36 -0000 Date: 26 Jun 2011 18:19:57 -0400 Message-ID: From: "John R. Levine" To: "Phil Regnauld" In-Reply-To: <20110626210329.GG22800@macbook.catpipe.net> References: <1309115504.2118.69.camel@localhost> <20110626204351.14432.qmail@joyce.lan> <20110626210329.GG22800@macbook.catpipe.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 22:19:59 -0000 >> Current practice for SSL signers is to scrape e-mail addresses from >> the domain's WHOIS, and send a confirmation message with a URL the >> applicant clicks on. It's hard for me to imagine a process more >> dependent on the DNS than that. > > That's susually not the case. Increasingly, SSL issuers will require > ssladmin@ or hostmaster@ domain to be active. That's not what I've found, but in any event, as you note sending the mail still depends on DNS. > DNS for sending the mail of course. Assumption is that DNS can be > trusted for cheap certificates. EV will require something else. It appears to me that for the $99 EV, they scrape corporate registration off state DOS websites. DNS again. > And whois, if it's available, is not DNS specific, and may not have the > email address of the registrant. How do you find a WHOIS server other than by looking up its name in the DNS? R's, John From johnl@iecc.com Sun Jun 26 18:01:41 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404A2228011 for ; Sun, 26 Jun 2011 18:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQbTy6PV6a1y for ; Sun, 26 Jun 2011 18:01:40 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCF7228006 for ; Sun, 26 Jun 2011 18:01:36 -0700 (PDT) Received: (qmail 63107 invoked from network); 27 Jun 2011 01:01:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=f681.4e07d66d.k1106; bh=7sUhydpLINrAofdsZlmn8cceGIQC6fjMOVbMyoPBc/s=; b=IjMRYPUD3IDhfjsDNeuPqPT2h9yNKquN3NydaM29Q4UiuB0CXkXG/4jZ4eX5FOmHSVtaB7UNMHCcG5qMoRhXvAjpCrGeoquAxM/HXvIZjv+dIa+aC0tEmRuJK1SK/FeDUdov4hhvXpDCEo41rc7LPyFLdXHmbH25T6u4zaaly80= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Jun 2011 01:01:10 -0000 Date: 26 Jun 2011 21:01:31 -0400 Message-ID: From: "John R. Levine" To: dnsext@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 01:01:41 -0000 >> Who is "we" > > The Internet community, with IETF playing its customary leadership role. Ah. Never mind, then. R's, John From Jeff.Hodges@KingsMountain.com Sun Jun 26 18:23:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E4811E8087 for ; Sun, 26 Jun 2011 18:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.665 X-Spam-Level: X-Spam-Status: No, score=-99.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wm+y4l0ad3ZY for ; Sun, 26 Jun 2011 18:23:10 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 55E6211E808B for ; Sun, 26 Jun 2011 18:23:10 -0700 (PDT) Received: (qmail 29929 invoked by uid 0); 27 Jun 2011 00:14:54 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 27 Jun 2011 00:14:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=5taezRh/KotjD0saaOkbt20rCazXpxcks1jMvUYofiugAzhIT5iU5HDI5OyRyW/hWVaGXUU8/dIcbIARebo6U1AZzstIoYrgzr2iwB9RAqT2tpM8ey1qMdI6f+0fBLaZ; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QazTa-0005te-Bc; Sun, 26 Jun 2011 18:14:54 -0600 Message-ID: <4E07CB7C.9000009@KingsMountain.com> Date: Sun, 26 Jun 2011 17:14:52 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: dane Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 01:23:11 -0000 > More generally, DNSSEC holds > enormous potential utility as a repository of integrity-protected > authoritative information about DNS names, including configuration for > new opt-in security schemes. However, each of these schemes may > increase the degree of exposure to malfeasance by the DNS operator (who > may not be the same entity as the authoritative holder of the domain) in > some or all cases, compared to traditional practice. Not to say that having these concerns is misplaced, but the DNSop WG, as well as various DNS operators, have been thinking along these lines... http://tools.ietf.org/wg/dnsop/ "DPS" = DNSSEC Practice Statement ..perhaps further discussion should go to the dnsop@ietf.org list? There's also: Dnssec-deployment@dnssec-deployment.org HTH, =JeffH --- DNSSEC Operational Practices, Version 2 http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis Abstract This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. --- DNSSEC Policy & Practice Statement Framework http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework Abstract This document presents a framework to assist writers of DNSSEC Policy and Practice Statements such as Domain Managers and Zone Operators on both the top-level and secondary level, who is managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. -- DPS framework (slides) DNSSEC in Sweden: Five Years of Practical Experience (slides) Root DNSSEC docs ---------------- Root DNSSEC - documentation (many documents) http://www.root-dnssec.org/documentation/ IANA DNSSEC Information https://www.iana.org/dnssec/ Individual DPSs --------------- DNSSEC Practice Statement for the Root Zone KSK Operator https://www.iana.org/dnssec/icann-dps.txt Verisign DNSSEC Practice Statements (.net, .edu, Signing Services, root zone ZSK operator) https://verisigninc.com/en_US/repository/index.xhtml RIPE DNSSEC Policy and Practice Statement http://www.ripe.net/rs/reverse/dnssec/dps.html DNSSEC Practice Statement (DPS) -- .se http://www.iis.se/docs/se-dnssec-dps-eng.pdf DNSSEC Practice Statement for the JP Zone (JP DPS) https://jprs.jp/doc/dnssec/jp-dps-eng.html --- end From paf@cisco.com Sun Jun 26 20:22:16 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3192411E809D; Sun, 26 Jun 2011 20:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cX9OT4CP-iz; Sun, 26 Jun 2011 20:22:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3B65111E8076; Sun, 26 Jun 2011 20:22:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=692; q=dns/txt; s=iport; t=1309144935; x=1310354535; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xT/FdTbYC31rtYi60ylgCIdiSEo0+SkUGfG6ugd+bow=; b=cCe2Ge5qZ83fwSlYWWjG7RUdeSlCwsTdamuW4cqYHYGK0h9xTyOXJgFj VRcLB93Pv2Y/Xg9PQ+j5K+YPWbW4rxLlGdTLl6xu35NULXjXFAKDN9yyD dQXPa1Ch+4CaJhgjTmrqEv2Oc3qo6pgtieLjXSyLgMVfLN+YVJtY0kvwl w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAD3B06Q/khN/2dsb2JhbABSp0N3iHShUJ0dhjAEkgOQHQ X-IronPort-AV: E=Sophos;i="4.65,429,1304294400"; d="scan'208";a="98283187" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Jun 2011 03:22:14 +0000 Received: from dhcp-10-55-93-191.cisco.com (dhcp-10-55-93-191.cisco.com [10.55.93.191]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5R3MDJo001288; Mon, 27 Jun 2011 03:22:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1309122338.2118.82.camel@localhost> Date: Mon, 27 Jun 2011 05:22:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <159B4B11-5186-45C3-9FC0-C2E5EAC11C13@cisco.com> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: John Levine , dnsext@ietf.org, dane@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 03:22:16 -0000 On 26 jun 2011, at 23.05, Matt McCutchen wrote: > But now if clients start to accept DANE positive > assertions, your friend can MITM your customers. Yes, but you did choose your friend as a DNS operator. And you will = always be giving your DNS hosting provider that ability. > With my proposal, clients would not accept positive assertions from = your > zone unless and until you ask your registrar to check the box, and you > wouldn't do that unless you were using a DNSSEC service provider you > fully trust with your site. You can not ask the registrar to keep track of who is your DNS hosting = provider. That has been tried and only leads to problems. Patrik From paf@cisco.com Sun Jun 26 20:23:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9FA11E8076; Sun, 26 Jun 2011 20:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gID6DpCiTK9; Sun, 26 Jun 2011 20:23:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DBA1111E80A8; Sun, 26 Jun 2011 20:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=353; q=dns/txt; s=iport; t=1309145005; x=1310354605; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=7zSK+xPxBXWS+XqgX1zhN5PF+QrmD45hVWLkw7K+s3Y=; b=b7mKZ2lHJvQtqOumFsUr4NKDfsTkr7gzFq/tSTxqcXLNlhxsDnV/kUZO H0Vq0VpZxGyJnmbczjnZTDR5f3oN9ur+tbnq4wjYwABdiBJ28cwYZrjyo bwgxtfCDPAYA62Gy+oyXYMXlhEHESHE4eOY1KHnbl7EloJIHjyWE/dQUi Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAD3B06Q/khM/2dsb2JhbABSp0N3iHShUJ0dhjAEkgOQHQ X-IronPort-AV: E=Sophos;i="4.65,429,1304294400"; d="scan'208";a="98283337" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 27 Jun 2011 03:23:24 +0000 Received: from dhcp-10-55-93-191.cisco.com (dhcp-10-55-93-191.cisco.com [10.55.93.191]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5R3NNgm026639; Mon, 27 Jun 2011 03:23:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1309122678.2118.85.camel@localhost> Date: Mon, 27 Jun 2011 05:23:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <740D926F-ECB5-4FEB-A1BC-29EFE8F9AD6F@cisco.com> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> <1309122678.2118.85.camel@localhost> To: Matt McCutchen X-Mailer: Apple Mail (2.1084) Cc: John Levine , dnsext@ietf.org, dane@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 03:23:25 -0000 On 26 jun 2011, at 23.11, Matt McCutchen wrote: > To restate my question: is an opt-in process necessary, or could we = just > give registrants with signed zones a deadline to get their house in > order? My take is that opt-in is not needed. The opt-in happens when zone gets = signed and the DS is published in the parent zone. Patrik From vixie@isc.org Sun Jun 26 20:30:46 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5827B11E80A8; Sun, 26 Jun 2011 20:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8Webe-pPWzP; Sun, 26 Jun 2011 20:30:46 -0700 (PDT) Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id CBB5111E808E; Sun, 26 Jun 2011 20:30:45 -0700 (PDT) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 37A96A1031; Mon, 27 Jun 2011 03:30:44 +0000 (UTC) (envelope-from vixie@isc.org) Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 1D546A1021; Mon, 27 Jun 2011 03:30:44 +0000 (UTC) (envelope-from vixie@isc.org) From: Paul Vixie To: dnsext@ietf.org, dane@ietf.org In-Reply-To: Your message of "Mon, 27 Jun 2011 05:23:23 +0200." <740D926F-ECB5-4FEB-A1BC-29EFE8F9AD6F@cisco.com> References: <20110626204351.14432.qmail@joyce.lan> <1309122338.2118.82.camel@localhost> <1309122678.2118.85.camel@localhost> <740D926F-ECB5-4FEB-A1BC-29EFE8F9AD6F@cisco.com> X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 27 Jun 2011 03:30:44 +0000 Message-ID: <83087.1309145444@nsa.vix.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 03:30:46 -0000 > From: Patrik Fältström > Date: Mon, 27 Jun 2011 05:23:23 +0200 > > > To restate my question: is an opt-in process necessary, or could we just > > give registrants with signed zones a deadline to get their house in > > order? > > My take is that opt-in is not needed. The opt-in happens when zone > gets signed and the DS is published in the parent zone. +1. From johnl@iecc.com Sun Jun 26 20:31:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F4F11E80AF for ; Sun, 26 Jun 2011 20:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.734 X-Spam-Level: X-Spam-Status: No, score=-110.734 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG--rCL7h9lm for ; Sun, 26 Jun 2011 20:31:06 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0F95D11E808E for ; Sun, 26 Jun 2011 20:31:05 -0700 (PDT) Received: (qmail 64463 invoked from network); 27 Jun 2011 03:31:04 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 27 Jun 2011 03:31:04 -0000 Received: (qmail 15945 invoked from network); 27 Jun 2011 03:31:04 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 27 Jun 2011 03:31:04 -0000 Date: 27 Jun 2011 03:30:42 -0000 Message-ID: <20110627033042.25841.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <740D926F-ECB5-4FEB-A1BC-29EFE8F9AD6F@cisco.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 03:31:06 -0000 >My take is that opt-in is not needed. The opt-in happens when zone gets signed and the DS is published in the parent zone. I get the impression that there are a lot of questions that start with "well, what happens if ..." to which the answer is "don't do that." R's, John From paf@cisco.com Sun Jun 26 21:04:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996E511E80BE for ; Sun, 26 Jun 2011 21:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9oj3f+RP6iA for ; Sun, 26 Jun 2011 21:04:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C054B11E80BB for ; Sun, 26 Jun 2011 21:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=1864; q=dns/txt; s=iport; t=1309147464; x=1310357064; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=KrsNGHc8nmogabdayZlXZ/3PlWVS+4mzxofEF/q35jQ=; b=h95ND2BHnsSVHpfnDoXsL9gmEY8hlg3qyNYngRSXMdl1S4ViOu/PLrrO tUih1dNDzMM6oTa80Ar0/c6K7SKGUwYKN85DytnNiugvJCJGf+/C27pqy oReTmy+PXXr9NyqQD29qRzQa2JR11Df9AVAGwbveRK6dRJ/LlVgJfpxa4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGwACE6Q/khN/2dsb2JhbABSp0N3iHShJ50dhjAEkgOQHQ X-IronPort-AV: E=Sophos;i="4.65,430,1304294400"; d="scan'208";a="98287358" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Jun 2011 04:04:23 +0000 Received: from dhcp-10-55-93-191.cisco.com (dhcp-10-55-93-191.cisco.com [10.55.93.191]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5R44Npi006972; Mon, 27 Jun 2011 04:04:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20110627033042.25841.qmail@joyce.lan> Date: Mon, 27 Jun 2011 06:04:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110627033042.25841.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 04:04:25 -0000 On 27 jun 2011, at 05.30, John Levine wrote: >> My take is that opt-in is not needed. The opt-in happens when zone >> gets signed and the DS is published in the parent zone. >=20 > I get the impression that there are a lot of questions that start with > "well, what happens if ..." to which the answer is "don't do that." Sure, but many of those questions: 1. Do not come from people that have experience from running DNSSEC = operationally in a registry/registrar/dns hosting provider environment 2. Are theoretical mind games (i.e. not wrong at all, but we have to be = realistic) 3. Come from people that do not separate enough theory and practice 4. Creates a correct and good exercise in re-calculation of risk versus = benefit, but not more than that (the answer to the calculation is still = the same ---> it is better to anchor SSL cert in DNSSEC trust than other = trust) Etc... Specifically, many of the issues I have seen brought up lately builds on = the case that the registrant is completely clueless and explicitly = chooses to buy services from someone that intentionally or non = intentionally screws up. I am sorry, but to some degree we can not protect people from doing = wrong things. We might be able to minimize the risk third parties are = not impacted though. For example, if I screw up with my zone, you should = still be able to communicate in a secure way with Paul. Instead I say that IF the registrant is just clueful enough on getting = registrar and DNS hosting service from entities (note, does not have to = be the same) so that the zone is signed correctly, then we have "go". = There are many other ways a registrant can shoot himself in the foot, or = both feet... And I am in support of systems that first of all helps the ones that DO = know what they want. Patrik From fweimer@bfk.de Mon Jun 27 01:30:56 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE8621F8656; Mon, 27 Jun 2011 01:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YoX90kb9oyl; Mon, 27 Jun 2011 01:30:56 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id CFF4321F8616; Mon, 27 Jun 2011 01:30:55 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Qb7DZ-0005LY-ME; Mon, 27 Jun 2011 08:30:53 +0000 Received: by bfk.de with local id 1Qb7DZ-00035D-JW; Mon, 27 Jun 2011 08:30:53 +0000 From: Florian Weimer To: Matt McCutchen References: <1309115504.2118.69.camel@localhost> <1309126645.2118.109.camel@localhost> Date: Mon, 27 Jun 2011 08:30:53 +0000 In-Reply-To: <1309126645.2118.109.camel@localhost> (Matt McCutchen's message of "Sun, 26 Jun 2011 18:17:25 -0400") Message-ID: <8262nrisle.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org, dane Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 08:30:56 -0000 * Matt McCutchen: > To restate, the upshot of DANE and similar schemes to come is that > Alice, a registrant with a signed zone, will need to apply the same > standard of governance to their zones as she currently does to her > relationships with public CAs. This is already a requirement without DANE, and with or without DNSSEC. There seems to be a persistent myth that DNS is just there and you don't have to take care. I don't know where this comes from. For most organizations, DNS is an important part of the infrastructure, one of the things where breakage is widely noticeable to users and beyond. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Mon Jun 27 01:33:32 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206BE11E807A; Mon, 27 Jun 2011 01:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlM7K7rKL8KX; Mon, 27 Jun 2011 01:33:31 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id E89D721F862A; Mon, 27 Jun 2011 01:33:29 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Qb7G4-0005TY-Gj; Mon, 27 Jun 2011 08:33:28 +0000 Received: by bfk.de with local id 1Qb7G4-0007Jo-Di; Mon, 27 Jun 2011 08:33:28 +0000 From: Florian Weimer To: Matt McCutchen References: <1309115504.2118.69.camel@localhost> Date: Mon, 27 Jun 2011 08:33:28 +0000 In-Reply-To: <1309115504.2118.69.camel@localhost> (Matt McCutchen's message of "Sun, 26 Jun 2011 15:11:44 -0400") Message-ID: <821uyfish3.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org, dane Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 08:33:32 -0000 * Matt McCutchen: > I'm looking forward to DANE positive assertions making TLS server > deployment significantly more convenient. Is there any browser vendor buy-in for this type of functionality? My gut feeling is that this is extremely unrealistic and will not happen. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From matt@mattmccutchen.net Mon Jun 27 04:46:07 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6061121F8607; Mon, 27 Jun 2011 04:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1eb0CQtiYRO; Mon, 27 Jun 2011 04:46:06 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id A38AD21F8690; Mon, 27 Jun 2011 03:45:31 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by hapkido.dreamhost.com (Postfix) with ESMTP id 6CA2017EACA; Mon, 27 Jun 2011 03:43:30 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 441FF57806E; Mon, 27 Jun 2011 03:37:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=sbYXAyaqtzK1DDueF/vtDja4dTlGcJxqHr9R/x6bgLS lIoqQizllYNl5KSEFR4KufRqzASHt9O3o/z/6lVrEFMKRc3xwr+AGQCMevDWVhQs ihYYoS+60ySCMAn+sGe748C6hjU9636AN+M2jvWF6iNwH6fu0ZRbUNooiffxHSK4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=Ehikfsyk/TVYZMqtdccl5sFC8F4=; b=tuSSkyLkRz +JGxBwer/azpCTGPgnzBnMPHnh5ZMgtJCzjJEWD75AZbcmzw066GkbFKFByuAxCK a/hhamUl3dOLdTTtMaYcfCGmgQiDQO7ufsE520oD/u82JmdiosUN5gj8/is/9kbA iG7hEIWdzbvqjy0yr7G1AguqOmSiT5QrY= Received: from [192.168.1.40] (pool-96-231-10-13.washdc.east.verizon.net [96.231.10.13]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPSA id 87D4B57806C; Mon, 27 Jun 2011 03:37:47 -0700 (PDT) From: Matt McCutchen To: Florian Weimer In-Reply-To: <821uyfish3.fsf@mid.bfk.de> References: <1309115504.2118.69.camel@localhost> <821uyfish3.fsf@mid.bfk.de> Content-Type: text/plain; charset="UTF-8" Date: Mon, 27 Jun 2011 06:37:45 -0400 Message-ID: <1309171065.2040.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, dane Subject: [dnsext] (Client deployment of DANE positive assertions) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 11:46:07 -0000 On Mon, 2011-06-27 at 08:33 +0000, Florian Weimer wrote: > * Matt McCutchen: > > > I'm looking forward to DANE positive assertions making TLS server > > deployment significantly more convenient. > > Is there any browser vendor buy-in for this type of functionality? > > My gut feeling is that this is extremely unrealistic and will not > happen. Chromium accepts stapled CAA-RP RRsets (http://www.imperialviolet.org/2011/06/16/dnssecchrome.html), and Mozilla is planning to follow suit (https://bugzilla.mozilla.org/show_bug.cgi?id=589537). Hopefully they switch to the DANE TLSA format when it is standardized. The stapling is an important implementation question but irrelevant to the security of positive assertions. -- Matt From rbarnes@bbn.com Sun Jun 26 20:33:26 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125B021F8568; Sun, 26 Jun 2011 20:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csYXwd7OHSoj; Sun, 26 Jun 2011 20:33:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8361921F856C; Sun, 26 Jun 2011 20:33:21 -0700 (PDT) Received: from [128.89.253.249] (port=51349 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qb2Zc-000GrW-Ez; Sun, 26 Jun 2011 23:33:21 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4E07CB7C.9000009@KingsMountain.com> Date: Sun, 26 Jun 2011 23:33:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FF98695-B8C2-4C90-AEC2-86680CAE0B4D@bbn.com> References: <4E07CB7C.9000009@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Mon, 27 Jun 2011 05:52:48 -0700 Cc: dnsext@ietf.org, dane Subject: Re: [dnsext] [dane] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 03:33:26 -0000 X-List-Received-Date: Mon, 27 Jun 2011 03:33:26 -0000 For example: On Jun 26, 2011, at 8:14 PM, =3DJeffH wrote: > > More generally, DNSSEC holds > > enormous potential utility as a repository of integrity-protected > > authoritative information about DNS names, including configuration = for > > new opt-in security schemes. However, each of these schemes may > > increase the degree of exposure to malfeasance by the DNS operator = (who > > may not be the same entity as the authoritative holder of the = domain) in > > some or all cases, compared to traditional practice. >=20 > Not to say that having these concerns is misplaced, but the DNSop WG, = as well as various DNS operators, have been thinking along these = lines... >=20 > http://tools.ietf.org/wg/dnsop/ >=20 > "DPS" =3D DNSSEC Practice Statement >=20 > ..perhaps further discussion should go to the dnsop@ietf.org list? >=20 > There's also: Dnssec-deployment@dnssec-deployment.org >=20 > HTH, >=20 > =3DJeffH >=20 > --- >=20 > DNSSEC Operational Practices, Version 2 > http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis >=20 > Abstract >=20 > This document describes a set of practices for operating the DNS = with > security extensions (DNSSEC). The target audience is zone > administrators deploying DNSSEC. >=20 > The document discusses operational aspects of using keys and > signatures in the DNS. It discusses issues of key generation, key > storage, signature generation, key rollover, and related policies. >=20 > This document obsoletes RFC 4641 as it covers more operational = ground > and gives more up-to-date requirements with respect to key sizes and > the DNSSEC operations. >=20 >=20 > --- >=20 > DNSSEC Policy & Practice Statement Framework > http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework >=20 > Abstract >=20 > This document presents a framework to assist writers of DNSSEC = Policy > and Practice Statements such as Domain Managers and Zone Operators = on > both the top-level and secondary level, who is managing and = operating > a DNS zone with Security Extensions (DNSSEC) implemented. >=20 > In particular, the framework provides a comprehensive list of = topics > that should be considered for inclusion into a DNSSEC Policy > definition and Practice Statement. >=20 > -- >=20 > DPS framework (slides) > = >=20 > DNSSEC in Sweden: Five Years of Practical Experience (slides) > = >=20 >=20 > Root DNSSEC docs > ---------------- >=20 > Root DNSSEC - documentation (many documents) > http://www.root-dnssec.org/documentation/ >=20 > IANA DNSSEC Information > https://www.iana.org/dnssec/ >=20 >=20 > Individual DPSs > --------------- >=20 > DNSSEC Practice Statement for the Root Zone KSK Operator > https://www.iana.org/dnssec/icann-dps.txt >=20 > Verisign DNSSEC Practice Statements > (.net, .edu, Signing Services, root zone ZSK operator) > https://verisigninc.com/en_US/repository/index.xhtml >=20 > RIPE DNSSEC Policy and Practice Statement > http://www.ripe.net/rs/reverse/dnssec/dps.html >=20 > DNSSEC Practice Statement (DPS) -- .se > http://www.iis.se/docs/se-dnssec-dps-eng.pdf >=20 > DNSSEC Practice Statement for the JP Zone (JP DPS) > https://jprs.jp/doc/dnssec/jp-dps-eng.html >=20 >=20 >=20 > --- > end >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From mohta@necom830.hpcl.titech.ac.jp Mon Jun 27 06:58:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4A11E80E1 for ; Mon, 27 Jun 2011 06:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vUYpJO2DJ7Z for ; Mon, 27 Jun 2011 06:58:49 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id AAF3311E80CB for ; Mon, 27 Jun 2011 06:58:48 -0700 (PDT) Received: (qmail 5422 invoked from network); 27 Jun 2011 14:10:14 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 27 Jun 2011 14:10:14 -0000 Message-ID: <4E088C77.50802@necom830.hpcl.titech.ac.jp> Date: Mon, 27 Jun 2011 22:58:15 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Edward Lewis References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <4E00B3F2.9030204@necom830.hpcl.titech.ac.jp> <4E011158.5050005@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 13:58:49 -0000 Edward Lewis wrote: >> You are saying DNS operators know nothing about the very basic >> (thus, classical) points of database maintenance. > > You have a vivid imagination. > > What I am saying is that operators, other than me, have proposed > updating the tired old definition of IXFR based on what is see in > practice today. Operators may find problems not properly handled by the current protocol and may also propose a solution. However, it does not mean that the problems are real nor that the solution is the best one. Thus, we are having an operational discussion, here. > And I am agreeing that there is a reason to do so. You may or may not join the discussion. However, a purely imaginary example of yours with unrealistic assumptions is merely harmful. > Times > have changed and older definitions sometimes need to be brought up to > current standards. Sure. If only there were convincing real world examples... > In addition, you yourself said yesterday that parts of RFC 1995 were > left somewhat unfinished No. Masataka Ohta From hallam@gmail.com Mon Jun 27 07:10:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D821F8566; Mon, 27 Jun 2011 07:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEaF2otLA2Oc; Mon, 27 Jun 2011 07:10:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE1D21F86EC; Mon, 27 Jun 2011 06:14:47 -0700 (PDT) Received: by ywp31 with SMTP id 31so2788011ywp.31 for ; Mon, 27 Jun 2011 06:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5MNCDsJLeqoAn9sE1c0yp6JKH4djaQ+OuncQ5N6pw0s=; b=TXDHKXqL92aUgH++gPWLgfZe4t3jBV2oO6KrgAEMsjjQijipBd0GO6ZUKr8fVp8fgW EJXCuqnQNMakgehBFNH0ep/ufexGmVN8OUyqqpx67NA/3FAt8Okg2YgsHw5hQhCVjQ6B E/GrYidveXX/SdD2oGrakZi5CMgPLbQOypWDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J05mumyjfJYSmI4FPAMHqHN0PqsHNuy7onoNcQ65Bzml0QeAXx/Y16om5w9MReo4re fW7qzNNloTjDf3T3nQtoeIbOvmsiu5YDvV/e3jn6S9mhsAoTKvfBU++ZSlecsds7dbWc yikjrCzNeaFwL0f7dwsjsxqT97lK1T3sMPsuE= MIME-Version: 1.0 Received: by 10.101.186.21 with SMTP id n21mr1030305anp.18.1309180387567; Mon, 27 Jun 2011 06:13:07 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Mon, 27 Jun 2011 06:13:07 -0700 (PDT) In-Reply-To: <1309171065.2040.7.camel@localhost> References: <1309115504.2118.69.camel@localhost> <821uyfish3.fsf@mid.bfk.de> <1309171065.2040.7.camel@localhost> Date: Mon, 27 Jun 2011 09:13:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=001636c92acef2a97b04a6b14fc6 Cc: dane , dnsext@ietf.org Subject: Re: [dnsext] (Client deployment of DANE positive assertions) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:10:58 -0000 --001636c92acef2a97b04a6b14fc6 Content-Type: text/plain; charset=ISO-8859-1 What I see there is a tracking bug. Stating that 'Mozilla intends to do X' is pretty much like saying 'IETF intends to do X', The facts behind the statement can range from one person involved in the organization intending to do something and an actual commitment to actual code. Getting stuff done in browsers is hard. There a billions of them out there. That is why I still think that Web Services is the place to start. There are lots of Web Services, there are new ones being developed all the time and very few of them have any real security model at all. On Mon, Jun 27, 2011 at 6:37 AM, Matt McCutchen wrote: > On Mon, 2011-06-27 at 08:33 +0000, Florian Weimer wrote: > > * Matt McCutchen: > > > > > I'm looking forward to DANE positive assertions making TLS server > > > deployment significantly more convenient. > > > > Is there any browser vendor buy-in for this type of functionality? > > > > My gut feeling is that this is extremely unrealistic and will not > > happen. > > Chromium accepts stapled CAA-RP RRsets > (http://www.imperialviolet.org/2011/06/16/dnssecchrome.html), and > Mozilla is planning to follow suit > (https://bugzilla.mozilla.org/show_bug.cgi?id=589537). Hopefully they > switch to the DANE TLSA format when it is standardized. The stapling is > an important implementation question but irrelevant to the security of > positive assertions. > > -- > Matt > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --001636c92acef2a97b04a6b14fc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What I see there is a tracking bug.

Stating that 'Mo= zilla intends to do X' is pretty much like saying 'IETF intends to = do X', The facts behind the statement can range from one person involve= d in the organization intending to do something and an actual commitment to= actual code.


Getting stuff done in browsers is hard. = There a billions of them out there. That is why I still think that Web Serv= ices is the place to start. There are lots of Web Services, there are new o= nes being developed all the time and very few of them have any real securit= y model at all.


On Mon, Jun 27, 2011 at = 6:37 AM, Matt McCutchen <matt@mattmccutchen.net> wrote:
On Mon, 2011-06-27 at 08:33 +0000, Florian Weimer wrote:
> * Matt McCutchen:
>
> > I'm looking forward to DANE positive assertions making TLS se= rver
> > deployment significantly more convenient.
>
> Is there any browser vendor buy-in for this type of functionality?
>
> My gut feeling is that this is extremely unrealistic and will not
> happen.

Chromium accepts stapled CAA-RP RRsets
(http://www.imperialviolet.org/2011/06/16/dnssecchrome.html), and
Mozilla is planning to follow suit
(https://bugzilla.mozilla.org/show_bug.cgi?id=3D589537). =A0= Hopefully they
switch to the DANE TLSA format when it is standardized. =A0The stapling is<= br> an important implementation question but irrelevant to the security of
positive assertions.

--
Matt

_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



--
Website: http://hallambaker.com/

--001636c92acef2a97b04a6b14fc6-- From mohta@necom830.hpcl.titech.ac.jp Mon Jun 27 07:11:52 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE9C21F864D for ; Mon, 27 Jun 2011 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYqCAXrwT58A for ; Mon, 27 Jun 2011 07:11:51 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 2894721F85C0 for ; Mon, 27 Jun 2011 07:11:51 -0700 (PDT) Received: (qmail 5540 invoked from network); 27 Jun 2011 14:23:25 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 27 Jun 2011 14:23:25 -0000 Message-ID: <4E088F8E.2080908@necom830.hpcl.titech.ac.jp> Date: Mon, 27 Jun 2011 23:11:26 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: dnsext@ietf.org References: <1309115504.2118.69.camel@localhost> In-Reply-To: <1309115504.2118.69.camel@localhost> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 14:11:52 -0000 Matt McCutchen wrote: > I'm looking forward to DANE positive assertions making TLS server > deployment significantly more convenient. More generally, DNSSEC holds > enormous potential utility as a repository of integrity-protected > authoritative information about DNS names, including configuration for > new opt-in security schemes. However, each of these schemes may > increase the degree of exposure to malfeasance by the DNS operator It is merely that PKIs, in general, are untrustworthy, because trusted third parties (CAs, DNS operators, etc.) are not really trustworthy. As you recognize TLS, a PKI, untrustworthy, you hope DNS, another PKI, can make it trustworthy, only to find that a combination of untrustworthy PKIs is still untrustworthy. If you define weak security feeling of security achieved by blindly believing some infrastructure (CAs, DNS operators, etc.) secure, PKIs (including TLS and DNSSEC) are merely weakly secure, that is, as secure as plain DNS. Masataka Ohta From pgut001@login01.cs.auckland.ac.nz Mon Jun 27 02:04:42 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA421F8644; Mon, 27 Jun 2011 02:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldHSpoLbTp+Q; Mon, 27 Jun 2011 02:04:40 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80521F85C5; Mon, 27 Jun 2011 02:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1309165481; x=1340701481; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20fweimer@bfk.de,=20matt@mattmccutchen.net|Subject: =20Re:=20[dane]=20[dnsext]=20Trustworthiness=20of=20DNSSE C=20data|Cc:=20dane@ietf.org,=20dnsext@ietf.org |In-Reply-To:=20<821uyfish3.fsf@mid.bfk.de>|Message-Id: =20|Date: =20Mon,=2027=20Jun=202011=2021:04:29=20+1200; bh=Jc8vNnQ83+F3+6gLoQG9WL7PaXZnLGKY1tDDVTw119A=; b=FnrLTUPjl1rv08IBbnZYFUiEEE492opf+2Sh0sqynwW0gf0QqZdebX9g Many+Lf5m53AxLA5HHf4xO2mVovwzTf4lgJJQJxEk/XKQRf7YTbXZN42G 59NGDQ+uxMfYonsAlWUBcEgtt+x7umvO7q0/HTvvD3ytZSgFYTnlWvwbD Q=; X-IronPort-AV: E=Sophos;i="4.65,431,1304251200"; d="scan'208";a="69185445" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Jun 2011 21:04:30 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qb7k5-0003y3-Iy; Mon, 27 Jun 2011 21:04:29 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qb7k5-0005OB-RA; Mon, 27 Jun 2011 21:04:29 +1200 From: Peter Gutmann To: fweimer@bfk.de, matt@mattmccutchen.net In-Reply-To: <821uyfish3.fsf@mid.bfk.de> Message-Id: Date: Mon, 27 Jun 2011 21:04:29 +1200 X-Mailman-Approved-At: Mon, 27 Jun 2011 07:45:43 -0700 Cc: dnsext@ietf.org, dane@ietf.org Subject: Re: [dnsext] [dane] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 09:04:42 -0000 Florian Weimer writes: >* Matt McCutchen: >> I'm looking forward to DANE positive assertions making TLS server >> deployment significantly more convenient. > >My gut feeling is that this is extremely unrealistic and will not happen. I was tempted to reply to the orignial message with "And I'm looking forward to Cindy Crawford popping out of thin air and falling into my lap. I guess we're both in for some disappointment" :-), but felt I'd wait for someone else to say something... Peter. From hallam@gmail.com Mon Jun 27 08:17:51 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106D711E810B for ; Mon, 27 Jun 2011 08:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE23-QatJQkV for ; Mon, 27 Jun 2011 08:17:50 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C59B11E80E6 for ; Mon, 27 Jun 2011 08:17:48 -0700 (PDT) Received: by gya6 with SMTP id 6so844057gya.31 for ; Mon, 27 Jun 2011 08:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mKV2F1XzMKZb7WEDZ0hRiVVimszNrrpRC1ulY3q4nEY=; b=FE1TJZlXln0WkpgRoQd45GTqEaRPWkwV5H4uP6E/KUY7kovdTECSV6uUWHibFG0FP3 6AjQuQdjC2iKIYmQRJS+ET42RbrRSO3MEZbhT4gVqQNbRUz8zE35+5Qy8OTVutEPwg3+ +KV71lxjaZ+XimvX5SAFxssfhtZrtBstIlkt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jRL3ZSZ3Ure9ecuneKAVLwS1baaxA7hDBDHXejUddZE5KeVAjxcN8g40+0CMWXQq2+ xkJ8q14Rs8kRdRGGL8rTZHTMqUh/PZoiC8gsM3cI9EVFZ0thtXvZEJiU/18WIamnPR85 5rzzghBqVovoqKfwWNAaRm+B8OVllYW1OEQis= MIME-Version: 1.0 Received: by 10.100.249.3 with SMTP id w3mr6817361anh.40.1309187866700; Mon, 27 Jun 2011 08:17:46 -0700 (PDT) Received: by 10.100.144.16 with HTTP; Mon, 27 Jun 2011 08:17:46 -0700 (PDT) In-Reply-To: <4E088F8E.2080908@necom830.hpcl.titech.ac.jp> References: <1309115504.2118.69.camel@localhost> <4E088F8E.2080908@necom830.hpcl.titech.ac.jp> Date: Mon, 27 Jun 2011 11:17:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Masataka Ohta Content-Type: multipart/alternative; boundary=0016369fa252bd2d7d04a6b30d75 Cc: dnsext@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 15:17:51 -0000 --0016369fa252bd2d7d04a6b30d75 Content-Type: text/plain; charset=ISO-8859-1 Security is risk reduction, not risk elimination. Lots of people who comment on PKI and PK based security fail to understand that fact. There is no point in spending $100 million to protect an asset worth $1. And there is little point in protecting the content of political messages if you don't also have a mechanism to prevent traffic analysis. The existing PKI was designed to perform a particular task and it has served that precise function with almost 100% success. I am not aware of any breach of any PKI infrastructure that has lead to an actual monetary loss. The losses that we have seen have come from end entity keys being compromised (e.g. stuxnet) On Mon, Jun 27, 2011 at 10:11 AM, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote: > Matt McCutchen wrote: > > > I'm looking forward to DANE positive assertions making TLS server > > deployment significantly more convenient. More generally, DNSSEC holds > > enormous potential utility as a repository of integrity-protected > > authoritative information about DNS names, including configuration for > > new opt-in security schemes. However, each of these schemes may > > increase the degree of exposure to malfeasance by the DNS operator > > It is merely that PKIs, in general, are untrustworthy, because > trusted third parties (CAs, DNS operators, etc.) are not really > trustworthy. > > As you recognize TLS, a PKI, untrustworthy, you hope DNS, another > PKI, can make it trustworthy, only to find that a combination of > untrustworthy PKIs is still untrustworthy. > > If you define weak security feeling of security achieved by blindly > believing some infrastructure (CAs, DNS operators, etc.) secure, > PKIs (including TLS and DNSSEC) are merely weakly secure, that is, > as secure as plain DNS. > > Masataka Ohta > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Website: http://hallambaker.com/ --0016369fa252bd2d7d04a6b30d75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Security is risk reduction, not risk elimination.

Lots o= f people who comment on PKI and PK based security fail to understand that f= act.


There is no point in spending = $100 million to protect an asset worth $1.

And there is little point in protecting the content of = political messages if you don't also have a mechanism to prevent traffi= c analysis.


The existing PKI was de= signed to perform a particular task and it has served that precise function= with almost 100% success. I am not aware of any breach of any PKI infrastr= ucture that has lead to an actual monetary loss. The losses that we have se= en have come from end entity keys being compromised (e.g. stuxnet)



On Mon, Jun 27, 2011= at 10:11 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> = wrote:
Matt McCutchen wrote:

> I'm looking forward to DANE positive assertions making TLS server<= br> > deployment significantly more convenient. =A0More generally, DNSSEC ho= lds
> enormous potential utility as a repository of integrity-protected
> authoritative information about DNS names, including configuration for=
> new opt-in security schemes. =A0However, each of these schemes may
> increase the degree of exposure to malfeasance by the DNS operator

It is merely that PKIs, in general, are untrustworthy, because
trusted third parties (CAs, DNS operators, etc.) are not really
trustworthy.

As you recognize TLS, a PKI, untrustworthy, you hope DNS, another
PKI, can make it trustworthy, only to find that a combination of
untrustworthy PKIs is still untrustworthy.

If you define weak security feeling of security achieved by blindly
believing some infrastructure (CAs, DNS operators, etc.) secure,
PKIs (including TLS and DNSSEC) are merely weakly secure, that is,
as secure as plain DNS.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0Masataka Ohta
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext



--
Website: http://hallambaker.com/

--0016369fa252bd2d7d04a6b30d75-- From mohta@necom830.hpcl.titech.ac.jp Tue Jun 28 06:49:45 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD8F228015 for ; Tue, 28 Jun 2011 06:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKi90QK3ZbKG for ; Tue, 28 Jun 2011 06:49:45 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 9F3F222800E for ; Tue, 28 Jun 2011 06:49:44 -0700 (PDT) Received: (qmail 18551 invoked from network); 28 Jun 2011 14:01:23 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 28 Jun 2011 14:01:23 -0000 Message-ID: <4E09DBDE.90406@necom830.hpcl.titech.ac.jp> Date: Tue, 28 Jun 2011 22:49:18 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <1309115504.2118.69.camel@localhost> <4E088F8E.2080908@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Trustworthiness of DNSSEC data X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 13:49:45 -0000 Phillip Hallam-Baker wrote: > Security is risk reduction, not risk elimination. > > Lots of people who comment on PKI and PK based security fail to understand > that fact. The important point you fail to understand is that such people want to have the end to end security not relying on intelligent intermediate entities such as CAs. PK is secure end to end, as long as an end obtains a public key of its peer directly from the peer. > There is no point in spending $100 million to protect an asset worth $1. That's exactly why DNSSEC has no point. > The existing PKI was designed to perform a particular task and it has served > that precise function with almost 100% success. I am not aware of any breach > of any PKI infrastructure that has lead to an actual monetary loss. The > losses that we have seen have come from end entity keys being compromised > (e.g. stuxnet) With stuxnet, you are saying any server less protected than servers in nuclear plants will be compromised, which means most PKI is just insecure. Masataka Ohta From snwells82@gmail.com Tue Jun 28 12:23:16 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C1611E818B for ; Tue, 28 Jun 2011 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tQlZlE5nwBc for ; Tue, 28 Jun 2011 12:23:16 -0700 (PDT) Received: from mail-vx0-f194.google.com (mail-vx0-f194.google.com [209.85.220.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2002511E8100 for ; Tue, 28 Jun 2011 12:23:15 -0700 (PDT) Received: by vxc11 with SMTP id 11so42813vxc.1 for ; Tue, 28 Jun 2011 12:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QlyS9z2GysQeRwdyOGzNiFhLtToHTo65IbxQn7jLcFw=; b=U/lcLgX87nIw6K59Nq5fW0m5jnSLiRsz2BGJSo0ibv3BEchGzriCwIrkEac5NjTvw6 OlG15eMtjGKy5WWtFMWDnXMch+cAGkTIlWQ8AA5XOtvNyaksciIxr0rd5yGvkq6XvhGD Z1HUSaPHAF8mZ4zogTJgs4sNhboloEZB30nKc= MIME-Version: 1.0 Received: by 10.220.48.203 with SMTP id s11mr1836700vcf.112.1309288995079; Tue, 28 Jun 2011 12:23:15 -0700 (PDT) Received: by 10.220.198.200 with HTTP; Tue, 28 Jun 2011 12:23:15 -0700 (PDT) In-Reply-To: References: <396B6F93A3774482A4DFAFD458C56BA0@local> Date: Tue, 28 Jun 2011 12:23:15 -0700 Message-ID: From: Sean Wells To: Edward Lewis Content-Type: multipart/alternative; boundary=0016e646026675c6f204a6ca9922 Cc: dnsext@ietf.org Subject: Re: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 19:23:16 -0000 --0016e646026675c6f204a6ca9922 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 21, 2011 at 6:38 AM, Edward Lewis wrote: > At 8:57 +0100 6/21/11, George Barwood wrote: > > It seems that the signer name has to be down-cased for this signature to >> verify. >> >> However this is contrary to http://tools.ietf.org/html/** >> draft-ietf-dnsext-dnssec-bis-**updates-12#section-5.1 >> >> When canonicalizing DNS names, DNS names in the RDATA section of NSEC >> and RRSIG resource records are not downcased. >> >> But existing validators don't fail, so it seems they do down-case. >> >> Hence I'm confused. Is dnssec-bis-updates "wrong"? >> > > This discussion came up recently on some list. The answer is that the case > doesn't matter, uh, in this case. The only time a domain name in the RDATA > has to be down cased is when it can be compressed. > > The reason is - without compression, the RR will appear in a response the > same as it was generated (outside of forgeries, which is what DNSSEC is > about). With compression, the case used for the domain name in the RDATA > depends on what comes first in the response. > > I am a little confused about this. As per RFC 4034, the signer name cannot be compressed and for signature calculation it should be lower case. So, it is possible that the received RRSIG has "ORG" in the signer name whereas the signature was computed with "org" ? > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=**-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=** > -=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > I'm overly entertained. > > ______________________________**_________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/dnsext > -- Sean --0016e646026675c6f204a6ca9922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 21, 2011 at 6:38 AM, Edward = Lewis <Ed.Lewi= s@neustar.biz> wrote:
At 8:57 +0100 6/21/11, George Barwood wrote:

It seems that the signer name has to be down-cased for this signature to ve= rify.

However this is contrary to http://tools.= ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section= -5.1

=A0 When canonicalizing DNS names, DNS names in the RDATA section of NSEC<= br> =A0 and RRSIG resource records are not downcased.

But existing validators don't fail, so it seems they do down-case.

Hence I'm confused. Is dnssec-bis-updates "wrong"?

This discussion came up recently on some list. =A0The answer is that the ca= se doesn't matter, uh, in this case. =A0The only time a domain name in = the RDATA has to be down cased is when it can be compressed.

The reason is - without compression, the RR will appear in a response the s= ame as it was generated (outside of forgeries, which is what DNSSEC is abou= t). =A0With compression, the case used for the domain name in the RDATA dep= ends on what comes first in the response.

I am a little confused about this. As per RFC = 4034, the signer name cannot be compressed and for signature calculation it= should be lower case. So, it is possible that the received RRSIG has "= ;ORG" in the signer name whereas the signature was computed with "= ;org" ?
=A0
--
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-
Edward Lewis
NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice messag= e at +1-571-434-5468

I'm overly entertained.

_______________________________________________
dnsext mailing list
dnsext@ietf.org = https://www.ietf.org/mailman/listinfo/dnsext



--
Sean
--0016e646026675c6f204a6ca9922-- From Ed.Lewis@neustar.biz Tue Jun 28 13:19:13 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C4211E8142 for ; Tue, 28 Jun 2011 13:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3gPerkPUU+E for ; Tue, 28 Jun 2011 13:19:13 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id F39AE11E80DB for ; Tue, 28 Jun 2011 13:19:12 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5SKJ9xo061142; Tue, 28 Jun 2011 16:19:09 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.108] by Work-Laptop-2.local (PGP Universal service); Tue, 28 Jun 2011 16:19:11 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 28 Jun 2011 16:19:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <396B6F93A3774482A4DFAFD458C56BA0@local> Date: Tue, 28 Jun 2011 16:18:12 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:19:14 -0000 At 12:23 -0700 6/28/11, Sean Wells wrote: >I am a little confused about this. As per RFC 4034, the signer name cannot >be compressed and for signature calculation it should be lower case. So, >it is possible that the received RRSIG has "ORG" in the signer name whereas >the signature was computed with "org" ? Where in RFC 4034 does it say "it should be in lower case."? Sect 6.2, item 3 does not include RRSIG, item 2 applies to the owner field only. Sect 3.1.7 does not mention a lower case requirement. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From brian.peter.dickson@gmail.com Tue Jun 28 13:47:52 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D23D11E81BC for ; Tue, 28 Jun 2011 13:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK-UwfnB1OOp for ; Tue, 28 Jun 2011 13:47:51 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7A511E8100 for ; Tue, 28 Jun 2011 13:47:51 -0700 (PDT) Received: by fxe4 with SMTP id 4so812561fxe.27 for ; Tue, 28 Jun 2011 13:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y89ZSuh66+WsA4hcNiaRWfp0vlLDWGwM2/jr/9jXO6g=; b=YHTSNczqVL0xZE87/BNDT5wDK1xPRauUfJRXDjhMA1FiRdfhFFvgccHvQOYF3nO4Oi /hEVUtSt8Jotco/4zJjsrcfD61LFxcuRozpHxqnOuQ/O3D+tIoAp7uvdKPdEcLC8/llK dJ1dTDIYB4nEY2i5zuKwACDyc1gCaxsDk9jOQ= MIME-Version: 1.0 Received: by 10.223.57.5 with SMTP id a5mr11379832fah.90.1309294070384; Tue, 28 Jun 2011 13:47:50 -0700 (PDT) Received: by 10.223.115.145 with HTTP; Tue, 28 Jun 2011 13:47:50 -0700 (PDT) In-Reply-To: References: <396B6F93A3774482A4DFAFD458C56BA0@local> Date: Tue, 28 Jun 2011 16:47:50 -0400 Message-ID: From: Brian Dickson To: Edward Lewis Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:47:52 -0000 On Tue, Jun 28, 2011 at 4:18 PM, Edward Lewis wrote: > At 12:23 -0700 6/28/11, Sean Wells wrote: > >> I am a little confused about this. As per RFC 4034, the signer name cannot >> be compressed and for signature calculation it should be lower case. So, >> it is possible that the received RRSIG has "ORG" in the signer name >> whereas >> the signature was computed with "org" ? > > Where in RFC 4034 does it say "it should be in lower case."? 3.1.8.1 says "RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form"... That, combined with 6.2 subitem 2, gives the requirement for lowercase. > Sect 6.2, item 3 does not include RRSIG, item 2 applies to the owner field > only. > Sect 3.1.7 does not mention a lower case requirement. I agree that it should have been explicitly put into 3.1.7, to be more clear. Brian From snwells82@gmail.com Tue Jun 28 13:54:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49B921F8647 for ; Tue, 28 Jun 2011 13:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=1.833, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kdYir255fNK for ; Tue, 28 Jun 2011 13:54:54 -0700 (PDT) Received: from mail-vx0-f194.google.com (mail-vx0-f194.google.com [209.85.220.194]) by ietfa.amsl.com (Postfix) with ESMTP id F17A021F85E8 for ; Tue, 28 Jun 2011 13:54:53 -0700 (PDT) Received: by vxc11 with SMTP id 11so47959vxc.1 for ; Tue, 28 Jun 2011 13:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pznVWtUUJ9Cy2v5aZbiQ1I3oy3fJvCBgVwn5kqyPb/A=; b=AvxmhIKtUdRZSYSi09eNqwEdVX5ikkJAt4Jfq2LYMKX+s6ITM4QOGQiWb9Qe9KAV2D plq5CcNMKIot39gW4ox2A/VM06+RfWnWNH5gHu+FAlGKcpR1bPw69APTJ7n8uZ9qmRgI ncbjCEXa/obiwomkCda9NQeUWeqosl/oK432E= MIME-Version: 1.0 Received: by 10.220.213.202 with SMTP id gx10mr6209vcb.77.1309294491920; Tue, 28 Jun 2011 13:54:51 -0700 (PDT) Received: by 10.220.198.200 with HTTP; Tue, 28 Jun 2011 13:54:51 -0700 (PDT) In-Reply-To: References: <396B6F93A3774482A4DFAFD458C56BA0@local> Date: Tue, 28 Jun 2011 13:54:51 -0700 Message-ID: From: Sean Wells To: Edward Lewis Content-Type: multipart/alternative; boundary=bcaec54eef9a18e92704a6cbe150 Cc: dnsext@ietf.org Subject: Re: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:54:54 -0000 --bcaec54eef9a18e92704a6cbe150 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 28, 2011 at 1:18 PM, Edward Lewis wrote: > At 12:23 -0700 6/28/11, Sean Wells wrote: > > I am a little confused about this. As per RFC 4034, the signer name cannot >> be compressed and for signature calculation it should be lower case. So, >> it is possible that the received RRSIG has "ORG" in the signer name >> whereas >> the signature was computed with "org" ? >> > > Where in RFC 4034 does it say "it should be in lower case."? > > Sect 6.2, item 3 does not include RRSIG, item 2 applies to the owner field > only. > Sect 3.1.7 does not mention a lower case requirement. > > Section 6.2 item 3: 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters; Any implementation based on this would have replaced the signer name with lower case. With the example George gave, it does not validate without replacing "US" with "us" when calculating the signature. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=**-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=** > -=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > I'm overly entertained. > -- Sean --bcaec54eef9a18e92704a6cbe150 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 28, 2011 at 1:18 PM, Edward = Lewis <Ed.Lewi= s@neustar.biz> wrote:
At 12:23 -0700 6/28/11, Sean Wells wrote:

I am a little confused about this. As per RFC 4034, the signer name cannot<= br> be compressed and for signature calculation it should be lower case. So, it is possible that the received RRSIG has "ORG" in the signer na= me whereas
the signature was computed with "org" ?

Where in RFC 4034 does it say "it should be in lower case."?

Sect 6.2, item 3 does not include RRSIG, item 2 applies to the owner field = only.
Sect 3.1.7 does not mention a lower case requirement.

Section 6.2 item 3:

3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
       the DNS names contained within the RDATA are replaced by the
       corresponding lowercase US-ASCII letters;
Any implementation based on this w=
ould have replaced the signer name with lower case. With the example George=
 gave, it does not validate without replacing "US" with "us&=
quot; when calculating the signature.
=A0
--
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-
Edward Lewis
NeuStar =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0You can leave a voice messag= e at +1-571-434-5468

I'm overly entertained.



--
Sean
--bcaec54eef9a18e92704a6cbe150-- From jaap@bartok.nlnetlabs.nl Tue Jun 28 14:32:35 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA48F11E811C for ; Tue, 28 Jun 2011 14:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDuhYRYWSErc for ; Tue, 28 Jun 2011 14:32:35 -0700 (PDT) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by ietfa.amsl.com (Postfix) with ESMTP id A7DB611E8100 for ; Tue, 28 Jun 2011 14:32:34 -0700 (PDT) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id p5SLWSmi004896; Tue, 28 Jun 2011 23:32:28 +0200 (CEST) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <201106282132.p5SLWSmi004896@bartok.nlnetlabs.nl> To: Sean Wells In-reply-to: References: <396B6F93A3774482A4DFAFD458C56BA0@local> Comments: In-reply-to Sean Wells message dated "Tue, 28 Jun 2011 13:54:51 -0700." Date: Tue, 28 Jun 2011 23:32:28 +0200 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bartok.nlnetlabs.nl [127.0.0.1]); Tue, 28 Jun 2011 23:32:28 +0200 (CEST) Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:32:35 -0000 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in the DNS names contained within the RDATA are replaced by the corresponding lowercase US-ASCII letters; Any implementation based on this would have replaced the signer name with lower case. With the example George gave, it does not validate without replacing "US" with "us" when calculating the signature. It doesn't say you have to do this replacement but qor order the RR's as if this replacement took place. jaap From Ed.Lewis@neustar.biz Tue Jun 28 15:29:39 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ECD21F8736 for ; Tue, 28 Jun 2011 15:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqIG7XPpEp4f for ; Tue, 28 Jun 2011 15:29:38 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id D3B4E21F8731 for ; Tue, 28 Jun 2011 15:29:37 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p5SMTYSl061978; Tue, 28 Jun 2011 18:29:35 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.108] by Work-Laptop-2.local (PGP Universal service); Tue, 28 Jun 2011 18:29:35 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 28 Jun 2011 18:29:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <396B6F93A3774482A4DFAFD458C56BA0@local> Date: Tue, 28 Jun 2011 18:29:31 -0400 To: From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-902822321==_ma============" X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4 Cc: Edward Lewis Subject: Re: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 22:29:39 -0000 --============_-902822321==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 13:54 -0700 6/28/11, Sean Wells wrote: >3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, > HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, > SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in > the DNS names contained within the RDATA are replaced by the > corresponding lowercase US-ASCII letters; OK - I missed the RRSIG in the middle of that. (I keep getting confused between DNSKEY and RRSIG in this thread.) US has been signed this way since 2009. Haven't heard a validation problem related to it. There are a few factors here. 1 - (Protocol designer speaking) It really doesn't matter what the case is because there's no compression, i.e., the requirement is wrong. However it is a requirement, I'll grant that. But there's some history, that list has been problematic as well as a misunderstanding of the list of compressible RR types over time. There happens to be an errata lodged against that very list. 2 - (Hack implementer/operator speaking) It's not apparent to me that validators aren't replacing the domain name with the down cased version. What you are seeing is the presentation/print format which is trying to preserve case. I haven't read the unbound and named code to see what they do. I know that it is a performance killer to copy data. But validators pretty much have to - to undo compression, to sort into canonical order and to assemble the plaintext buffer. One implementation technique is to preserve the original format, create a workspace, make it canonical, evaluate, and delete once the validation process finishes. The end user may never see the canonical form. If there were a bug here, I know we'd have seen it already... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. --============_-902822321==_ma============ Content-Type: text/html; charset="us-ascii" Re: [dnsext] RRSIG signer name down-casing
At 13:54 -0700 6/28/11, Sean Wells wrote:

>3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
>       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
>       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
>       the DNS names contained within the RDATA are replaced by the
>       corresponding lowercase US-ASCII letters;

OK - I missed the RRSIG in the middle of that.  (I keep getting confused between DNSKEY and RRSIG in this thread.)

US has been signed this way since 2009.  Haven't heard a validation problem related to it.  There are a few factors here.

1 - (Protocol designer speaking) It really doesn't matter what the case is because there's no compression, i.e., the requirement is wrong.  However it is a requirement, I'll grant that.  But there's some history, that list has been problematic as well as a misunderstanding of the list of compressible RR types over time.  There happens to be an errata lodged against that very list.

2 - (Hack implementer/operator speaking) It's not apparent to me that validators aren't replacing the domain name with the down cased version.  What you are seeing is the presentation/print format which is trying to preserve case.  I haven't read the unbound and named code to see what they do.

I know that it is a performance killer to copy data.  But validators pretty much have to - to undo compression, to sort into canonical order and to assemble the plaintext buffer.  One implementation technique is to preserve the original format, create a workspace, make it canonical, evaluate, and delete once the validation process finishes.  The end user may never see the canonical form.

If there were a bug here, I know we'd have seen it already...
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.
--============_-902822321==_ma============-- From snwells82@gmail.com Tue Jun 28 16:06:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D89421F865D for ; Tue, 28 Jun 2011 16:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.682 X-Spam-Level: X-Spam-Status: No, score=-4.682 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxfPtV+j9cSn for ; Tue, 28 Jun 2011 16:06:11 -0700 (PDT) Received: from mail-vx0-f194.google.com (mail-vx0-f194.google.com [209.85.220.194]) by ietfa.amsl.com (Postfix) with ESMTP id BD68E21F865C for ; Tue, 28 Jun 2011 16:06:10 -0700 (PDT) Received: by vxc11 with SMTP id 11so55451vxc.1 for ; Tue, 28 Jun 2011 16:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OF+XGWBM1aqRRtLtfq4OOX6mdNPmPr2BmGetXWqbWzo=; b=rXmPg8bcE4xOHNH9/61eh0vbaK7BQYMx5N+bWzNwyA4Z7OusKOlpr1gmO0BydONobn SSKWOGPR9tte2ONUO74+s7TX4MZ0pdM1Vt9DGEDyF8kSOaKJLn5HnYISUXGyTDa2Sbwi 0ct1nHV2hF9FRI/KdbOX9urJd1S++YbD6wDLI= MIME-Version: 1.0 Received: by 10.220.7.132 with SMTP id d4mr51630vcd.42.1309302369893; Tue, 28 Jun 2011 16:06:09 -0700 (PDT) Received: by 10.220.198.200 with HTTP; Tue, 28 Jun 2011 16:06:09 -0700 (PDT) In-Reply-To: References: <396B6F93A3774482A4DFAFD458C56BA0@local> Date: Tue, 28 Jun 2011 16:06:09 -0700 Message-ID: From: Sean Wells To: Edward Lewis Content-Type: multipart/alternative; boundary=000325572cb2a93c1b04a6cdb648 Cc: dnsext@ietf.org Subject: Re: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 23:06:11 -0000 --000325572cb2a93c1b04a6cdb648 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 28, 2011 at 3:29 PM, Edward Lewis wrote: > ** > At 13:54 -0700 6/28/11, Sean Wells wrote: > > >3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, > > HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, > > SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in > > the DNS names contained within the RDATA are replaced by the > > corresponding lowercase US-ASCII letters; > > OK - I missed the RRSIG in the middle of that. (I keep getting confused > between DNSKEY and RRSIG in this thread.) > > US has been signed this way since 2009. Haven't heard a validation problem > related to it. There are a few factors here. > > Because the implementation is converting to lower case. I tried this in a validator by not converting to lower case and it fails. > 1 - (Protocol designer speaking) It really doesn't matter what the case is > because there's no compression, i.e., the requirement is wrong. However it > is a requirement, I'll grant that. But there's some history, that list has > been problematic as well as a misunderstanding of the list of compressible > RR types over time. There happens to be an errata lodged against that very > list. > Ok, I see your point now. > 2 - (Hack implementer/operator speaking) It's not apparent to me that > validators aren't replacing the domain name with the down cased version. > What you are seeing is the presentation/print format which is trying to > preserve case. I haven't read the unbound and named code to see what they > do. > See above. > > I know that it is a performance killer to copy data. But validators pretty > much have to - to undo compression, to sort into canonical order and to > assemble the plaintext buffer. One implementation technique is to preserve > the original format, create a workspace, make it canonical, evaluate, and > delete once the validation process finishes. The end user may never see the > canonical form. > > If there were a bug here, I know we'd have seen it already... > There is no bug. Implementations must be converting to lower case. It is the dnssec-bis-updates that is incorrect. > ** > > -- > > ** > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -=-=-=- > Edward Lewis > NeuStar You can leave a voice message at > +1-571-434-5468 > > I'm overly entertained. > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > -- Sean --000325572cb2a93c1b04a6cdb648 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 28, 2011 at 3:29 PM, Edward = Lewis <Ed.Lewi= s@neustar.biz> wrote:
At 13:54 -0700 6/28/11, Sean Wells wrote:

>3.=A0 if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
>=A0=A0=A0=A0=A0=A0 HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
>=A0=A0=A0=A0=A0=A0 SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
>=A0=A0=A0=A0=A0=A0 the DNS names contained within the RDATA are replaced by the
>=A0=A0=A0=A0=A0=A0 corresponding lowercase US-ASCII letters;

OK - I missed the RRSIG in the middle of that.=A0 (I keep getting confused between DNSKEY and RRSIG in this thread.)

US has been signed this way since 2009.=A0 Haven't heard a validation problem related to it.=A0 There are a few factors here.

Because the implementation = is converting to lower case. I tried this in a validator by not converting = to lower case and it fails.
=A0
1 - (Protocol designer speaking) It really doesn't matter what the case is because there's no compression, i.e., the requirement is wrong.=A0 However it is a requirement, I'll grant that.=A0 But there's some history, that list has been problematic as well as a misunderstanding of the list of compressible RR types over time.=A0 There happens to be an errata lodged against that very list.
=A0
Ok, I see your point = now.
=A0
2 - (Hack implementer/operator speaking) It's not apparent to me that validators aren't replacing the domain name with the down cased version.=A0 What you are seeing is the presentation/print format which is trying to preserve case.=A0 I haven't read the unbound and named code to see what they do.
See above.
=A0

I know that it is a performance killer to copy data.=A0 But validators pretty much have to - to undo compression, to sort into canonical order and to assemble the plaintext buffer.=A0 One implementation technique is to preserve the original format, create a workspace, make it canonical, evaluate, and delete once the validation process finishes.=A0 The end user may never see the canonical form.

If there were a bug here, I know we'd have seen it already...
=A0
There is no bug.= Implementations must be converting to lower case. It is the dnssec-bis-upd= ates that is incorrect.
=A0
--=20
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-
Edward Lewis=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
NeuStar=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 You can leave a voice message at +1-571-434-5468

I'm overly entertained.

_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext




--
Sean
--000325572cb2a93c1b04a6cdb648-- From marka@isc.org Tue Jun 28 20:31:43 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E74511E809A for ; Tue, 28 Jun 2011 20:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL07aJsO-W4L for ; Tue, 28 Jun 2011 20:31:42 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 208CC11E8097 for ; Tue, 28 Jun 2011 20:31:42 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 7CACA5F98E7; Wed, 29 Jun 2011 03:31:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AC1D0216C7B; Wed, 29 Jun 2011 03:31:18 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4B41F1146EBD; Wed, 29 Jun 2011 13:31:15 +1000 (EST) To: Jaap Akkerhuis From: Mark Andrews References: <396B6F93A3774482A4DFAFD458C56BA0@local> <201106282132.p5SLWSmi004896@bartok.nlnetlabs.nl> In-reply-to: Your message of "Tue, 28 Jun 2011 23:32:28 +0200." <201106282132.p5SLWSmi004896@bartok.nlnetlabs.nl> Date: Wed, 29 Jun 2011 13:31:15 +1000 Message-Id: <20110629033115.4B41F1146EBD@drugs.dv.isc.org> Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] RRSIG signer name down-casing X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 03:31:43 -0000 In message <201106282132.p5SLWSmi004896@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr ites: > 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, > HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, > SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in > the DNS names contained within the RDATA are replaced by the > corresponding lowercase US-ASCII letters; > > Any implementation based on this would have replaced the signer name > with lower case. With the example George gave, it does not validate > without replacing "US" with "us" when calculating the signature. > > It doesn't say you have to do this replacement but qor order the > RR's as if this replacement took place. > > jaap When we implemented NSEC (RFC 3845) in named, well before RFC 4034 was written, we digested it as per RFC 2535/RFC 3597 (no downcasing). NSEC was *not* a type code roll of NXT. It was a new record that supports the listing of all possible types. RRSIG however was a type code roll of SIG (RFC 3755) and I missed making its signature generation compliant with RFC 3755 by not removing the downcasing of the signer's name. Others also missed doing this. The digest was built on the fly rather that by taking a complete RR and digesting that. RFC 3755 1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC RRs MUST NOT be compressed, 2) Embedded domain names in RRSIG and NSEC RRs are not downcased for purposes of DNSSEC canonical form and ordering nor for equality comparison, and 3) An RRSIG with a type-covered field of zero has undefined semantics. The meaning of such a resource record may only be defined by IETF Standards Action. RFC 4034 then took the list from RFC 3597, including errors, and extended it to add RRSIG and NSEC. This was not noticed until there was a post RFC 4034 implementation of DNSSECbis which immediately brought to light the issue with NSEC. It was then decided to correct RFC 4034 to bring it into line with RFC 3597 and correct the other defects in the list. No one however noticed that everyone had actually digested RRSIG's as described in RFC 4034 rather than RFC 3755. RFC 4034 was supposed to capture RFC 3755, not change it. The simplest way forward is to stay just downcase the signer when computing the digest of RRSIG. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From snwells82@gmail.com Thu Jun 30 12:18:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDF811E823C for ; Thu, 30 Jun 2011 12:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSQLPC02AFCU for ; Thu, 30 Jun 2011 12:18:24 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDA111E8201 for ; Thu, 30 Jun 2011 12:18:23 -0700 (PDT) Received: by vws12 with SMTP id 12so2280876vws.31 for ; Thu, 30 Jun 2011 12:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=YRmf5QQr9tEXoYIbxZED70eZmsPysx9JxBs4e4NXjA8=; b=kcLnEPS+7Q4hEnAyM1IA0Id44FEcSdb5o8+KVxhBMGY7rjBOQSyrPvWwVSDZ9P/Z5g TOBp6uAAtuwKqrbSXZfU7aR49bATi4VOabsaiKrx7G4GrVn4w/GEQShjnHSUn4YExNL1 0raosthL+ddeJHMzP6EpgkSdwROt2BThZYQ64= MIME-Version: 1.0 Received: by 10.52.160.68 with SMTP id xi4mr3267993vdb.106.1309461492974; Thu, 30 Jun 2011 12:18:12 -0700 (PDT) Received: by 10.220.198.200 with HTTP; Thu, 30 Jun 2011 12:18:12 -0700 (PDT) Date: Thu, 30 Jun 2011 12:18:12 -0700 Message-ID: From: Sean Wells To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=bcaec53f977922c3e904a6f2c3fc Subject: [dnsext] Insecure Delegation Proofs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 19:18:25 -0000 --bcaec53f977922c3e904a6f2c3fc Content-Type: text/plain; charset=ISO-8859-1 Hi, DNSSEC bis updates document states: [RFC4035] Section 5.2specifies that a validator, when proving a delegation is not secure, needs to check for the absence of the DS and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also needs to check for the presence of the NS bit in the matching NSEC (or NSEC3) RR (proving that there is, indeed, a delegation), or alternately make sure that the delegation is covered by an NSEC3 RR with the Opt-Out flag set. If this is not checked, spoofed unsigned delegations might be used to claim that an existing signed record is not signed. The last sentence is confusing: what is a "spoofed unsigned delegation" ? Let us say that there are two delegations one of which is secure. a.com is secure, so there is a DS record in com b.com is insecure, so there is a NSEC record for b.com in com with DS, SOA bits not set but the NS bit set. I am looking up the DS record for "a.com". The attacker is responding the NSEC record for b.com (or it was already in my cache). In this case, the owner name does not match the SNAME (a.com). I thought we checked the bitmap of the NSEC only if the owner name matches. This NSEC record might still be accepted depending on what is there in the "Next domain field". Is this the attack that is being described ? regards, Sean --bcaec53f977922c3e904a6f2c3fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

DNSSEC bis updates document states:

[RFC4035] Secti= on 5.2 specifies that a validator, when proving a
   delegation is not secu=
re, needs to check for the absence of the DS
   and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
   needs to check for the presence of the NS bit in the matching NSEC
   (or NSEC3) RR (proving that there is, indeed, a delegation), or
   alternately make sure that the delegation is covered by an NSEC3 RR
   with the Opt-Out flag set.  If this is not checked, spoofed unsigned
   delegations might be used to claim that an existing signed record is
   not signed.


The last sentence is confusing: what is a "spoofed unsigned delegation=
" ? Let us say that there are two delegations one of which is secure. =


a=
.com is secure, so there is a DS record in com
b.com is insecure, so there is a NSEC record f=
or b.com in com with DS, SOA bits not set but =
the NS bit set.

I am looking up the DS rec=
ord for "a.com". The attacker is res=
ponding the NSEC record for b.com (or it was a=
lready in my cache). In this case, the owner name does not match the SNAME =
(a.com). I thought we checked the bitmap of th=
e NSEC only if the owner name matches. This NSEC record might still be acce=
pted depending on what is there in the "Next domain field". Is th=
is the attack that is being described ?

regards,
Sean
--bcaec53f977922c3e904a6f2c3fc-- From brian.peter.dickson@gmail.com Thu Jun 30 14:30:28 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEF221F8848 for ; Thu, 30 Jun 2011 14:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoYWkJspC1f7 for ; Thu, 30 Jun 2011 14:30:27 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id EEEC221F883F for ; Thu, 30 Jun 2011 14:30:26 -0700 (PDT) Received: by fxe4 with SMTP id 4so3404509fxe.27 for ; Thu, 30 Jun 2011 14:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+OL3x4ghiZNq4SlCaEJuyd+c87Z/MtFDsXFfz4WKO2M=; b=pfQR3t7uRV0wuALv2e7gn3YF4R51kE1xvTCBUp9W7PXO0DF7lLJ9WzoWq2iDPHN8al Fyw7Y1LLnjSbYyubpR+PzIo7uG4YZn0ofKZL2KpRWNxw3wkcNYeKLVjeLH5wNLhl/rW0 Dhg16zqGSxXz2hfj+B6iedMUoAuwDxg6KEeSs= MIME-Version: 1.0 Received: by 10.223.87.69 with SMTP id v5mr3671901fal.147.1309469426038; Thu, 30 Jun 2011 14:30:26 -0700 (PDT) Received: by 10.223.115.145 with HTTP; Thu, 30 Jun 2011 14:30:25 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jun 2011 17:30:25 -0400 Message-ID: From: Brian Dickson To: Sean Wells Content-Type: text/plain; charset=ISO-8859-1 Cc: dnsext@ietf.org Subject: Re: [dnsext] Insecure Delegation Proofs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 21:30:28 -0000 No, the attack in question is NSEC3 specific. NSEC3 records, when opt-out is in use, only existence for NS records that also have a DS (or for non-NS records). In large, delegation-only zones, like most big TLDs, the ramp-up of DNSSEC means that those zones will be relatively sparse from a NSEC3 perspective. Most of the delegations will be insecure. Here, insecure means, "has no DS record". For an insecure NS RRset, the only DNSSEC records at that node could be NSEC(3) and the RRSIG(NSEC(3)). If NSEC3 with opt-out is used for the zone, there will be no signatures at all. If NSEC3 without opt-out is used, there *will* be an NSEC3 and RRSIG(NSEC3). The "opt-out" means the "next-hash" is the "next-hash-of-anything-which-is-not-an-NS-with-no-DS". Since the insecure NS records are not signed (at all!), they can be spoofed. (IMHO, the lack of signature on NS (without DS) is uncool in the extreme. Having NS RRSIGs, even though they are not authoritative, would still have been compatible with opt-out. But that ship has sailed, as they say.) The attack is, to over-write a *signed* NS (with DS), by an unsigned NS (with no DS or any other DNSSEC record). The defense is, to check the hash of any unsigned NS, and if it matches an NSEC3 with opt-out, it clearly is a forgery and should be discarded. The *real* challenge is, if the attacked owner-name has not yet been fetched into the cache, that it becomes a resource-hit to check for this (or race condition if the check isn't done - which is why it needs to be done). To prevent this NS hijacking, the NS has to be hashed. If the previous NSEC3 entry before it, does not cover it (i.e. have a next-hash greater than its hash), subsequent NSEC3 (hashed) RRs need to be retrieved, until the covering NSEC3 is found. If there is a covering NSEC3, the insecure and unsigned delegation can be considered plausible. If there is an NSEC3 whose hash matches the NS, it is supposed to be a secure delegation, and this is a forgery. This is the only way to guarantee that there isn't a secure delegation at that name - something that is strictly necessary to protect the secure delegations. So, it is about protecting secure delegations, not insecure delegations. And yes, this is rather deep stuff. Brian On Thu, Jun 30, 2011 at 3:18 PM, Sean Wells wrote: > Hi, > DNSSEC bis updates document states: > [RFC4035] Section 5.2 specifies that a validator, when proving a > > delegation is not secure, needs to check for the absence of the DS > and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also > needs to check for the presence of the NS bit in the matching NSEC > (or NSEC3) RR (proving that there is, indeed, a delegation), or > alternately make sure that the delegation is covered by an NSEC3 RR > with the Opt-Out flag set. If this is not checked, spoofed unsigned > delegations might be used to claim that an existing signed record is > not signed. > > The last sentence is confusing: what is a "spoofed unsigned delegation" ? > Let us say that there are two delegations one of which is secure. > > a.com is secure, so there is a DS record in com > > b.com is insecure, so there is a NSEC record for b.com in com with DS, SOA > bits not set but the NS bit set. > > I am looking up the DS record for "a.com". The attacker is responding the > NSEC record for b.com (or it was already in my cache). In this case, the > owner name does not match the SNAME (a.com). I thought we checked the bitmap > of the NSEC only if the owner name matches. This NSEC record might still be > accepted depending on what is there in the "Next domain field". Is this the > attack that is being described ? > > regards, > Sean > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > > From snwells82@gmail.com Thu Jun 30 20:11:18 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0141F0C3C for ; Thu, 30 Jun 2011 20:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.89 X-Spam-Level: X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKsnu++UiLLu for ; Thu, 30 Jun 2011 20:11:15 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6D1F0C37 for ; Thu, 30 Jun 2011 20:11:15 -0700 (PDT) Received: by vxi40 with SMTP id 40so2562416vxi.31 for ; Thu, 30 Jun 2011 20:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=diiVpUunmu0fy435qqcmvli9rxWojPr78hlzrNp1sq4=; b=pZ6KFaBkx7N3mWPIMRmBbzk+VO//YYNpO0Nn6HC6Ronq/El00ZYdCBm/V45S9WDtDl OO3WsO00FfM39xNSgLg50bPqdsaKwYVZWnu1djmMp6dcCNXYE3TZW2vLy1n/fzAvhSz8 2LMHeQ4JSVnGIysAnIzJQU6QMFLQlknLar/fA= MIME-Version: 1.0 Received: by 10.52.160.68 with SMTP id xi4mr204424vdb.106.1309489874582; Thu, 30 Jun 2011 20:11:14 -0700 (PDT) Received: by 10.220.198.200 with HTTP; Thu, 30 Jun 2011 20:11:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jun 2011 20:11:14 -0700 Message-ID: From: Sean Wells To: Brian Dickson Content-Type: multipart/alternative; boundary=bcaec53f9779cfbbbe04a6f95e92 Cc: dnsext@ietf.org Subject: Re: [dnsext] Insecure Delegation Proofs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 03:11:18 -0000 --bcaec53f9779cfbbbe04a6f95e92 Content-Type: text/plain; charset=ISO-8859-1 Brian, Thanks for the clarification. On Thu, Jun 30, 2011 at 2:30 PM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > No, the attack in question is NSEC3 specific. > > The current wording does not indicate that. It talks about both NSEC and NSEC3. NSEC3 records, when opt-out is in use, only existence for NS records > that also have a DS (or for non-NS records). > > In large, delegation-only zones, like most big TLDs, the ramp-up of > DNSSEC means that those zones will be relatively sparse from a NSEC3 > perspective. Most of the delegations will be insecure. > > Here, insecure means, "has no DS record". > > For an insecure NS RRset, the only DNSSEC records at that node could > be NSEC(3) and the RRSIG(NSEC(3)). If NSEC3 with opt-out is used for > the zone, there will be no signatures at all. If NSEC3 without opt-out > is used, there *will* be an NSEC3 and RRSIG(NSEC3). > > The "opt-out" means the "next-hash" is the > "next-hash-of-anything-which-is-not-an-NS-with-no-DS". > > Since the insecure NS records are not signed (at all!), they can be > spoofed. > (IMHO, the lack of signature on NS (without DS) is uncool in the > extreme. Having NS RRSIGs, even though they are not authoritative, > would still have been compatible with opt-out. But that ship has > sailed, as they say.) > > The attack is, to over-write a *signed* NS (with DS), by an unsigned > NS (with no DS or any other DNSSEC record). > > The defense is, to check the hash of any unsigned NS, and if it > matches an NSEC3 with opt-out, it clearly is a forgery and should be > discarded. > > Section 5.2 in RFC 4035 is about DS RRSets which is what is quoted in dnssec-bis. The attack that you are describing here looks different to me. The *real* challenge is, if the attacked owner-name has not yet been > fetched into the cache, that it becomes a resource-hit to check for > this (or race condition if the check isn't done - which is why it > needs to be done). > > To prevent this NS hijacking, the NS has to be hashed. If the previous > NSEC3 entry before it, does not cover it (i.e. have a next-hash > greater than its hash), subsequent NSEC3 (hashed) RRs need to be > retrieved, until the covering NSEC3 is found. If there is a covering > NSEC3, the insecure and unsigned delegation can be considered > plausible. If there is an NSEC3 whose hash matches the NS, it is > supposed to be a secure delegation, and this is a forgery. This is the > only way to guarantee that there isn't a secure delegation at that > name - something that is strictly necessary to protect the secure > delegations. > > So, it is about protecting secure delegations, not insecure delegations. > > And yes, this is rather deep stuff. > Do you mean to say that the last line I quoted means so much :-) Sean > > Brian > > On Thu, Jun 30, 2011 at 3:18 PM, Sean Wells wrote: > > Hi, > > DNSSEC bis updates document states: > > [RFC4035] Section 5.2 specifies that a validator, when proving a > > > > delegation is not secure, needs to check for the absence of the DS > > and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also > > needs to check for the presence of the NS bit in the matching NSEC > > (or NSEC3) RR (proving that there is, indeed, a delegation), or > > alternately make sure that the delegation is covered by an NSEC3 RR > > with the Opt-Out flag set. If this is not checked, spoofed unsigned > > delegations might be used to claim that an existing signed record is > > not signed. > > > > The last sentence is confusing: what is a "spoofed unsigned delegation" ? > > Let us say that there are two delegations one of which is secure. > > > > a.com is secure, so there is a DS record in com > > > > b.com is insecure, so there is a NSEC record for b.com in com with DS, > SOA > > bits not set but the NS bit set. > > > > I am looking up the DS record for "a.com". The attacker is responding > the > > NSEC record for b.com (or it was already in my cache). In this case, the > > owner name does not match the SNAME (a.com). I thought we checked the > bitmap > > of the NSEC only if the owner name matches. This NSEC record might still > be > > accepted depending on what is there in the "Next domain field". Is this > the > > attack that is being described ? > > > > regards, > > Sean > > > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > > --bcaec53f9779cfbbbe04a6f95e92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian,

Thanks for the clarification.

On Thu, Jun 30, 2011 at 2:30 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
No, the attack in question is NSEC3 specific= .

The current wording does not indicate that. =A0It tal= ks about both NSEC and NSEC3.

NSEC3 records, when opt-out is in use, only existence for NS records
that also have a DS (or for non-NS records).

In large, delegation-only zones, like most big TLDs, the ramp-up of
DNSSEC means that those zones will be relatively sparse from a NSEC3
perspective. Most of the delegations will be insecure.

Here, insecure means, "has no DS record".

For an insecure NS RRset, the only DNSSEC records at that node could
be NSEC(3) and the RRSIG(NSEC(3)). If NSEC3 with opt-out is used for
the zone, there will be no signatures at all. If NSEC3 without opt-out
is used, there *will* be an NSEC3 and RRSIG(NSEC3).

The "opt-out" means the "next-hash" is the
"next-hash-of-anything-which-is-not-an-NS-with-no-DS".

Since the insecure NS records are not signed (at all!), they can be spoofed= .
(IMHO, the lack of signature on NS (without DS) is uncool in the
extreme. Having NS RRSIGs, even though they are not authoritative,
would still have been compatible with opt-out. But that ship has
sailed, as they say.)

The attack is, to over-write a *signed* NS (with DS), by an unsigned
NS (with no DS or any other DNSSEC record).

The defense is, to check the hash of any unsigned NS, and if it
matches an NSEC3 with opt-out, it clearly is a forgery and should be
discarded.

=A0
Section 5.2 in RFC 4035 is about DS RRS= ets which is what is quoted in dnssec-bis. The
attack that you ar= e describing here looks different to me.

The *real* challenge is, if the attacked owner-name has not yet been
fetched into the cache, that it becomes a resource-hit to check for
this (or race condition if the check isn't done - which is why it
needs to be done).

To prevent this NS hijacking, the NS has to be hashed. If the previous
NSEC3 entry before it, does not cover it (i.e. have a next-hash
greater than its hash), subsequent NSEC3 (hashed) RRs need to be
retrieved, until the covering NSEC3 is found. If there is a covering
NSEC3, the insecure and unsigned delegation can be considered
plausible. If there is an NSEC3 whose hash matches the NS, it is
supposed to be a secure delegation, and this is a forgery. This is the
only way to guarantee that there isn't a secure delegation at that
name - something that is strictly necessary to protect the secure
delegations.

So, it is about protecting secure delegations, not insecure delegations.
And yes, this is rather deep stuff.
Do you mean to say= that the last line I quoted means so much :-)

Sea= n
=A0

Brian

On Thu, Jun 30, 2011 at 3:18 PM, Sean Wells <snwells82@gmail.com> wrote:
> Hi,
> DNSSEC bis updates document states:
> [RFC4035] Section 5.2 specifies that a validator, when proving a
>
> =A0 =A0delegation is not secure, needs to check for the absence of the= DS
> =A0 =A0and SOA bits in the NSEC (or NSEC3) type bitmap. =A0The validat= or also
> =A0 =A0needs to check for the presence of the NS bit in the matching N= SEC
> =A0 =A0(or NSEC3) RR (proving that there is, indeed, a delegation), or=
> =A0 =A0alternately make sure that the delegation is covered by an NSEC= 3 RR
> =A0 =A0with the Opt-Out flag set. =A0If this is not checked, spoofed u= nsigned
> =A0 =A0delegations might be used to claim that an existing signed reco= rd is
> =A0 =A0not signed.
>
> The last sentence is confusing: what is a "spoofed unsigned deleg= ation" ?
> Let us say that there are two delegations one of which is secure.
>
> a.com is secure, so the= re is a DS record in com
>
> b.com is insecure, so t= here is a NSEC record for b.com<= /a> in com with DS, SOA
> bits not set but the NS bit set.
>
> I am looking up the DS record for "a.com". The attacker is responding the
> NSEC record for b.com (= or it was already in my cache). In this case, the
> owner name does not match the SNAME (a.com). I thought we checked the bitmap
> of the NSEC only if the owner name matches. This NSEC record might sti= ll be
> accepted depending on what is there in the "Next domain field&quo= t;. Is this the
> attack that is being described ?
>
> regards,
> Sean
>
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
>
>
--bcaec53f9779cfbbbe04a6f95e92--